**Ayude a mejorar esta página** Para contribuir a esta guía del usuario, elija el enlace **Edit this page on GitHub** que se encuentra en el panel derecho de cada página. # Creación de nodos autoadministrados de Microsoft Windows Este tema describe cómo lanzar un grupo de Auto Scaling de nodos de Windows que se registrará con el clúster de Amazon EKS. Una vez que los nodos se hayan unido al clúster, puede implementar aplicaciones de Kubernetes en ellos. **importante** Los nodos de Amazon EKS son instancias estándar de Amazon EC2 y se le facturarán conforme a los precios ordinarios de las instancias de Amazon EC2. Para obtener más información, consulte [Precios de Amazon EC2](https://aws.amazon.com/ec2/pricing/). Puede lanzar nodos de Windows en clústeres extendidos de Amazon EKS en AWS Outposts, pero no puede lanzarlos en clústeres locales en AWS Outposts. Para obtener más información, consulte [Implementación de Amazon EKS en las instalaciones con AWS Outposts](eks-outposts.md). Habilite la compatibilidad con Windows para su clúster Recomendamos que revise las consideraciones importantes antes de lanzar un grupo de nodos de Windows. Para obtener más información, consulte [Habilitación de la compatibilidad con Windows](windows-support.md#enable-windows-support). Puede lanzar nodos de Windows autoadministrados con una de las siguientes opciones: + [`eksctl`](#eksctl_create_windows_nodes) + [Consola de administración de AWS](#console_create_windows_nodes) ## `eksctl` **Lanzamiento de nodos de Windows autoadministrados mediante `eksctl` ** En este procedimiento, se presupone que ha instalado `eksctl` y que su versión de `eksctl` es al menos `0.215.0`. Puede verificar la versión con el siguiente comando. ``` eksctl version ``` Para obtener instrucciones sobre cómo instalar o actualizar `eksctl`, consulte [Instalación](https://eksctl.io/installation) en la documentación de `eksctl`. **nota** Este procedimiento solo es válido para los clústeres que se crearon con `eksctl`. 1. (Opcional) Si la política de IAM administrada **AmazonEKS\$1CNI\$1Policy** (si tiene un clúster `IPv4`) o la política *AmazonEKS\$1CNI\$1IPv6\$1Policy* (que [haya creado](cni-iam-role.md#cni-iam-role-create-ipv6-policy) si tiene un clúster `IPv6`) están adjuntas a su [rol de IAM de nodos en Amazon EKS](create-node-role.md), le recomendamos asignarlas, en cambio, a un rol de IAM que asocie a la cuenta de servicio de `aws-node` de Kubernetes. Para obtener más información, consulte [Configuración del complemento de CNI de Amazon VPC para utilizar IRSA](cni-iam-role.md). 1. En este procedimiento, se presupone que dispone de un clúster existente. Si aún no tiene un clúster de Amazon EKS ni un grupo de nodos de Amazon Linux al cual agregarle un grupo de nodos de Windows, le recomendamos que siga la [Introducción a Amazon EKS: `eksctl`](getting-started-eksctl.md). En esta guía se proporciona una explicación completa para crear un clúster de Amazon EKS con nodos de Amazon Linux. Cree el grupo de nodos con el siguiente comando. Reemplace *region-code* por la región de AWS en la que se encuentra el clúster. Sustituya *my-cluster* por el nombre del clúster. El nombre solo puede contener caracteres alfanuméricos (con distinción de mayúsculas y minúsculas) y guiones. Debe comenzar con un carácter alfanumérico y no puede tener más de 100 caracteres. El nombre debe ser único dentro de la región de AWS y la cuenta de AWS en las que va a crear el clúster. Reemplace *ng-windows* por un nombre para su grupo de nodos. El nombre del grupo de nodos no puede tener más de 63 caracteres. Debe empezar por una letra o un dígito, pero también puede incluir guiones y guiones bajos como caracteres no iniciales. Puede reemplazar *2019* por `2022` para usar Windows Server 2022 o por `2025` para usar Windows Server 2025. Sustituya el resto de los valores de ejemplo por sus propios valores. **importante** Para implementar un grupo de nodos en las subredes de AWS Outposts, AWS Wavelength o zonas locales de AWS, no pase las subredes de AWS Outposts, Wavelength o zonas locales al crear el clúster. Cree el grupo de nodos con un archivo de configuración, que especifique las subredes de AWS Outposts, Wavelength o Local Zone. Para obtener más información, consulte [Crear un grupo de nodos a partir de un archivo de Config](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) y el [Esquema de archivo de configuración](https://eksctl.io/usage/schema/) en la documentación de `eksctl`. ``` eksctl create nodegroup \ --region region-code \ --cluster my-cluster \ --name ng-windows \ --node-type t2.large \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --managed=false \ --node-ami-family WindowsServer2019FullContainer ``` **nota** Si los nodos no se unen al clúster, consulte [Los nodos no pueden unirse al clúster](troubleshooting.md#worker-node-fail) en la Guía de solución de problemas. Para ver las opciones disponibles para los comandos `eksctl`, ingrese el siguiente comando. ``` eksctl command -help ``` Un ejemplo de salida sería el siguiente. Se generan varias líneas mientras se crean los nodos. Una de las últimas líneas de salida es la siguiente línea de ejemplo. ``` [✔] created 1 nodegroup(s) in cluster "my-cluster" ``` 1. (Opcional) Implemente una [aplicación de muestra](sample-deployment.md) para probar el clúster y los nodos de Windows. 1. Se recomienda bloquear el acceso al pod a IMDS si se cumplen las siguientes condiciones: + Tiene previsto asignar roles de IAM a todas sus cuentas de servicio de Kubernetes para que los pods solo tengan los permisos mínimos que necesitan. + Ninguno de los pods del clúster requiere acceso al servicio de metadatos de instancias (IMDS) de Amazon EC2 por otros motivos, como la recuperación de la región de AWS actual. Para obtener más información, consulte [Restringir el acceso al perfil de instancias asignado al nodo de trabajo](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node). ## Consola de administración de AWS **Requisitos previos** + Un clúster de Amazon EKS existente y un grupo de nodos de Linux. Si no tiene estos recursos, recomendamos que siga una de nuestras guías de para crearlos [Introducción a Amazon EKS](getting-started.md). En las guías se describe cómo crear un clúster de Amazon EKS con nodos de Linux. + Una VPC y un grupo de seguridad existentes que cumplen los requisitos para un clúster de Amazon EKS. Para obtener más información, consulte [Requisitos de red de Amazon EKS para VPC y subredes](network-reqs.md) y [Revisión de requisitos de grupos de seguridad de Amazon EKS para clústeres](sec-group-reqs.md). Las guías de [Introducción a Amazon EKS](getting-started.md) crean una VPC que cumple los requisitos. Si lo desea, también puede seguir [Creación de una Amazon VPC para su clúster de Amazon EKS](creating-a-vpc.md) para crear una manualmente. + Un clúster de Amazon EKS existente que utiliza una VPC y un grupo de seguridad que cumplen los requisitos de un clúster de Amazon EKS. Para obtener más información, consulte [Creación de un clúster de Amazon EKS](create-cluster.md). Si tiene subredes en la región de AWS, donde están habilitadas las subredes AWS Outposts, AWS Wavelength o zonas locales de AWS, estas no se deben haber pasado al crear el clúster. **Paso 1: lanzar nodos de Windows autoadministrados mediante la Consola de administración de AWS ** 1. Espere a que el estado del clúster sea `ACTIVE`. Si lanza los nodos antes de que el clúster esté activo, los nodos no pueden registrarse con el clúster y debe volver a lanzarlos. 1. Abra la [consola de AWS CloudFormation](https://console.aws.amazon.com/cloudformation/) 1. Elija **Crear pila**. 1. En **Especificar plantilla**, seleccione **URL de Amazon S3**. 1. Copie la siguiente URL y péguela en la **URL de Amazon S3**. ``` https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2023-02-09/amazon-eks-windows-nodegroup.yaml ``` 1. Seleccione **Siguiente** dos veces. 1. En la página **Creación rápida de pila**, ingrese los siguientes parámetros según corresponda: + **Nombre de pila**: elija un nombre para su pila de AWS CloudFormation. Por ejemplo, puede llamarla `my-cluster-nodes`. + **ClusterName**: ingrese el nombre que usó al crear el clúster de Amazon EKS. **importante** El nombre debe coincidir exactamente con el nombre que utilizó en el [Paso 1: Creación del clúster de Amazon EKS](getting-started-console.md#eks-create-cluster). De lo contrario, los nodos no podrán unirse al clúster. + **ClusterControlPlaneSecurityGroup**: elija el grupo de seguridad de la salida de AWS CloudFormation que generó al crear la [VPC](creating-a-vpc.md). En los pasos siguientes se muestra un método para recuperar el grupo aplicable. 1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Elija el nombre del clúster. 1. Elija la pestaña **Redes**. 1. Use el valor de **Grupo de seguridad adicional** como referencia al realizar una selección en la lista desplegable **ClusterControlPlaneSecurityGroup**. + **NodeGroupName**: escriba un nombre para el grupo de nodos. Este nombre se puede utilizar más adelante para identificar el grupo de nodos de escalado automático que se crea para los nodos. El nombre del grupo de nodos no puede tener más de 63 caracteres. Debe empezar por una letra o un dígito, pero también puede incluir guiones y guiones bajos como caracteres no iniciales. + **NodeAutoScalingGroupMinSize**: ingrese el número mínimo de nodos al que se puede reducir horizontalmente el grupo de escalado automático de nodos. + **NodeAutoScalingGroupDesiredCapacity**: escriba el número deseado de nodos que desea escalar cuando se crea la pila. + **NodeAutoScalingGroupMaxSize**: ingrese el número máximo de nodos que pueda alcanzar el grupo de Auto Scaling de nodos. + **NodeInstanceType**: elija un tipo de instancia para los nodos. Para obtener más información, consulte [Elección de un tipo de instancia de nodo de Amazon EC2 óptimo](choosing-instance-type.md). **nota** Los tipos de instancias compatibles con la versión más reciente del [complemento CNI de Amazon VPC para Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) se muestran en [vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go) en GitHub. Es posible que tenga que actualizar la versión de CNI para utilizar los tipos de instancia admitidos más recientes. Para obtener más información, consulte [Asignación de direcciones IP a pods con CNI de Amazon VPC](managing-vpc-cni.md). + **NodeImageIdSSMParam**: contiene un valor especificado previamente, que es el parámetro de Amazon EC2 Systems Manager del ID de la AMI de Windows Core optimizada para Amazon EKS más reciente recomendada. Para utilizar la versión completa de Windows, sustituya *Core* por `Full`. + **NodeImageId**: (opcional) si utiliza una AMI personalizada propia (en lugar de una AMI optimizada para Amazon EKS), escriba un ID de AMI de nodo para la región de AWS. Si especifica un valor para este campo, anula cualquier valor del campo **NodeImageIdSSMParam**. + **NodeVolumeSize**: especifique un tamaño de volumen raíz para los nodos en GiB. + **KeyName**: ingrese el nombre de un par de claves SSH de Amazon EC2 que pueda utilizar para conectar mediante SSH con los nodos después de haberlos lanzado. Si aún no tiene un par de claves de Amazon EC2, puede crear uno en la Consola de administración de AWS. Para obtener más información, consulte [Pares de claves de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html) en la *Guía del usuario de Amazon EC2*. **nota** Si no proporciona un par de claves aquí, se produce un error al crear la pila de AWS CloudFormation. + **BootstrapArguments**: especifique los argumentos opcionales que se van a pasar al script de arranque del nodo, como los argumentos de `kubelet` adicionales mediante `-KubeletExtraArgs`. + **DisableIMDSv1**: cada nodo admite de forma predeterminada la versión 1 (IMDSv1) e IMDSv2 del servicio de metadatos de la instancia. Puede desactivar IMDSv1. Para evitar que los nodos y pods futuros del grupo de nodos utilicen MDSv1, defina **DisableIMDSv1** en **verdadero**. Para obtener más información, consulte [Configurar el servicio de metadatos de instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html). + **VpcId**: seleccione el ID de la [VPC](creating-a-vpc.md) que creó. + **NodeSecurityGroups**: seleccione el grupo de seguridad que se creó para su grupo de nodos de Linux cuando creó la [VPC](creating-a-vpc.md). Si sus nodos de Linux tienen más de un grupo de seguridad adjuntado a ellos, especifíquelos a todos aquí. Esto, por ejemplo, si el grupo de nodos Linux se creó con `eksctl`. + **Subredes**: elija las subredes que creó. Si creó la VPC siguiendo los pasos que se describen en [Creación de Amazon VPC para su clúster de Amazon EKS](creating-a-vpc.md), especifique solo las subredes privadas en la VPC en las que desea lanzar los nodos. **importante** Si alguna de las subredes es pública, debe tener habilitada la configuración de asignación automática de direcciones IP públicas. Si la configuración no está habilitada para la subred pública, los nodos que implemente en dicha subred pública no tendrán asignada una dirección IP pública y no podrán comunicarse con el clúster u otros servicios de AWS. Si la subred se implementó antes del 26 de marzo de 2020 mediante cualquiera de las [plantillas de VPC de AWS CloudFormation de Amazon EKS](creating-a-vpc.md) o mediante `eksctl`, la asignación automática de direcciones IP públicas se deshabilitará en las subredes públicas. Para obtener información acerca de cómo habilitar la asignación de direcciones IP públicas en una subred, consulte [Modificación del atributo de direcciones IPv4 públicas de su subred](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip). Si el nodo se implementa en una subred privada, podrá comunicarse con el clúster y otros servicios de AWS a través de una puerta de enlace NAT. Si las subredes no tienen acceso a Internet, asegúrese de que conoce las consideraciones y los pasos adicionales en [Implementación de clústeres privados con acceso limitado a Internet](private-clusters.md). Si selecciona las subredes de AWS Outposts, Wavelength o zonas locales, las subredes no se deben haber pasado cuando creó el clúster. 1. Confirme que la pila pueda crear recursos de IAM y, a continuación, seleccione **Crear pila**. 1. Una vez completada la creación de la pila, selecciónela en la consola y elija **Salidas**. 1. Anote el valor de **NodeInstanceRoles** correspondiente al grupo de nodos creado. Lo necesitará al configurar los nodos de Windows para Amazon EKS. **Paso 2: habilitación para que los nodos se unan al clúster** 1. Verifique si ya tiene el `ConfigMap` de `aws-auth`. ``` kubectl describe configmap -n kube-system aws-auth ``` 1. Si se le muestra un `ConfigMap` de `aws-auth`, actualícelo según sea necesario. 1. Abra el icono `ConfigMap` para editar. ``` kubectl edit -n kube-system configmap/aws-auth ``` 1. Añada nuevas entradas de `mapRoles` según sea necesario. Establezca los valores de `rolearn` en los valores de **NodeInstanceRole** que registró en los procedimientos anteriores. ``` [...] data: mapRoles: | - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - eks:kube-proxy-windows [...] ``` 1. Guarde el archivo y salga del editor de texto. 1. Si recibe un error que indica “`Error from server (NotFound): configmaps "aws-auth" not found`, aplique el `ConfigMap` bursátil. 1. Descargue el mapa de configuración. ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml ``` 1. En el archivo `aws-auth-cm-windows.yaml`, establezca los valores de `rolearn` a los valores **NodeInstanceRole** que ha registrado en el procedimiento anterior. Puede hacerlo con un editor de texto o reemplazando los valores de ejemplo y ejecutando el siguiente comando: ``` sed -i.bak -e 's||my-node-linux-instance-role|' \ -e 's||my-node-windows-instance-role|' aws-auth-cm-windows.yaml ``` **importante** No modifique ninguna otra línea de este archivo. No utilice el mismo rol de IAM para los nodos de Windows y Linux. 1. Aplique la configuración. Este comando podría tardar varios minutos en finalizar. ``` kubectl apply -f aws-auth-cm-windows.yaml ``` 1. Observe el estado de los nodos y espere a que aparezca el estado `Ready`. ``` kubectl get nodes --watch ``` Ingrese `Ctrl`\$1`C` para obtener un símbolo del intérprete de comandos. **nota** Si recibe cualquier error de tipo de recurso o autorización, consulte [Acceso denegado o no autorizado (`kubectl`)](troubleshooting.md#unauthorized) en el tema de solución de problemas. Si los nodos no se unen al clúster, consulte [Los nodos no pueden unirse al clúster](troubleshooting.md#worker-node-fail) en el capítulo de solución de problemas. **Paso 3: acciones adicionales** 1. (Opcional) Implemente una [aplicación de muestra](sample-deployment.md) para probar el clúster y los nodos de Windows. 1. (Opcional) Si la política de IAM administrada **AmazonEKS\$1CNI\$1Policy** (si tiene un clúster `IPv4`) o la política *AmazonEKS\$1CNI\$1IPv6\$1Policy* (que [haya creado](cni-iam-role.md#cni-iam-role-create-ipv6-policy) si tiene un clúster `IPv6`) están adjuntas a su [rol de IAM de nodos en Amazon EKS](create-node-role.md), le recomendamos asignarlas a un rol de IAM que asocie a la cuenta de servicio de `aws-node` de Kubernetes como alternativa. Para obtener más información, consulte [Configuración del complemento de CNI de Amazon VPC para utilizar IRSA](cni-iam-role.md). 1. Se recomienda bloquear el acceso al pod a IMDS si se cumplen las siguientes condiciones: + Tiene previsto asignar roles de IAM a todas sus cuentas de servicio de Kubernetes para que los pods solo tengan los permisos mínimos que necesitan. + Ninguno de los pods del clúster requiere acceso al servicio de metadatos de instancias (IMDS) de Amazon EC2 por otros motivos, como la recuperación de la región de AWS actual. Para obtener más información, consulte [Restringir el acceso al perfil de instancias asignado al nodo de trabajo](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).