**Ayude a mejorar esta página** 

Para contribuir a esta guía del usuario, elija el enlace **Edit this page on GitHub** que se encuentra en el panel derecho de cada página.

# Creación de 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.