**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.

# Simplificación del ciclo de vida de los nodos con grupos de nodos administrados
<a name="managed-node-groups"></a>

Los grupos de nodos administrados por Amazon EKS automatizan el aprovisionamiento y la gestión del ciclo de vida de nodos (instancias de Amazon EC2) para clústeres de Kubernetes de Amazon EKS.

Con los grupos de nodos administrados por Amazon EKS, no es necesario aprovisionar o registrar por separado las instancias de Amazon EC2 que proporcionan capacidad informática para ejecutar sus aplicaciones de Kubernetes. Puede crear, actualizar o terminar nodos para el clúster con una sola operación y de manera automática. Las actualizaciones y terminaciones de nodos drenan de forma automática los nodos para garantizar que sus aplicaciones permanezcan disponibles.

Todos los nodos administrados se aprovisionan como parte de un grupo de Amazon EC2 Auto Scaling administrado por usted a través de Amazon EKS. Todos los recursos, incluidas las instancias y los grupos de Auto Scaling, se ejecutan dentro de su cuenta de AWS. Cada grupo de nodos puede ejecutarse en varias zonas de disponibilidad que defina.

Los grupos de nodos administrados también pueden aprovechar opcionalmente la reparación automática de nodos, que supervisa continuamente el estado de los nodos. Reacciona automáticamente ante los problemas detectados y reemplaza los nodos cuando es posible. Esto contribuye a mantener la disponibilidad general del clúster con una intervención manual mínima. Para obtener más información, consulte [Detección de los problemas de estado de los nodos y reparación automática de los nodos](node-health.md).

Puede agregar un grupo de nodos administrado a clústeres nuevos o existentes mediante la consola de Amazon EKS, `eksctl`, AWS CLI, la API de AWS o herramientas de infraestructura como código que incluyen AWS CloudFormation. Los nodos lanzados como parte de un grupo de nodos administrado se etiquetan automáticamente para la detección automática por el [Escalador automático de clústeres](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) de Kubernetes. Puede utilizar el grupo de nodos para aplicar etiquetas de Kubernetes a los nodos y actualizarlos en cualquier momento.

No incurre en costos adicionales por usar grupos de nodos administrados por Amazon EKS, solo paga por los recursos de AWS que aprovisione. Estos incluyen instancias de Amazon EC2, volúmenes de Amazon EBS, horas de clúster de Amazon EKS y cualquier otra infraestructura de AWS. No se requieren pagos mínimos ni compromisos iniciales.

Para comenzar a utilizar un grupo de nodos administrado y un clúster de Amazon EKS nuevos, consulte [Introducción a Amazon EKS: Consola de administración de AWS y AWS CLI](getting-started-console.md).

Para agregar un grupo de nodos administrados a un clúster existente, consulte [Creación de un grupo de nodos administrados para un clúster](create-managed-node-group.md).

## Conceptos de grupos de nodos administrados
<a name="managed-node-group-concepts"></a>
+ Los grupos de nodos administrados por Amazon EKS crean y administran instancias de Amazon EC2 para usted.
+ Todos los nodos administrados se aprovisionan como parte de un grupo de Amazon EC2 Auto Scaling administrado por usted a través de Amazon EKS. Además, todos los recursos, incluidas las instancias de Amazon EC2 y los grupos de Auto Scaling, se ejecutan dentro de su cuenta de AWS.
+ El grupo de Auto Scaling de un grupo de nodos administrados abarca todas las subredes que especifique al crear el grupo.
+ Las etiquetas de Amazon EKS administran recursos de grupo de nodos para que estén configurados para usar el [Escalador automático de clústeres](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) de Kubernetes.
**importante**  
Si ejecuta una aplicación con estado en varias zonas de disponibilidad basadas en volúmenes de Amazon EBS y utiliza el [Escalador automático de clústeres](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) de Kubernetes, debe configurar varios grupos de nodos, cada uno enfocado a una sola zona de disponibilidad. Además, debe habilitar la característica `--balance-similar-node-groups`.
+ Puede utilizar una plantilla de lanzamiento personalizada para obtener un mayor nivel de flexibilidad y personalización al implementar nodos administrados. Por ejemplo, puede especificar argumentos `kubelet` adicionales y utilizar una AMI personalizada. Para obtener más información, consulte [Personalización de nodos administrados con plantillas de lanzamiento](launch-templates.md). Si no usa una plantilla de lanzamiento personalizada al crear un grupo de nodos administrados, hay una plantilla de lanzamiento generada automáticamente. No modifique manualmente esta plantilla generada automáticamente o se producirán errores.
+ Amazon EKS sigue el modelo de responsabilidad compartida para CVE y los parches de seguridad en grupos de nodos administrados. Cuando los nodos administrados ejecutan una AMI optimizada para Amazon EKS, Amazon EKS es responsable de crear versiones con parches de la AMI cuando se informa de errores o problemas. Podemos publicar una solución. Sin embargo, es responsable de implementar estas versiones de AMI con parches en los grupos de nodos administrados. Cuando los nodos administrados ejecutan una AMI personalizada, es responsable de crear versiones con parches de la AMI cuando se informa de errores o problemas y, a continuación, implementar la AMI. Para obtener más información, consulte [Actualización de un grupo de nodos administrados para un clúster](update-managed-node-group.md).
+ Los grupos de nodos administrados por Amazon EKS se pueden lanzar tanto en subredes públicas como privadas. Si lanza un grupo de nodos administrado en una subred pública el 22 de abril de 2020 o después, la subred debe tener la opción `MapPublicIpOnLaunch` establecida en verdadero para que las instancias puedan unirse a un clúster correctamente. Si la subred pública se creó con `eksctl` o [las plantillas de AWS CloudFormation ofrecidas por Amazon EKS](creating-a-vpc.md) el 26 de marzo de 2020 o después, esta configuración ya está establecida en verdadero. Si las subredes públicas se crearon antes del 26 de marzo de 2020, debe cambiar el valor de forma manual. Para obtener más información, 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).
+ Al implementar un grupo de nodos administrado en subredes privadas, debe asegurarse de que pueda acceder a Amazon ECR para extraer imágenes de contenedores. Para ello, conecte una puerta de enlace de NAT a la tabla de enrutamiento de la subred o agregue los siguientes [puntos de conexión de VPC de AWS PrivateLink](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html#ecr-setting-up-vpc-create):
  + Interfaz de punto de conexión de la API de Amazon ECR: `com.amazonaws.region-code.ecr.api` 
  + Interfaz de punto de conexión de la API de registro de Docker de Amazon ECR: `com.amazonaws.region-code.ecr.dkr` 
  + Punto de conexión de puerta de enlace de Amazon S3: – `com.amazonaws.region-code.s3` 

  Para ver otros servicios y puntos de conexión de uso común, consulte [Implementación de clústeres privados con acceso limitado a Internet](private-clusters.md).
+ Los grupos de nodos administrados no se pueden implementar en [AWS Outposts](eks-outposts.md) ni en [AWS Wavelength](https://docs.aws.amazon.com/wavelength/). Los grupos de nodos administrados se pueden crear en [zonas locales de AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/). Para obtener más información, consulte [Lanzamiento de clústeres EKS de baja latencia con zonas locales de AWS](local-zones.md).
+ Puede crear varios grupos de nodos administrados dentro de un único clúster. Por ejemplo, puede crear un grupo de nodos con la AMI optimizada de Amazon Linux para Amazon EKS estándar para algunas cargas de trabajo y otro con la variante de GPU para las cargas de trabajo que requieren compatibilidad con GPU.
+ Si el grupo de nodos administrado encuentra un error de [comprobación de estado de instancia de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html), Amazon EKS devuelve un código de error para ayudarlo a diagnosticar el problema. Para obtener más información, consulte [Códigos de error del grupo de nodos administrado](troubleshooting.md#troubleshoot-managed-node-groups).
+ Amazon EKS agrega etiquetas de Kubernetes a instancias de grupos de nodos administrados. Estas etiquetas proporcionadas por Amazon EKS tienen el prefijo `eks.amazonaws.com`.
+ Amazon EKS drena nodos automáticamente a través de la API de Kubernetes durante las terminaciones o actualizaciones.
+ Los presupuestos de interrupción del pod no se respetan al terminar un nodo con `AZRebalance` o al reducir el número de nodos deseado. Estas acciones intentan expulsar los pods en el nodo. Sin embargo, si estas acciones tardan más de 15 minutos, el nodo se termina independientemente de si todos los pods del nodo están terminados. Para ampliar el período hasta que finalice el nodo, agregue un enlace de ciclo de vida al grupo de escalado automático. Para obtener más información, consulte [Agregar enlaces de enlace de ciclo de vida](https://docs.aws.amazon.com/autoscaling/ec2/userguide/adding-lifecycle-hooks.html) en la *guía de hombre del usuario de Amazon EC2 Auto Scaling*.
+ Para ejecutar el proceso de drenaje correctamente después de recibir una notificación de interrupción puntual o una notificación de reequilibrio de capacidad, `CapacityRebalance` debe configurarse en `true`.
+ La actualización de los grupos de nodos administrados respeta los presupuestos de interrupción de pods que ha establecido para sus pods. Para obtener más información, consulte [Descripción de cada fase de las actualizaciones de los nodos](managed-node-update-behavior.md).
+ No incurre en costos adicionales por usar grupos de nodos administrados de Amazon EKS. Solo pagará por los recursos de AWS que aprovisione.
+ Si desea cifrar volúmenes de Amazon EBS para sus nodos, puede implementarlos mediante una plantilla de lanzamiento. Para implementar nodos administrados con volúmenes cifrados de Amazon EBS sin utilizar una plantilla de lanzamiento, cifre todos los nuevos volúmenes de Amazon EBS creados en su cuenta. Para obtener más información, consulte [Cifrado de forma predeterminada](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#encryption-by-default) en la *Guía del usuario de Amazon EC2*.

## Tipos de capacidad de grupo de nodos administrado
<a name="managed-node-group-capacity-types"></a>

Al crear un grupo de nodos administrado, puede elegir el tipo de capacidad bajo demanda o Spot. Amazon EKS implementa un grupo de nodos administrado con un grupo de Amazon EC2 Auto Scaling que solo contiene instancias de spot bajo demanda o solo instancias de spot de Amazon EC2. Puede programar pods para aplicaciones con tolerancia a errores en grupos de nodos administrados de spot y aplicaciones intolerantes a errores a grupos de nodos bajo demanda dentro de un único clúster de Kubernetes. De forma predeterminada, un grupo de nodos administrado implementa instancias de Amazon EC2 bajo demanda.

### Bajo demanda
<a name="managed-node-group-capacity-types-on-demand"></a>

Con instancias bajo demanda, paga la capacidad informática por segundo, sin compromisos a largo plazo.

De forma predeterminada, si no especifica un **Tipo de capacidad**, el grupo de nodos administrado se aprovisionará con instancias bajo demanda. En su nombre, un grupo de nodos administrado configura un grupo de Amazon EC2 Auto Scaling con la siguiente configuración aplicada:
+ La estrategia de asignación para aprovisionar capacidad bajo demanda se establece en `prioritized`. El grupo de nodos administrado utiliza el orden de los tipos de instancia de la API para determinar qué tipo de instancia se utilizará en primer lugar al cumplir con la capacidad bajo demanda. Por ejemplo, puede especificar tres tipos de instancias en el siguiente orden: `c5.large`, `c4.large` y `c3.large`. Cuando se lanzan las instancias bajo demanda, el grupo de nodos administrado satisface la capacidad bajo demanda, primero en `c5.large`, luego en `c4.large` y luego en `c3.large`. Para obtener más información, consulte [Grupo de Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-purchase-options.html#asg-allocation-strategies) en la *Guía del usuario de Amazon EC2 Auto Scaling*.
+ Amazon EKS agrega la siguiente etiqueta de Kubernetes a todos los nodos del grupo de nodos administrado que especifica el tipo de capacidad: `eks.amazonaws.com/capacityType: ON_DEMAND`. Puede utilizar esta etiqueta para programar aplicaciones con estado o intolerantes a errores en nodos bajo demanda.

### Spot
<a name="managed-node-group-capacity-types-spot"></a>

Las instancias de spot de Amazon EC2 son una capacidad de Amazon EC2 de reemplazo que ofrece grandes descuentos con respecto a los precios bajo demanda. Las instancias de spot de Amazon EC2 se pueden interrumpir con una notificación previa de dos minutos cuando EC2 necesita recuperar la capacidad. Para obtener más información, consulte [Instancias de spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) en *Guía del usuario de Amazon EC2*. Puede configurar un grupo de nodos administrado con instancias de spot de Amazon EC2 para optimizar los costos de los nodos informáticos que se ejecutan en su clúster de Amazon EKS.

Para utilizar instancias de spot dentro de un grupo de nodos administrados, cree uno y establezca el tipo de capacidad como `spot`. Un grupo de nodos administrado configura un grupo de Amazon EC2 Auto Scaling en su nombre con las siguientes prácticas recomendadas de spot aplicadas:
+ Para garantizar que los nodos de spot se aprovisionen en los grupos de capacidad de spot óptima, la estrategia de asignación se establece en una de las siguientes:
  +  `price-capacity-optimized` (PCO): Al crear nuevos grupos de nodos en un clúster con la versión de Kubernetes `1.28` o una versión posterior, la estrategia de asignación se establece en `price-capacity-optimized`. Sin embargo, la estrategia de asignación no cambiará para los grupos de nodos ya creados con `capacity-optimized` antes de que los grupos de nodos administrados por Amazon EKS comenzaran a admitir PCO.
  +  `capacity-optimized` (CO): Al crear nuevos grupos de nodos en un clúster con la versión de Kubernetes `1.27` o una versión anterior, la estrategia de asignación se establece en `capacity-optimized`.

  Para aumentar el número de grupos de capacidad de spot disponibles a fin de asignar su capacidad, configure un grupo de nodos administrados para utilizar varios tipos de instancias.
+ El reequilibrio de capacidad de spot de Amazon EC2 está habilitado para que Amazon EKS pueda drenar y reequilibrar los nodos de spot de forma sencilla para minimizar la interrupción de la aplicación cuando un nodo de spot corre un riesgo elevado de interrupción. Para obtener más información, consulte [Reequilibrio de capacidad de Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/capacity-rebalance.html) en la *Guía del usuario de Amazon EC2 Auto Scaling*.
  + Cuando un nodo de Spot recibe una recomendación de reequilibrio, Amazon EKS automáticamente intenta lanzar un nuevo nodo de Spot de reemplazo.
  + Si llega un aviso de interrupción de spot de dos minutos antes de que el nodo de spot de reemplazo se encuentre en estado `Ready`, Amazon EKS comienza a vaciar el nodo de spot que recibió la recomendación de reequilibrio. Amazon EKS drena el nodo haciendo todo lo posible. En consecuencia, no hay garantía de que Amazon EKS espere a que el nodo de reemplazo se una al clúster antes de agotar el nodo existente.
  + Cuando se inicia un nodo spot de reemplazo con el estado `Ready` en Kubernetes, Amazon EKS acordona y drena el nodo de spot que recibió la recomendación de reequilibrio. El acordonamiento del nodo de spot garantiza que el controlador de servicio no envíe nuevas solicitudes a este nodo de spot. También lo elimina de su lista de nodos de spot activos y en buen estado. Drenar el nodo de spot garantiza que los pods en funcionamiento se expulsen de manera sencilla.
+ Amazon EKS agrega la siguiente etiqueta de Kubernetes a todos los nodos del grupo de nodos administrado que especifica el tipo de capacidad: `eks.amazonaws.com/capacityType: SPOT`. Puede utilizar esta etiqueta para programar aplicaciones con tolerancia a errores en nodos de spot.
**importante**  
EC2 emite un [aviso de interrupción de spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html) dos minutos antes de terminar la instancia de spot. Sin embargo, es posible que los pods de nodos de spot no reciban el plazo completo de dos minutos para que se terminen sin problemas. Cuando EC2 emite el aviso, se produce un retraso antes de que Amazon EKS comience a expulsar los pods. Las expulsiones se producen de forma secuencial para proteger el servidor de la API de Kubernetes, por lo que, durante varias recuperaciones simultáneas de spot, algunos pods pueden recibir avisos de expulsión con demora. Los pods se pueden terminar por la fuerza sin recibir señales de terminación, especialmente en los nodos con una alta densidad de pods, durante las recuperaciones simultáneas o cuando se utilizan periodos de gracia de terminación prolongados. Para las cargas de trabajo de spot, recomendamos diseñar las aplicaciones para que sean tolerantes a las interrupciones, utilizar periodos de gracia de terminación de 30 segundos o menos, evitar los enlaces preStop de larga duración y supervisar las métricas de expulsión de pods para comprender los periodos de gracia reales de los clústeres. En el caso de las cargas de trabajo que requieren una terminación correcta y garantizada, recomendamos utilizar la capacidad bajo demanda como alternativa.

Al decidir si desea implementar un grupo de nodos con capacidad bajo demanda o de spot, debe tener en cuenta las siguientes condiciones:
+ Las instancias de spot son una buena opción para aplicaciones sin estado, tolerantes a errores y flexibles. Estos incluyen cargas de trabajo de formación de machine learning y por lotes, ETL de big data como Apache Spark, aplicaciones de procesamiento de colas y puntos de conexión de API sin estado. Dado que spot es capacidad de Amazon EC2 de reemplazo y puede cambiar con el tiempo, le recomendamos que utilice la capacidad de spot para cargas de trabajo tolerantes a interrupciones. Más concretamente, la capacidad de spot es adecuada para cargas de trabajo que pueden tolerar periodos en los que la capacidad requerida no está disponible.
+ Recomendamos que utilice la opción bajo demanda para aplicaciones intolerantes a errores. Esto incluye herramientas de administración de clústeres como herramientas operativas y de supervisión, implementaciones que requieren `StatefulSets` y aplicaciones con estado, como bases de datos.
+ Para maximizar la disponibilidad de las aplicaciones mientras se utilizan instancias de spot, se recomienda configurar un grupo de nodos administrado de spot para que utilice varios tipos de instancias. Se recomienda aplicar las siguientes reglas al utilizar varios tipos de instancias:
  + Dentro de un grupo de nodos administrado, si está utilizando el [escalador automático de clústeres](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md), se recomienda utilizar un conjunto flexible de tipos de instancias con la misma cantidad de vCPU y recursos de memoria. Esto es para garantizar que los nodos del clúster se escalen según lo esperado. Por ejemplo, si necesita cuatro vCPU y 8 GiB de memoria, utilice `c3.xlarge`, `c4.xlarge`, `c5.xlarge`, `c5d.xlarge`, `c5a.xlarge`, `c5n.xlarge` u otros tipos de instancias similares.
  + Para mejorar la disponibilidad de las aplicaciones, recomendamos implementar varios grupos de nodos administrados por spot. Para ello, cada grupo debe utilizar un conjunto flexible de tipos de instancias que tengan los mismos recursos de memoria y vCPU. Por ejemplo, si necesita 4 vCPU y 8 GiB de memoria, le recomendamos que cree un grupo de nodos administrado con `c3.xlarge`, `c4.xlarge`, `c5.xlarge`, `c5d.xlarge`, `c5a.xlarge`, `c5n.xlarge` u otros tipos de instancias similares, y un segundo grupo de nodos administrado con `m3.xlarge`, `m4.xlarge`, `m5.xlarge`, `m5d.xlarge`, `m5a.xlarge`, `m5n.xlarge` u otros tipos de instancias similares.
  + Al implementar el grupo de nodos con el tipo de capacidad spot que utiliza una plantilla de lanzamiento personalizada, utilice la API para pasar varios tipos de instancia. No pase ni un solo tipo de instancia a través de la plantilla de lanzamiento. Para obtener más información sobre cómo implementar un grupo de nodos con una plantilla de lanzamiento, consulte [Personalización de nodos administrados con plantillas de lanzamiento](launch-templates.md).

# Creación de un grupo de nodos administrados para un clúster
<a name="create-managed-node-group"></a>

En este tema, se describe cómo puede lanzar grupos de nodos administrados de Amazon EKS que se registra en el clúster de Amazon EKS. Una vez que los nodos se hayan unido al clúster, puede implementar aplicaciones de Kubernetes en ellos.

Si es la primera vez que lanza un grupo de nodos administrado de Amazon EKS, le recomendamos que siga una de nuestras guías en [Introducción a Amazon EKS](getting-started.md) en su lugar. Estas guías proporcionan explicaciones para crear un clúster de Amazon EKS con nodos.

**importante**  
Los nodos de Amazon EKS son instancias estándar de Amazon EC2. Se le facturará en función de los precios normales de Amazon EC2. Para obtener más información, consulte [Precios de Amazon EC2](https://aws.amazon.com/ec2/pricing/).
No puede crear nodos administrados en una región de AWS en la que tenga habilitado AWS Outposts o AWS Wavelength. Puede crear nodos autoadministrados en su lugar. Para obtener más información, consulte [Creación de nodos autoadministrados de Amazon Linux](launch-workers.md), [Creación de nodos autoadministrados de Microsoft Windows](launch-windows-workers.md) y [Creación de nodos de Bottlerocket autoadministrados](launch-node-bottlerocket.md). También puede crear un grupo de nodos autoadministrados de Amazon Linux en un Outpost. Para obtener más información, consulte [Creación de nodos de Amazon Linux en AWS Outposts](eks-outposts-self-managed-nodes.md).
Si no [especifica un ID de AMI](launch-templates.md#launch-template-custom-ami) para el archivo `bootstrap.sh` incluido en Amazon EKS optimizado para Linux o Bottlerocket, los grupos de nodos administrados imponen un número máximo al valor de `maxPods`. Para las instancias con menos de 30 vCPU, el número máximo es `110`. Para las instancias con más de 30 vCPU, el número máximo aumenta a `250`. Esta aplicación obligatoria tiene precedencia sobre otras configuraciones de `maxPods`, incluida `maxPodsExpression`. Para obtener más información sobre cómo `maxPods` se determina y cómo personalizarlo, consulte [Cómo se determina maxPods](choosing-instance-type.md#max-pods-precedence).
+ Un clúster existente de Amazon EKS. Para implementar uno, consulte [Creación de un clúster de Amazon EKS](create-cluster.md).
+ 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.
+ Para agregar un grupo de nodos administrado de Windows, primero debe habilitar la compatibilidad con Windows de su clúster. Para obtener más información, consulte [Implementación de nodos de Windows en clústeres de EKS](windows-support.md).

Puede crear un grupo de nodos administrados con cualquiera de las siguientes opciones:
+  [`eksctl`](#eksctl_create_managed_nodegroup) 
+  [Consola de administración de AWS](#console_create_managed_nodegroup) 

## `eksctl`
<a name="eksctl_create_managed_nodegroup"></a>

 **Crear un grupo de nodos administrados con 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`.

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. Cree un grupo de nodos administrados con una plantilla de lanzamiento personalizada o sin ella. La especificación manual de una plantilla de lanzamiento permite una mayor personalización de un grupo de nodos. Por ejemplo, puede permitir implementar una AMI personalizada o proporcionar argumentos al script `boostrap.sh` en una AMI optimizada para Amazon EKS. Para obtener una lista completa de todas las opciones y valores predeterminados disponibles, ingrese el siguiente comando.

   ```
   eksctl create nodegroup --help
   ```

   En el siguiente comando, reemplace *my-cluster* por el nombre del clúster y *my-mng* por el nombre del 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.
**importante**  
Si no utiliza una plantilla de lanzamiento personalizada cuando crea un grupo de nodos administrados, evite utilizarla más adelante para ese mismo grupo. Si no especificó una plantilla de lanzamiento personalizada, el sistema genera automáticamente una plantilla de lanzamiento que no recomendamos que modifique manualmente. Si se modifica manualmente esta plantilla de lanzamiento generada automáticamente, se podrían producir errores.

 **Sin una plantilla de lanzamiento** 

 `eksctl` crea una plantilla de lanzamiento predeterminada de Amazon EC2 en su cuenta e implementa el grupo de nodos mediante una plantilla de lanzamiento que crea en función de las opciones que especifique. Antes de especificar un valor para `--node-type`, consulte [Elección de un tipo de instancia de nodo de Amazon EC2 óptimo](choosing-instance-type.md).

Reemplace *ami-family* por una palabra clave permitida. Para obtener más información, consulte [Configuración de la familia AMI del nodo](https://eksctl.io/usage/custom-ami-support/#setting-the-node-ami-family) en la documentación de `eksctl`. 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.

**nota**  
Para Windows, este comando no habilita SSH. En su lugar, asocia el par de claves de Amazon EC2 con la instancia y le permite RDP en la instancia.

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 información sobre Linux, consulte [Pares de claves e instancias de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) para Linux en la *Guía del usuario de Amazon EC2*. Para obtener información sobre Windows, consulte [Pares de claves e instancias de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html) para Windows en la *Guía del usuario de Amazon EC2*.

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).

Para bloquear el acceso del pod a IMDS, agregue la opción `--disable-pod-imds` al siguiente comando.

```
eksctl create nodegroup \
  --cluster my-cluster \
  --region region-code \
  --name my-mng \
  --node-ami-family ami-family \
  --node-type m5.large \
  --nodes 3 \
  --nodes-min 2 \
  --nodes-max 4 \
  --ssh-access \
  --ssh-public-key my-key
```

Las instancias pueden asignar de manera opcional un número significativamente mayor de direcciones IP a los pods, asignar direcciones IP a los pods de un bloque de CIDR diferente al de la instancia e implementar en un clúster sin acceso a Internet. Para obtener más información, consulte [Asignación de más direcciones IP a los nodos de Amazon EKS con prefijos](cni-increase-ip-addresses.md), [Implementación de pods en subredes alternativas con redes personalizadas](cni-custom-network.md) y [Implementación de clústeres privados con acceso limitado a Internet](private-clusters.md) para obtener opciones adicionales que se pueden agregar al comando anterior.

Los grupos de nodos administrados calculan y aplican un único valor para el número máximo de pods que se pueden ejecutar en cada nodo del grupo de nodos, según el tipo de instancia. Si crea un grupo de nodos con distintos tipos de instancias, el valor más pequeño calculado en todos los tipos de instancias se aplica como el número máximo de pods que se pueden ejecutar en cada tipo de instancia del grupo de nodos. Los grupos de nodos administrados calculan el valor mediante el script al que se hace referencia en el .

 **Con una plantilla de lanzamiento** 

La plantilla de lanzamiento ya debe existir y cumplir con los requisitos especificados en [Conceptos básicos de configuración de plantillas de lanzamiento](launch-templates.md#launch-template-basics). 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 de pod a IMDS, especifique la configuración necesaria en la plantilla de lanzamiento.

1. Copie los siguientes contenidos en su dispositivo. Sustituya los valores de ejemplo y, a continuación, ejecute el comando modificado para crear el archivo `eks-nodegroup.yaml`. Varias configuraciones que especifique al implementar sin una plantilla de lanzamiento se mueven a la plantilla de lanzamiento. Si no especifica una `version`, se utiliza la versión de plantilla predeterminada.

   ```
   cat >eks-nodegroup.yaml <<EOF
   apiVersion: eksctl.io/v1alpha5
   kind: ClusterConfig
   metadata:
     name: my-cluster
     region: region-code
   managedNodeGroups:
   - name: my-mng
     launchTemplate:
       id: lt-id
       version: "1"
   EOF
   ```

   Para obtener una lista completa de configuraciones de archivo de config de `eksctl`, consulte [Esquema de archivo de Config](https://eksctl.io/usage/schema/) en la documentación de `eksctl`. Las instancias pueden asignar de manera opcional un número significativamente mayor de direcciones IP a los pods, asignar direcciones IP a los pods de un bloque de CIDR diferente al de la instancia e implementar en un clúster sin acceso de salida a Internet. Para obtener más información, consulte [Asignación de más direcciones IP a los nodos de Amazon EKS con prefijos](cni-increase-ip-addresses.md), [Implementación de pods en subredes alternativas con redes personalizadas](cni-custom-network.md) y [Implementación de clústeres privados con acceso limitado a Internet](private-clusters.md) para obtener opciones adicionales que se pueden agregar al archivo de configuración.

   Si no especificó ningún ID de AMI en la plantilla de lanzamiento, los grupos de nodos administrados calculan y aplican un único valor para el número máximo de pods que se pueden ejecutar en cada nodo del grupo de nodos, según el tipo de instancia. Si crea un grupo de nodos con distintos tipos de instancias, el valor más pequeño calculado en todos los tipos de instancias se aplica como el número máximo de pods que se pueden ejecutar en cada tipo de instancia del grupo de nodos. Los grupos de nodos administrados calculan el valor mediante el script al que se hace referencia en el .

   Si especificó un ID de AMI en la plantilla de lanzamiento, debe especificar el número máximo de pods que se pueden ejecutar en cada nodo del grupo de nodos si usa [redes personalizadas](cni-custom-network.md) o quiere [aumentar el número de direcciones IP asignadas a la instancia](cni-increase-ip-addresses.md). Para obtener más información, consulte .

1. Implemente el grupo de nodos con el siguiente comando.

   ```
   eksctl create nodegroup --config-file eks-nodegroup.yaml
   ```

## Consola de administración de AWS
<a name="console_create_managed_nodegroup"></a>

 **Crear un grupo de nodos administrados con la Consola de administración de AWS ** 

1. Espere a que el estado del clúster sea `ACTIVE`. No se puede crear un grupo de nodos administrados para un clúster que aún no está `ACTIVE`.

1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).

1. Elija el nombre del clúster en el que desea crear un grupo de nodos administrados.

1. En la pestaña **Informática**.

1. Elija **Agregar grupo de nodos**.

1. En la página **Configurar grupo de nodos** rellene los parámetros en consecuencia y, a continuación, elija **Siguiente**.
   +  **Nombre**: Ingrese un nombre único para el grupo de nodos administrado. 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.
   +  **Rol de IAM de nodos**: Elija el rol de instancia de nodo que se va a utilizar con su grupo de nodos. Para obtener más información, consulte [Rol de IAM de nodo de Amazon EKS](create-node-role.md).
**importante**  
No se puede utilizar el mismo rol que se utiliza para crear clústeres.
Es recomendable utilizar un rol que no se esté utilizando actualmente en ningún grupo de nodos autoadministrados. De lo contrario, se utiliza en un nuevo grupo de nodos autoadministrados. Para obtener más información, consulte [Eliminación de un grupo de nodos administrado de un clúster](delete-managed-node-group.md).
   +  **Utilizar la plantilla de lanzamiento**: (opcional) seleccione esta opción si desea utilizar una plantilla de lanzamiento existente. Seleccione un **Nombre de plantilla de lanzamiento**. A continuación, seleccione **Versión de plantilla de lanzamiento**. Si no selecciona una versión, Amazon EKS utiliza la versión predeterminada de la plantilla. Las plantillas de lanzamiento permiten una mayor personalización del grupo de nodos, como permitir implementar una AMI personalizada, asignar un número significativamente mayor de direcciones IP a los pods, asignar direcciones IP a los pods de un bloque de CIDR diferente al de la instancia e implementar nodos en un clúster sin acceso a Internet saliente. Para obtener más información, consulte [Asignación de más direcciones IP a los nodos de Amazon EKS con prefijos](cni-increase-ip-addresses.md), [Implementación de pods en subredes alternativas con redes personalizadas](cni-custom-network.md) y [Implementación de clústeres privados con acceso limitado a Internet](private-clusters.md).

     La plantilla de lanzamiento debe cumplir los requisitos de [Personalización de nodos administrados con plantillas de lanzamiento](launch-templates.md). Si no utiliza su propia plantilla de lanzamiento, la API de Amazon EKS crea una plantilla de lanzamiento predeterminada de Amazon EC2 en su cuenta e implementa el grupo de nodos utilizando la plantilla de lanzamiento predeterminada.

     Si implementa [roles de IAM para cuentas de servicio](iam-roles-for-service-accounts.md), asigne los permisos necesarios directamente a todos los pods que requieren acceso a servicios de AWS y ningún pod del clúster requiere acceso a IMDS por otros motivos (como recuperar la región de AWS actual). También puede desactivar el acceso a IMDS para los pods que no utilizan redes de host en una plantilla de lanzamiento. 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).
   +  **Etiquetas de Kubernetes**: (Opcional) puede optar por aplicar etiquetas de Kubernetes a los nodos del grupo de nodos administrado.
   +  **Taints de Kubernetes**: (opcional) puede optar por aplicar taints de Kubernetes a los nodos de su grupo de nodos administrados. Las opciones disponibles en el menú **Efecto** son ` NoSchedule `, ` NoExecute ` y ` PreferNoSchedule `. Para obtener más información, consulte [Receta: Limitación para que los pods no se programen en nodos específicos](node-taints-managed-node-groups.md).
   +  **Etiquetas**: (Opcional) puede elegir etiquetar su grupo de nodos administrado de Amazon EKS. Estas etiquetas no se propagan a otros recursos del grupo de nodos, como instancias o grupos de escalado automático. Para obtener más información, consulte [Organización de los recursos de Amazon EKS con etiquetas](eks-using-tags.md).

1. En la página **Establecer configuración de informática y escalado**, rellene los parámetros según corresponda y, a continuación, elija **Siguiente**.
   +  **Tipo de AMI**: seleccione un tipo de AMI. Si implementa instancias Arm, asegúrese de revisar las consideraciones que se indican en [AMI de Arm de Amazon Linux optimizadas para Amazon EKS](eks-optimized-ami.md#arm-ami) antes de la implementación.

     Si especificó una plantilla de lanzamiento en la página anterior y especificó una AMI en la plantilla de lanzamiento, no podrá seleccionar un valor. Se muestra el valor de la plantilla. La AMI especificada en la plantilla debe cumplir los requisitos que están en [Especificación de una AMI](launch-templates.md#launch-template-custom-ami).
   +  **Tipo de capacidad**: Seleccione un tipo de capacidad. Para obtener más información sobre cómo elegir un tipo de capacidad, consulte [Tipos de capacidad de grupo de nodos administrado](managed-node-groups.md#managed-node-group-capacity-types). No se pueden mezclar diferentes tipos de capacidad dentro del mismo grupo de nodos. Si desea utilizar ambos tipos de capacidad, cree grupos de nodos independientes, cada uno con su propia capacidad y tipos de instancias. Consulte [Reserva de GPU para grupos de nodos administrados](https://docs.aws.amazon.com/eks/latest/userguide/capacity-blocks-mng.html) para obtener información sobre el aprovisionamiento y el escalado de nodos de trabajo acelerados por GPU.
   +  **Tipos de instancia**: Se especifican uno o más tipos de instancia de forma predeterminada. Para eliminar un tipo de instancia predeterminado, seleccione la casilla `X` en la parte derecha del tipo de instancia. Elija los tipos de instancia que se van a utilizar en el grupo de nodos administrado. Para obtener más información, consulte [Elección de un tipo de instancia de nodo de Amazon EC2 óptimo](choosing-instance-type.md).

     La consola muestra un conjunto de tipos de instancia de uso frecuente. Si necesita crear un grupo de nodos administrados con un tipo de instancia que no figura en la lista, utilice `eksctl`, la CLI de AWS, AWS CloudFormation o un SDK para crear el grupo de nodos. Si especificó una plantilla de lanzamiento en la página anterior, no podrá seleccionar un valor porque el tipo de instancia debe especificarse en la plantilla de lanzamiento. Se muestra el valor de la plantilla de lanzamiento. Si seleccionó **Spot** como **Capacity type (Tipo de capacidad)**, recomendamos especificar varios tipos de instancia para mejorar la disponibilidad.
   +  **Tamaño del disco**: ingrese el tamaño del disco (en GiB) que se va a utilizar para el volumen raíz de su nodo.

     Si especificó una plantilla de lanzamiento en la página anterior, no podrá seleccionar un valor porque debe especificarse en la plantilla de lanzamiento.
   +  **Tamaño deseado**: Especifique el número actual de nodos que debe mantener el grupo de nodos administrado durante el lanzamiento.
**nota**  
Amazon EKS no escala automáticamente el grupo de nodos de entrada o salida. Sin embargo, puede configurar el Escalador automático de clústeres de Kubernetes para que lo haga. Para obtener más información, consulte [Escalador automático de clústeres en AWS](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md).
   +  **Tamaño mínimo**: Especifica la cantidad mínima de nodos a los que puede escalar el grupo de nodos administrado.
   +  **Tamaño máximo**: Especifica el número máximo de nodos a los que puede escalar el grupo de nodos administrado.
   +  **Configuración de la actualización del grupo de nodos**: (Opcional) puede seleccionar el número o el porcentaje de nodos que se actualizarán en paralelo. Estos nodos no estarán disponibles durante la actualización. En **Máximo no disponible**, seleccione una de las siguientes opciones y especifique un **valor**:
     +  **Número**: Seleccione y especifique el número de nodos del grupo de nodos que se pueden actualizar en paralelo.
     +  **Porcentaje**: Seleccione y especifique el porcentaje de nodos del grupo de nodos que se pueden actualizar en paralelo. Esto es útil si tiene un gran número de nodos en su grupo de nodos.
   +  **Configuración de reparación automática de nodos**: (opcional) si activa la casilla **Habilitar la reparación automática de nodos**, Amazon EKS reemplazará automáticamente los nodos cuando se produzcan problemas detectados. Para obtener más información, consulte [Detección de los problemas de estado de los nodos y reparación automática de los nodos](node-health.md).

1. En la página **Especificar redes**, rellene los parámetros como corresponda y, a continuación, elija **Siguiente**.
   +  **Subredes**: Elija las subredes en las que lanzar los nodos administrados.
**importante**  
Si ejecuta una aplicación con estado en varias zonas de disponibilidad basadas en volúmenes de Amazon EBS y utiliza el [Escalador automático de clústeres](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) de Kubernetes, debe configurar varios grupos de nodos, cada uno enfocado a una sola zona de disponibilidad. Además, debe habilitar la característica `--balance-similar-node-groups`.
**importante**  
Si elige una subred pública y el clúster solo tiene habilitado el punto de conexión del servidor de API público, la subred debe tener `MapPublicIPOnLaunch` establecido en `true` para que las instancias se unan correctamente a un clúster. Si la subred se creó con `eksctl` o las [plantillas de AWS CloudFormation ofrecidas por Amazon EKS](creating-a-vpc.md) el 26 de marzo de 2020 o después, este valor ya está establecido en `true`. Si las subredes se crearon con `eksctl` o las plantillas de AWS CloudFormation antes del 26 de marzo de 2020, debe cambiar el valor de forma manual. Para obtener más información, 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 utiliza una plantilla de lanzamiento y especifica varias interfaces de red, Amazon EC2 no asignará automáticamente una dirección `IPv4` pública, incluso si `MapPublicIpOnLaunch` se establece en `true`. Para que los nodos se unan al clúster en este escenario, debe habilitar el punto de conexión del servidor de API privado del clúster o lanzar nodos en una subred privada con acceso a Internet saliente proporcionado a través de un método alternativo, como una puerta de enlace NAT. A fin de obtener más información, consulte [Direcciones IP de instancias de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html) en la *Guía del usuario de Amazon EC2*.
   +  **Configure el acceso SSH a los nodos** (opcional). El acceso SSH le permite conectarse a sus instancias y recopilar información de diagnóstico si hay algún problema. Le recomendamos que habilite el acceso remoto cuando cree un grupo de nodos. No puede habilitar el acceso remoto después de crear el grupo de nodos.

     Si eligió utilizar una plantilla de lanzamiento, esta opción no se muestra. Para habilitar el acceso remoto a los nodos, especifique un par de claves en la plantilla de lanzamiento y asegúrese de que el puerto adecuado esté abierto para los nodos de los grupos de seguridad que especifique en la plantilla de lanzamiento. Para obtener más información, consulte [Uso de grupos de seguridad personalizados](launch-templates.md#launch-template-security-groups).
**nota**  
Para Windows, este comando no habilita SSH. En su lugar, asocia el par de claves de Amazon EC2 con la instancia y le permite RDP en la instancia.
   + En **Par de claves de SSH** seleccione una clave SSH de Amazon EC2 para utilizar. Para obtener información sobre Linux, consulte [Pares de claves e instancias de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) para Linux en la *Guía del usuario de Amazon EC2*. Para obtener información sobre Windows, consulte [Pares de claves e instancias de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html) para Windows en la *Guía del usuario de Amazon EC2*. Si eligió utilizar una plantilla de lanzamiento, no puede seleccionar una. Cuando se proporciona una clave SSH de Amazon EC2 para grupos de nodos que utilizan AMI de Bottlerocket, el contenedor administrativo también se habilita. Para obtener más información, consulte [Contenedor de administración](https://github.com/bottlerocket-os/bottlerocket#admin-container) en GitHub.
   + En **Allow SSH remote access from (Permitir acceso remoto de SSH desde)**, si desea limitar el acceso a instancias específicas, seleccione los grupos de seguridad asociados a dichas instancias. Si no se seleccionan grupos de seguridad específicos, se permite el acceso SSH desde cualquier lugar de Internet (`0.0.0.0/0`).

1. En la página **Revisar y crear**, revise la configuración del grupo de nodos administrados y elija **Crear**.

   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. Observe el estado de los nodos y espere a que aparezca el estado `Ready`.

   ```
   kubectl get nodes --watch
   ```

1. (Solo para nodos de GPU) Si ha elegido un tipo de instancia de GPU y una AMI acelerada optimizada para Amazon EKS, deberá 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
   ```

## Instalación de complementos de Kubernetes
<a name="_install_kubernetes_add_ons"></a>

Ahora que tiene un clúster de Amazon EKS en funcionamiento con nodos, está listo para comenzar a instalar los complementos de Kubernetes e implementar aplicaciones en su clúster. Los siguientes temas de documentación lo ayudarán a ampliar la funcionalidad de su clúster.
+ La [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que creó el clúster es la única entidad principal que puede hacer llamadas al servidor de API de Kubernetes con `kubectl` o la Consola de administración de AWS. Si desea que otras entidades principales de IAM tengan acceso al clúster, debe agregarlas. Para obtener más información, consulte [Concesión a los usuarios y roles de IAM de acceso a las API de Kubernetes](grant-k8s-access.md) y [Permisos necesarios](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
+ 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).
+ Configure el [Escalador automático de clústeres](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) de Kubernetes para ajustar automáticamente el número de nodos en sus grupos de nodos.
+ Implemente una [aplicación de muestra](sample-deployment.md) en su clúster.
+  [Organice y supervise los recursos del clúster](eks-managing.md) con herramientas importantes para administrar el clúster.

# Actualización de un grupo de nodos administrados para un clúster
<a name="update-managed-node-group"></a>

Cuando inicia una actualización de grupo de nodos administrados, Amazon EKS actualiza los nodos de forma automática al completar los pasos que se indican en [Descripción de cada fase de las actualizaciones de los nodos](managed-node-update-behavior.md). Si utiliza una AMI optimizada para Amazon EKS, Amazon EKS aplica automáticamente los últimos parches de seguridad y actualizaciones del sistema operativo a los nodos como parte de la versión más reciente de la AMI.

Existen varios escenarios en los que resulta útil actualizar la versión o configuración del grupo de nodos administrado de Amazon EKS:
+ Ha actualizado la versión de Kubernetes para su clúster de Amazon EKS y desea actualizar los nodos para que utilicen la misma versión de Kubernetes.
+ Hay disponible una nueva versión de la AMI para el grupo de nodos administrados. Para obtener más información acerca de las versiones de AMI, consulte estas secciones:
  +  [Obtención de información acerca de la versión de la AMI de Amazon Linux](eks-linux-ami-versions.md) 
  +  [Creación de nodos con AMI de Bottlerocket optimizadas](eks-optimized-ami-bottlerocket.md) 
  +  [Recuperación de la información sobre la versión de la AMI de Windows](eks-ami-versions-windows.md) 
+ Desea ajustar el número mínimo, máximo o deseado de las instancias del grupo de nodos administrados.
+ Desea agregar o quitar etiquetas Kubernetes de las instancias del grupo de nodos administrados.
+ Desea agregar o quitar etiquetas de AWS del grupo de nodos administrados.
+ Debe implementar una nueva versión de una plantilla de lanzamiento con cambios de configuración, como una AMI personalizada actualizada.
+ Ha implementado la versión `1.9.0` o posterior del complemento CNI de Amazon VPC, ha habilitado el complemento para la delegación de prefijos y desea nuevas instancias de AWS Nitro System en un grupo de nodos para admitir un número significativamente mayor de pods. Para obtener más información, consulte [Asignación de más direcciones IP a los nodos de Amazon EKS con prefijos](cni-increase-ip-addresses.md).
+ Ha habilitado la delegación de prefijos IP para los nodos de Windows y quiere que las nuevas instancias de AWS Nitro System en un grupo de nodos admitan un número significativamente mayor de pods. Para obtener más información, consulte [Asignación de más direcciones IP a los nodos de Amazon EKS con prefijos](cni-increase-ip-addresses.md).

Si hay una versión de lanzamiento de AMI más reciente para la versión de Kubernetes del grupo de nodos administrado, puede actualizar la versión de su grupo de nodos para utilizar esa nueva versión de la AMI. De manera similar, si su clúster está ejecutando una versión de Kubernetes más reciente que su grupo de nodos, puede actualizar el grupo de nodos para que utilice la última versión de la AMI que coincida con la versión de Kubernetes del clúster.

Cuando se termina un nodo de un grupo de nodos administrados debido a una operación de escalado o actualización, los pods de ese nodo se drenan primero. Para obtener más información, consulte [Descripción de cada fase de las actualizaciones de los nodos](managed-node-update-behavior.md).

## Actualizar una versión de grupo de nodos
<a name="mng-update"></a>

Puede actualizar una versión del grupo de nodos con una de las siguientes opciones:
+  [`eksctl`](#eksctl_update_managed_nodegroup) 
+  [Consola de administración de AWS](#console_update_managed_nodegroup) 

La versión a la que se actualiza no puede ser superior a la versión del plano de control.

## `eksctl`
<a name="eksctl_update_managed_nodegroup"></a>

 **Actualice un grupo de nodos administrados mediante `eksctl` ** 

Actualice un grupo de nodos administrado a la última versión de AMI de la misma versión de Kubernetes implementada actualmente en los nodos de trabajo con el comando siguiente. Reemplace todos los *valores de ejemplo* por sus propios valores.

```
eksctl upgrade nodegroup \
  --name=node-group-name \
  --cluster=my-cluster \
  --region=region-code
```

**nota**  
Si va a actualizar un grupo de nodos que se implementa con una plantilla de lanzamiento a una nueva versión de plantilla de lanzamiento, agregue `--launch-template-version version-number ` al comando anterior. La plantilla de lanzamiento debe cumplir los requisitos descritos en [Personalización de nodos administrados con plantillas de lanzamiento](launch-templates.md). Si la plantilla de lanzamiento incluye una AMI personalizada, la AMI debe cumplir los requisitos en [Especificación de una AMI](launch-templates.md#launch-template-custom-ami). Cuando actualiza el grupo de nodos a una versión más reciente de la plantilla de lanzamiento, todos los nodos se reciclan para que coincidan con la nueva configuración de la versión de la plantilla de lanzamiento especificada.

No puede actualizar directamente un grupo de nodos que se implementa sin una plantilla de lanzamiento a una nueva versión de la plantilla de lanzamiento. En su lugar, debe implementar un nuevo grupo de nodos mediante la plantilla de lanzamiento para actualizar el grupo de nodos a una nueva versión de la plantilla de lanzamiento.

Puede actualizar un grupo de nodos a la misma versión que la versión de Kubernetes del plano de control. Por ejemplo, si tiene un clúster que ejecuta Kubernetes `1.35`, puede actualizar los nodos que ejecutan Kubernetes `1.34` actualmente a la versión `1.35` con el comando siguiente.

```
eksctl upgrade nodegroup \
  --name=node-group-name \
  --cluster=my-cluster \
  --region=region-code \
  --kubernetes-version=1.35
```

## Consola de administración de AWS
<a name="console_update_managed_nodegroup"></a>

 **Actualice un grupo de nodos administrado mediante la Consola de administración de AWS ** 

1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).

1. Elija el clúster que contiene el grupo de nodos que desea actualizar.

1. Si al menos un grupo de nodos tiene una actualización disponible, aparece un cuadro en la parte superior de la página con una notificación sobre la actualización disponible. Si selecciona la pestaña **Computación**, verá **Actualizar ahora** en la columna **Versión de lanzamiento de la AMI** de la tabla **Grupos de nodos** para el grupo de nodos que tenga una actualización disponible. Para actualizar el grupo de nodos, elija **Update now** (Actualizar ahora).

   No verá una notificación para los grupos de nodos que se implementaron con una AMI personalizada. Si los nodos se implementan con una AMI personalizada, complete los siguientes pasos para implementar una nueva AMI personalizada actualizada.

   1. Cree una nueva versión de su AMI.

   1. Cree una nueva versión de la plantilla de lanzamiento con el nuevo ID de AMI.

   1. Actualice los nodos a la nueva versión de la plantilla de lanzamiento.

1. En el cuadro de diálogo **Update node group version** (Actualizar la versión del grupo de nodos), active o desactive las siguientes opciones:
   +  **Update node group version** (Actualizar la versión del grupo de nodos): esta opción no está disponible si ha implementado una AMI personalizada o su AMI optimizada para Amazon EKS está actualmente en la versión más reciente del clúster.
   +  **Change launch template version** (Cambiar la versión de la plantilla de lanzamiento): esta opción no está disponible si el grupo de nodos se implementa sin una plantilla de lanzamiento personalizada. Solo puede actualizar la versión de la plantilla de lanzamiento para un grupo de nodos que se haya implementado con una plantilla de lanzamiento personalizada. Seleccione la **versión de la plantilla de lanzamiento** a la que desea actualizar el grupo de nodos. Si el grupo de nodos está configurado con una AMI personalizada, la versión que seleccione también debe especificar una AMI. Al actualizar a una versión más reciente de la plantilla de lanzamiento, todos los nodos se reciclan para que coincidan con la nueva configuración de la versión de la plantilla de lanzamiento especificada.

1. En **Actualizar estrategia**, seleccione una de las siguientes opciones:
   +  **Actualización continua**: esta opción respeta los presupuestos de interrupción del pod para el clúster. Se produce un error en las actualizaciones si hay un problema de presupuesto de interrupción de pod que hace que Amazon EKS no pueda vaciar correctamente los pods que se están ejecutando en este grupo de nodos.
   +  **Actualización forzada**: esta opción no respeta los presupuestos de interrupción del pod. Las actualizaciones se producen independientemente de los problemas presupuestarios de la interrupción del pod al forzar el reinicio de los nodos.

1. Elija **Actualizar**.

## Editar una configuración de grupo de nodos
<a name="mng-edit"></a>

Puede modificar algunas de las opciones de configuración de un grupo de nodos administrado.

1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).

1. Elija el clúster que contiene el grupo de nodos que desea editar.

1. Seleccione la pestaña **Compute** (Informática).

1. Seleccione el grupo de nodos que desea editar y elija **Edit** (Editar).

1. (Opcional) En la página **Editar grupo de nodos**, haga lo siguiente:

   1. Edite la **configuración de escalado del grupo de nodos**.
      +  **Tamaño deseado**: especifica el número actual de nodos que debe mantener el grupo de nodos administrado.
      +  **Tamaño mínimo**: Especifica la cantidad mínima de nodos a los que puede escalar el grupo de nodos administrado.
      +  **Tamaño máximo**: especifica el número máximo de nodos a los que puede escalar el grupo de nodos administrado. Para obtener el número máximo de nodos admitidos en un grupo de nodos, consulte [Visualización y administración de Amazon EKS y las Service Quotas de Fargate](service-quotas.md).

   1. (Opcional) Agregue o elimine **etiquetas de Kubernetes** para los nodos de su grupo de nodos. Las etiquetas que se muestran aquí son solo las que se han aplicado con Amazon EKS. Pueden existir otras etiquetas en los nodos que no se muestran aquí.

   1. (Opcional) Agregue o elimine **taints de Kubernetes** para los nodos de su grupo de nodos. Las taints agregadas pueden tener el efecto de ` NoSchedule `, ` NoExecute ` o ` PreferNoSchedule `. Para obtener más información, consulte [Receta: Limitación para que los pods no se programen en nodos específicos](node-taints-managed-node-groups.md).

   1. (Opcional) Agregue o elimine **etiquetas** del recurso de su grupo de nodos. Estas etiquetas solo se aplican al grupo de nodos de Amazon EKS. No se propagan a ningún otro recurso, como las subredes o instancias de Amazon EC2 en el grupo de nodos.

   1. (Opcional) Edite la **Configuración de la actualización del grupo de nodos**. Seleccione el **Number (Número)** o el **Percentage (Porcentaje)**.
      +  **Número**: seleccione y especifique el número de nodos del grupo de nodos que se pueden actualizar en paralelo. Estos nodos no estarán disponibles durante la actualización.
      +  **Porcentaje**: seleccione y especifique el porcentaje de nodos del grupo de nodos que se pueden actualizar en paralelo. Estos nodos no estarán disponibles durante la actualización. Esto es útil si tiene varios nodos en su grupo de nodos.

   1. Cuando haya terminado de editar, elija **Guardar cambios**.

**importante**  
Al actualizar la configuración del grupo de nodos, cuando se modifica el [https://docs.aws.amazon.com/eks/latest/APIReference/API_NodegroupScalingConfig.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_NodegroupScalingConfig.html), no se respetan los presupuestos de interrupción de pods (PDB). A diferencia del proceso de [actualización de grupos de nodos](managed-node-update-behavior.md) (que vacía los nodos y respeta los PDB durante la fase de actualización), al actualizar la configuración de escalado, los nodos se terminan inmediatamente a través de una llamada de reducción vertical del grupo de escalado automático (ASG). Esto ocurre sin tener en cuenta los PDB, independientemente del tamaño objetivo al que se reduce verticalmente. Esto significa que cuando se reduce el `desiredSize` de un grupo de nodos administrados por Amazon EKS, los pods se expulsan en cuanto se terminan los nodos, sin respetar ningún PDB.

# Descripción de cada fase de las actualizaciones de los nodos
<a name="managed-node-update-behavior"></a>

La estrategia de actualización del nodo de trabajo administrado de Amazon EKS tiene cuatro fases diferentes descritas en las siguientes secciones.

## Fase de configuración
<a name="managed-node-update-set-up"></a>

La fase de configuración incluye los siguientes pasos:

1. Crea una nueva versión de plantilla de lanzamiento de Amazon EC2 para el grupo de escalado automático asociado al grupo de nodos. La nueva versión de la plantilla de lanzamiento utiliza la AMI de destino o la versión de plantilla de lanzamiento personalizada para la actualización.

1. El grupo de escalado automático se actualiza para utilizar la versión más reciente de la plantilla de lanzamiento.

1. Determina la cantidad máxima de nodos que se van a actualizar en paralelo mediante la propiedad de `updateConfig` para el grupo de nodos. El máximo no disponible tiene una cuota de 100 nodos. El valor predeterminado es un nodo. Para obtener más información, consulte la propiedad [updateConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateNodegroupConfig.html#API_UpdateNodegroupConfig_RequestSyntax) en la *Referencia de la API de Amazon EKS*.

## Fase de escalado
<a name="managed-node-update-scale-up"></a>

Al actualizar los nodos de un grupo de nodos administrados, los nodos actualizados se lanzan en la misma zona de disponibilidad que los que se están actualizando. Para garantizar esta ubicación, utilizamos el reequilibrio de la zona de disponibilidad de Amazon EC2. Para obtener más información, consulte [Reequilibrio de la zona de disponibilidad](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage) en la *Guía del usuario de Amazon EC2 Auto Scaling*. Para cumplir este requisito, es posible que lancemos hasta dos instancias por zona de disponibilidad en su grupo de nodos administrado.

La fase de escalado incluye los siguientes pasos:

1. Aumenta el tamaño máximo del grupo de escalado automático y el tamaño deseado en el mayor:
   + Hasta el doble del número de zonas de disponibilidad en la que se implementa el grupo de escalado automático.
   + El máximo no disponible de actualización.

     Por ejemplo, si el grupo de nodos tiene cinco zonas de disponibilidad y `maxUnavailable` como uno solo, el proceso de actualización puede lanzar un máximo de 10 nodos. Sin embargo, cuando `maxUnavailable` es 20 (o cualquier número superior a 10), el proceso puede lanzar 20 nuevos nodos.

1. Después de escalar el grupo de Auto Scaling, comprueba si los nodos que utilizan la configuración más reciente están presentes en el grupo de nodos. Este paso solo se efectúa correctamente cuando cumple estos criterios:
   + Se lanza al menos un nuevo nodo en cada zona de disponibilidad en la que existe el nodo.
   + Todos los nuevos nodos deberían estar en estado `Ready`.
   + Los nuevos nodos deben tener etiquetas aplicadas de Amazon EKS.

     Estas son las etiquetas aplicadas de Amazon EKS en los nodos de trabajo de un grupo de nodos normal:
     +  `eks.amazonaws.com/nodegroup-image=$amiName` 
     +  `eks.amazonaws.com/nodegroup=$nodeGroupName` 

     Estas son las etiquetas aplicadas de Amazon EKS en los nodos de trabajo en una plantilla de lanzamiento personalizado o grupo de nodos de AMI:
     +  `eks.amazonaws.com/nodegroup-image=$amiName` 
     +  `eks.amazonaws.com/nodegroup=$nodeGroupName` 
     +  `eks.amazonaws.com/sourceLaunchTemplateId=$launchTemplateId` 
     +  `eks.amazonaws.com/sourceLaunchTemplateVersion=$launchTemplateVersion` 

1. Marca los nodos como no programables para evitar programar nuevos pods. También etiqueta los nodos con el `node.kubernetes.io/exclude-from-external-load-balancers=true` para eliminar los nodos antiguos de los equilibradores de carga antes de terminarlos.

Las siguientes son las razones conocidas que llevan a un error de `NodeCreationFailure` en esta fase:

 **Capacidad insuficiente en la zona de disponibilidad**   
Existe la posibilidad de que la zona de disponibilidad no tenga la capacidad de los tipos de instancias solicitados. Se recomienda configurar varios tipos de instancias al crear un grupo de nodos administrados.

 **Límites de instancia de EC2 en su cuenta**   
Es posible que tenga que aumentar el número de instancias de Amazon EC2 que su cuenta puede ejecutar simultáneamente mediante Service Quotas. Para obtener más información, consulte [EC2 Service Quotas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) en la *Guía del usuario de Amazon Elastic Compute Cloud para instancias de Linux*.

 **Datos de usuario personalizados**   
Los datos de usuario personalizados a veces pueden interrumpir el proceso de arranque. Este escenario puede llevar a que la `kubelet` no se inicie en el nodo o que los nodos no reciban etiquetas de Amazon EKS esperadas en ellos. Para obtener más información, consulte [Especificación de una AMI](launch-templates.md#launch-template-custom-ami).

 **Cualquier cambio que haga que un nodo no esté en buen estado o no esté preparado**   
La presión del disco del nodo, la presión de la memoria y condiciones similares pueden provocar que un nodo no funcione en estado `Ready`.

 **La mayoría de los nodos se arrancan en 15 minutos**   
Si algún nodo tarda más de 15 minutos en arrancar y unirse al clúster, se agotará el tiempo de espera de la actualización. Este es el tiempo de ejecución total para el arranque de un nodo nuevo, medido desde el momento en que se necesita un nodo nuevo hasta el momento en que se une al clúster. Al actualizar un grupo de nodos administrado, el contador de tiempo se inicia en cuanto aumenta el tamaño del grupo de escalado automático.

## Fase de actualización
<a name="managed-node-update-upgrade"></a>

La fase de actualización se comporta de dos maneras diferentes, en función de la *estrategia de actualización*. Hay dos estrategias de actualización: **predeterminada** y **mínima**.

Recomendamos la estrategia predeterminada en la mayoría de los casos. Crea nuevos nodos antes de terminar los antiguos, de modo que la capacidad disponible se mantiene durante la fase de actualización. La estrategia mínima resulta útil en situaciones en las que los recursos o los costos se ven limitados, por ejemplo, con aceleradores de hardware como las GPU. Consiste en terminar los nodos anteriores antes de crear los nuevos, de modo que la capacidad total nunca aumente más allá de la cantidad configurada.

La estrategia de actualización *predeterminada* consta de los siguientes pasos:

1. Aumenta la cantidad de nodos (cantidad deseada) en el grupo de escalado automático, lo que provoca que el grupo de nodos cree nodos adicionales.

1. Selecciona aleatoriamente un nodo que necesita una actualización hasta el máximo no disponible configurado para el grupo de nodos.

1. Drena los pods del nodo. Si los pods no salen del nodo en 15 minutos y no hay un indicador de fuerza, la fase de actualización falla con un error `PodEvictionFailure`. Para este escenario, puede aplicar el indicador de fuerza con la solicitud `update-nodegroup-version` para eliminar los pods.

1. Acordona el nodo después de expulsar todos los pods y espera 60 segundos. Esto se hace para que el controlador del servicio no envíe ninguna solicitud nueva a este nodo y elimine este nodo de su lista de nodos activos.

1. Envía una solicitud de terminación al grupo de escalado automático para el nodo acordonado.

1. Repite los pasos anteriores de actualización hasta que no haya nodos en el grupo de nodos que se implementen con la versión anterior de la plantilla de lanzamiento.

La estrategia de actualización *mínima* consta de los siguientes pasos:

1. Marca todos los nodos del grupo como no programables al inicio, para que el controlador de servicio no envíe nuevas solicitudes a estos nodos.

1. Selecciona aleatoriamente un nodo que necesita una actualización hasta el máximo no disponible configurado para el grupo de nodos.

1. Drena los pods de los nodos seleccionados. Si los pods no salen del nodo en 15 minutos y no hay un indicador de fuerza, la fase de actualización falla con un error `PodEvictionFailure`. Para este escenario, puede aplicar el indicador de fuerza con la solicitud `update-nodegroup-version` para eliminar los pods.

1. Después de que se haya desalojado cada pod y transcurran 60 segundos, se envía una solicitud de terminación al grupo de escalado automático para los nodos seleccionados. El grupo de escalado automático crea nuevos nodos (en la misma cantidad que los nodos seleccionados) para reemplazar la capacidad faltante.

1. Repite los pasos anteriores de actualización hasta que no haya nodos en el grupo de nodos que se implementen con la versión anterior de la plantilla de lanzamiento.

### Errores `PodEvictionFailure` durante la fase de actualización
<a name="_podevictionfailure_errors_during_the_upgrade_phase"></a>

Las siguientes son las razones conocidas que llevan a un error de `PodEvictionFailure` en esta fase:

 **PDB agresivo**   
El PDB agresivo se define en el pod o hay varios PDB que apuntan al mismo pod.

 **Implementación que tolera todas las taints**   
Una vez expulsado cada pod, se espera que el nodo esté vacío porque el nodo se marcó como [taint](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) en los pasos anteriores. Sin embargo, si la implementación tolera todas las taints, es más probable que el nodo no esté vacío, lo que provoca un error en la expulsión del pod.

## Fase de reducción vertical
<a name="managed-node-update-scale-down"></a>

La fase de reducción vertical disminuye el tamaño máximo del grupo de Auto Scaling y el tamaño deseado en uno para volver a los valores antes de que se inicie la actualización.

Si el flujo de trabajo de actualización determina que el escalador automático del clúster realiza el escalado vertical del grupo de nodos durante la fase de reducción vertical del flujo de trabajo, se cierra inmediatamente sin que el grupo de nodos vuelva a su tamaño original.

# Personalización de nodos administrados con plantillas de lanzamiento
<a name="launch-templates"></a>

Para obtener el nivel más alto de personalización, puede implementar nodos administrados con su propia plantilla de lanzamiento según los pasos de esta página. El uso de una plantilla de lanzamiento permite funciones como proporcionar argumentos de arranque durante la implementación de un nodo (por ejemplo, argumentos de [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) adicionales), asignar direcciones IP a los pods desde un bloque de CIDR diferente al de la dirección IP asignada al nodo, implementar una AMI o una CNI propias personalizadas en los nodos.

Si proporciona su propia plantilla de lanzamiento al crear por primera vez un grupo de nodos administrado, también tendrá mayor flexibilidad más adelante. Siempre que implemente un grupo de nodos administrado con su propia plantilla de lanzamiento, puede actualizarlo de forma iterativa con una versión diferente de la misma plantilla de lanzamiento. Cuando actualiza el grupo de nodos a una versión diferente de la plantilla de lanzamiento, todos los nodos del grupo se reciclan para que coincidan con la nueva configuración de la versión de la plantilla de lanzamiento especificada.

Los grupos de nodos administrados se implementan siempre con una plantilla de lanzamiento para utilizar con el grupo de Amazon EC2 Auto Scaling. Cuando no proporciona una plantilla de lanzamiento, la API de Amazon EKS crea una en su cuenta de forma automática con los valores predeterminados. Sin embargo, no le recomendamos que modifique las plantillas de lanzamiento generadas automáticamente. Además, los grupos de nodos existentes que no utilizan una plantilla de lanzamiento personalizada no se pueden actualizar directamente. En su lugar, debe crear un nuevo grupo de nodos con una plantilla de lanzamiento personalizada para hacerlo.

## Conceptos básicos de configuración de plantillas de lanzamiento
<a name="launch-template-basics"></a>

Puede crear una plantilla de lanzamiento de Amazon EC2 Auto Scaling con la Consola de administración de AWS, la AWS CLI o un SDK de AWS. Para obtener más información, consulte [Creación de una plantilla de lanzamiento para un grupo de Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-launch-template.html) en la *guía del usuario de Amazon EC2 Auto Scaling*. Algunas de las opciones de configuración de una plantilla de lanzamiento son similares a las que se utilizan para la configuración de nodos administrados. Al implementar o actualizar un grupo de nodos con una plantilla de lanzamiento, se deben especificar algunas opciones en la configuración del grupo de nodos o en la plantilla de lanzamiento. No especifique un ajuste en ambos lugares. Si existe una configuración donde no debería, las operaciones como la creación o actualización de un grupo de nodos fallarán.

En la siguiente tabla, se enumeran los ajustes prohibidos en una plantilla de lanzamiento. También se enumeran ajustes similares, si hay alguno disponible, que se requieren en la configuración del grupo de nodos administrados. La configuración de la lista es la configuración que aparece en la consola. Pueden tener nombres similares, pero diferentes en la AWS CLI y el SDK.


| Plantilla de lanzamiento: opciones prohibidas | Configuración del grupo de nodos de Amazon EKS | 
| --- | --- | 
|   **Subred** en **Interfaces de red** (**Agregar interfaz de red**)  |   **Subredes** en **Configuración de red del grupo de nodos** en la página **Especificar red**  | 
|   **Perfil de instancia de IAM** en **Detalles avanzados**   |   **Rol de IAM del nodo** en **Configuración del grupo de nodos** en la página **Configurar grupo de nodos**.  | 
|   **Comportamiento de apagado** y **Detener: comportamiento de hibernación** en **Detalles avanzados**. Mantenga la opción predeterminada **No incluir en la configuración de la plantilla de lanzamiento** en la plantilla de lanzamiento para ambas configuraciones.  |  Sin equivalente. Amazon EKS debe controlar el ciclo de vida de la instancia, no el grupo de escalado automático.  | 

En la siguiente tabla, se enumeran los ajustes prohibidos de una configuración de grupo de nodos administrados. También se enumeran configuraciones similares, si hay alguna disponible, que son necesarias en una plantilla de lanzamiento. La configuración de la lista es la configuración que aparece en la consola. Es posible que tengan nombres similares en la AWS CLI y el SDK.


| Configuración del grupo de nodos de Amazon EKS: opciones prohibidas | Plantilla de inicialización | 
| --- | --- | 
|  (Solo si especificó una AMI personalizada en una plantilla de lanzamiento) **Tipo de AMI** en **Configuración de computación del grupo de nodos** en la página **Establecer la configuración informática y de escalado**: la consola muestra **Se especifica en la plantilla de lanzamiento** y el ID de la AMI que se especificó. Si no se especificó nada en **Imágenes de aplicaciones y sistema operativo (Imagen de máquina de Amazon)** en la plantilla de lanzamiento, puede seleccionar una AMI en la configuración del grupo de nodos.  |   **Imágenes de aplicaciones y sistema operativo (Imagen de máquina de Amazon)** en **Contenido de la plantilla de lanzamiento**: debe especificar un ID si tiene alguno de los siguientes requisitos: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/launch-templates.html)  | 
|   **Tamaño del disco** en **Configuración de computación del grupo de nodos** en la página **Establecer la configuración de informática y escalado**: la consola muestra **Especificado en la plantilla de lanzamiento**.  |   **Tamaño** en **Almacenamiento (Volúmenes)** (**Agregar nuevo volumen**). Debe especificarlo en la plantilla de lanzamiento.  | 
|   **Par de claves de SSH** en **Configuración del grupo de nodos** en la página **Especificar redes**: la consola muestra la clave especificada en la plantilla de lanzamiento o muestra **No especificado en la plantilla de lanzamiento**.  |   **Nombre del par de claves** en **Par de claves (inicio de sesión)**.  | 
|  No se pueden especificar grupos de seguridad fuente a los que se permita el acceso remoto cuando se utiliza una plantilla de lanzamiento.  |   **Grupos de seguridad** en **Configuración de red** para la instancia o **Grupos de seguridad** en **Interfaces de red** (**Agregar interfaz de red**), pero no ambos. Para obtener más información, consulte [Uso de grupos de seguridad personalizados](#launch-template-security-groups).  | 

**nota**  
Si implementa un grupo de nodos mediante una plantilla de lanzamiento, especifique un **tipo de instancia** o ninguno en **Contenido de la plantilla de lanzamiento** en una plantilla de lanzamiento. Si lo desea, puede especificar entre 0 y 20 tipos de instancia para **Tipos de instancias** en la página **Establecer la configuración de informática y escalado** de la consola. O bien, puede hacerlo mediante otras herramientas que utilizan la API de Amazon EKS. Si especifica un tipo de instancia en una plantilla de lanzamiento y utiliza esa plantilla de lanzamiento para implementar el grupo de nodos, no podrá especificar ningún tipo de instancia en la consola ni utilizar otras herramientas que utilicen la API de Amazon EKS. Si no especifica un tipo de instancia en una plantilla de lanzamiento, en la consola o si utiliza otras herramientas que utilizan la API de Amazon EKS, se utiliza el tipo de instancia `t3.medium`. Si el grupo de nodos utiliza el tipo de capacidad spot, se recomienda especificar varios tipos de instancias mediante la consola. Para obtener más información, consulte [Tipos de capacidad de grupo de nodos administrado](managed-node-groups.md#managed-node-group-capacity-types).
Si alguno de los contenedores que implementa en el grupo de nodos utiliza el servicio de metadatos de instancia versión 2, asegúrese de establecer la propiedad **Límite del salto de respuesta de metadatos** en `2` en la plantilla de lanzamiento. Para obtener más información, consulte [Metadatos de instancia y datos de usuario](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) en la *Guía del usuario de Amazon EC2*.
Las plantillas de lanzamiento no son compatibles con la característica `InstanceRequirements`, que permite seleccionar el tipo de instancia de forma flexible.

## Etiquetado de instancias de Amazon EC2
<a name="launch-template-tagging"></a>

Puede utilizar el parámetro `TagSpecification` de una plantilla de lanzamiento para especificar qué etiquetas se aplicarán a las instancias de Amazon EC2 del grupo de nodos. La entidad IAM que llama a las API `CreateNodegroup` o `UpdateNodegroupVersion` debe tener permisos para `ec2:RunInstances` y `ec2:CreateTags`, y las etiquetas deben agregarse a la plantilla de lanzamiento.

## Uso de grupos de seguridad personalizados
<a name="launch-template-security-groups"></a>

Puede utilizar una plantilla de lanzamiento para especificar [grupos de seguridad](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html) de Amazon EC2 personalizados para aplicar a instancias del grupo de nodos. Esto puede estar en el parámetro de grupos de seguridad de nivel de instancia o como parte de los parámetros de configuración de la interfaz de red. Sin embargo, no se puede crear una plantilla de lanzamiento que especifique el nivel de la instancia y los grupos de seguridad de una interfaz de red. Tenga en cuenta las siguientes condiciones que se aplican al uso de grupos de seguridad personalizados con grupos de nodos administrados:
+ Cuando utiliza la Consola de administración de AWS, Amazon EKS solo permite plantillas de lanzamiento con una única especificación de interfaz de red.
+ De forma predeterminada, Amazon EKS aplica el [grupo de seguridad de clúster](sec-group-reqs.md) a las instancias del grupo de nodos para facilitar la comunicación entre nodos y el plano de control. Si especifica grupos de seguridad personalizados en la plantilla de lanzamiento mediante cualquiera de las opciones mencionadas anteriormente, Amazon EKS no agrega el grupo de seguridad del clúster. Debe asegurarse de que las reglas entrantes y salientes de los grupos de seguridad habiliten la comunicación con el punto de conexión del clúster. Si las reglas del grupo de seguridad son incorrectas, los nodos de trabajo no pueden unirse al clúster. Para obtener más información acerca de las reglas de los grupos de seguridad, consulte [Revisión de requisitos de grupos de seguridad de Amazon EKS para clústeres](sec-group-reqs.md).
+ Si necesita acceso SSH a las instancias del grupo de nodos, incluya un grupo de seguridad que permita ese acceso.

## Datos de usuario de Amazon EC2
<a name="launch-template-user-data"></a>

La plantilla de lanzamiento incluye una sección para datos de usuario personalizados. Puede especificar la configuración de su grupo de nodos en esta sección sin crear manualmente AMI personalizadas individuales. Para obtener más información sobre la configuración disponible para Bottlerocket, consulte [Utilización de datos de usuario](https://github.com/bottlerocket-os/bottlerocket#using-user-data) en GitHub.

Puede proporcionar datos de usuario de Amazon EC2 en su plantilla de lanzamiento mediante `cloud-init` al iniciar sus instancias. Para obtener más información, consulte la documentación de [cloud-init](https://cloudinit.readthedocs.io/en/latest/index.html). Los datos de usuario se pueden utilizar para realizar operaciones de configuración comunes. Esto incluye las operaciones siguientes:
+  [Inclusión de usuarios o grupos](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups) 
+  [Instalación de paquetes](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#install-arbitrary-packages) 

Los datos de usuario de Amazon EC2 en las plantillas de lanzamiento que se utilizan con grupos de nodos administrados deben estar en el formato de [archivo multiparte MIME](https://cloudinit.readthedocs.io/en/latest/topics/format.html#mime-multi-part-archive) para las AMI de Amazon Linux y en el formato TOML para las AMI de Bottlerocket. Esto se debe a que los datos de usuario se combinan con los datos de usuario de Amazon EKS necesarios para que los nodos se unan al clúster. No especifique ningún comando en los datos de usuario que inicie o modifique `kubelet`. Esto se realiza como parte de los datos de usuario fusionados por Amazon EKS. Ciertos parámetros de `kubelet`, como establecer etiquetas en nodos, se pueden configurar directamente a través de la API de grupos de nodos administrados.

**nota**  
Para obtener más información sobre la personalización de `kubelet` avanzada, lo que incluye un inicio manual o pasar parámetros de configuración personalizados, consulte [Especificación de una AMI](#launch-template-custom-ami). Si se especifica un ID de AMI personalizado en una plantilla de lanzamiento, Amazon EKS no fusiona los datos de usuario.

Los siguientes detalles proporcionan más información sobre la sección de datos de usuario.

 **Datos de usuario de Amazon Linux 2**   
Puede combinar varios bloques de datos de usuario en un único archivo multiparte MIME. Por ejemplo, puede combinar un boothook de nube que configure el daemon de Docker con un script de shell de datos de usuario que instala un paquete personalizado. Un archivo multiparte MIME consta de los siguientes componentes:  
+ El tipo de contenido y declaración de límite de partes: – `Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="` 
+ La declaración de versión de MIME: – `MIME-Version: 1.0` 
+ Uno o más bloques de datos de usuario, que contienen los siguientes componentes:
  + El límite de apertura, que señala el inicio de un bloque de datos de usuario: `--==MYBOUNDARY==` 
  + La declaración de tipo de contenido para el bloque: `Content-Type: text/cloud-config; charset="us-ascii"`. Para obtener más información sobre los tipos de contenido, consulte la [documentación de cloud-init](https://cloudinit.readthedocs.io/en/latest/topics/format.html).
  + El contenido de los datos de usuario, por ejemplo, una lista de comandos de shell o políticas de `cloud-init`.
  + El límite de cierre, que señala el final del archivo multiparte MIME: `--==MYBOUNDARY==--` 

  A continuación, se muestra un ejemplo de un archivo multiparte MIME que puede utilizar para crear el suyo propio.

```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="

--==MYBOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"

#!/bin/bash
echo "Running custom user data script"

--==MYBOUNDARY==--
```

 **Datos de usuario de Amazon Linux 2023**   
Amazon Linux 2023 (AL2023) introduce un nuevo proceso de inicialización de nodos `nodeadm` que utiliza un esquema de configuración YAML. Si utiliza grupos de nodos autoadministrados o una AMI con una plantilla de lanzamiento, ahora tendrá que proporcionar metadatos del clúster adicionales de forma explícita cuando cree un nuevo grupo de nodos. A continuación, se muestra un [ejemplo](https://awslabs.github.io/amazon-eks-ami/nodeadm/) de los parámetros mínimos necesarios, en los que ahora se necesitan `apiServerEndpoint`, `certificateAuthority` y el servicio de `cidr`:  

```
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name: my-cluster
    apiServerEndpoint: https://example.com
    certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
    cidr: 10.100.0.0/16
```
Por lo general, establecerá esta configuración en los datos de usuario, tal y como están o incrustados en un documento MIME de varias partes:  

```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"

--BOUNDARY
Content-Type: application/node.eks.aws

---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig spec: [...]

--BOUNDARY--
```
En AL2, los metadatos de estos parámetros se descubrieron a partir de la llamada a la API `DescribeCluster` de Amazon EKS. Con AL2023, este comportamiento ha cambiado, ya que la llamada a la API adicional corre el riesgo de limitarse durante los escalados verticales de nodos a gran escala. Este cambio no le afecta si utiliza grupos de nodos administrados sin una plantilla de lanzamiento o si utiliza Karpenter. Para obtener más información sobre `certificateAuthority` y el servicio `cidr`, consulte [https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html) en la *Referencia de la API de Amazon EKS*.  
Este es un ejemplo completo de datos de usuario de AL2023 que combina un script de intérprete de comandos para personalizar el nodo (por ejemplo, instalar paquetes o almacenar previamente en caché las imágenes de contenedores) con la configuración requerida de `nodeadm`. Este ejemplo muestra personalizaciones comunes, como la instalación de paquetes de sistema adicionales, el almacenamiento previo en caché de imágenes de contenedores para mejorar el tiempo de inicio de los pods, la configuración de un proxy HTTP y la definición de marcas de `kubelet` para el etiquetado de nodos  

```
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"

--BOUNDARY
Content-Type: text/x-shellscript; charset="us-ascii"

#!/bin/bash
set -o errexit
set -o pipefail
set -o nounset

# Install additional packages
yum install -y htop jq iptables-services

# Pre-cache commonly used container images
nohup docker pull public.ecr.aws/eks-distro/kubernetes/pause:3.2 &

# Configure HTTP proxy if needed
cat > /etc/profile.d/http-proxy.sh << 'EOF'
export HTTP_PROXY="http://proxy.example.com:3128"
export HTTPS_PROXY="http://proxy.example.com:3128"
export NO_PROXY="localhost,127.0.0.1,169.254.169.254,.internal"
EOF

--BOUNDARY
Content-Type: application/node.eks.aws

apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name: my-cluster
    apiServerEndpoint: https://example.com
    certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
    cidr: 10.100.0.0/16
  kubelet:
    config:
      clusterDNS:
      - 10.100.0.10
    flags:
    - --node-labels=app=my-app,environment=production

--BOUNDARY--
```

 **Datos de usuario de Bottlerocket**   
Bottlerocket estructura los datos de usuario en formato TOML. Puede facilitar datos de usuario para fusionarlos con los datos de usuario proporcionados por Amazon EKS. Por ejemplo, puede especificar un configuración adicional de `kubelet`.  

```
[settings.kubernetes.system-reserved]
cpu = "10m"
memory = "100Mi"
ephemeral-storage= "1Gi"
```
Para obtener más información acerca de la configuración admitida, consulte la [documentación de Bottlerocket](https://github.com/bottlerocket-os/bottlerocket). Puede configurar etiquetas de nodos y [taints](node-taints-managed-node-groups.md) en los datos de usuario. Sin embargo, recomendamos que las configure en su grupo de nodos. Amazon EKS aplica estas configuraciones cuando lo hace de este modo.  
Cuando se fusionan los datos de usuario, el formato no se conserva, pero el contenido sigue siendo el mismo. La configuración que proporciona en los datos de usuario anula cualquier configuración configurada por Amazon EKS. Entonces, si configura `settings.kubernetes.max-pods` o `settings.kubernetes.cluster-dns-ip`, estos valores de los datos de usuario se aplican a los nodos.  
Amazon EKS no admite todos los TOML válidos. A continuación, se muestra una lista de formatos conocidos no compatibles:  
+ Comillas dentro de las claves citadas: `'quoted "value"' = "value"` 
+ Comillas escapadas en valores: `str = "I’m a string. \"You can quote me\""` 
+ Flotantes y enteros mixtos: `numbers = [ 0.1, 0.2, 0.5, 1, 2, 5 ]` 
+ Tipos mixtos en matrices: `contributors = ["[foo@example.com](mailto:foo@example.com)", { name = "Baz", email = "[baz@example.com](mailto:baz@example.com)" }]` 
+ Encabezados entre corchetes con claves citadas: `[foo."bar.baz"]` 

 **Datos de usuario de Windows**   
Los datos de usuario de Windows utilizan comandos de PowerShell. Al crear un grupo de nodos administrado, los datos de usuario personalizados se combinan con los datos de usuario administrados de Amazon EKS. Sus comandos de PowerShell son lo primero, seguidos de los comandos de datos de usuario administrados, todo dentro de una etiqueta `<powershell></powershell>`.  
Al crear grupos de nodos de Windows, Amazon EKS actualiza el `aws-auth` `ConfigMap` para permitir que los nodos basados en Linux se unan al clúster. El servicio no configura automáticamente permisos para las AMI de Windows. Si utiliza nodos de Windows, deberá gestionar el acceso mediante la API de entrada de acceso o la actualización directa de `aws-auth` `ConfigMap`. Para obtener más información, consulte [Implementación de nodos de Windows en clústeres de EKS](windows-support.md).
Si no se especifica ningún ID de AMI en la plantilla de lanzamiento, no utilice el script Amazon EKS Bootstrap de Windows en los datos de usuario para configurar Amazon EKS.
Los datos de usuario de ejemplo son los siguientes.  

```
<powershell>
Write-Host "Running custom user data script"
</powershell>
```

## Especificación de una AMI
<a name="launch-template-custom-ami"></a>

Si tiene alguno de los siguientes requisitos, especifique un ID de AMI en el campo `ImageId` de la plantilla de lanzamiento. Seleccione el requisito que tiene para obtener información adicional.

### Proporcione datos de usuario a fin de pasar argumentos al archivo `bootstrap.sh` incluido con una AMI optimizada de Linux o Bottlerocket para Amazon EKS.
<a name="mng-specify-eks-ami"></a>

Bootstrapping es un término que se utiliza para describir la adición de comandos que se pueden ejecutar cuando se inicia una instancia. Por ejemplo, el arranque permite usar argumentos [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) adicionales. Puede pasar los argumentos al script `bootstrap.sh` mediante `eksctl` sin especificar una configuración de lanzamiento. O puede hacerlo al especificar la información en la sección de datos de usuario de una plantilla de lanzamiento.

 **eksctl sin especificar una plantilla de lanzamiento**   
Cree un archivo llamado *my-nodegroup.yaml* con el siguiente contenido. Reemplace todos los *valores de ejemplo* por sus propios valores. Los argumentos `--apiserver-endpoint`, `--b64-cluster-ca` y `--dns-cluster-ip` son opcionales. Sin embargo, definirlos permite que el script `bootstrap.sh` evite crear una llamada `describeCluster`. Esto resulta útil en configuraciones de clústeres privados o clústeres en los que los nodos se reducen y escalan horizontalmente con frecuencia. Para obtener más información sobre el script `bootstrap.sh`, consulte el archivo [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) en GitHub.  
+ El único argumento requerido es el nombre del clúster (*my-cluster*).
+ Para recuperar el ID de una AMI optimizada para `ami-1234567890abcdef0 `, consulte las siguientes secciones:
  +  [Recuperación de los ID de AMI de Amazon Linux recomendados](retrieve-ami-id.md) 
  +  [Recuperación de los ID de AMI de Bottlerocket recomendados](retrieve-ami-id-bottlerocket.md) 
  +  [Recuperación de los ID de AMI de Microsoft Windows recomendados](retrieve-windows-ami-id.md) 
+ Para recuperar el *certificate-authority* de su clúster, ejecute el siguiente comando.

  ```
  aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
  ```
+ Para recuperar el *api-server-endpoint* de su clúster, ejecute el siguiente comando.

  ```
  aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
  ```
+ El valor de `--dns-cluster-ip` es su servicio de CIDR con `.10` al final. Para recuperar el *service-cidr* de su clúster, ejecute el siguiente comando. Por ejemplo, si el valor devuelto es `ipv4 10.100.0.0/16`, su valor es *10.100.0.10*.

  ```
  aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
  ```
+ En este ejemplo proporciona un argumento `kubelet` para establecer un valor de `max-pods` personalizado mediante el script `bootstrap.sh` incluido con la AMI optimizada para Amazon EKS. 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 obtener ayuda con la selección de *my-max-pods-value*, consulte . Para obtener más información sobre cómo se determina `maxPods` al usar grupos de nodos administrados, consulte [Cómo se determina maxPods](choosing-instance-type.md#max-pods-precedence).

  ```
  ---
  apiVersion: eksctl.io/v1alpha5
  kind: ClusterConfig
  
  metadata:
    name: my-cluster
    region: region-code
  
  managedNodeGroups:
    - name: my-nodegroup
      ami: ami-1234567890abcdef0
      instanceType: m5.large
      privateNetworking: true
      disableIMDSv1: true
      labels: { x86-al2-specified-mng }
      overrideBootstrapCommand: |
        #!/bin/bash
        /etc/eks/bootstrap.sh my-cluster \
          --b64-cluster-ca certificate-authority \
          --apiserver-endpoint api-server-endpoint \
          --dns-cluster-ip service-cidr.10 \
          --kubelet-extra-args '--max-pods=my-max-pods-value' \
          --use-max-pods false
  ```

  Para cada opción de archivo `eksctl` `config` disponible, consulte [Config file schema](https://eksctl.io/usage/schema/) (Esquema de archivo de configuración) en la documentación de `eksctl`. La utilidad `eksctl` sigue creando una plantilla de lanzamiento para usted y rellena sus datos de usuario con los datos que proporciona en el archivo `config`.

  Cree un grupo de nodos con el siguiente comando.

  ```
  eksctl create nodegroup --config-file=my-nodegroup.yaml
  ```

 **Datos del usuario en una plantilla de lanzamiento**   
Especifique la siguiente información en la sección de datos de usuario de la plantilla de lanzamiento. Reemplace todos los *valores de ejemplo* por sus propios valores. Los argumentos `--apiserver-endpoint`, `--b64-cluster-ca` y `--dns-cluster-ip` son opcionales. Sin embargo, definirlos permite que el script `bootstrap.sh` evite crear una llamada `describeCluster`. Esto resulta útil en configuraciones de clústeres privados o clústeres en los que los nodos se reducen y escalan horizontalmente con frecuencia. Para obtener más información sobre el script `bootstrap.sh`, consulte el archivo [bootstrap.sh](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) en GitHub.  
+ El único argumento requerido es el nombre del clúster (*my-cluster*).
+ Para recuperar el *certificate-authority* de su clúster, ejecute el siguiente comando.

  ```
  aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
  ```
+ Para recuperar el *api-server-endpoint* de su clúster, ejecute el siguiente comando.

  ```
  aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
  ```
+ El valor de `--dns-cluster-ip` es su servicio de CIDR con `.10` al final. Para recuperar el *service-cidr* de su clúster, ejecute el siguiente comando. Por ejemplo, si el valor devuelto es `ipv4 10.100.0.0/16`, su valor es *10.100.0.10*.

  ```
  aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
  ```
+ En este ejemplo proporciona un argumento `kubelet` para establecer un valor de `max-pods` personalizado mediante el script `bootstrap.sh` incluido con la AMI optimizada para Amazon EKS. Para obtener ayuda con la selección de *my-max-pods-value*, consulte . Para obtener más información sobre cómo se determina `maxPods` al usar grupos de nodos administrados, consulte [Cómo se determina maxPods](choosing-instance-type.md#max-pods-precedence).

  ```
  MIME-Version: 1.0
  Content-Type: multipart/mixed; boundary="==MYBOUNDARY=="
  
  --==MYBOUNDARY==
  Content-Type: text/x-shellscript; charset="us-ascii"
  
  #!/bin/bash
  set -ex
  /etc/eks/bootstrap.sh my-cluster \
    --b64-cluster-ca certificate-authority \
    --apiserver-endpoint api-server-endpoint \
    --dns-cluster-ip service-cidr.10 \
    --kubelet-extra-args '--max-pods=my-max-pods-value' \
    --use-max-pods false
  
  --==MYBOUNDARY==--
  ```

### Proporcione datos de usuario a fin de pasar argumentos al archivo `Start-EKSBootstrap.ps1` incluido con una AMI de Windows optimizada para Amazon EKS.
<a name="mng-specify-eks-ami-windows"></a>

Bootstrapping es un término que se utiliza para describir la adición de comandos que se pueden ejecutar cuando se inicia una instancia. Puede pasar los argumentos al script `Start-EKSBootstrap.ps1` mediante `eksctl` sin especificar una configuración de lanzamiento. O puede hacerlo al especificar la información en la sección de datos de usuario de una plantilla de lanzamiento.

Si desea especificar un ID de AMI de Windows personalizado, tenga en cuenta las siguientes consideraciones:
+ Debe utilizar una plantilla de lanzamiento y proporcionar los comandos de arranque necesarios en la sección de datos de usuario. Para recuperar el ID de Windows deseado, puede utilizar la tabla de [Creación de nodos con AMI de Windows optimizadas](eks-optimized-windows-ami.md).
+ Hay varios límites y condiciones. Por ejemplo, debe agregar `eks:kube-proxy-windows` a su mapa de configuración de IAM Authenticator de AWS. Para obtener más información, consulte [Límites y condiciones al especificar un ID de AMI](#mng-ami-id-conditions).

Especifique la siguiente información en la sección de datos de usuario de la plantilla de lanzamiento. Reemplace todos los *valores de ejemplo* por sus propios valores. Los argumentos `-APIServerEndpoint`, `-Base64ClusterCA` y `-DNSClusterIP` son opcionales. Sin embargo, definirlos permite que el script `Start-EKSBootstrap.ps1` evite crear una llamada `describeCluster`.
+ El único argumento requerido es el nombre del clúster (*my-cluster*).
+ Para recuperar el *certificate-authority* de su clúster, ejecute el siguiente comando.

  ```
  aws eks describe-cluster --query "cluster.certificateAuthority.data" --output text --name my-cluster --region region-code
  ```
+ Para recuperar el *api-server-endpoint* de su clúster, ejecute el siguiente comando.

  ```
  aws eks describe-cluster --query "cluster.endpoint" --output text --name my-cluster --region region-code
  ```
+ El valor de `--dns-cluster-ip` es su servicio de CIDR con `.10` al final. Para recuperar el *service-cidr* de su clúster, ejecute el siguiente comando. Por ejemplo, si el valor devuelto es `ipv4 10.100.0.0/16`, su valor es *10.100.0.10*.

  ```
  aws eks describe-cluster --query "cluster.kubernetesNetworkConfig.serviceIpv4Cidr" --output text --name my-cluster --region region-code
  ```
+ Para obtener argumentos adicionales, consulte [Parámetros de configuración del script de arranque](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
**nota**  
Si utiliza un CIDR de servicio personalizado, debe especificarlo con el parámetro `-ServiceCIDR`. De lo contrario, se producirá un error en la resolución de DNS del clúster para pods.

```
<powershell>
[string]$EKSBootstrapScriptFile = "$env:ProgramFiles\Amazon\EKS\Start-EKSBootstrap.ps1"
& $EKSBootstrapScriptFile -EKSClusterName my-cluster `
	 -Base64ClusterCA certificate-authority `
	 -APIServerEndpoint api-server-endpoint `
	 -DNSClusterIP service-cidr.10
</powershell>
```

### Ejecute una AMI personalizada debido a requisitos específicos de seguridad, conformidad o políticas internas
<a name="mng-specify-custom-ami"></a>

Para obtener más información, consulte [Imágenes de máquina de Amazon (AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) en la *Guía del usuario de Amazon EC2*. La especificación de compilación de la AMI de Amazon EKS contiene recursos y scripts de configuración para crear una AMI personalizada de Amazon EKS basada en Amazon Linux. Para obtener más información, consulte [Especificación de compilación de AMI de Amazon EKS](https://github.com/awslabs/amazon-eks-ami/) en GitHub. Para crear AMI personalizadas instaladas con otros sistemas operativos, consulte [AMI personalizadas de ejemplo de Amazon EKS](https://github.com/aws-samples/amazon-eks-custom-amis) en GitHub.

No puede usar referencias de parámetros dinámicos para los ID de AMI en las plantillas de lanzamiento empleadas con grupos de nodos administrados.

**importante**  
Al especificar una AMI, Amazon EKS no valida la versión de Kubernetes incrustada en la AMI frente a la versión del plano de control del clúster. Usted es responsable de asegurarse de que la versión de Kubernetes de la AMI personalizada cumpla con la [política de desfase de versiones de Kubernetes](https://kubernetes.io/releases/version-skew-policy):  
La versión de `kubelet` en los nodos no debe ser posterior a la versión del clúster
La versión de `kubelet` en los nodos debe ser igual a la versión del clúster o estar hasta tres versiones secundarias por detrás (para Kubernetes versión `1.28` o superior), o hasta dos versiones secundarias por detrás (para Kubernetes versión `1.27` o inferior)  
La creación de grupos de nodos administrados con incumplimientos de la política de desfase de versiones puede dar lugar a lo siguiente:
Nodos que no se unen al clúster
Comportamiento indefinido o incompatibilidades de la API
Inestabilidad del clúster o fallos en las cargas de trabajo
Al especificar una AMI, Amazon EKS no combina ningún dato de usuario. Más bien, usted es responsable de suministrar el comando `bootstrap` requerido para que los nodos se unan al clúster. Si los nodos no se unen al clúster, las acciones de Amazon EKS `CreateNodegroup` y `UpdateNodegroupVersion` también fallan.

## Límites y condiciones al especificar un ID de AMI
<a name="mng-ami-id-conditions"></a>

A continuación se detallan los límites y las condiciones que implica especificar un ID de AMI con grupos de nodos administrados:
+ Debe crear un nuevo grupo de nodos para cambiar entre especificar un ID de AMI en una plantilla de lanzamiento y no especificar un ID de AMI.
+ No se le notifica en la consola cuando hay disponible una versión más reciente de AMI. Para actualizar el grupo de nodos a una versión de AMI más reciente, debe crear una nueva versión de la plantilla de lanzamiento con un ID de AMI actualizado. A continuación, debe actualizar el grupo de nodos con la nueva versión de plantilla de lanzamiento.
+ Los siguientes campos no se pueden establecer en la API si especifica un ID de AMI:
  +  `amiType` 
  +  `releaseVersion` 
  +  `version` 
+ Todas las `taints` configuradas en la API se aplican de manera asíncrona si se especifica un ID de AMI. Para aplicar taints antes de que un nodo se una al clúster, se deben transferir las taints a `kubelet` en sus datos de usuario mediante la marca `--register-with-taints` de la línea de comandos. Para obtener más información, consulte [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) en la documentación de Kubernetes.
+ Al especificar un ID de AMI personalizado para los grupos de nodos administrados de Windows, agregue `eks:kube-proxy-windows` al mapa de configuración del Autenticador de AWS IAM. Esto es necesario para que el DNS funcione correctamente.

  1. Abra el mapa de configuración de IAM Authenticator de AWS para editarlo.

     ```
     kubectl edit -n kube-system cm aws-auth
     ```

  1. Agregue esta entrada a la lista de `groups` debajo de cada uno de los `rolearn` asociados con nodos de Windows. El mapa de configuración debe tener un aspecto similar al de [aws-auth-cm-windows.yaml](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml).

     ```
     - eks:kube-proxy-windows
     ```

  1. Guarde el archivo y salga del editor de texto.
+ Para cualquier AMI que utilice una plantilla de lanzamiento personalizada, el valor predeterminado de `HttpPutResponseHopLimit` para los grupos de nodos administrados se establece en `2`.

# Eliminación de un grupo de nodos administrado de un clúster
<a name="delete-managed-node-group"></a>

En este tema se describe cómo puede eliminar un grupo de nodos administrado de Amazon EKS. Al eliminar un grupo de nodos administrados, Amazon EKS establece primero el tamaño mínimo, máximo y deseado del grupo de Auto Scaling en cero. Esto hace que el grupo de nodos se reduzca verticalmente.

Antes de terminar cada instancia, Amazon EKS envía una señal para vaciar ese nodo. Durante el proceso de vaciado, Kubernetes hace lo siguiente para cada pod del nodo: ejecuta cualquier enlace de ciclo de vida `preStop` configurado, envía señales `SIGTERM` a los contenedores y, a continuación, espera a que `terminationGracePeriodSeconds` se apague correctamente. Si el nodo no se ha drenado después de cinco minutos, Amazon EKS permite que el escalado automático continúe con la terminación forzada de la instancia. Una vez terminadas todas las instancias, se elimina el grupo de escalado automático.

**importante**  
Si elimina un grupo de nodos administrado que utiliza un rol de IAM de un nodo que no se emplea en ningún otro grupo de nodos administrado en el clúster, el rol se quitará del `ConfigMap` de `aws-auth`. Si algún grupo de nodos autoadministrados del clúster utiliza el mismo rol de IAM del nodo, los nodos autoadministrados adoptarán el estado `NotReady`. Además, también se interrumpe la operación del clúster. Para añadir una asignación para el rol que está utilizando solo para los grupos de nodos autoadministrados, consulte [Creación de entradas de acceso](creating-access-entries.md), si la versión de la plataforma de su clúster es al menos la versión mínima que aparece en la sección de requisitos previos de [Concesión de acceso a los usuarios de IAM a las entradas de acceso de Kubernetes con EKS](access-entries.md). Si la versión de la plataforma es anterior a la versión mínima requerida para las entradas de acceso, puede volver a añadir la entrada al `ConfigMap` de `aws-auth`. Para obtener más información, ingrese `eksctl create iamidentitymapping --help` en su terminal.

Se puede eliminar un grupo de nodos administrados con:
+  [`eksctl`](#eksctl-delete-managed-nodegroup) 
+  [Consola de administración de AWS](#console-delete-managed-nodegroup) 
+  [AWS CLI](#awscli-delete-managed-nodegroup) 

## `eksctl`
<a name="eksctl-delete-managed-nodegroup"></a>

 **Eliminar un grupo de nodos administrados con `eksctl` ** 

Escriba el siguiente comando. Reemplace cada `<example value>` con valores propios.

```
eksctl delete nodegroup \
  --cluster <my-cluster> \
  --name <my-mng> \
  --region <region-code>
```

Para obtener más opciones, consulte [Eliminar y drenar grupos de nodos](https://eksctl.io/usage/nodegroups/#deleting-and-draining-nodegroups) en la documentación `eksctl`.

## Consola de administración de AWS
<a name="console-delete-managed-nodegroup"></a>

 **Eliminar un grupo de nodos administrados con la Consola de administración de AWS ** 

1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).

1. En la página **Clústeres**, elija el clúster que contiene el grupo de nodos que desea eliminar.

1. En la página del clúster, seleccione la pestaña **Computar**.

1. En la sección de **Node Groups** (Grupos de nodos), elija el grupo de nodos que desea eliminar. A continuación, elija **Eliminar**.

1. En el cuadro de diálogo de confirmación **Eliminar grupo de nodos**, introduzca el nombre del grupo de nodos. A continuación, elija **Eliminar**.

## AWS CLI
<a name="awscli-delete-managed-nodegroup"></a>

 **Eliminar un grupo de nodos administrados con la CLI de AWS** 

1. Escriba el siguiente comando. Reemplace cada `<example value>` con valores propios.

   ```
   aws eks delete-nodegroup \
     --cluster-name <my-cluster> \
     --nodegroup-name <my-mng> \
     --region <region-code>
   ```

1. Si se ha establecido `cli_pager=` en la configuración de la CLI, use las teclas de flecha del teclado para desplazarse por el resultado de la respuesta. Pulse la tecla `q` cuando termine.

   Para obtener más opciones, consulte el comando ` [delete-nodegroup](https://docs.aws.amazon.com/cli/latest/reference/eks/delete-nodegroup.html) ` en la *Referencia de los comandos de la CLI de AWS*.