**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. # Mantenimiento de nodos por cuenta propia con nodos autoadministrados Un clúster contiene uno o varios nodos de Amazon EC2 en los que están programados los pods. Los nodos de Amazon EKS se ejecutan en su cuenta de AWS y se conectan con el plano de control del clúster a través del punto de conexión del servidor de la API del clúster. Se le factura por ellos en función de los precios de Amazon EC2. Para obtener más información, consulte [Precios de Amazon EC2](https://aws.amazon.com/ec2/pricing/). Un clúster puede contener varios grupos de nodos. Cada grupo de nodos contiene uno o varios nodos que se implementan en un [grupo de Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html). El tipo de instancia de los nodos del grupo puede variar; por ejemplo, cuando se utiliza [la selección del tipo de instancia basada en atributos](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html) con [Karpenter](https://karpenter.sh/). Todas las instancias de un grupo de nodos deben utilizar el [rol de IAM del nodo de Amazon EKS](create-node-role.md). Amazon EKS proporciona imágenes de máquina de Amazon (AMI) especializadas que se denominan AMI optimizadas para Amazon EKS. Las AMI están configuradas para funcionar con Amazon EKS. Sus componentes incluyen `containerd`, `kubelet` y el Autenticador de AWS IAM. Las AMI también contienen un [script de arranque](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) especializado que permite detectar el plano de control del clúster y conectarse automáticamente a él. Si restringe el acceso al punto de conexión público del clúster mediante bloques de CIDR, recomendamos habilitar también el acceso al punto de conexión privado. Esto permite que los nodos se puedan comunicar con el clúster. Si el punto de conexión privado no está habilitado, los bloques de CIDR que especifique para el acceso público deben incluir los orígenes de salida de su VPC. Para obtener más información, consulte [Punto de conexión del servidor de API del clúster](cluster-endpoint.md). Para agregar nodos autoadministrados a su clúster de Amazon EKS, consulte los temas siguientes. Si lanza de forma manual nodos autoadministrados, debe agregar la siguiente etiqueta a cada nodo y asegurarse de que `` coincida con el clúster. Para obtener más información, consulte [Cómo agregar etiquetas a un recurso individual y eliminarlas de él](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags). Si sigue los pasos de las siguientes guías, se agregará automáticamente la etiqueta necesaria a los nodos. | Clave | Valor | | --- | --- | | `kubernetes.io/cluster/` | `owned` | **importante** Las etiquetas del Servicio de metadatos de instancias (IMDS) de Amazon EC2 no son compatibles con los nodos de EKS. Cuando las etiquetas de metadatos de instancia están habilitadas, se impide el uso de barras diagonales (“/”) en los valores de las etiquetas. Esta limitación puede provocar errores en el lanzamiento de las instancias, especialmente cuando se utilizan herramientas de administración de nodos como Karpenter o el Escalador automático de clústeres, ya que estos servicios dependen de etiquetas que contienen barras diagonales para funcionar correctamente. Para obtener más información sobre los nodos desde un punto de vista general de Kubernetes, consulte [Nodos](https://kubernetes.io/docs/concepts/architecture/nodes/) en la documentación de Kubernetes. **Topics** + [Creación de nodos autoadministrados de Amazon Linux](launch-workers.md) + [Creación de nodos de Bottlerocket autoadministrados](launch-node-bottlerocket.md) + [Creación de nodos autoadministrados de Microsoft Windows](launch-windows-workers.md) + [Creación de nodos autoadministrados de Linux para Ubuntu](launch-node-ubuntu.md) + [Actualización de los nodos autoadministrados para un clúster](update-workers.md) # Creación de nodos autoadministrados de Amazon Linux En este tema, se describe cómo puede lanzar grupos de escalado automático de nodos de Linux 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. También puede lanzar nodos de Amazon Linux autoadministrados con `eksctl` o la Consola de administración de AWS. Si necesita lanzar nodos en AWS Outposts, consulte [Creación de nodos de Amazon Linux en AWS Outposts](eks-outposts-self-managed-nodes.md). + Un clúster existente de Amazon EKS. Para implementar uno, 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 AWS Local Zones, estas no se deben haber pasado al crear su clúster. + Un rol de IAM existente para que lo utilicen los nodos. Para crear uno, consulte [Rol de IAM de nodo de Amazon EKS](create-node-role.md). Si este rol no tiene ninguna de las políticas de la CNI de la VPC, es necesario el rol independiente que se indica a continuación para los pods de la CNI de la VPC. + (Opcional, pero recomendado) El complemento CNI de Amazon VPC para Kubernetes configurado con su propio rol de IAM que tenga adjunta la política de IAM necesaria. Para obtener más información, consulte [Configuración del complemento de CNI de Amazon VPC para utilizar IRSA](cni-iam-role.md). + Familiaridad con las consideraciones que se enumeran en [Elección de un tipo de instancia de nodo de Amazon EC2 óptimo](choosing-instance-type.md). Según el tipo de instancia que elija, es posible que haya requisitos previos adicionales para su clúster y VPC. Puede lanzar nodos de Linux autoadministrados con una de las siguientes opciones: + [`eksctl`](#eksctl_create_managed_amazon_linux) + [Consola de administración de AWS](#console_create_managed_amazon_linux) ## `eksctl` **Lanzamiento de nodos de Linux autoadministrados mediante `eksctl` ** 1. Instale la versión `0.215.0` o posterior de la herramienta de línea de comandos de `eksctl` instalada en su dispositivo o AWS CloudShell. Para instalar o actualizar `eksctl`, consulte la sección de [Instalación](https://eksctl.io/installation) en la documentación de `eksctl`. 1. (Opcional) Si la política de IAM administrada **AmazonEKS\$1CNI\$1Policy** se adjunta a su [rol de IAM de nodos de Amazon EKS](create-node-role.md), recomendamos asignarla a un rol de IAM asociado a la cuenta de servicio de `aws-node` de Kubernetes en su lugar. Para obtener más información, consulte [Configuración del complemento de CNI de Amazon VPC para utilizar IRSA](cni-iam-role.md). 1. El siguiente comando crea un grupo de nodos en un clúster existente. Sustituya *al-nodes* 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. Reemplace *my-cluster* por el nombre de su 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. Sustituya los *valores de ejemplo* restantes por sus propios valores. Los nodos se crean de forma predeterminada con la misma versión de Kubernetes que el plano de control. Antes de elegir un valor de `--node-type`, consulte [Elección de un tipo de instancia de nodo de Amazon EC2 óptimo](choosing-instance-type.md). Reemplace *my-key* con el nombre de su par de claves de Amazon EC2 o la clave pública. Esta clave se utiliza para SSH en sus nodos después de que se lancen. 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/UserGuide/ec2-key-pairs.html) en la *Guía del usuario de Amazon EC2*. Cree el grupo de nodos con el siguiente comando. **importante** Si desea implementar un grupo de nodos en las subredes de AWS Outposts, Wavelength o zonas locales, existen consideraciones adicionales: Las subredes no deben haberse transferido al crear el clúster. Debe crear el grupo de nodos con un archivo de configuración, que especifique las subredes y ` [volumeType](https://eksctl.io/usage/schema/#nodeGroups-volumeType): gp2`. 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 \ --cluster my-cluster \ --name al-nodes \ --node-type t3.medium \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --ssh-access \ --managed=false \ --ssh-public-key my-key ``` Para implementar un grupo de nodos que: + pueda asignar un número significativamente mayor de direcciones IP a pods que la configuración predeterminada, consulte [Asignación de más direcciones IP a los nodos de Amazon EKS con prefijos](cni-increase-ip-addresses.md). + pueda asignar direcciones `IPv4` a pods de un bloque de CIDR diferente que el de la instancia, consulte [Implementación de pods en subredes alternativas con redes personalizadas](cni-custom-network.md). + pueda asignar direcciones `IPv6` a los pods y los servicios, consulte [Información sobre la asignación de direcciones IPv6 a clústeres, pods y servicios](cni-ipv6.md). + no tenga acceso saliente a internet, consulte [Implementación de clústeres privados con acceso limitado a Internet](private-clusters.md). Para obtener una lista completa de todas las opciones y valores predeterminados disponibles, ingrese el siguiente comando. ``` eksctl create nodegroup --help ``` 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. 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 Linux. 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 **Paso 1: lanzamiento de nodos de Linux autoadministrados mediante la Consola de administración de AWS ** 1. Descargue la versión más reciente de la plantilla de AWS CloudFormation. ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2025-11-26/amazon-eks-nodegroup.yaml ``` 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 tendrá que volver a lanzarlos. 1. Abra la [AWS consola de CloudFormation](https://console.aws.amazon.com/cloudformation/). 1. Seleccione **Create stack (Crear pila)** y, a continuación, seleccione **With new resources (standard) (Con nuevos recursos [estándar])**. 1. Para **Especificar plantilla**, seleccione **Cargar un archivo de plantilla** y, a continuación, elija **Elegir archivo**. 1. Edite el archivo `amazon-eks-nodegroup.yaml` que ha descargado. 1. Seleccione **Siguiente**. 1. En la página **Especificar detalles de la pila**, ingrese los siguientes parámetros según corresponda y luego seleccione **Siguiente**: + **Nombre de pila**: elija un nombre para su pila de AWS CloudFormation. Por ejemplo, puede llamarla *my-cluster-nodes*. 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. + **ClusterName**: ingrese el nombre que usó al crear el clúster de Amazon EKS. Este nombre debe coincidir con el nombre del clúster o los nodos no se podrán unir al clúster. + **ClusterControlPlaneSecurityGroup**: elija el valor de **SecurityGroups** de la salida de AWS CloudFormation que generó al crear su [VPC](creating-a-vpc.md). En los siguientes pasos, se muestra una operación 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**. + **ApiServerEndpoint**: ingrese el punto de conexión del servidor de API para el clúster de EKS. Puede consultarlo en la sección Detalles de la consola de Clústeres de EKS. + **CertificateAuthorityData**: ingrese los datos de la autoridad de certificación codificados en base64, que también se encuentran en la sección Detalles de la consola de Clústeres de EKS. + **ServiceCidr**: ingrese el rango CIDR que se usó para asignar las direcciones IP a los servicios de Kubernetes en el clúster. Se encuentra en la pestaña Redes de la consola de Clústeres de EKS. + **AuthenticationMode**: para seleccionar el modo de autenticación que se usa en el clúster de EKS, consulte la pestaña de acceso en la consola de Clústeres de EKS. + **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). + **NodeImageIdSSMParam**: se rellena previamente con el parámetro de Amazon EC2 Systems Manager de una AMI de Amazon Linux 2023 optimizada recientemente para Amazon EKS para una versión de Kubernetes variable. Para utilizar otra versión secundaria de Kubernetes compatible con Amazon EKS, reemplace *1.XX* por una [versión admitida](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) diferente. Recomendamos especificar la misma versión de Kubernetes que el clúster. También puede sustituir *amazon-linux-2023* por un tipo de AMI diferente. Para obtener más información, consulte [Obtención de los ID de AMI de Amazon Linux recomendados](retrieve-ami-id.md). **nota** Las AMI de los nodos de Amazon EKS se basan en Amazon Linux. Puede realizar un seguimiento de los eventos de seguridad o privacidad de Amazon Linux 2023 en el [Centro de seguridad de Amazon Linux](https://alas.aws.amazon.com/alas2023.html) o suscribirse a la [fuente RSS](https://alas.aws.amazon.com/AL2023/alas.rss) asociada. Los eventos de seguridad y privacidad incluyen información general del problema, qué paquetes están afectados y cómo actualizar las instancias para corregir el problema. + **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 aquí, anula cualquier valor del campo **NodeImageIdSSMParam**. + **NodeVolumeSize**: especifique un tamaño de volumen raíz para los nodos en GiB. + **NodeVolumeType**: especifique un tipo de volumen raíz para sus nodos. + **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/UserGuide/ec2-key-pairs.html) en la *Guía del usuario de Amazon EC2*. + **VpcId**: ingrese el ID de la [VPC](creating-a-vpc.md) que ha creado. + **Subredes**: elija las subredes que creó para la VPC. Si creó la VPC siguiendo los pasos que se describen en [Creación de una 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. Puede ver qué subredes son privadas abriendo cada enlace de subred desde la pestaña **Redes** de su clúster. **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. Seleccione las opciones que desee en la página **Configurar las opciones de pila** y, a continuación, elija **Siguiente**. 1. Seleccione la casilla de verificación a la izquierda de **Reconozco que AWS podría crear recursos de IAM** y, luego, seleccione **Crear pila**. 1. Una vez completada la creación de la pila, selecciónela en la consola y elija **Salidas**. Si utiliza los modos de autenticación `EKS API` o `EKS API and ConfigMap`, este es el último paso. 1. Si utiliza el modo de autenticación `ConfigMap`, registre el valor de **NodeInstanceRole** correspondiente al grupo de nodos que se creó. **Paso 2: habilitación para que los nodos se unan al clúster** **nota** Los dos pasos siguientes solo son necesarios si se utiliza el modo de autenticación ConfigMap en el clúster de EKS. Además, si ha lanzado nodos dentro de una VPC privada sin acceso a Internet saliente, asegúrese de activar los nodos para que se unan al clúster desde dentro de la VPC. 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 una nueva entrada de `mapRoles` según sea necesario. Establezca el valor de `rolearn` en el valor de **NodeInstanceRole** que registró en el procedimiento anterior. ``` [...] data: mapRoles: | - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes [...] ``` 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.yaml ``` 1. En el archivo `aws-auth-cm.yaml`, establezca el valor de `rolearn` al valor **NodeInstanceRole** que ha registrado en el procedimiento anterior. Puede hacerlo con un editor de texto o al reemplazar *my-node-instance-role* y ejecutar el siguiente comando: ``` sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml ``` 1. Aplique la configuración. Este comando puede tardar varios minutos en finalizar. ``` kubectl apply -f aws-auth-cm.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. 1. (Solo para nodos de GPU) Si ha elegido un tipo de instancia de GPU y la AMI acelerada optimizada para Amazon EKS, debe aplicar el [complemento de dispositivo NVIDIA para Kubernetes](https://github.com/NVIDIA/k8s-device-plugin) como un DaemonSet en el clúster. Reemplace *vX.X.X* con la versión [NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin/releases) deseada antes de ejecutar el siguiente comando. ``` kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X.X/deployments/static/nvidia-device-plugin.yml ``` **Paso 3: acciones adicionales** 1. (Opcional) Implemente una [aplicación de muestra](sample-deployment.md) para probar el clúster y los nodos de Linux. 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). # Creación de nodos de Bottlerocket autoadministrados **nota** Los grupos de nodos administrados podrían ofrecer algunas ventajas para su caso de uso. Para obtener más información, consulte [Simplificación del ciclo de vida de los nodos con grupos de nodos administrados](managed-node-groups.md). En este tema, se describe cómo puede lanzar un grupo de escalado automático de nodos de [Bottlerocket](https://aws.amazon.com/bottlerocket/) que se registrará con el clúster de Amazon EKS. Bottlerocket es un sistema operativo de código abierto basado en Linux de AWS que puede utilizar para ejecutar contenedores en máquinas virtuales o hosts bare metal. Una vez que los nodos se hayan unido al clúster, puede implementar aplicaciones de Kubernetes en ellos. Para obtener más información acerca de Bottlerocket, consulte [Uso de una AMI de Bottlerocket con Amazon EKS](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-EKS.md) en GitHub y [Compatibilidad con AMI personalizada](https://eksctl.io/usage/custom-ami-support/) en la documentación de `eksctl`. Para obtener información sobre actualizaciones en contexto, consulte [Operador de actualización de Bottlerocket](https://github.com/bottlerocket-os/bottlerocket-update-operator) en GitHub. **importante** Los nodos de Amazon EKS son instancias estándar de Amazon EC2 y se les 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 Bottlerocket 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). Puede implementar en instancias de Amazon EC2 con procesadores `x86` o Arm. Sin embargo, no puede implementar en instancias que tienen chips Inferentia. Bottlerocket es compatible con AWS CloudFormation. Sin embargo, no existe ninguna plantilla oficial de CloudFormation que pueda copiarse para implementar nodos de Bottlerocket para Amazon EKS. Las imágenes de Bottlerocket no vienen con un servidor SSH ni un intérprete de comandos. Puede utilizar métodos de acceso fuera de banda para permitir que SSH habilite el contenedor de administración y superar algunos pasos de configuración de arranque con datos de usuario. Para obtener más información, consulte estas secciones en [bottlerocket README.md](https://github.com/bottlerocket-os/bottlerocket) en GitHub: [Exploration (Exploración](https://github.com/bottlerocket-os/bottlerocket#exploration) [Contenedor de administrador](https://github.com/bottlerocket-os/bottlerocket#admin-container) [Configuración de Kubernetes](https://github.com/bottlerocket-os/bottlerocket#kubernetes-settings) En este procedimiento, se requiere la versión `0.215.0` o posterior de `eksctl`. Puede verificar la versión con el siguiente comando: ``` eksctl version ``` Para obtener instrucciones acerca de cómo instalar o actualizar `eksctl`, consulte [Instalación](https://eksctl.io/installation) en la documentación de `eksctl`. NOTA: Este procedimiento solo funciona en los clústeres que se crearon con `eksctl`. 1. Copie los siguientes contenidos en su dispositivo. Reemplace *my-cluster* por el nombre de su 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-bottlerocket* 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. Para implementar en instancias Arm, reemplace *m5.large* por un tipo de instancia Arm. Sustituya *my-ec2-keypair-name* por 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/UserGuide/ec2-key-pairs.html) en la *Guía del usuario de Amazon EC2*. Sustituya todos los valores de ejemplo restantes por sus propios valores. Una vez que haya llevado a cabo las sustituciones, ejecute el comando modificado para crear el archivo `bottlerocket.yaml`. Si especifica un tipo de instancia Arm de Amazon EC2, revise las consideraciones en [AMI de Amazon Linux optimizada para Amazon EKS Arm](eks-optimized-ami.md#arm-ami) antes de llevar a cabo la implementación. Para ver instrucciones sobre cómo implementar mediante una AMI personalizada, consulte [Creación de Bottlerocket](https://github.com/bottlerocket-os/bottlerocket/blob/develop/BUILDING.md) en GitHub y [Compatibilidad con AMI personalizada](https://eksctl.io/usage/custom-ami-support/) en la documentación de `eksctl`. Para implementar un grupo de nodos administrados, implemente una AMI personalizada mediante el uso de una plantilla de lanzamiento. Para obtener más información, consulte [Personalización de nodos administrados con plantillas de lanzamiento](launch-templates.md). **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, AWS Wavelength o Zonas locales de AWS al crear el clúster. Debe especificar las subredes en el siguiente ejemplo. 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`. Reemplace *region-code* por la región de AWS en la que se encuentra el clúster. ``` cat >bottlerocket.yaml < 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). # Creación de nodos autoadministrados de Linux para Ubuntu **nota** Los grupos de nodos administrados podrían ofrecer algunas ventajas para su caso de uso. Para obtener más información, consulte [Simplificación del ciclo de vida de los nodos con grupos de nodos administrados](managed-node-groups.md). En este tema, se describe cómo lanzar grupos de escalado automático de nodos de [Ubuntu en Amazon Elastic Kubernetes Service (EKS)](https://cloud-images.ubuntu.com/aws-eks/) o [Ubuntu Pro en Amazon Elastic Kubernetes Service (EKS)](https://ubuntu.com/blog/ubuntu-pro-for-eks-is-now-generally-available) que se registran con el clúster de Amazon EKS. Ubuntu y Ubuntu Pro para EKS se basan en Ubuntu Minimal LTS oficial, incluyen el kernel de AWS personalizado que se desarrolla junto con AWS y se han creado específicamente para EKS. Ubuntu Pro agrega una cobertura de seguridad adicional, ya que es compatible con los periodos de soporte ampliados de EKS, el parche activo del kernel, la compatibilidad con FIPS y la capacidad de ejecutar contenedores Pro ilimitados. Una vez que los nodos se hayan unido al clúster, puede implementar aplicaciones de contenedores en ellos. Para obtener más información, consulte la documentación sobre [Ubuntu en AWS](https://documentation.ubuntu.com/aws/en/latest/) y la [Compatibilidad con AMI personalizada](https://eksctl.io/usage/custom-ami-support/) en la documentación de `eksctl`. **importante** Los nodos de Amazon EKS son instancias estándar de Amazon EC2 y se les 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 Ubuntu 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). Puede implementar en instancias de Amazon EC2 con procesadores `x86` o Arm. Sin embargo, es posible que las instancias que tienen chips de Inferentia deban instalar primero el [SDK de Neuron](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/). En este procedimiento, se requiere la versión `0.215.0` o posterior de `eksctl`. Puede verificar la versión con el siguiente comando: ``` eksctl version ``` Para obtener instrucciones acerca de cómo instalar o actualizar `eksctl`, consulte [Instalación](https://eksctl.io/installation) en la documentación de `eksctl`. NOTA: Este procedimiento solo funciona en los clústeres que se crearon con `eksctl`. 1. Copie los siguientes contenidos en su dispositivo. Reemplace `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 alfabético y no puede tener más de 100 caracteres. Reemplace `ng-ubuntu` 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. Para implementar en instancias Arm, reemplace `m5.large` por un tipo de instancia Arm. Sustituya `my-ec2-keypair-name` por 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/UserGuide/ec2-key-pairs.html) en la Guía del usuario de Amazon EC2. Sustituya todos los valores de ejemplo restantes por sus propios valores. Una vez que haya llevado a cabo las sustituciones, ejecute el comando modificado para crear el archivo `ubuntu.yaml`. **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, AWS Wavelength o Zonas locales de AWS al crear el clúster. Debe especificar las subredes en el siguiente ejemplo. 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`. Reemplace *region-code* por la región de AWS en la que se encuentra el clúster. ``` cat >ubuntu.yaml < Cuando se lanza una nueva AMI optimizada para Amazon EKS, considere la posibilidad de reemplazar los nodos del grupo de nodos autoadministrados con la nueva AMI. Asimismo, si ha actualizado la versión de Kubernetes del clúster de Amazon EKS, actualice los nodos para utilizarlos con la misma versión de Kubernetes. **importante** En este tema, se explican las actualizaciones de los nodos autoadministrados. Si utiliza [grupos de nodos administrados](managed-node-groups.md), consulte [Actualización de un grupo de nodos administrados para un clúster](update-managed-node-group.md). Existen dos formas básicas de actualizar grupos de nodos autoadministrados en los clústeres para utilizar una nueva AMI: ** [Migre sus aplicaciones a un nuevo grupo de nodos](migrate-stack.md) ** Cree un nuevo grupo de nodos y migre los pods a ese grupo. La migración a un nuevo grupo de nodos es más sencilla que simplemente actualizar el ID de la AMI en una pila de AWS CloudFormation existente. Esto se debe a que el proceso de migración [marca](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) al antiguo grupo de nodos como `NoSchedule` y drena los nodos después de que una nueva pila esté lista para aceptar la carga de trabajo del pod existente. ** [Actualizar una pila de nodos de AWS CloudFormation](update-stack.md) ** Actualice la pila de AWS CloudFormation para que un grupo de nodos existente utilice la nueva AMI. Este método no es compatible con los grupos de nodos creados con `eksctl`. # Migración de aplicaciones a un nuevo grupo de nodos En este tema, se describe cómo crear un nuevo grupo de nodos, migrar de forma correcta las aplicaciones existentes al nuevo grupo y eliminar el antiguo grupo de nodos del clúster. Puede migrar a un nuevo grupo de nodos mediante `eksctl` o la Consola de administración de AWS. + [`eksctl`](#eksctl_migrate_apps) + [Consola de administración de AWS y AWS CLI](#console_migrate_apps) ## `eksctl` **Migre sus aplicaciones a un nuevo grupo de nodos con `eksctl` ** Para obtener más información sobre el uso de eksctl para la migración, consulte [Nodos no administrados](https://eksctl.io/usage/nodegroup-unmanaged/) en la documentación de `eksctl`. En este procedimiento, se requiere la versión `0.215.0` o posterior de `eksctl`. 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 funciona para los clústeres y grupos de nodos que se crearon con `eksctl`. 1. Recupere el nombre de los grupos de nodos existentes al sustituir *mi clúster* por el nombre del clúster. ``` eksctl get nodegroups --cluster=my-cluster ``` Un ejemplo de salida sería el siguiente. ``` CLUSTER NODEGROUP CREATED MIN SIZE MAX SIZE DESIRED CAPACITY INSTANCE TYPE IMAGE ID default standard-nodes 2019-05-01T22:26:58Z 1 4 3 t3.medium ami-05a71d034119ffc12 ``` 1. Lance un nuevo grupo de nodos con `eksctl` mediante el siguiente comando. En el comando, sustituya cada *valor de ejemplo* por sus valores propios. El número de versión no puede ser posterior a la versión de Kubernetes del plano de control. Además, no puede ser más de dos versiones secundarias anteriores a la versión de Kubernetes para el plano de control. Recomendamos que utilice la misma versión que el plano de control. 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). Si desea bloquear el acceso del pod a IMDS, agregue la opción `--disable-pod-imds` al siguiente comando. **nota** Para obtener más marcadores disponibles y sus descripciones, consulte https://eksctl.io/. ``` eksctl create nodegroup \ --cluster my-cluster \ --version 1.35 \ --name standard-nodes-new \ --node-type t3.medium \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --managed=false ``` 1. Cuando se complete el comando anterior, verifique con el siguiente comando que todos los nodos tengan el estado `Ready` (Listo): ``` kubectl get nodes ``` 1. Elimine el grupo de nodos original con el siguiente comando. En el comando, sustituya cada *valor de ejemplo* con los nombres del clúster y el grupo de nodos: ``` eksctl delete nodegroup --cluster my-cluster --name standard-nodes-old ``` ## Consola de administración de AWS y AWS CLI **Migre sus aplicaciones a un nuevo grupo de nodos con la Consola de administración de AWS y la AWS CLI** 1. Lance un nuevo grupo de nodos mediante los pasos que se indican en [Creación de nodos autoadministrados de Amazon Linux](launch-workers.md). 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 necesita para agregar los nuevos nodos de Amazon EKS al clúster. **nota** Si ha adjuntado políticas de IAM adicionales al rol de IAM del grupo de nodos anterior, debe adjuntar esas mismas políticas al rol de IAM del nuevo grupo de nodos para mantener esa funcionalidad en el nuevo grupo. Esto se aplica si ha agregado permisos para el [escalador automático del clúster](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) de Kubernetes, por ejemplo. 1. Actualice los grupos de seguridad de ambos grupos de nodos para que puedan comunicarse entre sí. Para obtener más información, consulte [Revisión de requisitos de grupos de seguridad de Amazon EKS para clústeres](sec-group-reqs.md). 1. Anote los ID de grupo de seguridad de ambos grupos de nodos. Esto se muestra como el valor **NodeSecurityGroup** en los resultados de la pila de AWS CloudFormation. Puede utilizar los siguientes comandos de la AWS CLI para obtener los ID de grupo de seguridad de los nombres de pilas. En estos comandos, `oldNodes` es el nombre de pila de AWS CloudFormation de la pila de nodos antigua y `newNodes` es el nombre de la pila a la que migrará. Reemplace todos los *valores de ejemplo* por sus propios valores. ``` oldNodes="old_node_CFN_stack_name" newNodes="new_node_CFN_stack_name" oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) ``` 1. Agregue reglas de entrada a cada grupo de seguridad de nodos para que acepten tráfico de los otros grupos. Los siguientes comandos de la AWS CLI agregan reglas de entrada a cada grupo de seguridad que permiten todo el tráfico en todos los protocolos del otro grupo de seguridad. Esta configuración permite que los pods de cada grupo de nodos se comuniquen entre ellos mientras migra la carga de trabajo al nuevo grupo. ``` aws ec2 authorize-security-group-ingress --group-id $oldSecGroup \ --source-group $newSecGroup --protocol -1 aws ec2 authorize-security-group-ingress --group-id $newSecGroup \ --source-group $oldSecGroup --protocol -1 ``` 1. Edite el mapa de configuración de `aws-auth` para asignar el rol de la instancia del nuevo nodo en RBAC. ``` kubectl edit configmap -n kube-system aws-auth ``` Agregue una nueva entrada `mapRoles` para el nuevo grupo de nodos. ``` apiVersion: v1 data: mapRoles: | - rolearn: ARN of instance role (not instance profile) username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes> - rolearn: arn:aws:iam::111122223333:role/nodes-1-16-NodeInstanceRole-U11V27W93CX5 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes ``` Sustituya el fragmento *ARN of instance role (not instance profile)* por el valor de **NodeInstanceRole** anotado en el [procedimiento anterior](#node-instance-role-step). A continuación, guarde y cierre el archivo para aplicar el configmap actualizado. 1. Examine el estado de los nodos y espere a que los nuevos nodos se unan al clúster y tengan el estado `Ready` (Listo). ``` kubectl get nodes --watch ``` 1. (Opcional) Si utiliza el [escalador automático del clúster de Kubernetes](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), escale la implementación a cero (0) réplicas para evitar acciones de escalado en conflicto. ``` kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system ``` 1. Utilice el siguiente comando para agregar taints en cada uno de los nodos que desee eliminar con `NoSchedule`. Esto es para que los nuevos pods no se programen ni se vuelvan a programar en los nodos que va a reemplazar. Para obtener más información, consulte [Taints y toleraciones](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) en la documentación de Kubernetes. ``` kubectl taint nodes node_name key=value:NoSchedule ``` Si va a actualizar los nodos a una nueva versión de Kubernetes, puede identificar todos los nodos de una determinada versión de Kubernetes (en este caso, `1.33`) y aplicarles una taint con el siguiente fragmento de código. El número de versión no puede ser posterior a la versión de Kubernetes del plano de control. Además, no puede ser más de dos versiones secundarias anteriores a la versión de Kubernetes del plano de control. Recomendamos que utilice la misma versión que el plano de control. ``` K8S_VERSION=1.33 nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}") for node in ${nodes[@]} do echo "Tainting $node" kubectl taint nodes $node key=value:NoSchedule done ``` 1. Identifique el proveedor de DNS del clúster. ``` kubectl get deployments -l k8s-app=kube-dns -n kube-system ``` Un ejemplo de salida sería el siguiente. Este clúster utiliza CoreDNS para la resolución de DNS, pero el clúster puede devolver `kube-dns` en su lugar: ``` NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE coredns 1 1 1 1 31m ``` 1. Si su implementación actual está ejecutando menos de dos réplicas, escale la implementación a dos réplicas. Cambie *coredns* por `kubedns` si el resultado del comando anterior ha devuelto ese valor. ``` kubectl scale deployments/coredns --replicas=2 -n kube-system ``` 1. Vacíe cada uno de los nodos que desea eliminar de su clúster con el siguiente comando: ``` kubectl drain node_name --ignore-daemonsets --delete-local-data ``` Si va a actualizar los nodos a una nueva versión de Kubernetes, identifique y drene todos los nodos de una determinada versión de Kubernetes (en este caso *1.33*) con el siguiente fragmento de código. ``` K8S_VERSION=1.33 nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}") for node in ${nodes[@]} do echo "Draining $node" kubectl drain $node --ignore-daemonsets --delete-local-data done ``` 1. Una vez que haya terminado de vaciar los nodos antiguos, revoque las reglas de entrada del grupo de seguridad que autorizó anteriormente. A continuación, elimine la pila de AWS CloudFormation para terminar las instancias. **nota** Si ha adjuntado políticas de IAM adicionales al rol de IAM del grupo de nodos anterior, como agregar permisos para el [escalador automático del clúster de Kubernetes](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), desconecte esas políticas adicionales del rol antes de eliminar la pila de AWS CloudFormation. 1. Revoque las reglas de entrada que creó anteriormente para los grupos de seguridad de nodos. En estos comandos, `oldNodes` es el nombre de pila de AWS CloudFormation de la pila de nodos antigua y `newNodes` es el nombre de la pila a la que migrará. ``` oldNodes="old_node_CFN_stack_name" newNodes="new_node_CFN_stack_name" oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) aws ec2 revoke-security-group-ingress --group-id $oldSecGroup \ --source-group $newSecGroup --protocol -1 aws ec2 revoke-security-group-ingress --group-id $newSecGroup \ --source-group $oldSecGroup --protocol -1 ``` 1. Abra la [AWS consola de CloudFormation](https://console.aws.amazon.com/cloudformation/). 1. Seleccione la pila de nodos antigua. 1. Elija **Eliminar**. 1. En el cuadro de diálogo de confirmación **Eliminar pila**, elija **Eliminar pila**. 1. Edite el mapa de configuración de `aws-auth` para eliminar el rol de la instancia del nodo anterior de RBAC. ``` kubectl edit configmap -n kube-system aws-auth ``` Elimine la entrada `mapRoles` del grupo de nodos antiguo. ``` apiVersion: v1 data: mapRoles: | - rolearn: arn:aws:iam::111122223333:role/nodes-1-16-NodeInstanceRole-W70725MZQFF8 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - rolearn: arn:aws:iam::111122223333:role/nodes-1-15-NodeInstanceRole-U11V27W93CX5 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes> ``` Guarde y cierre el archivo para aplicar el mapa de configuración actualizado. 1. (Opcional) Si utiliza el [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) de Kubernetes, vuelva a escalar la implementación a una réplica. **nota** También debe etiquetar el nuevo grupo de Auto Scaling de forma correcta (por ejemplo, `k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/my-cluster`) y actualizar el comando de implementación del escalador automático del clúster para que señale el grupo de Auto Scaling recién etiquetado. Para obtener más información, consulte [Escalador automático de clústeres en AWS](https://github.com/kubernetes/autoscaler/tree/cluster-autoscaler-release-1.3/cluster-autoscaler/cloudprovider/aws). ``` kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system ``` 1. (Opcional) Verifique que utiliza la última versión del [complemento CNI de Amazon VPC para Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s). 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). 1. Si el clúster utiliza `kube-dns` para la resolución DNS (consulte [[migrate-determine-dns-step]](#migrate-determine-dns-step)), reduzca horizontalmente la implementación de `kube-dns` a una réplica. ``` kubectl scale deployments/kube-dns --replicas=1 -n kube-system ``` # Actualización de una pila de nodos de AWS CloudFormation En este tema, se describe cómo puede actualizar una pila existente de nodos autoadministrados de AWS CloudFormation con una nueva AMI. Puede utilizar este procedimiento para actualizar los nodos a una nueva versión de Kubernetes después de la actualización de un clúster. De lo contrario, puede actualizar a la última AMI optimizada de Amazon EKS para una versión existente de Kubernetes. **importante** En este tema, se explican las actualizaciones de los nodos autoadministrados. Para obtener información sobre el uso de la [Simplificación del ciclo de vida de los nodos con grupos de nodos administrados](managed-node-groups.md), consulte [Actualización de un grupo de nodos administrados para un clúster](update-managed-node-group.md). La última plantilla de AWS CloudFormation de nodos de Amazon EKS predeterminada está configurada para lanzar una instancia con la nueva AMI en el clúster antes de eliminar una antigua, una por vez. Esta configuración garantiza que siempre tenga el número deseado de instancias activas del grupo de Auto Scaling en el clúster durante la actualización progresiva. **nota** Este método no es compatible con los grupos de nodos creados con `eksctl`. Si ha creado su clúster o un grupo de nodos con `eksctl`, consulte [Migración de aplicaciones a un nuevo grupo de nodos](migrate-stack.md). 1. Determine el proveedor de DNS para el clúster. ``` kubectl get deployments -l k8s-app=kube-dns -n kube-system ``` Un ejemplo de salida sería el siguiente. Este clúster utiliza CoreDNS para la resolución de DNS, pero el clúster puede devolver `kube-dns` en su lugar. El resultado puede tener un aspecto diferente según la versión de `kubectl` que utilice. ``` NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE coredns 1 1 1 1 31m ``` 1. Si su implementación actual está ejecutando menos de dos réplicas, escale la implementación a dos réplicas. Cambie *coredns* por `kube-dns` si el resultado del comando anterior ha devuelto ese valor. ``` kubectl scale deployments/coredns --replicas=2 -n kube-system ``` 1. (Opcional) Si utiliza el [escalador automático del clúster de Kubernetes](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md), escale la implementación a cero (0) réplicas para evitar acciones de escalado en conflicto. ``` kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system ``` 1. Determine el tipo de instancia y el número de instancias deseado del grupo de nodos actual. Ingrese estos valores más tarde cuando actualice la plantilla de AWS CloudFormation del grupo. 1. Abra la consola de Amazon EC2 en https://console.aws.amazon.com/ec2/. 1. En el panel de navegación izquierdo, elija **Configuraciones de lanzamiento** (Configuraciones de lanzamiento) y anote el tipo de instancia de la configuración de lanzamiento de nodos existente. 1. En el panel de navegación izquierdo, elija **Auto Scaling Groups** (Grupos de Auto Scaling) y anote el recuento de instancias **deseado** para el grupo de Auto Scaling de nodos existente. 1. Abra la [AWS consola de CloudFormation](https://console.aws.amazon.com/cloudformation/). 1. Seleccione la pila del grupo de nodos y, a continuación, seleccione **Update (Actualizar)**. 1. Seleccione **Replace current template (Reemplazar plantilla actual)** y seleccione **Amazon S3 URL**. 1. Para **URL de Amazon S3**, pegue la siguiente URL en el área de texto a fin de asegurarse de que utiliza la versión más reciente de la plantilla de AWS Cloud Formation de nodos. A continuación, elija **Siguiente**: ``` https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-12-23/amazon-eks-nodegroup.yaml ``` 1. En la página **Especificar detalles**, rellene los parámetros siguientes y seleccione **Siguiente**: + **NodeAutoScalingGroupDesiredCapacity**: ingrese el recuento de instancias deseado que registró en un [paso anterior](#existing-worker-settings-step). O bien, ingrese el nuevo número deseado de nodos para escalar cuando se actualice la pila. + **NodeAutoScalingGroupMaxSize**: ingrese el número máximo de nodos al que pueda llegar el grupo de Auto Scaling de nodos. Este valor debe ser al menos un nodo más que la capacidad deseada. Es para que pueda realizar una actualización continua de los nodos sin que se reduzca el número durante la actualización. + **NodeInstanceType**: elija el tipo de instancia que registró en un [paso anterior](#existing-worker-settings-step). Por otra parte, puede elegir un tipo de instancia diferente para los nodos. Antes de elegir un tipo de instancia diferente, vea [Elección de un tipo de instancia de nodo de Amazon EC2 óptimo](choosing-instance-type.md). Cada tipo de instancia de Amazon EC2 admite un número máximo de interfaces de redes elásticas (interfaz de red) y cada interfaz de red admite un número máximo de direcciones IP. Dado que a cada nodo de trabajo y pod se les asigna su propia dirección IP, es importante elegir un tipo de instancia que admita el número máximo de pods que desea ejecutar en cada nodo de Amazon EC2. Para obtener una lista del número de interfaces de red y direcciones IP admitidas por los tipos de instancias, consulte [Direcciones IP por interfaz de red por tipo de instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI). Por ejemplo, el tipo de instancia `m5.large` admite un máximo de 30 direcciones IP para el nodo de trabajo y los pods. **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 del complemento CNI de Amazon VPC para Kubernetes a fin de 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). **importante** Algunos tipos de instancias podrían no estar disponibles en todas las regiones de AWS. + **NodeImageIdSSMParam**: el parámetro de Amazon EC2 Systems Manager del ID de AMI al que desee actualizar. El siguiente valor utiliza la última AMI optimizada para Amazon EKS para la versión  de Kubernetes `1.35`. ``` /aws/service/eks/optimized-ami/1.35/amazon-linux-2/recommended/image_id ``` Puede reemplazar *1.35* por una [versión de la plataforma](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html) que sea igual. O bien, debería ser hasta una versión anterior a la versión de Kubernetes que se ejecuta en el plano de control. Le recomendamos que los nodos tengan la misma versión que el plano de control. También puede sustituir *amazon-linux-2* por un tipo de AMI diferente. Para obtener más información, consulte [Obtención de los ID de AMI de Amazon Linux recomendados](retrieve-ami-id.md). **nota** El uso del parámetro de Amazon EC2 Systems Manager lo habilita a actualizar los nodos en el futuro sin tener que buscar y especificar un ID de AMI. Si la pila de AWS CloudFormation utiliza este valor, cualquier actualización de la pila lanzará siempre la última AMI optimizada para Amazon EKS recomendada en función de la versión de Kubernetes especificada. Este es el caso incluso si no cambia ningún valor en la plantilla. + **NodeImageId**: para utilizar su propia AMI personalizada, introduzca el ID de la AMI que va a utilizar. **importante** Este valor anula cualquier valor especificado para **NodeImageIdSSMParam**. Si desea utilizar el valor **NodeImageIdSSMParam** asegúrese de que el valor de **NodeImageId** esté vacío. + **DisableIMDSv1**: cada nodo admite de forma predeterminada la versión 1 (IMDSv1) e IMDSv2 del servicio de metadatos de la instancia. Sin embargo, puede desactivar IMDSv1. Seleccione **verdadero** si no desea que ningún nodo o ningún pod programado en el grupo de nodos utilice IMDSv1. Para obtener más información, consulte [Configuración del servicio de metadatos de instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html). Si ha implementado roles de IAM para cuentas de servicio, asigne los permisos necesarios de forma directa a todos los pods que requieren acceso a servicios de AWS. De esta manera, ningún pod del clúster requiere el acceso a IMDS por otros motivos, como la recuperación de la región de AWS actual. A continuación, también puede deshabilitar el acceso a IMDSv2 para los pods que no utilizan redes de host. 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). 1. (Opcional) En la página **Options (Opciones)**, marque los recursos de la pila. Elija **Siguiente**. 1. En la página **Review** (Revisar), revise la información, confirme la advertencia de que la pila puede crear recursos de IAM y elija **Update stack** (Actualizar pila). **nota** La actualización de cada nodo del clúster tarda varios minutos. Espere a que se complete la actualización de todos los nodos antes de realizar los siguientes pasos. 1. Si su proveedor DNS del clúster es `kube-dns`, reduzca horizontalmente la implementación de `kube-dns` a una réplica. ``` kubectl scale deployments/kube-dns --replicas=1 -n kube-system ``` 1. (Opcional) Si utiliza el [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) de Kubernetes, vuelva a escalar la implementación a la cantidad de réplicas deseada. ``` kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system ``` 1. (Opcional) Verifique que utiliza la última versión del [complemento CNI de Amazon VPC para Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s). Es posible que tenga que actualizar la versión del complemento CNI de Amazon VPC para Kubernetes a fin de 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).