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

# Administración de los recursos de computación mediante nodos
<a name="eks-compute"></a>

Un nodo de Kubernetes es una máquina que ejecuta aplicaciones en contenedores. Cada nodo tiene los siguientes componentes:
+  **[Tiempo de ejecución del contenedor](https://kubernetes.io/docs/setup/production-environment/container-runtimes/)**: es el software responsable de ejecutar los contenedores.
+  **[kubelet:](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)** se asegura de que los contenedores estén en buen estado y funcionando dentro de su pod asociado.
+  **[kube-proxy](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/)**: mantiene las reglas de red que permiten la comunicación con sus pods.

Para obtener más información, consulte [Nodos](https://kubernetes.io/docs/concepts/architecture/nodes/) en la documentación de Kubernetes.

El clúster de Amazon EKS puede programar pods en cualquier combinación de [nodos administrados del modo automático de EKS](automode.md), [nodos autoadministrados](worker.md), [grupos de nodos administrados de Amazon EKS](managed-node-groups.md), [AWS Fargate](fargate.md) y [Nodos híbridos de Amazon EKS](hybrid-nodes-overview.md). Para obtener más información sobre los nodos implementados en el clúster, consulte [Visualización de los recursos de Kubernetes en la Consola de administración de AWS](view-kubernetes-resources.md).

**nota**  
A excepción de los nodos híbridos, los nodos deben estar en la misma VPC que las subredes que seleccionó al crear el clúster. Sin embargo, los nodos no tienen que estar en las mismas subredes.

## Comparación de opciones de computación
<a name="_compare_compute_options"></a>

La siguiente tabla proporciona varios criterios para evaluar a la hora de decidir qué opciones se ajustan mejor a sus requisitos. Los nodos autoadministrados son otra opción que cumple todos los criterios enumerados, pero requieren mucho más mantenimiento manual. Para obtener más información, consulte [Mantenimiento de nodos por cuenta propia con nodos autoadministrados](worker.md).

**nota**  
Bottlerocket presenta algunas diferencias específicas con respecto a la información general de esta tabla. Para obtener más información, consulte la [documentación](https://github.com/bottlerocket-os/bottlerocket/blob/develop/README.md) de Bottlerocket en GitHub.


| Criterios | Grupos de nodos administrados por EKS | Modo automático de EKS | Nodos híbridos de Amazon EKS | 
| --- | --- | --- | --- | 
|  Se puede implementar en [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)   |  No  |  No  |  No  | 
|  Se puede implementar en [ zonas locales de AWS](local-zones.md).   |  Sí  |  No  |  No  | 
|  Puede ejecutar contenedores que requieren Windows  |  Sí  |  No  |  No  | 
|  Puede ejecutar contenedores que requieran Linux.  |  Sí  |  Sí  |  Sí  | 
|  Puede ejecutar cargas de trabajo que requieren el chip de inferencias.  |   [Sí](inferentia-support.md). Solo nodos de Amazon Linux.  |  Sí  |  No  | 
|  Puede ejecutar cargas de trabajo que requieren una GPU.  |   [Sí](eks-optimized-ami.md#gpu-ami). Solo nodos de Amazon Linux.  |  Sí  |  Sí  | 
|  Puede ejecutar cargas de trabajo que requieren procesadores Arm.  |   [Sí](eks-optimized-ami.md#arm-ami)   |  Sí  |  Sí  | 
|  Puede ejecutar AWS [Bottlerocket](https://aws.amazon.com/bottlerocket/).   |  Sí  |  Sí  |  No  | 
|  Los pods comparten CPU, memoria, almacenamiento y recursos de red con otros pods.  |  Sí  |  Sí  |  Sí  | 
|  Debe implementar y administrar instancias de Amazon EC2.  |  Sí  |  No, obtenga más información sobre las [instancias administradas por EC2](automode-learn-instances.md)   |  Sí, usted administra las máquinas virtuales o físicas en las instalaciones con las herramientas que elija.  | 
|  Debe proteger, mantener y aplicar parches al sistema operativo de las instancias de Amazon EC2.  |  Sí  |  No  |  Sí, usted administra el sistema operativo que se ejecuta en las máquinas virtuales o físicas con las herramientas que elija.  | 
|  Puede proporcionar argumentos de arranque en la implementación de un nodo, como argumentos [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) adicionales.  |  Sí, mediante `eksctl` o una [plantilla de lanzamiento](launch-templates.md) con una AMI personalizada.  |  No, [utilice `NodeClass` para configurar nodos](create-node-class.md)   |  Sí, puede personalizar los argumentos de arranque con nodeadm. Consulte [Referencia de `nodeadm` de nodos híbridos](hybrid-nodes-nodeadm.md).  | 
|  Puede asignar direcciones IP a pods desde un bloque de CIDR diferente de la dirección IP asignada al nodo.  |  Sí. Mediante una plantilla de lanzamiento con una AMI personalizada. Para obtener más información, consulte [Personalización de nodos administrados con plantillas de lanzamiento](launch-templates.md).  |  No  |  Sí, consulte [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md).  | 
|  Se puede utilizar SSH en el nodo.  |  Sí  |  No, [aprenda a solucionar problemas con los nodos](auto-troubleshoot.md)   |  Sí  | 
|  Puede implementar su propia AMI personalizada en los nodos.  |  Sí. Mediante una [plantilla de lanzamiento](launch-templates.md).   |  No  |  Sí  | 
|  Puede implementar su propia CNI personalizada en los nodos.  |  Sí. Mediante una [plantilla de lanzamiento](launch-templates.md) con una AMI personalizada.  |  No  |  Sí  | 
|  Debe actualizar la AMI de nodos por su cuenta  |   [Sí](update-managed-node-group.md): si ha implementado una AMI optimizada de Amazon EKS, recibirá una notificación en la consola de Amazon EKS cuando las actualizaciones estén disponibles. Puede realizar la actualización con un solo clic de en la consola. Si ha implementado una AMI personalizada, no recibirá una notificación en la consola de Amazon EKS cuando las actualizaciones estén disponibles. Debe realizar la actualización por su cuenta.  |  No  |  Sí, usted administra el sistema operativo que se ejecuta en las máquinas virtuales o físicas con las herramientas que elija. Consulte [Cómo preparar el sistema operativo para los nodos híbridos](hybrid-nodes-os.md).  | 
|  Debe actualizar la versión de Kubernetes de los nodos por su cuenta.  |   [Sí](update-managed-node-group.md): si ha implementado una AMI optimizada de Amazon EKS, recibirá una notificación en la consola de Amazon EKS cuando las actualizaciones estén disponibles. Puede realizar la actualización con un solo clic de en la consola. Si ha implementado una AMI personalizada, no recibirá una notificación en la consola de Amazon EKS cuando las actualizaciones estén disponibles. Debe realizar la actualización por su cuenta.  |  No  |  Sí, usted administra las actualizaciones de los nodos híbridos con las herramientas que elija o con `nodeadm`. Consulte [Actualización de nodos híbridos para el clúster](hybrid-nodes-upgrade.md).  | 
|  Puede utilizar el almacenamiento de Amazon EBS con pods.  |   [Sí](ebs-csi.md)   |  Sí, como una capacidad integrada. Aprenda a [crear una clase de almacenamiento](create-storage-class.md).   |  No  | 
|  Puede utilizar el almacenamiento de Amazon EFS con pods.  |   [Sí](efs-csi.md)   |  Sí  |  No  | 
|  Puede utilizar el almacenamiento de Amazon FSx para Lustre con pods.  |   [Sí](fsx-csi.md)   |  Sí  |  No  | 
|  Puede utilizar el Network Load Balancer para servicios.  |   [Sí](network-load-balancing.md)   |  Sí  |  Sí, debe usar el tipo de destino `ip`.  | 
|  Los pods pueden ejecutarse en una subred pública.  |  Sí  |  Sí  |  No, los pods se ejecutan en un entorno en las instalaciones.  | 
|  Puede asignar diferentes grupos de seguridad de VPC a pods individuales.  |   [Sí](security-groups-for-pods.md). Solo nodos de Linux.  |  No  |  No  | 
|  Puede ejecutar DaemonSets de Kubernetes.  |  Sí  |  Sí  |  Sí  | 
|  Soporte de `HostPort` y `HostNetwork` en el manifiesto del pod.  |  Sí  |  Sí  |  Sí  | 
|   Disponibilidad regional de AWS  |   [Todas las regiones admitidas por Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html)   |   [Todas las regiones admitidas por Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html)   |   [Todas las regiones compatibles con Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) excepto las regiones de AWS GovCloud (EE. UU.) y China.  | 
|  Puede ejecutar contenedores en hosts dedicados de Amazon EC2  |  Sí  |  No  |  No  | 
|  Precios  |  Costo de la instancia de Amazon EC2 que ejecuta varios pods. Para obtener más información, consulte [Precios de Amazon EC2](https://aws.amazon.com/ec2/pricing/).  |  Cuando el modo automático de EKS está habilitado en el clúster, se paga una tarifa aparte, además de las tarifas estándar de las instancias de EC2, correspondiente a las instancias lanzadas mediante la capacidad de computación del modo automático. El importe varía en función del tipo de instancia lanzada y de la región de AWS en la que se encuentre el clúster. Para obtener más información, consulte los [precios de Amazon EKS](https://aws.amazon.com/eks/pricing/).  |  Costo por hora de vCPU de nodos híbridos. Para obtener más información, consulte los [precios de Amazon EKS](https://aws.amazon.com/eks/pricing/).  | 

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

# Mantenimiento de nodos por cuenta propia con nodos autoadministrados
<a name="worker"></a>

Un clúster contiene uno o varios nodos de Amazon EC2 en los que están programados los pods. Los nodos de Amazon EKS se ejecutan en su cuenta de AWS y se conectan con el plano de control del clúster a través del punto de conexión del servidor de la API del clúster. Se le factura por ellos en función de los precios de Amazon EC2. Para obtener más información, consulte [Precios de Amazon EC2](https://aws.amazon.com/ec2/pricing/).

Un clúster puede contener varios grupos de nodos. Cada grupo de nodos contiene uno o varios nodos que se implementan en un [grupo de Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html). El tipo de instancia de los nodos del grupo puede variar; por ejemplo, cuando se utiliza [la selección del tipo de instancia basada en atributos](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html) con [Karpenter](https://karpenter.sh/). Todas las instancias de un grupo de nodos deben utilizar el [rol de IAM del nodo de Amazon EKS](create-node-role.md).

Amazon EKS proporciona imágenes de máquina de Amazon (AMI) especializadas que se denominan AMI optimizadas para Amazon EKS. Las AMI están configuradas para funcionar con Amazon EKS. Sus componentes incluyen `containerd`, `kubelet` y el Autenticador de AWS IAM. Las AMI también contienen un [script de arranque](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) especializado que permite detectar el plano de control del clúster y conectarse automáticamente a él.

Si restringe el acceso al punto de conexión público del clúster mediante bloques de CIDR, recomendamos habilitar también el acceso al punto de conexión privado. Esto permite que los nodos se puedan comunicar con el clúster. Si el punto de conexión privado no está habilitado, los bloques de CIDR que especifique para el acceso público deben incluir los orígenes de salida de su VPC. Para obtener más información, consulte [Punto de conexión del servidor de API del clúster](cluster-endpoint.md).

Para agregar nodos autoadministrados a su clúster de Amazon EKS, consulte los temas siguientes. Si lanza de forma manual nodos autoadministrados, debe agregar la siguiente etiqueta a cada nodo y asegurarse de que `<cluster-name>` coincida con el clúster. Para obtener más información, consulte [Cómo agregar etiquetas a un recurso individual y eliminarlas de él](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags). Si sigue los pasos de las siguientes guías, se agregará automáticamente la etiqueta necesaria a los nodos.


| Clave | Valor | 
| --- | --- | 
|   `kubernetes.io/cluster/<cluster-name>`   |   `owned`   | 

**importante**  
Las etiquetas del Servicio de metadatos de instancias (IMDS) de Amazon EC2 no son compatibles con los nodos de EKS. Cuando las etiquetas de metadatos de instancia están habilitadas, se impide el uso de barras diagonales (“/”) en los valores de las etiquetas. Esta limitación puede provocar errores en el lanzamiento de las instancias, especialmente cuando se utilizan herramientas de administración de nodos como Karpenter o el Escalador automático de clústeres, ya que estos servicios dependen de etiquetas que contienen barras diagonales para funcionar correctamente.

Para obtener más información sobre los nodos desde un punto de vista general de Kubernetes, consulte [Nodos](https://kubernetes.io/docs/concepts/architecture/nodes/) en la documentación de Kubernetes.

**Topics**
+ [Creación de nodos autoadministrados de Amazon Linux](launch-workers.md)
+ [Creación de nodos de Bottlerocket autoadministrados](launch-node-bottlerocket.md)
+ [Creación de nodos autoadministrados de Microsoft Windows](launch-windows-workers.md)
+ [Creación de nodos autoadministrados de Linux para Ubuntu](launch-node-ubuntu.md)
+ [Actualización de los nodos autoadministrados para un clúster](update-workers.md)

# Creación de nodos autoadministrados de Amazon Linux
<a name="launch-workers"></a>

En este tema, se describe cómo puede lanzar grupos de escalado automático de nodos de Linux que se registrará con el clúster de Amazon EKS. Una vez que los nodos se hayan unido al clúster, puede implementar aplicaciones de Kubernetes en ellos. También puede lanzar nodos de Amazon Linux autoadministrados con `eksctl` o la Consola de administración de AWS. Si necesita lanzar nodos en AWS Outposts, consulte [Creación de nodos de Amazon Linux en AWS Outposts](eks-outposts-self-managed-nodes.md).
+ Un clúster existente de Amazon EKS. Para implementar uno, consulte [Creación de un clúster de Amazon EKS](create-cluster.md). Si tiene subredes en la región de AWS, donde están habilitadas las subredes AWS Outposts, AWS Wavelength o AWS Local Zones, estas no se deben haber pasado al crear su clúster.
+ Un rol de IAM existente para que lo utilicen los nodos. Para crear uno, consulte [Rol de IAM de nodo de Amazon EKS](create-node-role.md). Si este rol no tiene ninguna de las políticas de la CNI de la VPC, es necesario el rol independiente que se indica a continuación para los pods de la CNI de la VPC.
+ (Opcional, pero recomendado) El complemento CNI de Amazon VPC para Kubernetes configurado con su propio rol de IAM que tenga adjunta la política de IAM necesaria. Para obtener más información, consulte [Configuración del complemento de CNI de Amazon VPC para utilizar IRSA](cni-iam-role.md).
+ Familiaridad con las consideraciones que se enumeran en [Elección de un tipo de instancia de nodo de Amazon EC2 óptimo](choosing-instance-type.md). Según el tipo de instancia que elija, es posible que haya requisitos previos adicionales para su clúster y VPC.

Puede lanzar nodos de Linux autoadministrados con una de las siguientes opciones:
+  [`eksctl`](#eksctl_create_managed_amazon_linux) 
+  [Consola de administración de AWS](#console_create_managed_amazon_linux) 

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

 **Lanzamiento de nodos de Linux autoadministrados mediante `eksctl` ** 

1. Instale la versión `0.215.0` o posterior de la herramienta de línea de comandos de `eksctl` instalada en su dispositivo o AWS CloudShell. Para instalar o actualizar `eksctl`, consulte la sección de [Instalación](https://eksctl.io/installation) en la documentación de `eksctl`.

1. (Opcional) Si la política de IAM administrada **AmazonEKS\$1CNI\$1Policy** se adjunta a su [rol de IAM de nodos de Amazon EKS](create-node-role.md), recomendamos asignarla a un rol de IAM asociado a la cuenta de servicio de `aws-node` de Kubernetes en su lugar. Para obtener más información, consulte [Configuración del complemento de CNI de Amazon VPC para utilizar IRSA](cni-iam-role.md).

1. El siguiente comando crea un grupo de nodos en un clúster existente. Sustituya *al-nodes* por un nombre para su grupo de nodos. El nombre del grupo de nodos no puede tener más de 63 caracteres. Debe empezar por una letra o un dígito, pero también puede incluir guiones y guiones bajos como caracteres no iniciales. Reemplace *my-cluster* por el nombre de su clúster. El nombre solo puede contener caracteres alfanuméricos (con distinción de mayúsculas y minúsculas) y guiones. Debe comenzar con un carácter alfanumérico y no puede tener más de 100 caracteres. El nombre debe ser único dentro de la región de AWS y la cuenta de AWS en las que va a crear el clúster. Sustituya los *valores de ejemplo* restantes por sus propios valores. Los nodos se crean de forma predeterminada con la misma versión de Kubernetes que el plano de control.

   Antes de elegir un valor de `--node-type`, consulte [Elección de un tipo de instancia de nodo de Amazon EC2 óptimo](choosing-instance-type.md).

   Reemplace *my-key* con el nombre de su par de claves de Amazon EC2 o la clave pública. Esta clave se utiliza para SSH en sus nodos después de que se lancen. Si aún no tiene un par de claves de Amazon EC2, puede crear uno en la Consola de administración de AWS. Para obtener más información, consulte [Pares de claves de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) en la *Guía del usuario de Amazon EC2*.

   Cree el grupo de nodos con el siguiente comando.
**importante**  
Si desea implementar un grupo de nodos en las subredes de AWS Outposts, Wavelength o zonas locales, existen consideraciones adicionales:  
Las subredes no deben haberse transferido al crear el clúster.
Debe crear el grupo de nodos con un archivo de configuración, que especifique las subredes y ` [volumeType](https://eksctl.io/usage/schema/#nodeGroups-volumeType): gp2`. Para obtener más información, consulte [Crear un grupo de nodos a partir de un archivo de Config](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) y el [Esquema de archivo de configuración](https://eksctl.io/usage/schema/) en la documentación de `eksctl`.

   ```
   eksctl create nodegroup \
     --cluster my-cluster \
     --name al-nodes \
     --node-type t3.medium \
     --nodes 3 \
     --nodes-min 1 \
     --nodes-max 4 \
     --ssh-access \
     --managed=false \
     --ssh-public-key my-key
   ```

   Para implementar un grupo de nodos que:
   + pueda asignar un número significativamente mayor de direcciones IP a pods que la configuración predeterminada, consulte [Asignación de más direcciones IP a los nodos de Amazon EKS con prefijos](cni-increase-ip-addresses.md).
   + pueda asignar direcciones `IPv4` a pods de un bloque de CIDR diferente que el de la instancia, consulte [Implementación de pods en subredes alternativas con redes personalizadas](cni-custom-network.md).
   + pueda asignar direcciones `IPv6` a los pods y los servicios, consulte [Información sobre la asignación de direcciones IPv6 a clústeres, pods y servicios](cni-ipv6.md).
   + no tenga acceso saliente a internet, consulte [Implementación de clústeres privados con acceso limitado a Internet](private-clusters.md).

     Para obtener una lista completa de todas las opciones y valores predeterminados disponibles, ingrese el siguiente comando.

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

     Si los nodos no se unen al clúster, consulte [Los nodos no pueden unirse al clúster](troubleshooting.md#worker-node-fail) en el capítulo de solución de problemas.

     Un ejemplo de salida sería el siguiente. Se generan varias líneas mientras se crean los nodos. Una de las últimas líneas de salida es la siguiente línea de ejemplo.

     ```
     [✔]  created 1 nodegroup(s) in cluster "my-cluster"
     ```

1. (Opcional) Implemente una [aplicación de muestra](sample-deployment.md) para probar el clúster y los nodos de Linux.

1. Se recomienda bloquear el acceso al pod a IMDS si se cumplen las siguientes condiciones:
   + Tiene previsto asignar roles de IAM a todas sus cuentas de servicio de Kubernetes para que los pods solo tengan los permisos mínimos que necesitan.
   + Ninguno de los pods del clúster requiere acceso al servicio de metadatos de instancias (IMDS) de Amazon EC2 por otros motivos, como la recuperación de la región de AWS actual.

   Para obtener más información, consulte [Restringir el acceso al perfil de instancias asignado al nodo de trabajo](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).

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

 **Paso 1: lanzamiento de nodos de Linux autoadministrados mediante la Consola de administración de AWS ** 

1. Descargue la versión más reciente de la plantilla de AWS CloudFormation.

   ```
   curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2025-11-26/amazon-eks-nodegroup.yaml
   ```

1. Espere a que el estado del clúster sea `ACTIVE`. Si lanza los nodos antes de que el clúster esté activo, los nodos no pueden registrarse con el clúster y tendrá que volver a lanzarlos.

1. Abra la [AWS consola de CloudFormation](https://console.aws.amazon.com/cloudformation/).

1. Seleccione **Create stack (Crear pila)** y, a continuación, seleccione **With new resources (standard) (Con nuevos recursos [estándar])**.

1. Para **Especificar plantilla**, seleccione **Cargar un archivo de plantilla** y, a continuación, elija **Elegir archivo**.

1. Edite el archivo `amazon-eks-nodegroup.yaml` que ha descargado.

1. Seleccione **Siguiente**.

1. En la página **Especificar detalles de la pila**, ingrese los siguientes parámetros según corresponda y luego seleccione **Siguiente**:
   +  **Nombre de pila**: elija un nombre para su pila de AWS CloudFormation. Por ejemplo, puede llamarla *my-cluster-nodes*. El nombre solo puede contener caracteres alfanuméricos (con distinción de mayúsculas y minúsculas) y guiones. Debe comenzar con un carácter alfanumérico y no puede tener más de 100 caracteres. El nombre debe ser único dentro de la región de AWS y la cuenta de AWS en las que va a crear el clúster.
   +  **ClusterName**: ingrese el nombre que usó al crear el clúster de Amazon EKS. Este nombre debe coincidir con el nombre del clúster o los nodos no se podrán unir al clúster.
   +  **ClusterControlPlaneSecurityGroup**: elija el valor de **SecurityGroups** de la salida de AWS CloudFormation que generó al crear su [VPC](creating-a-vpc.md).

     En los siguientes pasos, se muestra una operación para recuperar el grupo aplicable.

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

     1. Elija el nombre del clúster.

     1. Elija la pestaña **Redes**.

     1. Use el valor de **Grupo de seguridad adicional** como referencia al realizar una selección en la lista desplegable **ClusterControlPlaneSecurityGroup**.
   +  **ApiServerEndpoint**: ingrese el punto de conexión del servidor de API para el clúster de EKS. Puede consultarlo en la sección Detalles de la consola de Clústeres de EKS.
   +  **CertificateAuthorityData**: ingrese los datos de la autoridad de certificación codificados en base64, que también se encuentran en la sección Detalles de la consola de Clústeres de EKS.
   +  **ServiceCidr**: ingrese el rango CIDR que se usó para asignar las direcciones IP a los servicios de Kubernetes en el clúster. Se encuentra en la pestaña Redes de la consola de Clústeres de EKS.
   +  **AuthenticationMode**: para seleccionar el modo de autenticación que se usa en el clúster de EKS, consulte la pestaña de acceso en la consola de Clústeres de EKS.
   +  **NodeGroupName**: escriba un nombre para el grupo de nodos. Este nombre se puede utilizar más adelante para identificar el grupo de nodos de escalado automático que se crea para los nodos. El nombre del grupo de nodos no puede tener más de 63 caracteres. Debe empezar por una letra o un dígito, pero también puede incluir guiones y guiones bajos como caracteres no iniciales.
   +  **NodeAutoScalingGroupMinSize**: ingrese el número mínimo de nodos al que se puede reducir horizontalmente el grupo de escalado automático de nodos.
   +  **NodeAutoScalingGroupDesiredCapacity**: escriba el número deseado de nodos que desea escalar cuando se crea la pila.
   +  **NodeAutoScalingGroupMaxSize**: ingrese el número máximo de nodos que pueda alcanzar el grupo de Auto Scaling de nodos.
   +  **NodeInstanceType**: elija un tipo de instancia para los nodos. Para obtener más información, consulte [Elección de un tipo de instancia de nodo de Amazon EC2 óptimo](choosing-instance-type.md).
   +  **NodeImageIdSSMParam**: se rellena previamente con el parámetro de Amazon EC2 Systems Manager de una AMI de Amazon Linux 2023 optimizada recientemente para Amazon EKS para una versión de Kubernetes variable. Para utilizar otra versión secundaria de Kubernetes compatible con Amazon EKS, reemplace *1.XX* por una [versión admitida](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) diferente. Recomendamos especificar la misma versión de Kubernetes que el clúster.

     También puede sustituir *amazon-linux-2023* por un tipo de AMI diferente. Para obtener más información, consulte [Obtención de los ID de AMI de Amazon Linux recomendados](retrieve-ami-id.md).
**nota**  
Las AMI de los nodos de Amazon EKS se basan en Amazon Linux. Puede realizar un seguimiento de los eventos de seguridad o privacidad de Amazon Linux 2023 en el [Centro de seguridad de Amazon Linux](https://alas.aws.amazon.com/alas2023.html) o suscribirse a la [fuente RSS](https://alas.aws.amazon.com/AL2023/alas.rss) asociada. Los eventos de seguridad y privacidad incluyen información general del problema, qué paquetes están afectados y cómo actualizar las instancias para corregir el problema.
   +  **NodeImageId**: (opcional) si utiliza una AMI personalizada propia (en lugar de una AMI optimizada para Amazon EKS), escriba un ID de AMI de nodo para la región de AWS. Si especifica un valor aquí, anula cualquier valor del campo **NodeImageIdSSMParam**.
   +  **NodeVolumeSize**: especifique un tamaño de volumen raíz para los nodos en GiB.
   +  **NodeVolumeType**: especifique un tipo de volumen raíz para sus nodos.
   +  **KeyName**: ingrese el nombre de un par de claves SSH de Amazon EC2 que pueda utilizar para conectar mediante SSH con los nodos después de haberlos lanzado. Si aún no tiene un par de claves de Amazon EC2, puede crear uno en la Consola de administración de AWS. Para obtener más información, consulte [Pares de claves de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) en la *Guía del usuario de Amazon EC2*.
   +  **VpcId**: ingrese el ID de la [VPC](creating-a-vpc.md) que ha creado.
   +  **Subredes**: elija las subredes que creó para la VPC. Si creó la VPC siguiendo los pasos que se describen en [Creación de una Amazon VPC para su clúster de Amazon EKS](creating-a-vpc.md), especifique solo las subredes privadas en la VPC en las que desea lanzar los nodos. Puede ver qué subredes son privadas abriendo cada enlace de subred desde la pestaña **Redes** de su clúster.
**importante**  
Si alguna de las subredes es pública, debe tener habilitada la configuración de asignación automática de direcciones IP públicas. Si la configuración no está habilitada para la subred pública, los nodos que implemente en dicha subred pública no tendrán asignada una dirección IP pública y no podrán comunicarse con el clúster u otros servicios de AWS. Si la subred se implementó antes del 26 de marzo de 2020 mediante cualquiera de las [plantillas de VPC de AWS CloudFormation de Amazon EKS](creating-a-vpc.md) o mediante `eksctl`, la asignación automática de direcciones IP públicas se deshabilitará en las subredes públicas. Para obtener información acerca de cómo habilitar la asignación de direcciones IP públicas en una subred, consulte [Modificación del atributo de direcciones IPv4 públicas de su subred](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip). Si el nodo se implementa en una subred privada, podrá comunicarse con el clúster y otros servicios de AWS a través de una puerta de enlace NAT.
Si las subredes no tienen acceso a Internet, asegúrese de que conoce las consideraciones y los pasos adicionales en [Implementación de clústeres privados con acceso limitado a Internet](private-clusters.md).
Si selecciona las subredes de AWS Outposts, Wavelength o zonas locales, las subredes no se deben haber pasado cuando creó el clúster.

1. Seleccione las opciones que desee en la página **Configurar las opciones de pila** y, a continuación, elija **Siguiente**.

1. Seleccione la casilla de verificación a la izquierda de **Reconozco que AWS podría crear recursos de IAM** y, luego, seleccione **Crear pila**.

1. Una vez completada la creación de la pila, selecciónela en la consola y elija **Salidas**. Si utiliza los modos de autenticación `EKS API` o `EKS API and ConfigMap`, este es el último paso.

1. Si utiliza el modo de autenticación `ConfigMap`, registre el valor de **NodeInstanceRole** correspondiente al grupo de nodos que se creó.

 **Paso 2: habilitación para que los nodos se unan al clúster** 

**nota**  
Los dos pasos siguientes solo son necesarios si se utiliza el modo de autenticación ConfigMap en el clúster de EKS. Además, si ha lanzado nodos dentro de una VPC privada sin acceso a Internet saliente, asegúrese de activar los nodos para que se unan al clúster desde dentro de la VPC.

1. Verifique si ya tiene el `ConfigMap` de `aws-auth`.

   ```
   kubectl describe configmap -n kube-system aws-auth
   ```

1. Si se le muestra un `ConfigMap` de `aws-auth`, actualícelo según sea necesario.

   1. Abra el icono `ConfigMap` para editar.

      ```
      kubectl edit -n kube-system configmap/aws-auth
      ```

   1. Añada una nueva entrada de `mapRoles` según sea necesario. Establezca el valor de `rolearn` en el valor de **NodeInstanceRole** que registró en el procedimiento anterior.

      ```
      [...]
      data:
        mapRoles: |
          - rolearn: <ARN of instance role (not instance profile)>
            username: system:node:{{EC2PrivateDNSName}}
            groups:
              - system:bootstrappers
              - system:nodes
      [...]
      ```

   1. Guarde el archivo y salga del editor de texto.

1. Si recibe un error que indica “`Error from server (NotFound): configmaps "aws-auth" not found`, aplique el `ConfigMap` bursátil.

   1. Descargue el mapa de configuración.

      ```
      curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml
      ```

   1. En el archivo `aws-auth-cm.yaml`, establezca el valor de `rolearn` al valor **NodeInstanceRole** que ha registrado en el procedimiento anterior. Puede hacerlo con un editor de texto o al reemplazar *my-node-instance-role* y ejecutar el siguiente comando:

      ```
      sed -i.bak -e 's|<ARN of instance role (not instance profile)>|my-node-instance-role|' aws-auth-cm.yaml
      ```

   1. Aplique la configuración. Este comando puede tardar varios minutos en finalizar.

      ```
      kubectl apply -f aws-auth-cm.yaml
      ```

1. Observe el estado de los nodos y espere a que aparezca el estado `Ready`.

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

   Ingrese `Ctrl`\$1`C` para obtener un símbolo del intérprete de comandos.
**nota**  
Si recibe cualquier error de tipo de recurso o autorización, consulte [Acceso denegado o no autorizado (`kubectl`)](troubleshooting.md#unauthorized) en el tema de solución de problemas.

   Si los nodos no se unen al clúster, consulte [Los nodos no pueden unirse al clúster](troubleshooting.md#worker-node-fail) en el capítulo de solución de problemas.

1. (Solo para nodos de GPU) Si ha elegido un tipo de instancia de GPU y la AMI acelerada optimizada para Amazon EKS, debe aplicar el [complemento de dispositivo NVIDIA para Kubernetes](https://github.com/NVIDIA/k8s-device-plugin) como un DaemonSet en el clúster. Reemplace *vX.X.X* con la versión [NVIDIA/k8s-device-plugin](https://github.com/NVIDIA/k8s-device-plugin/releases) deseada antes de ejecutar el siguiente comando.

   ```
   kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X.X/deployments/static/nvidia-device-plugin.yml
   ```

 **Paso 3: acciones adicionales** 

1. (Opcional) Implemente una [aplicación de muestra](sample-deployment.md) para probar el clúster y los nodos de Linux.

1. (Opcional) Si la política de IAM administrada **AmazonEKS\$1CNI\$1Policy** (si tiene un clúster `IPv4`) o la política *AmazonEKS\$1CNI\$1IPv6\$1Policy* (que [haya creado](cni-iam-role.md#cni-iam-role-create-ipv6-policy) si tiene un clúster `IPv6`) están adjuntas a su [rol de IAM de nodos en Amazon EKS](create-node-role.md), le recomendamos asignarlas a un rol de IAM que asocie a la cuenta de servicio de `aws-node` de Kubernetes como alternativa. Para obtener más información, consulte [Configuración del complemento de CNI de Amazon VPC para utilizar IRSA](cni-iam-role.md).

1. Se recomienda bloquear el acceso al pod a IMDS si se cumplen las siguientes condiciones:
   + Tiene previsto asignar roles de IAM a todas sus cuentas de servicio de Kubernetes para que los pods solo tengan los permisos mínimos que necesitan.
   + Ninguno de los pods del clúster requiere acceso al servicio de metadatos de instancias (IMDS) de Amazon EC2 por otros motivos, como la recuperación de la región de AWS actual.

   Para obtener más información, consulte [Restringir el acceso al perfil de instancias asignado al nodo de trabajo](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).

# Creación de nodos de Bottlerocket autoadministrados
<a name="launch-node-bottlerocket"></a>

**nota**  
Los grupos de nodos administrados podrían ofrecer algunas ventajas para su caso de uso. Para obtener más información, consulte [Simplificación del ciclo de vida de los nodos con grupos de nodos administrados](managed-node-groups.md).

En este tema, se describe cómo puede lanzar un grupo de escalado automático de nodos de [Bottlerocket](https://aws.amazon.com/bottlerocket/) que se registrará con el clúster de Amazon EKS. Bottlerocket es un sistema operativo de código abierto basado en Linux de AWS que puede utilizar para ejecutar contenedores en máquinas virtuales o hosts bare metal. Una vez que los nodos se hayan unido al clúster, puede implementar aplicaciones de Kubernetes en ellos. Para obtener más información acerca de Bottlerocket, consulte [Uso de una AMI de Bottlerocket con Amazon EKS](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-EKS.md) en GitHub y [Compatibilidad con AMI personalizada](https://eksctl.io/usage/custom-ami-support/) en la documentación de `eksctl`.

Para obtener información sobre actualizaciones en contexto, consulte [Operador de actualización de Bottlerocket](https://github.com/bottlerocket-os/bottlerocket-update-operator) en GitHub.

**importante**  
Los nodos de Amazon EKS son instancias estándar de Amazon EC2 y se les facturarán conforme a los precios ordinarios de las instancias de Amazon EC2. Para obtener más información, consulte [Precios de Amazon EC2](https://aws.amazon.com/ec2/pricing/).
Puede lanzar nodos de Bottlerocket en clústeres extendidos de Amazon EKS en AWS Outposts, pero no puede lanzarlos en clústeres locales en AWS Outposts. Para obtener más información, consulte [Implementación de Amazon EKS en las instalaciones con AWS Outposts](eks-outposts.md).
Puede implementar en instancias de Amazon EC2 con procesadores `x86` o Arm. Sin embargo, no puede implementar en instancias que tienen chips Inferentia.
Bottlerocket es compatible con AWS CloudFormation. Sin embargo, no existe ninguna plantilla oficial de CloudFormation que pueda copiarse para implementar nodos de Bottlerocket para Amazon EKS.
Las imágenes de Bottlerocket no vienen con un servidor SSH ni un intérprete de comandos. Puede utilizar métodos de acceso fuera de banda para permitir que SSH habilite el contenedor de administración y superar algunos pasos de configuración de arranque con datos de usuario. Para obtener más información, consulte estas secciones en [bottlerocket README.md](https://github.com/bottlerocket-os/bottlerocket) en GitHub:  
 [Exploration (Exploración](https://github.com/bottlerocket-os/bottlerocket#exploration) 
 [Contenedor de administrador](https://github.com/bottlerocket-os/bottlerocket#admin-container) 
 [Configuración de Kubernetes](https://github.com/bottlerocket-os/bottlerocket#kubernetes-settings) 

En este procedimiento, se requiere la versión `0.215.0` o posterior de `eksctl`. Puede verificar la versión con el siguiente comando:

```
eksctl version
```

Para obtener instrucciones acerca de cómo instalar o actualizar `eksctl`, consulte [Instalación](https://eksctl.io/installation) en la documentación de `eksctl`. NOTA: Este procedimiento solo funciona en los clústeres que se crearon con `eksctl`.

1. Copie los siguientes contenidos en su dispositivo. Reemplace *my-cluster* por el nombre de su clúster. El nombre solo puede contener caracteres alfanuméricos (con distinción de mayúsculas y minúsculas) y guiones. Debe comenzar con un carácter alfanumérico y no puede tener más de 100 caracteres. El nombre debe ser único dentro de la región de AWS y la cuenta de AWS en las que va a crear el clúster. Reemplace *ng-bottlerocket* por un nombre para su grupo de nodos. El nombre del grupo de nodos no puede tener más de 63 caracteres. Debe empezar por una letra o un dígito, pero también puede incluir guiones y guiones bajos como caracteres no iniciales. Para implementar en instancias Arm, reemplace *m5.large* por un tipo de instancia Arm. Sustituya *my-ec2-keypair-name* por el nombre de un par de claves SSH de Amazon EC2 que pueda utilizar para conectar mediante SSH con los nodos después de haberlos lanzado. Si aún no tiene un par de claves de Amazon EC2, puede crear uno en la Consola de administración de AWS. Para obtener más información, consulte [Pares de claves de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) en la *Guía del usuario de Amazon EC2*. Sustituya todos los valores de ejemplo restantes por sus propios valores. Una vez que haya llevado a cabo las sustituciones, ejecute el comando modificado para crear el archivo `bottlerocket.yaml`.

   Si especifica un tipo de instancia Arm de Amazon EC2, revise las consideraciones en [AMI de Amazon Linux optimizada para Amazon EKS Arm](eks-optimized-ami.md#arm-ami) antes de llevar a cabo la implementación. Para ver instrucciones sobre cómo implementar mediante una AMI personalizada, consulte [Creación de Bottlerocket](https://github.com/bottlerocket-os/bottlerocket/blob/develop/BUILDING.md) en GitHub y [Compatibilidad con AMI personalizada](https://eksctl.io/usage/custom-ami-support/) en la documentación de `eksctl`. Para implementar un grupo de nodos administrados, implemente una AMI personalizada mediante el uso de una plantilla de lanzamiento. Para obtener más información, consulte [Personalización de nodos administrados con plantillas de lanzamiento](launch-templates.md).
**importante**  
Para implementar un grupo de nodos en las subredes de AWS Outposts, AWS Wavelength o zonas locales de AWS, no pase las subredes de AWS Outposts, AWS Wavelength o Zonas locales de AWS al crear el clúster. Debe especificar las subredes en el siguiente ejemplo. Para obtener más información, consulte [Crear un grupo de nodos a partir de un archivo de Config](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) y el [Esquema de archivo de configuración](https://eksctl.io/usage/schema/) en la documentación de `eksctl`. Reemplace *region-code* por la región de AWS en la que se encuentra el clúster.

   ```
   cat >bottlerocket.yaml <<EOF
   ---
   apiVersion: eksctl.io/v1alpha5
   kind: ClusterConfig
   
   metadata:
     name: my-cluster
     region: region-code
     version: '1.35'
   
   iam:
     withOIDC: true
   
   nodeGroups:
     - name: ng-bottlerocket
       instanceType: m5.large
       desiredCapacity: 3
       amiFamily: Bottlerocket
       ami: auto-ssm
       iam:
          attachPolicyARNs:
             - arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
             - arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
             - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
             - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
       ssh:
           allow: true
           publicKeyName: my-ec2-keypair-name
   EOF
   ```

1. Implemente los nodos con el siguiente comando.

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

   Un ejemplo de salida sería el siguiente.

   Se generan varias líneas mientras se crean los nodos. Una de las últimas líneas de salida es la siguiente línea de ejemplo.

   ```
   [✔]  created 1 nodegroup(s) in cluster "my-cluster"
   ```

1. (Opcional) Cree un [volumen persistente](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) de Kubernetes en un nodo de Bottlerocket mediante el [Complemento CSI de Amazon EBS](https://github.com/kubernetes-sigs/aws-ebs-csi-driver). El controlador predeterminado de Amazon EBS se basa en herramientas del sistema de archivos que no están incluidas en Bottlerocket. Para obtener información adicional acerca de cómo crear una clase de almacenamiento mediante un controlador, consulte [Uso del almacenamiento de volúmenes de Kubernetes con Amazon EBS](ebs-csi.md).

1. (Opcional) De forma predeterminada, `kube-proxy` establece el parámetro del kernel `nf_conntrack_max` en un valor predeterminado que puede diferir de lo que Bottlerocket establece inicialmente en el arranque. Para mantener la [configuración predeterminada](https://github.com/bottlerocket-os/bottlerocket-core-kit/blob/develop/packages/release/release-sysctl.conf) de Bottlerocket, edite la configuración de `kube-proxy` con el siguiente comando.

   ```
   kubectl edit -n kube-system daemonset kube-proxy
   ```

   Agregue `--conntrack-max-per-core` y `--conntrack-min` a los argumentos `kube-proxy` que se encuentran en el siguiente ejemplo. Una configuración de `0` implica que no hay cambios.

   ```
         containers:
         - command:
           - kube-proxy
           - --v=2
           - --config=/var/lib/kube-proxy-config/config
           - --conntrack-max-per-core=0
           - --conntrack-min=0
   ```

1. (Opcional) Implemente una [aplicación de muestra](sample-deployment.md) para probar los nodos de Bottlerocket.

1. Se recomienda bloquear el acceso al pod a IMDS si se cumplen las siguientes condiciones:
   + Tiene previsto asignar roles de IAM a todas sus cuentas de servicio de Kubernetes para que los pods solo tengan los permisos mínimos que necesitan.
   + Ninguno de los pods del clúster requiere acceso al servicio de metadatos de instancias (IMDS) de Amazon EC2 por otros motivos, como la recuperación de la región de AWS actual.

   Para obtener más información, consulte [Restringir el acceso al perfil de instancias asignado al nodo de trabajo](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).

# Creación de nodos autoadministrados de Microsoft Windows
<a name="launch-windows-workers"></a>

Este tema describe cómo lanzar un grupo de Auto Scaling de nodos de Windows que se registrará con el clúster de Amazon EKS. Una vez que los nodos se hayan unido al clúster, puede implementar aplicaciones de Kubernetes en ellos.

**importante**  
Los nodos de Amazon EKS son instancias estándar de Amazon EC2 y se le facturarán conforme a los precios ordinarios de las instancias de Amazon EC2. Para obtener más información, consulte [Precios de Amazon EC2](https://aws.amazon.com/ec2/pricing/).
Puede lanzar nodos de Windows en clústeres extendidos de Amazon EKS en AWS Outposts, pero no puede lanzarlos en clústeres locales en AWS Outposts. Para obtener más información, consulte [Implementación de Amazon EKS en las instalaciones con AWS Outposts](eks-outposts.md).

Habilite la compatibilidad con Windows para su clúster Recomendamos que revise las consideraciones importantes antes de lanzar un grupo de nodos de Windows. Para obtener más información, consulte [Habilitación de la compatibilidad con Windows](windows-support.md#enable-windows-support).

Puede lanzar nodos de Windows autoadministrados con una de las siguientes opciones:
+  [`eksctl`](#eksctl_create_windows_nodes) 
+  [Consola de administración de AWS](#console_create_windows_nodes) 

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

 **Lanzamiento de nodos de Windows autoadministrados mediante `eksctl` ** 

En este procedimiento, se presupone que ha instalado `eksctl` y que su versión de `eksctl` es al menos `0.215.0`. Puede verificar la versión con el siguiente comando.

```
eksctl version
```

Para obtener instrucciones sobre cómo instalar o actualizar `eksctl`, consulte [Instalación](https://eksctl.io/installation) en la documentación de `eksctl`.

**nota**  
Este procedimiento solo es válido para los clústeres que se crearon con `eksctl`.

1. (Opcional) Si la política de IAM administrada **AmazonEKS\$1CNI\$1Policy** (si tiene un clúster `IPv4`) o la política *AmazonEKS\$1CNI\$1IPv6\$1Policy* (que [haya creado](cni-iam-role.md#cni-iam-role-create-ipv6-policy) si tiene un clúster `IPv6`) están adjuntas a su [rol de IAM de nodos en Amazon EKS](create-node-role.md), le recomendamos asignarlas, en cambio, a un rol de IAM que asocie a la cuenta de servicio de `aws-node` de Kubernetes. Para obtener más información, consulte [Configuración del complemento de CNI de Amazon VPC para utilizar IRSA](cni-iam-role.md).

1. En este procedimiento, se presupone que dispone de un clúster existente. Si aún no tiene un clúster de Amazon EKS ni un grupo de nodos de Amazon Linux al cual agregarle un grupo de nodos de Windows, le recomendamos que siga la [Introducción a Amazon EKS: `eksctl`](getting-started-eksctl.md). En esta guía se proporciona una explicación completa para crear un clúster de Amazon EKS con nodos de Amazon Linux.

   Cree el grupo de nodos con el siguiente comando. Reemplace *region-code* por la región de AWS en la que se encuentra el clúster. Sustituya *my-cluster* por el nombre del clúster. El nombre solo puede contener caracteres alfanuméricos (con distinción de mayúsculas y minúsculas) y guiones. Debe comenzar con un carácter alfanumérico y no puede tener más de 100 caracteres. El nombre debe ser único dentro de la región de AWS y la cuenta de AWS en las que va a crear el clúster. Reemplace *ng-windows* por un nombre para su grupo de nodos. El nombre del grupo de nodos no puede tener más de 63 caracteres. Debe empezar por una letra o un dígito, pero también puede incluir guiones y guiones bajos como caracteres no iniciales. Puede reemplazar *2019* por `2022` para usar Windows Server 2022 o por `2025` para usar Windows Server 2025. Sustituya el resto de los valores de ejemplo por sus propios valores.
**importante**  
Para implementar un grupo de nodos en las subredes de AWS Outposts, AWS Wavelength o zonas locales de AWS, no pase las subredes de AWS Outposts, Wavelength o zonas locales al crear el clúster. Cree el grupo de nodos con un archivo de configuración, que especifique las subredes de AWS Outposts, Wavelength o Local Zone. Para obtener más información, consulte [Crear un grupo de nodos a partir de un archivo de Config](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) y el [Esquema de archivo de configuración](https://eksctl.io/usage/schema/) en la documentación de `eksctl`.

   ```
   eksctl create nodegroup \
       --region region-code \
       --cluster my-cluster \
       --name ng-windows \
       --node-type t2.large \
       --nodes 3 \
       --nodes-min 1 \
       --nodes-max 4 \
       --managed=false \
       --node-ami-family WindowsServer2019FullContainer
   ```
**nota**  
Si los nodos no se unen al clúster, consulte [Los nodos no pueden unirse al clúster](troubleshooting.md#worker-node-fail) en la Guía de solución de problemas.
Para ver las opciones disponibles para los comandos `eksctl`, ingrese el siguiente comando.  

     ```
     eksctl command -help
     ```

   Un ejemplo de salida sería el siguiente. Se generan varias líneas mientras se crean los nodos. Una de las últimas líneas de salida es la siguiente línea de ejemplo.

   ```
   [✔]  created 1 nodegroup(s) in cluster "my-cluster"
   ```

1. (Opcional) Implemente una [aplicación de muestra](sample-deployment.md) para probar el clúster y los nodos de Windows.

1. Se recomienda bloquear el acceso al pod a IMDS si se cumplen las siguientes condiciones:
   + Tiene previsto asignar roles de IAM a todas sus cuentas de servicio de Kubernetes para que los pods solo tengan los permisos mínimos que necesitan.
   + Ninguno de los pods del clúster requiere acceso al servicio de metadatos de instancias (IMDS) de Amazon EC2 por otros motivos, como la recuperación de la región de AWS actual.

   Para obtener más información, consulte [Restringir el acceso al perfil de instancias asignado al nodo de trabajo](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).

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

 **Requisitos previos** 
+ Un clúster de Amazon EKS existente y un grupo de nodos de Linux. Si no tiene estos recursos, recomendamos que siga una de nuestras guías de para crearlos [Introducción a Amazon EKS](getting-started.md). En las guías se describe cómo crear un clúster de Amazon EKS con nodos de Linux.
+ Una VPC y un grupo de seguridad existentes que cumplen los requisitos para un clúster de Amazon EKS. Para obtener más información, consulte [Requisitos de red de Amazon EKS para VPC y subredes](network-reqs.md) y [Revisión de requisitos de grupos de seguridad de Amazon EKS para clústeres](sec-group-reqs.md). Las guías de [Introducción a Amazon EKS](getting-started.md) crean una VPC que cumple los requisitos. Si lo desea, también puede seguir [Creación de una Amazon VPC para su clúster de Amazon EKS](creating-a-vpc.md) para crear una manualmente.
+ Un clúster de Amazon EKS existente que utiliza una VPC y un grupo de seguridad que cumplen los requisitos de un clúster de Amazon EKS. Para obtener más información, consulte [Creación de un clúster de Amazon EKS](create-cluster.md). Si tiene subredes en la región de AWS, donde están habilitadas las subredes AWS Outposts, AWS Wavelength o zonas locales de AWS, estas no se deben haber pasado al crear el clúster.

 **Paso 1: lanzar nodos de Windows autoadministrados mediante la Consola de administración de AWS ** 

1. Espere a que el estado del clúster sea `ACTIVE`. Si lanza los nodos antes de que el clúster esté activo, los nodos no pueden registrarse con el clúster y debe volver a lanzarlos.

1. Abra la [consola de AWS CloudFormation](https://console.aws.amazon.com/cloudformation/) 

1. Elija **Crear pila**.

1. En **Especificar plantilla**, seleccione **URL de Amazon S3**.

1. Copie la siguiente URL y péguela en la **URL de Amazon S3**.

   ```
   https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2023-02-09/amazon-eks-windows-nodegroup.yaml
   ```

1. Seleccione **Siguiente** dos veces.

1. En la página **Creación rápida de pila**, ingrese los siguientes parámetros según corresponda:
   +  **Nombre de pila**: elija un nombre para su pila de AWS CloudFormation. Por ejemplo, puede llamarla `my-cluster-nodes`.
   +  **ClusterName**: ingrese el nombre que usó al crear el clúster de Amazon EKS.
**importante**  
El nombre debe coincidir exactamente con el nombre que utilizó en el [Paso 1: Creación del clúster de Amazon EKS](getting-started-console.md#eks-create-cluster). De lo contrario, los nodos no podrán unirse al clúster.
   +  **ClusterControlPlaneSecurityGroup**: elija el grupo de seguridad de la salida de AWS CloudFormation que generó al crear la [VPC](creating-a-vpc.md). En los pasos siguientes se muestra un método para recuperar el grupo aplicable.

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

     1. Elija el nombre del clúster.

     1. Elija la pestaña **Redes**.

     1. Use el valor de **Grupo de seguridad adicional** como referencia al realizar una selección en la lista desplegable **ClusterControlPlaneSecurityGroup**.
   +  **NodeGroupName**: escriba un nombre para el grupo de nodos. Este nombre se puede utilizar más adelante para identificar el grupo de nodos de escalado automático que se crea para los nodos. El nombre del grupo de nodos no puede tener más de 63 caracteres. Debe empezar por una letra o un dígito, pero también puede incluir guiones y guiones bajos como caracteres no iniciales.
   +  **NodeAutoScalingGroupMinSize**: ingrese el número mínimo de nodos al que se puede reducir horizontalmente el grupo de escalado automático de nodos.
   +  **NodeAutoScalingGroupDesiredCapacity**: escriba el número deseado de nodos que desea escalar cuando se crea la pila.
   +  **NodeAutoScalingGroupMaxSize**: ingrese el número máximo de nodos que pueda alcanzar el grupo de Auto Scaling de nodos.
   +  **NodeInstanceType**: elija un tipo de instancia para los nodos. Para obtener más información, consulte [Elección de un tipo de instancia de nodo de Amazon EC2 óptimo](choosing-instance-type.md).
**nota**  
Los tipos de instancias compatibles con la versión más reciente del [complemento CNI de Amazon VPC para Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) se muestran en [vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go) en GitHub. Es posible que tenga que actualizar la versión de CNI para utilizar los tipos de instancia admitidos más recientes. Para obtener más información, consulte [Asignación de direcciones IP a pods con CNI de Amazon VPC](managing-vpc-cni.md).
   +  **NodeImageIdSSMParam**: contiene un valor especificado previamente, que es el parámetro de Amazon EC2 Systems Manager del ID de la AMI de Windows Core optimizada para Amazon EKS más reciente recomendada. Para utilizar la versión completa de Windows, sustituya *Core* por `Full`.
   +  **NodeImageId**: (opcional) si utiliza una AMI personalizada propia (en lugar de una AMI optimizada para Amazon EKS), escriba un ID de AMI de nodo para la región de AWS. Si especifica un valor para este campo, anula cualquier valor del campo **NodeImageIdSSMParam**.
   +  **NodeVolumeSize**: especifique un tamaño de volumen raíz para los nodos en GiB.
   +  **KeyName**: ingrese el nombre de un par de claves SSH de Amazon EC2 que pueda utilizar para conectar mediante SSH con los nodos después de haberlos lanzado. Si aún no tiene un par de claves de Amazon EC2, puede crear uno en la Consola de administración de AWS. Para obtener más información, consulte [Pares de claves de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html) en la *Guía del usuario de Amazon EC2*.
**nota**  
Si no proporciona un par de claves aquí, se produce un error al crear la pila de AWS CloudFormation.
   +  **BootstrapArguments**: especifique los argumentos opcionales que se van a pasar al script de arranque del nodo, como los argumentos de `kubelet` adicionales mediante `-KubeletExtraArgs`.
   +  **DisableIMDSv1**: cada nodo admite de forma predeterminada la versión 1 (IMDSv1) e IMDSv2 del servicio de metadatos de la instancia. Puede desactivar IMDSv1. Para evitar que los nodos y pods futuros del grupo de nodos utilicen MDSv1, defina **DisableIMDSv1** en **verdadero**. Para obtener más información, consulte [Configurar el servicio de metadatos de instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html).
   +  **VpcId**: seleccione el ID de la [VPC](creating-a-vpc.md) que creó.
   +  **NodeSecurityGroups**: seleccione el grupo de seguridad que se creó para su grupo de nodos de Linux cuando creó la [VPC](creating-a-vpc.md). Si sus nodos de Linux tienen más de un grupo de seguridad adjuntado a ellos, especifíquelos a todos aquí. Esto, por ejemplo, si el grupo de nodos Linux se creó con `eksctl`.
   +  **Subredes**: elija las subredes que creó. Si creó la VPC siguiendo los pasos que se describen en [Creación de Amazon VPC para su clúster de Amazon EKS](creating-a-vpc.md), especifique solo las subredes privadas en la VPC en las que desea lanzar los nodos.
**importante**  
Si alguna de las subredes es pública, debe tener habilitada la configuración de asignación automática de direcciones IP públicas. Si la configuración no está habilitada para la subred pública, los nodos que implemente en dicha subred pública no tendrán asignada una dirección IP pública y no podrán comunicarse con el clúster u otros servicios de AWS. Si la subred se implementó antes del 26 de marzo de 2020 mediante cualquiera de las [plantillas de VPC de AWS CloudFormation de Amazon EKS](creating-a-vpc.md) o mediante `eksctl`, la asignación automática de direcciones IP públicas se deshabilitará en las subredes públicas. Para obtener información acerca de cómo habilitar la asignación de direcciones IP públicas en una subred, consulte [Modificación del atributo de direcciones IPv4 públicas de su subred](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip). Si el nodo se implementa en una subred privada, podrá comunicarse con el clúster y otros servicios de AWS a través de una puerta de enlace NAT.
Si las subredes no tienen acceso a Internet, asegúrese de que conoce las consideraciones y los pasos adicionales en [Implementación de clústeres privados con acceso limitado a Internet](private-clusters.md).
Si selecciona las subredes de AWS Outposts, Wavelength o zonas locales, las subredes no se deben haber pasado cuando creó el clúster.

1. Confirme que la pila pueda crear recursos de IAM y, a continuación, seleccione **Crear pila**.

1. Una vez completada la creación de la pila, selecciónela en la consola y elija **Salidas**.

1. Anote el valor de **NodeInstanceRoles** correspondiente al grupo de nodos creado. Lo necesitará al configurar los nodos de Windows para Amazon EKS.

 **Paso 2: habilitación para que los nodos se unan al clúster** 

1. Verifique si ya tiene el `ConfigMap` de `aws-auth`.

   ```
   kubectl describe configmap -n kube-system aws-auth
   ```

1. Si se le muestra un `ConfigMap` de `aws-auth`, actualícelo según sea necesario.

   1. Abra el icono `ConfigMap` para editar.

      ```
      kubectl edit -n kube-system configmap/aws-auth
      ```

   1. Añada nuevas entradas de `mapRoles` según sea necesario. Establezca los valores de `rolearn` en los valores de **NodeInstanceRole** que registró en los procedimientos anteriores.

      ```
      [...]
      data:
        mapRoles: |
      - rolearn: <ARN of linux instance role (not instance profile)>
            username: system:node:{{EC2PrivateDNSName}}
            groups:
              - system:bootstrappers
              - system:nodes
          - rolearn: <ARN of windows instance role (not instance profile)>
            username: system:node:{{EC2PrivateDNSName}}
            groups:
              - system:bootstrappers
              - system:nodes
              - eks:kube-proxy-windows
      [...]
      ```

   1. Guarde el archivo y salga del editor de texto.

1. Si recibe un error que indica “`Error from server (NotFound): configmaps "aws-auth" not found`, aplique el `ConfigMap` bursátil.

   1. Descargue el mapa de configuración.

      ```
      curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm-windows.yaml
      ```

   1. En el archivo `aws-auth-cm-windows.yaml`, establezca los valores de `rolearn` a los valores **NodeInstanceRole** que ha registrado en el procedimiento anterior. Puede hacerlo con un editor de texto o reemplazando los valores de ejemplo y ejecutando el siguiente comando:

      ```
      sed -i.bak -e 's|<ARN of linux instance role (not instance profile)>|my-node-linux-instance-role|' \
          -e 's|<ARN of windows instance role (not instance profile)>|my-node-windows-instance-role|' aws-auth-cm-windows.yaml
      ```
**importante**  
No modifique ninguna otra línea de este archivo.
No utilice el mismo rol de IAM para los nodos de Windows y Linux.

   1. Aplique la configuración. Este comando podría tardar varios minutos en finalizar.

      ```
      kubectl apply -f aws-auth-cm-windows.yaml
      ```

1. Observe el estado de los nodos y espere a que aparezca el estado `Ready`.

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

   Ingrese `Ctrl`\$1`C` para obtener un símbolo del intérprete de comandos.
**nota**  
Si recibe cualquier error de tipo de recurso o autorización, consulte [Acceso denegado o no autorizado (`kubectl`)](troubleshooting.md#unauthorized) en el tema de solución de problemas.

   Si los nodos no se unen al clúster, consulte [Los nodos no pueden unirse al clúster](troubleshooting.md#worker-node-fail) en el capítulo de solución de problemas.

 **Paso 3: acciones adicionales** 

1. (Opcional) Implemente una [aplicación de muestra](sample-deployment.md) para probar el clúster y los nodos de Windows.

1. (Opcional) Si la política de IAM administrada **AmazonEKS\$1CNI\$1Policy** (si tiene un clúster `IPv4`) o la política *AmazonEKS\$1CNI\$1IPv6\$1Policy* (que [haya creado](cni-iam-role.md#cni-iam-role-create-ipv6-policy) si tiene un clúster `IPv6`) están adjuntas a su [rol de IAM de nodos en Amazon EKS](create-node-role.md), le recomendamos asignarlas a un rol de IAM que asocie a la cuenta de servicio de `aws-node` de Kubernetes como alternativa. Para obtener más información, consulte [Configuración del complemento de CNI de Amazon VPC para utilizar IRSA](cni-iam-role.md).

1. Se recomienda bloquear el acceso al pod a IMDS si se cumplen las siguientes condiciones:
   + Tiene previsto asignar roles de IAM a todas sus cuentas de servicio de Kubernetes para que los pods solo tengan los permisos mínimos que necesitan.
   + Ninguno de los pods del clúster requiere acceso al servicio de metadatos de instancias (IMDS) de Amazon EC2 por otros motivos, como la recuperación de la región de AWS actual.

   Para obtener más información, consulte [Restringir el acceso al perfil de instancias asignado al nodo de trabajo](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).

# Creación de nodos autoadministrados de Linux para Ubuntu
<a name="launch-node-ubuntu"></a>

**nota**  
Los grupos de nodos administrados podrían ofrecer algunas ventajas para su caso de uso. Para obtener más información, consulte [Simplificación del ciclo de vida de los nodos con grupos de nodos administrados](managed-node-groups.md).

En este tema, se describe cómo lanzar grupos de escalado automático de nodos de [Ubuntu en Amazon Elastic Kubernetes Service (EKS)](https://cloud-images.ubuntu.com/aws-eks/) o [Ubuntu Pro en Amazon Elastic Kubernetes Service (EKS)](https://ubuntu.com/blog/ubuntu-pro-for-eks-is-now-generally-available) que se registran con el clúster de Amazon EKS. Ubuntu y Ubuntu Pro para EKS se basan en Ubuntu Minimal LTS oficial, incluyen el kernel de AWS personalizado que se desarrolla junto con AWS y se han creado específicamente para EKS. Ubuntu Pro agrega una cobertura de seguridad adicional, ya que es compatible con los periodos de soporte ampliados de EKS, el parche activo del kernel, la compatibilidad con FIPS y la capacidad de ejecutar contenedores Pro ilimitados.

Una vez que los nodos se hayan unido al clúster, puede implementar aplicaciones de contenedores en ellos. Para obtener más información, consulte la documentación sobre [Ubuntu en AWS](https://documentation.ubuntu.com/aws/en/latest/) y la [Compatibilidad con AMI personalizada](https://eksctl.io/usage/custom-ami-support/) en la documentación de `eksctl`.

**importante**  
Los nodos de Amazon EKS son instancias estándar de Amazon EC2 y se les facturarán conforme a los precios ordinarios de las instancias de Amazon EC2. Para obtener más información, consulte [Precios de Amazon EC2](https://aws.amazon.com/ec2/pricing/).
Puede lanzar nodos de Ubuntu en clústeres extendidos de Amazon EKS en AWS Outposts, pero no puede lanzarlos en clústeres locales en AWS Outposts. Para obtener más información, consulte [Implementación de Amazon EKS en las instalaciones con AWS Outposts](eks-outposts.md).
Puede implementar en instancias de Amazon EC2 con procesadores `x86` o Arm. Sin embargo, es posible que las instancias que tienen chips de Inferentia deban instalar primero el [SDK de Neuron](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/).

En este procedimiento, se requiere la versión `0.215.0` o posterior de `eksctl`. Puede verificar la versión con el siguiente comando:

```
eksctl version
```

Para obtener instrucciones acerca de cómo instalar o actualizar `eksctl`, consulte [Instalación](https://eksctl.io/installation) en la documentación de `eksctl`. NOTA: Este procedimiento solo funciona en los clústeres que se crearon con `eksctl`.

1. Copie los siguientes contenidos en su dispositivo. Reemplace `my-cluster` por el nombre del clúster. El nombre solo puede contener caracteres alfanuméricos (con distinción de mayúsculas y minúsculas) y guiones. Debe comenzar con un carácter alfabético y no puede tener más de 100 caracteres. Reemplace `ng-ubuntu` por un nombre para su grupo de nodos. El nombre del grupo de nodos no puede tener más de 63 caracteres. Debe empezar por una letra o un dígito, pero también puede incluir guiones y guiones bajos como caracteres no iniciales. Para implementar en instancias Arm, reemplace `m5.large` por un tipo de instancia Arm. Sustituya `my-ec2-keypair-name` por el nombre de un par de claves SSH de Amazon EC2 que pueda utilizar para conectar mediante SSH con los nodos después de haberlos lanzado. Si aún no tiene un par de claves de Amazon EC2, puede crear uno en la Consola de administración de AWS. Para obtener más información, consulte [Pares de claves de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) en la Guía del usuario de Amazon EC2. Sustituya todos los valores de ejemplo restantes por sus propios valores. Una vez que haya llevado a cabo las sustituciones, ejecute el comando modificado para crear el archivo `ubuntu.yaml`.
**importante**  
Para implementar un grupo de nodos en las subredes de AWS Outposts, AWS Wavelength o zonas locales de AWS, no pase las subredes de AWS Outposts, AWS Wavelength o Zonas locales de AWS al crear el clúster. Debe especificar las subredes en el siguiente ejemplo. Para obtener más información, consulte [Crear un grupo de nodos a partir de un archivo de Config](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file) y el [Esquema de archivo de configuración](https://eksctl.io/usage/schema/) en la documentación de `eksctl`. Reemplace *region-code* por la región de AWS en la que se encuentra el clúster.

   ```
   cat >ubuntu.yaml <<EOF
   ---
   apiVersion: eksctl.io/v1alpha5
   kind: ClusterConfig
   
   metadata:
     name: my-cluster
     region: region-code
     version: '1.35'
   
   iam:
     withOIDC: true
   
   nodeGroups:
     - name: ng-ubuntu
       instanceType: m5.large
       desiredCapacity: 3
       amiFamily: Ubuntu2204
       iam:
          attachPolicyARNs:
             - arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
             - arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
             - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
             - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
       ssh:
           allow: true
           publicKeyName: my-ec2-keypair-name
   EOF
   ```

   Para crear un grupo de nodos de Ubuntu Pro, solo tiene que cambiar el valor `amiFamily` a `UbuntuPro2204`.

1. Implemente los nodos con el siguiente comando.

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

   Un ejemplo de salida sería el siguiente.

   Se generan varias líneas mientras se crean los nodos. Una de las últimas líneas de salida es la siguiente línea de ejemplo.

   ```
   [✔]  created 1 nodegroup(s) in cluster "my-cluster"
   ```

1. (Opcional) Implemente una [aplicación de muestra](sample-deployment.md) para probar los nodos de Ubuntu.

1. Se recomienda bloquear el acceso al pod a IMDS si se cumplen las siguientes condiciones:
   + Tiene previsto asignar roles de IAM a todas sus cuentas de servicio de Kubernetes para que los pods solo tengan los permisos mínimos que necesitan.
   + Ninguno de los pods del clúster requiere acceso al servicio de metadatos de instancias (IMDS) de Amazon EC2 por otros motivos, como la recuperación de la región de AWS actual.

   Para obtener más información, consulte [Restringir el acceso al perfil de instancias asignado al nodo de trabajo](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).

# Actualización de los nodos autoadministrados para un clúster
<a name="update-workers"></a>

Cuando se lanza una nueva AMI optimizada para Amazon EKS, considere la posibilidad de reemplazar los nodos del grupo de nodos autoadministrados con la nueva AMI. Asimismo, si ha actualizado la versión de Kubernetes del clúster de Amazon EKS, actualice los nodos para utilizarlos con la misma versión de Kubernetes.

**importante**  
En este tema, se explican las actualizaciones de los nodos autoadministrados. Si utiliza [grupos de nodos administrados](managed-node-groups.md), consulte [Actualización de un grupo de nodos administrados para un clúster](update-managed-node-group.md).

Existen dos formas básicas de actualizar grupos de nodos autoadministrados en los clústeres para utilizar una nueva AMI:

 ** [Migre sus aplicaciones a un nuevo grupo de nodos](migrate-stack.md) **   
Cree un nuevo grupo de nodos y migre los pods a ese grupo. La migración a un nuevo grupo de nodos es más sencilla que simplemente actualizar el ID de la AMI en una pila de AWS CloudFormation existente. Esto se debe a que el proceso de migración [marca](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) al antiguo grupo de nodos como `NoSchedule` y drena los nodos después de que una nueva pila esté lista para aceptar la carga de trabajo del pod existente.

 ** [Actualizar una pila de nodos de AWS CloudFormation](update-stack.md) **   
Actualice la pila de AWS CloudFormation para que un grupo de nodos existente utilice la nueva AMI. Este método no es compatible con los grupos de nodos creados con `eksctl`.

# Migración de aplicaciones a un nuevo grupo de nodos
<a name="migrate-stack"></a>

En este tema, se describe cómo crear un nuevo grupo de nodos, migrar de forma correcta las aplicaciones existentes al nuevo grupo y eliminar el antiguo grupo de nodos del clúster. Puede migrar a un nuevo grupo de nodos mediante `eksctl` o la Consola de administración de AWS.
+  [`eksctl`](#eksctl_migrate_apps) 
+  [Consola de administración de AWS y AWS CLI](#console_migrate_apps) 

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

 **Migre sus aplicaciones a un nuevo grupo de nodos con `eksctl` ** 

Para obtener más información sobre el uso de eksctl para la migración, consulte [Nodos no administrados](https://eksctl.io/usage/nodegroup-unmanaged/) en la documentación de `eksctl`.

En este procedimiento, se requiere la versión `0.215.0` o posterior de `eksctl`. Puede verificar la versión con el siguiente comando:

```
eksctl version
```

Para obtener instrucciones sobre cómo instalar o actualizar `eksctl`, consulte [Instalación](https://eksctl.io/installation) en la documentación de `eksctl`.

**nota**  
Este procedimiento solo funciona para los clústeres y grupos de nodos que se crearon con `eksctl`.

1. Recupere el nombre de los grupos de nodos existentes al sustituir *mi clúster* por el nombre del clúster.

   ```
   eksctl get nodegroups --cluster=my-cluster
   ```

   Un ejemplo de salida sería el siguiente.

   ```
   CLUSTER      NODEGROUP          CREATED               MIN SIZE      MAX SIZE     DESIRED CAPACITY     INSTANCE TYPE     IMAGE ID
   default      standard-nodes   2019-05-01T22:26:58Z  1             4            3                    t3.medium         ami-05a71d034119ffc12
   ```

1. Lance un nuevo grupo de nodos con `eksctl` mediante el siguiente comando. En el comando, sustituya cada *valor de ejemplo* por sus valores propios. El número de versión no puede ser posterior a la versión de Kubernetes del plano de control. Además, no puede ser más de dos versiones secundarias anteriores a la versión de Kubernetes para el plano de control. Recomendamos que utilice la misma versión que el plano de control.

   Se recomienda bloquear el acceso al pod a IMDS si se cumplen las siguientes condiciones:
   + Tiene previsto asignar roles de IAM a todas sus cuentas de servicio de Kubernetes para que los pods solo tengan los permisos mínimos que necesitan.
   + Ninguno de los pods del clúster requiere acceso al servicio de metadatos de instancias (IMDS) de Amazon EC2 por otros motivos, como la recuperación de la región de AWS actual.

     Para obtener más información, consulte [Restringir el acceso al perfil de instancias asignado al nodo de trabajo](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).

     Si desea bloquear el acceso del pod a IMDS, agregue la opción `--disable-pod-imds` al siguiente comando.
**nota**  
Para obtener más marcadores disponibles y sus descripciones, consulte https://eksctl.io/.

   ```
   eksctl create nodegroup \
     --cluster my-cluster \
     --version 1.35 \
     --name standard-nodes-new \
     --node-type t3.medium \
     --nodes 3 \
     --nodes-min 1 \
     --nodes-max 4 \
     --managed=false
   ```

1. Cuando se complete el comando anterior, verifique con el siguiente comando que todos los nodos tengan el estado `Ready` (Listo):

   ```
   kubectl get nodes
   ```

1. Elimine el grupo de nodos original con el siguiente comando. En el comando, sustituya cada *valor de ejemplo* con los nombres del clúster y el grupo de nodos:

   ```
   eksctl delete nodegroup --cluster my-cluster --name standard-nodes-old
   ```

## Consola de administración de AWS y AWS CLI
<a name="console_migrate_apps"></a>

 **Migre sus aplicaciones a un nuevo grupo de nodos con la Consola de administración de AWS y la AWS CLI** 

1. Lance un nuevo grupo de nodos mediante los pasos que se indican en [Creación de nodos autoadministrados de Amazon Linux](launch-workers.md).

1. Una vez completada la creación de la pila, selecciónela en la consola y elija **Salidas**.

1.  Anote el valor de **NodeInstanceRoles** correspondiente al grupo de nodos creado. Lo necesita para agregar los nuevos nodos de Amazon EKS al clúster.
**nota**  
Si ha adjuntado políticas de IAM adicionales al rol de IAM del grupo de nodos anterior, debe adjuntar esas mismas políticas al rol de IAM del nuevo grupo de nodos para mantener esa funcionalidad en el nuevo grupo. Esto se aplica si ha agregado permisos para el [escalador automático del clúster](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) de Kubernetes, por ejemplo.

1. Actualice los grupos de seguridad de ambos grupos de nodos para que puedan comunicarse entre sí. Para obtener más información, consulte [Revisión de requisitos de grupos de seguridad de Amazon EKS para clústeres](sec-group-reqs.md).

   1. Anote los ID de grupo de seguridad de ambos grupos de nodos. Esto se muestra como el valor **NodeSecurityGroup** en los resultados de la pila de AWS CloudFormation.

      Puede utilizar los siguientes comandos de la AWS CLI para obtener los ID de grupo de seguridad de los nombres de pilas. En estos comandos, `oldNodes` es el nombre de pila de AWS CloudFormation de la pila de nodos antigua y `newNodes` es el nombre de la pila a la que migrará. Reemplace todos los *valores de ejemplo* por sus propios valores.

      ```
      oldNodes="old_node_CFN_stack_name"
      newNodes="new_node_CFN_stack_name"
      
      oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \
      --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
      --output text)
      newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \
      --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
      --output text)
      ```

   1. Agregue reglas de entrada a cada grupo de seguridad de nodos para que acepten tráfico de los otros grupos.

      Los siguientes comandos de la AWS CLI agregan reglas de entrada a cada grupo de seguridad que permiten todo el tráfico en todos los protocolos del otro grupo de seguridad. Esta configuración permite que los pods de cada grupo de nodos se comuniquen entre ellos mientras migra la carga de trabajo al nuevo grupo.

      ```
      aws ec2 authorize-security-group-ingress --group-id $oldSecGroup \
      --source-group $newSecGroup --protocol -1
      aws ec2 authorize-security-group-ingress --group-id $newSecGroup \
      --source-group $oldSecGroup --protocol -1
      ```

1. Edite el mapa de configuración de `aws-auth` para asignar el rol de la instancia del nuevo nodo en RBAC.

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

   Agregue una nueva entrada `mapRoles` para el nuevo grupo de nodos.

   ```
   apiVersion: v1
   data:
     mapRoles: |
       - rolearn: ARN of instance role (not instance profile)
         username: system:node:{{EC2PrivateDNSName}}
         groups:
           - system:bootstrappers
           - system:nodes>
       - rolearn: arn:aws:iam::111122223333:role/nodes-1-16-NodeInstanceRole-U11V27W93CX5
         username: system:node:{{EC2PrivateDNSName}}
         groups:
           - system:bootstrappers
           - system:nodes
   ```

   Sustituya el fragmento *ARN of instance role (not instance profile)* por el valor de **NodeInstanceRole** anotado en el [procedimiento anterior](#node-instance-role-step). A continuación, guarde y cierre el archivo para aplicar el configmap actualizado.

1. Examine el estado de los nodos y espere a que los nuevos nodos se unan al clúster y tengan el estado `Ready` (Listo).

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

1. (Opcional) Si utiliza el [escalador automático del clúster de Kubernetes](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), escale la implementación a cero (0) réplicas para evitar acciones de escalado en conflicto.

   ```
   kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system
   ```

1. Utilice el siguiente comando para agregar taints en cada uno de los nodos que desee eliminar con `NoSchedule`. Esto es para que los nuevos pods no se programen ni se vuelvan a programar en los nodos que va a reemplazar. Para obtener más información, consulte [Taints y toleraciones](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) en la documentación de Kubernetes.

   ```
   kubectl taint nodes node_name key=value:NoSchedule
   ```

   Si va a actualizar los nodos a una nueva versión de Kubernetes, puede identificar todos los nodos de una determinada versión de Kubernetes (en este caso, `1.33`) y aplicarles una taint con el siguiente fragmento de código. El número de versión no puede ser posterior a la versión de Kubernetes del plano de control. Además, no puede ser más de dos versiones secundarias anteriores a la versión de Kubernetes del plano de control. Recomendamos que utilice la misma versión que el plano de control.

   ```
   K8S_VERSION=1.33
   nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}")
   for node in ${nodes[@]}
   do
       echo "Tainting $node"
       kubectl taint nodes $node key=value:NoSchedule
   done
   ```

1.  Identifique el proveedor de DNS del clúster.

   ```
   kubectl get deployments -l k8s-app=kube-dns -n kube-system
   ```

   Un ejemplo de salida sería el siguiente. Este clúster utiliza CoreDNS para la resolución de DNS, pero el clúster puede devolver `kube-dns` en su lugar:

   ```
   NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
   coredns   1         1         1            1           31m
   ```

1. Si su implementación actual está ejecutando menos de dos réplicas, escale la implementación a dos réplicas. Cambie *coredns* por `kubedns` si el resultado del comando anterior ha devuelto ese valor.

   ```
   kubectl scale deployments/coredns --replicas=2 -n kube-system
   ```

1. Vacíe cada uno de los nodos que desea eliminar de su clúster con el siguiente comando:

   ```
   kubectl drain node_name --ignore-daemonsets --delete-local-data
   ```

   Si va a actualizar los nodos a una nueva versión de Kubernetes, identifique y drene todos los nodos de una determinada versión de Kubernetes (en este caso *1.33*) con el siguiente fragmento de código.

   ```
   K8S_VERSION=1.33
   nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}")
   for node in ${nodes[@]}
   do
       echo "Draining $node"
       kubectl drain $node --ignore-daemonsets --delete-local-data
   done
   ```

1. Una vez que haya terminado de vaciar los nodos antiguos, revoque las reglas de entrada del grupo de seguridad que autorizó anteriormente. A continuación, elimine la pila de AWS CloudFormation para terminar las instancias.
**nota**  
Si ha adjuntado políticas de IAM adicionales al rol de IAM del grupo de nodos anterior, como agregar permisos para el [escalador automático del clúster de Kubernetes](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), desconecte esas políticas adicionales del rol antes de eliminar la pila de AWS CloudFormation.

   1. Revoque las reglas de entrada que creó anteriormente para los grupos de seguridad de nodos. En estos comandos, `oldNodes` es el nombre de pila de AWS CloudFormation de la pila de nodos antigua y `newNodes` es el nombre de la pila a la que migrará.

      ```
      oldNodes="old_node_CFN_stack_name"
      newNodes="new_node_CFN_stack_name"
      
      oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \
      --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
      --output text)
      newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \
      --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \
      --output text)
      aws ec2 revoke-security-group-ingress --group-id $oldSecGroup \
      --source-group $newSecGroup --protocol -1
      aws ec2 revoke-security-group-ingress --group-id $newSecGroup \
      --source-group $oldSecGroup --protocol -1
      ```

   1. Abra la [AWS consola de CloudFormation](https://console.aws.amazon.com/cloudformation/).

   1. Seleccione la pila de nodos antigua.

   1. Elija **Eliminar**.

   1. En el cuadro de diálogo de confirmación **Eliminar pila**, elija **Eliminar pila**.

1. Edite el mapa de configuración de `aws-auth` para eliminar el rol de la instancia del nodo anterior de RBAC.

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

   Elimine la entrada `mapRoles` del grupo de nodos antiguo.

   ```
   apiVersion: v1
   data:
     mapRoles: |
       - rolearn: arn:aws:iam::111122223333:role/nodes-1-16-NodeInstanceRole-W70725MZQFF8
         username: system:node:{{EC2PrivateDNSName}}
         groups:
           - system:bootstrappers
           - system:nodes
       - rolearn: arn:aws:iam::111122223333:role/nodes-1-15-NodeInstanceRole-U11V27W93CX5
         username: system:node:{{EC2PrivateDNSName}}
         groups:
           - system:bootstrappers
           - system:nodes>
   ```

   Guarde y cierre el archivo para aplicar el mapa de configuración actualizado.

1. (Opcional) Si utiliza el [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) de Kubernetes, vuelva a escalar la implementación a una réplica.
**nota**  
También debe etiquetar el nuevo grupo de Auto Scaling de forma correcta (por ejemplo, `k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/my-cluster`) y actualizar el comando de implementación del escalador automático del clúster para que señale el grupo de Auto Scaling recién etiquetado. Para obtener más información, consulte [Escalador automático de clústeres en AWS](https://github.com/kubernetes/autoscaler/tree/cluster-autoscaler-release-1.3/cluster-autoscaler/cloudprovider/aws).

   ```
   kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system
   ```

1. (Opcional) Verifique que utiliza la última versión del [complemento CNI de Amazon VPC para Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s). Es posible que tenga que actualizar la versión de CNI para utilizar los tipos de instancia admitidos más recientes. Para obtener más información, consulte [Asignación de direcciones IP a pods con CNI de Amazon VPC](managing-vpc-cni.md).

1. Si el clúster utiliza `kube-dns` para la resolución DNS (consulte [[migrate-determine-dns-step]](#migrate-determine-dns-step)), reduzca horizontalmente la implementación de `kube-dns` a una réplica.

   ```
   kubectl scale deployments/kube-dns --replicas=1 -n kube-system
   ```

# Actualización de una pila de nodos de AWS CloudFormation
<a name="update-stack"></a>

En este tema, se describe cómo puede actualizar una pila existente de nodos autoadministrados de AWS CloudFormation con una nueva AMI. Puede utilizar este procedimiento para actualizar los nodos a una nueva versión de Kubernetes después de la actualización de un clúster. De lo contrario, puede actualizar a la última AMI optimizada de Amazon EKS para una versión existente de Kubernetes.

**importante**  
En este tema, se explican las actualizaciones de los nodos autoadministrados. Para obtener información sobre el uso de la [Simplificación del ciclo de vida de los nodos con grupos de nodos administrados](managed-node-groups.md), consulte [Actualización de un grupo de nodos administrados para un clúster](update-managed-node-group.md).

La última plantilla de AWS CloudFormation de nodos de Amazon EKS predeterminada está configurada para lanzar una instancia con la nueva AMI en el clúster antes de eliminar una antigua, una por vez. Esta configuración garantiza que siempre tenga el número deseado de instancias activas del grupo de Auto Scaling en el clúster durante la actualización progresiva.

**nota**  
Este método no es compatible con los grupos de nodos creados con `eksctl`. Si ha creado su clúster o un grupo de nodos con `eksctl`, consulte [Migración de aplicaciones a un nuevo grupo de nodos](migrate-stack.md).

1. Determine el proveedor de DNS para el clúster.

   ```
   kubectl get deployments -l k8s-app=kube-dns -n kube-system
   ```

   Un ejemplo de salida sería el siguiente. Este clúster utiliza CoreDNS para la resolución de DNS, pero el clúster puede devolver `kube-dns` en su lugar. El resultado puede tener un aspecto diferente según la versión de `kubectl` que utilice.

   ```
   NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
   coredns   1         1         1            1           31m
   ```

1. Si su implementación actual está ejecutando menos de dos réplicas, escale la implementación a dos réplicas. Cambie *coredns* por `kube-dns` si el resultado del comando anterior ha devuelto ese valor.

   ```
   kubectl scale deployments/coredns --replicas=2 -n kube-system
   ```

1. (Opcional) Si utiliza el [escalador automático del clúster de Kubernetes](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md), escale la implementación a cero (0) réplicas para evitar acciones de escalado en conflicto.

   ```
   kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system
   ```

1.  Determine el tipo de instancia y el número de instancias deseado del grupo de nodos actual. Ingrese estos valores más tarde cuando actualice la plantilla de AWS CloudFormation del grupo.

   1. Abra la consola de Amazon EC2 en https://console.aws.amazon.com/ec2/.

   1. En el panel de navegación izquierdo, elija **Configuraciones de lanzamiento** (Configuraciones de lanzamiento) y anote el tipo de instancia de la configuración de lanzamiento de nodos existente.

   1. En el panel de navegación izquierdo, elija **Auto Scaling Groups** (Grupos de Auto Scaling) y anote el recuento de instancias **deseado** para el grupo de Auto Scaling de nodos existente.

1. Abra la [AWS consola de CloudFormation](https://console.aws.amazon.com/cloudformation/).

1. Seleccione la pila del grupo de nodos y, a continuación, seleccione **Update (Actualizar)**.

1. Seleccione **Replace current template (Reemplazar plantilla actual)** y seleccione **Amazon S3 URL**.

1. Para **URL de Amazon S3**, pegue la siguiente URL en el área de texto a fin de asegurarse de que utiliza la versión más reciente de la plantilla de AWS Cloud Formation de nodos. A continuación, elija **Siguiente**:

   ```
   https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-12-23/amazon-eks-nodegroup.yaml
   ```

1. En la página **Especificar detalles**, rellene los parámetros siguientes y seleccione **Siguiente**:
   +  **NodeAutoScalingGroupDesiredCapacity**: ingrese el recuento de instancias deseado que registró en un [paso anterior](#existing-worker-settings-step). O bien, ingrese el nuevo número deseado de nodos para escalar cuando se actualice la pila.
   +  **NodeAutoScalingGroupMaxSize**: ingrese el número máximo de nodos al que pueda llegar el grupo de Auto Scaling de nodos. Este valor debe ser al menos un nodo más que la capacidad deseada. Es para que pueda realizar una actualización continua de los nodos sin que se reduzca el número durante la actualización.
   +  **NodeInstanceType**: elija el tipo de instancia que registró en un [paso anterior](#existing-worker-settings-step). Por otra parte, puede elegir un tipo de instancia diferente para los nodos. Antes de elegir un tipo de instancia diferente, vea [Elección de un tipo de instancia de nodo de Amazon EC2 óptimo](choosing-instance-type.md). Cada tipo de instancia de Amazon EC2 admite un número máximo de interfaces de redes elásticas (interfaz de red) y cada interfaz de red admite un número máximo de direcciones IP. Dado que a cada nodo de trabajo y pod se les asigna su propia dirección IP, es importante elegir un tipo de instancia que admita el número máximo de pods que desea ejecutar en cada nodo de Amazon EC2. Para obtener una lista del número de interfaces de red y direcciones IP admitidas por los tipos de instancias, consulte [Direcciones IP por interfaz de red por tipo de instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI). Por ejemplo, el tipo de instancia `m5.large` admite un máximo de 30 direcciones IP para el nodo de trabajo y los pods.
**nota**  
Los tipos de instancias compatibles con la versión más reciente del [complemento CNI de Amazon VPC para Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) se muestran en [vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go) en GitHub. Es posible que tenga que actualizar la versión del complemento CNI de Amazon VPC para Kubernetes a fin de utilizar los tipos de instancia admitidos más recientes. Para obtener más información, consulte [Asignación de direcciones IP a pods con CNI de Amazon VPC](managing-vpc-cni.md).
**importante**  
Algunos tipos de instancias podrían no estar disponibles en todas las regiones de AWS.
   +  **NodeImageIdSSMParam**: el parámetro de Amazon EC2 Systems Manager del ID de AMI al que desee actualizar. El siguiente valor utiliza la última AMI optimizada para Amazon EKS para la versión  de Kubernetes `1.35`.

     ```
     /aws/service/eks/optimized-ami/1.35/amazon-linux-2/recommended/image_id
     ```

     Puede reemplazar *1.35* por una [versión de la plataforma](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html) que sea igual. O bien, debería ser hasta una versión anterior a la versión de Kubernetes que se ejecuta en el plano de control. Le recomendamos que los nodos tengan la misma versión que el plano de control. También puede sustituir *amazon-linux-2* por un tipo de AMI diferente. Para obtener más información, consulte [Obtención de los ID de AMI de Amazon Linux recomendados](retrieve-ami-id.md).
**nota**  
El uso del parámetro de Amazon EC2 Systems Manager lo habilita a actualizar los nodos en el futuro sin tener que buscar y especificar un ID de AMI. Si la pila de AWS CloudFormation utiliza este valor, cualquier actualización de la pila lanzará siempre la última AMI optimizada para Amazon EKS recomendada en función de la versión de Kubernetes especificada. Este es el caso incluso si no cambia ningún valor en la plantilla.
   +  **NodeImageId**: para utilizar su propia AMI personalizada, introduzca el ID de la AMI que va a utilizar.
**importante**  
Este valor anula cualquier valor especificado para **NodeImageIdSSMParam**. Si desea utilizar el valor **NodeImageIdSSMParam** asegúrese de que el valor de **NodeImageId** esté vacío.
   +  **DisableIMDSv1**: cada nodo admite de forma predeterminada la versión 1 (IMDSv1) e IMDSv2 del servicio de metadatos de la instancia. Sin embargo, puede desactivar IMDSv1. Seleccione **verdadero** si no desea que ningún nodo o ningún pod programado en el grupo de nodos utilice IMDSv1. Para obtener más información, consulte [Configuración del servicio de metadatos de instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html). Si ha implementado roles de IAM para cuentas de servicio, asigne los permisos necesarios de forma directa a todos los pods que requieren acceso a servicios de AWS. De esta manera, ningún pod del clúster requiere el acceso a IMDS por otros motivos, como la recuperación de la región de AWS actual. A continuación, también puede deshabilitar el acceso a IMDSv2 para los pods que no utilizan redes de host. Para obtener más información, consulte [Restringir el acceso al perfil de instancias asignado al nodo de trabajo](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).

1. (Opcional) En la página **Options (Opciones)**, marque los recursos de la pila. Elija **Siguiente**.

1. En la página **Review** (Revisar), revise la información, confirme la advertencia de que la pila puede crear recursos de IAM y elija **Update stack** (Actualizar pila).
**nota**  
La actualización de cada nodo del clúster tarda varios minutos. Espere a que se complete la actualización de todos los nodos antes de realizar los siguientes pasos.

1. Si su proveedor DNS del clúster es `kube-dns`, reduzca horizontalmente la implementación de `kube-dns` a una réplica.

   ```
   kubectl scale deployments/kube-dns --replicas=1 -n kube-system
   ```

1. (Opcional) Si utiliza el [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) de Kubernetes, vuelva a escalar la implementación a la cantidad de réplicas deseada.

   ```
   kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system
   ```

1. (Opcional) Verifique que utiliza la última versión del [complemento CNI de Amazon VPC para Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s). Es posible que tenga que actualizar la versión del complemento CNI de Amazon VPC para Kubernetes a fin de utilizar los tipos de instancia admitidos más recientes. Para obtener más información, consulte [Asignación de direcciones IP a pods con CNI de Amazon VPC](managing-vpc-cni.md).

# Simplificación de la administración de computación con AWS Fargate
<a name="fargate"></a>

En este tema se explica cómo utilizar Amazon EKS para ejecutar pods de Kubernetes en AWS Fargate. Fargate es una tecnología que proporciona capacidad informática bajo demanda correctamente dimensionada para [contenedores](https://aws.amazon.com/what-are-containers). Con Fargate ya no tendrá que aprovisionar, configurar ni escalar grupos de máquinas virtuales por su cuenta para ejecutar los contenedores. Tampoco tendrá que elegir tipos de servidores, decidir cuándo escalar los grupos de nodos u optimizar el empaquetado de clústeres.

Puede controlar qué pods se comienzan en Fargate y cómo se ejecutan con [perfiles de Fargate](fargate-profile.md). Los perfiles de Fargate se definen como parte de su clúster de Amazon EKS. Amazon EKS integra Kubernetes con Fargate mediante controladores creados por AWS con el modelo ascendente y extensible proporcionado por Kubernetes. Estos controladores funcionan como parte del plano de control de Kubernetes administrado por Amazon EKS y son responsables de programar los pods de Kubernetes nativos en Fargate. Los controladores de Fargate incluyen un nuevo programador que se ejecuta junto con el programador predeterminado de Kubernetes, además de varios controladores de admisión de mutación y validación. Cuando comienza un pod que cumple los criterios para ejecutarse en Fargate, los controladores de Fargate que se ejecutan en el clúster reconocen, actualizan y programan el pod en Fargate.

En este tema se describen los diferentes componentes de los pods que se ejecutan en Fargate y se ofrecen consideraciones especiales sobre cómo utilizar Fargate con Amazon EKS.

## Consideraciones sobre Fargate de AWS
<a name="fargate-considerations"></a>

Aquí se incluyen algunos aspectos que debe tener en cuenta sobre la utilización de Fargate en Amazon EKS.
+ Cada pod que se ejecuta en Fargate tiene su propio límite de computación. No comparten el kernel subyacente, los recursos de CPU, los recursos de memoria o la interfaz de red elástica con otro pod.
+ Los Network Load Balancers y los Application Load Balancers (ALB) solo se pueden utilizar con Fargate con destinos IP. Para obtener más información, consulte [Crear un equilibrador de carga de red](network-load-balancing.md#network-load-balancer) y [Redirección de tráfico de aplicaciones y HTTP con los equilibradores de carga de aplicaciones](alb-ingress.md).
+ Los servicios expuestos de Fargate solo se ejecutan en modo IP de tipo de destino y no en modo IP de nodo. La forma recomendada de verificar la conectividad de un servicio que se ejecuta en un nodo administrado y un servicio que se ejecuta en Fargate es conectarse a través del nombre del servicio.
+ Los pods deben coincidir con un perfil de Fargate en el momento de su programación para ejecutarse en Fargate. Los pods que no coinciden con un perfil de Fargate podrían quedarse atascados como `Pending`. Si existe un perfil de Fargate coincidente, puede eliminar los pods pendientes que haya creado para reprogramarlos en Fargate.
+ No se admiten DaemonSets en Fargate. Si su aplicación requiere un daemon, reconfigure ese daemon para que se ejecute como un contenedor asociado en sus pods.
+ No se admiten contenedores con privilegios en Fargate.
+ Los pods que se ejecutan en Fargate no pueden especificar `HostPort` ni `HostNetwork` en el manifiesto del pod.
+ El límite flexible predeterminado de `nofile` y `nproc` es 1024 y el límite invariable es 65 535 para los pods de Fargate.
+ Las GPU no están disponibles actualmente en Fargate.
+ Los pods que se ejecutan en Fargate solo se admiten en subredes privadas (con acceso de una puerta de enlace NAT a servicios de AWS, pero sin una ruta directa a una puerta de enlace de Internet), por lo que la VPC del clúster debe tener subredes privadas disponibles. Para los clústeres sin acceso a Internet saliente, consulte [Implementación de clústeres privados con acceso limitado a Internet](private-clusters.md).
+ Puede utilizar el [Ajuste de los recursos de pods con el Escalador automático vertical de pods](vertical-pod-autoscaler.md) para establecer el tamaño correcto inicial de la CPU y la memoria de sus pods de Fargate y, a continuación, utilizar el [Escalado de las implementaciones de pods con el Escalador automático horizontal de pods](horizontal-pod-autoscaler.md) para ajustar la escala de esos pods. Si desea que el Escalador automático vertical de pods vuelva a implementar automáticamente los pods en Fargate con combinaciones de CPU y memoria más grandes, configure el modo del Escalador automático vertical de pods en `Auto` o `Recreate` para garantizar la funcionalidad correcta. Para obtener más información, consulte el documento [Escalador automático vertical de pods](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#quick-start) en GitHub.
+ La resolución de DNS y los nombres de host DNS deben estar habilitados en la VPC. Para obtener más información, consulte [Ver y actualizar el soporte de DNS para su VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating).
+ Fargate de Amazon EKS agrega defensa en profundidad para las aplicaciones de Kubernetes aislando cada pod dentro de una máquina virtual (VM). Este límite de VM impide el acceso a los recursos basados en host utilizados por otros pods en caso de escape de contenedor, que es un método común para atacar aplicaciones en contenedores y obtener acceso a recursos fuera del contenedor.

  El uso de Amazon EKS no modifica sus responsabilidades en virtud del [modelo de responsabilidad compartida](security.md). Debe evaluar detenidamente la configuración de los controles de seguridad y gobernanza del clúster. La forma más segura de aislar una aplicación es ejecutarla siempre en un clúster independiente.
+ Los perfiles de Fargate admiten la especificación de subredes de bloques de CIDR secundarios de VPC. Puede que desee especificar un bloque de CIDR secundario. Esto es debido a que hay un número limitado de direcciones IP disponibles en una subred. Como resultado, hay también un número limitado de pods que se pueden crear en el clúster. Si usa subredes diferentes para los pods, puede aumentar el número de direcciones IP disponibles. Para obtener más información, consulte [Adición de bloques de CIDR IPv4 a una VPC.](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#vpc-resize) 
+ El servicio de metadatos de instancias (IMDS) de Amazon EC2 no está disponible para pods implementados en nodos de Fargate. Si tiene pods implementados en Fargate que necesitan credenciales de IAM, asígnelos a sus pods mediante [roles de IAM para cuentas de servicio](iam-roles-for-service-accounts.md). Si los pods necesitan acceso a otra información disponible a través de IMDS, debe llevar a cabo una codificación rígida de esta información en la especificación del pod. Esto incluye la región de AWS o zona de disponibilidad en la que se implementa un pod.
+ No se pueden implementar pods de Fargate en AWS Outposts, AWS Wavelength o Zonas locales de AWS.
+ Amazon EKS debe aplicar parches periódicamente de pods de Fargate para mantenerlos seguros. Intentamos las actualizaciones de forma que disminuya el impacto, pero hay ocasiones en que los pods deben eliminarse si no se expulsan correctamente. Hay algunas acciones que puede emprender para minimizar las interrupciones. Para obtener más información, consulte [Definición de acciones para los eventos de aplicación de revisiones del sistema operativo de AWS Fargate](fargate-pod-patching.md).
+ El [complemento CNI de Amazon VPC para Amazon EKS](https://github.com/aws/amazon-vpc-cni-plugins) se encuentra instalado en los nodos de Fargate. No puede utilizar [complementos CNI alternativos para clústeres de Amazon EKS](alternate-cni-plugins.md) con nodos de Fargate.
+ Un pod que se ejecuta en Fargate monta automáticamente un sistema de archivos de Amazon EFS, sin necesidad de seguir pasos manuales para la instalación de controladores. No se puede utilizar el aprovisionamiento dinámico de volúmenes persistentes con nodos de Fargate, pero se puede utilizar el aprovisionamiento estático.
+ Amazon EKS no es compatible con Fargate Spot.
+ No puede montar volúmenes de Amazon EBS en los pods de Fargate.
+ Puede ejecutar el controlador CSI de Amazon EBS en nodos de Fargate, pero el DaemonSet del nodo CSI de Amazon EBS solo se puede ejecutar en instancias de Amazon EC2.
+ Después de marcar un [trabajo de Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/job/) como `Completed` o `Failed`, los pods que el trabajo crea normalmente siguen existiendo. Este comportamiento le permite ver sus registros y resultados, pero se pueden generar costos adicionales con Fargate si después no limpia el trabajo.

  Para eliminar automáticamente los pods relacionados después de que se complete o falle un trabajo, puede especificar un periodo de tiempo mediante el controlador de tiempo de vida (TTL). En el siguiente ejemplo, se muestra la especificación `.spec.ttlSecondsAfterFinished` en el manifiesto del trabajo.

  ```
  apiVersion: batch/v1
  kind: Job
  metadata:
    name: busybox
  spec:
    template:
      spec:
        containers:
        - name: busybox
          image: busybox
          command: ["/bin/sh", "-c", "sleep 10"]
        restartPolicy: Never
    ttlSecondsAfterFinished: 60 # <-- TTL controller
  ```

## Tabla de comparación de Fargate
<a name="_fargate_comparison_table"></a>


| Criterios |  AWS Fargate | 
| --- | --- | 
|  Se puede implementar en [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)   |  No  | 
|  Se puede implementar en [AWS Local Zones](local-zones.md).   |  No  | 
|  Puede ejecutar contenedores que requieren Windows  |  No  | 
|  Puede ejecutar contenedores que requieran Linux.  |  Sí  | 
|  Puede ejecutar cargas de trabajo que requieren el chip de inferencias.  |  No  | 
|  Puede ejecutar cargas de trabajo que requieren una GPU.  |  No  | 
|  Puede ejecutar cargas de trabajo que requieren procesadores Arm.  |  No  | 
|  Puede ejecutar AWS [Bottlerocket](https://aws.amazon.com/bottlerocket/).   |  No  | 
|  Los pods comparten un entorno en tiempo de ejecución del kernel con otros pods.  |  No. Cada pod tiene un kernel dedicado.  | 
|  Los pods comparten CPU, memoria, almacenamiento y recursos de red con otros pods.  |  No. Cada pod tiene recursos dedicados y su tamaño se puede adaptar de forma independiente para maximizar la utilización de los recursos.  | 
|  Los pods pueden utilizar más hardware y memoria que lo que se indica en las especificaciones del pod.  |  No. El pod se puede volver a implementar mediante una vCPU y una configuración de memoria más grandes.  | 
|  Debe implementar y administrar instancias de Amazon EC2.  |  No  | 
|  Debe proteger, mantener y aplicar parches al sistema operativo de las instancias de Amazon EC2.  |  No  | 
|  Puede proporcionar argumentos de arranque en la implementación de un nodo, como argumentos [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) adicionales.  |  No  | 
|  Puede asignar direcciones IP a pods desde un bloque de CIDR diferente de la dirección IP asignada al nodo.  |  No  | 
|  Se puede utilizar SSH en el nodo.  |  No: no hay ningún sistema operativo host de nodos para utilizar SSH.  | 
|  Puede implementar su propia AMI personalizada en los nodos.  |  No  | 
|  Puede implementar su propia CNI personalizada en los nodos.  |  No  | 
|  Debe actualizar la AMI de nodos por su cuenta  |  No  | 
|  Debe actualizar la versión de Kubernetes de los nodos por su cuenta.  |  No: no administra nodos.  | 
|  Puede utilizar el almacenamiento de Amazon EBS con pods.  |  No  | 
|  Puede utilizar el almacenamiento de Amazon EFS con pods.  |   [Sí](efs-csi.md)   | 
|  Puede utilizar el almacenamiento de Amazon FSx para Lustre con pods.  |  No  | 
|  Puede utilizar el Network Load Balancer para servicios.  |  Sí, cuando se utiliza la [Creación de un equilibrador de carga de red](network-load-balancing.md#network-load-balancer)   | 
|  Los pods pueden ejecutarse en una subred pública.  |  No  | 
|  Puede asignar diferentes grupos de seguridad de VPC a pods individuales.  |  Sí  | 
|  Puede ejecutar DaemonSets de Kubernetes.  |  No  | 
|  Soporte de `HostPort` y `HostNetwork` en el manifiesto del pod.  |  No  | 
|   Disponibilidad regional de AWS  |   [Algunas regiones admitidas por Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html)   | 
|  Puede ejecutar contenedores en hosts dedicados de Amazon EC2  |  No  | 
|  Precios  |  Costo de una memoria de Fargate individual y configuración de CPU. Cada pod tiene su propio costo. Para obtener más información, consulte [AWS Precios de Fargate](https://aws.amazon.com/fargate/pricing/).  | 

# Introducción a AWS Fargate para un clúster
<a name="fargate-getting-started"></a>

En este tema, se explica cómo comenzar a ejecutar pods en AWS Fargate con su clúster de Amazon EKS.

Si restringe el acceso al punto de conexión público del clúster mediante bloques de CIDR, recomendamos habilitar también el acceso al punto de conexión privado. De este modo, los pods de Fargate pueden comunicarse con el clúster. Si el punto de conexión privado no está habilitado, los bloques de CIDR que especifique para el acceso público deben incluir los orígenes de salida de su VPC. Para obtener más información, consulte [Punto de conexión del servidor de API del clúster](cluster-endpoint.md).

**Requisito previo**  
Un clúster existente. Si no dispone de un clúster de Amazon EKS, consulte [Introducción a Amazon EKS](getting-started.md).

## Paso 1: garantía de que los nodos existentes se puedan comunicar con los pods de Fargate
<a name="fargate-gs-check-compatibility"></a>

Si está trabajando con un nuevo clúster sin nodos o con un clúster solo con grupos de nodos administrados (consulte [Simplificación del ciclo de vida de los nodos con grupos de nodos administrados](managed-node-groups.md)), puede ir directamente a [Paso 2: creación de un rol de ejecución de pods de Fargate](#fargate-sg-pod-execution-role).

Supongamos que está trabajando con un clúster existente que ya tiene nodos asociados. Asegúrese de que los pods de estos nodos puedan comunicarse libremente con los pods que se ejecutan en Fargate. Los pods que se ejecutan en Fargate se configuran automáticamente para utilizar el grupo de seguridad del clúster al que están asociados. Asegúrese de que los nodos existentes en su clúster puedan enviar y recibir tráfico hacia el grupo de seguridad del clúster y recibirlo desde este. Los grupos de nodos administrados se configuran de manera automática para utilizar también el grupo de seguridad del clúster, por lo que no es necesario modificarlos ni verificar si admiten esta función (consulte [Simplificación del ciclo de vida de los nodos con grupos de nodos administrados](managed-node-groups.md)).

Para los grupos de nodos existentes que se crearon con `eksctl` o con las plantillas de AWS CloudFormation administradas de Amazon EKS, puede agregar manualmente el grupo de seguridad del clúster a los nodos. O bien, puede modificar la plantilla de lanzamiento del grupo de Auto Scaling para el grupo de nodos a fin de adjuntar el grupo de seguridad del clúster a las instancias. Para obtener más información, consulte [Cambio de los grupos de seguridad de una instancia](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SG_Changing_Group_Membership) en la *Guía del usuario de Amazon VPC*.

Puede buscar un grupo de seguridad para su clúster en la Consola de administración de AWS, en la sección **Networking** (Redes) del clúster. O puede hacerlo con el siguiente comando de AWS CLI. Cuando utilice este comando, sustituya `<my-cluster>` por el nombre del clúster.

```
aws eks describe-cluster --name <my-cluster> --query cluster.resourcesVpcConfig.clusterSecurityGroupId
```

## Paso 2: creación de un rol de ejecución de pods de Fargate
<a name="fargate-sg-pod-execution-role"></a>

Cuando su clúster crea pods en AWS Fargate, los componentes que se ejecutan en la infraestructura de Fargate deben hacer llamadas a las API de AWS en su nombre. El rol de ejecución de pods de Amazon EKS proporciona los permisos de IAM para esta tarea. Para crear un rol de ejecución de pods de AWS Fargate, consulte [Rol de IAM de ejecución de pods de Amazon EKS](pod-execution-role.md).

**nota**  
Si creó el clúster con `eksctl` a través de la opción `--fargate`, el clúster ya tiene un rol de ejecución de pods que puede encontrar en la consola de IAM con el patrón `eksctl-my-cluster-FargatePodExecutionRole-ABCDEFGHIJKL`. Del mismo modo, si utiliza `eksctl` para crear sus perfiles de Fargate, `eksctl` crea su rol de ejecución de pods si aún no se ha creado uno.

## Paso 3: creación de un perfil de Fargate para el clúster
<a name="fargate-gs-create-profile"></a>

Para poder programar los pods que se ejecuten en Fargate en su clúster, debe definir un perfil de Fargate que especifique qué pods deben utilizar Fargate cuando se lancen. Para obtener más información, consulte [Cómo definir los pods que deben lanzarse en AWS Fargate](fargate-profile.md).

**nota**  
Si creó el clúster con `eksctl` mediante la opción `--fargate`, ya se habrá creado un perfil de Fargate para el clúster con selectores para todos los pods de los espacios de nombres `kube-system` y `default`. Utilice el siguiente procedimiento para crear perfiles de Fargate para cualquier otro espacio de nombres que desee utilizar con Fargate.

Puede crear un perfil de Fargate con una de las siguientes herramientas:
+  [`eksctl`](#eksctl_fargate_profile_create) 
+  [Consola de administración de AWS](#console_fargate_profile_create) 

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

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

 **Cómo crear un perfil de Fargate con `eksctl` ** 

Cree el perfil de Fargate con el siguiente comando de `eksctl` y reemplace cada `<example value>` con valores propios. Debe especificar un espacio de nombres. Sin embargo, la opción `--labels` no es obligatoria.

```
eksctl create fargateprofile \
    --cluster <my-cluster> \
    --name <my-fargate-profile> \
    --namespace <my-kubernetes-namespace> \
    --labels <key=value>
```

Puede usar ciertos comodines para las etiquetas `<my-kubernetes-namespace>` y `<key=value>`. Para obtener más información, consulte [Comodines de perfil de Fargate](fargate-profile.md#fargate-profile-wildcards).

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

 **Para crear un perfil de Fargate con 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 para el que desea crear un perfil de Fargate.

1. Elija la pestaña **Computación**.

1. En **Perfiles de Fargate**, elija **Agregar perfil de Fargate**.

1. En la página **Configurar perfil de Fargate**, haga lo siguiente:

   1. En **Name** (Nombre), ingrese un nombre único para el perfil de Fargate. El nombre debe ser único.

   1. En **Rol de ejecución de pods**, elija el rol de ejecución de pods que se va a utilizar con el perfil de Fargate. Solo se muestran los roles de IAM con la entidad principal del servicio de `eks-fargate-pods.amazonaws.com`. Si no ve ningún rol, debe crear uno. Para obtener más información, consulte [Rol de IAM de ejecución de pods de Amazon EKS](pod-execution-role.md).

   1. Modifique las **Subredes** seleccionadas según sea necesario.
**nota**  
Solo las subredes privadas son compatibles con los pods que se ejecutan en Fargate.

   1. En **Etiquetas**, puede etiquetar su perfil de Fargate si lo desea. Estas etiquetas no se propagan a otros recursos asociados con el perfil, como los pods.

   1. Elija **Siguiente**.

1. En la página **Configurar la selección de pods**, haga lo siguiente:

   1. En **Espacio de nombres**, ingrese un espacio de nombres que coincida con los pods.
      + Puede usar espacios de nombres específicos para que coincidan, como `kube-system` o `default`.
      + Puede usar ciertos comodines (por ejemplo, `prod-*`) para que coincidan con varios espacios de nombres (por ejemplo, `prod-deployment` y `prod-test`). Para obtener más información, consulte [Comodines de perfil de Fargate](fargate-profile.md#fargate-profile-wildcards).

   1. (Opcional) Agregue etiquetas de Kubernetes al selector. Agréguelos específicamente al selector con el que deben coincidir los pods del espacio de nombres especificado.
      + Puede agregar la etiqueta `infrastructure: fargate` al selector para que solo los pods del espacio de nombres especificado que también tengan la etiqueta `infrastructure: fargate` de Kubernetes coincidan con el selector.
      + Puede usar ciertos comodines (por ejemplo, `key?: value?`) para que coincidan con varios espacios de nombres (por ejemplo, `keya: valuea` y `keyb: valueb`). Para obtener más información, consulte [Comodines de perfil de Fargate](fargate-profile.md#fargate-profile-wildcards).

   1. Elija **Siguiente**.

1. En la página **Revisar y crear**, revise la información de su perfil de Fargate y elija **Crear**.

## Paso 4: actualización de CoreDNS
<a name="fargate-gs-coredns"></a>

De forma predeterminada, CoreDNS está configurado para ejecutarse en la infraestructura de Amazon EC2 en clústeres de Amazon EKS. Si desea ejecutar *solo* los pods de Fargate en el clúster, complete los pasos que se describen a continuación.

**nota**  
Si ha creado el clúster con `eksctl` mediante la opción `--fargate`, entonces puede ir directamente a [Siguientes pasos](#fargate-gs-next-steps).

1. Cree un perfil de Fargate para CoreDNS con el siguiente comando. Reemplace `<my-cluster>` con su nombre de clúster, `<111122223333>` con su ID de cuenta, `<AmazonEKSFargatePodExecutionRole>` con el nombre de su rol de ejecución del pod y `<000000000000000a>`, `<000000000000000b>` y `<000000000000000c>` con los ID de las subredes privadas. Si no tiene un rol de ejecución de pods, debe crear uno antes (consulte [Paso 2: creación de un rol de ejecución de pods de Fargate](#fargate-sg-pod-execution-role)).
**importante**  
El ARN de rol no puede incluir una [ruta de acceso](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-friendly-names) que no sea `/`. Por ejemplo, si el nombre de su rol es `development/apps/AmazonEKSFargatePodExecutionRole`, tendrá que cambiarlo a `AmazonEKSFargatePodExecutionRole` cuando especifique el ARN del rol. El formato del ARN del rol debe ser ` arn:aws:iam::<111122223333>:role/<AmazonEKSFargatePodExecutionRole>`.

   ```
   aws eks create-fargate-profile \
       --fargate-profile-name coredns \
       --cluster-name <my-cluster> \
       --pod-execution-role-arn arn:aws:iam::<111122223333>:role/<AmazonEKSFargatePodExecutionRole> \
       --selectors namespace=kube-system,labels={k8s-app=kube-dns} \
       --subnets subnet-<000000000000000a> subnet-<000000000000000b> subnet-<000000000000000c>
   ```

1. Active un despliegue de la implementación `coredns`.

   ```
   kubectl rollout restart -n kube-system deployment coredns
   ```

## Siguientes pasos
<a name="fargate-gs-next-steps"></a>
+ Puede comenzar a migrar las aplicaciones existentes para que se ejecuten en Fargate con el siguiente flujo de trabajo.

  1.  [Creación de un perfil de Fargate](fargate-profile.md#create-fargate-profile) que coincida con el espacio de nombres de Kubernetes y las etiquetas de Kubernetes de su aplicación.

  1. Elimine y vuelva a crear los pods existentes para que se programen en Fargate. Modifique `<namespace>` y `<deployment-type>` para actualizar sus pods específicos.

     ```
     kubectl rollout restart -n <namespace> deployment <deployment-type>
     ```
+ Implemente [Redirección de tráfico de aplicaciones y HTTP con los equilibradores de carga de aplicaciones](alb-ingress.md) para permitir que los objetos de entrada de los pods se ejecuten en Fargate.
+ Puede utilizar el [Ajuste de los recursos del pod con el escalador automático vertical de pods](vertical-pod-autoscaler.md) para medir correctamente inicialmente el tamaño de la CPU y la memoria de los pods de Fargate y, a continuación, utilizar el [Escalado de las implementaciones de pods con el escalador automático de pods horizontales](horizontal-pod-autoscaler.md) para escalar esos pods. Si desea que el Escalador automático vertical de pods vuelva a implementar automáticamente los pods en Fargate con combinaciones de CPU y memoria mayores, configure el modo del Escalador automático vertical de pods en `Auto` o `Recreate`. Esto es para garantizar una funcionalidad correcta. Para obtener más información, consulte el documento [Escalador automático vertical de pods](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#quick-start) en GitHub.
+ Puede configurar el recopilador [AWS Distro for OpenTelemetry](https://aws.amazon.com/otel) (ADOT) para el monitoreo de aplicaciones siguiendo [estas instrucciones](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-EKS-otel.html).

# Cómo definir los pods que deben lanzarse en AWS Fargate
<a name="fargate-profile"></a>

Antes de programar pods en Fargate en el clúster, debe definir al menos un perfil de Fargate que especifique qué pods utilizan Fargate cuando se lanzan.

Como administrador, puede utilizar un perfil de Fargate para declarar qué pods se ejecutan en Fargate. Puede hacerlo a través de los selectores del perfil. Puede agregar hasta cinco selectores a cada perfil. Cada selector debe contener un espacio de nombres. El selector también puede incluir etiquetas. El campo de etiqueta consta de varios pares de clave-valor opcionales. Los pods que coinciden con un selector se programan en Fargate. Los pods se comparan mediante un espacio de nombres y las etiquetas que se especifican en el selector. Si se define un selector de espacio de nombres sin etiquetas, Amazon EKS intenta programar todos los pods que se ejecutan en ese espacio de nombres en Fargate mediante el perfil. Si un pod programado coincide con alguno de los selectores del perfil de Fargate, ese pod se programa en Fargate.

Si un pod coincide con varios perfiles de Fargate, puede especificar qué perfil utiliza un pod al agregar la siguiente etiqueta de Kubernetes a la especificación del pod: `eks.amazonaws.com/fargate-profile: my-fargate-profile`. El pod debe coincidir con un selector en ese perfil para que se pueda programar en Fargate. Las reglas de afinidad y antiafinidad de Kubernetes no se aplican y no son necesarias con los pods de Fargate de Amazon EKS.

Cuando se crea un perfil de Fargate, se debe especificar un rol de ejecución de pods. Este rol de ejecución es para los componentes de Amazon EKS que se ejecutan en la infraestructura de Fargate mediante el perfil. Se agrega al [control de acceso basado en roles (RBAC)](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) de Kubernetes del clúster para la autorización. De este modo, el `kubelet` que se ejecuta en la infraestructura de Fargate puede registrarse en su clúster de Amazon EKS y aparecer en su clúster como un nodo. El rol de ejecución de pods también proporciona permisos de IAM a la infraestructura de Fargate para permitir el acceso de lectura a los repositorios de imágenes de Amazon ECR. Para obtener más información, consulte [Rol de IAM de ejecución de pods de Amazon EKS](pod-execution-role.md).

Los perfiles de Fargate no se pueden cambiar. Sin embargo, puede crear un nuevo perfil actualizado para reemplazar un perfil existente y, a continuación, eliminar el original.

**nota**  
Los pods que se están ejecutando con un perfil de Fargate se detienen y pasan a un estado pendiente cuando se elimina el perfil.

Si el estado de alguno de los perfiles de Fargate de un clúster es `DELETING`, hay que esperar a que se borre el perfil de Fargate antes de crear otros perfiles en ese clúster.

**nota**  
Fargate actualmente no admite [topologySpreadConstraints](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/) de Kubernetes.

Amazon EKS y Fargate distribuyen los pods en cada una de las subredes definidas en el perfil de Fargate. Sin embargo, es posible que acabe con una propagación desigual. Si debe tener una propagación uniforme, utilice dos perfiles de Fargate. Es importante una propagación uniforme en los escenarios en los que se desea desplegar dos réplicas y no se desea ningún tiempo de inactividad. Se recomienda que cada perfil tenga solo una subred.

## Componentes de un perfil de Fargate
<a name="fargate-profile-components"></a>

Un perfil de Fargate consta de los siguientes componentes.

 **Rol de ejecución de pods**   
Cuando el clúster crea pods en AWS Fargate, el `kubelet` que se ejecuta en la infraestructura de Fargate debe hacer llamadas a las API de AWS en su nombre. Por ejemplo, necesita hacer llamadas para extraer imágenes del contenedor de Amazon ECR. El rol de ejecución de pods de Amazon EKS proporciona los permisos de IAM para esta tarea.  
Al crear un perfil de Fargate, debe especificar un rol de ejecución de pods para utilizarlo con los pods. Este rol se agrega al [control de acceso basado en roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) de Kubernetes del clúster para su autorización. De este modo, el `kubelet` que se está ejecutando en la infraestructura de Fargate puede registrarse en el clúster de Amazon EKS y aparecer en el clúster como un nodo. Para obtener más información, consulte [Rol de IAM de ejecución de pods de Amazon EKS](pod-execution-role.md).

 **Subredes**   
Los identificadores de las subredes en las que se lanzarán los pods que utilizan este perfil. En este momento, a los pods que se ejecutan en Fargate no se les asignan direcciones IP públicas. Por lo tanto, para este parámetro solo se aceptan subredes privadas que no tengan una ruta directa a una puerta de enlace de Internet.

 **Selectores**   
Los selectores que deben coincidir para que los pods utilicen este perfil de Fargate. Puede especificar hasta cinco selectores en un perfil Fargate. Los selectores tienen los siguientes componentes:  
+  **Espacio de nombres**: debe especificar un espacio de nombres para un selector. El selector solo coincide con los pods que se crean en este espacio de nombres. Sin embargo, puede crear varios selectores para orientar varios espacios de nombres.
+  **Etiquetas**: si lo desea, puede especificar etiquetas de Kubernetes que coincidan con el selector. El selector solo coincide con los pods que tienen todas las etiquetas especificadas en el selector.

## Comodines de perfil de Fargate
<a name="fargate-profile-wildcards"></a>

Además de los caracteres permitidos por Kubernetes, se permite utilizar `*` y `?` en los criterios del selector para los espacios de nombres, las claves de las etiquetas y los valores de las etiquetas:
+  `*` representa ninguno, uno o varios caracteres. Por ejemplo, `prod*` puede representar `prod` y `prod-metrics`.
+  `?` representa un solo carácter (por ejemplo, `value?` puede representar `valuea`). Sin embargo, no puede representar `value` y `value-a`, porque `?` solo puede representar exactamente un carácter.

Estos caracteres comodín se pueden usar en cualquier posición y en combinación (por ejemplo, `prod*`, `*dev` y `frontend*?`). No se admiten otros comodines ni formas de coincidencia de patrones, como las expresiones regulares.

Si hay varios perfiles que coinciden con el espacio de nombres y las etiquetas en la especificación del pod, Fargate elige el perfil según la clasificación alfanumérica por nombre de perfil. Por ejemplo, si tanto el perfil A (con el nombre `beta-workload`) como el perfil B (con el nombre `prod-workload`) tienen selectores coincidentes para los pods que se lanzarán, Fargate elige el perfil A (`beta-workload`) para los pods. Los pods tienen etiquetas con el perfil A en los pods (por ejemplo, `eks.amazonaws.com/fargate-profile=beta-workload`).

Si desea migrar los pods de Fargate existentes a los nuevos perfiles que utilizan comodines, hay dos maneras de hacerlo:
+ Cree un nuevo perfil con los selectores correspondientes y, a continuación, elimine los perfiles antiguos. Los pods etiquetados con perfiles antiguos se reprograman con nuevos perfiles coincidentes.
+ Si quiere migrar cargas de trabajo, pero no sabe con seguridad qué etiquetas de Fargate hay en cada pod de Fargate, puede utilizar el siguiente método. Cree un nuevo perfil con un nombre que se ordene alfanuméricamente en primer lugar entre los perfiles del mismo clúster. A continuación, recicle los pods de Fargate que deban migrar a nuevos perfiles.

## Creación de un perfil de Fargate
<a name="create-fargate-profile"></a>

En esta sección se explica cómo crear un perfil de Fargate. También debe haber creado un rol de ejecución de pods para utilizarlo en su perfil de Fargate. Para obtener más información, consulte [Rol de IAM de ejecución de pods de Amazon EKS](pod-execution-role.md). Los pods que se ejecutan en Fargate solo se admiten en subredes privadas con acceso a la [puerta de enlace de NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) a AWS, pero no una ruta directa a una puerta de enlace de Internet. Esto es para que la VPC de su clúster tenga subredes privadas disponibles.

Para crear un perfil puede realizar lo siguiente:
+  [`eksctl`](#eksctl_create_a_fargate_profile) 
+  [Consola de administración de AWS](#console_create_a_fargate_profile) 

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

 **Para crear un perfil de Fargate con `eksctl` ** 

Cree el perfil de Fargate con el siguiente comando de `eksctl` y reemplace cada valor de ejemplo con valores propios. Debe especificar un espacio de nombres. Sin embargo, la opción `--labels` no es obligatoria.

```
eksctl create fargateprofile \
    --cluster my-cluster \
    --name my-fargate-profile \
    --namespace my-kubernetes-namespace \
    --labels key=value
```

Puede usar ciertos comodines para las etiquetas `my-kubernetes-namespace` y `key=value`. Para obtener más información, consulte [Comodines de perfil de Fargate](#fargate-profile-wildcards).

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

 **Para crear un perfil de Fargate con 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 para el que desea crear un perfil de Fargate.

1. Elija la pestaña **Computación**.

1. En **Perfiles de Fargate**, elija **Agregar perfil de Fargate**.

1. En la página **Configurar perfil de Fargate**, haga lo siguiente:

   1. En **Name** (Nombre), ingrese un nombre único para su perfil de Fargate; por ejemplo, `my-profile`.

   1. En **Rol de ejecución de pods**, elija el rol de ejecución de pods que se va a utilizar con el perfil de Fargate. Solo se muestran los roles de IAM con la entidad principal del servicio de `eks-fargate-pods.amazonaws.com`. Si no ve ningún rol, debe crear uno. Para obtener más información, consulte [Rol de IAM de ejecución de pods de Amazon EKS](pod-execution-role.md).

   1. Modifique las **Subredes** seleccionadas según sea necesario.
**nota**  
Solo las subredes privadas son compatibles con los pods que se ejecutan en Fargate.

   1. En **Etiquetas**, puede etiquetar su perfil de Fargate si lo desea. Estas etiquetas no se propagan a otros recursos asociados con el perfil, como los pods.

   1. Elija **Siguiente**.

1. En la página **Configurar la selección de pods**, haga lo siguiente:

   1. En **Espacio de nombres**, ingrese un espacio de nombres que coincida con los pods.
      + Puede usar espacios de nombres específicos para que coincidan, como `kube-system` o `default`.
      + Puede usar ciertos comodines (por ejemplo, `prod-*`) para que coincidan con varios espacios de nombres (por ejemplo, `prod-deployment` y `prod-test`). Para obtener más información, consulte [Comodines de perfil de Fargate](#fargate-profile-wildcards).

   1. (Opcional) Agregue etiquetas de Kubernetes al selector. Agréguelos específicamente al selector con el que deben coincidir los pods del espacio de nombres especificado.
      + Puede agregar la etiqueta `infrastructure: fargate` al selector para que solo los pods del espacio de nombres especificado que también tengan la etiqueta `infrastructure: fargate` de Kubernetes coincidan con el selector.
      + Puede usar ciertos comodines (por ejemplo, `key?: value?`) para que coincidan con varios espacios de nombres (por ejemplo, `keya: valuea` y `keyb: valueb`). Para obtener más información, consulte [Comodines de perfil de Fargate](#fargate-profile-wildcards).

   1. Elija **Siguiente**.

1. En la página **Revisar y crear**, revise la información de su perfil de Fargate y elija **Crear**.

# Eliminación de un perfil de Fargate
<a name="delete-fargate-profile"></a>

En este tema se explica cómo eliminar un perfil de Fargate. Al eliminar un perfil de Fargate, se eliminan todos los pods que se programaron en Fargate con el perfil. Si esos pods coinciden con otro perfil de Fargate, se programan en Fargate con ese perfil. Si ya no coinciden con ningún perfil de Fargate, significa que no están programados en Fargate y pueden permanecer como pendientes.

Solo un perfil de Fargate de un clúster puede tener el estado `DELETING` a la vez. Espere a que un perfil de Fargate termine de eliminarse para poder eliminar cualquier otro perfil de ese clúster.

Puede eliminar perfiles con cualquiera de las siguientes herramientas:
+  [`eksctl`](#eksctl_delete_a_fargate_profile) 
+  [Consola de administración de AWS](#console_delete_a_fargate_profile) 
+  [AWS CLI](#awscli_delete_a_fargate_profile) 

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

 **Elimine un perfil de Fargate con `eksctl` ** 

Utilice el siguiente comando para eliminar un perfil de un clúster. Reemplace los *valores de ejemplo* por sus propios valores.

```
eksctl delete fargateprofile  --name my-profile --cluster my-cluster
```

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

 **Elimine un perfil de Fargate con Consola de administración de AWS ** 

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

1. En el panel de navegación izquierdo, elija **Clusters (Clústeres)**. En la lista de clústeres, elija el clúster del que desea eliminar el perfil de Fargate.

1. Elija la pestaña **Computación**.

1. Elija el perfil de Fargate que desea eliminar y, a continuación, elija **Delete** (Eliminar).

1. En la página **Delete Fargate Profile** (Eliminar perfil de Fargate), ingrese el nombre del perfil y, a continuación, elija **Delete** (Eliminar).

## AWS CLI
<a name="awscli_delete_a_fargate_profile"></a>

 **Elimine un perfil de Fargate con la AWS CLI** 

Utilice el siguiente comando para eliminar un perfil de un clúster. Reemplace los *valores de ejemplo* por sus propios valores.

```
aws eks delete-fargate-profile --fargate-profile-name my-profile --cluster-name my-cluster
```

# Descripción de los detalles de configuración de pods de Fargate
<a name="fargate-pod-configuration"></a>

En esta sección se describen algunos de los detalles de configuración únicos de los pods para ejecutar pods de Kubernetes en AWS Fargate.

## Memoria y CPU de los pods
<a name="fargate-cpu-and-memory"></a>

Con Kubernetes, puede definir solicitudes, una cantidad mínima de vCPU y recursos de memoria que se asignan a cada contenedor en un pod. Kubernetes programa los pods para garantizar que al menos los recursos solicitados para cada pod estén disponibles en el recurso informático. Para obtener más información, consulte la [administración de recursos de computación para contenedores](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/) en la documentación de Kubernetes.

**nota**  
Dado que Amazon EKS Fargate ejecuta solo un pod por nodo, no se produce el escenario de expulsión de pods en caso de menos recursos. Todos los pods de Amazon EKS Fargate se ejecutan con prioridad garantizada, por lo que la CPU y la memoria solicitadas deben ser iguales al límite de todos los contenedores. A fin de obtener más información, consulte [Configurar la calidad del servicio para los pods](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/) en la documentación de Kubernetes.

Cuando los pods están programados en Fargate, las reservas de vCPU y memoria dentro de la especificación del pod determinan cuánta CPU y memoria se debe aprovisionar para el pod.
+ La solicitud máxima de cualquier contenedor Init se utiliza para determinar los requisitos de vCPU y de memoria de la solicitud Init.
+ Las solicitudes para todos los contenedores de larga duración se suman para determinar los requisitos de memoria y vCPU de las solicitudes de larga duración.
+ El mayor de los dos valores anteriores se elige para la solicitud de vCPU y de memoria que se utilizará para el pod.
+ Fargate agrega 256 MB a la reserva de memoria de cada pod para los componentes requeridos de Kubernetes (`kubelet`, `kube-proxy` y `containerd`).

Fargate redondea hasta la siguiente configuración de computación que más se acerque a la suma de las solicitudes de vCPU y memoria para garantizar que los pods siempre tengan los recursos que necesitan para ejecutarse.

Si no especifica una combinación de vCPU y memoria, se utilizará la combinación más chica disponible (0,25 vCPU y 0,5 GB de memoria).

En la siguiente tabla se muestran las combinaciones de vCPU y memoria disponibles para los pods que se ejecutan en Fargate.


| Valor de vCPU | Valor de memoria | 
| --- | --- | 
|  0,25 vCPU  |  0,5 GB, 1 GB, 2 GB  | 
|  0,5 vCPU  |  1 GB, 2 GB, 3 GB, 4 GB  | 
|  1 vCPU  |  2 GB, 3 GB, 4 GB, 5 GB, 6 GB, 7 GB, 8 GB  | 
|  2 vCPU  |  Entre 4 GB y 16 GB en incrementos de 1 GB  | 
|  4 vCPU  |  Entre 8 GB y 30 GB en incrementos de 1 GB  | 
|  8 vCPU  |  Entre 16 GB y 60 GB en incrementos de 4 GB  | 
|  16 vCPU  |  Entre 32 GB y 120 GB en incrementos de 8 GB  | 

La memoria adicional reservada para los componentes de Kubernetes puede generar una tarea de Fargate con más vCPU de las que se solicitaron aprovisionar. Por ejemplo, una solicitud de 1 vCPU y 8 GB de memoria tendrá 256 MB agregados a su solicitud de memoria y aprovisionará una tarea de Fargate con 2 vCPU y 9 GB de memoria, ya que no hay ninguna tarea con 1 vCPU y 9 GB de memoria disponible.

No hay correlación entre el tamaño del pod que se ejecuta en Fargate y el tamaño del nodo informado por Kubernetes con `kubectl get nodes`. El tamaño del nodo informado suele ser mayor que la capacidad del pod. Puede verificar la capacidad de los pods con el siguiente comando. Reemplace *default* por el espacio de nombres del pod y *pod-name* por el nombre del pod.

```
kubectl describe pod --namespace default pod-name
```

Un ejemplo de salida sería el siguiente.

```
[...]
annotations:
    CapacityProvisioned: 0.25vCPU 0.5GB
[...]
```

La anotación `CapacityProvisioned` representa la capacidad del pod forzada y determina el costo del pod que se ejecuta en Fargate. Para obtener información sobre los precios de las configuraciones informáticas, consulte [Precios de AWS Fargate](https://aws.amazon.com/fargate/pricing/).

## Almacenamiento de Fargate
<a name="fargate-storage"></a>

Un pod que se ejecuta en Fargate monta automáticamente un sistema de archivos de Amazon EFS, sin necesidad de seguir pasos manuales para la instalación de controladores. No se puede utilizar el aprovisionamiento dinámico de volúmenes persistentes con nodos de Fargate, pero se puede utilizar el aprovisionamiento estático. Para obtener más información, consulte [Controlador de CSI de Amazon EFS](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/docs/README.md) en GitHub.

Cuando se aprovisiona, cada pod que se ejecuta en Fargate recibe un almacenamiento efímero predeterminado de 20 GiB. Este tipo de almacenamiento se elimina después de que un pod se detenga. Los nuevos pods lanzados en Fargate tienen el cifrado del volumen de almacenamiento efímero habilitado de forma predeterminada. El almacenamiento de pod efímero se cifra con un algoritmo de cifrado AES-256 mediante claves administradas por AWS Fargate.

**nota**  
El almacenamiento utilizable predeterminado para pods de Amazon EKS que se ejecuta en Fargate tiene menos de 20 GiB. Esto se debe a que parte del espacio lo utilizan `kubelet` y otros módulos de Kubernetes que se cargan dentro del pod.

La cantidad total de almacenamiento efímero se puede aumentar hasta un máximo de 175 GiB. Para configurar el tamaño con Kubernetes, especifique las solicitudes del recurso de `ephemeral-storage` para cada contenedor en un pod. Cuando Kubernetes programa pods, asegura que la suma de las solicitudes de recursos para cada pod es inferior a la capacidad de la tarea de Fargate. Para obtener más información, consulte [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/) en la documentación de Kubernetes.

Amazon EKS Fargate proporciona más almacenamiento efímero del solicitado para el uso del sistema. Por ejemplo, una solicitud de 100 GiB aprovisionará una tarea de Fargate con 115 GiB de almacenamiento efímero.

# Definición de acciones para los eventos de aplicación de revisiones del sistema operativo de AWS Fargate
<a name="fargate-pod-patching"></a>

Amazon EKS debe aplicar parches periódicamente del sistema operativo para los nodos de AWS Fargate a fin de mantenerlos seguros. Como parte del proceso de aplicación de parches, reciclamos los nodos para instalar los parches del sistema operativo. Las actualizaciones se intentan de tal manera que se produzca el menor impacto en sus servicios. Sin embargo, si los pods no se expulsan correctamente, hay ocasiones en que deben eliminarse. A continuación, se muestran las acciones que puede realizar para minimizar las posibles interrupciones:
+ Establezca los presupuestos de interrupción de pods (PDB) adecuados para controlar el número de pods que están inactivos simultáneamente.
+ Cree reglas de Amazon EventBridge para controlar las expulsiones fallidas antes de que se eliminen los pods.
+ Reinicie manualmente los pods afectados antes de la fecha de expulsión que se indica en la notificación que reciba.
+ Cree una configuración de notificaciones en Notificaciones de usuario de AWS.

Amazon EKS trabaja en estrecha colaboración con la comunidad de Kubernetes para que las correcciones de errores y los parches de seguridad estén disponibles lo antes posible. Todos los pods de Fargate empiezan en la versión de parche de Kubernetes más recientes, que está disponible en Amazon EKS para la versión de Kubernetes de su clúster. Si tiene un pod con una versión de parche anterior, Amazon EKS podría reciclarlo para actualizarlo a la última versión. Esto garantiza que los pods estén equipados con las últimas actualizaciones de seguridad. De esa forma, si hay un problema de [Vulnerabilidades y exposiciones comunes](https://cve.mitre.org/) (CVE) crítico, estará al tanto para reducir los riesgos de seguridad.

Cuando se actualice el sistema operativo de AWS Fargate, Amazon EKS enviará una notificación que incluirá los recursos afectados y la fecha de las próximas expulsiones de pods. Si la fecha de expulsión prevista resulta inoportuna, es posible reiniciar manualmente los pods afectados antes de la fecha de expulsión indicada en la notificación. Todos los pods creados antes del momento en que reciba la notificación están sujetos a expulsión. Consulte la [documentación de Kubernetes](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_rollout/kubectl_rollout_restart) para obtener más instrucciones sobre cómo reiniciar manualmente los pods.

Para limitar el número de pods que están inactivos al mismo tiempo cuando se reciclan pods, puede establecer presupuestos de interrupción de pods (PDB). Puede utilizar PDB para definir la disponibilidad mínima en función de los requisitos de cada una de las aplicaciones y, al mismo tiempo, permitir que se produzcan actualizaciones. La disponibilidad mínima de PDB debe ser inferior al 100 %. Para obtener más información, consulte [Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/) en la documentación de Kubernetes.

Amazon EKS utiliza la [API de expulsión](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/#eviction-api) para drenar el pod de forma segura a la vez que se respetan los PDB que configuró para la aplicación. La zona de disponibilidad expulsa los pods para minimizar el impacto. Si la expulsión tiene éxito, el nuevo pod obtiene el parche más reciente y no será necesario llevar a cabo más acciones.

Cuando falla la expulsión de un pod, Amazon EKS envía un evento a su cuenta con detalles sobre los pods que han fallado la expulsión. Puede actuar en función del mensaje antes de la hora de finalización programada. El tiempo específico varía según la urgencia del parche. Cuando llega el momento, Amazon EKS intenta expulsar de nuevo los pods. Sin embargo, esta vez no se envía un nuevo evento si la expulsión falla. Si la expulsión vuelve a fallar, los pods existentes se eliminan periódicamente para que los nuevos pods puedan tener el último parche.

A continuación, se muestra un evento de ejemplo recibido cuando falla la expulsión de pods. Contiene detalles sobre el clúster, el nombre del pod, el espacio de nombres del pod, el perfil de Fargate y la hora de finalización programada.

```
{
    "version": "0",
    "id": "12345678-90ab-cdef-0123-4567890abcde",
    "detail-type": "EKS Fargate Pod Scheduled Termination",
    "source": "aws.eks",
    "account": "111122223333",
    "time": "2021-06-27T12:52:44Z",
    "region": "region-code",
    "resources": [
        "default/my-database-deployment"
    ],
    "detail": {
        "clusterName": "my-cluster",
        "fargateProfileName": "my-fargate-profile",
        "podName": "my-pod-name",
        "podNamespace": "default",
        "evictErrorMessage": "Cannot evict pod as it would violate the pod's disruption budget",
        "scheduledTerminationTime": "2021-06-30T12:52:44.832Z[UTC]"
    }
}
```

Además, tener varios PDB asociados a un pod puede provocar un error de expulsión. Este evento devuelve el siguiente mensaje de error.

```
"evictErrorMessage": "This pod has multiple PodDisruptionBudget, which the eviction subresource does not support",
```

Puede crear una acción deseada basada en este evento. Por ejemplo, puede ajustar el presupuesto de interrupción de pods (PDB) para controlar cómo se expulsan los pods. Más concretamente, supongamos que empieza con un PDB que especifica el porcentaje objetivo de pods que están disponibles. Antes de que los pods finalicen forzosamente durante una actualización, puede ajustar el PDB a un porcentaje diferente de pods. Para recibir este evento, debe crear una regla de Amazon EventBridge en la cuenta de AWS y la región de AWS a la que pertenece el clúster. La regla debe utilizar el siguiente **patrón personalizado**. Para obtener más información, consulte [Creación de reglas de EventBridge que reaccionan a eventos](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html) en la *Guía del usuario de Amazon EventBridge*.

```
{
  "source": ["aws.eks"],
  "detail-type": ["EKS Fargate Pod Scheduled Termination"]
}
```

Se puede establecer un objetivo adecuado para que el evento lo capture. Para obtener una lista completa de los destinos admitidos, consulte [Destinos de Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html) en la *Guía del usuario de Amazon EventBridge*. También puede crear una configuración de notificaciones en Notificaciones de usuario de AWS. Al utilizar la Consola de administración de AWS para crear la notificación, en **Reglas de eventos**, seleccione **Elastic Kubernetes Service (EKS)** para el ** AWS nombre del servicio** y **Terminación programada de EKS Fargate Pod** para el **tipo de evento**. Para obtener más información, consulte [Introducción a las notificaciones de usuario de AWS](https://docs.aws.amazon.com/notifications/latest/userguide/getting-started.html) en la Guía de usuario de notificaciones de usuario de AWS.

Consulte [Preguntas frecuentes: notificación de expulsión del pod de Fargate](https://repost.aws/knowledge-center/fargate-pod-eviction-notice) en *AWS re:Post* para consultar las preguntas más frecuentes sobre las expulsiones del pod de EKS.

# Recopilación de métricas de uso y aplicación de AWS Fargate
<a name="monitoring-fargate-usage"></a>

Puede recopilar métricas del sistema y métricas de uso de CloudWatch para AWS Fargate.

## Métricas de aplicación
<a name="fargate-application-metrics"></a>

Para aplicaciones que se ejecutan en Amazon EKS y AWS Fargate, puede utilizar AWS Distro para OpenTelemetry (ADOT). ADOT le permite recopilar métricas del sistema y enviarlas a los paneles de CloudWatch Container Insights. Para empezar a utilizar ADOT para aplicaciones que se ejecutan en Fargate, consulte [Using CloudWatch Container Insights with AWS Distro for OpenTelemetry](https://aws-otel.github.io/docs/getting-started/container-insights) (Uso de CloudWatch Container Insights con Distro for OpenTelemetry) en la documentación de ADOT.

## Métricas de uso
<a name="fargate-usage-metrics"></a>

Puede utilizar las métricas de uso de CloudWatch para proporcionar visibilidad sobre el uso de los recursos de su cuenta. Utilice estas métricas para visualizar el uso actual del servicio en paneles y gráficos de CloudWatch.

 Las métricas de uso de AWS Fargate se corresponden con las Service Quotas de servicio de AWS. Puede configurar alarmas que le avisen cuando su uso se acerque a una Service Quota. Para obtener más información acerca de las cuotas de servicio de Fargate, consulte [Visualización y administración de Amazon EKS y las Service Quotas de Fargate](service-quotas.md).

 AWS Fargate publica las siguientes métricas en el espacio de nombres ` AWS/Usage`.


| Métrica | Descripción | 
| --- | --- | 
|   `ResourceCount`   |  El número total de los recursos especificados que se ejecutan en su cuenta. Los recursos se definen por las dimensiones asociadas a la métrica.  | 

Las siguientes dimensiones se utilizan para ajustar las métricas de uso que publica AWS Fargate.


| Dimensión | Descripción | 
| --- | --- | 
|   `Service`   |  El nombre del servicio de AWS que contiene el recurso. Para las métricas de uso de AWS Fargate, el valor de esta dimensión es `Fargate`.  | 
|   `Type`   |  El tipo de entidad que se notifica. Actualmente, el único valor válido para las métricas de uso de AWS Fargate es `Resource`.  | 
|   `Resource`   |  El tipo de recurso que se ejecuta. En la actualidad, AWS Fargate devuelve información sobre la utilización bajo demanda de Fargate. El valor de recurso para la utilización bajo demanda de Fargate es `OnDemand`. [NOTA] ==== El uso bajo demanda de Fargate combina los pods de Amazon EKS que utilizan Fargate, las tareas de Amazon ECS que utilizan el tipo de lanzamiento de Fargate y las tareas de Amazon ECS que utilizan el proveedor de capacidad de `FARGATE`. ====  | 
|   `Class`   |  La clase de recurso a la que se realiza el seguimiento. En la actualidad, AWS Fargate no utiliza la dimensión de clase.  | 

### Creación de una alarma de CloudWatch para monitorear las métricas de uso de recursos de Fargate
<a name="service-quota-alarm"></a>

 AWS Fargate proporciona métricas de uso de CloudWatch que corresponden a las Service Quotas de AWS para el uso de recursos bajo demanda de Fargate. En la consola de Service Quotas, puede ver el uso en un gráfico. También puede configurar alarmas que le avisen cuando su uso se acerque a una cuota de servicio. Para obtener más información, consulte [Recopilación de métricas de uso y aplicación de AWS Fargate](#monitoring-fargate-usage).

Siga estos pasos para crear una alarma de CloudWatch basada en las métricas de uso de recursos de Fargate.

1. Abra la consola de Service Quotas en https://console.aws.amazon.com/servicequotas/.

1. En el panel de navegación de la izquierda, elija **Servicios de AWS**.

1. En la lista **Servicios de AWS**, busque y seleccione **AWS Fargate**.

1. En la lista **Service quotas** (Cuotas de servicio), elija la cuota de utilización de Fargate para la que desee crear una alarma.

1. En la sección Amazon CloudWatch alarms (Alarmas de Amazon CloudWatch), elija **Create** (Crear).

1. En **Alarm threshold (Umbral de alarma)**, elija el porcentaje del valor de la cuota aplicada que desee establecer como valor de la alarma.

1. En **Alarm name (Nombre de la alarma)**, escriba el nombre de la alarma y elija **Create (Crear)**.

# Inicio del registro de AWS Fargate para un clúster
<a name="fargate-logging"></a>

Amazon EKS en Fargate ofrece un enrutador de registros integrado basado en Fluent Bit. Esto significa que no ejecuta explícitamente un contenedor de Fluent Bit como archivo sidecar, sino que Amazon lo ejecuta. Todo lo que tiene que hacer es configurar el enrutador de registros. La configuración se realiza a través de un `ConfigMap` dedicado que debe cumplir los siguientes criterios:
+ Tener un `aws-logging` con nombre. 
+ Haber sido creado en un espacio de nombres dedicado llamado `aws-observability`. 
+ No puede superar los 5300 caracteres.

Una vez que haya creado el `ConfigMap`, Amazon EKS en Fargate lo detecta automáticamente y configura el enrutador de registros con él. Fargate utiliza una versión de AWS para Fluent Bit, una distribución conforme del cliente al servidor de Fluent Bit administrada por AWS. Para obtener más información, consulte [AWS para Fluent Bit](https://github.com/aws/aws-for-fluent-bit) en GitHub.

El enrutador de registros le permite utilizar la amplia gama de servicios de AWS para el análisis y el almacenamiento de registros. Puede transmitir registros desde Fargate directamente a Amazon CloudWatch, Amazon OpenSearch Service. También puede transmitir registros a destinos como [Amazon S3](https://aws.amazon.com/s3/), [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) y herramientas de socios a través de [Amazon Data Firehose](https://aws.amazon.com/kinesis/data-firehose/).
+ Un perfil de Fargate existente que especifica un espacio de nombres de Kubernetes existente en el que se implementan pods de Fargate. Para obtener más información, consulte [Paso 3: creación de un perfil de Fargate para el clúster](fargate-getting-started.md#fargate-gs-create-profile).
+ Un rol de ejecución de pods de Fargate existente. Para obtener más información, consulte [Paso 2: creación de un rol de ejecución de pods de Fargate](fargate-getting-started.md#fargate-sg-pod-execution-role).

## Configuración del enrutador de registros
<a name="fargate-logging-log-router-configuration"></a>

**importante**  
Para que los registros se publiquen correctamente, debe haber acceso de red desde la VPC en la que se encuentra el clúster hasta el destino de los registros. Esto se aplica principalmente a los usuarios que personalizan las reglas de salida de la VPC. Para ver un ejemplo con CloudWatch, consulte la sección *Uso de Registros de CloudWatch con puntos de conexión de VPC de interfaz* en la [Guía del usuario de los Registros de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-and-interface-VPC.html).

En los siguientes pasos, reemplace cada *valor de ejemplo* por valores propios.

1. Cree un espacio de nombres de Kubernetes dedicado llamado `aws-observability`.

   1. Guarde el siguiente contenido en un archivo llamado `aws-observability-namespace.yaml` en el equipo. El valor de `name` debe ser `aws-observability` y la etiqueta `aws-observability: enabled` es obligatoria.

      ```
      kind: Namespace
      apiVersion: v1
      metadata:
        name: aws-observability
        labels:
          aws-observability: enabled
      ```

   1. Cree el espacio de nombres.

      ```
      kubectl apply -f aws-observability-namespace.yaml
      ```

1. Cree un `ConfigMap` con un valor de datos de `Fluent Conf` para enviar los registros de contenedores a un destino. Fluent Conf es Fluent Bit, que es un lenguaje de configuración del procesador de registros rápido y ligero que se utiliza para dirigir los registros del contenedor a un destino de registro de su elección. Para obtener más información, consulte [Archivo de configuración](https://docs.fluentbit.io/manual/administration/configuring-fluent-bit/classic-mode/configuration-file) en la documentación de Fluent Bit.
**importante**  
En un `Fluent Conf` típico, las secciones principales incluidas son `Service`, `Input`, `Filter` y `Output`. Sin embargo, el enrutador de registros de Fargate solo acepta:  
Las secciones `Filter` y `Output`.
Una sección `Parser`.
Si proporciona otras secciones, se rechazarán.

   El enrutador de registros de Fargate administra las secciones `Service` e `Input`. Tiene la siguiente sección `Input`, la cual no se puede modificar y no es necesaria en su `ConfigMap`. Sin embargo, puede obtener información a partir de ella, como el límite del búfer de memoria y la etiqueta aplicada a los registros.

   ```
   [INPUT]
       Name tail
       Buffer_Max_Size 66KB
       DB /var/log/flb_kube.db
       Mem_Buf_Limit 45MB
       Path /var/log/containers/*.log
       Read_From_Head On
       Refresh_Interval 10
       Rotate_Wait 30
       Skip_Long_Lines On
       Tag kube.*
   ```

   Al crear el `ConfigMap`, debe tener en cuenta las siguientes reglas que Fargate utiliza para validar campos:
   +  Se supone que `[FILTER]`, `[OUTPUT]` y `[PARSER]` deben especificarse en cada clave correspondiente. Por ejemplo, `[FILTER]` debe estar en `filters.conf`. Puede tener uno o más `[FILTER]` en `filters.conf`. Las secciones `[OUTPUT]` y `[PARSER]` también deben estar en sus claves correspondientes. Mediante la especificación de varias secciones `[OUTPUT]`, puede dirigir sus registros a diferentes destinos al mismo tiempo.
   + Fargate valida las claves requeridas para cada sección. `Name` y `match` son necesarias para cada `[FILTER]` y `[OUTPUT]`. `Name` y `format` son necesarias para cada `[PARSER]`. Las claves distinguen entre mayúsculas y minúsculas.
   + Las variables de entorno, como `${ENV_VAR}` no se permiten en `ConfigMap`.
   + La sangría tiene que ser la misma para la política o el par clave-valor dentro de cada `filters.conf`, `output.conf` y `parsers.conf`. Los pares clave-valor deben tener más sangría que las políticas.
   + Fargate valida con los siguientes filtros compatibles: `grep`, `parser`, `record_modifier`, `rewrite_tag`, `throttle`, `nest`, `modify` y `kubernetes`.
   + Fargate verifica las siguientes salidas compatibles: `es`, `firehose`, `kinesis_firehose`, `cloudwatch`, `cloudwatch_logs` y `kinesis`.
   + Se debe proporcionar al menos un complemento de `Output` compatible en el `ConfigMap` a fin de habilitar el registro. `Filter` y `Parser` no son necesarios para habilitar el registro.

     También puede ejecutar Fluent Bit en Amazon EC2 con la configuración deseada para solucionar cualquier problema que surja de la validación. Cree su `ConfigMap` con uno de los siguientes ejemplos.
**importante**  
El registro de Fargate de Amazon EKS no admite la configuración dinámica del `ConfigMap`. Cualquier cambio en `ConfigMap` solo se aplica a los pods nuevos. Los cambios no se aplican a los pods existentes.

     Cree un `ConfigMap` con el ejemplo para el destino de registro deseado.
**nota**  
También puede utilizar Amazon Kinesis Data Streams como destino para su registro. Si usa Kinesis Data Streams, asegúrese de que la función de ejecución del pod tenga otorgado el permiso `kinesis:PutRecords`. Para obtener más información, consulte [Permisos](https://docs.fluentbit.io/manual/pipeline/outputs/kinesis#permissions) de Amazon Kinesis Data Streams en * Fluent Bit: Manual oficial*.  
**Example**  

------
#### [ CloudWatch ]

   Tiene dos opciones de salida al utilizar CloudWatch:
   +  [Un complemento de salida escrito en C](https://docs.fluentbit.io/manual/v/1.5/pipeline/outputs/cloudwatch) 
   +  [Un complemento de salida escrito en Golang](https://github.com/aws/amazon-cloudwatch-logs-for-fluent-bit) 

   En el siguiente ejemplo se muestra cómo utilizar el complemento de `cloudwatch_logs` para enviar registros a CloudWatch.

   1. Guarde los siguientes contenidos en un archivo llamado `aws-logging-cloudwatch-configmap.yaml`. Reemplace *region-code* por la región de AWS en la que se encuentra el clúster. Se requieren los parámetros en `[OUTPUT]`.

      ```
      kind: ConfigMap
      apiVersion: v1
      metadata:
        name: aws-logging
        namespace: aws-observability
      data:
        flb_log_cw: "false"  # Set to true to ship Fluent Bit process logs to CloudWatch.
        filters.conf: |
          [FILTER]
              Name parser
              Match *
              Key_name log
              Parser crio
          [FILTER]
              Name kubernetes
              Match kube.*
              Merge_Log On
              Keep_Log Off
              Buffer_Size 0
              Kube_Meta_Cache_TTL 300s
        output.conf: |
          [OUTPUT]
              Name cloudwatch_logs
              Match   kube.*
              region region-code
              log_group_name my-logs
              log_stream_prefix from-fluent-bit-
              log_retention_days 60
              auto_create_group true
        parsers.conf: |
          [PARSER]
              Name crio
              Format Regex
              Regex ^(?<time>[^ ]+) (?<stream>stdout|stderr) (?<logtag>P|F) (?<log>.*)$
              Time_Key    time
              Time_Format %Y-%m-%dT%H:%M:%S.%L%z
      ```

   1. Aplique el manifiesto al clúster.

      ```
      kubectl apply -f aws-logging-cloudwatch-configmap.yaml
      ```

------
#### [ Amazon OpenSearch Service ]

   Si desea enviar registros a Amazon OpenSearch Service, puede utilizar la salida [es](https://docs.fluentbit.io/manual/v/1.5/pipeline/outputs/elasticsearch), que es un complemento escrito en C. En el ejemplo siguiente se muestra cómo utilizar el complemento para enviar registros a OpenSearch.

   1. Guarde los siguientes contenidos en un archivo llamado `aws-logging-opensearch-configmap.yaml`. Reemplace los *valores de ejemplo* por sus propios valores.

      ```
      kind: ConfigMap
      apiVersion: v1
      metadata:
        name: aws-logging
        namespace: aws-observability
      data:
        output.conf: |
          [OUTPUT]
            Name  es
            Match *
            Host  search-example-gjxdcilagiprbglqn42jsty66y.region-code.es.amazonaws.com
            Port  443
            Index example
            Type  example_type
            AWS_Auth On
            AWS_Region region-code
            tls   On
      ```

   1. Aplique el manifiesto al clúster.

      ```
      kubectl apply -f aws-logging-opensearch-configmap.yaml
      ```

------
#### [ Firehose ]

   Tiene dos opciones de salida al enviar registros a Firehose:
   +  [kinesis\$1firehose](https://docs.fluentbit.io/manual/pipeline/outputs/firehose): un complemento de salida escrito en C.
   +  [firehose](https://github.com/aws/amazon-kinesis-firehose-for-fluent-bit): un complemento de salida escrito en Golang.

     En el siguiente ejemplo se muestra cómo utilizar el complemento de `kinesis_firehose` para enviar registros a Firehose.

     1. Guarde los siguientes contenidos en un archivo llamado `aws-logging-firehose-configmap.yaml`. Reemplace *region-code* por la región de AWS en la que se encuentra el clúster.

        ```
        kind: ConfigMap
        apiVersion: v1
        metadata:
          name: aws-logging
          namespace: aws-observability
        data:
          output.conf: |
            [OUTPUT]
             Name  kinesis_firehose
             Match *
             region region-code
             delivery_stream my-stream-firehose
        ```

     1. Aplique el manifiesto al clúster.

        ```
        kubectl apply -f aws-logging-firehose-configmap.yaml
        ```

------

1. Configure los permisos del rol de ejecución de pods en Fargate para enviar los registros al destino correspondiente.

   1. Descargue la política de IAM para el destino en su computadora.  
**Example**  

------
#### [ CloudWatch ]

      Descargue la política de IAM de CloudWatch en su equipo. También puede ver la [política](https://raw.githubusercontent.com/aws-samples/amazon-eks-fluent-logging-examples/mainline/examples/fargate/cloudwatchlogs/permissions.json) en GitHub.

      ```
      curl -O https://raw.githubusercontent.com/aws-samples/amazon-eks-fluent-logging-examples/mainline/examples/fargate/cloudwatchlogs/permissions.json
      ```

------
#### [ Amazon OpenSearch Service ]

      Descargue la política de IAM de OpenSearch en su ordenador. También puede ver la [política](https://raw.githubusercontent.com/aws-samples/amazon-eks-fluent-logging-examples/mainline/examples/fargate/amazon-elasticsearch/permissions.json) en GitHub.

      ```
      curl -O https://raw.githubusercontent.com/aws-samples/amazon-eks-fluent-logging-examples/mainline/examples/fargate/amazon-elasticsearch/permissions.json
      ```

      Asegúrese de que el control de acceso de OpenSearch Dashboards esté configurado correctamente. El `all_access role` de OpenSearch Dashboards debe tener el rol de ejecución de pods de Fargate y el rol de IAM asignado. Se debe hacer el mismo mapeo para el rol de `security_manager`. Puede agregar los mapeos anteriores al seleccionar `Menu`, `Security` y `Roles` y, a continuación, seleccionar los roles respectivos. Para obtener más información, consulte [¿Cómo puedo solucionar los problemas de CloudWatch Logs para que transmita a mi dominio de Amazon ES?](https://aws.amazon.com/tr/premiumsupport/knowledge-center/es-troubleshoot-cloudwatch-logs/).

------
#### [ Firehose ]

      Descargue la política de IAM de Firehose en su ordenador. También puede ver la [política](https://raw.githubusercontent.com/aws-samples/amazon-eks-fluent-logging-examples/mainline/examples/fargate/kinesis-firehose/permissions.json) en GitHub.

      ```
      curl -O https://raw.githubusercontent.com/aws-samples/amazon-eks-fluent-logging-examples/mainline/examples/fargate/kinesis-firehose/permissions.json
      ```

------

   1. Cree una política de IAM a partir del archivo de política que descargó.

      ```
      aws iam create-policy --policy-name eks-fargate-logging-policy --policy-document file://permissions.json
      ```

   1. Adjunte la política de IAM al rol de ejecución de pods especificado para el perfil de Fargate con el siguiente comando. Reemplace *111122223333* por el ID de su cuenta. Reemplace *AmazonEKSFargatePodExecutionRole* por el rol de ejecución de pods (para obtener más información, consulte [Paso 2: creación de un rol de ejecución de pods de Fargate](fargate-getting-started.md#fargate-sg-pod-execution-role)).

      ```
      aws iam attach-role-policy \
        --policy-arn arn:aws:iam::111122223333:policy/eks-fargate-logging-policy \
        --role-name AmazonEKSFargatePodExecutionRole
      ```

### Compatibilidad del filtro de Kubernetes
<a name="fargate-logging-kubernetes-filter"></a>

El filtro de Kubernetes de Fluent Bit permite agregar metadatos de Kubernetes a los archivos de registro. Para obtener más información acerca del filtro, consulte [Kubernetes](https://docs.fluentbit.io/manual/pipeline/filters/kubernetes) en la documentación de Fluent Bit. Puede aplicar un filtro mediante el punto de conexión del servidor de la API.

```
filters.conf: |
    [FILTER]
        Name             kubernetes
        Match            kube.*
        Merge_Log           On
        Buffer_Size         0
        Kube_Meta_Cache_TTL 300s
```

**importante**  
 `Kube_URL`, `Kube_CA_File`, `Kube_Token_Command` y `Kube_Token_File` son parámetros de configuración propiedad del servicio y no deben especificarse. Amazon EKS Fargate completa estos valores.
 `Kube_Meta_Cache_TTL` es el tiempo que Fluent Bit espera hasta que se comunica con el servidor de la API para obtener los metadatos más recientes. Si `Kube_Meta_Cache_TTL` no se especifica, Amazon EKS Fargate agrega un valor predeterminado de 30 minutos para reducir la carga en el servidor de la API.

### Envío de registros de procesos de Fluent Bit a su cuenta
<a name="ship-fluent-bit-process-logs"></a>

Opcionalmente, puede enviar registros de procesos de Fluent Bit a Amazon CloudWatch mediante el siguiente `ConfigMap`. El envío de registros de procesos de Fluent Bit a CloudWatch requiere costos adicionales de ingesta y almacenamiento de registros. Reemplace *region-code* por la región de AWS en la que se encuentra el clúster.

```
kind: ConfigMap
apiVersion: v1
metadata:
  name: aws-logging
  namespace: aws-observability
  labels:
data:
  # Configuration files: server, input, filters and output
  # ======================================================
  flb_log_cw: "true"  # Ships Fluent Bit process logs to CloudWatch.

  output.conf: |
    [OUTPUT]
        Name cloudwatch
        Match kube.*
        region region-code
        log_group_name fluent-bit-cloudwatch
        log_stream_prefix from-fluent-bit-
        auto_create_group true
```

Los registros se encuentran en CloudWatch, en la misma región de AWS que el clúster. El nombre del grupo de registros es ` my-cluster-fluent-bit-logs` y el nombre del flujo de registros de Fluent Bit es `fluent-bit-podname-pod-namespace `.

**nota**  
Los registros de proceso se envían solo cuando el proceso de Fluent Bit se inicia de forma correcta. Si se produce un error al iniciar Fluent Bit, se pierden los registros del proceso. Solo puede enviar los registros del proceso a CloudWatch.
Para depurar los registros del proceso de envío en la cuenta, puede aplicar el `ConfigMap` anterior a fin de obtener los registros del proceso. El hecho de que Fluent Bit no se inicie suele deberse a que Fluent Bit no analiza ni acepta el `ConfigMap` durante el inicio.

### Detención del envío de registros de procesos de Fluent Bit
<a name="stop-fluent-bit-process-logs"></a>

El envío de registros de procesos de Fluent Bit a CloudWatch requiere costos adicionales de ingesta y almacenamiento de registros. Para excluir los registros de procesos de una configuración de `ConfigMap` existente, siga estos pasos.

1. Busque el grupo de registro de CloudWatch creado automáticamente para los registros de procesos de Fluent Bit del clúster de Amazon EKS después de habilitar el registro de Fargate. Sigue el formato ` my-cluster-fluent-bit-logs`.

1. Elimine los flujos de registro de CloudWatch existentes creados para los registros de procesos de cada pod en el grupo de registros de CloudWatch.

1. Edite el `ConfigMap` y configure `flb_log_cw: "false"`.

1. Reinicie todos los pods existentes en el clúster.

## Probar la aplicación
<a name="fargate-logging-test-application"></a>

1. Implemente un pod de ejemplo.

   1. Guarde el siguiente contenido en un archivo llamado `sample-app.yaml` en el equipo.

      ```
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: sample-app
        namespace: same-namespace-as-your-fargate-profile
      spec:
        replicas: 3
        selector:
          matchLabels:
            app: nginx
        template:
          metadata:
            labels:
              app: nginx
          spec:
            containers:
              - name: nginx
                image: nginx:latest
                ports:
                  - name: http
                    containerPort: 80
      ```

   1. Aplique el manifiesto al clúster.

      ```
      kubectl apply -f sample-app.yaml
      ```

1. Visualización de los registros NGINX con los destinos que configuró en el `ConfigMap`.

## Consideraciones sobre el tamaño
<a name="fargate-logging-size-considerations"></a>

Le sugerimos que planee utilizar hasta 50 MB de memoria para el enrutador de registros. Si anticipa que su aplicación generará registros con un rendimiento muy alto, entonces debe planificar utilizar hasta 100 MB.

## Solución de problemas
<a name="fargate-logging-troubleshooting"></a>

Para confirmar si la característica de registro está habilitada o desactivada por algún motivo, como un `ConfigMap` que no es válido y desea saber por qué no es válido, verifique los eventos de pods con `kubectl describe pod pod-name `. La salida puede incluir eventos del pod que aclaran si el registro está habilitado o no, como la siguiente salida de ejemplo.

```
[...]
Annotations:          CapacityProvisioned: 0.25vCPU 0.5GB
                      Logging: LoggingDisabled: LOGGING_CONFIGMAP_NOT_FOUND
[...]
Events:
  Type     Reason           Age        From                                                           Message
  ----     ------           ----       ----                                                           -------
  Warning  LoggingDisabled  <unknown>  fargate-scheduler                                              Disabled logging because aws-logging configmap was not found. configmap "aws-logging" not found
```

Los eventos de pod son efímeros con un periodo de tiempo en función de la configuración. También puede ver las anotaciones de un pod con `kubectl describe pod pod-name `. En la anotación del pod, hay información sobre si la característica de registro está habilitada o desactivada y el motivo.

# Elección de un tipo de instancia de nodo de Amazon EC2 óptimo
<a name="choosing-instance-type"></a>

Amazon EC2 proporciona una amplia selección de tipos de instancias para nodos de trabajo. Cada tipo de instancia ofrece diferentes capacidades de computación, memoria y almacenamiento. Cada instancia se agrupa también en una familia de instancias en función de dichas características. Para obtener una lista, consulte [Tipos de instancias disponibles](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#AvailableInstanceTypes) en la *Guía del usuario de Amazon EC2*. Amazon EKS publica diferentes variaciones de las AMI de Amazon EC2 para habilitar el soporte. Para asegurarse de que el tipo de instancia que seleccione es compatible con Amazon EKS, tenga en cuenta los siguientes criterios.
+ En la actualidad, las AMI de Amazon EKS no admiten la familia `mac`.
+ Las AMI de Arm y las no aceleradas de Amazon EKS no admiten las familias `g3`, `g4`, `inf` y `p`.
+ Las AMI aceleradas de Amazon EKS no admiten las familias `a`, `c`, `hpc`, `m` y `t`.
+ Para las instancias basadas en ARM, Amazon Linux 2023 (AL2023) solo admite tipos de instancias que utilizan procesadores Graviton2 o posteriores. AL2023 no admite las instancias `A1`.

Al elegir entre los tipos de instancias admitidos por Amazon EKS, tenga en cuenta las siguientes capacidades de cada tipo.

 **Número de instancias de un grupo de nodos**   
En general, que haya menos instancias y que sean más grandes es mejor, especialmente si tiene muchos DaemonSets. Cada instancia requiere llamadas a la API para el servidor de API, por lo que cuantas más instancias tenga, más carga tendrá el servidor de API.

 **Sistema operativo**   
Revise los tipos de instancias admitidos para [Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html), [Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html) y [Bottlerocket](https://aws.amazon.com/bottlerocket/faqs/). Antes de crear instancias de Windows, consulte [Deploy Windows nodes on EKS clusters](windows-support.md).

 **Arquitectura de hardware**   
¿Necesita x86 o Arm? Antes de implementar instancias de Arm, consulte [Amazon EKS optimized Arm Amazon Linux AMIs](eks-optimized-ami.md#arm-ami). ¿Necesita instancias integradas en Nitro System ([Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances) o [Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html#ec2-nitro-instances)) o que tengan capacidades [aceleradas](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/accelerated-computing-instances.html)? Si necesita capacidades aceleradas, solo puede utilizar Linux con Amazon EKS.

 **Número máximo de pods**   
Dado que a cada pod se le asigna su propia dirección IP, la cantidad de direcciones IP admitidas por un tipo de instancia es un factor que se considera a la hora de determinar el número de pods que se pueden ejecutar en la instancia. Para determinar manualmente cuántos pods admite un tipo de instancia, consulte .  
 Los tipos de instancia [AWS Nitro System](https://aws.amazon.com/ec2/nitro/) admiten opcionalmente más direcciones IP que los tipos de instancias que no son Nitro System. Sin embargo, no todas las direcciones IP asignadas a una instancia están disponibles para los pods. Para asignar un número significativamente mayor de direcciones IP a sus instancias, debe tener la versión `1.9.0` o posterior del complemento Amazon VPC CNI instalada en el clúster y configurada de forma adecuada. 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). Para asignar el mayor número de direcciones IP a sus instancias, debe tener la versión `1.10.1` o posterior del complemento Amazon VPC CNI instalada en su clúster, e implementar este con la familia `IPv6`.

 **Familia de IP**   
Puede usar cualquier tipo de instancia compatible cuando utilice la familia `IPv4` para un clúster, que permite que su clúster asigne direcciones `IPv4` privadas a sus pods y servicios. Pero si desea usar la familia `IPv6` para su clúster, entonces debe usar tipos de instancias [AWS Nitro System](https://aws.amazon.com/ec2/nitro/) o tipos de ejemplares bare metal. Solo se admite `IPv4` en las instancias de Windows. Su clúster debe ejecutar la versión `1.10.1` o posterior del complemento Amazon VPC CNI. Para obtener más información acerca del uso de `IPv6`, consulte [Información sobre la asignación de direcciones IPv6 a clústeres, pods y servicios](cni-ipv6.md).

 **Versión del complemento CNI de Amazon VPC que ejecuta**   
La versión más reciente del [complemento CNI de Amazon VPC para Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) es compatible con [estos tipos de instancias](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go). Es posible que tenga que actualizar la versión del complemento CNI de Amazon VPC para aprovechar los últimos tipos de instancia admitidos. Para obtener más información, consulte [Asignación de direcciones IP a pods con CNI de Amazon VPC](managing-vpc-cni.md). La última versión admite las características más recientes para el uso con Amazon EKS. Las versiones anteriores no admiten todas las características. Puede ver las características compatibles con las distintas versiones en [Changelog](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/CHANGELOG.md) en GitHub.

 ** AWS Región de en la que va a crear los nodos**   
No todos los tipos de instancias están disponibles en todas las regiones de AWS.

 **Si utiliza grupos de seguridad para pods**   
Si utiliza grupos de seguridad para pods, solo se admiten tipos de instancia específicos. Para obtener más información, consulte [Asignación de los grupos de seguridad a pods individuales](security-groups-for-pods.md).

## Cómo se determina maxPods
<a name="max-pods-precedence"></a>

El valor `maxPods` final aplicado a un nodo depende de varios componentes que interactúan en un orden específico de precedencia. Comprender este orden ayuda a evitar comportamientos inesperados al personalizar `maxPods`.

 **Orden de precedencia (de mayor a menor):** 

1.  **Aplicación obligatoria de grupos de nodos administrados**: cuando utiliza un grupo de nodos administrado sin una [AMI personalizada](launch-templates.md#launch-template-custom-ami), Amazon EKS aplica un límite a `maxPods` en los datos de usuario del nodo. Para instancias con menos de 30 vCPU, el límite es `110`. Para instancias con más de 30 vCPU, el límite es `250`. Este valor tiene precedencia sobre cualquier otra configuración de `maxPods`, incluida `maxPodsExpression`.

1.  **Configuración de `maxPods` en kubelet**: si establece `maxPods` directamente en la configuración de kubelet (por ejemplo, mediante una plantilla de lanzamiento con una AMI personalizada), este valor tiene precedencia sobre `maxPodsExpression`.

1.  **nodeadm `maxPodsExpression`**: si utiliza [https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/examples/#defining-a-max-pods-expression](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/examples/#defining-a-max-pods-expression) en la `NodeConfig`, nodeadm evalúa la expresión para calcular `maxPods`. Esto solo es efectivo cuando el valor no ha sido establecido previamente por un origen de mayor precedencia.

1.  **Cálculo predeterminado basado en ENI**: si no se establece ningún otro valor, la AMI calcula `maxPods` en función del número de interfaces de red elásticas (ENI) y direcciones IP admitidas por el tipo de instancia. Esto es equivalente a la fórmula `(number of ENIs × (IPs per ENI − 1)) + 2`. El `+ 2` tiene en cuenta que la CNI y `kube-proxy` de Amazon VPC se ejecutan en cada nodo y no consumen una dirección IP de pod.

**importante**  
Si utiliza un grupo de nodos administrado y establece `maxPodsExpression` en la `NodeConfig`, la aplicación del grupo de nodos administrado tiene precedencia sobre la expresión. Para utilizar un valor personalizado de `maxPods` con grupos de nodos administrados, debe especificar una AMI personalizada en la plantilla de lanzamiento y establecer `maxPods` directamente. Para obtener más información, consulte [Personalización de nodos administrados con plantillas de lanzamiento](launch-templates.md).

 **Grupos de nodos administrados frente a nodos autoadministrados** 

Con grupos de nodos administrados (sin una AMI personalizada), Amazon EKS inyecta el valor de `maxPods` en los datos de usuario de arranque del nodo. Esto significa:
+ El valor de `maxPods` siempre se limita a `110` o `250`, según el tamaño de la instancia.
+ Cualquier valor de `maxPodsExpression` que configure se reemplaza por este valor inyectado.
+ Para utilizar un valor diferente de `maxPods`, especifique una AMI personalizada en la plantilla de lanzamiento y pase `--use-max-pods false` junto con `--kubelet-extra-args '--max-pods=my-value'` al script `bootstrap.sh`. Para ver ejemplos, consulte [Personalización de nodos administrados con plantillas de lanzamiento](launch-templates.md).

Con nodos autoadministrados, tiene control total sobre el proceso de arranque. Puede utilizar `maxPodsExpression` en la `NodeConfig` o pasar `--max-pods` directamente a `bootstrap.sh`.

## Consideraciones para el modo automático de EKS
<a name="_considerations_for_eks_auto_mode"></a>

El modo automático de EKS limita la cantidad de pods en los nodos al menor de los siguientes valores:
+ Límite fijo de 110 pods
+ El resultado del cálculo de pods máximos descrito anteriormente.

# Creación de nodos con imágenes optimizadas precompiladas
<a name="eks-optimized-amis"></a>

Puede implementar nodos con [imágenes de máquina de Amazon (AMI)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) optimizadas para Amazon EKS prediseñadas o con AMI personalizadas propias al utilizar grupos de nodos administrados o nodos autoadministrados. Si ejecuta nodos híbridos, consulte [Cómo preparar el sistema operativo para los nodos híbridos](hybrid-nodes-os.md). A fin de obtener información acerca de cada tipo de AMI optimizada para Amazon EKS, consulte uno de los siguientes temas. Para obtener instrucciones sobre cómo crear su propia AMI personalizada, consulte [Creación de una AMI de Amazon Linux optimizada para EKS personalizada](eks-ami-build-scripts.md).

Con el modo automático de Amazon EKS, EKS administra la instancia de EC2, incluida la selección y actualización de la AMI.

**Topics**
+ [Guía sobre las características de transición de las AMI EKS AL2 y AL2-Accelerated](eks-ami-deprecation-faqs.md)
+ [Creación de nodos con AMI de Amazon Linux optimizadas](eks-optimized-ami.md)
+ [Creación de nodos con AMI de Bottlerocket optimizadas](eks-optimized-ami-bottlerocket.md)
+ [Creación de nodos con AMI de Ubuntu Linux optimizadas](eks-partner-amis.md)
+ [Creación de nodos con AMI de Windows optimizadas](eks-optimized-windows-ami.md)

# Guía sobre las características de transición de las AMI EKS AL2 y AL2-Accelerated
<a name="eks-ami-deprecation-faqs"></a>

**aviso**  
Amazon EKS dejó de publicar las AMI optimizadas para EKS de Amazon Linux 2 (AL2) el 26 de noviembre de 2025. Las AMI basadas en AL2023 y Bottlerocket para Amazon EKS están disponibles para todas las versiones de Kubernetes compatibles, lo que incluye la versión 1.33 y posteriores.

 AWS finalizará el soporte para las AMI EKS AL2 y AL2-Accelerated a partir del 26 de noviembre de 2025. Aunque aún podrá utilizar las AMI EKS AL2 después de la fecha de fin de soporte (EOS) (26 de noviembre de 2025), EKS dejará de publicar nuevas versiones de Kubernetes o actualizaciones de las AMI AL2, incluso versiones secundarias, revisiones y correcciones de errores después de esta fecha. Recomendamos actualizar a las AMI de Amazon Linux 2023 (AL2023) o Bottlerocket:
+ AL2023 ofrece un enfoque de seguridad desde el diseño con políticas de seguridad previamente configuradas, SELinux en modo permisivo, modo exclusivo IMDSv2 habilitado de forma predeterminada, tiempos de arranque optimizados y administración de paquetes mejorada para aumentar la seguridad y el rendimiento, lo que resulta idóneo para infraestructuras que exigen personalizaciones significativas, como acceso directo a nivel de sistema operativo o cambios amplios en los nodos. Para obtener más información, consulte las [Preguntas frecuentes sobre AL2023](https://aws.amazon.com/linux/amazon-linux-2023/faqs/) o nuestra guía de migración detallada en [Actualización de Amazon Linux 2 a Amazon Linux 2023](al2023.md).
+ Bottlerocket aumenta la seguridad, acelera los tiempos de arranque y reduce la superficie de ataque a fin de mejorar la eficacia gracias a su diseño específico y optimizado para contenedores, que resulta idóneo para enfoques de uso nativo de contenedores con muy pocas personalizaciones de nodos. Para obtener más información, consulte las [Preguntas frecuentes sobre Bottlerocket](https://aws.amazon.com/bottlerocket/faqs/) o nuestra guía de migración detallada en [Creación de nodos con AMI de Bottlerocket optimizadas](eks-optimized-ami-bottlerocket.md).

Como alternativa, puede utilizar [Creación de una AMI de Amazon Linux optimizada para EKS personalizada](eks-ami-build-scripts.md) hasta la fecha de finalización del soporte (26 de noviembre de 2025). Además, puede crear una AMI personalizada con una instancia base de Amazon Linux 2 hasta la fecha de finalización del soporte de Amazon Linux 2 (30 de junio de 2026).

## Preguntas frecuentes sobre migración y soporte
<a name="_migration_and_support_faqs"></a>

### ¿Cómo se realiza la migración de AL2 a una AMI de AL2023?
<a name="_how_do_i_migrate_from_my_al2_to_an_al2023_ami"></a>

Recomendamos crear e implementar un plan de migración que incluya pruebas exhaustivas de las cargas de trabajo de las aplicaciones y procedimientos de reversión documentados, y posteriormente seguir las instrucciones paso a paso que se indican en [Actualización de Amazon Linux 2 a Amazon Linux 2023](https://docs.aws.amazon.com/eks/latest/userguide/al2023.html) en la documentación oficial de EKS.

### ¿Podré crear una AMI de AL2 personalizada pasada la fecha de fin de soporte (EOS) de EKS para las AMI de AL2 optimizadas para EKS?
<a name="_can_i_build_a_custom_al2_ami_past_the_eks_end_of_support_eos_date_for_eks_optimized_al2_amis"></a>

Aunque recomendamos adoptar las AMI optimizadas para EKS, oficialmente admitidas y publicadas para AL2023 o Bottlerocket, puede crear AMI personalizadas optimizadas y aceleradas para EKS AL2 hasta la fecha de finalización del soporte de las AMI de AL2 (26 de noviembre de 2025). Como alternativa, puede crear una AMI personalizada con una instancia base de Amazon Linux 2 hasta la fecha de finalización del soporte de Amazon Linux 2 (30 de junio de 2026). Para obtener instrucciones paso a paso sobre cómo crear una AMI personalizada optimizada y acelerada para EKS AL2, consulte la sección [Creación de una AMI personalizada de Amazon Linux](https://docs.aws.amazon.com/eks/latest/userguide/eks-ami-build-scripts.html) en la documentación oficial de EKS.

### ¿La política de soporte de versiones de Kubernetes en EKS aplica a las distribuciones de Amazon Linux?
<a name="_does_the_eks_kubernetes_version_support_policy_apply_to_amazon_linux_distributions"></a>

No. La fecha de finalización del soporte para las AMI optimizadas y aceleradas para EKS AL2 es independiente de los periodos de soporte estándar y extendido de las versiones de Kubernetes por parte de EKS. Debe migrar a AL2023 o Bottlerocket incluso si utiliza el soporte extendido de EKS.

### ¿Cómo afecta a la migración el cambio de cgroupv1 a cgroupv2?
<a name="_how_does_the_shift_from_cgroupv1_to_cgroupv2_affect_my_migration"></a>

La [comunidad de Kubernetes](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/4569-cgroup-v1-maintenance-mode/README.md) trasladó el soporte para `cgroupv1` (utilizado por AL2) a modo de mantenimiento, lo que significa que no se agregarán nuevas características y solo se proporcionarán correcciones críticas de seguridad y errores importantes. Para adoptar `cgroupv2` en Kubernetes, debe garantizar la compatibilidad entre el sistema operativo, el kernel, el tiempo de ejecución de contenedores y los componentes de Kubernetes. Esto requiere una distribución de Linux que habilite `cgroupv2` de forma predeterminada, como AL2023, Bottlerocket, Red Hat Enterprise Linux (RHEL) 9 o superior, Ubuntu 22.04 o superior, o Debian 11 o superior. Estas distribuciones se entregan con versiones del kernel iguales o superiores a la 5.8, que es el requisito mínimo para el soporte de `cgroupv2` en Kubernetes. Para obtener más información, consulte [Acerca de cgroup v2](https://kubernetes.io/docs/concepts/architecture/cgroups/).

### ¿Qué se debe hacer si se necesita Neuron en la AMI personalizada de AL2?
<a name="_what_do_i_do_if_i_need_neuron_in_my_custom_al2_ami"></a>

No puede ejecutar de forma nativa las aplicaciones completas basadas en Neuron en AMI basadas en AL2. Para aprovechar AWS Neuron en una AMI basada en AL2, debe contenerizar las aplicaciones con un contenedor compatible con Neuron que utilice una distribución de Linux distinta a AL2 (por ejemplo, Ubuntu 22.04, Amazon Linux 2023, etc.) y luego implementar esos contenedores en una AMI basada en AL2 que tenga instalado el controlador de Neuron (`aws-neuronx-dkms`).

### ¿Debo cambiarme a una instancia básica de Amazon Linux 2 después de la fecha de finalización del soporte de la AMI de AL2 de EKS (26 de noviembre de 2025)?
<a name="_should_i_switch_to_a_bare_amazon_linux_2_base_instance_after_the_eks_al2_ami_eos_date_november_26_2025"></a>

El cambio a una instancia básica de Amazon Linux 2 carece de las optimizaciones, configuraciones de tiempo de ejecución de contenedores y personalizaciones específicas que proporcionan las AMI optimizadas y aceleradas para AL2 de EKS. Como alternativa, si debe continuar utilizando una solución basada en AL2, le recomendamos que cree una AMI personalizada con las recetas de AMI de EKS que aparecen en [Creación de una AMI de Amazon Linux optimizada para EKS personalizada](eks-ami-build-scripts.md) o la [especificación de creación de AMI de Amazon EKS](https://github.com/awslabs/amazon-eks-ami). De este modo, se garantiza la compatibilidad con sus cargas de trabajo existentes y se incluyen las actualizaciones del kernel de AL2 hasta la fecha de finalización del soporte de Amazon Linux 2 (30 de junio de 2026).

### Al crear una AMI de AL2 personalizada con el repositorio de GitHub de la AMI de EKS después de la fecha de finalización del soporte de la AMI de AL2 de EKS (26 de noviembre de 2025), ¿qué soporte está disponible para los paquetes de repositorios como amzn2-core y amzn2extra-docker?
<a name="_when_building_a_custom_al2_ami_using_the_eks_ami_github_repository_after_the_eks_al2_ami_eos_date_november_26_2025_what_support_is_available_for_packages_from_repositories_like_amzn2_core_and_amzn2extra_docker"></a>

La receta de la AMI de EKS que se encuentra en la [especificación de creación de AMI de Amazon EKS](https://github.com/awslabs/amazon-eks-ami) extrae paquetes mediante YUM del software estándar de Amazon Linux 2, como [amzn2-core](https://docs.aws.amazon.com/linux/al2/ug/managing-software.html) y [amzn2extra-docker](https://docs.aws.amazon.com/linux/al2/ug/managing-software.html). Después de la fecha de finalización del soporte de la AMI de AL2 de EKS (26 de noviembre de 2025), este software continuará siendo compatible hasta la fecha de finalización del soporte de Amazon Linux 2 (30 de junio de 2026). Tenga en cuenta que el soporte se limita a las actualizaciones del kernel durante este periodo, lo que significa que tendrá que administrar y aplicar manualmente otras actualizaciones de paquetes, parches de seguridad y cualquier dependencia ajena al kernel para mantener la seguridad y la compatibilidad.

### ¿Por qué es posible que las aplicaciones Java que utilizan versiones anteriores de JDK8 en Amazon EKS con AL2023 experimenten excepciones por falta de memoria (OOM) y se reinicien los pods? ¿Cómo se puede resolver esto?
<a name="_why_might_java_applications_using_older_versions_of_jdk8_on_amazon_eks_with_al2023_experience_out_of_memory_oom_exceptions_and_pod_restarts_and_how_can_this_be_resolved"></a>

Cuando se ejecutan en nodos de Amazon EKS con AL2023, las aplicaciones Java que dependen de versiones de JDK 8 anteriores a `jdk8u372` pueden provocar excepciones de OOM y reinicios de pods porque JVM no es compatible con `cgroupv2`. Este problema surge específicamente de la incapacidad de JVM de detectar los límites de memoria del contenedor mediante `cgroupv2`, la opción predeterminada en Amazon Linux 2023. Como resultado, basa la asignación de pilas en la memoria total del nodo en lugar del límite definido por el pod. Esto se debe a que `cgroupv2` cambia la ubicación de almacenamiento de los datos con límite de memoria, lo que provoca que las versiones anteriores de Java malinterpreten la memoria disponible y utilicen recursos del nodo. Algunas opciones posibles son las siguientes:
+  **Actualización de la versión de JDK**: la actualización a `jdk8u372` o una versión posterior, o a una versión más reciente de JDK con soporte para `cgroupv2` completo, puede resolver este problema. Para obtener una lista de las versiones de Java completamente compatibles con `cgroupv2`, consulte [About cgroup v2](https://kubernetes.io/docs/concepts/architecture/cgroups/).
+  **Creación de una AMI personalizada**: si debe continuar utilizando una solución basada en AL2, puede crear una AMI personalizada basada en AL2 (hasta el 26 de noviembre de 2025) con [Creación de una AMI de Amazon Linux optimizada para EKS personalizada](eks-ami-build-scripts.md) o la [especificación de creación de AMI de Amazon EKS](https://github.com/awslabs/amazon-eks-ami). Por ejemplo, puede crear una AMI v1.33 basada en AL2 (hasta el 26 de noviembre de 2025). Amazon EKS proporcionará AMI basadas en AL2 hasta la fecha de finalización del soporte de AL2 de EKS (26 de noviembre de 2025). Después de la fecha de finalización del soporte (26 de noviembre de 2025), tendrá que crear su propia AMI.
+  **Activación de cgroupv1**: si debe continuar utilizando `cgroupv1`, puede activar `cgroupv1` en una AMI de AL2023 de EKS. Para activarlo, ejecute `sudo grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0"` y reinicie el sistema (por ejemplo, un nodo o una instancia de EC2 que ejecute Amazon Linux 2023). De este modo, se modificarán los parámetros de arranque del sistema (por ejemplo, al agregar el parámetro del kernel “systemd.unified\$1cgroup\$1hierarchy=0” a la configuración de GRUB, que indica a systemd que debe utilizar la jerarquía de `cgroupv1` heredad) y activará `cgroupv1`. Tenga en cuenta que, cuando ejecuta este comando grubby, está reconfigurando el kernel para que se lance con `cgroupv1` activado y `cgroupv2` desactivado. Solo una de estas versiones de cgroup se utiliza para la administración activa de los recursos en un nodo. No es lo mismo que ejecutar `cgroupv2` con compatibilidad con versiones anteriores para la API de `cgroupv1`.

**aviso**  
No recomendamos el uso continuo de `cgroupv1`. En su lugar, recomendamos migrar a `cgroupv2`. La comunidad de Kubernetes trasladó el soporte para `cgroupv1` (utilizado por AL2) a modo de mantenimiento, lo que significa que no se agregarán nuevas características ni actualizaciones y solo se proporcionarán correcciones críticas de seguridad y errores importantes. Se espera la eliminación total del soporte para `cgroupv1` en una versión futura, aunque aún no se ha anunciado ninguna fecha específica para esta eliminación total. Si tiene problemas con `cgroupv1`, AWS no podrá proporcionarle soporte y le recomendará que actualice a `cgroupv2`.

## Compatibilidad y versiones
<a name="_compatibility_and_versions"></a>

### Versiones de Kubernetes compatibles con las AMI de AL2
<a name="_supported_kubernetes_versions_for_al2_amis"></a>

La versión 1.32 de Kubernetes será la última para la cual Amazon EKS publicará AMI basadas en AL2 (Amazon Linux 2). Para las versiones de Kubernetes [compatibles](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) hasta la 1.32, EKS continuará publicando AMI de AL2 (AL2\$1ARM\$164, AL2\$1x86\$164) y AMI aceleradas de AL2 (AL2\$1x86\$164\$1GPU) hasta el 26 de noviembre de 2025. Después de esta fecha, EKS dejará de publicar AMI optimizadas y aceleradas de AL2 para todas las versiones de Kubernetes. Tenga en cuenta que la fecha de finalización del soporte para las AMI optimizadas y aceleradas de AL2 en EKS es independiente de los periodos de soporte estándar y extendido de las versiones de Kubernetes por parte de EKS.

### Comparación de controladores compatibles y versiones del kernel de Linux para las AMI de AL2, AL2023 y Bottlerocket
<a name="_supported_drivers_and_linux_kernel_versions_comparison_for_al2_al2023_and_bottlerocket_amis"></a>


| Componente | AMI de AL2 de EKS | AMI de AL2023 de EKS | AMI de Bottlerocket de EKS | 
| --- | --- | --- | --- | 
|  Compatibilidad con el sistema operativo base  |  RHEL7/CentOS 7  |  Fedora/CentOS 9  |  N/A  | 
|   [Controlador de modo de usuario CUDA](https://docs.nvidia.com/deploy/cuda-compatibility/why-cuda-compatibility.html#why-cuda-compatibility)   |  12.x  |  12.x,13.x  |  12.x,13.x  | 
|  Controlador de GPU NVIDIA  |  R570  |  R580  |  R570, R580  | 
|   Controlador de AWS Neuron  |  2.20\$1  |  2.20\$1  |  2.20\$1  | 
|  Kernel de Linux   |  5.10  |  6.1, 6.12  |  6.1, 6.12  | 

Para obtener más información sobre la compatibilidad de CUDA y los controladores de NVIDIA, consulte la [documentación de NVIDIA](https://docs.nvidia.com/datacenter/tesla/drivers/index.html#supported-drivers-and-cuda-toolkit-versions).

### Compatibilidad de AWS Neuron con las AMI de AL2
<a name="shared_aws_neuron_compatibility_with_al2_amis"></a>

A partir de la [versión 2.20 de AWS Neuron](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/release-notes/prev/rn.html#neuron-2-20-0-whatsnew), el entorno de ejecución de Neuron (`aws-neuronx-runtime-lib`) utilizado por las AMI basadas en AL para EKS ya no es compatible con Amazon Linux 2 (AL2). El controlador de Neuron (`aws-neuronx-dkms`) es ahora el único paquete de AWS Neuron que admite Amazon Linux 2. Esto significa que no puede ejecutar las aplicaciones con tecnología de Neuron de forma nativa en una AMI basada en AL2. Para configurar Neuron en AMI de AL2023, consulte la guía de [configuración de AWS Neuron](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/general/setup/index.html#setup-guide-index).

### Compatibilidad de Kubernetes con las AMI de AL2
<a name="_kubernetes_compatibility_with_al2_amis"></a>

La comunidad de Kubernetes ha puesto el soporte para `cgroupv1` (utilizado por AL2) en modo de mantenimiento. Esto significa que no se agregarán nuevas características y solo se proporcionarán correcciones críticas de seguridad y de errores importantes. Cualquier característica de Kubernetes que dependa de cgroupv2, como MemoryQoS y el aislamiento mejorado de recursos, no está disponible en AL2. Además, la versión 1.32 de Kubernetes en Amazon EKS fue la última en admitir AMI basadas en AL2. Para mantener la compatibilidad con las versiones más recientes de Kubernetes, recomendamos migrar a AL2023 o Bottlerocket, que habilitan `cgroupv2` de forma predeterminada.

### Compatibilidad de versiones de Linux con las AMI de AL2
<a name="_linux_version_compatibility_with_al2_amis"></a>

Amazon Linux 2 (AL2) cuenta con soporte de AWS hasta su fecha de finalización del soporte (EOS), el 30 de junio de 2026. Sin embargo, con el paso del tiempo, el respaldo de la comunidad de Linux para nuevas aplicaciones y funcionalidades en AL2 se ha reducido. Las AMI de AL2 se basan en el [kernel de Linux 5.10](https://docs.aws.amazon.com/linux/al2/ug/kernel.html), mientras que AL2023 utiliza el [kernel de Linux 6.1](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2-kernel.html). A diferencia de AL2023, AL2 cuenta con un soporte limitado por parte de la comunidad de Linux en general. Esto significa que muchos paquetes y herramientas de Linux de origen deben adaptarse para funcionar con la versión antigua del kernel de AL2; además, algunas características modernas de Linux y mejoras de seguridad no están disponibles debido a ese kernel, y muchos proyectos de código abierto han quedado obsoletos o han limitado el soporte para versiones antiguas como la 5.10.

### Paquetes obsoletos no incluidos en AL2023
<a name="_deprecated_packages_not_included_in_al2023"></a>

Algunos de los paquetes más comunes que no están incluidos o que han cambiado en AL2023 incluyen:
+ Algunos [paquetes binarios de origen disponibles en Amazon Linux 2](https://docs.aws.amazon.com/linux/al2023/release-notes/removed-AL2023.6-AL2.html) ya no lo están en Amazon Linux 2023.
+ Cambios en cómo Amazon Linux admite diferentes versiones de paquetes (por ejemplo, el sistema [amazon-linux-extras](https://repost.aws/questions/QUWGU3VFJMRSGf6MDPWn4tLg/how-to-resolve-amazon-linux-extras-in-al2023)) en AL2023
+  Los [paquetes adicionales para Enterprise Linux (EPEL)](https://docs.aws.amazon.com/linux/al2023/ug/epel.html) no son compatibles con AL2023
+  [Las aplicaciones de 32 bits](https://docs.aws.amazon.com/linux/al2023/ug/deprecated-al2.html#deprecated-32bit-rpms) no son compatibles con AL2023

Para obtener más información, consulte la [Comparación entre AL2 y AL2023](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html).

### Comparación de la validación FIPS entre AL2, AL2023 y Bottlerocket
<a name="_fips_validation_comparison_across_al2_al2023_and_bottlerocket"></a>

Amazon Linux 2 (AL2), Amazon Linux 2023 (AL2023) y Bottlerocket ofrecen compatibilidad con el cumplimiento de los Estándares Federales de Procesamiento de Información (FIPS).
+ AL2 cuenta con certificación FIPS 140-2 y AL2023 con certificación FIPS 140-3. Para habilitar el modo FIPS en AL2023, instale los paquetes necesarios en la instancia de Amazon EC2 y siga las instrucciones de configuración que se indican en [Habilitación del modo FIPS en AL2023](https://docs.aws.amazon.com/linux/al2023/ug/fips-mode.html). Para obtener más información, consulte las [Preguntas frecuentes de AL2023](https://aws.amazon.com/linux/amazon-linux-2023/faqs).
+ Bottlerocket ofrece variantes diseñadas específicamente para FIPS, que restringen el kernel y los componentes del espacio de usuario al uso de módulos criptográficos que han sido enviados al Programa de validación de módulos criptográficos FIPS 140-3.

### Registro de cambios de controladores y versiones de las AMI de EKS
<a name="_eks_ami_driver_and_versions_changelog"></a>

Para ver la lista completa de todos los componentes de las AMI de EKS y sus versiones, consulte las [Notas de la versión de las AMI de Amazon EKS](https://github.com/awslabs/amazon-eks-ami/releases) en GitHub.

# Creación de nodos con AMI de Amazon Linux optimizadas
<a name="eks-optimized-ami"></a>

Amazon Elastic Kubernetes Service (Amazon EKS) proporciona imágenes de máquina de Amazon (AMI) especializadas optimizadas para ejecutar nodos de trabajo de Kubernetes. Estas AMI de Amazon Linux (AL) optimizadas para EKS vienen preconfiguradas con componentes esenciales, como `kubelet`, Autenticador de AWS IAM y `containerd` para garantizar la seguridad y una integración sin problemas en sus clústeres. En esta guía, se detallan las versiones de AMI disponibles y describe las opciones especializadas para la computación acelerada y las arquitecturas basadas en Arm.

## Consideraciones
<a name="ami-considerations"></a>
+ Puede realizar un seguimiento de los eventos de seguridad o privacidad de Amazon Linux en el [Centro de seguridad de Amazon Linux](https://alas.aws.amazon.com/) seleccionando la pestaña de la versión que desee. También puede suscribirse a la fuente RSS correspondiente. Los eventos de seguridad y privacidad incluyen información general del problema, qué paquetes están afectados y cómo actualizar las instancias para corregir el problema.
+ Antes de implementar una AMI de Arm o acelerada, revise la información de [AMI de Amazon Linux aceleradas optimizadas para Amazon EKS](#gpu-ami) y [AMI de Amazon Linux de Arm optimizadas para Amazon EKS](#arm-ami).
+ Las instancias `P2` de Amazon EC2 no son compatibles con Amazon EKS ya que requieren la versión 470 del controlador `NVIDIA` o anterior.
+ A partir de la versión `1.30` o posterior, todos los grupos de nodos administrados recién creados utilizarán automáticamente AL2023 como sistema operativo de nodos de forma predeterminada.

## AMI de Amazon Linux aceleradas optimizadas para Amazon EKS
<a name="gpu-ami"></a>

Las AMI de Amazon Linux (AL) aceleradas optimizadas para Amazon EKS se crean sobre las AMI de Amazon Linux optimizadas para EKS estándar. Están configuradas para actuar como imágenes opcionales para que los nodos de Amazon EKS admitan cargas de trabajo basadas en GPU, [Inferentia](https://aws.amazon.com/machine-learning/inferentia/) y [Trainium](https://aws.amazon.com/machine-learning/trainium/).

Para obtener más información, consulte [Uso de AMI aceleradas optimizadas para EKS para instancias de GPU](ml-eks-optimized-ami.md).

## AMI de Amazon Linux de Arm optimizadas para Amazon EKS
<a name="arm-ami"></a>

Las instancias Arm ofrecen un importante ahorro de costos para aplicaciones de escalado horizontal y aplicaciones basadas en Arm, como servidores web, microservicios en contenedores, flotas de almacenamiento en caché y almacenes de datos distribuidos. Al agregar nodos de Arm al clúster, tenga en cuenta las siguientes consideraciones.
+ Si el clúster se implementó antes del 17 de agosto de 2020, debe realizar una actualización única de los manifiestos complementarios de clúster críticos. Esto es para que Kubernetes pueda extraer la imagen correcta para cada arquitectura de hardware que se utilice en el clúster. Para obtener más información acerca de la actualización de complementos de clúster, consulte [Paso 1: preparación para la actualización](update-cluster.md#update-existing-cluster). Si implementó el clúster a partir del 17 de agosto de 2020, significa que su CoreDNS, `kube-proxy` y los complementos CNI de Amazon VPC para los complementos de Kubernetes ya son aptos en múltiples arquitecturas.
+ Las aplicaciones implementadas en los nodos de Arm deben compilarse para Arm.
+ Si tiene algún DaemonSet que está implementado en un clúster existente o desea implementarlos en un clúster nuevo en el que también quiera implementar nodos de Arm, compruebe que el DaemonSet se pueda ejecutar en todas las arquitecturas de hardware del clúster.
+ Puede ejecutar grupos de nodos de Arm y grupos de nodos x86 en el mismo clúster. Si lo hace, considere la posibilidad de implementar imágenes de contenedor de varias arquitecturas en un repositorio de contenedores como Amazon Elastic Container Registry y, a continuación, agregar selectores de nodo a los manifiestos para que Kubernetes sepa en qué arquitectura de hardware se puede implementar un pod. Para obtener más información, consulte [Introducir una imagen de varias arquitecturas](https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-multi-architecture-image.html) en la *Guía del usuario de Amazon ECR* y en la publicación del blog [Introducing multi-architecture container images for Amazon ECR](https://aws.amazon.com/blogs/containers/introducing-multi-architecture-container-images-for-amazon-ecr).

## Más información
<a name="linux-more-information"></a>

Para obtener más información sobre el uso de las AMI de Amazon Linux optimizadas para Amazon EKS, consulte las siguientes secciones:
+ Para usar Amazon Linux con grupos de nodos administrados, consulte [Simplificación del ciclo de vida de los nodos con grupos de nodos administrados](managed-node-groups.md).
+ Para lanzar nodos autoadministrados de Amazon Linux, consulte [Obtención de los ID de AMI de Amazon Linux recomendados](retrieve-ami-id.md).
+ Para obtener información sobre la versión, consulte [Obtención de información acerca de la versión de la AMI de Amazon Linux](eks-linux-ami-versions.md).
+ Para recuperar los ID más recientes de las AMI de Amazon Linux optimizadas para Amazon EKS, consulte [Obtención de los ID de AMI de Amazon Linux recomendados](retrieve-ami-id.md).
+ Para los scripts de código abierto que se utilizan para crear las AMI optimizadas para Amazon EKS, consulte [Creación de una AMI de Amazon Linux optimizada para EKS personalizada](eks-ami-build-scripts.md).

# Actualización de Amazon Linux 2 a Amazon Linux 2023
<a name="al2023"></a>

**aviso**  
Amazon EKS dejó de publicar las AMI optimizadas para EKS de Amazon Linux 2 (AL2) el 26 de noviembre de 2025. Las AMI basadas en AL2023 y Bottlerocket para Amazon EKS están disponibles para todas las versiones de Kubernetes compatibles, lo que incluye la versión 1.33 y posteriores.

AL2023 es un sistema operativo basado en Linux diseñado para proporcionar un entorno seguro, estable y de alto rendimiento para las aplicaciones en la nube. Es la próxima generación de Amazon Linux de Amazon Web Services y está disponible en todas las versiones compatibles de Amazon EKS.

AL2023 ofrece varias mejoras con respecto al AL2. Para obtener una comparación completa, consulte [Comparación de AL2 y Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html) en la *Guía del usuario de Amazon Linux 2023*. Se han añadido, actualizado y eliminado varios paquetes de AL2. Se recomienda encarecidamente probar las aplicaciones con AL2023 antes de realizar la actualización. Para ver una lista de todos los cambios de paquetes en AL2023, consulte [Cambios de paquetes en Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/release-notes/compare-packages.html) en las *Notas de la versión de Amazon Linux 2023*.

Además de estos cambios, debe tener en cuenta lo siguiente:
+ AL2023 presenta 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
  ```

  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*.
+ En el caso de AL2023, `nodeadm` también cambia el formato para aplicar los parámetros al `kubelet` para cada nodo que utilice [https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec). En AL2, esto se hizo con el parámetro `--kubelet-extra-args`. Se suele utilizar para agregar etiquetas y taints a los nodos. En el siguiente ejemplo, se muestra cómo aplicar `maxPods` y `--node-labels` al nodo.

  ```
  ---
  apiVersion: node.eks.aws/v1alpha1
  kind: NodeConfig
  spec:
    cluster:
      name: test-cluster
      apiServerEndpoint: https://example.com
      certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
      cidr: 10.100.0.0/16
    kubelet:
      config:
        maxPods: 110
      flags:
        - --node-labels=karpenter.sh/capacity-type=on-demand,karpenter.sh/nodepool=test
  ```
+ Se requiere la versión `1.16.2` o posterior de CNI de Amazon VPC para AL2023.
+ De forma predeterminada, AL2023 requiere `IMDSv2`. `IMDSv2` tiene varios beneficios que ayudan a mejorar la postura de seguridad. Utiliza un método de autenticación orientado a la sesión que requiere la creación de un token secreto en una solicitud sencilla de HTTP PUT para iniciar la sesión. El tiempo de validez de un token de sesión puede oscilar entre 1 segundo y 6 horas. Para obtener más información sobre cómo realizar la transición de `IMDSv1` a `IMDSv2`, consulte [Transición a la versión 2 del servicio de metadatos de instancias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html) y [Cómo aprovechar todos los beneficios de IMDSv2 e inhabilitar IMDSv1 en toda la infraestructura de AWS](https://aws.amazon.com/blogs/security/get-the-full-benefits-of-imdsv2-and-disable-imdsv1-across-your-aws-infrastructure). Si desea utilizar `IMDSv1`, puede hacerlo si anula de manera manual la configuración mediante las propiedades de inicio de la opción de metadatos de la instancia.
**nota**  
Para el `IMDSv2` con AL2023, el recuento de saltos predeterminado para los grupos de nodos administrados puede variar:  
Cuando no se utiliza una plantilla de lanzamiento, el valor predeterminado es `1`. Esto significa que los contenedores no tendrán acceso a las credenciales del nodo mediante IMDS. Si necesita acceso del contenedor a las credenciales del nodo, puede hacerlo usando una [plantilla de lanzamiento personalizada de Amazon EC2](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-launchtemplate-metadataoptions.html).
Cuando se utiliza una AMI personalizada en una plantilla de lanzamiento, el valor predeterminado de `HttpPutResponseHopLimit` es `2`. Puede anular manualmente el `HttpPutResponseHopLimit` en la plantilla de lanzamiento.
Como alternativa, puede utilizar [Pod Identity de Amazon EKS](pod-identities.md) para proporcionar credenciales en lugar de `IMDSv2`.
+ AL2023 presenta la siguiente generación de jerarquías de grupos de control unificados (`cgroupv2`). `cgroupv2` se utiliza para implementar un tiempo de ejecución de contenedores y por `systemd`. Si bien AL2023 sigue incluyendo un código que puede hacer que el sistema funcione mediante `cgroupv1`, esta configuración no se recomienda ni se admite. Esta configuración se eliminará por completo en una futura versión importante de Amazon Linux.
+  Se requiere una versión de `eksctl` `0.176.0` o superior para que `eksctl` sea compatible con AL2023.

En el caso de los grupos de nodos administrados que existían con anterioridad, puede realizar una actualización local o una actualización azul/verde, según cómo utilice la plantilla de lanzamiento:
+ Si utiliza una AMI personalizada con un grupo de nodos administrado, puede realizar una actualización local si intercambia el ID de la AMI en la plantilla de lanzamiento. Debe asegurarse de que las aplicaciones y cualquier dato de usuario se transfieran primero a AL2023 antes de llevar a cabo esta estrategia de actualización.
+ Si utiliza grupos de nodos administrados con la plantilla de lanzamiento estándar o con una plantilla de lanzamiento personalizada que no especifica el ID de la AMI, deberá actualizar mediante una estrategia azul/verde. Una actualización azul/verde suele ser más compleja e implica la creación de un grupo de nodos completamente nuevo en el que se especificará AL2023 como tipo de AMI. Luego, será necesario configurar con cuidado el nuevo grupo de nodos para garantizar que todos los datos personalizados del grupo de nodos de AL2 sean compatibles con el nuevo sistema operativo. Una vez que el nuevo grupo de nodos se haya probado y validado con sus aplicaciones, podrá migrar pods del grupo de nodos anterior al nuevo grupo de nodos. Una vez completada la migración, puede eliminar el grupo de nodos anterior.

Si utiliza Karpenter y quiere utilizar AL2023, deberá modificar el campo de `EC2NodeClass` `amiFamily` con AL2023. De forma predeterminada, la desviación está habilitada en Karpenter. Esto significa que, una vez que se haya cambiado el campo `amiFamily`, Karpenter actualizará automáticamente los nodos de trabajo a la AMI más reciente cuando esté disponible.

## Información adicional sobre nodeadm
<a name="_additional_information_about_nodeadm"></a>

Al utilizar una AMI optimizada para EKS basada en Amazon Linux 2023 o al crear una AMI personalizada de EKS basada en Amazon Linux 2023 mediante los scripts de Packer proporcionados en el repositorio oficial de GitHub amazon-eks-ami, debe evitar ejecutar explícitamente nodeadm init dentro de los datos de usuario de EC2 o como parte de la AMI personalizada.

Si desea generar un NodeConfig dinámico en los datos de usuario, puede escribir esa configuración en un archivo yaml o json de configuración complementario en `/etc/eks/nodeadm.d`. Estos archivos de configuración se combinarán y se aplicarán al nodo cuando nodeadm init se inicie automáticamente más adelante en el proceso de arranque. Por ejemplo:

```
cat > /etc/eks/nodeadm.d/additional-node-labels.yaml << EOF
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  kubelet:
    flags:
      - --node-labels=foo=bar
EOF
```

Las AMI optimizadas para EKS basadas en Amazon Linux 2023 ejecutan automáticamente nodeadm init en dos fases mediante servicios de systemd independientes: nodeadm-config se ejecuta antes de la ejecución de los datos de usuario, mientras que nodeadm-run se ejecuta después. El servicio nodeadm-config establece las configuraciones básicas de containerd y kubelet antes de que se ejecuten los datos de usuario. El servicio nodeadm-run ejecuta determinados daemons del sistema y completa cualquier configuración final después de la ejecución de los datos de usuario. Si el comando nodeadm init se ejecuta una vez adicional, mediante los datos de usuario o una AMI personalizada, puede alterar el orden previsto de ejecución, lo que podría generar resultados inesperados, incluida una configuración incorrecta de las interfaces de red elásticas.

# Obtención de información acerca de la versión de la AMI de Amazon Linux
<a name="eks-linux-ami-versions"></a>

Las AMI de Amazon Linux optimizadas para Amazon EKS están versionadas por la versión de Kubernetes y la fecha de lanzamiento de la AMI en el siguiente formato:

```
k8s_major_version.k8s_minor_version.k8s_patch_version-release_date
```

Cada versión de AMI incluye varias versiones de [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/), el kernel de Linux y [containerd](https://containerd.io/). Las AMI aceleradas también incluyen varias versiones del controlador de NVIDIA. Puede encontrar la información de esta versión en [Changelog](https://github.com/awslabs/amazon-eks-ami/blob/main/CHANGELOG.md) en GitHub.

# Obtención de los ID de AMI de Amazon Linux recomendados
<a name="retrieve-ami-id"></a>

Al implementar nodos, puede especificar un ID de una imagen de máquina de Amazon (AMI) optimizada para Amazon EKS previamente creada. Para recuperar un ID de AMI que se ajuste a la configuración deseada, consulte la API del almacén de parámetros de AWS Systems Manager. Al utilizar esta API, se elimina la necesidad de buscar manualmente los ID de AMI optimizados para Amazon EKS. Para obtener más información, consulte [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html). La [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que utiliza debe tener el permiso `ssm:GetParameter` de IAM para recuperar los metadatos de la AMI optimizada para Amazon EKS.

Puede recuperar el ID de imagen de la última AMI de Amazon Linux optimizada para Amazon EKS recomendada con el siguiente comando, que usa el parámetro secundario `image_id`. Realice las siguientes modificaciones en el comando según sea necesario y, a continuación, ejecute el comando modificado:
+ Reemplace `<kubernetes-version>` por una [versión compatible de Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
+ Reemplace *ami-type* por una de las siguientes opciones: Para obtener más información sobre los tipos de instancias de Amazon EC2, consulte [Tipos de instancias de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html).
  + Use *amazon-linux-2023/x86\$164/standard* para instancias basadas en Amazon Linux 2023 (AL2023) `x86`.
  + Use *amazon-linux-2023/arm64/standard* para instancias ARM AL2023, como las instancias basadas en [AWS Graviton](https://aws.amazon.com/ec2/graviton/).
  + Use *amazon-linux-2023/x86\$164/nvidia* para las instancias aprobadas más recientes de NVIDIA AL2023 basadas en `x86`.
  + Use *amazon-linux-2023/arm64/nvidia* para las instancias aprobadas más recientes de NVIDIA AL2023 basadas en `arm64`.
  + Use *amazon-linux-2023/x86\$164/neuron* para las instancias más recientes de [AWS Neuron](https://aws.amazon.com/machine-learning/neuron/) AL2023.
+ Reemplace `<region-code>` por una [región de AWS compatible con Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) para la que desee el ID de la AMI.

```
aws ssm get-parameter --name /aws/service/eks/optimized-ami/<kubernetes-version>/<ami-type>/recommended/image_id \
    --region <region-code> --query "Parameter.Value" --output text
```

A continuación, se muestra un comando de ejemplo después de reemplazar los marcadores de posición.

```
aws ssm get-parameter --name /aws/service/eks/optimized-ami/1.31/amazon-linux-2023/x86_64/standard/recommended/image_id \
    --region us-west-2 --query "Parameter.Value" --output text
```

Un ejemplo de salida sería el siguiente.

```
ami-1234567890abcdef0
```

# Creación de una AMI de Amazon Linux optimizada para EKS personalizada
<a name="eks-ami-build-scripts"></a>

**aviso**  
Amazon EKS dejó de publicar las AMI optimizadas para EKS de Amazon Linux 2 (AL2) el 26 de noviembre de 2025. Las AMI basadas en AL2023 y Bottlerocket para Amazon EKS están disponibles para todas las versiones de Kubernetes compatibles, lo que incluye la versión 1.33 y posteriores.

Amazon EKS proporciona scripts de creación de código abierto en el repositorio de [especificaciones de creación de la AMI de Amazon EKS](https://github.com/awslabs/amazon-eks-ami) que podrá utilizar para ver las configuraciones de `kubelet`, el tiempo de ejecución y el autenticador de AWS IAM para Kubernetes, así como crear su propia AMI basada en AL desde cero.

Este repositorio contiene el [script de arranque para AL2](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) especializado y la [herramienta nodeadm para AL2023](https://awslabs.github.io/amazon-eks-ami/nodeadm/) que se ejecuta en el momento del arranque. Estos scripts configuran los datos de certificado de la instancia, el punto de conexión del plano de control, el nombre del clúster, etcétera. Estos scripts se consideran el origen de información verdadera para las creaciones de la AMI optimizada para Amazon EKS, de modo que puede seguir el repositorio de GitHub para supervisar los cambios en nuestras AMI.

Al crear AMI personalizadas con las AMI optimizadas para EKS como base, no se recomienda ni se admite ejecutar una actualización del sistema operativo (por ejemplo, `dnf upgrade`) ni actualizar cualquiera de los paquetes de Kubernetes o GPU que se incluyen en las AMI optimizadas para EKS, ya que se corre el riesgo de interrumpir la compatibilidad de los componentes. Si actualiza el sistema operativo o los paquetes que se incluyen en las AMI optimizadas para EKS, se recomienda llevar a cabo pruebas exhaustivas en un entorno de desarrollo o ensayo antes de implementarlas en producción.

Al crear AMI personalizadas para instancias de GPU, se recomienda crear AMI personalizadas independientes para cada familia y generación del tipo de instancia que vaya a ejecutar. Las AMI aceleradas optimizadas para EKS instalan de forma selectiva los controladores y paquetes en tiempo de ejecución en función de la familia y generación del tipo de instancia subyacentes. Para obtener más información, consulte los scripts de AMI de EKS para la [instalación](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2023/provisioners/install-nvidia-driver.sh) y el [tiempo de ejecución](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2023/runtime/gpu/nvidia-kmod-load.sh).

## Requisitos previos
<a name="_prerequisites"></a>
+  [Instalar la CLI de AWS](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) 
+  [Instalar HashiCorp Packer v1.9.4\$1](https://developer.hashicorp.com/packer/downloads) 
+  [Instalar GNU Make](https://www.gnu.org/software/make/) 

## Inicio rápido
<a name="_quickstart"></a>

En este inicio rápido, se muestran los comandos para crear una AMI personalizada en su cuenta de AWS. Para obtener más información sobre las configuraciones disponibles para personalizar la AMI, consulte las variables de plantilla en la página [Amazon Linux 2023](https://awslabs.github.io/amazon-eks-ami/usage/al2023/).

### Requisitos previos
<a name="_prerequisites_2"></a>

Instale el [complemento de Amazon](https://developer.hashicorp.com/packer/integrations/hashicorp/amazon) necesario. Por ejemplo:

```
packer plugins install github.com/hashicorp/amazon
```

### Paso 1. Configure su entorno
<a name="_step_1_setup_your_environment"></a>

Clone o bifurque el repositorio de AMI oficial de Amazon EKS. Por ejemplo:

```
git clone https://github.com/awslabs/amazon-eks-ami.git
cd amazon-eks-ami
```

Compruebe que Packer esté instalado:

```
packer --version
```

### Paso 2. Para crear una AMI de personalizada
<a name="_step_2_create_a_custom_ami"></a>

A continuación, se muestran ejemplos de comandos para varias AMI personalizadas.

 **AMI de NVIDIA AL2 básica:** 

```
make k8s=1.31 os_distro=al2 \
  enable_accelerator=nvidia \
  nvidia_driver_major_version=560 \
  enable_efa=true
```

 **AMI de NVIDIA AL2023 básica:** 

```
make k8s=1.31 os_distro=al2023 \
  enable_accelerator=nvidia \
  nvidia_driver_major_version=560 \
  enable_efa=true
```

 **AMI de Neuron AL2023 compatible con STIG:** 

```
make k8s=1.31 os_distro=al2023 \
  enable_accelerator=neuron \
  enable_fips=true \
  source_ami_id=ami-0abcd1234efgh5678 \
  kms_key_id=alias/aws-stig
```

Tras ejecutar estos comandos, Packer hará lo siguiente: \$1 Lanzará una instancia temporal de Amazon EC2. \$1 Instalará los componentes, los controladores y las configuraciones de Kubernetes. \$1 Creará la AMI en su cuenta de AWS.

El resultado esperado debe tener el siguiente aspecto:

```
==> Wait completed after 8 minutes 42 seconds

==> Builds finished. The artifacts of successful builds are:
--> amazon-ebs: AMIs were created:
us-west-2: ami-0e139a4b1a7a9a3e9

--> amazon-ebs: AMIs were created:
us-west-2: ami-0e139a4b1a7a9a3e9

--> amazon-ebs: AMIs were created:
us-west-2: ami-0e139a4b1a7a9a3e9
```

### Paso 3. Vea los valores predeterminados
<a name="_step_3_view_default_values"></a>

Para ver los valores predeterminados y las opciones adicionales, ejecute el siguiente comando:

```
make help
```

# Creación de nodos con AMI de Bottlerocket optimizadas
<a name="eks-optimized-ami-bottlerocket"></a>

 [Bottlerocket](https://aws.amazon.com/bottlerocket/) es una distribución de Linux de código abierto patrocinada y respaldada por AWS. Bottlerocket está diseñado específicamente para alojar cargas de trabajo de contenedores. Con Bottlerocket, puede mejorar la disponibilidad de las implementaciones en contenedores y reducir los costos operativos mediante la automatización de las actualizaciones de la infraestructura de contenedores. Bottlerocket incluye solo el software esencial para ejecutar los contenedores, lo que mejora el uso de los recursos, reduce las amenazas a la seguridad y reduce los gastos de administración. La AMI de Bottlerocket incluyes `containerd`, `kubelet` y el Autenticador de AWS IAM. Además de los grupos de nodos administrados y los nodos autoadministrados, Bottlerocket también es compatible con [Karpenter](https://karpenter.sh/).

## Ventajas
<a name="bottlerocket-advantages"></a>

Al utilizar Bottlerocket con el clúster de Amazon EKS, tiene las siguientes ventajas:
+  **Mayor tiempo de actividad con un menor costo operativo y una menor complejidad de administración:** Bottlerocket ocupa menos recursos, tiene tiempos de arranque más cortos y es menos vulnerable a las amenazas de seguridad que otras distribuciones de Linux. Una huella más pequeña de Bottlerocket ayuda a reducir los costos al utilizar menos recursos de almacenamiento, computación y redes.
+  **Seguridad mejorada gracias a las actualizaciones automáticas del sistema operativo**: las actualizaciones de Bottlerocket se aplican como una sola unidad y se pueden anular si es necesario. Esto elimina el riesgo de actualizaciones dañadas o fallidas que pueden dejar el sistema inutilizable. Con Bottlerocket, las actualizaciones de seguridad se pueden aplicar automáticamente tan pronto como estén disponibles de forma mínimamente disruptiva y revertirse si se producen errores.
+  **Soporte premium**: las versiones proporcionadas por AWS de Bottlerocket en Amazon EC2 están cubiertas por los mismos planes de AWS Support que también cubren servicios de AWS como Amazon EC2, Amazon EKS y Amazon ECR.

## Consideraciones
<a name="bottlerocket-considerations"></a>

Tenga en cuenta lo siguiente cuando utilice Bottlerocket para su tipo de AMI:
+ Bottlerocket admite instancias de Amazon EC2 con procesadores `x86_64` y `arm64`.
+ Bottlerocket admite instancias de Amazon EC2 con GPU. Para obtener más información, consulte [Uso de AMI aceleradas optimizadas para EKS para instancias de GPU](ml-eks-optimized-ami.md).
+ Las imágenes de Bottlerocket no incluyen un servidor SSH ni un intérprete de comandos. Puede utilizar métodos de acceso fuera de banda para permitir SSH. Estos métodos permiten el contenedor de administrador y superar algunos pasos de configuración de arranque con datos de usuario. Para obtener más información, consulte las siguientes secciones de [Bottlerocket OS](https://github.com/bottlerocket-os/bottlerocket/blob/develop/README.md) en GitHub:
  +  [Exploration (Exploración](https://github.com/bottlerocket-os/bottlerocket/blob/develop/README.md#exploration) 
  +  [Contenedor de administrador](https://github.com/bottlerocket-os/bottlerocket/blob/develop/README.md#admin-container) 
  +  [Configuración de Kubernetes](https://github.com/bottlerocket-os/bottlerocket/blob/develop/README.md#kubernetes-settings) 
+ Bottlerocket utiliza diferentes tipos de contenedores:
  + De forma predeterminada, se habilita un [contenedor de control](https://github.com/bottlerocket-os/bottlerocket-control-container). Este contenedor ejecuta el [agente de AWS Systems Manager](https://github.com/aws/amazon-ssm-agent) que puede utilizar para ejecutar comandos o iniciar sesiones de intérprete de comandos en instancias de Bottlerocket de Amazon EC2. Para obtener más información, consulte [Configuración del Administrador de sesiones](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started.html) en la *Guía del usuario de AWS*.
  + Si se proporciona una clave SSH al crear el grupo de nodos, se habilita un contenedor de administración. Recomendamos utilizar el contenedor de administración solo para escenarios de desarrollo y pruebas. No recomendamos utilizarlo en entornos de producción. Para obtener más información, consulte [Contenedor de administración](https://github.com/bottlerocket-os/bottlerocket/blob/develop/README.md#admin-container) en GitHub.

## Más información
<a name="bottlerocket-more-information"></a>

Para obtener más información sobre el uso de las AMI de Bottlerocket optimizadas para Amazon EKS, consulte las siguientes secciones:
+ Para obtener más información sobre Bottlerocket, consulte la [documentación de Bottlerocket](https://bottlerocket.dev/en/).
+ Para obtener recursos de información sobre la versión, consulte [Recuperación de información sobre la versión de la AMI de Bottlerocket](eks-ami-versions-bottlerocket.md).
+ Para usar Bottlerocket con grupos de nodos administrados, consulte [Simplificación del ciclo de vida de los nodos con grupos de nodos administrados](managed-node-groups.md).
+ Para lanzar nodos de Bottlerocket autoadministrados, consulte [Creación de nodos de Bottlerocket autoadministrados](launch-node-bottlerocket.md).
+ Para recuperar los ID más recientes de las AMI de Bottlerocket optimizadas para Amazon EKS, consulte [Recuperación de los ID de AMI de Bottlerocket recomendados](retrieve-ami-id-bottlerocket.md).
+ Para obtener más información sobre el soporte de cumplimiento, consulte [Cómo cumplir con los requisitos de conformidad mediante Bottlerocket](bottlerocket-compliance-support.md).

# Recuperación de información sobre la versión de la AMI de Bottlerocket
<a name="eks-ami-versions-bottlerocket"></a>

Cada versión de la AMI de Bottlerocket incluye varias versiones de [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/), el kernel de Bottlerocket y [containerd](https://containerd.io/). Las variantes de AMI aceleradas también incluyen varias versiones del controlador de NVIDIA. Encontrará más información sobre esta versión en el tema sobre el [sistema operativo](https://bottlerocket.dev/en/os/) en la *documentación de Bottlerocket*. En esta página, navegue hasta el subtema *Información sobre la versión* correspondiente.

A veces, la *documentación de Bottlerocket* puede retrasarse respecto a las versiones que están disponibles en GitHub. Puede encontrar una lista de los cambios de las últimas versiones en [Releases](https://github.com/bottlerocket-os/bottlerocket/releases) en GitHub.

# Recuperación de los ID de AMI de Bottlerocket recomendados
<a name="retrieve-ami-id-bottlerocket"></a>

Al implementar nodos, puede especificar un ID de una imagen de máquina de Amazon (AMI) optimizada para Amazon EKS previamente creada. Para recuperar un ID de AMI que se ajuste a la configuración deseada, consulte la API del almacén de parámetros de AWS Systems Manager. Al utilizar esta API, se elimina la necesidad de buscar manualmente los ID de AMI optimizados para Amazon EKS. Para obtener más información, consulte [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html). La [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que utiliza debe tener el permiso `ssm:GetParameter` de IAM para recuperar los metadatos de la AMI optimizada para Amazon EKS.

Puede recuperar el ID de imagen de la última AMI de Bottlerocket optimizada para Amazon EKS recomendada con el siguiente comando de la AWS CLI, que usa el parámetro secundario `image_id`. Realice las siguientes modificaciones en el comando según sea necesario y, a continuación, ejecute el comando modificado:
+ Reemplace *kubernetes-version* por cualquier [versión de la plataforma](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html) compatible.
+ Reemplace *-flavor* por una de las siguientes opciones:
  + Elimine *-flavor* para las variantes sin GPU.
  + Use *-nvidia* para las variantes con GPU habilitadas.
  + Utilice *-fips* para las variantes habilitadas para FIPS.
+ Reemplace *architecture* por una de las siguientes opciones:
  + Use *x86\$164* para instancias basadas en `x86`.
  + Use *arm64* para instancias de ARM.
+ Sustituya *region-code* por una [región de AWS compatible con Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) para la que desea el ID de AMI.

```
aws ssm get-parameter --name /aws/service/bottlerocket/aws-k8s-kubernetes-version-flavor/architecture/latest/image_id \
    --region region-code --query "Parameter.Value" --output text
```

A continuación, se muestra un comando de ejemplo después de reemplazar los marcadores de posición.

```
aws ssm get-parameter --name /aws/service/bottlerocket/aws-k8s-1.31/x86_64/latest/image_id \
    --region us-west-2 --query "Parameter.Value" --output text
```

Un ejemplo de salida sería el siguiente.

```
ami-1234567890abcdef0
```

# Cómo cumplir con los requisitos de conformidad mediante Bottlerocket
<a name="bottlerocket-compliance-support"></a>

Bottlerocket cumple con las recomendaciones definidas por varias organizaciones:
+ Hay un [punto de referencia del CIS](https://www.cisecurity.org/benchmark/bottlerocket) definido por Bottlerocket. En una configuración predeterminada, la imagen de Bottlerocket tiene la mayoría de los controles requeridos por el perfil de configuración de nivel 1 del CIS. Puede implementar los controles requeridos para un perfil de configuración de nivel 2 de CIS. Para obtener más información, consulte [Validar la AMI de Bottlerocket optimizada de Amazon EKS con el punto de referencia del CIS](https://aws.amazon.com/blogs/containers/validating-amazon-eks-optimized-bottlerocket-ami-against-the-cis-benchmark) en el blog de AWS.
+ El conjunto de características optimizado y la reducción de la superficie expuesta a ataques significan que las instancias de Bottlerocket requieren menos configuración para cumplir con los requisitos de PCI DSS. El [Punto de referencia de CIS para Bottlerocket](https://www.cisecurity.org/benchmark/bottlerocket) es un recurso excelente para reforzar las directrices y cumple con los requisitos de estándares de configuración segura según el requisito 2.2 de PCI DSS. También puede aprovechar [Fluent Bit](https://opensearch.org/blog/technical-post/2022/07/bottlerocket-k8s-fluent-bit/) para cumplir con sus requisitos de registro de auditorías a nivel de sistema operativo según el requisito 10.2 de PCI DSS. AWS publica instancias nuevas (con parches) de Bottlerocket periódicamente para ayudarlo a cumplir con los requisitos 6.2 de PCI DSS (para la versión 3.2.1) y 6.3.3 (para la versión 4.0).
+ Bottlerocket es una característica que cumple los requisitos de la HIPAA y está autorizada para su uso con cargas de trabajo reguladas tanto para Amazon EC2 como para Amazon EKS. Para obtener más información, consulte la [Referencia de servicios compatibles con HIPAA](https://aws.amazon.com/compliance/hipaa-eligible-services-reference/).
+ Existen AMI de Bottlerocket preconfiguradas para utilizar módulos criptográficos validados por FIPS 140-3. Entre otras, el módulo criptográfico Kernel Crypto API de Amazon Linux 2023 y el módulo criptográfico AWS-LC. Para obtener más información, consulte [Prepare sus nodos de trabajo para el FIPS con las AMI aprobadas por el FIPS de Bottlerocket](bottlerocket-fips-amis.md).

# Prepare sus nodos de trabajo para el FIPS con las AMI aprobadas por el FIPS de Bottlerocket
<a name="bottlerocket-fips-amis"></a>

El Estándar de procesamiento de la información federal (FIPS), publicación 140-3, es un estándar de los gobiernos de Estados Unidos y Canadá que especifica los requisitos de seguridad de los módulos criptográficos que protegen información confidencial. Bottlerocket facilita el cumplimiento del FIPS porque ofrece AMI con un kernel de FIPS.

Estas AMI están preconfiguradas para utilizar módulos criptográficos validados por FIPS 140-3. Entre otras, el módulo criptográfico Kernel Crypto API de Amazon Linux 2023 y el módulo criptográfico AWS-LC.

El uso de las AMI aprobadas por el FIPS de Bottlerocket hace que sus nodos de trabajo estén “preparados para el FIPS”, pero no hace que automáticamente “cumplan con el FIPS”. Para obtener más información, consulte [Estándar de procesamiento de la información federal (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).

## Consideraciones
<a name="_considerations"></a>
+ Si el clúster utiliza subredes aisladas, es posible que no se pueda acceder al punto de conexión del FIPS de Amazon ECR. Esto puede provocar que el arranque del nodo falle. Asegúrese de que la configuración de red permita el acceso a los puntos de conexión del FIPS necesarios. Para obtener más información, consulte [Acceso a un recurso a través un punto de conexión de VPC](https://docs.aws.amazon.com/vpc/latest/privatelink/use-resource-endpoint.html) en la *Guía de AWS PrivateLink*.
+ Si su clúster usa una subred con [PrivateLink](vpc-interface-endpoints.md), las extracciones de imágenes fallarán porque los puntos de conexión del FIPS de Amazon ECR no están disponibles a través de PrivateLink.

## Creación de un grupo de nodos administrados con una AMI aprobada por el FIPS de Bottlerocket
<a name="_create_a_managed_node_group_with_a_bottlerocket_fips_ami"></a>

La AMI Bottlerocket FIPS está disponible en cuatro variantes para admitir las cargas de trabajo.
+  `BOTTLEROCKET_x86_64_FIPS` 
+  `BOTTLEROCKET_ARM_64_FIPS` 
+  `BOTTLEROCKET_x86_64_NVIDIA_FIPS` 
+  `BOTTLEROCKET_ARM_64_NVIDIA_FIPS` 

Para crear un grupo de nodos administrado con una AMI aprobada por el FIPS de Bottlerocket, elija el tipo de AMI correspondiente durante el proceso de creación. Para obtener más información, consulte [Creación de un grupo de nodos administrados para un clúster](create-managed-node-group.md).

Para obtener más información sobre cómo seleccionar variantes compatibles con FIPS, consulte [Recuperación de los ID de AMI de Bottlerocket recomendados](retrieve-ami-id-bottlerocket.md).

## Deshabilite el punto de conexión del FIPS para las regiones de AWS no compatibles
<a name="disable_the_fips_endpoint_for_non_supported_shared_aws_regions"></a>

Las AMI aprobadas por el FIPS de Bottlerocket se admiten directamente en los Estados Unidos, incluidas las regiones de AWS GovCloud (EE. UU.). En las regiones de AWS en las que las AMI están disponibles, pero no se admiten directamente, puede seguir usándolas mediante la creación de un grupo de nodos administrados con una plantilla de lanzamiento.

La AMI aprobada por el FIPS de Bottlerocket se basa en el punto de conexión del FIPS de Amazon ECR durante el arranque, que generalmente no está disponible fuera de los Estados Unidos. Para usar la AMI para su kernel de FIPS en las regiones de AWS que no tienen disponible el punto de conexión del FIPS de Amazon ECR, siga estos pasos para inhabilitar el punto de conexión del FIPS:

1. Cree un nuevo archivo de configuración con el siguiente contenido o incorpórelo a su archivo de configuración existente.

```
[default]
use_fips_endpoint=false
```

1. Codifique el contenido del archivo en formato Base64.

1. En el `UserData` de la plantilla de lanzamiento, añada la siguiente cadena codificada en formato TOML:

```
[settings.aws]
config = "<your-base64-encoded-string>"
```

Para ver otros ajustes, consulte la [descripción de los ajustes](https://github.com/bottlerocket-os/bottlerocket?tab=readme-ov-file#description-of-settings) de Bottlerocket en GitHub.

A continuación, se muestra un ejemplo de `UserData` en una plantilla de lanzamiento:

```
[settings]
motd = "Hello from eksctl!"
[settings.aws]
config = "W2RlZmF1bHRdCnVzZV9maXBzX2VuZHBvaW50PWZhbHNlCg==" # Base64-encoded string.
[settings.kubernetes]
api-server = "<api-server-endpoint>"
cluster-certificate = "<cluster-certificate-authority>"
cluster-name = "<cluster-name>"
...<other-settings>
```

Para obtener más información acerca de la creación de una plantilla de lanzamiento, consulte [Personalización de nodos administrados con plantillas de lanzamiento](launch-templates.md).

# Creación de nodos con AMI de Ubuntu Linux optimizadas
<a name="eks-partner-amis"></a>

Canonical se ha asociado con Amazon EKS para crear AMI de nodo que puede utilizar en sus clústeres.

 [Canonical](https://www.canonical.com/) distribuye una imagen de sistema operativo de nodo de Kubernetes personalizada. Esta imagen de Ubuntu minimizada está optimizada para Amazon EKS e incluye el kernel de AWS personalizado desarrollado conjuntamente con AWS. Para obtener más información, consulte [Ubuntu en Amazon Elastic Kubernetes Service (EKS)](https://cloud-images.ubuntu.com/aws-eks/) y [Creación de nodos autoadministrados de Linux para Ubuntu](launch-node-ubuntu.md). Para obtener más información sobre la compatibilidad, consulte la sección de [Software de terceros](https://aws.amazon.com/premiumsupport/faqs/#Third-party_software) de las *Preguntas frecuentes sobre AWS Premium Support*.

# Creación de nodos con AMI de Windows optimizadas
<a name="eks-optimized-windows-ami"></a>

Las AMI optimizadas para Windows de Amazon EKS se basan en Windows Server 2019, Windows Server 2022 y Windows Server 2025. Están configuradas de modo que sirvan de imagen base para los nodos de Amazon EKS. De forma predeterminada, las AMI incluyen los siguientes componentes:
+  [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) 
+  [kube-proxy](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/) 
+  [Autenticador de AWS IAM para Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator) 
+  [csi-proxy](https://github.com/kubernetes-csi/csi-proxy) 
+  [containerd](https://containerd.io/) 

**nota**  
Puede realizar un seguimiento de eventos de seguridad o privacidad para Windows Server con la [guía de actualización de seguridad de Microsoft](https://portal.msrc.microsoft.com/en-us/security-guidance).

Amazon EKS ofrece las siguientes variantes de AMI optimizadas para contenedores de Windows:
+ La AMI de Windows Server 2019 Core optimizada para Amazon EKS
+ AMI de Windows Server 2019 Full optimizada para Amazon EKS
+ AMI de Windows Server 2022 Core optimizada para Amazon EKS
+ AMI de Windows Server 2022 Full optimizada para Amazon EKS
+ La AMI de Windows Server 2025 Core optimizada para Amazon EKS
+ AMI de Windows Server 2025 Full optimizada para Amazon EKS

**importante**  
La AMI de Windows Server 20H2 Core optimizada para Amazon EKS está obsoleta. No se lanzarán nuevas versiones de esta AMI.
Para asegurarse de que dispone de las actualizaciones de seguridad más recientes de forma predeterminada, Amazon EKS mantiene optimizada las AMI de Windows durante los últimos cuatro meses. Cada nueva AMI estará disponible durante cuatro meses a partir del momento de su lanzamiento inicial. Después de este período, las AMI más antiguas pasan a ser privadas y ya no se podrá acceder a ellas. Recomendamos utilizar las AMI más recientes para evitar vulnerabilidades de seguridad y perder el acceso a las AMI más antiguas que hayan llegado al final de su vida útil. Si bien no podemos garantizar que podamos proporcionar acceso a las AMI que se han convertido en privadas, puede solicitar el acceso enviando un ticket a AWS Support.

## Calendario de versiones
<a name="windows-ami-release-calendar"></a>

En la siguiente tabla se enumeran las fechas de lanzamiento y finalización de la compatibilidad para las versiones de Windows de Amazon EKS. Si una fecha de finalización está en blanco, significa que la versión aún es compatible.


| Versión de Windows | Versión de Amazon EKS | Fin de la compatibilidad de Amazon EKS | 
| --- | --- | --- | 
|  Windows Server 2025 Core  |  27/01/2026  |  | 
|  Windows Server 2025 Full  |  27/01/2026  |  | 
|  Windows Server 2022 Core  |  17/10/2022  |  | 
|  Windows Server 2022 Full  |  17/10/2022  |  | 
|  Windows Server 20H2 Core  |  12/08/2021  |  09/08/2022  | 
|  Windows Server 2004 Core  |  8/19/2020  |  14/12/2021  | 
|  Windows Server 2019 Core  |  07/10/2019  |  | 
|  Windows Server 2019 Full  |  07/10/2019  |  | 
|  Windows Server 1909 Core  |  07/10/2019  |  08/12/2020  | 

## Parámetros de configuración del script de arranque
<a name="bootstrap-script-configuration-parameters"></a>

Al crear un nodo de Windows, hay un script en el nodo que permite la configuración de diferentes parámetros. Según la configuración, este script se puede encontrar en el nodo en una ubicación similar a: `C:\Program Files\Amazon\EKS\Start-EKSBootstrap.ps1`. Para especificar valores de parámetros personalizados, puede especificarlos como argumentos del script de arranque. Por ejemplo, puede actualizar los datos de usuario en la plantilla de lanzamiento. Para obtener más información, consulte [Datos de usuario de Amazon EC2](launch-templates.md#launch-template-user-data).

El script incluye los siguientes parámetros de la línea de comandos:
+  `-EKSClusterName`: especifica el nombre del clúster de Amazon EKS para que este nodo de trabajo se va a unir.
+  `-KubeletExtraArgs`: especifica argumentos adicionales para `kubelet` (opcional).
+  `-KubeProxyExtraArgs`: especifica argumentos adicionales para `kube-proxy` (opcional).
+  `-APIServerEndpoint`: especifica el punto de conexión del servidor de API del clúster de Amazon EKS (opcional). Solo válido cuando se utiliza con `-Base64ClusterCA`. Se omite llamando a `Get-EKSCluster`.
+  `-Base64ClusterCA`: especifica el contenido de CA de clúster codificado en base64 (opcional). Solo válido cuando se utiliza con `-APIServerEndpoint`. Se omite llamando a `Get-EKSCluster`.
+  `-DNSClusterIP`: sustituye la dirección IP que se va a utilizar para las consultas DNS dentro del clúster (opcional). El valor predeterminado es `10.100.0.10` o `172.20.0.10` en función de la dirección IP de la interfaz principal.
+  `-ServiceCIDR`: anula el rango de direcciones IP del servicio de Kubernetes desde el que se direccionan los servicios del clúster. El valor predeterminado es `172.20.0.0/16` o `10.100.0.0/16` en función de la dirección IP de la interfaz principal.
+  `-ExcludedSnatCIDRs`: lista de los CIDR de `IPv4` que se deben excluir de la traducción de direcciones de red de origen (SNAT). Esto implica que la IP privada del pod, que es accesible dentro de la VPC, no se traduciría a la dirección IP de la dirección `IPv4` principal de la ENI de la instancia para el tráfico saliente. De forma predeterminada, se agrega el CIDR de `IPv4` de la VPC para el nodo de Windows de Amazon EKS. Al especificar los CIDR en este parámetro también se excluyen los CIDR especificados. Para obtener más información, consulte [Habilitación del acceso a Internet saliente para pods](external-snat.md).

Además de los parámetros de la línea de comandos, también puede especificar algunos parámetros de variables de entorno. Cuando se especifica un parámetro de la línea de comandos, tiene prioridad sobre la variable de entorno correspondiente. Las variables de entorno deben definirse con la máquina (o sistema) como ámbito, ya que el script de arranque solo leerá variables cuyo ámbito sea la máquina.

El script tiene en cuenta las siguientes variables de entorno:
+  `SERVICE_IPV4_CIDR`: consulte el parámetro de la línea de comandos `ServiceCIDR` para ver la definición.
+  `EXCLUDED_SNAT_CIDRS`: debe ser una cadena separada por comas. Consulte el parámetro de la línea de comandos `ExcludedSnatCIDRs` para ver la definición.

### Soporte de autenticación de gMSA
<a name="ad-and-gmsa-support"></a>

Los pods de Windows de Amazon EKS permiten diferentes tipos de autenticación de cuenta de servicio administrada por grupo (gMSA).
+ Amazon EKS admite identidades de dominio de Active Directory para la autenticación. Para obtener más información sobre la gMSA unida a un dominio, consulte [Windows Authentication on Amazon EKS Windows pods](https://aws.amazon.com/blogs/containers/windows-authentication-on-amazon-eks-windows-pods) en el blog de AWS.
+ Amazon EKS ofrece un complemento que permite que los nodos de Windows que no están unidos a un dominio recuperen credenciales de gMSA con una identidad de usuario portátil. Para obtener más información sobre la gMSA sin dominio, consulte [Domainless Windows Authentication for Amazon EKS Windows pods](https://aws.amazon.com/blogs/containers/domainless-windows-authentication-for-amazon-eks-windows-pods) en el blog de AWS.

## Imágenes de contenedor en caché
<a name="windows-cached-container-images"></a>

Las AMI de Windows optimizadas para Amazon EKS poseen algunas imágenes de contenedor en caché para los tiempos de ejecución de `containerd`. Las imágenes de los contenedores se almacenan en caché al crear AMI personalizadas mediante componentes de compilación administrados por Amazon. Para obtener más información, consulte [Uso del componente de compilación administrado por Amazon](eks-custom-ami-windows.md#custom-windows-ami-build-component).

Las siguientes imágenes de contenedores en caché son para el tiempo de ejecución de `containerd`:
+  `amazonaws.com/eks/pause-windows` 
+  `mcr.microsoft.com/windows/nanoserver` 
+  `mcr.microsoft.com/windows/servercore` 

## Más información
<a name="windows-more-information"></a>

Para obtener más información sobre el uso de las AMI de Windows optimizadas para Amazon EKS, consulte las siguientes secciones:
+ Para obtener más información sobre la ejecución de cargas de trabajo en AMI de Windows aceleradas y optimizadas para Amazon EKS, consulte [Ejecución de contenedores acelerados por GPU (Windows en EC2 G-Series)](ml-eks-windows-optimized-ami.md).
+ Para usar Windows con grupos de nodos administrados, consulte [Simplificación del ciclo de vida de los nodos con grupos de nodos administrados](managed-node-groups.md).
+ Para lanzar nodos de Windows autoadministrados, consulte [Creación de nodos autoadministrados de Microsoft Windows](launch-windows-workers.md).
+ Para obtener información sobre la versión, consulte [Recuperación de la información sobre la versión de la AMI de Windows](eks-ami-versions-windows.md).
+ Para recuperar los ID más recientes de las AMI de Windows optimizadas para Amazon EKS, consulte [Recuperación de los ID de AMI de Microsoft Windows recomendados](retrieve-windows-ami-id.md).
+ Para utilizar el Generador de imágenes de Amazon EC2 para crear las AMI de Windows personalizadas optimizadas para Amazon EKS, consulte [Creación de una AMI de Windows personalizada con el Generador de imágenes](eks-custom-ami-windows.md).
+ Para conocer las prácticas recomendadas, consulte [Administración de AMI de Windows optimizadas para Amazon EKS](https://aws.github.io/aws-eks-best-practices/windows/docs/ami/) en la *Guía de prácticas recomendadas de EKS*.

# Creación de nodos de Windows Server 2022 autoadministrados con `eksctl`
<a name="self-managed-windows-server-2022"></a>

Puede usar `test-windows-2022.yaml` como referencia para crear nodos autoadministrados de Windows Server 2022. Reemplace los *valores de ejemplo* por sus propios valores.

**nota**  
Debe usar la versión de `eksctl` [0.116.0](https://github.com/weaveworks/eksctl/releases/tag/v0.116.0) o una posterior para poner en funcionamiento nodos autoadministrados de Windows Server 2022.

```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: windows-2022-cluster
  region: region-code
  version: '1.35'

nodeGroups:
  - name: windows-ng
    instanceType: m5.2xlarge
    amiFamily: WindowsServer2022FullContainer
    volumeSize: 100
    minSize: 2
    maxSize: 3
  - name: linux-ng
    amiFamily: AmazonLinux2
    minSize: 2
    maxSize: 3
```

Los grupos de nodos se pueden crear con el siguiente comando.

```
eksctl create cluster -f test-windows-2022.yaml
```

# Recuperación de la información sobre la versión de la AMI de Windows
<a name="eks-ami-versions-windows"></a>

En este tema, se enumeran las versiones de las AMI de Windows optimizadas para Amazon EKS y sus versiones correspondientes de [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/), [containerd](https://containerd.io/) y [csi-proxy](https://github.com/kubernetes-csi/csi-proxy).

Los metadatos de la AMI optimizada para Amazon EKS, incluido el ID de la AMI, de cada variante se pueden recuperar mediante programación. Para obtener más información, consulte [Recuperación de los ID de AMI de Microsoft Windows recomendados](retrieve-windows-ami-id.md).

Las AMI están versionadas por la versión de Kubernetes y la fecha de lanzamiento de la AMI en el siguiente formato:

```
k8s_major_version.k8s_minor_version-release_date
```

**nota**  
Los grupos de nodos administrados de Amazon EKS admiten las versiones de noviembre de 2022 y posteriores de las AMI de Windows.

Para recibir notificaciones de todos los cambios en el archivo de origen de esta página de documentación específica, puede suscribirse a la siguiente URL con un lector de RSS:

```
https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/nodes/eks-ami-versions-windows.adoc.atom
```

## AMI de Windows Server 2025 Core optimizada para Amazon EKS
<a name="eks-ami-versions-windows-2025-core"></a>

En las siguientes tablas, se enumeran las versiones actuales y anteriores de la AMI de Windows Server 2025 Core optimizada para Amazon EKS.

**Example**  


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.35-2026.02.16`   |   `1.35.0`   |   `2.1.6`   |   `1.2.1`   |  | 
|   `1.35-2026-01-22`   |   `1.35.0`   |   `2.1.6`   |   `1.2.1`   |  | 

## AMI de Windows Server 2025 Full optimizada para Amazon EKS
<a name="eks-ami-versions-windows-2025-full"></a>

En las siguientes tablas, se enumeran las versiones actuales y anteriores de la AMI de Windows Server 2025 Full optimizada para Amazon EKS.

**Example**  


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.35-2026.02.16`   |   `1.35.0`   |   `2.1.6`   |   `1.2.1`   |  | 
|   `1.35-2026-01-22`   |   `1.35.0`   |   `2.1.6`   |   `1.2.1`   |  | 

## AMI de Windows Server 2022 Core optimizada para Amazon EKS
<a name="eks-ami-versions-windows-2022-core"></a>

En las siguientes tablas, se enumeran las versiones actuales y anteriores de la AMI de Windows Server 2022 Core optimizada para Amazon EKS.

**Example**  


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.35-2026.02.16`   |   `1.35.0`   |   `2.1.6`   |   `1.2.1`   |  | 
|   `1.35-2026-01-22`   |   `1.35.0`   |   `2.1.6`   |   `1.2.1`   |  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.34-2026.02.13`   |   `1.34.3`   |   `2.1.6`   |   `1.2.1`   |  | 
|   `1.34-2026.01.22`   |   `1.34.2`   |   `2.1.6`   |   `1.2.1`   |  Se actualizó `containerd` a `2.1.6`.  | 
|   `1.34-2025.12.15`   |   `1.34.2`   |   `2.1.4`   |   `1.2.1`   |  | 
|   `1.34-2025.11.14`   |   `1.34.1`   |   `2.1.4`   |   `1.2.1`   |  | 
|   `1.34-2025.10.18`   |   `1.34.1`   |   `2.1.4`   |   `1.2.1`   |  | 
|   `1.34-2025.09.13`   |   `1.34.0`   |   `2.1.4`   |   `1.2.1`   |  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.33-2026.02.13`   |   `1.33.7`   |   `1.7.30`   |   `1.2.1`   |  | 
|   `1.33-2026.01.22`   |   `1.33.5`   |   `1.7.30`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.30`.  | 
|   `1.33-2025.12.15`   |   `1.33.5`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.33-2025.11.14`   |   `1.33.5`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.33-2025.10.18`   |   `1.33.5`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.33-2025.09.13`   |   `1.33.4`   |   `1.7.28`   |   `1.2.1`   |  Se cambiaron los registros del complemento gMSA a Eventos de Windows.  | 
|   `1.33-2025.08.18`   |   `1.33.3`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.33-2025.07.16`   |   `1.33.1`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.33-2025.06.13`   |   `1.33.1`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.33-2025.05.17`   |   `1.33.1`   |   `1.7.27`   |   `1.2.1`   |  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.32-2026.02.13`   |   `1.32.11`   |   `1.7.30`   |   `1.2.1`   |  | 
|   `1.32-2026.01.22`   |   `1.32.9`   |   `1.7.30`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.30`.  | 
|   `1.32-2025.12.15`   |   `1.32.9`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.32-2025.11.14`   |   `1.32.9`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.32-2025.10.18`   |   `1.32.9`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.32-2025.09.13`   |   `1.32.8`   |   `1.7.28`   |   `1.2.1`   |  Se cambiaron los registros del complemento gMSA a Eventos de Windows.  | 
|   `1.32-2025.08.18`   |   `1.32.7`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.32-2025.07.16`   |   `1.32.5`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.32-2025.06.13`   |   `1.32.5`   |   `1.7.27`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.27`.  | 
|   `1.32-2025.05.17`   |   `1.32.5`   |   `1.7.20`   |   `1.2.1`   |  | 
|   `1.32-2025.04.14`   |   `1.32.1`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.32-2025.03.14`   |   `1.32.1`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.32-2025.02.18`   |   `1.32.1`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.32-2025.01.15`   |   `1.32.0`   |   `1.7.20`   |   `1.1.3`   |  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.31-2026.02.13`   |   `1.31.14`   |   `1.7.30`   |   `1.2.1`   |  | 
|   `1.31-2026.01.22`   |   `1.31.13`   |   `1.7.30`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.30`.  | 
|   `1.31-2025.12.15`   |   `1.31.13`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.31-2025.11.14`   |   `1.31.13`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.31-2025.10.18`   |   `1.31.13`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.31-2025.09.13`   |   `1.31.12`   |   `1.7.28`   |   `1.2.1`   |  Se cambiaron los registros del complemento gMSA a Eventos de Windows.  | 
|   `1.31-2025.08.18`   |   `1.31.11`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.31-2025.07.16`   |   `1.31.9`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.31-2025.06.13`   |   `1.31.9`   |   `1.7.27`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.27`.  | 
|   `1.31-2025.05.17`   |   `1.31.9`   |   `1.7.20`   |   `1.2.1`   |  | 
|   `1.31-2025.04.14`   |   `1.31.5`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2025.03.14`   |   `1.31.5`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2025.02.15`   |   `1.31.5`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2025.01.15`   |   `1.31.4`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2025.01.01`   |   `1.31.4`   |   `1.7.20`   |   `1.1.3`   |  Incluye parches para `CVE-2024-9042`.  | 
|   `1.31-2024.12.13`   |   `1.31.3`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2024.11.12`   |   `1.31.1`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2024.10.08`   |   `1.31.1`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2024.10.01`   |   `1.31.1`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2024.09.10`   |   `1.31.0`   |   `1.7.20`   |   `1.1.3`   |  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.30-2026.02.13`   |   `1.30.14`   |   `1.7.30`   |   `1.2.1`   |  | 
|   `1.30-2026.01.22`   |   `1.30.14`   |   `1.7.30`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.30`.  | 
|   `1.30-2025.12.15`   |   `1.30.14`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.30-2025.11.21`   |   `1.30.14`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.30-2025.10.18`   |   `1.30.14`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.30-2025.09.13`   |   `1.30.14`   |   `1.7.28`   |   `1.2.1`   |  Se cambiaron los registros del complemento gMSA a Eventos de Windows.  | 
|   `1.30-2025.08.18`   |   `1.30.14`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.30-2025.07.16`   |   `1.30.13`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.30-2025.06.13`   |   `1.30.13`   |   `1.7.27`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.27`.  | 
|   `1.30-2025.05.17`   |   `1.30.13`   |   `1.7.20`   |   `1.2.1`   |  | 
|   `1.30-2025.04.14`   |   `1.30.9`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.30-2025.03.14`   |   `1.30.9`   |   `1.7.20`   |   `1.1.3`   |  Se actualizó `containerd` a `1.7.20`.  | 
|   `1.30-2025.02.15`   |   `1.30.9`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2025.01.15`   |   `1.30.8`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2025.01.01`   |   `1.30.8`   |   `1.7.14`   |   `1.1.3`   |  Incluye parches para `CVE-2024-9042`.  | 
|   `1.30-2024.12.11`   |   `1.30.7`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2024.11.12`   |   `1.30.4`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2024.10.08`   |   `1.30.4`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2024.09.10`   |   `1.30.2`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2024.08.13`   |   `1.30.2`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2024.07.10`   |   `1.30.2`   |   `1.7.14`   |   `1.1.2`   |  Incluye parches para `CVE-2024-5321`.  | 
|   `1.30-2024.06.17`   |   `1.30.0`   |   `1.7.14`   |   `1.1.2`   |  Se actualizó `containerd` a `1.7.14`.  | 
|   `1.30-2024.05.15`   |   `1.30.0`   |   `1.6.28`   |   `1.1.2`   |  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.29-2026.02.13`   |   `1.29.15`   |   `1.7.30`   |   `1.2.1`   |  | 
|   `1.29-2026.01.22`   |   `1.29.15`   |   `1.7.30`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.30`.  | 
|   `1.29-2025.12.15`   |   `1.29.15`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.29-2025.11.14`   |   `1.29.15`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.29-2025.10.18`   |   `1.29.15`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.29-2025.09.13`   |   `1.29.15`   |   `1.7.28`   |   `1.2.1`   |  Se cambiaron los registros del complemento gMSA a Eventos de Windows.  | 
|   `1.29-2025.08.18`   |   `1.29.15`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.29-2025.07.16`   |   `1.29.15`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.29-2025.06.13`   |   `1.29.15`   |   `1.7.27`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.27`.  | 
|   `1.29-2025.05.17`   |   `1.29.15`   |   `1.7.20`   |   `1.2.1`   |  | 
|   `1.29-2025.04.14`   |   `1.29.13`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.29-2025.03.14`   |   `1.29.13`   |   `1.7.20`   |   `1.1.3`   |  Se actualizó `containerd` a `1.7.20`.  | 
|   `1.29-2025.02.15`   |   `1.29.13`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2025.01.15`   |   `1.29.12`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2025.01.01`   |   `1.29.12`   |   `1.7.14`   |   `1.1.3`   |  Incluye parches para `CVE-2024-9042`.  | 
|   `1.29-2024.12.11`   |   `1.29.10`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2024.11.12`   |   `1.29.8`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2024.10.08`   |   `1.29.8`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2024.09.10`   |   `1.29.6`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2024.08.13`   |   `1.29.6`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2024.07.10`   |   `1.29.6`   |   `1.7.11`   |   `1.1.2`   |  Incluye parches para `CVE-2024-5321`.  | 
|   `1.29-2024.06.17`   |   `1.29.3`   |   `1.7.11`   |   `1.1.2`   |  | 
|   `1.29-2024.05.15`   |   `1.29.3`   |   `1.7.11`   |   `1.1.2`   |  Se actualizó `containerd` a `1.7.11`. Se actualizó `kubelet` a `1.29.3`.  | 
|   `1.29-2024.04.09`   |   `1.29.0`   |   `1.6.28`   |   `1.1.2`   |  Se actualizó `containerd` a `1.6.28`. Se volvieron a crear CNI y `csi-proxy` mediante `golang 1.22.1`.  | 
|   `1.29-2024.03.12`   |   `1.29.0`   |   `1.6.25`   |   `1.1.2`   |  | 
|   `1.29-2024.02.13`   |   `1.29.0`   |   `1.6.25`   |   `1.1.2`   |  | 
|   `1.29-2024.02.06`   |   `1.29.0`   |   `1.6.25`   |   `1.1.2`   |  Se corrigió el error de que la imagen de pausa se borraba incorrectamente durante el proceso de recogida de basura de `kubelet`.  | 
|   `1.29-2024.01.11`   |   `1.29.0`   |   `1.6.18`   |   `1.1.2`   |  Se excluye la actualización independiente de Windows [KB5034439](https://support.microsoft.com/en-au/topic/kb5034439-windows-recovery-environment-update-for-azure-stack-hci-version-22h2-and-windows-server-2022-january-9-2024-6f9d26e6-784c-4503-a3c6-0beedda443ca) en las AMI principales de Windows Server 2022. La base de conocimientos se aplica solo a las instalaciones de Windows con una partición de WinRE independiente, las cuales no se incluyen en ninguna de las AMI de Windows optimizadas para Amazon EKS.  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.28-2025.11.14`   |   `1.28.15`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.28-2025.10.18`   |   `1.28.15`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.28-2025.09.13`   |   `1.28.15`   |   `1.7.28`   |   `1.2.1`   |  Se cambiaron los registros del complemento gMSA a Eventos de Windows.  | 
|   `1.28-2025.08.18`   |   `1.28.15`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.28-2025.07.16`   |   `1.28.15`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.28-2025.06.13`   |   `1.28.15`   |   `1.7.27`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.27`.  | 
|   `1.28-2025.05.17`   |   `1.28.15`   |   `1.7.20`   |   `1.2.1`   |  | 
|   `1.28-2025.04.14`   |   `1.28.15`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.28-2025.03.14`   |   `1.28.15`   |   `1.7.20`   |   `1.1.3`   |  Se actualizó `containerd` a `1.7.20`.  | 
|   `1.28-2025.02.15`   |   `1.28.15`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2025.01.15`   |   `1.28.15`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2025-01-01`   |   `1.28.15`   |   `1.7.14`   |   `1.1.3`   |  Incluye parches para `CVE-2024-9042`.  | 
|   `1.28-2024.12.11`   |   `1.28.15`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2024.11.12`   |   `1.28.13`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2024.10.08`   |   `1.28.13`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2024.09.10`   |   `1.28.11`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2024.08.13`   |   `1.28.11`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2024.07.10`   |   `1.28.11`   |   `1.7.11`   |   `1.1.2`   |  Incluye parches para `CVE-2024-5321`.  | 
|   `1.28-2024.06.17`   |   `1.28.8`   |   `1.7.11`   |   `1.1.2`   |  Se actualizó `containerd` a `1.7.11`.  | 
|   `1.28-2024.05.14`   |   `1.28.8`   |   `1.6.28`   |   `1.1.2`   |  Se actualizó `containerd` a `1.6.28`. Se actualizó `kubelet` a `1.28.8`.  | 
|   `1.28-2024.04.09`   |   `1.28.5`   |   `1.6.25`   |   `1.1.2`   |  Se actualizó `containerd` a `1.6.25`. Se volvieron a crear CNI y `csi-proxy` mediante `golang 1.22.1`.  | 
|   `1.28-2024.03.12`   |   `1.28.5`   |   `1.6.18`   |   `1.1.2`   |  | 
|   `1.28-2024.02.13`   |   `1.28.5`   |   `1.6.18`   |   `1.1.2`   |  | 
|   `1.28-2024.01.11`   |   `1.28.5`   |   `1.6.18`   |   `1.1.2`   |  Se excluye la actualización independiente de Windows [KB5034439](https://support.microsoft.com/en-au/topic/kb5034439-windows-recovery-environment-update-for-azure-stack-hci-version-22h2-and-windows-server-2022-january-9-2024-6f9d26e6-784c-4503-a3c6-0beedda443ca) en las AMI principales de Windows Server 2022. La base de conocimientos se aplica solo a las instalaciones de Windows con una partición de WinRE independiente, las cuales no se incluyen en ninguna de las AMI de Windows optimizadas para Amazon EKS.  | 
|   `1.28-2023.12.12`   |   `1.28.3`   |   `1.6.18`   |   `1.1.2`   |  | 
|   `1.28-2023.11.14`   |   `1.28.3`   |   `1.6.18`   |   `1.1.2`   |  Incluye parches para `CVE-2023-5528`.  | 
|   `1.28-2023.10.19`   |   `1.28.2`   |   `1.6.18`   |   `1.1.2`   |  Se actualizó `containerd` a `1.6.18`. Se agregaron nuevas [variables de entorno de script de arranque](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters) (`SERVICE_IPV4_CIDR` y `EXCLUDED_SNAT_CIDRS`).  | 
|   `1.28-2023-09.27`   |   `1.28.2`   |   `1.6.6`   |   `1.1.2`   |  Se ha corregido un [aviso de seguridad](https://github.com/advisories/GHSA-6xv5-86q9-7xr8) en `kubelet`.  | 
|   `1.28-2023.09.12`   |   `1.28.1`   |   `1.6.6`   |   `1.1.2`   |  | 

## AMI de Windows Server 2022 Full optimizada para Amazon EKS
<a name="eks-ami-versions-windows-2022-full"></a>

En las siguientes tablas, se enumeran las versiones actuales y anteriores de la AMI de Windows Server 2022 Full optimizada para Amazon EKS.

**Example**  


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.35-2026.02.16`   |   `1.35.0`   |   `2.1.6`   |   `1.2.1`   |  | 
|   `1.35-2026-01-22`   |   `1.35.0`   |   `2.1.6`   |   `1.2.1`   |  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.34-2026.02.13`   |   `1.34.3`   |   `2.1.6`   |   `1.2.1`   |  | 
|   `1.34-2026.01.22`   |   `1.34.2`   |   `2.1.6`   |   `1.2.1`   |  Se actualizó `containerd` a `2.1.6`.  | 
|   `1.34-2025.12.15`   |   `1.34.2`   |   `2.1.4`   |   `1.2.1`   |  | 
|   `1.34-2025.11.14`   |   `1.34.1`   |   `2.1.4`   |   `1.2.1`   |  | 
|   `1.34-2025.10.18`   |   `1.34.1`   |   `2.1.4`   |   `1.2.1`   |  | 
|   `1.34-2025.09.13`   |   `1.34.0`   |   `2.1.4`   |   `1.2.1`   |  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.33-2026.02.13`   |   `1.33.7`   |   `1.7.30`   |   `1.2.1`   |  | 
|   `1.33-2026.01.22`   |   `1.33.5`   |   `1.7.30`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.30`.  | 
|   `1.33-2025.12.15`   |   `1.33.5`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.33-2025.11.14`   |   `1.33.5`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.33-2025.10.18`   |   `1.33.5`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.33-2025.09.13`   |   `1.33.4`   |   `1.7.28`   |   `1.2.1`   |  Se cambiaron los registros del complemento gMSA a Eventos de Windows.  | 
|   `1.33-2025.08.18`   |   `1.33.3`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.33-2025.07.16`   |   `1.33.1`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.33-2025.06.13`   |   `1.33.1`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.33-2025.05.17`   |   `1.33.1`   |   `1.7.27`   |   `1.2.1`   |  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.32-2026.02.13`   |   `1.32.11`   |   `1.7.30`   |   `1.2.1`   |  | 
|   `1.32-2026.01.22`   |   `1.32.9`   |   `1.7.30`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.30`.  | 
|   `1.32-2025.12.15`   |   `1.32.9`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.32-2025.11.14`   |   `1.32.9`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.32-2025.10.18`   |   `1.32.9`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.32-2025.09.13`   |   `1.32.8`   |   `1.7.28`   |   `1.2.1`   |  Se cambiaron los registros del complemento gMSA a Eventos de Windows.  | 
|   `1.32-2025.08.18`   |   `1.32.7`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.32-2025.07.16`   |   `1.32.5`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.32-2025.06.13`   |   `1.32.5`   |   `1.7.27`   |   `1.2.1`   |  Se actualizó `containrd` a `1.7.27`   | 
|   `1.32-2025.05.17`   |   `1.32.5`   |   `1.7.20`   |   `1.2.1`   |  | 
|   `1.32-2025.04.14`   |   `1.32.1`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.32-2025.03.14`   |   `1.32.1`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.32-2025.02.18`   |   `1.32.1`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.32-2025.01.01`   |   `1.32.0`   |   `1.7.20`   |   `1.1.3`   |  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.31-2026.02.13`   |   `1.31.14`   |   `1.7.30`   |   `1.2.1`   |  | 
|   `1.31-2026.01.22`   |   `1.31.13`   |   `1.7.30`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.30`.  | 
|   `1.31-2025.12.15`   |   `1.31.13`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.31-2025.11.14`   |   `1.31.13`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.31-2025.10.18`   |   `1.31.13`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.31-2025.09.13`   |   `1.31.12`   |   `1.7.28`   |   `1.2.1`   |  Se cambiaron los registros del complemento gMSA a Eventos de Windows.  | 
|   `1.31-2025.08.18`   |   `1.31.11`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.31-2025.07.16`   |   `1.31.9`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.31-2025.06.13`   |   `1.31.9`   |   `1.7.27`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.27`.  | 
|   `1.31-2025.05.17`   |   `1.31.9`   |   `1.7.20`   |   `1.2.1`   |  | 
|   `1.31-2025.04.14`   |   `1.31.5`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2025.03.14`   |   `1.31.5`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2025.02.15`   |   `1.31.5`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2025.01.15`   |   `1.31.4`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2025.01.01`   |   `1.31.4`   |   `1.7.20`   |   `1.1.3`   |  Incluye parches para `CVE-2024-9042`.  | 
|   `1.31-2024.12.13`   |   `1.31.3`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2024.11.12`   |   `1.31.1`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2024.10.08`   |   `1.31.1`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2024.10.01`   |   `1.31.1`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2024.09.10`   |   `1.31.0`   |   `1.7.20`   |   `1.1.3`   |  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.30-2026.02.13`   |   `1.30.14`   |   `1.7.30`   |   `1.2.1`   |  | 
|   `1.30-2026.01.22`   |   `1.30.14`   |   `1.7.30`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.30`.  | 
|   `1.30-2025.12.15`   |   `1.30.14`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.30-2025.11.21`   |   `1.30.14`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.30-2025.10.18`   |   `1.30.14`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.30-2025.09.13`   |   `1.30.14`   |   `1.7.28`   |   `1.2.1`   |  Se cambiaron los registros del complemento gMSA a Eventos de Windows.  | 
|   `1.30-2025.08.18`   |   `1.30.14`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.30-2025.07.16`   |   `1.30.13`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.30-2025.06.13`   |   `1.30.13`   |   `1.7.27`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.27`.  | 
|   `1.30-2025.05.17`   |   `1.30.13`   |   `1.7.20`   |   `1.2.1`   |  | 
|   `1.30-2025.04.14`   |   `1.30.9`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.30-2025.03.14`   |   `1.30.9`   |   `1.7.20`   |   `1.1.3`   |  Se actualizó `contianerd` a `1.7.20`.  | 
|   `1.30-2025.02.15`   |   `1.30.9`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2025.01.15`   |   `1.30.8`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2025.01.01`   |   `1.30.8`   |   `1.7.14`   |   `1.1.3`   |  Incluye parches para `CVE-2024-9042`.  | 
|   `1.30-2024.12.11`   |   `1.30.7`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2024.11.12`   |   `1.30.4`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2024.10.08`   |   `1.30.4`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2024.09.10`   |   `1.30.2`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2024.08.13`   |   `1.30.2`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2024.07.10`   |   `1.30.2`   |   `1.7.14`   |   `1.1.2`   |  Incluye parches para `CVE-2024-5321`.  | 
|   `1.30-2024.06.17`   |   `1.30.0`   |   `1.7.14`   |   `1.1.2`   |  Se actualizó `containerd` a `1.7.14`.  | 
|   `1.30-2024.05.15`   |   `1.30.0`   |   `1.6.28`   |   `1.1.2`   |  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.29-2026.02.13`   |   `1.29.15`   |   `1.7.30`   |   `1.2.1`   |  | 
|   `1.29-2026.01.22`   |   `1.29.15`   |   `1.7.30`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.30`.  | 
|   `1.29-2025.12.15`   |   `1.29.15`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.29-2025.11.14`   |   `1.29.15`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.29-2025.10.18`   |   `1.29.15`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.29-2025.09.13`   |   `1.29.15`   |   `1.7.28`   |   `1.2.1`   |  Se cambiaron los registros del complemento gMSA a Eventos de Windows.  | 
|   `1.29-2025.08.18`   |   `1.29.15`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.29-2025.07.16`   |   `1.29.15`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.29-2025.06.13`   |   `1.29.15`   |   `1.7.27`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.27`.  | 
|   `1.29-2025.05.17`   |   `1.29.15`   |   `1.7.20`   |   `1.2.1`   |  | 
|   `1.29-2025.04.14`   |   `1.29.13`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.29-2025.03.14`   |   `1.29.13`   |   `1.7.20`   |   `1.1.3`   |  Se actualizó `containerd` a `1.7.20`.  | 
|   `1.29-2025.02.15`   |   `1.29.13`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2025.01.15`   |   `1.29.12`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2025.01.01`   |   `1.29.12`   |   `1.7.14`   |   `1.1.3`   |  Incluye parches para `CVE-2024-9042`.  | 
|   `1.29-2024.12.11`   |   `1.29.10`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2024.11.12`   |   `1.29.8`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2024.10.08`   |   `1.29.8`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2024.09.10`   |   `1.29.6`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2024.08.13`   |   `1.29.6`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2024.07.10`   |   `1.29.6`   |   `1.7.11`   |   `1.1.2`   |  Incluye parches para `CVE-2024-5321`.  | 
|   `1.29-2024.06.17`   |   `1.29.3`   |   `1.7.11`   |   `1.1.2`   |  | 
|   `1.29-2024.05.15`   |   `1.29.3`   |   `1.7.11`   |   `1.1.2`   |  Se actualizó `containerd` a `1.7.11`. Se actualizó `kubelet` a `1.29.3`.  | 
|   `1.29-2024.04.09`   |   `1.29.0`   |   `1.6.28`   |   `1.1.2`   |  Se actualizó `containerd` a `1.6.28`. Se volvieron a crear CNI y `csi-proxy` mediante `golang 1.22.1`.  | 
|   `1.29-2024.03.12`   |   `1.29.0`   |   `1.6.25`   |   `1.1.2`   |  | 
|   `1.29-2024.02.13`   |   `1.29.0`   |   `1.6.25`   |   `1.1.2`   |  | 
|   `1.29-2024.02.06`   |   `1.29.0`   |   `1.6.25`   |   `1.1.2`   |  Se corrigió el error de que la imagen de pausa se borraba incorrectamente durante el proceso de recogida de basura de `kubelet`.  | 
|   `1.29-2024.01.09`   |   `1.29.0`   |   `1.6.18`   |   `1.1.2`   |  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.28-2025.11.14`   |   `1.28.15`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.28-2025.10.18`   |   `1.28.15`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.28-2025.09.13`   |   `1.28.15`   |   `1.7.28`   |   `1.2.1`   |  Se cambiaron los registros del complemento gMSA a Eventos de Windows.  | 
|   `1.28-2025.08.18`   |   `1.28.15`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.28-2025.07.16`   |   `1.28.15`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.28-2025.06.13`   |   `1.28.15`   |   `1.7.27`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.27`.  | 
|   `1.28-2025.05.17`   |   `1.28.15`   |   `1.7.20`   |   `1.2.1`   |  | 
|   `1.28-2025.04.14`   |   `1.28.15`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.28-2025.03.14`   |   `1.28.15`   |   `1.7.20`   |   `1.1.3`   |  Se actualizó `containerd` a `1.7.20`.  | 
|   `1.28-2025.02.15`   |   `1.28.15`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2025.01.15`   |   `1.28.15`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2025.01.01`   |   `1.28.15`   |   `1.7.14`   |   `1.1.3`   |  Incluye parches para `CVE-2024-9042`.  | 
|   `1.28-2024.12.11`   |   `1.28.15`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2024.11.12`   |   `1.28.13`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2024.10.08`   |   `1.28.13`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2024.09.10`   |   `1.28.11`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2024.08.13`   |   `1.28.11`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2024.07.10`   |   `1.28.11`   |   `1.7.11`   |   `1.1.2`   |  Incluye parches para `CVE-2024-5321`.  | 
|   `1.28-2024.06.17`   |   `1.28.8`   |   `1.7.11`   |   `1.1.2`   |  Se actualizó `containerd` a `1.7.11`.  | 
|   `1.28-2024.05.14`   |   `1.28.8`   |   `1.6.28`   |   `1.1.2`   |  Se actualizó `containerd` a `1.6.28`. Se actualizó `kubelet` a `1.28.8`.  | 
|   `1.28-2024.04.09`   |   `1.28.5`   |   `1.6.25`   |   `1.1.2`   |  Se actualizó `containerd` a `1.6.25`. Se volvieron a crear CNI y `csi-proxy` mediante `golang 1.22.1`.  | 
|   `1.28-2024.03.12`   |   `1.28.5`   |   `1.6.18`   |   `1.1.2`   |  | 
|   `1.28-2024.02.13`   |   `1.28.5`   |   `1.6.18`   |   `1.1.2`   |  | 
|   `1.28-2024.01.09`   |   `1.28.5`   |   `1.6.18`   |   `1.1.2`   |  | 
|   `1.28-2023.12.12`   |   `1.28.3`   |   `1.6.18`   |   `1.1.2`   |  | 
|   `1.28-2023.11.14`   |   `1.28.3`   |   `1.6.18`   |   `1.1.2`   |  Incluye parches para `CVE-2023-5528`.  | 
|   `1.28-2023.10.19`   |   `1.28.2`   |   `1.6.18`   |   `1.1.2`   |  Se actualizó `containerd` a `1.6.18`. Se agregaron nuevas [variables de entorno de script de arranque](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters) (`SERVICE_IPV4_CIDR` y `EXCLUDED_SNAT_CIDRS`).  | 
|   `1.28-2023-09.27`   |   `1.28.2`   |   `1.6.6`   |   `1.1.2`   |  Se ha corregido un [aviso de seguridad](https://github.com/advisories/GHSA-6xv5-86q9-7xr8) en `kubelet`.  | 
|   `1.28-2023.09.12`   |   `1.28.1`   |   `1.6.6`   |   `1.1.2`   |  | 

## AMI de Windows Server 2019 Core optimizada para Amazon EKS
<a name="eks-ami-versions-windows-2019-core"></a>

En las siguientes tablas, se enumeran las versiones actuales y anteriores de la AMI de Windows Server 2019 Core optimizada para Amazon EKS.

**Example**  


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.35-2026.02.16`   |   `1.35.0`   |   `2.1.6`   |   `1.2.1`   |  | 
|   `1.35-2026-01-22`   |   `1.35.0`   |   `2.1.6`   |   `1.2.1`   |  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.34-2026.02.13`   |   `1.34.3`   |   `2.1.6`   |   `1.2.1`   |  | 
|   `1.34-2026.01.22`   |   `1.34.2`   |   `2.1.6`   |   `1.2.1`   |  Se actualizó `containerd` a `2.1.6`.  | 
|   `1.34-2025.12.15`   |   `1.34.2`   |   `2.1.4`   |   `1.2.1`   |  | 
|   `1.34-2025.11.14`   |   `1.34.1`   |   `2.1.4`   |   `1.2.1`   |  | 
|   `1.34-2025.10.18`   |   `1.34.1`   |   `2.1.4`   |   `1.2.1`   |  | 
|   `1.34-2025.09.13`   |   `1.34.0`   |   `2.1.4`   |   `1.2.1`   |  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.33-2026.02.13`   |   `1.33.7`   |   `1.7.30`   |   `1.2.1`   |  | 
|   `1.33-2026.01.22`   |   `1.33.5`   |   `1.7.30`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.30`.  | 
|   `1.33-2025.12.15`   |   `1.33.5`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.33-2025.11.14`   |   `1.33.5`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.33-2025.10.18`   |   `1.33.5`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.33-2025.09.13`   |   `1.33.4`   |   `1.7.28`   |   `1.2.1`   |  Se cambiaron los registros del complemento gMSA a Eventos de Windows.  | 
|   `1.33-2025.08.18`   |   `1.33.3`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.33-2025.07.16`   |   `1.33.1`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.33-2025.06.13`   |   `1.33.1`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.33-2025.05.17`   |   `1.33.1`   |   `1.7.27`   |   `1.2.1`   |  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.32-2026.02.13`   |   `1.32.11`   |   `1.7.30`   |   `1.2.1`   |  | 
|   `1.32-2026.01.22`   |   `1.32.9`   |   `1.7.30`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.30`.  | 
|   `1.32-2025.12.15`   |   `1.32.9`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.32-2025.11.14`   |   `1.32.9`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.32-2025.10.18`   |   `1.32.9`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.32-2025.09.13`   |   `1.32.8`   |   `1.7.28`   |   `1.2.1`   |  Se cambiaron los registros del complemento gMSA a Eventos de Windows.  | 
|   `1.32-2025.08.18`   |   `1.32.7`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.32-2025.07.16`   |   `1.32.5`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.32-2025.06.13`   |   `1.32.5`   |   `1.7.27`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.27`.  | 
|   `1.32-2025.05.17`   |   `1.32.5`   |   `1.7.20`   |   `1.2.1`   |  | 
|   `1.32-2025.04.14`   |   `1.32.1`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.32-2025.03.14`   |   `1.32.1`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.32-2025.02.18`   |   `1.32.1`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.32-2025.01.15`   |   `1.32.4`   |   `1.7.20`   |   `1.1.3`   |  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.31-2026.02.13`   |   `1.31.14`   |   `1.7.30`   |   `1.2.1`   |  | 
|   `1.31-2026.01.22`   |   `1.31.13`   |   `1.7.30`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.30`.  | 
|   `1.31-2025.12.15`   |   `1.31.13`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.31-2025.11.14`   |   `1.31.13`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.31-2025.10.18`   |   `1.31.13`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.31-2025.09.13`   |   `1.31.12`   |   `1.7.28`   |   `1.2.1`   |  Se cambiaron los registros del complemento gMSA a Eventos de Windows.  | 
|   `1.31-2025.08.18`   |   `1.31.11`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.31-2025.07.16`   |   `1.31.9`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.31-2025.06.13`   |   `1.31.9`   |   `1.7.27`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.27`.  | 
|   `1.31-2025.05.17`   |   `1.31.9`   |   `1.7.20`   |   `1.2.1`   |  | 
|   `1.31-2025.04.14`   |   `1.31.5`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2025.03.14`   |   `1.31.5`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2025.02.15`   |   `1.31.5`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2025.01.15`   |   `1.31.4`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2025.01.01`   |   `1.31.4`   |   `1.7.20`   |   `1.1.3`   |  Incluye parches para `CVE-2024-9042`.  | 
|   `1.31-2024.12.13`   |   `1.31.3`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2024.11.12`   |   `1.31.1`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2024.10.08`   |   `1.31.1`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2024.10.01`   |   `1.31.1`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2024.09.10`   |   `1.31.0`   |   `1.7.20`   |   `1.1.3`   |  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.30-2026.02.13`   |   `1.30.14`   |   `1.7.30`   |   `1.2.1`   |  | 
|   `1.30-2026.01.22`   |   `1.30.14`   |   `1.7.30`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.30`.  | 
|   `1.30-2025.12.15`   |   `1.30.14`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.30-2025.11.21`   |   `1.30.14`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.30-2025.10.18`   |   `1.30.14`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.30-2025.09.13`   |   `1.30.14`   |   `1.7.28`   |   `1.2.1`   |  Se cambiaron los registros del complemento gMSA a Eventos de Windows.  | 
|   `1.30-2025.08.18`   |   `1.30.14`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.30-2025.07.16`   |   `1.30.13`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.30-2025.06.13`   |   `1.30.13`   |   `1.7.27`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.27`.  | 
|   `1.30-2025.05.17`   |   `1.30.13`   |   `1.7.20`   |   `1.2.1`   |  | 
|   `1.30-2025.04.14`   |   `1.30.9`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.30-2025.03.14`   |   `1.30.9`   |   `1.7.20`   |   `1.1.3`   |  Se actualizó `containerd` a `1.7.20`.  | 
|   `1.30-2025-02-15`   |   `1.30.9`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2025.01.15`   |   `1.30.8`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2025.01.01`   |   `1.30.8`   |   `1.7.14`   |   `1.1.3`   |  Incluye parches para `CVE-2024-9042`.  | 
|   `1.30-2024.12.11`   |   `1.30.7`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2024.11.12`   |   `1.30.4`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2024.10.08`   |   `1.30.4`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2024.09.10`   |   `1.30.2`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2024.08.13`   |   `1.30.2`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2024.07.10`   |   `1.30.2`   |   `1.7.14`   |   `1.1.2`   |  Incluye parches para `CVE-2024-5321`.  | 
|   `1.30-2024.06.17`   |   `1.30.0`   |   `1.7.14`   |   `1.1.2`   |  Se actualizó `containerd` a `1.7.14`.  | 
|   `1.30-2024.05.15`   |   `1.30.0`   |   `1.6.28`   |   `1.1.2`   |  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.29-2026.02.13`   |   `1.29.15`   |   `1.7.30`   |   `1.2.1`   |  | 
|   `1.29-2026.01.22`   |   `1.29.15`   |   `1.7.30`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.30`.  | 
|   `1.29-2025.12.15`   |   `1.29.15`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.29-2025.11.14`   |   `1.29.15`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.29-2025.10.18`   |   `1.29.15`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.29-2025.09.13`   |   `1.29.15`   |   `1.7.28`   |   `1.2.1`   |  Se cambiaron los registros del complemento gMSA a Eventos de Windows.  | 
|   `1.29-2025.08.18`   |   `1.29.15`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.29-2025.07.16`   |   `1.29.15`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.29-2025.06.13`   |   `1.29.15`   |   `1.7.27`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.27`.  | 
|   `1.29-2025.05.17`   |   `1.29.15`   |   `1.7.20`   |   `1.2.1`   |  | 
|   `1.29-2025.04.14`   |   `1.29.13`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.29-2025.03.14`   |   `1.29.13`   |   `1.7.20`   |   `1.1.3`   |  Se actualizó `containerd` a `1.7.20`.  | 
|   `1.29-2025.02.15`   |   `1.29.13`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2025.01.15`   |   `1.29.12`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2025.01.01`   |   `1.29.12`   |   `1.7.14`   |   `1.1.3`   |  Incluye parches para `CVE-2024-9042`.  | 
|   `1.29-2024.12.11`   |   `1.29.10`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2024.11.12`   |   `1.29.8`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2024.10.08`   |   `1.29.8`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2024.09.10`   |   `1.29.6`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2024.08.13`   |   `1.29.6`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2024.07.10`   |   `1.29.6`   |   `1.7.11`   |   `1.1.2`   |  Incluye parches para `CVE-2024-5321`.  | 
|   `1.29-2024.06.17`   |   `1.29.3`   |   `1.7.11`   |   `1.1.2`   |  | 
|   `1.29-2024.05.15`   |   `1.29.3`   |   `1.7.11`   |   `1.1.2`   |  Se actualizó `containerd` a `1.7.11`. Se actualizó `kubelet` a `1.29.3`.  | 
|   `1.29-2024.04.09`   |   `1.29.0`   |   `1.6.28`   |   `1.1.2`   |  Se actualizó `containerd` a `1.6.28`. Se volvieron a crear CNI y `csi-proxy` mediante `golang 1.22.1`.  | 
|   `1.29-2024.03.13`   |   `1.29.0`   |   `1.6.25`   |   `1.1.2`   |  | 
|   `1.29-2024.02.13`   |   `1.29.0`   |   `1.6.25`   |   `1.1.2`   |  | 
|   `1.29-2024.02.06`   |   `1.29.0`   |   `1.6.25`   |   `1.1.2`   |  Se corrigió el error de que la imagen de pausa se borraba incorrectamente durante el proceso de recogida de basura de `kubelet`.  | 
|   `1.29-2024.01.09`   |   `1.29.0`   |   `1.6.18`   |   `1.1.2`   |  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.28-2025.11.14`   |   `1.28.15`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.28-2025.10.18`   |   `1.28.15`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.28-2025.09.13`   |   `1.28.15`   |   `1.7.28`   |   `1.2.1`   |  Se cambiaron los registros del complemento gMSA a Eventos de Windows.  | 
|   `1.28-2025.08.18`   |   `1.28.15`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.28-2025.07.16`   |   `1.28.15`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.28-2025.06.13`   |   `1.28.15`   |   `1.7.20`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.27`.  | 
|   `1.28-2025.05.17`   |   `1.28.15`   |   `1.7.20`   |   `1.2.1`   |  | 
|   `1.28-2025.04.14`   |   `1.28.15`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.28-2025.03.14`   |   `1.28.15`   |   `1.7.20`   |   `1.1.3`   |  Se actualizó `containerd` a `1.7.20`.  | 
|   `1.28-2025.02.15`   |   `1.28.15`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2025-01-15`   |   `1.28.15`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2025-01-01`   |   `1.28.15`   |   `1.7.14`   |   `1.1.3`   |  Incluye parches para `CVE-2024-9042`.  | 
|   `1.28-2024.12.11`   |   `1.28.15`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2024.11.12`   |   `1.28.13`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2024.10.08`   |   `1.28.13`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2024.09.10`   |   `1.28.11`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2024.08.13`   |   `1.28.11`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2024.07.10`   |   `1.28.11`   |   `1.7.11`   |   `1.1.2`   |  Incluye parches para `CVE-2024-5321`.  | 
|   `1.28-2024.06.17`   |   `1.28.8`   |   `1.7.11`   |   `1.1.2`   |  Se actualizó `containerd` a `1.7.11`.  | 
|   `1.28-2024.05.14`   |   `1.28.8`   |   `1.6.28`   |   `1.1.2`   |  Se actualizó `containerd` a `1.6.28`. Se actualizó `kubelet` a `1.28.8`.  | 
|   `1.28-2024.04.09`   |   `1.28.5`   |   `1.6.25`   |   `1.1.2`   |  Se actualizó `containerd` a `1.6.25`. Se volvieron a crear CNI y `csi-proxy` mediante `golang 1.22.1`.  | 
|   `1.28-2024.03.13`   |   `1.28.5`   |   `1.6.18`   |   `1.1.2`   |  | 
|   `1.28-2024.02.13`   |   `1.28.5`   |   `1.6.18`   |   `1.1.2`   |  | 
|   `1.28-2024.01.09`   |   `1.28.5`   |   `1.6.18`   |   `1.1.2`   |  | 
|   `1.28-2023.12.12`   |   `1.28.3`   |   `1.6.18`   |   `1.1.2`   |  | 
|   `1.28-2023.11.14`   |   `1.28.3`   |   `1.6.18`   |   `1.1.2`   |  Incluye parches para `CVE-2023-5528`.  | 
|   `1.28-2023.10.19`   |   `1.28.2`   |   `1.6.18`   |   `1.1.2`   |  Se actualizó `containerd` a `1.6.18`. Se agregaron nuevas [variables de entorno de script de arranque](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters) (`SERVICE_IPV4_CIDR` y `EXCLUDED_SNAT_CIDRS`).  | 
|   `1.28-2023-09.27`   |   `1.28.2`   |   `1.6.6`   |   `1.1.2`   |  Se ha corregido un [aviso de seguridad](https://github.com/advisories/GHSA-6xv5-86q9-7xr8) en `kubelet`.  | 
|   `1.28-2023.09.12`   |   `1.28.1`   |   `1.6.6`   |   `1.1.2`   |  | 

## AMI de Windows Server 2019 Full optimizada para Amazon EKS
<a name="eks-ami-versions-windows-2019-full"></a>

En las siguientes tablas, se enumeran las versiones actuales y anteriores de la AMI de Windows Server 2019 Full optimizada para Amazon EKS.

**Example**  


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.35-2026.02.16`   |   `1.35.0`   |   `2.1.6`   |   `1.2.1`   |  | 
|   `1.35-2026-01-22`   |   `1.35.0`   |   `2.1.6`   |   `1.2.1`   |  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.34-2026.02.13`   |   `1.34.3`   |   `2.1.6`   |   `1.2.1`   |  | 
|   `1.34-2026.01.22`   |   `1.34.2`   |   `2.1.6`   |   `1.2.1`   |  Se actualizó `containerd` a `2.1.6`.  | 
|   `1.34-2025.12.15`   |   `1.34.2`   |   `2.1.4`   |   `1.2.1`   |  | 
|   `1.34-2025.11.14`   |   `1.34.1`   |   `2.1.4`   |   `1.2.1`   |  | 
|   `1.34-2025.10.18`   |   `1.34.1`   |   `2.1.4`   |   `1.2.1`   |  | 
|   `1.34-2025.09.13`   |   `1.34.0`   |   `2.1.4`   |   `1.2.1`   |  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.33-2026.02.13`   |   `1.33.7`   |   `1.7.30`   |   `1.2.1`   |  | 
|   `1.33-2026.01.22`   |   `1.33.5`   |   `1.7.30`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.30`.  | 
|   `1.33-2025.12.15`   |   `1.33.5`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.33-2025.11.14`   |   `1.33.5`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.33-2025.10.18`   |   `1.33.5`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.33-2025.09.13`   |   `1.33.4`   |   `1.7.28`   |   `1.2.1`   |  Se cambiaron los registros del complemento gMSA a Eventos de Windows.  | 
|   `1.33-2025.08.18`   |   `1.33.3`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.33-2025.07.16`   |   `1.33.1`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.33-2025.06.13`   |   `1.33.1`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.33-2025.05.17`   |   `1.33.1`   |   `1.7.27`   |   `1.2.1`   |  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.32-2026.02.13`   |   `1.32.11`   |   `1.7.30`   |   `1.2.1`   |  | 
|   `1.32-2026.01.22`   |   `1.32.9`   |   `1.7.30`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.30`.  | 
|   `1.32-2025.12.15`   |   `1.32.9`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.32-2025.11.14`   |   `1.32.9`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.32-2025.10.18`   |   `1.32.9`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.32-2025.09.13`   |   `1.32.8`   |   `1.7.28`   |   `1.2.1`   |  Se cambiaron los registros del complemento gMSA a Eventos de Windows.  | 
|   `1.32-2025.08.18`   |   `1.32.7`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.32-2025.07.16`   |   `1.32.5`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.32-2025.06.13`   |   `1.32.5`   |   `1.7.27`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.27`.  | 
|   `1.32-2025.05.17`   |   `1.32.5`   |   `1.7.20`   |   `1.2.1`   |  | 
|   `1.32-2025.04.14`   |   `1.32.1`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.32-2025.03.14`   |   `1.32.1`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.32-2025.02.18`   |   `1.32.1`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.32-2025.01.15`   |   `1.32.0`   |   `1.7.20`   |   `1.1.3`   |  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.31-2026.02.13`   |   `1.31.14`   |   `1.7.30`   |   `1.2.1`   |  | 
|   `1.31-2026.01.22`   |   `1.31.13`   |   `1.7.30`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.30`.  | 
|   `1.31-2025.12.15`   |   `1.31.13`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.31-2025.11.14`   |   `1.31.13`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.31-2025.10.18`   |   `1.31.13`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.31-2025.09.13`   |   `1.31.12`   |   `1.7.28`   |   `1.2.1`   |  Se cambiaron los registros del complemento gMSA a Eventos de Windows.  | 
|   `1.31-2025.08.18`   |   `1.31.11`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.31-2025.07.16`   |   `1.31.9`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.31-2025.06.13`   |   `1.31.9`   |   `1.7.27`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.27`.  | 
|   `1.31-2025.05.17`   |   `1.31.9`   |   `1.7.20`   |   `1.2.1`   |  | 
|   `1.31-2025.04.14`   |   `1.31.5`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2025.03.14`   |   `1.31.5`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2025.02.15`   |   `1.31.5`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2025.01.15`   |   `1.31.4`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2025.01.01`   |   `1.31.4`   |   `1.7.20`   |   `1.1.3`   |  Incluye parches para `CVE-2024-9042`.  | 
|   `1.31-2024.12.13`   |   `1.31.3`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2024.11.12`   |   `1.31.1`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2024.10.08`   |   `1.31.1`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2024.10.01`   |   `1.31.1`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.31-2024.09.10`   |   `1.31.0`   |   `1.7.20`   |   `1.1.3`   |  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.30-2026.02.13`   |   `1.30.14`   |   `1.7.30`   |   `1.2.1`   |  | 
|   `1.30-2026.01.22`   |   `1.30.14`   |   `1.7.30`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.30`.  | 
|   `1.30-2025.12.15`   |   `1.30.14`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.30-2025.11.21`   |   `1.30.14`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.30-2025.10.18`   |   `1.30.14`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.30-2025.09.13`   |   `1.30.14`   |   `1.7.28`   |   `1.2.1`   |  Se cambiaron los registros del complemento gMSA a Eventos de Windows.  | 
|   `1.30-2025.08.18`   |   `1.30.14`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.30-2025.07.16`   |   `1.30.13`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.30-2025.06.13`   |   `1.30.13`   |   `1.7.27`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.27`.  | 
|   `1.30-2025.05.17`   |   `1.30.13`   |   `1.7.20`   |   `1.2.1`   |  | 
|   `1.30-2025.04.14`   |   `1.30.9`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.30-2025.03.14`   |   `1.30.9`   |   `1.7.20`   |   `1.1.3`   |  Se actualizó `containerd` a `1.7.20`.  | 
|   `1.30-2025.02.15`   |   `1.30.9`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2025.01.15`   |   `1.30.8`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2025.01.01`   |   `1.30.8`   |   `1.7.14`   |   `1.1.3`   |  Incluye parches para `CVE-2024-9042`.  | 
|   `1.30-2024.12.11`   |   `1.30.7`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2024.11.12`   |   `1.30.4`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2024.10.08`   |   `1.30.4`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2024.09.10`   |   `1.30.2`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2024.08.13`   |   `1.30.2`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.30-2024.07.10`   |   `1.30.2`   |   `1.7.14`   |   `1.1.2`   |  Incluye parches para `CVE-2024-5321`.  | 
|   `1.30-2024.06.17`   |   `1.30.0`   |   `1.7.14`   |   `1.1.2`   |  Se actualizó `containerd` a `1.7.14`.  | 
|   `1.30-2024.05.15`   |   `1.30.0`   |   `1.6.28`   |   `1.1.2`   |  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.29-2026.02.13`   |   `1.29.15`   |   `1.7.30`   |   `1.2.1`   |  | 
|   `1.29-2026.01.22`   |   `1.29.15`   |   `1.7.30`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.30`.  | 
|   `1.29-2025.12.15`   |   `1.29.15`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.29-2025.11.14`   |   `1.29.15`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.29-2025.10.18`   |   `1.29.15`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.29-2025.09.13`   |   `1.29.15`   |   `1.7.28`   |   `1.2.1`   |  Se cambiaron los registros del complemento gMSA a Eventos de Windows.  | 
|   `1.29-2025.08.18`   |   `1.29.15`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.29-2025.07.16`   |   `1.29.15`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.29-2025.06.13`   |   `1.29.15`   |   `1.7.27`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.27`.  | 
|   `1.29-2025.05.17`   |   `1.29.15`   |   `1.7.20`   |   `1.2.1`   |  | 
|   `1.29-2025.04.14`   |   `1.29.13`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.29-2025.03.14`   |   `1.29.13`   |   `1.7.20`   |   `1.1.3`   |  Se actualizó `containerd` a `1.7.20`.  | 
|   `1.29-2025.02.15`   |   `1.29.13`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2025.01.15`   |   `1.29.12`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2025.01.01`   |   `1.29.12`   |   `1.7.14`   |   `1.1.3`   |  Incluye parches para `CVE-2024-9042`.  | 
|   `1.29-2024.12.11`   |   `1.29.10`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2024.11.12`   |   `1.29.8`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2024.10.08`   |   `1.29.8`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2024.09.10`   |   `1.29.6`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2024.08.13`   |   `1.29.6`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.29-2024.07.10`   |   `1.29.6`   |   `1.7.11`   |   `1.1.2`   |  Incluye parches para `CVE-2024-5321`.  | 
|   `1.29-2024.06.17`   |   `1.29.3`   |   `1.7.11`   |   `1.1.2`   |  | 
|   `1.29-2024.05.15`   |   `1.29.3`   |   `1.7.11`   |   `1.1.2`   |  Se actualizó `containerd` a `1.7.11`. Se actualizó `kubelet` a `1.29.3`.  | 
|   `1.29-2024.04.09`   |   `1.29.0`   |   `1.6.28`   |   `1.1.2`   |  Se actualizó `containerd` a `1.6.28`. Se volvieron a crear CNI y `csi-proxy` mediante `golang 1.22.1`.  | 
|   `1.29-2024.03.13`   |   `1.29.0`   |   `1.6.25`   |   `1.1.2`   |  | 
|   `1.29-2024.02.13`   |   `1.29.0`   |   `1.6.25`   |   `1.1.2`   |  | 
|   `1.29-2024.02.06`   |   `1.29.0`   |   `1.6.25`   |   `1.1.2`   |  Se corrigió el error de que la imagen de pausa se borraba incorrectamente durante el proceso de recogida de basura de `kubelet`.  | 
|   `1.29-2024.01.09`   |   `1.29.0`   |   `1.6.18`   |   `1.1.2`   |  | 


| Versión de AMI | versión de kubelet | versión de containerd | versión de csi-proxy | Notas de la versión | 
| --- | --- | --- | --- | --- | 
|   `1.28-2025.11.14`   |   `1.28.15`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.28-2025.10.18`   |   `1.28.15`   |   `1.7.28`   |   `1.2.1`   |  | 
|   `1.28-2025.09.13`   |   `1.28.15`   |   `1.7.28`   |   `1.2.1`   |  Se cambiaron los registros del complemento gMSA a Eventos de Windows.  | 
|   `1.28-2025.08.18`   |   `1.28.15`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.28-2025.07.16`   |   `1.28.15`   |   `1.7.27`   |   `1.2.1`   |  | 
|   `1.28-2025.06.13`   |   `1.28.15`   |   `1.7.27`   |   `1.2.1`   |  Se actualizó `containerd` a `1.7.27`.  | 
|   `1.28-2025.05.17`   |   `1.28.15`   |   `1.7.20`   |   `1.2.1`   |  | 
|   `1.28-2025.04.14`   |   `1.28.15`   |   `1.7.20`   |   `1.1.3`   |  | 
|   `1.28-2025.03.14`   |   `1.28.15`   |   `1.7.20`   |   `1.1.3`   |  Se actualizó `containerd` a `1.7.20`.  | 
|   `1.28-2025.02.15`   |   `1.28.15`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2025-01-15`   |   `1.28.15`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2025-01-01`   |   `1.28.15`   |   `1.7.14`   |   `1.1.3`   |  Incluye parches para `CVE-2024-9042`.  | 
|   `1.28-2024.12.11`   |   `1.28.15`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2024.11.12`   |   `1.28.13`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2024.10.08`   |   `1.28.13`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2024.09.10`   |   `1.28.11`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2024.08.13`   |   `1.28.11`   |   `1.7.14`   |   `1.1.3`   |  | 
|   `1.28-2024.07.10`   |   `1.28.11`   |   `1.7.11`   |   `1.1.2`   |  Incluye parches para `CVE-2024-5321`.  | 
|   `1.28-2024.06.17`   |   `1.28.8`   |   `1.7.11`   |   `1.1.2`   |  Se actualizó `containerd` a `1.7.11`.  | 
|   `1.28-2024.05.14`   |   `1.28.8`   |   `1.6.28`   |   `1.1.2`   |  Se actualizó `containerd` a `1.6.28`. Se actualizó `kubelet` a `1.28.8`.  | 
|   `1.28-2024.04.09`   |   `1.28.5`   |   `1.6.25`   |   `1.1.2`   |  Se actualizó `containerd` a `1.6.25`. Se volvieron a crear CNI y `csi-proxy` mediante `golang 1.22.1`.  | 
|   `1.28-2024.03.13`   |   `1.28.5`   |   `1.6.18`   |   `1.1.2`   |  | 
|   `1.28-2024.02.13`   |   `1.28.5`   |   `1.6.18`   |   `1.1.2`   |  | 
|   `1.28-2024.01.09`   |   `1.28.5`   |   `1.6.18`   |   `1.1.2`   |  | 
|   `1.28-2023.12.12`   |   `1.28.3`   |   `1.6.18`   |   `1.1.2`   |  | 
|   `1.28-2023.11.14`   |   `1.28.3`   |   `1.6.18`   |   `1.1.2`   |  Incluye parches para `CVE-2023-5528`.  | 
|   `1.28-2023.10.19`   |   `1.28.2`   |   `1.6.18`   |   `1.1.2`   |  Se actualizó `containerd` a `1.6.18`. Se agregaron nuevas [variables de entorno de script de arranque](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters) (`SERVICE_IPV4_CIDR` y `EXCLUDED_SNAT_CIDRS`).  | 
|   `1.28-2023-09.27`   |   `1.28.2`   |   `1.6.6`   |   `1.1.2`   |  Se ha corregido un [aviso de seguridad](https://github.com/advisories/GHSA-6xv5-86q9-7xr8) en `kubelet`.  | 
|   `1.28-2023.09.12`   |   `1.28.1`   |   `1.6.6`   |   `1.1.2`   |  | 

# Recuperación de los ID de AMI de Microsoft Windows recomendados
<a name="retrieve-windows-ami-id"></a>

Al implementar nodos, puede especificar un ID de una imagen de máquina de Amazon (AMI) optimizada para Amazon EKS previamente creada. Para recuperar un ID de AMI que se ajuste a la configuración deseada, consulte la API del almacén de parámetros de AWS Systems Manager. Al utilizar esta API, se elimina la necesidad de buscar manualmente los ID de AMI optimizados para Amazon EKS. Para obtener más información, consulte [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html). La [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que utiliza debe tener el permiso `ssm:GetParameter` de IAM para recuperar los metadatos de la AMI optimizada para Amazon EKS.

Puede recuperar el ID de imagen de la última AMI de Windows optimizada para Amazon EKS recomendada con el siguiente comando, que usa el parámetro secundario `image_id`. Realice las siguientes modificaciones en el comando según sea necesario y, a continuación, ejecute el comando modificado:
+ Reemplace *release* por una de las siguientes opciones:
  + Use *2025* para Windows Server 2025.
  + Use *2022* para Windows Server 2022.
  + Use *2019* para Windows Server 2019.
+ Reemplace *installation-option* por una de las siguientes opciones. Para obtener más información, consulte [¿Qué es la opción de instalación Server Core en Windows Server?](https://learn.microsoft.com/en-us/windows-server/administration/server-core/what-is-server-core)
  + Use *Core* para una instalación mínima con una superficie expuesta a ataques más pequeña.
  + Use *Full* para incluir la experiencia de escritorio de Windows.
+ Reemplace *kubernetes-version* por cualquier [versión de la plataforma](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html) compatible.
+ Sustituya *region-code* por una [región de AWS compatible con Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) para la que desea el ID de AMI.

```
aws ssm get-parameter --name /aws/service/ami-windows-latest/Windows_Server-release-English-installation-option-EKS_Optimized-kubernetes-version/image_id \
    --region region-code --query "Parameter.Value" --output text
```

A continuación, se muestra un comando de ejemplo después de reemplazar los marcadores de posición.

```
aws ssm get-parameter --name /aws/service/ami-windows-latest/Windows_Server-2022-English-Core-EKS_Optimized-k8s-n-2/image_id \
    --region us-west-2 --query "Parameter.Value" --output text
```

Un ejemplo de salida sería el siguiente.

```
ami-1234567890abcdef0
```

# Creación de una AMI de Windows personalizada con el Generador de imágenes
<a name="eks-custom-ami-windows"></a>

Puede utilizar el Generador de imágenes de EC2 para crear las AMI de Windows personalizadas optimizadas para Amazon EKS con una de las siguientes opciones:
+  [Uso de una AMI de Windows optimizada para Amazon EKS como base](#custom-windows-ami-as-base) 
+  [Uso del componente de compilación administrado por Amazon](#custom-windows-ami-build-component) 

Con ambos métodos, debe crear su propia receta de Image Builder. Para obtener más información, consulte [Crear una nueva versión de una receta de imagen](https://docs.aws.amazon.com/imagebuilder/latest/userguide/create-image-recipes.html) en la Guía del usuario de Image Builder.

**importante**  
Los siguientes componentes **administrados por Amazon** para `eks` incluyen parches para `CVE-2024-5321`.  
 `1.28.2` y posteriores
 `1.29.2` y posteriores
 `1.30.1` y posteriores
Todas las versiones para Kubernetes 1.31 y posteriores

## Uso de una AMI de Windows optimizada para Amazon EKS como base
<a name="custom-windows-ami-as-base"></a>

Esta opción es la forma recomendada de crear las AMI de Windows personalizadas. Las AMI de Windows optimizadas para Amazon EKS que ofrecemos se actualizan con más frecuencia que el componente de compilación administrado por Amazon.

1. Inicie una receta nueva de Image Builder.

   1. Abra la consola del Generador de imágenes de EC2 en https://console.aws.amazon.com/imagebuilder.

   1. En el panel de navegación izquierdo, elija **Recetas de imágenes**.

   1. Seleccione **Crear receta de imagen**.

1. En la sección **Detalles de la receta**, ingrese un **nombre** y una **versión**.

1. Especifique el ID de la AMI de Windows optimizada para Amazon EKS en la sección **Imagen base**.

   1. Elija **Escribir el ID personalizado de la AMI**.

   1. Recupere el ID de la AMI de la versión del sistema operativo de Windows que necesita. Para obtener más información, consulte [Recuperación de los ID de AMI de Microsoft Windows recomendados](retrieve-windows-ami-id.md).

   1. Ingrese el **ID de la AMI** personalizada. Si no encuentra el ID de la AMI, asegúrese de que la región de AWS del ID de la AMI coincida con la región de AWS que se muestra en la esquina superior derecha de la consola.

1. (Opcional) Para obtener las actualizaciones de seguridad más recientes, agrega el componente `update-windows` en la sección **Componentes de compilación: **.

   1. En la lista desplegable situada a la derecha del cuadro de búsqueda **Buscar componentes por nombre**, seleccione **Administrado por Amazon**.

   1. En el cuadro de búsqueda **Buscar componentes por nombre**, ingrese `update-windows`.

   1. Seleccione la casilla de verificación del resultado de búsqueda **`update-windows`**. Este componente incluye los parches de Windows más recientes para el sistema operativo.

1. Complete las entradas restantes de la receta de imágenes con las configuraciones necesarias. Para obtener más información, consulte [Crear una nueva versión de una receta de imagen (consola)](https://docs.aws.amazon.com/imagebuilder/latest/userguide/create-image-recipes.html#create-image-recipe-version-console) en la Guía del usuario de Image Builder.

1. Elija **Crear receta**.

1. Utilice la nueva receta de imagen en una canalización de imágenes nueva o existente. Una vez que la canalización de imágenes se ejecute correctamente, la AMI personalizada aparecerá como imagen de salida y estará lista para su uso. Para obtener más información, consulte [Crear una canalización de imágenes mediante el asistente de la consola de Image Builder de EC2](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-image-pipeline.html).

## Uso del componente de compilación administrado por Amazon
<a name="custom-windows-ami-build-component"></a>

Si no es viable utilizar una AMI de Windows optimizada para Amazon EKS como base, puede utilizar en su lugar el componente de compilación administrado por Amazon. Esta opción puede estar retrasada con respecto a las versiones de Kubernetes compatibles más recientes.

1. Inicie una receta nueva de Image Builder.

   1. Abra la consola del Generador de imágenes de EC2 en https://console.aws.amazon.com/imagebuilder.

   1. En el panel de navegación izquierdo, elija **Recetas de imágenes**.

   1. Seleccione **Crear receta de imagen**.

1. En la sección **Detalles de la receta**, ingrese un **nombre** y una **versión**.

1. Determine qué opción utilizará para crear su AMI personalizada en la sección **Imagen base**:
   +  **Seleccione imágenes administradas**: elija **Windows** para su **sistema operativo (SO) de imágenes**. A continuación, elija una de las siguientes opciones para **Origen de la imagen**.
     +  **Inicio rápido (administrado por Amazon)**: en el menú desplegable **Nombre de la imagen**, seleccione una versión de Windows Server compatible con Amazon EKS. Para obtener más información, consulte [Creación de nodos con AMI de Windows optimizadas](eks-optimized-windows-ami.md).
     +  **Imágenes de mi propiedad**: en **Nombre de la imagen**, seleccione el ARN de su propia imagen con su propia licencia. La imagen que proporcione no puede tener ya instalados los componentes de Amazon EKS.
   +  **Escribir el ID personalizado de la AMI**: en el ID de la AMI, ingrese el ID de su AMI con su propia licencia. La imagen que proporcione no puede tener ya instalados los componentes de Amazon EKS.

1. En la sección **Componentes de compilación: Windows**, haga lo siguiente:

   1. En la lista desplegable situada a la derecha del cuadro de búsqueda **Buscar componentes por nombre**, seleccione **Administrado por Amazon**.

   1. En el cuadro de búsqueda **Buscar componentes por nombre**, ingrese `eks`.

   1. Seleccione el resultado de búsqueda **`eks-optimized-ami-windows`**, aunque el resultado devuelto puede no ser la versión que desea.

   1. En el cuadro de búsqueda **Buscar componentes por nombre**, ingrese `update-windows`.

   1. Seleccione la casilla de verificación del resultado de búsqueda **update-windows**. Este componente incluye los parches de Windows más recientes para el sistema operativo.

1. En la sección **Componentes seleccionados**, haga lo siguiente:

   1. Elija **Opciones de control de versiones** para ** `eks-optimized-ami-windows` **.

   1. Elija **Especificar la versión del componente**.

   1. En el campo **Versión del componente**, ingrese *version.x* y reemplace *version* por una versión de Kubernetes compatible. Al ingresar una *x* para una parte del número de versión, se indica que se debe utilizar la versión más reciente del componente, que también se alinea con la parte de la versión que defina explícitamente. Preste atención a la salida de la consola, ya que le indicará si la versión que desea está disponible como componente administrado. Tenga en cuenta que es posible que las versiones de Kubernetes más recientes no estén disponibles para el componente de compilación. Para obtener más información sobre versiones disponibles, consulte [Recuperación de información sobre las versiones de los componentes de `eks-optimized-ami-windows`](#custom-windows-ami-component-versions).

1. Complete las entradas restantes de la receta de imágenes con las configuraciones necesarias. Para obtener más información, consulte [Crear una nueva versión de una receta de imagen (consola)](https://docs.aws.amazon.com/imagebuilder/latest/userguide/create-image-recipes.html#create-image-recipe-version-console) en la Guía del usuario de Image Builder.

1. Elija **Crear receta**.

1. Utilice la nueva receta de imagen en una canalización de imágenes nueva o existente. Una vez que la canalización de imágenes se ejecute correctamente, la AMI personalizada aparecerá como imagen de salida y estará lista para su uso. Para obtener más información, consulte [Crear una canalización de imágenes mediante el asistente de la consola de Image Builder de EC2](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-image-pipeline.html).

## Recuperación de información sobre las versiones de los componentes de `eks-optimized-ami-windows`
<a name="custom-windows-ami-component-versions"></a>

Puede recuperar información específica sobre lo que se instala con cada componente. Por ejemplo, puede comprobar qué versión de `kubelet` está instalada. Los componentes pasan por pruebas funcionales en las versiones de sistemas operativos Windows compatibles con Amazon EKS. Para obtener más información, consulte [Calendario de versiones](eks-optimized-windows-ami.md#windows-ami-release-calendar). Es posible que otras versiones de sistemas operativos Windows que se indican como compatibles o que han llegado al fin del soporte técnico no sean compatibles con el componente.

1. Abra la consola del Generador de imágenes de EC2 en https://console.aws.amazon.com/imagebuilder.

1. En el panel de navegación izquierdo, elija **Componentes**.

1. En la lista desplegable situada a la derecha del cuadro de búsqueda **Buscar componentes por nombre**, cambie **De mi propiedad** a **Inicio rápido (administrado por Amazon)**.

1. En el recuadro **Find components by name** (Buscar componentes por nombre), ingrese `eks`.

1. (Opcional) Si utiliza una versión reciente, seleccione dos veces la columna **Versión** para ordenarla en orden descendente.

1. Elija el enlace de ** `eks-optimized-ami-windows` ** con la versión que desee.

La **descripción** de la página resultante muestra la información específica.

# Detección de los problemas de estado de los nodos y reparación automática de los nodos
<a name="node-health"></a>

El estado del nodo hace referencia a su funcionamiento operativo y a la capacidad de un nodo de Kubernetes para ejecutar cargas de trabajo de manera eficiente. Un nodo en buen estado mantiene la conectividad esperada, cuenta con suficientes recursos informáticos y de almacenamiento y puede ejecutar las cargas de trabajo correctamente sin interrupciones.

Para ayudar a mantener nodos en buen estado en los clústeres de EKS, EKS ofrece el *agente de supervisión de nodos* y la *reparación automática de nodos*. Estas características se activan automáticamente con la computación en modo automático de EKS. También puede utilizar la reparación automática de nodos con grupos de nodos administrados por EKS y Karpenter, y puede utilizar el agente de supervisión de nodos de EKS con cualquier tipo de computación de EKS, excepto AWS Fargate. El agente de supervisión de nodos de EKS y la reparación automática de nodos son más eficaces cuando se utilizan juntos, pero también se pueden utilizar de forma individual en los clústeres de EKS.

**importante**  
El *agente de supervisión de nodos* y la *reparación automática de nodos* solo están disponibles en Linux. Estas características no están disponibles en Windows.

## Agente de supervisión de nodos
<a name="node-monitoring-agent"></a>

El agente de supervisión de nodos de EKS lee los registros de los nodos para detectar problemas de estado. Analiza los registros para detectar fallas y muestra información de estado sobre el estado de los nodos. Para cada categoría de problemas detectados, el agente aplica un `NodeCondition` dedicado a los nodos de trabajo. Para obtener información detallada sobre los problemas de estado de los nodos detectados por el agente de supervisión de nodos de EKS, consulte [Detecte problemas de estado de los nodos con el agente de supervisión de nodos EKS](node-health-nma.md).

La computación en modo automático de EKS incluye el agente de supervisión de nodos. Para otros tipos de computación de EKS, puede agregar el agente de supervisión de nodos como complemento de EKS o puede administrarlo con herramientas de Kubernetes como Helm. Para obtener más información, consulte [Configuración del agente de supervisión de nodos](node-health-nma.md#node-monitoring-agent-configure).

Con el agente de supervisión de nodos de EKS, las siguientes categorías de problemas de estado de los nodos aparecen como condiciones de los nodos. Tenga en cuenta que `Ready`, `DiskPressure` y `MemoryPressure` son condiciones estándar de los nodos de Kubernetes que aparecen incluso sin el agente de supervisión de nodos de EKS.


| Condiciones de nodos | Descripción | 
| --- | --- | 
|  AcceleratedHardwareReady  |  AcceleratedHardwareReady indica si el hardware acelerado (GPU, Neuron) del nodo funciona correctamente.  | 
|  ContainerRuntimeReady  |  ContainerRuntimeReady indica si el tiempo de ejecución del contenedor (containerd, etc.) funciona correctamente y puede ejecutar contenedores.  | 
|  DiskPressure  |  DiskPressure es una condición estándar de Kubernetes que indica que el nodo está bajo presión en el disco (poco espacio en disco o gran cantidad de E/S).  | 
|  KernelReady  |  KernelReady indica si el kernel funciona correctamente sin errores críticos, problemas o agotamiento de los recursos.  | 
|  Presión de memoria  |  MemoryPressure es una condición estándar de Kubernetes que indica que el nodo está experimentando una presión de memoria (poca memoria disponible).  | 
|  NetworkingReady  |  NetworkingReady indica si la pila de redes del nodo funciona correctamente (interfaces, enrutamiento, conectividad).  | 
|  StorageReady  |  StorageReady indica si el subsistema de almacenamiento del nodo funciona correctamente (discos, sistemas de archivos, E/S).  | 
|  Ready  |  Listo es la condición estándar de Kubernetes que indica que el nodo está en buen estado y listo para aceptar pods.  | 

## Reparación automática de nodos
<a name="node-auto-repair"></a>

La reparación automática de nodos de EKS supervisa continuamente el estado de los nodos, reacciona ante los problemas detectados y reemplaza o reinicia los nodos cuando es posible. Esto mejora la fiabilidad del clúster con una intervención manual mínima y ayuda a reducir el tiempo de inactividad de las aplicaciones.

Por sí sola, la reparación automática de nodos de EKS reacciona a las condiciones `Ready` del kubelet, a cualquier objeto de nodo eliminado manualmente y a las instancias de grupos de nodos administradas por EKS que no se unen al clúster. Cuando la reparación automática de nodos de EKS está habilitada con el agente de supervisión de nodos instalado, la reparación automática de nodos de EKS reacciona ante condiciones adicionales de los nodos: `AcceleratedHardwareReady`, `ContainerRuntimeReady`, `KernelReady`, `NetworkingReady` y `StorageReady`.

La reparación automática de nodos de EKS no reacciona a las condiciones de nodos `DiskPressure`, `MemoryPressure` o `PIDPressure` estándar de Kubernetes. Estas condiciones suelen indicar problemas relacionados con el comportamiento de la aplicación, la configuración de la carga de trabajo o los límites de recursos, en lugar de fallos en el nodo, lo que dificulta determinar una acción de reparación predeterminada adecuada. En estos escenarios, las cargas de trabajo están sujetas al [comportamiento de desalojo por presión de los nodos](https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction) de Kubernetes.

Para obtener más información sobre la reparación automática de nodos de EKS, consulte [Reparación automática de nodos en clústeres de EKS](node-repair.md).

**Topics**

# Detecte problemas de estado de los nodos con el agente de supervisión de nodos EKS
<a name="node-health-nma"></a>

En este tema se detallan los problemas de estado de los nodos detectados por el agente de supervisión de nodos de EKS, cómo estos problemas se manifiestan como condiciones o eventos de los nodos y cómo configurar el agente de supervisión de nodos.

El agente de supervisión de nodos de EKS se puede utilizar con o sin la reparación automática de nodos de EKS. Para obtener más información sobre la reparación automática de nodos de EKS, consulte [Reparación automática de nodos en clústeres de EKS](node-repair.md).

El código fuente del agente de supervisión de nodos EKS está publicado en GitHub en el repositorio [aws/eks-node-monitoring-agent](https://github.com/aws/eks-node-monitoring-agent).

## Problemas de estado de los nodos
<a name="node-health-issues"></a>

En las siguientes tablas se describen los problemas de estado de los nodos que el agente de supervisión de nodos puede detectar. Existen dos tipos de problemas:
+ Condición: un problema terminal que requiere una acción correctiva, como la sustitución o el reinicio de la instancia. Cuando la reparación automática está habilitada, Amazon EKS realizará una acción de reparación, ya sea la sustitución o el reinicio del nodo. Para obtener más información, consulte [Condiciones de nodos](learn-status-conditions.md#status-node-conditions).
+ Evento: un problema temporal o una configuración de nodo subóptima. No se realizará ninguna acción de reparación automática. Para obtener más información, consulte [Eventos de nodos](learn-status-conditions.md#status-node-events).

## Problemas de estado de los nodos AcceleratedHardware
<a name="node-health-AcceleratedHardware"></a>

La condición de supervisión es `AcceleratedHardwareReady` para los problemas de la tabla siguiente que tengan una gravedad de “Estado”. Los eventos y condiciones de la siguiente tabla se refieren a problemas de estado de los nodos relacionados con NVIDIA y Neuron.


| Nombre | Gravedad | Descripción | Acción de reparación | 
| --- | --- | --- | --- | 
|  DCGMDiagnosticFailure  |  Condición  |  Se produjo un error en un caso de prueba del conjunto de pruebas de diagnóstico activo de DCGM.  |  Ninguno  | 
|  DCGMError  |  Condición  |  Se perdió la conexión con el proceso host del DCGM o no fue posible establecerla.  |  Ninguno  | 
|  DCGMFieldError[Código]  |  Evento  |  DCGM detectó degradación de la GPU mediante un identificador de campo.  |  Ninguno  | 
|  DCGMHealthCode[Código]  |  Evento  |  Una comprobación de estado del DCGM falló de manera no fatal.  |  Ninguno  | 
|  DCGMHealthCode[Código]  |  Condición  |  Una comprobación de estado del DCGM falló de manera fatal.  |  Ninguno  | 
|  NeuronDMAError  |  Condición  |  Un motor de DMA encontró un error no recuperable.  |  Reemplazar  | 
|  NeuronHBMUncorrectableError  |  Condición  |  Un HBM encontró un error no corregible y generó resultados incorrectos.  |  Reemplazar  | 
|  NeuronNCUncorrectableError  |  Condición  |  Se detectó un error de memoria incorregible en Neuron Core.  |  Reemplazar  | 
|  NeuronSRAMUncorrectableError  |  Condición  |  Una SRAM integrada en el chip encontró un error de paridad y generó resultados incorrectos.  |  Reemplazar  | 
|  NvidiaDeviceCountMismatch  |  Evento  |  La cantidad de GPU visibles a través de NVML no coincide con el número de dispositivos de NVIDIA del sistema de archivos.  |  Ninguno  | 
|  NvidiaDoubleBitError  |  Condición  |  El controlador de la GPU produjo un error de doble bit.  |  Reemplazar  | 
|  NvidiaNCCLError  |  Evento  |  Se ha producido un error segfault en NVIDIA Collective Communications Library (`libnccl`).  |  Ninguno  | 
|  NvidiaNVLinkError  |  Condición  |  El controlador de la GPU notificó errores de NVLink.  |  Reemplazar  | 
|  NvidiaPCIeError  |  Evento  |  Las repeticiones de PCIe se activaron para recuperarse de errores de transmisión.  |  Ninguno  | 
|  NvidiaPageRetirement  |  Evento  |  El controlador de la GPU ha marcado una página de memoria para su retirada. Esto puede ocurrir si hay un único error de doble bit o si se encuentran dos errores de bit único en la misma dirección.  |  Ninguno  | 
|  NvidiaPowerError  |  Evento  |  El uso de energía de las GPU superó los umbrales permitidos.  |  Ninguno  | 
|  NvidiaThermalError  |  Evento  |  El estado térmico de las GPU superó los umbrales permitidos.  |  Ninguno  | 
|  NvidiaXID[Código]Error  |  Condición  |  Se ha producido un error crítico de la GPU.  |  Reemplazar o reiniciar  | 
|  NvidiaXID[Code]Warning  |  Evento  |  Se ha producido un error no crítico de la GPU.  |  Ninguno  | 

## Códigos de error de NVIDIA XID
<a name="nvidia-xid-codes"></a>

El agente de supervisión de nodos detecta los errores de NVIDIA XID en los registros del kernel de la GPU. Los errores XID se dividen en dos categorías:
+  **Códigos XID conocidos**: errores críticos que establecen una condición de nodo (`AcceleratedHardwareReady=False`) y desencadenan la reparación automática cuando están habilitados. Motivo por el que el formato del código es `NvidiaXID[Code]Error`. Es posible que los códigos XID conocidos que detecta el agente de supervisión de nodos EKS no representen la lista completa de códigos de NVIDIA XID que requieren acciones de reparación.
+  **Códigos XID desconocidos**: se registran únicamente como eventos de Kubernetes. No desencadenan la reparación automática. Motivo por el que el formato del código es `NvidiaXID[Code]Warning`. Para investigar errores XID desconocidos, revise los registros del kernel con`dmesg | grep -i nvrm`.

Para obtener más información sobre los errores de XID, consulte [Errores de Xid](https://docs.nvidia.com/deploy/xid-errors/index.html#topic_5_1) en la *documentación sobre la implementación y administración de las GPU de NVIDIA*. Para obtener más información sobre los mensajes XID individuales, consulte [Comprensión de los mensajes Xid](https://docs.nvidia.com/deploy/gpu-debug-guidelines/index.html#understanding-xid-messages) en la *documentación sobre implementación y administración de GPU de NVIDIA*.

La siguiente tabla muestra los códigos XID más conocidos, sus significados y la acción de reparación de nodos predeterminada si está habilitada.


| Código XID | Descripción | Acción de reparación | 
| --- | --- | --- | 
|  13  |  Excepción en el motor gráfico: se produjo un error en el motor gráfico de la GPU, normalmente provocado por problemas de software o errores de controlador.  |  Reboot  | 
|  31  |  Error de página en la memoria de la GPU: una aplicación intentó acceder a la memoria de la GPU que no está asignada ni accesible.  |  Reboot  | 
|  48  |  Error de ECC de doble bit: se produjo un error de doble bit incorregible en la memoria de la GPU, lo que indica una posible degradación del hardware.  |  Reboot  | 
|  63  |  Evento de reasignación de la memoria de la GPU: el controlador de la GPU reasignó una parte de la memoria de la GPU debido a errores detectados. Suele ser recuperable.  |  Reboot  | 
|  64  |  Error al reasignar la memoria de la GPU: la GPU no pudo reasignar la memoria defectuosa, lo que indica problemas de hardware.  |  Reboot  | 
|  74  |  Error de NVLink: se produjo un error en la interconexión NVLink de alta velocidad entre las GPU.  |  Reemplazar  | 
|  79  |  La GPU se ha caído del bus: ya no se puede acceder a la GPU a través de PCIe, lo que suele indicar un fallo de hardware o un problema de alimentación.  |  Reemplazar  | 
|  94  |  Error de memoria contenida: se produjo un error de memoria, pero estaba contenida y no afectó a otras aplicaciones.  |  Reboot  | 
|  95  |  Error de memoria no contenida: se produjo un error de memoria que puede haber afectado a otras aplicaciones o a la memoria del sistema.  |  Reboot  | 
|  119  |  Tiempo de espera del RPC de GSP: se agotó el tiempo de espera de la comunicación con el procesador del sistema de la GPU, posiblemente debido a problemas de firmware.  |  Reemplazar  | 
|  120  |  Error GSP: se produjo un error en el procesador del sistema de la GPU.  |  Reemplazar  | 
|  121  |  Error C2C: se produjo un error en la interconexión chip a chip (utilizada en las GPU de varios chips).  |  Reemplazar  | 
|  140  |  Error de ECC no recuperado: un error de ECC escapó a la contención y puede haber dañado los datos.  |  Reemplazar  | 

Para ver las condiciones actuales de los nodos relacionadas con el estado de la GPU, ejecute el siguiente comando.

```
kubectl get nodes -o custom-columns='NAME:.metadata.name,ACCELERATOR_READY:.status.conditions[?(@.type=="AcceleratedHardwareReady")].status,REASON:.status.conditions[?(@.type=="AcceleratedHardwareReady")].reason'
```

Para ver los eventos relacionados con XID en el clúster, ejecute uno de los siguientes comandos.

```
kubectl get events | grep -i "NvidiaXID"
```

## Problemas de estado de los nodos ContainerRuntime
<a name="node-health-ContainerRuntime"></a>

La condición de supervisión es `ContainerRuntimeReady` para los problemas de la tabla siguiente que tengan una gravedad de “Estado”.


| Nombre | Gravedad | Descripción | Acción de reparación | 
| --- | --- | --- | --- | 
|  ContainerRuntimeFailed  |  Evento  |  El tiempo de ejecución del contenedor no pudo crear un contenedor, lo que probablemente está relacionado con cualquier problema reportado si ocurre de manera repetida.  |  Ninguno  | 
|  DeprecatedContainerdConfiguration  |  Evento  |  Recientemente, se incorporó al nodo a través de `containerd` una imagen de contenedor con un manifiesto de imagen obsoleto (versión 2, esquema 1).  |  Ninguno  | 
|  KubeletFailed  |  Evento  |  El kubelet entró en un estado de fallo.  |  Ninguno  | 
|  LivenessProbeFailures  |  Evento  |  Se detectó una falla en la sonda de actividad, lo que podría indicar problemas en el código de la aplicación o valores de tiempo de espera insuficientes si ocurre de manera repetida.  |  Ninguno  | 
|  PodStuckTerminating  |  Condición  |  Un pod está o estuvo atascado al intentar terminar durante un tiempo excesivo, lo que puede ser causado por errores en CRI que impiden la progresión del estado del pod.  |  Reemplazar  | 
|  ReadinessProbeFailures  |  Evento  |  Se detectó una falla en la sonda de preparación, lo que podría indicar problemas en el código de la aplicación o valores de tiempo de espera insuficientes si ocurre de manera repetida.  |  Ninguno  | 
|  [Nombre]RepeatedRestart  |  Evento  |  Una unidad systemd se reinicia con frecuencia.  |  Ninguno  | 
|  ServiceFailedToStart  |  Evento  |  No se pudo iniciar una unidad de systemd.  |  Ninguno  | 

## Problemas de estado de los nodos del núcleo
<a name="node-health-Kernel"></a>

La condición de supervisión es `KernelReady` para los problemas de la tabla siguiente que tengan una gravedad de “Estado”.


| Nombre | Gravedad | Descripción | Acción de reparación | 
| --- | --- | --- | --- | 
|  AppBlocked  |  Evento  |  La tarea ha estado bloqueada durante un largo período para su programación, generalmente debido a estar bloqueada en la entrada o salida.  |  Ninguno  | 
|  AppCrash  |  Evento  |  Se colapsó una aplicación del nodo.  |  Ninguno  | 
|  ApproachingKernelPidMax  |  Evento  |  La cantidad de procesos está próxima a alcanzar la cantidad máxima de PID disponibles según la configuración de `kernel.pid_max` actual. Una vez alcanzado este límite, no se podrán inicializar más procesos.  |  Ninguno  | 
|  ApproachingMaxOpenFiles  |  Evento  |  La cantidad de archivos abiertos está próxima a la cantidad máxima de archivos abiertos posibles dada la configuración actual del núcleo. Una vez alcanzado este límite, no se podrán abrir nuevos archivos.  |  Ninguno  | 
|  ConntrackExceededKernel  |  Evento  |  El seguimiento de conexiones excedió el límite máximo del núcleo, lo que impidió el establecimiento de nuevas conexiones y podría ocasionar la pérdida de paquetes.  |  Ninguno  | 
|  ExcessiveZombieProcesses  |  Evento  |  Los procesos que no pueden ser completamente recuperados se acumulan en grandes cantidades, lo que indica problemas en la aplicación y podría llevar a alcanzar los límites de procesos del sistema.  |  Ninguno  | 
|  ForkFailedOutOfPIDs  |  Condición  |  Una llamada a fork o exec ha fallado debido a que el sistema se ha quedado sin identificadores de proceso o memoria, lo cual podría ser causado por procesos zombis o agotamiento de la memoria física.  |  Reemplazar  | 
|  KernelBug  |  Evento  |  Se detectó un error en el núcleo y fue reportado por el propio núcleo de Linux, aunque esto a veces puede ser causado por nodos con un alto uso de CPU o memoria que provocan retrasos en el procesamiento de eventos.  |  Ninguno  | 
|  LargeEnvironment  |  Evento  |  La cantidad de variables de entorno de este proceso es mayor de lo esperado, lo que se podría deber a la existencia de muchos servicios con `enableServiceLinks` configurado en verdadero, lo que podría provocar problemas de rendimiento.  |  Ninguno  | 
|  RapidCron  |  Evento  |  Un trabajo cron se ejecuta con una frecuencia inferior a cinco minutos en este nodo, lo que podría afectar el rendimiento si el trabajo consume recursos significativos.  |  Ninguno  | 
|  SoftLockup  |  Evento  |  La CPU se detuvo durante un periodo determinado.  |  Ninguno  | 

## Problemas de estado de los nodos de red
<a name="node-health-Networking"></a>

La condición de supervisión es `NetworkingReady` para los problemas de la tabla siguiente que tengan una gravedad de “Estado”.


| Nombre | Gravedad | Descripción | Acción de reparación | 
| --- | --- | --- | --- | 
|  BandwidthInExceeded  |  Evento  |  Los paquetes se han puesto en cola o se han descartado porque el ancho de banda agregado de entrada ha superado el máximo para la instancia.  |  Ninguno  | 
|  BandwidthOutExceeded  |  Evento  |  Los paquetes se han puesto en cola o se han descartado porque el ancho de banda agregado de salida ha superado el máximo para la instancia.  |  Ninguno  | 
|  ConntrackExceeded  |  Evento  |  El seguimiento de conexiones excedió el límite máximo de la instancia, lo que impidió el establecimiento de nuevas conexiones, lo que podría ocasionar la pérdida de paquetes.  |  Ninguno  | 
|  EFAErrorMetric  |  Evento  |  Las métricas del controlador EFA muestran que hay una interfaz con una degradación del rendimiento.  |  Ninguno  | 
|  IPAMDInconsistentState  |  Evento  |  El estado del punto de control de IPAMD en el disco no refleja las IP en el tiempo de ejecución del contenedor.  |  Ninguno  | 
|  IPAMDNoIPs  |  Evento  |  IPAMD se quedó sin direcciones IP.  |  Ninguno  | 
|  IPAMDNotReady  |  Condición  |  IPAMD no se puede conectar al servidor de la API.  |  Reemplazar  | 
|  IPAMDNotRunning  |  Condición  |  El proceso de CNI de Amazon VPC no se encontró en ejecución.  |  Reemplazar  | 
|  IPAMDRepeatedlyRestart  |  Evento  |  Se han producido múltiples reinicios en el servicio IPAMD.  |  Ninguno  | 
|  InterfaceNotRunning  |  Condición  |  Esta interfaz parece no estar en ejecución o existen problemas de red.  |  Reemplazar  | 
|  InterfaceNotUp  |  Condición  |  Parece que esta interfaz no está activa o que existen problemas de red.  |  Reemplazar  | 
|  KubeProxyNotReady  |  Evento  |  Kube-proxy no pudo ver ni enumerar los recursos.  |  Ninguno  | 
|  LinkLocalExceeded  |  Evento  |  Se descartaron paquetes porque los paquetes por segundo (PPS) del tráfico hacia los servicios proxy locales excedieron el máximo de la interfaz de red.  |  Ninguno  | 
|  MACAddressPolicyMisconfigured  |  Evento  |  La configuración del enlace systemd-networkd tiene un valor `MACAddressPolicy` incorrecto.  |  Ninguno  | 
|  MissingDefaultRoutes  |  Evento  |  Faltan reglas de ruta predeterminadas.  |  Ninguno  | 
|  MissingIPRoutes  |  Evento  |  Faltan rutas para las IP de los pods.  |  Ninguno  | 
|  MissingIPRules  |  Evento  |  Faltan reglas para las IP de los pods.  |  Ninguno  | 
|  MissingLoopbackInterface  |  Condición  |  La interfaz de bucle de retorno falta en esta instancia, lo que provoca fallos en los servicios que dependen de la conectividad local.  |  Reemplazar  | 
|  NetworkSysctl  |  Evento  |  La configuración de `sysctl` de red de este nodo es potencialmente incorrecta.  |  Ninguno  | 
|  PPSExceeded  |  Evento  |  Los paquetes han sido puestos en cola o descartados porque los paquetes por segundo (PPS) bidireccionales excedieron el máximo permitido para la instancia.  |  Ninguno  | 
|  PortConflict  |  Evento  |  Si un pod utiliza hostPort, puede escribir reglas de `iptables` que sobrescriban los puertos ya asignados del host, lo que podría impedir el acceso del servidor de la API al `kubelet`.  |  Ninguno  | 
|  UnexpectedRejectRule  |  Evento  |  Se encontró una regla inesperada de `REJECT` o `DROP` en las `iptables`, lo que podría bloquear el tráfico esperado.  |  Ninguno  | 

## Problemas de estado en el nodo de almacenamiento
<a name="node-health-Storage"></a>

La condición de supervisión es `StorageReady` para los problemas de la tabla siguiente que tengan una gravedad de “Estado”.


| Nombre | Gravedad | Descripción | Acción de reparación | 
| --- | --- | --- | --- | 
|  EBSInstanceIOPSExceeded  |  Evento  |  Se ha superado el máximo de IOPS de la instancia.  |  Ninguno  | 
|  EBSInstanceThroughputExceeded  |  Evento  |  Se ha superado el rendimiento máximo de la instancia.  |  Ninguno  | 
|  EBSVolumeIOPSExceeded  |  Evento  |  Se ha superado el máximo de IOPS para un volumen de EBS concreto.  |  Ninguno  | 
|  EBSVolumeThroughputExceeded  |  Evento  |  Se ha superado el rendimiento máximo de un volumen de Amazon EBS concreto.  |  Ninguno  | 
|  EtcHostsMountFailed  |  Evento  |  El montaje del `/etc/hosts` generado por el kubelet falló debido al remonte de `/var/lib/kubelet/pods` por parte de userdata durante la operación del `kubelet-container`.  |  Ninguno  | 
|  IODelays  |  Evento  |  Se detectó un retraso en la entrada o salida de un proceso, lo que podría indicar un aprovisionamiento insuficiente de recursos de entrada y salida si es excesivo.  |  Ninguno  | 
|  KubeletDiskUsageSlow  |  Evento  |  El `kubelet` informa de un uso lento del disco al intentar acceder al sistema de archivos. Esto podría indicar que no hay suficientes entradas y salidas en el disco o problemas con el sistema de archivos.  |  Ninguno  | 
|  XFSSmallAverageClusterSize  |  Evento  |  El tamaño medio del clúster de XFS es pequeño, lo que indica una fragmentación excesiva del espacio libre. De este modo, se puede impedir la creación de archivos a pesar de que haya nodos de indexación o espacio libre disponibles.  |  Ninguno  | 

## Configuración del agente de supervisión de nodos
<a name="node-monitoring-agent-configure"></a>

El agente de supervisión de nodos EKS se implementa como DaemOnset. Al implementarlo como un complemento de EKS, puede personalizar la instalación con los siguientes valores de configuración. Para ver las configuraciones predeterminadas, consulte el [gráfico de Helm](https://github.com/aws/eks-node-monitoring-agent/blob/main/charts/eks-node-monitoring-agent/values.yaml) del agente de supervisión de nodos de EKS.


| Opción de configuración | Descripción | 
| --- | --- | 
|   `monitoringAgent.resources.requests.cpu`   |  Solicitud de recursos de CPU para el agente de supervisión.  | 
|   `monitoringAgent.resources.requests.memory`   |  Solicitud de recursos de memoria para el agente de supervisión.  | 
|   `monitoringAgent.resources.limits.cpu`   |  Límite de recursos de CPU para el agente de supervisión.  | 
|   `monitoringAgent.resources.limits.memory`   |  Límite de recursos de memoria para el agente de supervisión.  | 
|   `monitoringAgent.tolerations`   |  Tolerancias para programar el agente de supervisión en nodos con taint.  | 
|   `monitoringAgent.additionalArgs`   |  Argumentos de línea de comandos opcionales que se trasladarán al agente de supervisión único.  | 

**nota**  
Puede configurar `hostname-override` y `verbosity` como `monitoringAgent.additionalArgs` con los complementos de EKS o la instalación de Helm. Actualmente no se pueden personalizar los agentes de supervisión de nodos `probe-address` (`8002`) o `metrics-address` (`8003`) mediante argumentos adicionales con los complementos de EKS o la instalación de Helm.

El agente de supervisión de nodos incluye un componente de servidor NVIDIA DCGM (administrador de GPU del centro de datos) (`nv-hostengine`) para supervisar las GPU de NVIDIA. Este componente solo se ejecuta en los nodos que son del tipo de instancia de GPU de NVIDIA, como muestra `nodeAffinity` en el [gráfico de Helm](https://github.com/aws/eks-node-monitoring-agent/blob/main/charts/eks-node-monitoring-agent/values.yaml) del agente. No puede usar una instalación DCGM de NVIDIA existente con el agente de supervisión de nodos de EKS. Si necesita esta funcionalidad, envíenos sus comentarios sobre la hoja de ruta de EKS en [GitHub, problema número 2763](https://github.com/aws/containers-roadmap/issues/2763).

Al implementar el agente de supervisión de nodos de EKS como un complemento de EKS, puede personalizar la instalación de DCGM de NVIDIA con los siguientes valores de configuración.


| Opción de configuración | Descripción | 
| --- | --- | 
|   `dcgmAgent.resources.requests.cpu`   |  Solicitud de recursos de CPU para el agente de DCGM.  | 
|   `dcgmAgent.resources.requests.memory`   |  Solicitud de recursos de memoria para el agente de DCGM.  | 
|   `dcgmAgent.resources.limits.cpu`   |  Límite de recursos de CPU para el agente de DCGM.  | 
|   `dcgmAgent.resources.limits.memory`   |  Límite de recursos de memoria para el agente de DCGM.  | 
|   `dcgmAgent.tolerations`   |  Tolerancias para programar el agente de DCGM en nodos con taint.  | 

Puede usar los siguientes comandos de la AWS CLI para obtener información útil sobre las versiones y el esquema del complemento de EKS del agente de supervisión de nodos EKS.

Obtenga la última versión del complemento de agente para su versión de Kubernetes. Sustituya `1.35` por su versión de Kubernetes.

```
aws eks describe-addon-versions \
  --addon-name eks-node-monitoring-agent \
  --kubernetes-version 1.35 \
  --query='addons[].addonVersions[].addonVersion'
```

Obtenga el esquema de complementos del agente compatible con los complementos de EKS. Sustituya `v1.5.1-eksbuild.1` por su versión de agente.

```
aws eks describe-addon-configuration \
  --addon-name eks-node-monitoring-agent \
  --addon-version v1.5.1-eksbuild.1
```

# Reparación automática de nodos en clústeres de EKS
<a name="node-repair"></a>

En este tema se detalla el comportamiento de la reparación automática de nodos de EKS y cómo configurarlo para que cumpla con sus requisitos. La reparación automática de nodos de EKS está habilitada de forma predeterminada en el modo automático de EKS y se puede utilizar con los grupos de nodos administrados por EKS y con Karpenter.

Las acciones predeterminadas de reparación automática de nodos de EKS se resumen en la siguiente tabla y se aplican al comportamiento del modo automático de EKS, los grupos de nodos administrados por EKS y Karpenter. Cuando se utiliza el modo automático de EKS o Karpenter, todas las acciones de reparación de `AcceleratedHardwareReady` son `Replace`, y solo los grupos de nodos administrados por EKS admiten `Reboot` como acción de reparación.

Para obtener una lista detallada de los problemas de estado de los nodos detectados por el agente de supervisión de nodos de EKS y sus correspondientes acciones de reparación de nodos, consulte [Detecte problemas de estado de los nodos con el agente de supervisión de nodos EKS](node-health-nma.md).


| Condiciones de nodos | Descripción | Reparación posterior | Acciones de reparación | 
| --- | --- | --- | --- | 
|  AcceleratedHardwareReady  |  AcceleratedHardwareReady indica si el hardware acelerado (GPU, Neuron) del nodo funciona correctamente.  |  10 m  |  Reemplazar o reiniciar  | 
|  ContainerRuntimeReady  |  ContainerRuntimeReady indica si el tiempo de ejecución del contenedor (containerd, etc.) funciona correctamente y puede ejecutar contenedores.  |  30 m  |  Reemplazar  | 
|  DiskPressure  |  DiskPressure es una condición estándar de Kubernetes que indica que el nodo está bajo presión en el disco (poco espacio en disco o gran cantidad de E/S).  |  N/A  |  Ninguno  | 
|  KernelReady  |  KernelReady indica si el kernel funciona correctamente sin errores críticos, problemas o agotamiento de los recursos.  |  30 m  |  Reemplazar  | 
|  Presión de memoria  |  MemoryPressure es una condición estándar de Kubernetes que indica que el nodo está experimentando una presión de memoria (poca memoria disponible).  |  N/A  |  Ninguno  | 
|  NetworkingReady  |  NetworkingReady indica si la pila de redes del nodo funciona correctamente (interfaces, enrutamiento, conectividad).  |  30 m  |  Reemplazar  | 
|  StorageReady  |  StorageReady indica si el subsistema de almacenamiento del nodo funciona correctamente (discos, sistemas de archivos, E/S).  |  30 m  |  Reemplazar  | 
|  Ready  |  Listo es la condición estándar de Kubernetes que indica que el nodo está en buen estado y listo para aceptar pods.  |  30 m  |  Reemplazar  | 

Las acciones de reparación automática de nodos de EKS están deshabilitadas de forma predeterminada en los siguientes escenarios. Las acciones de reparación de nodos en curso continúan en cada escenario. Consulte [Configuración de la reparación automática de nodos](#configure-node-repair) para saber cómo anular esta configuración predeterminada.

 **Grupos de nodos administrados por EKS** 
+ El grupo de nodos tiene más de cinco nodos y más del 20 % de los nodos del grupo de nodos están en mal estado.
+ Un cambio de zona para el clúster se desencadena a través del Controlador de recuperación de aplicaciones (ARC).

 **Modo automático de EKS y Karpenter** 
+ Más del 20 % de los nodos del NodePool están en mal estado.
+ En el caso de los NodeClaims independientes, el 20 % de los nodos del clúster están en mal estado.

## Configuración de la reparación automática de nodos
<a name="configure-node-repair"></a>

La reparación automática de nodos no se puede configurar cuando se utiliza el modo automático de EKS y siempre está activado con los mismos ajustes predeterminados que Karpenter.

### Karpenter
<a name="configure-node-repair-karpenter"></a>

Para utilizar la reparación automática de nodos con Karpenter, active la puerta de características `NodeRepair=true`. Puede habilitar las puertas de características mediante la opción `--feature-gates` de la CLI o la variable de entorno `FEATURE_GATES` en la implementación de Karpenter. Para obtener más información, consulte la documentación de [Karpenter](https://karpenter.sh/docs/concepts/disruption/#node-auto-repair).

### Grupos de nodos administrados
<a name="configure-node-repair-mng"></a>

Puede activar la reparación automática de nodos al crear nuevos grupos de nodos administrados por EKS o al actualizar los grupos de nodos administrados por EKS existentes.
+  **Consola Amazon EKS**: seleccione la casilla de verificación **Habilitar la reparación automática de nodos** para el grupo de nodos administrado. Para obtener más información, consulte [Creación de un grupo de nodos administrados para un clúster](create-managed-node-group.md).
+  **AWS CLI**: agregue `--node-repair-config enabled=true` al comando [https://docs.aws.amazon.com/cli/latest/reference/eks/create-nodegroup.html](https://docs.aws.amazon.com/cli/latest/reference/eks/create-nodegroup.html) o [https://docs.aws.amazon.com/cli/latest/reference/eks/update-nodegroup-config.html](https://docs.aws.amazon.com/cli/latest/reference/eks/update-nodegroup-config.html).
+  **eksctl**: configure `managedNodeGroups.nodeRepairConfig.enabled: true` y consulte el ejemplo en el [GitHub de eksctl](https://github.com/eksctl-io/eksctl/blob/main/examples/44-node-repair.yaml).

Al utilizar grupos de nodos administrados por EKS, puede controlar el comportamiento de reparación automática de los nodos con los siguientes ajustes.

Para controlar cuándo la reparación automática de nodos deja de funcionar, establezca un umbral en función del número de nodos en mal estado del grupo de nodos. Establezca el porcentaje o el recuento absoluto, pero no ambos.


| Opción | Descripción | 
| --- | --- | 
|   `maxUnhealthyNodeThresholdCount`   |  El número absoluto de nodos en mal estado por encima del cual se detiene la reparación automática de nodos. Úselo para limitar el alcance de las reparaciones.  | 
|   `maxUnhealthyNodeThresholdPercentage`   |  El número absoluto de nodos en mal estado por encima del cual se detiene la reparación automática de nodos (0-100).  | 

Para controlar el número de nodos que se reparan al mismo tiempo, puede configurar el paralelismo de reparación. Al igual que con el umbral de nodos en mal estado, establezca el porcentaje o el recuento absoluto, pero no ambos.


| Opción | Descripción | 
| --- | --- | 
|   `maxParallelNodesRepairedCount`   |  El número máximo de nodos para la reparación simultánea.  | 
|   `maxParallelNodesRepairedPercentage`   |  El porcentaje máximo de nodos en mal estado que se pueden reparar simultáneamente (0-100).  | 

Con `nodeRepairConfigOverrides`, puede personalizar el comportamiento de reparación para condiciones específicas. Úselo cuando necesite diferentes acciones de reparación o tiempos de espera para diferentes tipos de problemas.

Cada anulación requiere los siguientes campos:


| Campo | Descripción | 
| --- | --- | 
|   `nodeMonitoringCondition`   |  El tipo de condición del nodo notificada por el agente de supervisión de nodos. Por ejemplo: `AcceleratedHardwareReady`, `NetworkingReady`, `StorageReady`, `KernelReady`.  | 
|   `nodeUnhealthyReason`   |  El código de motivo específico de la condición de mal estado. Por ejemplo: `NvidiaXID31Error`, `IPAMDNotRunning`.  | 
|   `minRepairWaitTimeMins`   |  El tiempo mínimo (en minutos) que debe persistir la condición de reparación antes de que el nodo sea elegible para la reparación. Utilícelo para evitar reparar los nodos por problemas temporales.  | 
|   `repairAction`   |  La acción que se debe realizar cuando se cumplen las condiciones. Valores válidos: `Replace` (terminar y reemplazar el nodo), `Reboot` (reiniciar el nodo) o `NoAction` (sin acciones de reparación).  | 

El siguiente ejemplo de la AWS CLI crea un grupo de nodos con una configuración de reparación personalizada.

```
aws eks create-nodegroup \
  --cluster-name my-cluster \
  --nodegroup-name my-nodegroup \
  --node-role arn:aws:iam::111122223333:role/NodeRole \
  --subnets subnet-0123456789abcdef0 \
  --node-repair-config '{
    "enabled": true,
    "maxUnhealthyNodeThresholdPercentage": 10,
    "maxParallelNodesRepairedCount": 3,
    "nodeRepairConfigOverrides": [
      {
        "nodeMonitoringCondition": "AcceleratedHardwareReady",
        "nodeUnhealthyReason": "NvidiaXID64Error",
        "minRepairWaitTimeMins": 5,
        "repairAction": "Replace"
      },
      {
        "nodeMonitoringCondition": "AcceleratedHardwareReady",
        "nodeUnhealthyReason": "NvidiaXID31Error",
        "minRepairWaitTimeMins": 15,
        "repairAction": "NoAction"
      }
    ]
  }'
```

Esta configuración hace lo siguiente:
+ Permite la reparación automática de nodos
+ Detiene las acciones de reparación cuando más del 10 % de los nodos están en mal estado
+ Repara hasta 3 nodos a la vez
+ Anula los errores XID 64 (error de reasignación de la memoria de la GPU) para reemplazar el nodo después de 5 minutos. El valor predeterminado para el reinicio es tras 10 minutos.
+ Anula los errores XID 31 (error de página en la memoria de la GPU) para no realizar ninguna acción. El valor predeterminado para el reinicio es tras 10 minutos.

# Cómo ver el estado de los nodos
<a name="learn-status-conditions"></a>

En este tema se explican las herramientas y métodos que existen para supervisar el estado de los nodos en los clústeres de Amazon EKS. La información abarca condiciones, eventos y casos de detección de nodos útiles a la hora de identificar y diagnosticar problemas a nivel de nodo. Utilice los comandos y patrones descritos aquí para inspeccionar los recursos de estado de los nodos, interpretar las condiciones de estado y analizar los eventos de los nodos para la resolución de problemas operativos.

Puede obtener información sobre el estado de los nodos con comandos de Kubernetes para todos los nodos. Además, si utiliza el agente de supervisión de nodos a través del modo automático de Amazon EKS o el complemento administrado de Amazon EKS, obtendrá una mayor variedad de señales de nodos útiles para la resolución de problemas. Las descripciones de los problemas de estado detectados por el agente de supervisión de nodos también se encuentran disponibles en el panel de observabilidad. Para obtener más información, consulte [Detecte problemas de estado de los nodos con el agente de supervisión de nodos EKS](node-health-nma.md).

## Condiciones de nodos
<a name="status-node-conditions"></a>

Las condiciones del nodo representan problemas en el terminal que requieren acciones correctoras, como la sustitución de la instancia o el reinicio.

 **Para obtener las condiciones de todos los nodos:** 

```
kubectl get nodes -o 'custom-columns=NAME:.metadata.name,CONDITIONS:.status.conditions[*].type,STATUS:.status.conditions[*].status'
```

 **Para obtener las condiciones detalladas de un nodo específico** 

```
kubectl describe node node-name
```

 **Ejemplo del resultado de condición de un nodo en buen estado:** 

```
  - lastHeartbeatTime: "2024-11-21T19:07:40Z"
    lastTransitionTime: "2024-11-08T03:57:40Z"
    message: Monitoring for the Networking system is active
    reason: NetworkingIsReady
    status: "True"
    type: NetworkingReady
```

 **Ejemplo de condición de un nodo en mal estado con un problema de red:** 

```
  - lastHeartbeatTime: "2024-11-21T19:12:29Z"
    lastTransitionTime: "2024-11-08T17:04:17Z"
    message: IPAM-D has failed to connect to API Server which could be an issue with
      IPTable rules or any other network configuration.
    reason: IPAMDNotReady
    status: "False"
    type: NetworkingReady
```

## Eventos de nodos
<a name="status-node-events"></a>

Los eventos de nodos indican problemas temporales o configuraciones que no son óptimas.

 **Para obtener todos los eventos notificados por el agente de supervisión de nodos** 

Si el agente de supervisión de nodos está disponible, puede ejecutar el siguiente comando.

```
kubectl get events --field-selector=reportingComponent=eks-node-monitoring-agent
```

Código de salida de ejemplo:

```
LAST SEEN   TYPE      REASON       OBJECT                                              MESSAGE
4s          Warning   SoftLockup   node/ip-192-168-71-251.us-west-2.compute.internal   CPU stuck for 23s
```

 **Para obtener eventos de todos los nodos** 

```
kubectl get events --field-selector involvedObject.kind=Node
```

 **Para obtener eventos de un nodo específico** 

```
kubectl get events --field-selector involvedObject.kind=Node,involvedObject.name=node-name
```

 **Para ver eventos en tiempo real** 

```
kubectl get events -w --field-selector involvedObject.kind=Node
```

 **Ejemplo de resultado de un evento:** 

```
LAST SEEN   TYPE     REASON           OBJECT         MESSAGE
2m          Warning  MemoryPressure   Node/node-1    Node experiencing memory pressure
5m          Normal   NodeReady        Node/node-1    Node became ready
```

## Comandos de resolución de problemas habituales
<a name="status-node-troubleshooting"></a>

```
# Get comprehensive node status
kubectl get node node-name -o yaml

# Watch node status changes
kubectl get nodes -w

# Get node metrics
kubectl top node
```

# Recuperación de los registros de nodos de un nodo administrado mediante kubectl y S3
<a name="auto-get-logs"></a>

Aprenda a recuperar los registros de nodos de un nodo administrado por Amazon EKS que tenga el agente de supervisión de nodos.

## Requisitos previos
<a name="_prerequisites"></a>

Asegúrese de contar con lo siguiente:
+ Un clúster de Amazon EKS con el agente de supervisión de nodos existente. 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).
+ La herramienta de línea de comandos `kubectl` instalada y configurada para comunicarse con el clúster.
+ AWS CLI instalada y sesión iniciada con los permisos suficientes para crear buckets y objetos de S3.
+ Una versión reciente de Python 3 instalada
+ El SDK de AWS para Python 3 y Boto 3 instalado.

## Paso 1: Creación de un destino de bucket de S3 (opcional)
<a name="_step_1_create_s3_bucket_destination_optional"></a>

Si aún no tiene un bucket de S3 para almacenar los registros, cree uno. Utilice el siguiente comando de AWS CLI. El bucket utiliza de manera predeterminada la lista de control de acceso `private`. Sustituya *bucket-name* por el nombre único que haya elegido.

```
aws s3api create-bucket --bucket <bucket-name>
```

## Paso 2: Creación de una URL de S3 previamente firmada para HTTP Put
<a name="_step_2_create_pre_signed_s3_url_for_http_put"></a>

Amazon EKS devuelve los registros de nodo mediante una operación HTTP PUT a una URL especificada. En este tutorial, generaremos una URL de HTTP PUT de S3 previamente firmada.

Los registros se devolverán como un gzip tarball, con la extensión `.tar.gz`.

**nota**  
Debe usar la API de AWS o un SDK para crear la URL de carga previamente firmada de S3 para que EKS cargue el archivo de registro. No puede crear una URL de carga previamente firmada de S3 mediante AWS CLI.

1. Determine en qué parte del bucket desea almacenar los registros. Por ejemplo, puede utilizar *2024-11-12/logs1.tar.gz* como clave.

1. Copie el siguiente código de Python en el archivo *presign-upload.py*. Sustituya *<bucket-name>* y *<key>*. La clave debe terminar con `.tar.gz`.

   ```
   import boto3; print(boto3.client('s3').generate_presigned_url(
      ClientMethod='put_object',
      Params={'Bucket': '<bucket-name>', 'Key': '<key>'},
      ExpiresIn=1000
   ))
   ```

1. Ejecute el script con

   ```
   python presign-upload.py
   ```

1. Anote la URL de resultado. Utilice este valor en el siguiente paso como *http-put-destination*.

Para obtener más información, consulte [Generate a presigned URL to upload a file](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/s3-presigned-urls.html#generating-a-presigned-url-to-upload-a-file) en la documentación del AWS SDK para Python Boto3.

## Paso 3: Creación del recurso de NodeDiagnostic
<a name="_step_3_create_nodediagnostic_resource"></a>

Identifique el nombre del nodo del que desea recopilar los registros.

Cree un manifiesto `NodeDiagnostic` que utilice el nombre del nodo como nombre del recurso y que proporcione un destino de URL de HTTP PUT.

```
apiVersion: eks.amazonaws.com/v1alpha1
kind: NodeDiagnostic
metadata:
    name: <node-name>
spec:
    logCapture:
        destination: http-put-destination
```

Aplique el manifiesto al clúster.

```
kubectl apply -f nodediagnostic.yaml
```

Para comprobar el estado de la recopilación, puede describir el recurso `NodeDiagnostic`:
+ Un estado de `Success` o `SuccessWithErrors` indica que la tarea se completó y los registros se cargaron en el destino indicado (`SuccessWithErrors` indica que es posible que falten algunos registros)
+ Si el estado es Error, confirme que la URL de carga esté formada correctamente y no haya caducado.

```
kubectl describe nodediagnostics.eks.amazonaws.com/<node-name>
```

## Paso 4: Descarga de los registros de S3
<a name="_step_4_download_logs_from_s3"></a>

Espere aproximadamente un minuto antes de intentar descargar los registros. A continuación, use la CLI de S3 para descargar los registros.

```
# Once NodeDiagnostic shows Success status, download the logs
aws s3 cp s3://<bucket-name>/key ./<path-to-node-logs>.tar.gz
```

## Paso 5: Cómo limpiar el recurso de NodeDiagnostic
<a name="_step_5_clean_up_nodediagnostic_resource"></a>
+  Los recursos de `NodeDiagnostic` no se eliminan automáticamente. Deberá limpiarlos por cuenta propia después de haber obtenido los artefactos de registro

```
# Delete the NodeDiagnostic resource
kubectl delete nodediagnostics.eks.amazonaws.com/<node-name>
```

## Destino `node` de NodeDiagnostic
<a name="_nodediagnostic_node_destination"></a>

A partir de la versión `v1.6.0` del agente de supervisión de nodos, existe la opción de establecer el destino de la recopilación de registros en `node`. El uso de este destino permitirá recopilar y conservar temporalmente los registros en el nodo para su posterior recopilación. Además de esta funcionalidad, en el repositorio de GitHub del agente de supervisión de nodos hay un complemento `kubectl` que puede instalar para facilitar la interacción y la recopilación de registros. Para obtener más información, consulte la [documentación del complemento `kubectl ekslogs`](https://github.com/aws/eks-node-monitoring-agent/blob/main/tools/kubectl-ekslogs/README.md).

## Ejemplo de uso
<a name="_example_usage"></a>

```
# Collect NodeDiagnostic logs from a single node
kubectl ekslogs <node-name>

# Collect NodeDiagnostic logs from multiple nodes
kubectl ekslogs <node-name-1> <node-name-2> <node-name-3>

# Collect NodeDiagnostic logs from all nodes with a specific label
kubectl ekslogs -l <key>=<value>
```

# Información general sobre los Nodos híbridos de Amazon EKS
<a name="hybrid-nodes-overview"></a>

Con los *Nodos híbridos de Amazon EKS*, puede utilizar la infraestructura en las instalaciones y periférica como nodos en los clústeres de Amazon EKS. AWS administra el plano de control de Kubernetes alojado en AWS del clúster de Amazon EKS y usted administra los nodos híbridos que se ejecutan en los entornos en las instalaciones o periféricos. Así se unifica la administración de Kubernetes en los entornos y se delega la administración del plano de control de Kubernetes en AWS para las aplicaciones en las instalaciones y periféricas.

Los Nodos híbridos de Amazon EKS funcionan con cualquier hardware en las instalaciones o máquinas virtuales, lo que aporta la eficacia, escalabilidad y disponibilidad propias de Amazon EKS a dondequiera que las aplicaciones se ejecuten. Puede utilizar una amplia gama de características de Amazon EKS con los Nodos híbridos de Amazon EKS, incluidos complementos de Amazon EKS, Pod Identity de Amazon EKS, entradas de acceso a clústeres, información sobre clústeres y soporte ampliado para versiones de Kubernetes. Los Nodos híbridos de Amazon EKS se integran de forma nativa con los servicios de AWS, incluidos AWS Systems Manager, AWS IAM Roles Anywhere, Amazon Managed Service para Prometheus y Amazon CloudWatch para la supervisión centralizada, el registro y la administración de identidades.

Con los Nodos híbridos de Amazon EKS, no existen compromisos iniciales ni cuotas mínimas, y se cobra por hora por los recursos de vCPU de los nodos híbridos cuando están asociados a los clústeres de Amazon EKS. Para obtener más información sobre los precios, consulte [Precios de Amazon EKS](https://aws.amazon.com/eks/pricing/).

[![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/tFn9IdlddBw?rel=0/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/tFn9IdlddBw?rel=0)


## Características
<a name="hybrid-nodes-features"></a>

Los Nodos híbridos de EKS ofrecen las siguientes características de alto nivel:
+  **Plano de control de Kubernetes administrado**: AWS administra el plano de control de Kubernetes alojado en AWS del clúster de EKS, mientras que su responsabildiad es administrar los nodos híbridos que se ejecutan en los entornos en las instalaciones o periféricos. Así se unifica la administración de Kubernetes en los entornos y se delega la administración del plano de control de Kubernetes en AWS para las aplicaciones en las instalaciones y periféricas. Si trasladaa el plano de control de Kubernetes a AWS, podrá conservar la capacidad existente en las instalaciones para las aplicaciones y confiar en que el plano de control de Kubernetes escalará junto con las cargas de trabajo.
+  **Experiencia de EKS coherente**: la mayoría de las características de EKS son compatibles con los Nodos híbridos de EKS, con lo que es posible disfrutar de una experiencia coherente de EKS tanto en entornos en las instalaciones como en la nube, incluidos los complementos de EKS, Pod Identity de EKS, las entradas de acceso al clúster, la información del clúster, el soporte ampliado de versiones de Kubernetes y más. Consulte [Cómo configurar complementos para nodos híbridos](hybrid-nodes-add-ons.md) para obtener más información sobre los complementos de EKS compatibles con los Nodos híbridos de EKS.
+  **Observabilidad y administración de identidades centralizadas**: los Nodos híbridos de EKS se integran de forma nativa con los servicios de AWS, incluidos AWS Systems Manager, AWS IAM Roles Anywhere, Amazon Managed Service para Prometheus y Amazon CloudWatch, para ofrecer supervisión, registro y administración de identidades centralizados.
+  **Ampliación a la nube o incremento de capacidad en las instalaciones**: un único clúster de EKS puede ejecutar nodos híbridos junto con nodos en las regiones de AWS, las Zonas locales de AWS oAWS Outposts, lo que permite una ampliación dinámica hacia la nube o el incremento de capacidad en las instalaciones en los clústeres de EKS. Consulte [Consideraciones para clústeres en modo mixto](hybrid-nodes-webhooks.md#hybrid-nodes-considerations-mixed-mode) para obtener más información.
+  **Infraestructura flexible**: los Nodos híbridos de EKS permiten *utilizar infraestructura propia*, por lo que funcionan de manera independiente del entorno de infraestructura que se utilice para los nodos híbridos. Puede ejecutar nodos híbridos en máquinas físicas o virtuales, y en arquitecturas x86 y ARM, lo que permite migrar cargas de trabajo en las instalaciones que se ejecutan en nodos híbridos entre distintos tipos de infraestructura.
+  **Redes flexibles**: al utilizar los nodos híbridos de EKS, la comunicación entre el plano de control de EKS y los nodos híbridos se enruta a través de la VPC y las subredes que se transmiten durante la creación del clúster, que se basa en el [mecanismo existente](https://docs.aws.amazon.com/eks/latest/best-practices/subnets.html) en EKS para la conexión en red del plano de control a los nodos. Esto es flexible con respecto al método que prefiera para conectar las redes en las instalaciones a una VPC en AWS. Existen varias [opciones documentadas](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html), como AWS Site-to-Site VPN y AWS Direct Connect, o una solución de VPN propia. Además, puede elegir el método que mejor se adapte al caso de uso.

## Límites
<a name="hybrid-node-limits"></a>
+ Hasta 15 CIDR para redes de nodos remotos y 15 CIDR para redes de pods remotos por clúster.

## Consideraciones
<a name="hybrid-nodes-general"></a>
+ Los Nodos híbridos de EKS se pueden utilizar con clústeres de EKS nuevos o existentes.
+ Los Nodos híbridos de EKS se encuentran disponibles en todas las regiones de AWS, excepto en las regiones de AWS GovCloud (EE. UU.) y AWS China.
+ Los Nodos híbridos de EKS deben disponer de una conexión fiable entre el entorno en las instalaciones y AWS. Los Nodos híbridos de EKS no son adecuados para entornos desconectados, interrumpidos, intermitentes o limitados (DDIL). Si ejecuta en un entorno DDIL, considere la posibilidad de utilizar [Amazon EKS Anywhere](https://aws.amazon.com/eks/eks-anywhere/). Consulte las [prácticas recomendadas para los nodos híbridos de EKS](https://docs.aws.amazon.com/eks/latest/best-practices/hybrid-nodes-network-disconnections.html) para obtener información sobre cómo se comportan los nodos híbridos durante los escenarios de desconexión de la red.
+ No se admite la ejecución de Nodos híbridos de EKS en infraestructura en la nube, incluidas las regiones de AWS, las Zonas locales de AWS, AWS Outposts o en otras nubes. Se aplicará la tarifa de nodos híbridos si ejecuta nodos híbridos en instancias de Amazon EC2.
+ El cobro correspondiente a los nodos híbridos comenzará en el momento en que los nodos se unan al clúster de EKS y finalizará cuando los nodos se eliminen del clúster. Asegúrese de eliminar los nodos híbridos del clúster de EKS si no los utiliza.

## Recursos adicionales
<a name="hybrid-nodes-resources"></a>
+  [https://www.eksworkshop.com/docs/networking/eks-hybrid-nodes/](https://www.eksworkshop.com/docs/networking/eks-hybrid-nodes/): instrucciones paso a paso para implementar nodos híbridos de EKS en un entorno de demostración.
+  [https://www.youtube.com/watch?v=ZxC7SkemxvU](https://www.youtube.com/watch?v=ZxC7SkemxvU): sesión de AWS re:Invent para presentar el lanzamiento de los nodos híbridos de EKS, en la que un cliente mostró cómo utiliza los nodos híbridos de EKS en su entorno.
+  [https://repost.aws/articles/ARL44xuau6TG2t-JoJ3mJ5Mw/unpacking-the-cluster-networking-for-amazon-eks-hybrid-nodes](https://repost.aws/articles/ARL44xuau6TG2t-JoJ3mJ5Mw/unpacking-the-cluster-networking-for-amazon-eks-hybrid-nodes): artículo en el que se explican varios métodos para configurar las redes de los nodos híbridos de EKS.
+  [https://aws.amazon.com/blogs/containers/run-genai-inference-across-environments-with-amazon-eks-hybrid-nodes/](https://aws.amazon.com/blogs/containers/run-genai-inference-across-environments-with-amazon-eks-hybrid-nodes/): entrada de blog que muestra cómo ejecutar la inferencia de GenAI en todos los entornos con nodos híbridos de EKS.

# Configuración previa requerida para los nodos híbridos
<a name="hybrid-nodes-prereqs"></a>

Para usar los Nodos híbridos de Amazon EKS, debe tener conectividad privada desde el entorno en las instalaciones hacia AWS, servidores bare metal o máquinas virtuales y viceversa con un sistema operativo compatible. Además, debe configurar AWS IAM Roles Anywhere o las activaciones híbridas de AWS Systems Manager (SSM). Usted será el responsable de administrar estos requisitos previos durante todo el ciclo de vida de los nodos híbridos.
+ Conectividad de red híbrida desde el entorno en las instalaciones hacia AWS y viceversa. 
+ Infraestructura en forma de máquinas físicas o virtuales
+ Sistema operativo compatible con nodos híbridos
+ Proveedor de credenciales de IAM en las instalaciones configurado

![\[Conectividad de red de nodos híbridos.\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/hybrid-prereq-diagram.png)


## Conectividad de red híbrida
<a name="hybrid-nodes-prereqs-connect"></a>

La comunicación entre el plano de control de Amazon EKS y los nodos híbridos se enruta a través de la VPC y las subredes que se transmiten durante la creación del clúster, que se basa en el [mecanismo existente](https://aws.github.io/aws-eks-best-practices/networking/subnets/) en Amazon EKS para la conexión en red del plano de control a los nodos. Existen varias [opciones documentadas](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html) disponibles para conectar el entorno en las instalaciones con la VPC, como AWS Site-to-Site VPN, AWS Direct Connect o una conexión de VPN propia. Consulte las guías del usuario de [AWS Site-to-Site VPN y](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) para obtener más información sobre cómo usar esas soluciones para la conexión de red híbrida.

Para disfrutar de una experiencia óptima, recomendamos una conectividad de red fiable de al menos 100 Mbps y un máximo de 200 ms de latencia de ida y vuelta para la conexión de los nodos híbridos a la región de AWS. Esta es una guía general que se adapta a la mayoría de los casos de uso, pero no es un requisito estricto. Los requisitos de ancho de banda y latencia pueden variar en función de la cantidad de nodos híbridos y de las características de la carga de trabajo, como el tamaño de la imagen de la aplicación, la elasticidad de la aplicación, las configuraciones de supervisión y registro, y las dependencias de la aplicación para acceder a datos almacenados en otros servicios de AWS. Recomendamos que realice pruebas con aplicaciones y entornos propios antes de la implementación en la fase de producción con el fin de comprobar que la configuración de red cumple los requisitos de las cargas de trabajo.

## Configuración de red en las instalaciones
<a name="hybrid-nodes-prereqs-onprem"></a>

Debe habilitar el acceso de red entrante desde el plano de control de Amazon EKS al entorno en las instalaciones para permitir que el plano de control de Amazon EKS se comunique con el `kubelet` que se ejecuta en los nodos híbridos y, opcionalmente, con los webhooks que se ejecutan en los nodos híbridos. Además, debe habilitar el acceso de red saliente para que los nodos híbridos y los componentes que se ejecutan en estos se puedan comunicar con el plano de control de Amazon EKS. Puede configurar esta comunicación para que permanezca completamente privada a AWS Direct Connect, AWS Site-to-Site VPN o a la conexión de VPN propia.

Los rangos de enrutamiento entre dominios sin clases (CIDR) que se utilizan para las redes de nodos y pods en las instalaciones deben emplear rangos de direcciones IPv4 RFC-1918 o CGNAT. El enrutador en las instalaciones debe estar configurado con rutas a los nodos y, opcionalmente, a los pods en las instalaciones. Consulte [Configuración de redes en las instalaciones](hybrid-nodes-networking.md#hybrid-nodes-networking-on-prem) para obtener más información sobre los requisitos de red en las instalaciones, incluida la lista completa de puertos y protocolos necesarios que deben habilitarse en el firewall y en el entorno local.

## Configuración del clúster de EKS
<a name="hybrid-nodes-prereqs-cluster"></a>

Para minimizar la latencia, le recomendamos crear el clúster de Amazon EKS en la región de AWS más cercana al entorno en las instalaciones o periférico. Los CIDR de nodos y pods en las instalaciones, durante la creación del clúster de Amazon EKS, se transfieren a través de dos campos de la API: `RemoteNodeNetwork` y `RemotePodNetwork`. Es posible que necesite hablar con el equipo de redes en las instalaciones para identificar los CIDR de nodos y pods en las instalaciones. El CIDR de nodos se asigna desde la red en las instalaciones y el CIDR de pods se asigna desde la interfaz de red del contenedor (CNI) si se utiliza una red superpuesta para la CNI. Cilium y Calico utilizan redes superpuestas de forma predeterminada.

Los CIDR de nodos y pods en las instalaciones que configura mediante los campos `RemoteNodeNetwork` y `RemotePodNetwork` se utilizan para configurar el plano de control de Amazon EKS a fin de dirigir el tráfico a través de la VPC al `kubelet` y los pods que se ejecutan en los nodos híbridos. Los CIDR de nodos y pods en las instalaciones no se pueden superponer entre sí, con el CIDR de VPC que se transmite durante la creación del clúster ni con la configuración de IPv4 de servicio correspondiente al clúster de Amazon EKS. Además, los CIDR de los pods deben ser exclusivos de cada clúster de EKS para que el enrutador en las instalaciones pueda enrutar el tráfico.

Recomendamos utilizar acceso mediante un punto de conexión público o privado para el punto de conexión del servidor de la API de Kubernetes en Amazon EKS. Si elige “Público y privado”, el punto de conexión del servidor de la API de Kubernetes de Amazon EKS siempre se resolverá en las IP públicas de los nodos híbridos que se ejecutan fuera de la VPC, lo que puede impedir que los nodos híbridos se unan al clúster. Cuando utiliza el acceso de punto de conexión público, el punto de conexión del servidor de la API de Kubernetes se resuelve en direcciones IP públicas y la comunicación desde los nodos híbridos al plano de control de Amazon EKS se enrutará a través de Internet. Cuando elige el acceso de punto de conexión privado, el punto de conexión del servidor de la API de Kubernetes se resuelve en direcciones IP privadas y la comunicación desde los nodos híbridos hacia el plano de control de Amazon EKS se enruta a través del enlace de conectividad privada, que en la mayoría de los casos es AWS Direct Connect o AWS Site-to-Site VPN.

## Configuración de la VPC
<a name="hybrid-nodes-prereqs-vpc"></a>

Debe configurar la VPC que se transmite durante la creación del clúster de Amazon EKS con rutas en su tabla de enrutamiento para las redes de los nodos y, opcionalmente, de los pods en las instalaciones, mediante la puerta de enlace privada virtual (VGW) o puerta de enlace de tránsito (TGW) como destino. A continuación se muestra un ejemplo. Sustituya `REMOTE_NODE_CIDR` y `REMOTE_POD_CIDR` por los valores de la red en las instalaciones.


| Destino | Objetivo | Descripción | 
| --- | --- | --- | 
|  10.226.0.0/16  |  local  |  Tráfico local a las rutas de la VPC dentro de la VPC  | 
|  REMOTE\$1NODE\$1CIDR  |  tgw-abcdef123456  |  El CIDR del nodo en las instalaciones dirige el tráfico a la puerta de enlace de tránsito  | 
|  REMODE\$1POD\$1CIDR  |  tgw-abcdef123456  |  El CIDR del pod en las instalaciones dirige el tráfico a la puerta de enlace de tránsito  | 

## Configuración del grupo de seguridad
<a name="hybrid-nodes-prereqs-sg"></a>

Al crear un clúster, Amazon EKS crea un grupo de seguridad denominado `eks-cluster-sg-<cluster-name>-<uniqueID>`. No puede modificar las reglas de entrada de este grupo de seguridad de clúster, pero puede restringir las reglas de salida. Debe agregar un grupo de seguridad adicional al clúster para permitir que el kubelet y, opcionalmente, los webhooks que se ejecutan en los nodos híbridos contacten al plano de control de Amazon EKS. Las reglas de entrada requeridas para este grupo de seguridad adicional se muestran a continuación. Sustituya `REMOTE_NODE_CIDR` y `REMOTE_POD_CIDR` por los valores de la red en las instalaciones.


| Nombre | ID de regla del grupo de seguridad | Versión de IP | Tipo | Protocolo | Intervalo de puertos | Origen | 
| --- | --- | --- | --- | --- | --- | --- | 
|  Nodo en las instalaciones entrante  |  sgr-abcdef123456  |  IPv4  |  HTTPS  |  TCP  |  443  |  REMOTE\$1NODE\$1CIDR  | 
|  Pod en las instalaciones entrante  |  sgr-abcdef654321  |  IPv4  |  HTTPS  |  TCP  |  443  |  REMOTE\$1POD\$1CIDR  | 

## Infraestructura
<a name="hybrid-nodes-prereqs-infra"></a>

Debe tener servidores bare metal o máquinas virtuales disponibles para su uso como nodos híbridos. Los nodos híbridos son independientes de la infraestructura subyacente y admiten arquitecturas x86 y ARM. El servicio de Nodos Híbridos de Amazon EKS adopta un enfoque de “use su propia infraestructura”, donde usted tiene la responsabilidad de aprovisionar y administrar los servidores bare metal o las máquinas virtuales que emplea para los nodos híbridos. Si bien no existe un requisito de recursos mínimos estricto, le recomendamos utilizar hosts con al menos 1 CPU virtual y 1 GiB de RAM para los nodos híbridos.

## Sistema operativo
<a name="hybrid-nodes-prereqs-os"></a>

Bottlerocket, Amazon Linux 2023 (AL2023), Ubuntu y RHEL se validan de forma continua para su uso como sistema operativo de nodo para los nodos híbridos. Bottlerocket es compatible únicamente con AWS en los entornos VMware vSphere. Los planes de AWS Support no cubren AL2023 cuando se ejecuta fuera de Amazon EC2. AL2023 solo se puede utilizar en entornos virtualizados en las instalaciones. Consulte la [Guía del usuario de Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/outside-ec2.html) para obtener más información. AWS admite la integración de nodos híbridos con los sistemas operativos Ubuntu y RHEL, pero no proporciona soporte para los sistemas operativos en sí.

Usted es responsable del aprovisionamiento y la administración del sistema operativo. Al probar nodos híbridos por primera vez, lo más sencillo es ejecutar la CLI de Nodos híbridos de Amazon EKS (`nodeadm`) en un host ya aprovisionado. En el caso de implementaciones en producción, se recomienda incluir `nodeadm` en las imágenes base del sistema operativo, configurado para ejecutarse como un servicio de systemd, de modo que los hosts se unan automáticamente a los clústeres de Amazon EKS al iniciar.

## Proveedor de credenciales de IAM en las instalaciones
<a name="hybrid-nodes-prereqs-iam"></a>

Los Nodos híbridos de Amazon EKS utilizan credenciales de IAM temporales aprovisionadas por activaciones híbridas de AWS SSM o AWS IAM Roles Anywhere para autenticarse con el clúster de Amazon EKS. Debe usar activaciones híbridas de AWS SSM o AWS IAM Roles Anywhere con la CLI (`nodeadm`) de los Nodos híbridos de Amazon EKS. Le recomendamos utilizar las activaciones híbridas de AWS SSM si no dispone de una infraestructura de clave pública (PKI) existente con una entidad de certificación (CA) y certificados para los entornos en las instalaciones. Si ya dispone de PKI y certificados en las instalaciones, utilice AWS IAM Roles Anywhere.

De manera similar a [Rol de IAM de nodo de Amazon EKS](create-node-role.md) para los nodos que se ejecutan en Amazon EC2, deberá crear un rol de IAM para los nodos híbridos con los permisos necesarios para unir nodos híbridos a los clústeres de Amazon EKS. Si utiliza AWS IAM Roles Anywhere, configure una política de confianza que permita a AWS IAM Roles Anywhere asumir el rol de IAM de nodos híbridos y configurar el perfil de AWS IAM Roles Anywhere con el rol de IAM de nodos híbridos como rol asumible. Si utiliza AWS SSM, configure una política de confianza que permita a AWS SSM asumir el rol de IAM de nodos híbridos y crear la activación híbrida con el rol de IAM de nodos híbridos. Consulte [Cómo preparar las credenciales para los nodos híbridos](hybrid-nodes-creds.md) para averiguar cómo crear el rol de IAM de nodos híbridos con los permisos necesarios.

# Cómo preparar las redes para los nodos híbridos
<a name="hybrid-nodes-networking"></a>

En este tema se ofrece información general sobre la configuración de red que se debe establecer antes de crear el clúster de Amazon EKS y conectar los nodos híbridos. En esta guía se presupone que ha cumplido los requisitos previos para la conectividad de red híbrida mediante [AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html), [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) o una solución de VPN propia.

![\[Conectividad de red de nodos híbridos.\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/hybrid-prereq-diagram.png)


## Configuración de redes en las instalaciones
<a name="hybrid-nodes-networking-on-prem"></a>

### Requisitos mínimos de red
<a name="hybrid-nodes-networking-min-reqs"></a>

Para disfrutar de una experiencia óptima, recomendamos una conectividad de red fiable de al menos 100 Mbps y un máximo de 200 ms de latencia de ida y vuelta para la conexión de los nodos híbridos a la región de AWS. Esta es una guía general que se adapta a la mayoría de los casos de uso, pero no es un requisito estricto. Los requisitos de ancho de banda y latencia pueden variar en función de la cantidad de nodos híbridos y de las características de la carga de trabajo, como el tamaño de la imagen de la aplicación, la elasticidad de la aplicación, las configuraciones de supervisión y registro, y las dependencias de la aplicación para acceder a datos almacenados en otros servicios de AWS. Recomendamos que realice pruebas con aplicaciones y entornos propios antes de la implementación en la fase de producción con el fin de comprobar que la configuración de red cumple los requisitos de las cargas de trabajo.

### CIDR de nodos y pods en las instalaciones
<a name="hybrid-nodes-networking-on-prem-cidrs"></a>

Identifique los CIDR de nodos y pods que utilizará para los nodos híbridos y las cargas de trabajo que se ejecutan en estos. El CIDR de nodos se asigna desde la red en las instalaciones y el CIDR de pods se asigna desde la interfaz de red del contenedor (CNI) si se utiliza una red superpuesta para la CNI. Transmite los CIDR de los nodos en las instalaciones y los CIDR de los pods como entradas al crear su clúster de EKS con los campos `RemoteNodeNetwork` y `RemotePodNetwork`. Los CIDR de los nodos en las instalaciones deben ser enrutables en su red local. Consulte la siguiente sección para obtener información sobre la enrutabilidad del CIDR del pod en las instalaciones.

Los bloques de CIDR del pod y del nodo en las instalaciones deben cumplir los siguientes requisitos:

1. Estar dentro de uno de los siguientes rangos `IPv4` RFC-1918: `10.0.0.0/8`, `172.16.0.0/12` o `192.168.0.0/16`, o dentro del rango CGNAT definido por RFC 6598: `100.64.0.0/10`.

1. Que no se solapen entre sí, el CIDR de la VPC del clúster de EKS o el CIDR `IPv4` del servicio de Kubernetes.

### Enrutamiento de red del pod en las instalaciones
<a name="hybrid-nodes-networking-on-prem-pod-routing"></a>

Si utiliza los nodos híbridos de EKS, generalmente recomendamos que configure los CIDR del pod en las instalaciones de manera tal que se puedan enrutar en su red local para permitir la comunicación y la funcionalidad completas del clúster entre los entornos de la nube y los que están en las instalaciones.

 **Redes de pods enrutables** 

Si puede configurar la red de los pods para que se pueda enrutar en su red en las instalaciones, siga las instrucciones que se indican a continuación.

1. Configure el campo `RemotePodNetwork` para su clúster de EKS con el CIDR del pod en las instalaciones, sus tablas de enrutamiento de VPC con el CIDR del pod en las instalaciones y el grupo de seguridad de su clúster de EKS con el CIDR del pod en las instalaciones.

1. Existen varias técnicas que puede utilizar para hacer que el CIDR de los pods en las instalaciones sea enrutable en la red en las instalaciones, como el protocolo de puerta de enlace fronteriza (BGP), rutas estáticas u otras soluciones de enrutamiento personalizadas. BGP es la solución recomendada, ya que es más escalable y fácil de administrar que las soluciones alternativas que requieren configuración manual o personalizada de rutas. AWS admite las capacidades de BGP de Cilium y Calico para anunciar los CIDR de los pods. Consulte [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md) y [CIDR de pod remoto enrutable](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-pod-cidrs) para obtener más información.

1. Los webhooks se pueden ejecutar en nodos híbridos, ya que el plano de control de EKS puede comunicarse con las direcciones IP del pod asignadas a los webhooks.

1. Las cargas de trabajo que se ejecutan en los nodos de la nube pueden comunicarse directamente con las cargas de trabajo que se ejecutan en los nodos híbridos del mismo clúster de EKS.

1. Otros servicios de AWS, como los equilibradores de carga de aplicación de AWS y Amazon Managed Service para Prometheus, pueden comunicarse con las cargas de trabajo que se ejecutan en nodos híbridos para equilibrar el tráfico de red y analizar las métricas de los pods.

 **Redes de pods no enrutables** 

Si *no* puede hacer que las redes de los pods se enruten en la red en las instalaciones, siga las instrucciones que se indican a continuación.

1. Los webhooks no se pueden ejecutar en nodos híbridos, ya que requieren conectividad desde el plano de control de EKS a las direcciones IP de los pods asignadas a los webhooks. En este caso, le recomendamos que ejecute los webhooks en los nodos de la nube del mismo clúster de EKS que los nodos híbridos; consulte [Configuración de webhooks para nodos híbridos](hybrid-nodes-webhooks.md) para obtener más información.

1. Las cargas de trabajo que se ejecutan en los nodos de la nube no pueden comunicarse directamente con las cargas de trabajo que se ejecutan en los nodos híbridos cuando se utiliza la CNI de la VPC para los nodos de la nube y Cilium o Calico para los nodos híbridos.

1. Utilice la distribución de tráfico del servicio para mantener el tráfico local en la zona de origen. Para obtener más información sobre la distribución de tráfico del servicio, consulte [Configurar la distribución de tráfico del servicio](hybrid-nodes-webhooks.md#hybrid-nodes-mixed-service-traffic-distribution).

1. Configure su CNI para que utilice la máscara de salida o la traducción de direcciones de red (NAT) para el tráfico de los pods cuando salga de los hosts en las instalaciones. Esta opción está habilitada de forma predeterminada en Cilium. Calico requiere que `natOutgoing` se establezca en `true`.

1. Otros servicios de AWS, como los equilibradores de carga de aplicación de AWS y Amazon Managed Service para Prometheus, no pueden comunicarse con las cargas de trabajo que se ejecutan en nodos híbridos.

### Se requiere acceso durante la instalación y actualización de nodos híbridos
<a name="hybrid-nodes-networking-access-reqs"></a>

Debe tener acceso a los siguientes dominios durante el proceso de instalación en el que instala las dependencias de los nodos híbridos en los hosts. Este proceso se puede realizar una vez al crear las imágenes del sistema operativo o en cada host en tiempo de ejecución. Esto incluye la instalación inicial y cuando se actualiza la versión de Kubernetes de los nodos híbridos.

Algunos paquetes se instalan mediante el administrador de paquetes predeterminado del sistema operativo. En AL2023 y RHEL, el comando `yum` se usa para instalar `containerd`, `ca-certificates`, `iptables` y `amazon-ssm-agent`. En Ubuntu, `apt` se usa para instalar `containerd`, `ca-certificates` y `iptables`, mientras que `snap` se usa para instalar `amazon-ssm-agent`.


| Componente | URL | Protocolo | Puerto | 
| --- | --- | --- | --- | 
|  Artefactos de nodos de EKS (S3)  |  https://hybrid-assets.eks.amazonaws.com  |  HTTPS  |  443  | 
|   [Puntos de conexión de servicio de EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html)   |  https://eks.*region*.amazonaws.com  |  HTTPS  |  443  | 
|   [Puntos de conexión de servicio de ECR](https://docs.aws.amazon.com/general/latest/gr/ecr.html)   |  https://api.ecr.*region*.amazonaws.com  |  HTTPS  |  443  | 
|  Puntos de conexión de ECR de EKS  |  Consulte [Visualización de los registros de imágenes de contenedores de Amazon para los complementos de Amazon EKS](add-ons-images.md) para conocer los puntos de conexión regionales.  |  HTTPS  |  443  | 
|  Punto de conexión binario SSM 1   |  https://amazon-ssm-*region*.s3.*region*.amazonaws.com  |  HTTPS  |  443  | 
|   [Punto de conexión de servicio de SSM](https://docs.aws.amazon.com/general/latest/gr/ssm.html) 1   |  https://ssm.*region*.amazonaws.com  |  HTTPS  |  443  | 
|  Punto de conexión binario de IAM Anywhere 2   |  https://rolesanywhere.amazonaws.com  |  HTTPS  |  443  | 
|   [Punto de conexión de servicio de IAM Anywhere](https://docs.aws.amazon.com/general/latest/gr/rolesanywhere.html) 2   |  https://rolesanywhere.*region*.amazonaws.com  |  HTTPS  |  443  | 
|  Puntos de conexión del administrador de paquetes del sistema operativo  |  Los puntos de conexión del repositorio de paquetes son específicos del sistema operativo y pueden variar según la región geográfica.  |  HTTPS  |  443  | 

**nota**  
 1 El acceso a los puntos de conexión de AWS SSM solo es necesario si utiliza activaciones híbridas de AWS SSM para el proveedor de credenciales de IAM en las instalaciones.  
 2 El acceso a los puntos de conexión de AWS IAM solo es necesario si utiliza AWS IAM Roles Anywhere como proveedor de credenciales de IAM en las instalaciones.

### Acceso necesario para las operaciones de clúster en curso
<a name="hybrid-nodes-networking-access-reqs-ongoing"></a>

El siguiente acceso a la red para el firewall en las instalaciones es necesario para las operaciones de clúster en curso.

**importante**  
Según el CNI que elija, deberá configurar reglas de acceso a la red adicionales para los puertos del CNI. Consulte la documentación de [Cilium](https://docs.cilium.io/en/stable/operations/system_requirements/#firewall-rules) y la documentación de [Calico](https://docs.tigera.io/calico/latest/getting-started/kubernetes/requirements#network-requirements) para obtener más información.


| Tipo | Protocolo | Dirección | Puerto | Origen | Destino | Uso | 
| --- | --- | --- | --- | --- | --- | --- | 
|  HTTPS  |  TCP  |  Salida  |  443  |  CIDR de nodos remotos  |  IP de clúster de EKS 1   |  Servidor de API de kubelet a Kubernetes  | 
|  HTTPS  |  TCP  |  Salida  |  443  |  CIDR de pods remotos  |  IP de clúster de EKS 1   |  Pod a servidor de API de Kubernetes  | 
|  HTTPS  |  TCP  |  Salida  |  443  |  CIDR de nodos remotos  |   [Punto de conexión de servicio de SSM](https://docs.aws.amazon.com/general/latest/gr/ssm.html)   |  Actualización de credenciales de activaciones híbridas de SSM y señales de SSM cada 5 minutos  | 
|  HTTPS  |  TCP  |  Salida  |  443  |  CIDR de nodos remotos  |   [Punto de conexión del servicio IAM Anywhere](https://docs.aws.amazon.com/general/latest/gr/rolesanywhere.html)   |  Actualización de credenciales de IAM Roles Anywhere  | 
|  HTTPS  |  TCP  |  Salida  |  443  |  CIDR de pods remotos  |   [Punto de conexión regional de STS](https://docs.aws.amazon.com/general/latest/gr/sts.html)   |  Pod a punto de conexión de STS. Obligatorio solo para IRSA  | 
|  HTTPS  |  TCP  |  Salida  |  443  |  CIDR de nodos remotos  |   [Punto de conexión del servicio Auth de Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html)   |  Nodo a punto de conexión de autenticación de Amazon EKS. Obligatorio solo para Pod Identity de Amazon EKS  | 
|  HTTPS  |  TCP  |  Entrada  |  10250  |  IP de clúster de EKS 1   |  CIDR de nodos remotos  |  Servidor de la API de Kubernetes a kubelet  | 
|  HTTPS  |  TCP  |  Entrada  |  Puertos de webhook  |  IP de clúster de EKS 1   |  CIDR de pods remotos  |  Servidor de la API de Kubernetes a webhooks  | 
|  HTTPS  |  TCP,UDP  |  Entrada,Salida  |  53  |  CIDR de pods remotos  |  CIDR de pods remotos  |  Pod a CoreDNS. Si ejecuta al menos una réplica de CoreDNS en la nube, debe permitir el tráfico DNS a la VPC donde se ejecuta CoreDNS.  | 
|  Definido por el usuario  |  Definido por el usuario  |  Entrada,Salida  |  Puertos de la aplicación  |  CIDR de pods remotos  |  CIDR de pods remotos  |  Pod a pod  | 

**nota**  
 1 Las direcciones IP del clúster de EKS. Consulte la siguiente sección sobre las interfaces de red elásticas de Amazon EKS.

### Interfaces de red de Amazon EKS
<a name="hybrid-nodes-networking-eks-network-interfaces"></a>

Amazon EKS asocia interfaces de red a las subredes de la VPC que se transmiten durante la creación del clúster para permitir la comunicación entre el plano de control de EKS y la VPC. Las interfaces de red que Amazon EKS crea se pueden encontrar tras la creación del clúster en la consola de Amazon EC2 o con la AWS CLI. Las interfaces de red originales se eliminan y se crean nuevas interfaces de red cuando se aplican cambios en el clúster de EKS, como actualizaciones de la versión de Kubernetes. Para restringir el rango de IP de las interfaces de red de Amazon EKS, es posible utilizar tamaños de subred limitados para las subredes que se transmiten durante la creación del clúster, lo que facilita la configuración del firewall en las instalaciones para permitir la conectividad entrante/saliente a este conjunto de IP conocidas y limitadas. Para controlar en qué subredes se crean las interfaces de red, puede limitar la cantidad de subredes que especifica al crear un clúster o puede actualizar las subredes después de crear el clúster.

Las interfaces de red aprovisionadas por Amazon EKS tienen una descripción del formato `Amazon EKS your-cluster-name `. Consulte el ejemplo que aparece a continuación para ver un comando de la AWS CLI que se puede utilizar para buscar las direcciones IP de las interfaces de red que Amazon EKS aprovisiona. Sustituya `VPC_ID` por el ID de la VPC que se transmite durante la creación del clúster.

```
aws ec2 describe-network-interfaces \
--query 'NetworkInterfaces[?(VpcId == VPC_ID && contains(Description,Amazon EKS))].PrivateIpAddress'
```

## AWS VPC y configuración de subredes
<a name="hybrid-nodes-networking-vpc"></a>

Los [requisitos de VPC y subredes existentes](network-reqs.md) para Amazon EKS se aplican a los clústeres con nodos híbridos. Además, el CIDR de la VPC no se puede solapar con los CIDR de los nodos y pods en las instalaciones. Debe configurar rutas en la tabla de enrutamiento de la VPC para el CIDR de nodos en las instalaciones y, opcionalmente, el CIDR de pods. Estas rutas se deben configurar para dirigir el tráfico a la puerta de enlace que se utiliza para la conectividad de la red híbrida, que comúnmente es una puerta de enlace privada virtual (VGW) o una puerta de enlace de tránsito (TGW). Si está utiliza TGW o VGW para conectar la VPC con el entorno en las instalaciones, debe crear una conexión TGW o VGW para la VPC. La VPC debe tener un nombre de host DNS y admitir la resolución DNS.

Para los siguientes pasos, se utiliza la AWS CLI. También puede crear estos recursos en la Consola de administración de AWS o con otras interfaces, como AWS CloudFormation, AWS CDK o Terraform.

### Paso 1: Creación de la VPC
<a name="_step_1_create_vpc"></a>

1. Ejecute el siguiente comando para crear una VPC. Sustituya VPC\$1CIDR por uno de los siguientes rangos IPv4 CIDR: RFC 1918 (privado), CGNAT (RFC 6598) o no RFC 1918/no CGNAT (público) (por ejemplo, 10.0.0.0/16). Nota: La resolución de DNS, que es un requisito de EKS, está habilitada para la VPC de forma predeterminada.

   ```
   aws ec2 create-vpc --cidr-block VPC_CIDR
   ```

1. Habilite los nombres de host de DNS para la VPC. Nota: La resolución de DNS está habilitada para la VPC de forma predeterminada. Sustituya `VPC_ID` por el ID de la VPC que creó en el paso anterior.

   ```
   aws ec2 modify-vpc-attribute --vpc-id VPC_ID --enable-dns-hostnames
   ```

### Paso 2: Creación de subredes
<a name="_step_2_create_subnets"></a>

Cree al menos 2 subredes. Amazon EKS usa estas subredes para las interfaces de red del clúster. Para obtener más información, consulte [Requisitos y consideraciones de las subredes](network-reqs.md#network-requirements-subnets).

1. Puede buscar las zonas de disponibilidad de una región de AWS con el siguiente comando. Reemplace `us-west-2` por la región.

   ```
   aws ec2 describe-availability-zones \
        --query 'AvailabilityZones[?(RegionName == us-west-2)].ZoneName'
   ```

1. Cree una subred. Sustituya `VPC_ID` por el ID de la VPC. Sustituya `SUBNET_CIDR` por el bloque de CIDR de la subred (por ejemplo, 10.0.1.0/24). Sustituya `AZ` por la zona de disponibilidad en la que se creará la subred (por ejemplo, us-west-2a). Las subredes que cree deben estar en al menos dos zonas de disponibilidad diferentes.

   ```
   aws ec2 create-subnet \
       --vpc-id VPC_ID \
       --cidr-block SUBNET_CIDR \
       --availability-zone AZ
   ```

### (Opcional) Paso 3: adjunción de una VPC con la puerta de enlace de tránsito (TGW) de Amazon VPC o una puerta de enlace privada virtual (VGW) de AWS Direct Connect
<a name="optional_step_3_attach_vpc_with_amazon_vpc_transit_gateway_tgw_or_shared_aws_direct_connect_virtual_private_gateway_vgw"></a>

Si utiliza una TGW o VGW, conecte la VPC a la TGW o VGW. Para obtener más información, consulte [Amazon VPC attachments in Amazon VPC Transit Gateways](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html) o [AWS Direct Connect virtual private gateway associations](https://docs.aws.amazon.com/vpn/latest/s2svpn/how_it_works.html#VPNGateway).

 **Transit Gateway** 

Ejecute el siguiente comando para conectar una puerta de enlace de tránsito. Sustituya `VPC_ID` por el ID de la VPC. Sustituya `SUBNET_ID1` y `SUBNET_ID2` por el ID de las subredes que creó en el paso anterior. Sustituya `TGW_ID` por el ID de la TGW.

```
aws ec2 create-transit-gateway-vpc-attachment \
    --vpc-id VPC_ID \
    --subnet-ids SUBNET_ID1 SUBNET_ID2 \
    --transit-gateway-id TGW_ID
```

 **Puerta de enlace privada virtual** 

Ejecute el siguiente comando para conectar una puerta de enlace de tránsito. Sustituya `VPN_ID` por el ID de la VGW. Sustituya `VPC_ID` por el ID de la VPC.

```
aws ec2 attach-vpn-gateway \
    --vpn-gateway-id VPN_ID \
    --vpc-id VPC_ID
```

### (Opcional) Paso 4: Creación de una tabla de enrutamiento
<a name="_optional_step_4_create_route_table"></a>

Puede modificar la tabla de enrutamiento principal de la VPC o puede crear una tabla de enrutamiento personalizada. En los siguientes pasos, se crea una tabla de enrutamiento personalizada con las rutas a los CIDR de nodos y pods en las instalaciones. Para obtener más información, consulte [Tablas de enrutamiento de subredes](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-route-tables.html). Sustituya `VPC_ID` por el ID de la VPC.

```
aws ec2 create-route-table --vpc-id VPC_ID
```

### Paso 5: Creación de rutas para nodos y pods en las instalaciones
<a name="_step_5_create_routes_for_on_premises_nodes_and_pods"></a>

Cree rutas en la tabla de enrutamiento para cada uno de los nodos remotos en las instalaciones. Puede modificar la tabla de enrutamiento principal de la VPC o utilizar la tabla de enrutamiento personalizada que creó en el paso anterior.

En los ejemplos que aparecen a continuación se muestra cómo crear rutas para los CIDR de nodos y pods en las instalaciones. En los ejemplos, se utiliza una puerta de enlace de tránsito (TGW) para conectar la VPC con el entorno en las instalaciones. Si tiene múltiples CIDR de nodos y pods en las instalaciones, repita los pasos para cada CIDR.
+ Si utiliza una puerta de enlace de Internet o una puerta de enlace privada virtual (VGW), sustituya `--transit-gateway-id` por `--gateway-id`.
+ Sustituya `RT_ID` por el ID de la tabla de enrutamiento que creó en el paso anterior.
+ Sustituya `REMOTE_NODE_CIDR` por el rango de CIDR que utilizará para los nodos híbridos.
+ Sustituya `REMOTE_POD_CIDR` por el rango de CIDR que utilizará para los pods que se ejecutan en nodos híbridos. El rango de CIDR del pod corresponde a la configuración de la interfaz de red de contenedores (CNI), que habitualmente utiliza una red superpuesta en las instalaciones. Para obtener más información, consulte [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md).
+ Sustituya `TGW_ID` por el ID de la TGW.

 **Red de nodos remotos** 

```
aws ec2 create-route \
    --route-table-id RT_ID \
    --destination-cidr-block REMOTE_NODE_CIDR \
    --transit-gateway-id TGW_ID
```

 **Red de pods remotos** 

```
aws ec2 create-route \
    --route-table-id RT_ID \
    --destination-cidr-block REMOTE_POD_CIDR \
    --transit-gateway-id TGW_ID
```

### (Opcional) Paso 6: Asociación de las subredes a la tabla de enrutamiento
<a name="_optional_step_6_associate_subnets_with_route_table"></a>

Si creó una tabla de enrutamiento personalizada en el paso anterior, asocie cada una de las subredes que creó en el paso anterior a la tabla de enrutamiento personalizada. Si va a modificar la tabla de enrutamiento principal de la VPC, las subredes se asociarán automáticamente a la tabla de enrutamiento principal de la VPC y podrá omitir este paso.

Ejecute el siguiente comando para cada una de las subredes que creó en los pasos anteriores. Sustituya `RT_ID` por la tabla de enrutamiento que creó en el paso anterior. Sustituya `SUBNET_ID` por el ID de una subred.

```
aws ec2 associate-route-table --route-table-id RT_ID --subnet-id SUBNET_ID
```

## Configuración del grupo de seguridad del clúster
<a name="hybrid-nodes-networking-cluster-sg"></a>

El siguiente acceso para el grupo de seguridad del clúster de EKS se necesita para las operaciones de clúster en curso. Amazon EKS crea automáticamente las reglas de grupo de seguridad de **entrada** necesarias para los nodos híbridos al crear o actualizar el clúster con las redes de nodos y pods remotos configuradas. Como los grupos de seguridad permiten todo el tráfico **saliente** de forma predeterminada, Amazon EKS no modifica automáticamente las reglas de **salida** del grupo de seguridad del clúster para los nodos híbridos. Si desea personalizar el grupo de seguridad del clúster, puede limitar el tráfico a las reglas de la siguiente tabla.


| Tipo | Protocolo | Dirección | Puerto | Origen | Destino | Uso | 
| --- | --- | --- | --- | --- | --- | --- | 
|  HTTPS  |  TCP  |  Entrada  |  443  |  CIDR de nodos remotos  |  N/A  |  Servidor de la API de Kubelet a Kubernetes  | 
|  HTTPS  |  TCP  |  Entrada  |  443  |  CIDR de pods remotos  |  N/A  |  Pods que requieren acceso al servidor de la API de K8s cuando el CNI no utiliza NAT para el tráfico de pods.  | 
|  HTTPS  |  TCP  |  Salida  |  10250  |  N/A  |  CIDR de nodos remotos  |  Servidor de la API de Kubernetes a Kubelet  | 
|  HTTPS  |  TCP  |  Salida  |  Puertos de webhook  |  N/A  |  CIDR de pods remotos  |  Servidor de la API de Kubernetes a webhook (si se ejecutan webhooks en nodos híbridos)  | 

**importante**  
 **Límites de reglas de grupos de seguridad**: los grupos de seguridad de Amazon EC2 tienen un máximo de 60 reglas de entrada de forma predeterminada. Es posible que las reglas de entrada de los grupos de seguridad no se apliquen si el grupo de seguridad del clúster se acerca a este límite. En este caso, puede que sea necesario agregar manualmente las reglas de entrada que faltan.  
 **Responsabilidad de limpiar el CIDR**: si se eliminan las redes de nodos o pods remotos de los clústeres de EKS, EKS no elimina automáticamente las reglas de los grupos de seguridad correspondientes. Usted tiene la responsabilidad de eliminar manualmente las redes de nodos o pods remotos que no se utilicen de las reglas de su grupo de seguridad.

Para obtener más información acerca del grupo de seguridad de clúster que crea Amazon EKS, consulte [Revisión de requisitos de grupos de seguridad de Amazon EKS para clústeres](sec-group-reqs.md).

### (Opcional) Configuración manual del grupo de seguridad
<a name="_optional_manual_security_group_configuration"></a>

Si necesita crear grupos de seguridad adicionales o modificar las reglas que se crean automáticamente, puede utilizar los siguientes comandos como referencia. De forma predeterminada, el siguiente comando crea un grupo de seguridad que permite todos los accesos salientes. Puede restringir el acceso saliente para incluir únicamente las reglas indicadas anteriormente. Si considera limitar las reglas de salida, recomendamos que pruebe exhaustivamente la conectividad de todas las aplicaciones y pods antes de aplicar las reglas modificadas a un clúster en fase de producción.
+ En el primer comando, sustituya `SG_NAME` por el nombre del grupo de seguridad
+ En el primer comando, sustituya `VPC_ID` por el ID de la VPC que creó en el paso anterior
+ En el segundo comando, sustituya `SG_ID` por el ID del grupo de seguridad que creó en el primer comando
+ En el segundo comando, sustituya `REMOTE_NODE_CIDR` y `REMOTE_POD_CIDR` por los valores de los nodos híbridos y la red en las instalaciones.

```
aws ec2 create-security-group \
    --group-name SG_NAME \
    --description "security group for hybrid nodes" \
    --vpc-id VPC_ID
```

```
aws ec2 authorize-security-group-ingress \
    --group-id SG_ID \
    --ip-permissions '[{"IpProtocol": "tcp", "FromPort": 443, "ToPort": 443, "IpRanges": [{"CidrIp": "REMOTE_NODE_CIDR"}, {"CidrIp": "REMOTE_POD_CIDR"}]}]'
```

# Cómo preparar el sistema operativo para los nodos híbridos
<a name="hybrid-nodes-os"></a>

Bottlerocket, Amazon Linux 2023 (AL2023), Ubuntu y RHEL se validan de forma continua para su uso como sistema operativo de nodo para los nodos híbridos. Bottlerocket es compatible únicamente con AWS en los entornos VMware vSphere. Los planes de AWS Support no cubren AL2023 cuando se ejecuta fuera de Amazon EC2. AL2023 solo se puede utilizar en entornos virtualizados en las instalaciones. Consulte la [Guía del usuario de Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/outside-ec2.html) para obtener más información. AWS admite la integración de nodos híbridos con los sistemas operativos Ubuntu y RHEL, pero no proporciona soporte para los sistemas operativos en sí.

Usted es responsable del aprovisionamiento y la administración del sistema operativo. Al probar nodos híbridos por primera vez, lo más sencillo es ejecutar la CLI de Nodos híbridos de Amazon EKS (`nodeadm`) en un host ya aprovisionado. En el caso de implementaciones en producción, se recomienda incluir `nodeadm` en las imágenes del sistema operativo, configurado para ejecutarse como un servicio de systemd, de modo que los hosts se unan automáticamente a los clústeres de Amazon EKS al iniciar. Si usa Bottlerocket como sistema operativo de nodo en vSphere, no es necesario utilizar `nodeadm`, ya que Bottlerocket incluye las dependencias necesarias para nodos híbridos y se conectará automáticamente al clúster configurado al iniciar el host.

## Compatibilidad de versiones
<a name="_version_compatibility"></a>

La tabla que aparece a continuación representa las versiones del sistema operativo compatibles y validadas para su uso como sistema operativo de nodo para nodos híbridos. Si utiliza otras variantes o versiones del sistema operativo que no aparecen en esta tabla, la compatibilidad de los nodos híbridos con la variante o versión del sistema operativo no está cubierta por AWS Support. Los nodos híbridos son independientes de la infraestructura subyacente y admiten arquitecturas x86 y ARM.


| Sistema operativo | Versiones | 
| --- | --- | 
|  Amazon Linux  |  Amazon Linux 2023 (AL2023)  | 
|  Bottlerocket  |  Variantes de VMware desde la v1.37.0 en adelante que ejecutan Kubernetes v1.28 o superior  | 
|  Ubuntu  |  Ubuntu 20.04, Ubuntu 22.04, Ubuntu 24.04  | 
|  Red Hat Enterprise Linux  |  RHEL 8, RHEL 9  | 

## Consideraciones de los sistemas operativos
<a name="_operating_system_considerations"></a>

### General
<a name="_general"></a>
+ La CLI (`nodeadm`) de los Nodos híbridos de Amazon EKS se puede utilizar para simplificar la instalación y configuración de los componentes y dependencias de los nodos híbridos. Puede ejecutar el proceso `nodeadm install` durante las canalizaciones de creación de imágenes del sistema operativo o en tiempo de ejecución en cada host en las instalaciones. Para más información sobre los componentes que `nodeadm` instala, consulte el [Referencia de `nodeadm` de nodos híbridos](hybrid-nodes-nodeadm.md).
+ Si utiliza un proxy en el entorno en las instalaciones para acceder a Internet, se requiere una configuración adicional del sistema operativo para que los procesos de instalación y actualización configuren el administrador de paquetes para utilizar el proxy. Para obtener instrucciones, consulte [Configuración del proxy para nodos híbridos](hybrid-nodes-proxy.md).

### Bottlerocket
<a name="_bottlerocket"></a>
+ Los pasos y herramientas para conectar un nodo de Bottlerocket son diferentes de los requeridos para otros sistemas operativos y se abordan por separado en [Conexión de nodos híbridos con Bottlerocket](hybrid-nodes-bottlerocket.md), en lugar de los pasos indicados en [Cómo conectar nodos híbridos](hybrid-nodes-join.md).
+ Los pasos para Bottlerocket no requieren el uso de la herramienta de interfaz de la línea de comandos (CLI) para nodos híbridos, `nodeadm`.
+ Solo se admiten las variantes de VMware de Bottlerocket a partir de la versión v1.37.0 con los Nodos híbridos de EKS. Las variantes de VMware de Bottlerocket están disponibles para las versiones v1.28 y posteriores de Kubernetes. [Otras variantes de Bottlerocket](https://bottlerocket.dev/en/os/1.36.x/concepts/variants) no son compatibles como sistema operativo de nodos híbridos. NOTA: Las variantes de VMware de Bottlerocket solo se encuentran disponibles para la arquitectura x86\$164.

### Containerd
<a name="_containerd"></a>
+ Containerd es el tiempo de ejecución de contenedores estándar de Kubernetes y es una dependencia para los nodos híbridos, así como para todos los tipos de computación de nodos de Amazon EKS. La CLI (`nodeadm`) de los Nodos Híbridos de Amazon EKS intenta instalar containerd durante el proceso `nodeadm install`. Puede configurar la instalación de containerd en tiempo de ejecución de `nodeadm install` con la opción de línea de comandos `--containerd-source`. Las opciones válidas son `none`, `distro` y `docker`. Si utiliza RHEL, `distro` no es una opción válida y puede, o bien configurar `nodeadm` para instalar la compilación containerd desde los repositorios de Docker, o instalar containerd manualmente. Cuando se usa AL2023 o Ubuntu, `nodeadm` instala containerd desde la distribución del sistema operativo de forma predeterminada. Si no quiere que nodeadm instale containerd, use la opción `--containerd-source none`.

### Ubuntu
<a name="_ubuntu"></a>
+ Si usa Ubuntu 24.04, es posible que tenga que actualizar la versión de containerd o cambiar la configuración de AppArmor para adoptar una corrección que permita que los pods se terminen correctamente. Consulte [Ubuntu \$12065423](https://bugs.launchpad.net/ubuntu/+source/containerd-app/\+bug/2065423). Se requiere un reinicio para aplicar los cambios al perfil de AppArmor. La versión más reciente de Ubuntu 24.04 tiene una versión actualizada de containerd en su administrador de paquetes con la corrección (versión 1.7.19\$1 de containerd).

### ARM
<a name="_arm"></a>
+ Si utiliza hardware de ARM, se requiere un procesador compatible con ARMv8.2 con la extensión de criptografía (ARMv8.2\$1crypto) para ejecutar la versión 1.31 o posterior del complemento kube-proxy de EKS. Todos los sistemas Raspberry Pi anteriores a Raspberry Pi 5, así como los procesadores basados en Cortex-A72, no cumplen este requisito. Como solución alternativa, puede seguir utilizando la versión 1.30 del complemento kube-proxy de EKS hasta que finalice el soporte extendido en julio de 2026 (consulte el [calendario de lanzamiento de Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) o utilice una imagen de kube-proxy personalizada ascendente).
+ El siguiente mensaje de error del registro de kube-proxy indica esta incompatibilidad:

```
Fatal glibc error: This version of Amazon Linux requires a newer ARM64 processor compliant with at least ARM architecture 8.2-a with Cryptographic extensions. On EC2 this is Graviton 2 or later.
```

## Creación de imágenes del sistema operativo
<a name="_building_operating_system_images"></a>

Amazon EKS proporciona [plantillas Packer de ejemplo](https://github.com/aws/eks-hybrid/tree/main/example/packer) que se pueden utilizar para crear imágenes del sistema operativo que incluyan `nodeadm` y lo configuren de modo que se ejecute al iniciar el host. Este proceso se recomienda para no tener que extraer las dependencias de los nodos híbridos individualmente en cada host y para automatizar el proceso de arranque de los nodos híbridos. Puede utilizar las plantillas Packer de ejemplo con una imagen ISO de Ubuntu 22.04, Ubuntu 24.04, RHEL 8 o RHEL 9 y puede obtener imágenes con estos formatos: OVA, Qcow2 o sin procesar.

### Requisitos previos
<a name="_prerequisites"></a>

Antes de utilizar las plantillas Packer de ejemplo, debe tener instalado lo siguiente en la máquina desde la que ejecuta Packer.
+ Versión 1.11.0 o superior de Packer. Para obtener instrucciones sobre cómo instalar Packer, consulte [Instalación de Packer](https://developer.hashicorp.com/packer/tutorials/docker-get-started/get-started-install-cli) en la documentación de Packer.
+ Si se crean OVA, la versión 1.4.0 o superior del complemento VMware vSphere.
+ Si crea imágenes `Qcow2` o sin procesar, utilice la versión 1.x del complemento QEMU

### Configuración de las variables de entorno
<a name="_set_environment_variables"></a>

Antes de ejecutar la compilación de Packer, establezca las siguientes variables de entorno en la máquina desde la que ejecuta Packer.

 **General** 

Se deben establecer las siguientes variables de entorno para crear imágenes con todos los sistemas operativos y formatos de salida.


| Variable de entorno | Tipo | Descripción | 
| --- | --- | --- | 
|  PKR\$1SSH\$1PASSWORD  |  Cadena  |  Durante el aprovisionamiento, Packer utiliza las variables `ssh_username` y `ssh_password` para acceder mediante SSH a la máquina creada. Esto debe coincidir con las contraseñas utilizadas para crear el usuario inicial dentro de los archivos kickstart o user-data del SO respectivo. El valor predeterminado se establece como “builder” o “ubuntu” según el sistema operativo. Al configurar la contraseña, asegúrese de cambiarla dentro del archivo `ks.cfg` o `user-data` correspondiente de modo que coincida.  | 
|  ISO\$1URL  |  Cadena  |  URL de la ISO que se va a utilizar. Puede ser un enlace web para descargar de un servidor, o una ruta absoluta a un archivo local  | 
|  ISO\$1CHECKSUM  |  Cadena  |  Suma de comprobación asociada para la ISO suministrada.  | 
|  CREDENTIAL\$1PROVIDER  |  Cadena  |  Proveedor de credenciales para nodos híbridos. Los valores válidos son `ssm` (predeterminados) para las activaciones híbridas de SSM y `iam` para IAM Roles Anywhere  | 
|  K8S\$1VERSION  |  Cadena  |  Versión de Kubernetes para nodos híbridos (por ejemplo, `1.31`). Para ver las versiones de Kubernetes compatibles, consulte las [versiones compatibles de Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).  | 
|  NODEADM\$1ARCH  |  Cadena  |  Arquitecturas para `nodeadm install`. Seleccione `amd` o `arm`.  | 

 **RHEL** 

Si utiliza RHEL, se deben configurar las siguientes variables de entorno.


| Variable de entorno | Tipo | Descripción | 
| --- | --- | --- | 
|  RH\$1USERNAME  |  Cadena  |  Nombre de usuario del administrador de suscripciones de RHEL  | 
|  RH\$1PASSWORD  |  Cadena  |  Contraseña del administrador de suscripciones de RHEL  | 
|  RHEL\$1VERSION  |  Cadena  |  La versión iso de Rhel que se utiliza. Los valores válidos son `8` o `9`.  | 

 **Ubuntu** 

No se requieren variables de entorno específicas de Ubuntu.

 **vSphere** 

Si va a crear un OVA de VMware vSphere, deberá configurar las siguientes variables de entorno.


| Variable de entorno | Tipo | Descripción | 
| --- | --- | --- | 
|  VSPHERE\$1SERVER  |  Cadena  |  Dirección del servidor vSphere  | 
|  VSPHERE\$1USER  |  Cadena  |  Nombre de usuario de vSphere  | 
|  VSPHERE\$1PASSWORD  |  Cadena  |  Contraseña de vSphere  | 
|  VSPHERE\$1DATACENTER  |  Cadena  |  Nombre del centro de datos de vSphere  | 
|  VSPHERE\$1CLUSTER  |  Cadena  |  Nombre del clúster de vSphere  | 
|  VSPHERE\$1DATASTORE  |  Cadena  |  Nombre del almacén de datos de vSphere  | 
|  VSPHERE\$1NETWORK  |  Cadena  |  Nombre de la red de vSphere  | 
|  VSPHERE\$1OUTPUT\$1FOLDER  |  Cadena  |  Carpeta de salida de vSphere para las plantillas  | 

 **QEMU** 


| Variable de entorno | Tipo | Descripción | 
| --- | --- | --- | 
|  PACKER\$1OUTPUT\$1FORMAT  |  Cadena  |  Formato de salida para el generador QEMU. Los valores válidos son `qcow2` y `raw`.  | 

 **Validación de la plantilla** 

Antes de ejecutar la compilación, valide la plantilla con el siguiente comando después de configurar las variables de entorno. Sustituya `template.pkr.hcl` si utiliza un nombre diferente para la plantilla.

```
packer validate template.pkr.hcl
```

### Generación de imágenes
<a name="_build_images"></a>

Genere las imágenes con los siguientes comandos y utilice la marca `-only` para especificar el destino y el sistema operativo de las imágenes. Sustituya `template.pkr.hcl` si utiliza un nombre diferente para la plantilla.

 **OVA de vSphere** 

**nota**  
Si utiliza RHEL con vSphere necesita convertir los archivos kickstart a una imagen OEMDRV y transmitirla como una ISO desde la que arrancar. Para obtener más información, consulte [Readme de Packer](https://github.com/aws/eks-hybrid/tree/main/example/packer#utilizing-rhel-with-vsphere) en el repositorio de GitHub de los Nodos híbridos de EKS.

 **OVA de Ubuntu** 

```
packer build -only=general-build.vsphere-iso.ubuntu22 template.pkr.hcl
```

 **OVA de Ubuntu** 

```
packer build -only=general-build.vsphere-iso.ubuntu24 template.pkr.hcl
```

 **OVA de RHEL** 

```
packer build -only=general-build.vsphere-iso.rhel8 template.pkr.hcl
```

 **OVA de RHEL** 

```
packer build -only=general-build.vsphere-iso.rhel9 template.pkr.hcl
```

 **QEMU** 

**nota**  
Si va a generar una imagen para una CPU de host específica que no coincide con el host del generador, consulte la documentación de [QEMU](https://www.qemu.org/docs/master/system/qemu-cpu-models.html) para obtener el nombre que coincida con la CPU de host y utilice la marca `-cpu` con el nombre de la CPU de host cuando ejecute los siguientes comandos.

 **Ubuntu 22.04 Qcow2/sin procesar** 

```
packer build -only=general-build.qemu.ubuntu22 template.pkr.hcl
```

 **Ubuntu 24.04 Qcow2/sin procesar** 

```
packer build -only=general-build.qemu.ubuntu24 template.pkr.hcl
```

 **RHEL 8 Qcow2/sin procesar** 

```
packer build -only=general-build.qemu.rhel8 template.pkr.hcl
```

 **RHEL 9 Qcow2/sin procesar** 

```
packer build -only=general-build.qemu.rhel9 template.pkr.hcl
```

### Cómo transmitir la configuración de nodeadm a través de user-data
<a name="_pass_nodeadm_configuration_through_user_data"></a>

Puede transmitir la configuración de `nodeadm` en los user-data a través de cloud-init para configurar y conectar automáticamente los nodos híbridos al clúster de EKS al iniciar el host. A continuación, encontrará un ejemplo de cómo lograrlo al utilizar VMware vSphere como infraestructura para los nodos híbridos.

1. Instale la CLI de `govc` según las instrucciones del archivo [govc readme](https://github.com/vmware/govmomi/blob/main/govc/README.md) en GitHub.

1. Después de ejecutar la compilación de Packer en la sección anterior y aprovisionar la plantilla, podrá clonar la plantilla para crear varios nodos diferentes de la siguiente manera. Debe clonar la plantilla para cada nueva máquina virtual que cree y que vaya a utilizar para nodos híbridos. Sustituya las variables del comando que aparece a continuación por los valores correspondientes al entorno. El `VM_NAME` en el comando que aparece a continuación se utiliza como `NODE_NAME` cuando se introducen los nombres de las máquinas virtuales a través del archivo `metadata.yaml`.

   ```
   govc vm.clone -vm "/PATH/TO/TEMPLATE" -ds="YOUR_DATASTORE" \
       -on=false -template=false -folder=/FOLDER/TO/SAVE/VM "VM_NAME"
   ```

1. Después de clonar la plantilla para cada una de sus nuevas máquinas virtuales, cree un `userdata.yaml` y `metadata.yaml` para las máquinas virtuales. Las máquinas virtuales pueden compartir los mismos `userdata.yaml` y `metadata.yaml`, que deberá completar según cada máquina virtual y a través de los pasos que se indican a continuación. La configuración `nodeadm` se crea y define en la sección `write_files` del `userdata.yaml`. En el siguiente ejemplo, se utilizan las activaciones híbridas de AWS SSM como proveedor de credenciales en las instalaciones para los nodos híbridos. Para obtener más información sobre la configuración de `nodeadm`, consulte [Referencia de `nodeadm` de nodos híbridos](hybrid-nodes-nodeadm.md).

    **userdata.yaml:** 

   ```
   #cloud-config
   users:
     - name: # username for login. Use 'builder' for RHEL or 'ubuntu' for Ubuntu.
       passwd: # password to login. Default is 'builder' for RHEL.
       groups: [adm, cdrom, dip, plugdev, lxd, sudo]
       lock-passwd: false
       sudo: ALL=(ALL) NOPASSWD:ALL
       shell: /bin/bash
   
   write_files:
     - path: /usr/local/bin/nodeConfig.yaml
       permissions: '0644'
       content: |
         apiVersion: node.eks.aws/v1alpha1
         kind: NodeConfig
         spec:
             cluster:
                 name: # Cluster Name
                 region: # AWS region
             hybrid:
                 ssm:
                     activationCode: # Your ssm activation code
                     activationId: # Your ssm activation id
   
   runcmd:
     - /usr/local/bin/nodeadm init -c file:///usr/local/bin/nodeConfig.yaml >> /var/log/nodeadm-init.log 2>&1
   ```

    **metadata.yaml:** 

   Cree un `metadata.yaml` para el entorno. Mantenga el formato de la variable `"$NODE_NAME"` en el archivo, ya que este se completará con valores en un paso posterior.

   ```
   instance-id: "$NODE_NAME"
   local-hostname: "$NODE_NAME"
   network:
     version: 2
     ethernets:
       nics:
         match:
           name: ens*
         dhcp4: yes
   ```

1. Agregue los archivos `userdata.yaml` y `metadata.yaml` como cadenas `gzip+base64` con los siguientes comandos. Se deben ejecutar los siguientes comandos para cada una de las máquinas virtuales que se van a crear. Sustituya `VM_NAME` por el nombre de la máquina virtual que va a actualizar.

   ```
   export NODE_NAME="VM_NAME"
   export USER_DATA=$(gzip -c9 <userdata.yaml | base64)
   
   govc vm.change -dc="YOUR_DATASTORE" -vm "$NODE_NAME" -e guestinfo.userdata="${USER_DATA}"
   govc vm.change -dc="YOUR_DATASTORE" -vm "$NODE_NAME" -e guestinfo.userdata.encoding=gzip+base64
   
   envsubst '$NODE_NAME' < metadata.yaml > metadata.yaml.tmp
   export METADATA=$(gzip -c9 <metadata.yaml.tmp | base64)
   
   govc vm.change -dc="YOUR_DATASTORE" -vm "$NODE_NAME" -e guestinfo.metadata="${METADATA}"
   govc vm.change -dc="YOUR_DATASTORE" -vm "$NODE_NAME" -e guestinfo.metadata.encoding=gzip+base64
   ```

1. Encienda las nuevas máquinas virtuales, que se conectarán automáticamente al clúster de EKS que configuró.

   ```
   govc vm.power -on "${NODE_NAME}"
   ```

# Cómo preparar las credenciales para los nodos híbridos
<a name="hybrid-nodes-creds"></a>

Los Nodos híbridos de Amazon EKS utilizan credenciales de IAM temporales aprovisionadas por activaciones híbridas de AWS SSM o AWS IAM Roles Anywhere para autenticarse con el clúster de Amazon EKS. Debe usar activaciones híbridas de AWS SSM o AWS IAM Roles Anywhere con la CLI (`nodeadm`) de los Nodos híbridos de Amazon EKS. No debe utilizar ambas opciones, únicamente activaciones híbridas de AWS o AWS IAM Roles Anywhere. Le recomendamos utilizar las activaciones híbridas de AWS SSM si no dispone de una infraestructura de clave pública (PKI) existente con una entidad de certificación (CA) y certificados para los entornos en las instalaciones. Si ya dispone de PKI y certificados en las instalaciones, utilice AWS IAM Roles Anywhere.

## Rol de IAM de nodos híbridos
<a name="hybrid-nodes-role"></a>

Antes de poder conectar nodos híbridos al clúster de Amazon EKS, deberá crear un rol de IAM que se utilizará con las activaciones híbridas de AWS SSM o AWS IAM Roles Anywhere para las credenciales de los nodos híbridos. Tras la creación del clúster, utilizará este rol con una entrada de acceso de Amazon EKS o una entrada de `aws-auth` ConfigMap para asignar el rol de IAM al control de acceso basado en roles (RBAC) de Kubernetes. Para obtener más información sobre cómo asociar el de IAM de Nodos híbridos al RBAC de Kubernetes, consulte [Cómo preparar el acceso al clúster para los nodos híbridos](hybrid-nodes-cluster-prep.md).

El rol de IAM de nodos híbridos debe tener los siguientes permisos:
+ Permisos para que `nodeadm` utilice la acción `eks:DescribeCluster` a fin de recopilar información sobre el clúster al que quiere conectar los nodos híbridos. Si no activa la acción `eks:DescribeCluster`, deberá transmitir el punto de conexión de la API de Kubernetes, el paquete de CA del clúster y el CIDR IPv4 del servicio a la configuración de nodos que transmite al comando `nodeadm init`.
+ Permisos para que `nodeadm` utilice la acción `eks:ListAccessEntries` a fin de enumerar las entradas de acceso en el clúster al que quiere conectar los nodos híbridos. Si no activa la acción `eks:ListAccessEntries`, deberá transmitir el indicador `--skip cluster-access-validation` al ejecutar el comando `nodeadm init`.
+ Permisos para que el kubelet pueda utilizar imágenes de contenedores de Amazon Elastic Container Registry (Amazon ECR), según lo dispuesto en la política [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ContainerRegistryPullOnly.html).
+ Si utiliza AWS SSM, debe conceder permisos a `nodeadm init` para usar activaciones híbridas de AWS SSM, según se define en la política [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSSMManagedInstanceCore.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSSMManagedInstanceCore.html).
+ Si usa AWS SSM, permisos para usar la acción `ssm:DeregisterManagedInstance` y la acción `ssm:DescribeInstanceInformation` para que `nodeadm uninstall` anule el registro de instancias.
+ (Opcional) Permisos para que el agente de Pod Identity de Amazon EKS utilice la acción `eks-auth:AssumeRoleForPodIdentity` para recuperar las credenciales de los pods.

## Configuración de activaciones híbridas de AWS SSM
<a name="hybrid-nodes-ssm"></a>

Antes de configurar las activaciones híbridas de AWS SSM, deberá crear y configurar un rol de IAM de nodos híbridos. Para obtener más información, consulte [Creación del rol de IAM de nodos híbridos](#hybrid-nodes-create-role). Siga las instrucciones que aparecen en [Cómo crear una activación híbrida para registrar nodos en Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/hybrid-activation-managed-nodes.html) en la Guía del usuario de AWS Systems Manager para crear una activación híbrida de AWS SSM para los nodos híbridos. El código de activación y el ID que recibe se utilizan con `nodeadm` al registrar los hosts como nodos híbridos en el clúster de Amazon EKS. Podrá volver a este paso más adelante, una vez que haya creado y preparado los clústeres de Amazon EKS para nodos híbridos.

**importante**  
Systems Manager regresa inmediatamente el código e ID de activación a la consola o la ventana de comandos, en función de cómo haya creado la activación. Copie esta información y guárdela en un lugar seguro. Si sale de la consola o cierra la ventana de comandos, podría perder esta información. Si la pierde, debe crear una nueva activación.

De forma predeterminada, las activaciones híbridas de AWS SSM se mantienen activas durante 24 horas. También puede especificar una `--expiration-date` al crear la activación híbrida en formato de marca de tiempo, por ejemplo `2024-08-01T00:00:00`. Cuando utiliza AWS SSM como proveedor de credenciales, el nombre de nodo de los nodos híbridos no se puede configurar, sino que AWS SSM lo genera automáticamente. Puede ver y administrar las instancias administradas por AWS SSM en la consola de AWS Systems Manager, en Administrador de flotas. Puede registrar hasta 1000 [nodos activados de manera híbrida](https://docs.aws.amazon.com/systems-manager/latest/userguide/activations.html) estándar por cada cuenta por región de AWS sin costo adicional. Sin embargo, para registrar más de 1000 nodos híbridos es necesario activar el nivel de instancias avanzadas. El uso del nivel de instancias avanzadas conlleva un cargo que no está incluido en los precios de los [Nodos híbridos de Amazon EKS](https://aws.amazon.com/eks/pricing/). Para obtener más información, consulte [Precios de AWS Systems Manager](https://aws.amazon.com/systems-manager/pricing/).

Consulte el siguiente ejemplo para saber cómo crear una activación híbrida de AWS SSM con el rol de IAM de nodos híbridos. Si utiliza activaciones híbridas de AWS SSM para las credenciales de los nodos híbridos, los nombres de los nodos híbridos tendrán el mismo formato `mi-012345678abcdefgh` y las credenciales temporales aprovisionadas por AWS SSM serán válidas durante 1 hora. No puede modificar el nombre del nodo ni la duración de las credenciales si utiliza AWS SSM como proveedor de credenciales. AWS SSM rota automáticamente las credenciales temporales y la rotación no afecta al estado de los nodos o las aplicaciones.

Le recomendamos utilizar una activación híbrida de AWS SSM por clúster de EKS para limitar el permiso `ssm:DeregisterManagedInstance` de AWS SSM del rol de IAM de nodos híbridos de modo que únicamente pueda anular el registro de las instancias asociadas a la activación híbrida de AWS SSM. En el ejemplo que aparece en esta página, se utiliza una etiqueta con el ARN del clúster de EKS, que se puede utilizar para asignar la activación híbrida de AWS SSM al clúster de EKS. También puede utilizar la etiqueta y el método que prefiera para determinar el alcance de los permisos de AWS SSM en función de los límites de permisos y requisitos. La opción `REGISTRATION_LIMIT` del siguiente comando es un número entero que se utiliza para limitar la cantidad de máquinas que pueden utilizar la activación híbrida de AWS SSM (por ejemplo, `10`)

```
aws ssm create-activation \
     --region AWS_REGION \
     --default-instance-name eks-hybrid-nodes \
     --description "Activation for EKS hybrid nodes" \
     --iam-role AmazonEKSHybridNodesRole \
     --tags Key=EKSClusterARN,Value=arn:aws:eks:AWS_REGION:AWS_ACCOUNT_ID:cluster/CLUSTER_NAME \
     --registration-limit REGISTRATION_LIMIT
```

Consulte las instrucciones de [Creación de una activación híbrida para registrar nodos en Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/hybrid-activation-managed-nodes.html) para obtener más información sobre los ajustes de configuración disponibles para las activaciones híbridas de AWS SSM.

## Configuración de AWS IAM Roles Anywhere
<a name="hybrid-nodes-iam-roles-anywhere"></a>

Siga las instrucciones que aparecen en [Introducción a IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/getting-started.html) en la Guía del usuario de IAM Roles Anywhere para configurar el anclaje de veracidad y el perfil que utilizará como credenciales de IAM temporales para el rol de IAM de nodos híbridos. Puede crear el perfil sin agregar ningún rol. Puede crear este perfil, volver a estos pasos para crear el rol de IAM de nodos híbridos y, a continuación, agregar el rol al perfil una vez creado. También puede utilizar los pasos de AWS CloudFormation que aparecen más adelante en esta página para completar la configuración de IAM Roles Anywhere para los nodos híbridos.

Cuando agregue el rol de IAM de Nodos híbridos al perfil, seleccione **Aceptar nombre de sesión de rol personalizado** en el panel **Nombre de sesión de rol personalizado**, ubicado en la parte inferior de la página **Editar perfil** en la consola de AWS IAM Roles Anywhere. Corresponde al campo [acceptRoleSessionName](https://docs.aws.amazon.com/rolesanywhere/latest/APIReference/API_CreateProfile.html#rolesanywhere-CreateProfile-request-acceptRoleSessionName) de la API `CreateProfile`. Esto permite proporcionar un nombre de nodo personalizado para los nodos híbridos en la configuración que se transmite a `nodeadm` durante el proceso de arranque. Es necesario transmitir un nombre de nodo personalizado durante el proceso de `nodeadm init`. Puede actualizar el perfil para aceptar un nombre de sesión de rol personalizado después de crear el perfil.

Puede configurar la duración de la validez de las credenciales con AWS IAM Roles Anywhere mediante el campo [durationSeconds](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/authentication-create-session#credentials-object) del perfil de AWS IAM Roles Anywhere. La duración predeterminada es de una hora con un máximo de 12 horas. La configuración `MaxSessionDuration` del rol de IAM de nodos híbridos debe ser mayor que la configuración `durationSeconds` del perfil de AWS IAM Roles Anywhere. Para obtener más información sobre `MaxSessionDuration`, consulte la [documentación sobre la API UpdateRole](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_UpdateRole.html).

Los certificados y claves por máquina que genere a partir de la entidad de certificación (CA) se deben colocar en el directorio `/etc/iam/pki` de cada nodo híbrido con los nombres de archivo `server.pem` para el certificado y `server.key` para la clave.

## Creación del rol de IAM de nodos híbridos
<a name="hybrid-nodes-create-role"></a>

Para ejecutar los pasos de esta sección, la entidad principal de IAM que utilice la consola de AWS o AWS CLI debe tener los siguientes permisos.
+  `iam:CreatePolicy` 
+  `iam:CreateRole` 
+  `iam:AttachRolePolicy` 
+ Si utiliza AWS IAM Roles Anywhere
  +  `rolesanywhere:CreateTrustAnchor` 
  +  `rolesanywhere:CreateProfile` 
  +  `iam:PassRole` 

### AWS CloudFormation
<a name="hybrid-nodes-creds-cloudformation"></a>

Si aún no lo ha hecho, instale y configure AWS CLI. Consulte [Instalación o actualización de la versión más reciente de AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).

 **Pasos para las activaciones híbridas de AWS SSM** 

La pila de CloudFormation crea el rol de IAM de nodos híbridos con los permisos descritos anteriormente. La plantilla de CloudFormation no crea la activación híbrida de AWS SSM.

1. Descargue la plantilla de AWS SSM CloudFormation para nodos híbridos:

   ```
   curl -OL 'https://raw.githubusercontent.com/aws/eks-hybrid/refs/heads/main/example/hybrid-ssm-cfn.yaml'
   ```

1. Cree un `cfn-ssm-parameters.json` con las opciones siguientes:

   1. Sustituya `ROLE_NAME` por el nombre del rol de IAM de nodos híbridos. De forma predeterminada, la plantilla de CloudFormation utiliza `AmazonEKSHybridNodesRole` como el nombre del rol que crea si no se especifica ningún nombre.

   1. Sustituya `TAG_KEY` por la clave de etiqueta del recurso de AWS SSM que utilizó al crear la activación híbrida de AWS SSM. La combinación de la clave de etiqueta y el valor de la etiqueta se utiliza en la condición de `ssm:DeregisterManagedInstance` para permitir que el rol de IAM de nodos híbridos anule el registro de las instancias administradas por AWS SSM asociadas a la activación híbrida de AWS SSM. En la plantilla de CloudFormation, el valor predeterminado de `TAG_KEY` es `EKSClusterARN`.

   1. Sustituya `TAG_VALUE` por el valor de etiqueta del recurso de AWS SSM que utilizó al crear la activación híbrida de AWS SSM. La combinación de la clave de etiqueta y el valor de la etiqueta se utiliza en la condición de `ssm:DeregisterManagedInstance` para permitir que el rol de IAM de nodos híbridos anule el registro de las instancias administradas por AWS SSM asociadas a la activación híbrida de AWS SSM. Si utiliza la `TAG_KEY` predeterminada de `EKSClusterARN`, transmita el ARN del clúster de EKS como el `TAG_VALUE`. Los ARN del clúster de EKS tienen el formato ` arn:aws:eks:AWS_REGION:AWS_ACCOUNT_ID:cluster/CLUSTER_NAME`.

      ```
      {
        "Parameters": {
          "RoleName": "ROLE_NAME",
          "SSMDeregisterConditionTagKey": "TAG_KEY",
          "SSMDeregisterConditionTagValue": "TAG_VALUE"
        }
      }
      ```

1. Implementación de la pila de CloudFormation. Sustituya `STACK_NAME` por el nombre de la pila de CloudFormation.

   ```
   aws cloudformation deploy \
       --stack-name STACK_NAME \
       --template-file hybrid-ssm-cfn.yaml \
       --parameter-overrides file://cfn-ssm-parameters.json \
       --capabilities CAPABILITY_NAMED_IAM
   ```

 **Pasos correspondientes a AWS IAM Roles Anywhere** 

La pila de CloudFormation crea el anclaje de veracidad de AWS IAM Roles Anywhere con la entidad de certificación (CA) que configure, crea el perfil de AWS IAM Roles Anywhere y crea el rol de IAM de nodos híbridos con los permisos descritos anteriormente.

1. Para configurar una entidad de certificación

   1. Para utilizar un recurso de AWS Private CA, abra la consola de [AWS Private Certificate Authority](https://console.aws.amazon.com/acm-pca/home). Siga las instrucciones que aparecen en la [Guía del usuario de AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html).

   1. Para usar una entidad de certificación externa, siga las instrucciones proporcionadas por esta. El contenido del certificado se proporcionará más adelante.

   1. Los certificados emitidos por entidades de certificación públicas no se pueden utilizar como anclajes de veracidad.

1. Descargue la plantilla de CloudFormation de AWS IAM Roles Anywhere para nodos híbridos

   ```
   curl -OL 'https://raw.githubusercontent.com/aws/eks-hybrid/refs/heads/main/example/hybrid-ira-cfn.yaml'
   ```

1. Cree un `cfn-iamra-parameters.json` con las opciones siguientes:

   1. Sustituya `ROLE_NAME` por el nombre del rol de IAM de nodos híbridos. De forma predeterminada, la plantilla de CloudFormation utiliza `AmazonEKSHybridNodesRole` como el nombre del rol que crea si no se especifica ningún nombre.

   1. Sustituya `CERT_ATTRIBUTE` por el atributo de certificado por máquina que identifique de forma exclusiva al host. El atributo de certificado que utilice debe coincidir con el nodeName que utilice para la configuración de `nodeadm` al conectar nodos híbridos al clúster. Para obtener más información, consulte la [Referencia de `nodeadm` de nodos híbridos](hybrid-nodes-nodeadm.md). De forma predeterminada, la plantilla de CloudFormation utiliza `${aws:PrincipalTag/x509Subject/CN}` como `CERT_ATTRIBUTE`, que corresponde al campo CN de los certificados por máquina. También puede transmitir `$(aws:PrincipalTag/x509SAN/Name/CN}` como `CERT_ATTRIBUTE`.

   1. Sustituya `CA_CERT_BODY` por el contenido del certificado de la entidad de certificación sin saltos de línea. El `CA_CERT_BODY` debe estar en formato Privacy Enhanced Mail (PEM). Si tiene un certificado de entidad de certificación en formato PEM, elimine los saltos de línea y las líneas BEGIN CERTIFICATE y END CERTIFICATE antes de incluir el contenido del certificado de la entidad de certificación en el archivo `cfn-iamra-parameters.json`.

      ```
      {
        "Parameters": {
          "RoleName": "ROLE_NAME",
          "CertAttributeTrustPolicy": "CERT_ATTRIBUTE",
          "CABundleCert": "CA_CERT_BODY"
        }
      }
      ```

1. Implemente la plantilla de CloudFormation. Sustituya `STACK_NAME` por el nombre de la pila de CloudFormation.

   ```
   aws cloudformation deploy \
       --stack-name STACK_NAME \
       --template-file hybrid-ira-cfn.yaml \
       --parameter-overrides file://cfn-iamra-parameters.json
       --capabilities CAPABILITY_NAMED_IAM
   ```

### AWS CLI
<a name="hybrid-nodes-creds-awscli"></a>

Si aún no lo ha hecho, instale y configure AWS CLI. Consulte [Instalación o actualización de la versión más reciente de AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).

 **Cómo crear la política de descripción de clústeres de EKS** 

1. Cree un archivo denominado `eks-describe-cluster-policy.json` con el siguiente contenido:

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "eks:DescribeCluster"
               ],
               "Resource": "*"
           }
       ]
   }
   ```

1. Cree la política con el siguiente comando:

   ```
   aws iam create-policy \
       --policy-name EKSDescribeClusterPolicy \
       --policy-document file://eks-describe-cluster-policy.json
   ```

 **Pasos para las activaciones híbridas de AWS SSM** 

1. Cree un archivo denominado `eks-hybrid-ssm-policy.json` con el siguiente contenido. La política concede permisos para dos acciones: `ssm:DescribeInstanceInformation` y `ssm:DeregisterManagedInstance`. La política restringe el permiso `ssm:DeregisterManagedInstance` a las instancias administradas por AWS SSM asociadas a la activación híbrida de AWS SSM en función de la etiqueta de recurso que especifique en la política de confianza.

   1. Sustituya `AWS_REGION` por la región AWS para la activación híbrida de AWS SSM.

   1. Reemplace `AWS_ACCOUNT_ID` por su ID de cuenta de AWS.

   1. Sustituya `TAG_KEY` por la clave de etiqueta del recurso de AWS SSM que utilizó al crear la activación híbrida de AWS SSM. La combinación de la clave de etiqueta y el valor de la etiqueta se utiliza en la condición de `ssm:DeregisterManagedInstance` para permitir que el rol de IAM de nodos híbridos anule el registro de las instancias administradas por AWS SSM asociadas a la activación híbrida de AWS SSM. En la plantilla de CloudFormation, el valor predeterminado de `TAG_KEY` es `EKSClusterARN`.

   1. Sustituya `TAG_VALUE` por el valor de etiqueta del recurso de AWS SSM que utilizó al crear la activación híbrida de AWS SSM. La combinación de la clave de etiqueta y el valor de la etiqueta se utiliza en la condición de `ssm:DeregisterManagedInstance` para permitir que el rol de IAM de nodos híbridos anule el registro de las instancias administradas por AWS SSM asociadas a la activación híbrida de AWS SSM. Si utiliza la `TAG_KEY` predeterminada de `EKSClusterARN`, transmita el ARN del clúster de EKS como el `TAG_VALUE`. Los ARN del clúster de EKS tienen el formato ` arn:aws:eks:AWS_REGION:AWS_ACCOUNT_ID:cluster/CLUSTER_NAME`.

      ```
      {
          "Version":"2012-10-17",		 	 	 
          "Statement": [
              {
                  "Effect": "Allow",
                  "Action": "ssm:DescribeInstanceInformation",
                  "Resource": "*"
              },
              {
                  "Effect": "Allow",
                  "Action": "ssm:DeregisterManagedInstance",
                  "Resource": "arn:aws:ssm:us-east-1:123456789012:managed-instance/*",
                  "Condition": {
                      "StringEquals": {
                          "ssm:resourceTag/TAG_KEY": "TAG_VALUE"
                      }
                  }
              }
          ]
      }
      ```

1. Cree la política mediante el siguiente comando

   ```
   aws iam create-policy \
       --policy-name EKSHybridSSMPolicy \
       --policy-document file://eks-hybrid-ssm-policy.json
   ```

1. Cree un archivo denominado `eks-hybrid-ssm-trust.json`. Sustituya `AWS_REGION` por la región de AWS de la activación híbrida de AWS SSM y `AWS_ACCOUNT_ID` por el ID de la cuenta de AWS.

   ```
   {
      "Version":"2012-10-17",		 	 	 
      "Statement":[
         {
            "Sid":"",
            "Effect":"Allow",
            "Principal":{
               "Service":"ssm.amazonaws.com"
            },
            "Action":"sts:AssumeRole",
            "Condition":{
               "StringEquals":{
                  "aws:SourceAccount":"123456789012"
               },
               "ArnEquals":{
                  "aws:SourceArn":"arn:aws:ssm:us-east-1:123456789012:*"
               }
            }
         }
      ]
   }
   ```

1. Cree el rol con el siguiente comando.

   ```
   aws iam create-role \
       --role-name AmazonEKSHybridNodesRole \
       --assume-role-policy-document file://eks-hybrid-ssm-trust.json
   ```

1. Asocie la `EKSDescribeClusterPolicy` y la `EKSHybridSSMPolicy` que creó en los pasos anteriores. Reemplace `AWS_ACCOUNT_ID` por su ID de cuenta de AWS.

   ```
   aws iam attach-role-policy \
       --role-name AmazonEKSHybridNodesRole \
       --policy-arn arn:aws:iam::AWS_ACCOUNT_ID:policy/EKSDescribeClusterPolicy
   ```

   ```
   aws iam attach-role-policy \
       --role-name AmazonEKSHybridNodesRole \
       --policy-arn arn:aws:iam::AWS_ACCOUNT_ID:policy/EKSHybridSSMPolicy
   ```

1. Asocie las políticas `AmazonEC2ContainerRegistryPullOnly` y `AmazonSSMManagedInstanceCore` administradas por AWS.

   ```
   aws iam attach-role-policy \
       --role-name AmazonEKSHybridNodesRole \
       --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly
   ```

   ```
   aws iam attach-role-policy \
       --role-name AmazonEKSHybridNodesRole \
       --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
   ```

 **Pasos correspondientes a AWS IAM Roles Anywhere** 

Para utilizar AWS IAM Roles Anywhere, debe configurar el anclaje de veracidad de AWS IAM Roles Anywhere antes de crear el rol de IAM de nodos híbridos. Para obtener instrucciones, consulte [Configuración de AWS IAM Roles Anywhere](#hybrid-nodes-iam-roles-anywhere).

1. Cree un archivo denominado `eks-hybrid-iamra-trust.json`. Sustituya `TRUST_ANCHOR ARN` por el ARN del anclaje de veracidad que creó en los pasos de [Configuración de AWS IAM Roles Anywhere](#hybrid-nodes-iam-roles-anywhere). La condición en esta política de confianza limita la capacidad de AWS IAM Roles Anywhere para asumir el rol de IAM de nodos híbridos. Esto permite el intercambio de credenciales temporales de IAM únicamente cuando el nombre de la sesión del rol coincide con el CN especificado en el certificado x509 instalado en los nodos híbridos. Alternativamente, puede utilizar otros atributos del certificado para identificar de manera única el nodo. El atributo de certificado que utilice en la política de confianza debe corresponder al `nodeName` que haya establecido en la configuración de `nodeadm`. Para obtener más información, consulte la [Referencia de `nodeadm` de nodos híbridos](hybrid-nodes-nodeadm.md).

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Principal": {
                   "Service": "rolesanywhere.amazonaws.com"
               },
               "Action": [
                   "sts:TagSession",
                   "sts:SetSourceIdentity"
               ],
               "Condition": {
                   "StringEquals": {
                       "aws:PrincipalTag/x509Subject/CN": "${aws:PrincipalTag/x509Subject/CN}"
                   },
                   "ArnEquals": {
                       "aws:SourceArn": "arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/TA_ID"
                   }
               }
           },
           {
               "Effect": "Allow",
               "Principal": {
                   "Service": "rolesanywhere.amazonaws.com"
               },
               "Action": "sts:AssumeRole",
               "Condition": {
                   "StringEquals": {
                       "sts:RoleSessionName": "${aws:PrincipalTag/x509Subject/CN}",
                       "aws:PrincipalTag/x509Subject/CN": "${aws:PrincipalTag/x509Subject/CN}"
                   },
                   "ArnEquals": {
                       "aws:SourceArn": "arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/TA_ID"
                   }
               }
           }
       ]
   }
   ```

1. Cree el rol con el siguiente comando.

   ```
   aws iam create-role \
       --role-name AmazonEKSHybridNodesRole \
       --assume-role-policy-document file://eks-hybrid-iamra-trust.json
   ```

1. Asocie la `EKSDescribeClusterPolicy` que creó en los pasos anteriores. Reemplace `AWS_ACCOUNT_ID` por su ID de cuenta de AWS.

   ```
   aws iam attach-role-policy \
       --role-name AmazonEKSHybridNodesRole \
       --policy-arn arn:aws:iam::AWS_ACCOUNT_ID:policy/EKSDescribeClusterPolicy
   ```

1. Asocie la política `AmazonEC2ContainerRegistryPullOnly` administrada por AWS.

   ```
   aws iam attach-role-policy \
       --role-name AmazonEKSHybridNodesRole \
       --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly
   ```

### Consola de administración de AWS
<a name="hybrid-nodes-creds-console"></a>

 **Cómo crear la política de descripción de clústeres de EKS** 

1. Abra la [consola de Amazon IAM](https://console.aws.amazon.com/iam/home). 

1. En el panel de navegación izquierdo, elija **Políticas**.

1. En la página **Políticas**, seleccione **Crear una política**.

1. En la página Especificar permisos, en Seleccionar un panel de servicio, elija EKS.

   1. Filtre las acciones de **DescribeCluster** y seleccione la acción de lectura **DescribeCluster**.

   1. Elija **Siguiente**.

1. En la página **Revisar y crear**

   1. Ingresa un **Nombre de política** para la política, como `EKSDescribeClusterPolicy`.

   1. Elija **Crear política**.

 **Pasos para las activaciones híbridas de AWS SSM** 

1. Abra la [consola de Amazon IAM](https://console.aws.amazon.com/iam/home). 

1. En el panel de navegación izquierdo, elija **Políticas**.

1. En la página **Políticas**, seleccione **Crear una política**.

1. En la página **Especificar permisos**, en el **Editor de políticas** en la esquina superior derecha, elija **JSON**. Pegue el siguiente fragmento. Sustituya `AWS_REGION` por la región de AWS de la activación híbrida de AWS SSM y `AWS_ACCOUNT_ID` por el ID de la cuenta de AWS. Sustituya `TAG_KEY` y `TAG_VALUE` por la clave de etiqueta del recurso de AWS SSM que utilizó al crear la activación híbrida de AWS SSM.

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": "ssm:DescribeInstanceInformation",
               "Resource": "*"
           },
           {
               "Effect": "Allow",
               "Action": "ssm:DeregisterManagedInstance",
               "Resource": "arn:aws:ssm:us-east-1:123456789012:managed-instance/*",
               "Condition": {
                   "StringEquals": {
                       "ssm:resourceTag/TAG_KEY": "TAG_VALUE"
                   }
               }
           }
       ]
   }
   ```

   1. Elija **Siguiente**.

1. En la página **Revisar y crear**.

   1. Ingrese un nombre de **Política** para la política, como `EKSHybridSSMPolicy` 

   1. Seleccione **Crear política**.

1. En el panel de navegación izquierdo, elija **Roles**.

1. En la página **Roles**, elija **Crear rol**.

1. En la página **Seleccionar entidad de confianza**, haga lo siguiente:

   1. En la sección de tipo de **Entidad de confianza**, elija **Política de confianza personalizada**. Pegue lo siguiente en el editor de políticas de confianza personalizadas. Sustituya `AWS_REGION` por la región de AWS de la activación híbrida de AWS SSM y `AWS_ACCOUNT_ID` por el ID de la cuenta de AWS.

      ```
      {
         "Version":"2012-10-17",		 	 	 
         "Statement":[
            {
               "Sid":"",
               "Effect":"Allow",
               "Principal":{
                  "Service":"ssm.amazonaws.com"
               },
               "Action":"sts:AssumeRole",
               "Condition":{
                  "StringEquals":{
                     "aws:SourceAccount":"123456789012"
                  },
                  "ArnEquals":{
                     "aws:SourceArn":"arn:aws:ssm:us-east-1:123456789012:*"
                  }
               }
            }
         ]
      }
      ```

   1. Seleccione Siguiente.

1. En la página **Agregar permisos**, asocie una política personalizada o haga lo siguiente:

   1. En el cuadro **Filtrar políticas**, ingrese `EKSDescribeClusterPolicy` o el nombre de la política que creó anteriormente. Marque la casilla situada a la izquierda del nombre de la política en los resultados de la búsqueda.

   1. En el cuadro **Filtrar políticas**, ingrese `EKSHybridSSMPolicy` o el nombre de la política que creó anteriormente. Marque la casilla situada a la izquierda del nombre de la política en los resultados de la búsqueda.

   1. En el cuadro **Filtrar políticas**, escriba `AmazonEC2ContainerRegistryPullOnly`. Marque la casilla situada a la izquierda de `AmazonEC2ContainerRegistryPullOnly` en los resultados de la búsqueda.

   1. En el cuadro **Filtrar políticas**, escriba `AmazonSSMManagedInstanceCore`. Marque la casilla situada a la izquierda de `AmazonSSMManagedInstanceCore` en los resultados de la búsqueda.

   1. Elija **Siguiente**.

1. En la página **Nombrar, revisar y crear**, haga lo siguiente:

   1. En **Nombre del rol**, ingrese un nombre único para su rol, por ejemplo, `AmazonEKSHybridNodesRole`.

   1. En **Description** (Descripción), sustituya el texto actual por un texto descriptivo, como `Amazon EKS - Hybrid Nodes role`.

   1. Elija **Creación de rol**.

 **Pasos correspondientes a AWS IAM Roles Anywhere** 

Para utilizar AWS IAM Roles Anywhere, debe configurar el anclaje de veracidad de AWS IAM Roles Anywhere antes de crear el rol de IAM de nodos híbridos. Para obtener instrucciones, consulte [Configuración de AWS IAM Roles Anywhere](#hybrid-nodes-iam-roles-anywhere).

1. Abra la [consola de Amazon IAM](https://console.aws.amazon.com/iam/home). 

1. En el panel de navegación izquierdo, elija **Roles**.

1. En la página **Roles**, elija **Crear rol**.

1. En la página **Seleccionar entidad de confianza**, haga lo siguiente:

   1. En la sección de tipo de **Entidad de confianza**, elija **Política de confianza personalizada**. Pegue lo siguiente en el editor de políticas de confianza personalizadas. Sustituya `TRUST_ANCHOR ARN` por el ARN del anclaje de veracidad que creó en los pasos de [Configuración de AWS IAM Roles Anywhere](#hybrid-nodes-iam-roles-anywhere). La condición en esta política de confianza limita la capacidad de AWS IAM Roles Anywhere para asumir el rol de IAM de nodos híbridos. Esto permite el intercambio de credenciales temporales de IAM únicamente cuando el nombre de la sesión del rol coincide con el CN especificado en el certificado x509 instalado en los nodos híbridos. Alternativamente, puede utilizar otros atributos del certificado para identificar de manera única el nodo. El atributo de certificado que utilice en la política de confianza debe corresponder al nodeName que haya establecido en la configuración de nodeadm. Para obtener más información, consulte la [Referencia de `nodeadm` de nodos híbridos](hybrid-nodes-nodeadm.md).

      ```
      {
          "Version":"2012-10-17",		 	 	 
          "Statement": [
              {
                  "Effect": "Allow",
                  "Principal": {
                      "Service": "rolesanywhere.amazonaws.com"
                  },
                  "Action": [
                      "sts:TagSession",
                      "sts:SetSourceIdentity"
                  ],
                  "Condition": {
                      "StringEquals": {
                          "aws:PrincipalTag/x509Subject/CN": "${aws:PrincipalTag/x509Subject/CN}"
                      },
                      "ArnEquals": {
                          "aws:SourceArn": "arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/TA_ID"
                      }
                  }
              },
              {
                  "Effect": "Allow",
                  "Principal": {
                      "Service": "rolesanywhere.amazonaws.com"
                  },
                  "Action": "sts:AssumeRole",
                  "Condition": {
                      "StringEquals": {
                          "sts:RoleSessionName": "${aws:PrincipalTag/x509Subject/CN}",
                          "aws:PrincipalTag/x509Subject/CN": "${aws:PrincipalTag/x509Subject/CN}"
                      },
                      "ArnEquals": {
                          "aws:SourceArn": "arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/TA_ID"
                      }
                  }
              }
          ]
      }
      ```

   1. Seleccione Siguiente.

1. En la página **Agregar permisos**, asocie una política personalizada o haga lo siguiente:

   1. En el cuadro **Filtrar políticas**, ingrese `EKSDescribeClusterPolicy` o el nombre de la política que creó anteriormente. Marque la casilla situada a la izquierda del nombre de la política en los resultados de la búsqueda.

   1. En el cuadro **Filtrar políticas**, escriba `AmazonEC2ContainerRegistryPullOnly`. Marque la casilla situada a la izquierda de `AmazonEC2ContainerRegistryPullOnly` en los resultados de la búsqueda.

   1. Elija **Siguiente**.

1. En la página **Nombrar, revisar y crear**, haga lo siguiente:

   1. En **Nombre del rol**, ingrese un nombre único para su rol, por ejemplo, `AmazonEKSHybridNodesRole`.

   1. En **Description** (Descripción), sustituya el texto actual por un texto descriptivo, como `Amazon EKS - Hybrid Nodes role`.

   1. Elija **Creación de rol**.

# Cómo crear un clúster de Amazon EKS con nodos híbridos
<a name="hybrid-nodes-cluster-create"></a>

En este tema se ofrece información general sobre las opciones disponibles y se describen los aspectos que se deben tener en cuenta al crear un clúster de Amazon EKS habilitado para nodos híbridos. Los Nodos híbridos de EKS cuentan con el mismo [soporte de versiones de Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) que los clústeres de Amazon EKS con nodos en la nube, incluidos los soportes estándar y extendido.

Si no tiene previsto usar los Nodos híbridos de EKS, consulte la documentación principal para crear clústeres de Amazon EKS en [Creación de un clúster de Amazon EKS](create-cluster.md).

## Requisitos previos
<a name="hybrid-nodes-cluster-create-prep"></a>
+ [Configuración previa requerida para los nodos híbridos](hybrid-nodes-prereqs.md) cumplidos. Antes de crear el clúster habilitado para los nodos híbridos, debe tener identificados los CIDR del nodo en las instalaciones y, opcionalmente, los de los pods. También necesita haber creado la VPC y las subredes según los requisitos de EKS y de los nodos híbridos, así como configurar un grupo de seguridad con reglas de entrada para los CIDR en las instalaciones y, opcionalmente, los de los pods. Para obtener más información sobre estos requisitos previos, consulte [Cómo preparar las redes para los nodos híbridos](hybrid-nodes-networking.md).
+ La versión más reciente de la Interfaz de Línea de Comandos de AWS (AWS CLI) instalada y configurada en el dispositivo. Para comprobar su versión actual, utilice `aws --version`. Los administradores de paquetes, tales como yum, apt-get o Homebrew para macOS suelen estar atrasados varias versiones respecto de la versión de AWS CLI más reciente. Para instalar la versión más reciente, consulte [Instalación o actualización de la versión más reciente de AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) y [Configuración de los ajustes de AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) en la Guía del usuario de la Interfaz de la línea de comandos de AWS.
+ Una [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles#iam-term-principal) con permisos para crear roles de IAM y asociar políticas, así como para crear y describir clústeres de EKS

## Consideraciones
<a name="hybrid-nodes-cluster-create-consider"></a>
+ El clúster debe utilizar el modo `API` o `API_AND_CONFIG_MAP` de autenticación de clústeres.
+ El clúster debe utilizar la familia de direcciones IPv4.
+ El clúster debe utilizar conectividad de punto de conexión de clúster pública o privada. El clúster no puede utilizar la conectividad de punto de conexión de clúster “pública y privada”, ya que el punto de conexión del servidor de la API de Kubernetes de Amazon EKS se resolverá en las IP públicas de los nodos híbridos que se ejecutan fuera de la VPC.
+ Se admite la autenticación OIDC para clústeres de EKS con nodos híbridos.
+ Puede añadir, cambiar o eliminar la configuración de nodos híbridos de un clúster existente. Para obtener más información, consulte [Habilitación de nodos híbridos en un clúster de Amazon EKS existente o modificación de la configuración](hybrid-nodes-cluster-update.md).

## Paso 1: creación de un rol de IAM del clúster
<a name="hybrid-nodes-cluster-create-iam"></a>

Si ya cuenta con un rol de IAM del clúster o va a crear el clúster con `eksctl` o AWS CloudFormation, puede omitir este paso. De forma predeterminada, `eksctl` y la plantilla de AWS CloudFormation crean el rol de IAM del clúster en su nombre.

1. Ejecute el siguiente comando para crear un archivo de política de confianza JSON de IAM.

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "Service": "eks.amazonaws.com"
         },
         "Action": "sts:AssumeRole"
       }
     ]
   }
   ```

1. Creación del rol de IAM del clúster de Amazon EKS. Si es necesario, introduzca eks-cluster-role-trust-policy.json con la ruta del equipo en la que escribió el archivo en el paso anterior. El comando asocia la política de confianza creada en el paso anterior al rol. Para crear un rol de IAM, a la [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles#iam-term-principal) que está creando el rol se le debe asignar la acción `iam:CreateRole` (permiso).

   ```
   aws iam create-role \
       --role-name myAmazonEKSClusterRole \
       --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
   ```

1. Puede asignar la política administrada de Amazon EKS o bien crear su propia política personalizada. Para conocer los permisos mínimos que debe utilizar en su política personalizada, consulte [Rol de IAM de nodo de Amazon EKS](create-node-role.md). Adjunte la política administrada de IAM por Amazon EKS denominada `AmazonEKSClusterPolicy` al rol. Para adjuntar una política de IAM a una [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles#iam-term-principal), se debe asignar una de las siguientes acciones de IAM (permisos) a la entidad principal que adjunta la política: `iam:AttachUserPolicy` o `iam:AttachRolePolicy`.

   ```
   aws iam attach-role-policy \
       --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy \
       --role-name myAmazonEKSClusterRole
   ```

## Paso 2: Creación del clúster habilitado para nodos híbridos
<a name="hybrid-nodes-cluster-create-cluster"></a>

Puede crear un clúster mediante:
+  [eksctl](#hybrid-nodes-cluster-create-eksctl) 
+  [AWS CloudFormation](#hybrid-nodes-cluster-create-cfn) 
+  [AWS CLI](#hybrid-nodes-cluster-create-cli) 
+  [Consola de administración de AWS](#hybrid-nodes-cluster-create-console) 

### Cómo crear el clúster habilitado para nodos híbridos: eksctl
<a name="hybrid-nodes-cluster-create-eksctl"></a>

Debe instalar la versión más reciente de la herramienta de línea de comandos de `eksctl`. Para instalar o actualizar `eksctl`, consulte la sección de [Instalación](https://eksctl.io/installation) en la documentación de `eksctl`.

1. Cree `cluster-config.yaml` para definir un clúster IPv4 de Amazon EKS habilitado para nodos híbridos. Sustituya los siguientes valores en el `cluster-config.yaml`. Para obtener una lista completa de los ajustes, consulte la [documentación de eksctl](https://eksctl.io/getting-started/).

   1. Reemplace `CLUSTER_NAME` por el nombre del clúster. El nombre solo puede contener caracteres alfanuméricos (con distinción de mayúsculas y minúsculas) y guiones. Debe comenzar con un carácter alfanumérico y no puede tener más de 100 caracteres. El nombre debe ser único dentro de la región de AWS y la cuenta de AWS en las que va a crear el clúster.

   1. Reemplace `AWS_REGION` por la región de AWS en la que desea crear el clúster.

   1. Reemplace `K8S_VERSION` por cualquier [versión compatible con Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).

   1. Sustituya `CREDS_PROVIDER` por `ssm` o `ira` según el proveedor de credenciales que configuró en los pasos correspondientes a [Cómo preparar las credenciales para los nodos híbridos](hybrid-nodes-creds.md).

   1. Sustituya `CA_BUNDLE_CERT` si el proveedor de credenciales está configurado en `ira`, que utiliza AWS IAM Roles Anywhere como proveedor de credenciales. El CA\$1BUNDLE\$1CERT es el contenido del certificado de la entidad de certificación (CA) y depende de la entidad de certificación que elija. El certificado debe estar en formato Privacy Enhanced Mail (PEM).

   1. Sustituya `GATEWAY_ID` por el ID de la puerta de enlace privada virtual o de la puerta de enlace de tránsito que se va a asociar a la VPC.

   1. Sustituya `REMOTE_NODE_CIDRS` por el CIDR del nodo en las instalaciones para los nodos híbridos.

   1. Sustituya `REMOTE_POD_CIDRS` por el CIDR del pod en las instalaciones para las cargas de trabajo que se ejecutan en nodos híbridos. De otro modo, elimine la línea de la configuración si no va a ejecutar webhooks en nodos híbridos. Debe configurar los `REMOTE_POD_CIDRS` si la CNI no utiliza la traducción de direcciones de red (NAT) ni la ocultación de las direcciones IP de los pods cuando el tráfico del pod sale de los hosts en las instalaciones. Debe configurar `REMOTE_POD_CIDRS` si ejecuta webhooks en nodos híbridos. Consulte [Configuración de webhooks para nodos híbridos](hybrid-nodes-webhooks.md) para obtener más información.

   1. Los bloques de CIDR del pod y del nodo en las instalaciones deben cumplir los siguientes requisitos:

      1. Estar dentro de uno de los rangos IPv4 RFC-1918: `10.0.0.0/8`, `172.16.0.0/12` o `192.168.0.0/16`, o dentro del rango CGNAT definido por RFC 6598: `100.64.0.0/10`.

      1. Que no se solapen entre sí, el `VPC CIDR` del clúster o el CIDR de IPv4 del servicio de Kubernetes.

         ```
         apiVersion: eksctl.io/v1alpha5
         kind: ClusterConfig
         
         metadata:
           name: CLUSTER_NAME
           region: AWS_REGION
           version: "K8S_VERSION"
         
         remoteNetworkConfig:
           iam:
             provider: CREDS_PROVIDER # default SSM, can also be set to IRA
             # caBundleCert: CA_BUNDLE_CERT
           vpcGatewayID: GATEWAY_ID
           remoteNodeNetworks:
           - cidrs: ["REMOTE_NODE_CIDRS"]
           remotePodNetworks:
           - cidrs: ["REMOTE_POD_CIDRS"]
         ```

1. Use el siguiente comando:

   ```
   eksctl create cluster -f cluster-config.yaml
   ```

   El aprovisionamiento de clústeres tarda varios minutos. Mientras se crea el clúster, aparecen varias líneas de salida. La última línea de salida es similar a la siguiente línea de ejemplo.

   ```
   [✓]  EKS cluster "CLUSTER_NAME" in "REGION" region is ready
   ```

1. Continúe con [Paso 3: actualización de kubeconfig](#hybrid-nodes-cluster-create-kubeconfig).

### Cómo crear un clúster con nodos híbridos habilitados: AWS CloudFormation
<a name="hybrid-nodes-cluster-create-cfn"></a>

La pila de CloudFormation crea el rol de IAM del clúster de EKS y un clúster de EKS con la `RemoteNodeNetwork` y la `RemotePodNetwork` que especifique. Modifique la plantilla de CloudFormation si necesita personalizar configuraciones para el clúster de EKS que no están expuestas en la plantilla de CloudFormation.

1. Descargar la plantilla de CloudFormation.

   ```
   curl -OL 'https://raw.githubusercontent.com/aws/eks-hybrid/refs/heads/main/example/hybrid-eks-cfn.yaml'
   ```

1. Cree un `cfn-eks-parameters.json` y especifique la configuración de cada valor.

   1.  `CLUSTER_NAME`: el nombre del clúster de EKS que se va a crear

   1.  `CLUSTER_ROLE_NAME`: el nombre del rol de IAM del clúster de EKS que se va a crear. El valor predeterminado de la plantilla es “EKSClusterRole”.

   1.  `SUBNET1_ID`: el ID de la primera subred que creó en los pasos para cumplir los requisitos previos

   1.  `SUBNET2_ID`: el ID de la segunda subred que creó en los pasos para cumplir los requisitos previos

   1.  `SG_ID`: el ID del grupo de seguridad que creó en los pasos para cumplir los requisitos previos

   1.  `REMOTE_NODE_CIDRS`: el CIDR del nodo en las instalaciones para los nodos híbridos

   1.  `REMOTE_POD_CIDRS`: el CIDR del pod en las instalaciones para cargas de trabajo que se ejecutan en nodos híbridos. Debe configurar los `REMOTE_POD_CIDRS` si la CNI no utiliza la traducción de direcciones de red (NAT) ni la ocultación de las direcciones IP de los pods cuando el tráfico del pod sale de los hosts en las instalaciones. Debe configurar `REMOTE_POD_CIDRS` si ejecuta webhooks en nodos híbridos. Consulte [Configuración de webhooks para nodos híbridos](hybrid-nodes-webhooks.md) para obtener más información.

   1. Los bloques de CIDR del pod y del nodo en las instalaciones deben cumplir los siguientes requisitos:

      1. Estar dentro de uno de los rangos IPv4 RFC-1918: `10.0.0.0/8`, `172.16.0.0/12` o `192.168.0.0/16`, o dentro del rango CGNAT definido por RFC 6598: `100.64.0.0/10`.

      1. Que no se solapen entre sí, el `VPC CIDR` del clúster o el CIDR de IPv4 del servicio de Kubernetes.

   1.  `CLUSTER_AUTH`: el modo de autenticación del clúster. Los valores válidos son `API` y `API_AND_CONFIG_MAP`. El valor predeterminado que aparece en la plantilla es `API_AND_CONFIG_MAP`.

   1.  `CLUSTER_ENDPOINT`: la conectividad de punto de conexión del clúster. Los valores válidos son “Pública” o “Privada”. El valor predeterminado que aparece en la plantilla es Privada, lo que significa que solo se podrá establecer conexión con el punto de conexión de la API de Kubernetes desde dentro de la VPC.

   1.  `K8S_VERSION`: la versión de Kubernetes que se va a utilizar para el clúster. Consulte [Versiones compatibles de Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).

      ```
      {
        "Parameters": {
          "ClusterName": "CLUSTER_NAME",
          "ClusterRoleName": "CLUSTER_ROLE_NAME",
          "SubnetId1": "SUBNET1_ID",
          "SubnetId2": "SUBNET2_ID",
          "SecurityGroupId" "SG_ID",
          "RemoteNodeCIDR": "REMOTE_NODE_CIDRS",
          "RemotePodCIDR": "REMOTE_POD_CIDRS",
          "ClusterAuthMode": "CLUSTER_AUTH",
          "ClusterEndpointConnectivity": "CLUSTER_ENDPOINT",
          "K8sVersion": "K8S_VERSION"
        }
       }
      ```

1. Implementación de la pila de CloudFormation. Sustituya `STACK_NAME` por el nombre de la pila de CloudFormation y `AWS_REGION` por la región de AWS en la que se creará el clúster.

   ```
   aws cloudformation deploy \
       --stack-name STACK_NAME \
       --region AWS_REGION \
       --template-file hybrid-eks-cfn.yaml \
       --parameter-overrides file://cfn-eks-parameters.json \
       --capabilities CAPABILITY_NAMED_IAM
   ```

   El aprovisionamiento de clústeres tarda varios minutos. Puede comprobar el estado de la pila con el siguiente comando. Sustituya `STACK_NAME` por el nombre de la pila de CloudFormation y `AWS_REGION` por la región de AWS en la que se creará el clúster.

   ```
   aws cloudformation describe-stacks \
       --stack-name STACK_NAME \
       --region AWS_REGION \
       --query 'Stacks[].StackStatus'
   ```

1. Continúe con [Paso 3: actualización de kubeconfig](#hybrid-nodes-cluster-create-kubeconfig).

### Cómo crear el clúster habilitado para nodos híbridos: AWS CLI
<a name="hybrid-nodes-cluster-create-cli"></a>

1. Ejecute el siguiente comando para crear un clúster de EKS habilitado para nodos híbridos. Antes de ejecutar el comando, sustituya los siguientes valores por la configuración deseada. Para obtener una lista completa de los ajustes, consulte la documentación de [Creación de un clúster de Amazon EKS](create-cluster.md).

   1.  `CLUSTER_NAME`: el nombre del clúster de EKS que se va a crear

   1.  `AWS_REGION`: región de AWS en la que se creará el clúster.

   1.  `K8S_VERSION`: la versión de Kubernetes que se va a utilizar para el clúster. Consulte Versiones compatibles de Amazon EKS.

   1.  `ROLE_ARN`: el rol de clúster de Amazon EKS que configuró para el clúster. Consulte Rol de IAM del clúster de Amazon EKS para obtener más información.

   1.  `SUBNET1_ID`: el ID de la primera subred que creó en los pasos para cumplir los requisitos previos

   1.  `SUBNET2_ID`: el ID de la segunda subred que creó en los pasos para cumplir los requisitos previos

   1.  `SG_ID`: el ID del grupo de seguridad que creó en los pasos para cumplir los requisitos previos

   1. Puede utilizar `API` y `API_AND_CONFIG_MAP` para el modo de autenticación de acceso al clúster. En el siguiente comando, el modo de autenticación de acceso al clúster está establecido en `API_AND_CONFIG_MAP`.

   1. Puede utilizar los parámetros `endpointPublicAccess` y `endpointPrivateAccess` para habilitar o desactivar el acceso público y privado al punto de conexión del servidor de la API de Kubernetes del clúster. En el siguiente comando, `endpointPublicAccess` se establece en falso y `endpointPrivateAccess` se establece en verdadero.

   1.  `REMOTE_NODE_CIDRS`: el CIDR del nodo en las instalaciones para los nodos híbridos.

   1.  `REMOTE_POD_CIDRS`: (opcional) el CIDR del pod en las instalaciones para cargas de trabajo que se ejecutan en nodos híbridos.

   1. Los bloques de CIDR del pod y del nodo en las instalaciones deben cumplir los siguientes requisitos:

      1. Estar dentro de uno de los rangos IPv4 RFC-1918: `10.0.0.0/8`, `172.16.0.0/12` o `192.168.0.0/16`, o dentro del rango CGNAT definido por RFC 6598: `100.64.0.0/10`.

      1. Que no se solapen entre sí, el `VPC CIDR` del clúster de Amazon EKS o el CIDR de IPv4 del servicio de Kubernetes.

         ```
         aws eks create-cluster \
             --name CLUSTER_NAME \
             --region AWS_REGION \
             --kubernetes-version K8S_VERSION \
             --role-arn ROLE_ARN \
             --resources-vpc-config subnetIds=SUBNET1_ID,SUBNET2_ID,securityGroupIds=SG_ID,endpointPrivateAccess=true,endpointPublicAccess=false \
             --access-config authenticationMode=API_AND_CONFIG_MAP \
             --remote-network-config '{"remoteNodeNetworks":[{"cidrs":["REMOTE_NODE_CIDRS"]}],"remotePodNetworks":[{"cidrs":["REMOTE_POD_CIDRS"]}]}'
         ```

1. La provisión del clúster puede tardar varios minutos. Puede consultar el estado del clúster con el siguiente comando. Sustituya `CLUSTER_NAME` por el nombre del clúster que va a crear y `AWS_REGION` por la región de AWS en la que se va a crear el clúster. No continúe con el siguiente paso hasta que la salida devuelta sea `ACTIVE`.

   ```
   aws eks describe-cluster \
       --name CLUSTER_NAME \
       --region AWS_REGION \
       --query "cluster.status"
   ```

1. Continúe con [Paso 3: actualización de kubeconfig](#hybrid-nodes-cluster-create-kubeconfig).

### Creación del clúster habilitado para nodos híbridos: Consola de administración de AWS
<a name="hybrid-nodes-cluster-create-console"></a>

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

1. Elija Agregar clúster y, a continuación, elija Crear.

1. En la página Configurar clúster rellene los siguientes campos:

   1.  **Nombre**: un nombre único para el clúster. El nombre solo puede contener caracteres alfanuméricos (con distinción de mayúsculas y minúsculas) y guiones bajos. Debe comenzar con un carácter alfanumérico y no puede tener más de 100 caracteres. El nombre debe ser único dentro de la región de AWS y la cuenta de AWS en las que va a crear el clúster.

   1.  **Rol de IAM del clúster**: elija el rol de IAM del clúster de Amazon EKS que creó para permitir que el plano de control de Kubernetes administre los recursos de AWS en su nombre.

   1.  **Versión de Kubernetes**: la versión de Kubernetes que debe utilizarse para el clúster. Le recomendamos que seleccione la versión más reciente, a menos que necesite una versión anterior.

   1.  **Política de actualización**: elija entre extendida o estándar.

      1.  **Extendida:** esta opción es compatible con la versión de Kubernetes durante 26 meses a partir de la fecha de lanzamiento. El periodo de soporte extendido tiene un costo adicional por hora que comenzará una vez finalizado el periodo de soporte estándar. Una vez finalizado el soporte extendido, el clúster se actualizará automáticamente a la siguiente versión.

      1.  **Estándar:** esta opción es compatible con la versión de Kubernetes durante 14 meses a partir de la fecha de lanzamiento. No supone ningún costo adicional. Una vez finalizado el soporte estándar, el clúster se actualizará automáticamente a la siguiente versión.

   1.  **Acceso al clúster**: elija permitir o denegar el acceso del administrador al clúster y seleccione un modo de autenticación. Los siguientes modos de autenticación son compatibles con los clústeres habilitados para nodos híbridos.

      1.  **API de EKS**: el clúster obtendrá las entidades principales de IAM autenticadas únicamente de las API de entrada de acceso de EKS.

      1.  **API de EKS y ConfigMap**: el clúster obtendrá las entidades principales de IAM autenticadas tanto de las API de entrada de acceso de EKS como de `aws-auth` ConfigMap.

   1.  **Cifrado de secretos**: (opcional) elija habilitar el cifrado de secretos de los secretos de Kubernetes con una clave de KMS. También puede habilitarlo después de crear el clúster. Antes de habilitar esta capacidad, asegúrese de estar familiarizado con la información de [Cifrado de los secretos de Kubernetes con KMS en los clústeres existentes](enable-kms.md).

   1.  **Cambio de zona de ARC**: si esta opción está activada, EKS registrará el clúster en el cambio de zona de ARC de modo que pueda recurrir al cambio de zona para desplazar el tráfico fuera de aplicaciones de una zona de disponibilidad.

   1.  **Etiquetas**: (opcional) agregue las etiquetas a su clúster. Para obtener más información, consulte [Organización de los recursos de Amazon EKS con etiquetas](eks-using-tags.md).

   1. Cuando haya terminado con esta página, seleccione **Siguiente**.

1. En la página **Especificar red** seleccione valores para los siguientes campos:

   1.  **VPC**: elija una VPC existente que cumpla con [Requisitos de red de Amazon EKS para VPC y subredes](network-reqs.md) y los [requisitos de los Nodos híbridos de Amazon EKS](hybrid-nodes-prereqs.md). Antes de elegir una VPC, recomendamos que esté familiarizado con todos los requisitos y consideraciones que se indican en Consulte los requisitos de red de Amazon EKS para VPC, subredes y nodos híbridos. No puede cambiar la VPC que desea utilizar después de crear un clúster. Si no hay ninguna VPC en la lista, debe crear una primero. Para obtener más información, consulte [Creación de una Amazon VPC para su clúster de Amazon EKS](creating-a-vpc.md) y [Requisitos de red para los Nodos híbridos de Amazon EKS](hybrid-nodes-prereqs.md).

   1.  **Subredes**: de forma predeterminada, se preseleccionan todas las subredes disponibles de la VPC especificada en el campo anterior. Debe seleccionar al menos dos.

   1.  **Grupos de seguridad**: (opcional) especifique uno o varios grupos de seguridad que desea que Amazon EKS asocie a las interfaces de red que crea. Al menos uno de los grupos de seguridad que especifique debe tener reglas de entrada para los CIDR del nodo en las instalaciones y, opcionalmente, los de los pods. Consulte [Requisitos de red de los Nodos híbridos de Amazon EKS](hybrid-nodes-networking.md) para obtener más información. Independientemente de que elija grupos de seguridad o no, Amazon EKS crea un grupo de seguridad que permite la comunicación entre el clúster y la VPC. Amazon EKS asocia este grupo de seguridad, y el que elija, a las interfaces de red que crea. Para obtener más información acerca del grupo de seguridad de clústeres que Amazon EKS crea, consulte [Revisión de requisitos de grupos de seguridad de Amazon EKS para clústeres](sec-group-reqs.md). Puede modificar las reglas del grupo de seguridad de clústeres que Amazon EKS crea.

   1.  **Elija la familia de direcciones IP del clúster**: debe elegir IPv4 para los clústeres habilitados para nodos híbridos.

   1. (Opcional) Elija **Configuración del rango de direcciones IP del servicio de Kubernetes** y especifique un **Rango de servicio IPv4**.

   1.  **Elija Configuración de redes remotas para habilitar nodos híbridos** y especifique los CIDR del nodo en las instalaciones y de los pods para los nodos híbridos.

   1. Debe configurar el CIDR del pod remoto si la CNI no utiliza la traducción de direcciones de red (NAT) ni la ocultación de las direcciones IP de los pods cuando el tráfico del pod sale de los hosts en las instalaciones. Debe configurar el CIDR de pod remoto si va a ejecutar webhooks en nodos híbridos.

   1. Los bloques de CIDR del pod y del nodo en las instalaciones deben cumplir los siguientes requisitos:

      1. Estar dentro de uno de los rangos IPv4 RFC-1918: `10.0.0.0/8`, `172.16.0.0/12` o `192.168.0.0/16`, o dentro del rango CGNAT definido por RFC 6598: `100.64.0.0/10`.

      1. Que no se solapen entre sí, el `VPC CIDR` del clúster o el CIDR de IPv4 del servicio de Kubernetes.

   1. Para el **Acceso al punto de conexión del clúster**, seleccione una opción. Una vez que se crea el clúster, puede cambiar esta opción. En el caso de los clústeres habilitados para nodos híbridos, debe elegir entre Pública o Privada. Antes de seleccionar una opción no predeterminada, asegúrese de familiarizarse con las opciones y sus implicaciones. Para obtener más información, consulte [Punto de conexión del servidor de API del clúster](cluster-endpoint.md).

   1. Cuando haya terminado con esta página, seleccione **Siguiente**.

1. (Opcional) En la página **Configuración** de la observabilidad, seleccione qué opciones de métricas y registro de planos de control desea activar. De forma predeterminada, cada tipo de registro está desactivado.

   1. Para obtener más información sobre la opción de las métricas de Prometheus, consulte [Supervisión de las métricas del clúster con Prometheus](prometheus.md).

   1. Para obtener más información sobre las opciones de registro de control de EKS, consulte [Envío de los registros del plano de control a Registros de CloudWatch](control-plane-logs.md).

   1. Cuando haya terminado con esta página, seleccione **Siguiente**.

1. En la página **Seleccionar complementos**, elija los complementos que desea agregar al clúster.

   1. Puede elegir tantos **complementos de Amazon EKS** y **complementos de Marketplace de AWS** como necesite. Los complementos de Amazon EKS que no son compatibles con los nodos híbridos están marcados con el mensaje “No es compatible con los nodos híbridos” y cuentan con una regla de antiafinidad que evita que se ejecuten en nodos híbridos. Consulte Configuración de complementos para nodos híbridos para obtener más información. Si los **complementos de Marketplace de AWS** que quiere instalar no aparecen en la lista, puede buscar los **complementos de Marketplace de AWS** disponibles al introducir texto en el cuadro de búsqueda. También puede buscar por **categoría**, **proveedor** o **modelo de precios** y, a continuación, elegir los complementos en los resultados de la búsqueda.

   1. Algunos complementos, como CoreDNS y kube-proxy, se instalan de forma predeterminada. Si desactiva alguno de los complementos predeterminados, esto puede afectar a su capacidad para ejecutar aplicaciones de Kubernetes.

   1. Cuando haya terminado con esta página, seleccione `Next`.

1. En la página **Configurar las opciones de complementos seleccionados**, seleccione la versión que desee instalar.

   1. Siempre puede actualizar a una versión posterior después de crear el clúster. Puede actualizar la configuración de cada complemento después de crear el clúster. Para obtener más información acerca de la configuración de complementos, consulte [Actualización de un complemento de Amazon EKS](updating-an-add-on.md). Para ver las versiones de complementos compatibles con los nodos híbridos, consulte [Cómo configurar complementos para nodos híbridos](hybrid-nodes-add-ons.md).

   1. Cuando haya terminado con esta página, seleccione Siguiente.

1. En la página **Revisar y crear**, revise la información que introdujo o seleccionó en las páginas anteriores. Si necesita realizar cambios, seleccione **Edit** (Editar). Cuando esté satisfecho, seleccione **Crear**. El campo **Estado** muestra **CREANDO** mientras se aprovisiona el clúster. El aprovisionamiento de clústeres tarda varios minutos.

1. Continúe con [Paso 3: actualización de kubeconfig](#hybrid-nodes-cluster-create-kubeconfig).

## Paso 3: actualización de kubeconfig
<a name="hybrid-nodes-cluster-create-kubeconfig"></a>

Si ha creado el clúster mediante `eksctl`, puede omitir este paso. Esto se debe a que `eksctl` ya ha completado este paso. Habilite `kubectl` para comunicarse con el clúster al agregar contexto nuevo al archivo de configuración `kubectl`. Para obtener más información acerca de cómo crear y actualizar el archivo, consulte [Conexión de kubectl a un clúster de EKS mediante la creación de un archivo kubeconfig](create-kubeconfig.md).

```
aws eks update-kubeconfig --name CLUSTER_NAME --region AWS_REGION
```

Un ejemplo de salida sería el siguiente.

```
Added new context arn:aws:eks:AWS_REGION:111122223333:cluster/CLUSTER_NAME to /home/username/.kube/config
```

Confirme la comunicación con el clúster ejecutando el siguiente comando.

```
kubectl get svc
```

Un ejemplo de salida sería el siguiente.

```
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.100.0.1   <none>        443/TCP   28h
```

## Paso 4: configuración del clúster
<a name="_step_4_cluster_setup"></a>

Para el siguiente paso, consulte [Cómo preparar el acceso al clúster para los nodos híbridos](hybrid-nodes-cluster-prep.md) para habilitar el acceso para que los nodos híbridos se unan al clúster.

# Habilitación de nodos híbridos en un clúster de Amazon EKS existente o modificación de la configuración
<a name="hybrid-nodes-cluster-update"></a>

Este tema ofrece una descripción general de las opciones disponibles y explica qué aspectos debe tener en cuenta al agregar, modificar o eliminar la configuración de nodos híbridos de un clúster de Amazon EKS.

Para permitir que un clúster de Amazon EKS utilice nodos híbridos, añada los rangos CIDR de direcciones IP del nodo en las instalaciones y, opcionalmente, de la red de pods en la configuración `RemoteNetworkConfig`. EKS usa esta lista de CIDR para habilitar la conectividad entre el clúster y las redes en las instalaciones. Para obtener una lista completa de las opciones a la hora de actualizar la configuración del clúster, consulte [UpdateClusterConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateClusterConfig.html) en la *referencia de la API de Amazon EKS*.

Puede realizar cualquiera de las siguientes acciones en la configuración de red de los nodos híbridos de EKS en un clúster:
+  [Agregar una configuración de red remota para habilitar los nodos híbridos de EKS en un clúster existente.](#hybrid-nodes-cluster-enable-existing) 
+  [Agregar, cambiar o eliminar las redes de nodos remotos o las redes de pods remotos de un clúster existente.](#hybrid-nodes-cluster-update-config) 
+  [Eliminar todos los rangos CIDR de redes de nodos remotos para deshabilitar los nodos híbridos de EKS en un clúster existente.](#hybrid-nodes-cluster-disable) 

## Requisitos previos
<a name="hybrid-nodes-cluster-enable-prep"></a>
+ Antes de habilitar su clúster de Amazon EKS para nodos híbridos, asegúrese de que su entorno cumpla los requisitos descritos en [Configuración previa requerida para los nodos híbridos](hybrid-nodes-prereqs.md) y detallados en [Cómo preparar las redes para los nodos híbridos](hybrid-nodes-networking.md), [Cómo preparar el sistema operativo para los nodos híbridos](hybrid-nodes-os.md) y[Cómo preparar las credenciales para los nodos híbridos](hybrid-nodes-creds.md).
+ El clúster debe utilizar la familia de direcciones IPv4.
+ El clúster debe utilizar el modo `API` o `API_AND_CONFIG_MAP` de autenticación de clústeres. El proceso para modificar el modo de autenticación del clúster se describe en [Cambio del modo de autenticación para utilizar las entradas de acceso](setting-up-access-entries.md).
+ Recomendamos utilizar acceso mediante un punto de conexión público o privado para el punto de conexión del servidor de la API de Kubernetes en Amazon EKS, pero no ambos. Si elige “Público y privado”, el punto de conexión del servidor de la API de Kubernetes de Amazon EKS siempre se resolverá en las IP públicas de los nodos híbridos que se ejecutan fuera de la VPC, lo que puede impedir que los nodos híbridos se unan al clúster. El proceso para modificar el acceso de red al clúster se describe en [Punto de conexión del servidor de API del clúster](cluster-endpoint.md).
+ La versión más reciente de la Interfaz de Línea de Comandos de AWS (AWS CLI) instalada y configurada en el dispositivo. Para comprobar su versión actual, utilice `aws --version`. Los administradores de paquetes, tales como yum, apt-get o Homebrew para macOS suelen estar atrasados varias versiones respecto de la versión de AWS CLI más reciente. Para instalar la versión más reciente, consulte [Instalación o actualización a la versión más reciente de AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) y [Configuración de los ajustes de AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) en la Guía del usuario de la interfaz de la línea de comandos de AWS.
+ Una [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles#iam-term-principal) con permiso para llamar a [UpdateClusterConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateClusterConfig.html) en su clúster de Amazon EKS.
+ Actualice los complementos a versiones compatibles con los nodos híbridos. Para ver las versiones de complementos compatibles con los nodos híbridos, consulte [Cómo configurar complementos para nodos híbridos](hybrid-nodes-add-ons.md).
+ Si está ejecutando complementos que no son compatibles con los nodos híbridos, asegúrese de que el complemento [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) o [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) tenga la siguiente regla de afinidad para evitar la implementación en nodos híbridos. Añada la siguiente regla de afinidad si aún no está presente.

  ```
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: eks.amazonaws.com/compute-type
            operator: NotIn
            values:
            - hybrid
  ```

## Consideraciones
<a name="hybrid-nodes-cluster-enable-consider"></a>

El objeto `remoteNetworkConfig` JSON tiene el siguiente comportamiento durante una actualización:
+ Cualquier parte existente de la configuración que no especifique permanece sin cambios. Si no especifica ninguna de `remoteNodeNetworks` o `remotePodNetworks`, esa parte seguirá siendo la misma.
+ Si modificará las listas `remoteNodeNetworks` o `remotePodNetworks` de CIDR, debe especificar la lista completa de CIDR que desee incluir en la configuración final. Al especificar un cambio en la lista `remoteNodeNetworks` o `remotePodNetworks` de CIDR, EKS reemplaza la lista original durante la actualización.
+ Los bloques de CIDR del pod y del nodo en las instalaciones deben cumplir los siguientes requisitos:

  1. Estar dentro de uno de los rangos IPv4 RFC-1918: 10.0.0.0/8, 172.16.0.0/12 o 192.168.0.0/16, o dentro del rango CGNAT definido por RFC 6598: `100.64.0.0/10` 

  1. Que no se solapen entre sí, todos los CIDR de la VPC del clúster de Amazon EKS o el CIDR de IPv4 del servicio de Kubernetes.

## Habilitación de nodos híbridos en un clúster existente
<a name="hybrid-nodes-cluster-enable-existing"></a>

Puede habilitar los nodos híbridos de EKS en un clúster existente con lo siguiente:
+  [AWS CloudFormation](#hybrid-nodes-cluster-enable-cfn) 
+  [AWS CLI](#hybrid-nodes-cluster-enable-cli) 
+  [Consola de administración de AWS](#hybrid-nodes-cluster-enable-console) 

### Habilitación de los nodos híbridos de EKS en un clúster existente: AWS CloudFormation
<a name="hybrid-nodes-cluster-enable-cfn"></a>

1. Para habilitar los nodos híbridos de EKS en su clúster, añada `RemoteNodeNetwork` y (opcional) `RemotePodNetwork` a la plantilla de CloudFormation y actualice la pila. Tenga en cuenta que `RemoteNodeNetwork` es una lista con un máximo de un elemento `Cidrs`, y `Cidrs` es una lista de varios rangos de CIDR de IP.

   ```
   RemoteNetworkConfig:
     RemoteNodeNetworks:
       - Cidrs: [RemoteNodeCIDR]
     RemotePodNetworks:
       - Cidrs: [RemotePodCIDR]
   ```

1. Continuar con [Cómo preparar el acceso al clúster para los nodos híbridos](hybrid-nodes-cluster-prep.md).

### Habilitación de los nodos híbridos de EKS en un clúster existente: AWS CLI
<a name="hybrid-nodes-cluster-enable-cli"></a>

1. Ejecute el siguiente comando para habilitar `RemoteNetworkConfig` para nodos híbridos de EKS para su clúster de EKS. Antes de ejecutar el comando, sustituya los siguientes valores por la configuración deseada. Para obtener una lista completa de los ajustes, consulte [UpdateClusterConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateClusterConfig.html) en la *referencia de la API de Amazon EKS*.

   1.  `CLUSTER_NAME`: nombre del clúster de EKS que se va a actualizar.

   1.  `AWS_REGION`: región de AWS en la que se ejecuta el clúster de EKS.

   1.  `REMOTE_NODE_CIDRS`: el CIDR del nodo en las instalaciones para los nodos híbridos.

   1.  `REMOTE_POD_CIDRS`: (opcional) el CIDR del pod en las instalaciones para cargas de trabajo que se ejecutan en nodos híbridos.

      ```
      aws eks update-cluster-config \
          --name CLUSTER_NAME \
          --region AWS_REGION \
          --remote-network-config '{"remoteNodeNetworks":[{"cidrs":["REMOTE_NODE_CIDRS"]}],"remotePodNetworks":[{"cidrs":["REMOTE_POD_CIDRS"]}]}'
      ```

1. La actualización del clúster puede tardar varios minutos. Puede consultar el estado del clúster con el siguiente comando. Sustituya `CLUSTER_NAME` por el nombre del clúster que va a modificar y `AWS_REGION` por la región de AWS en la que se va a ejecutar el clúster. No continúe con el siguiente paso hasta que la salida devuelta sea `ACTIVE`.

   ```
   aws eks describe-cluster \
       --name CLUSTER_NAME \
       --region AWS_REGION \
       --query "cluster.status"
   ```

1. Continuar con [Cómo preparar el acceso al clúster para los nodos híbridos](hybrid-nodes-cluster-prep.md).

### Habilitación de los nodos híbridos de EKS en un clúster existente: Consola de administración de AWS
<a name="hybrid-nodes-cluster-enable-console"></a>

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

1. Elija el nombre del clúster para mostrar la información del clúster.

1. En la pestaña **Redes**, elija **Administrar**.

1. En el menú desplegable, elija **Redes remotas**.

1.  **Elija Configuración de redes remotas para habilitar nodos híbridos** y especifique los CIDR del nodo en las instalaciones y de los pods para los nodos híbridos.

1. Elija **Save changes (Guardar cambios)** para terminar. Espere a que el estado del clúster vuelva a ser **Activo**.

1. Continuar con [Cómo preparar el acceso al clúster para los nodos híbridos](hybrid-nodes-cluster-prep.md).

## Actualización de la configuración de los nodos híbridos en un clúster existente
<a name="hybrid-nodes-cluster-update-config"></a>

Puede modificar `remoteNetworkConfig` en un clúster híbrido existente mediante cualquiera de las siguientes opciones:
+  [AWS CloudFormation](#hybrid-nodes-cluster-update-cfn) 
+  [AWS CLI](#hybrid-nodes-cluster-update-cli) 
+  [Consola de administración de AWS](#hybrid-nodes-cluster-update-console) 

### Actualización de la configuración en un clúster existente: AWS CloudFormation
<a name="hybrid-nodes-cluster-update-cfn"></a>

1. Actualice la plantilla de CloudFormation con los nuevos valores de CIDR de red.

   ```
   RemoteNetworkConfig:
     RemoteNodeNetworks:
       - Cidrs: [NEW_REMOTE_NODE_CIDRS]
     RemotePodNetworks:
       - Cidrs: [NEW_REMOTE_POD_CIDRS]
   ```
**nota**  
Al actualizar las listas CIDR de `RemoteNodeNetworks` o `RemotePodNetworks`, incluya todos los CIDR (nuevos y existentes). EKS reemplaza la lista completa durante las actualizaciones. Si se omiten estos campos de la solicitud de actualización, se conservan las configuraciones existentes.

1. Actualice la pila de CloudFormation con la plantilla modificada y espere a que se complete la actualización de la pila.

### Actualización de la configuración híbrida en un clúster existente: AWS CLI
<a name="hybrid-nodes-cluster-update-cli"></a>

1. Para modificar los CIDR de la red remota, ejecute el siguiente comando. Sustituya los valores por los ajustes que desee:

   ```
   aws eks update-cluster-config
   --name CLUSTER_NAME
   --region AWS_REGION
   --remote-network-config '{"remoteNodeNetworks":[{"cidrs":["NEW_REMOTE_NODE_CIDRS"]}],"remotePodNetworks":[{"cidrs":["NEW_REMOTE_POD_CIDRS"]}]}'
   ```
**nota**  
Al actualizar las listas CIDR de `remoteNodeNetworks` o `remotePodNetworks`, incluya todos los CIDR (nuevos y existentes). EKS reemplaza la lista completa durante las actualizaciones. Si se omiten estos campos de la solicitud de actualización, se conservan las configuraciones existentes.

1. Espere a que el estado del clúster vuelva a ser ACTIVO antes de proceder.

### Actualización de la configuración híbrida en un clúster existente: Consola de administración de AWS
<a name="hybrid-nodes-cluster-update-console"></a>

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

1. Elija el nombre del clúster para mostrar la información del clúster.

1. En la pestaña **Redes**, elija **Administrar**.

1. En el menú desplegable, elija **Redes remotas**.

1. Actualice los CIDR en `Remote node networks` y `Remote pod networks - Optional` según sea necesario.

1. Seleccione **Guardar cambios** y espere a que el estado del clúster vuelva a ser **Activo**.

## Inhabilitación de los nodos híbridos en un clúster existente
<a name="hybrid-nodes-cluster-disable"></a>

Puede inhabilitar los nodos híbridos de EKS en un clúster existente con lo siguiente:
+  [AWS CloudFormation](#hybrid-nodes-cluster-disable-cfn) 
+  [AWS CLI](#hybrid-nodes-cluster-disable-cli) 
+  [Consola de administración de AWS](#hybrid-nodes-cluster-disable-console) 

### Inhabilitación de los nodos híbridos de EKS en un clúster existente: AWS CloudFormation
<a name="hybrid-nodes-cluster-disable-cfn"></a>

1. Para inhabilitar los nodos híbridos de EKS en su clúster, configure `RemoteNodeNetworks` y `RemotePodNetworks` para vaciar las matrices en su plantilla de CloudFormation y actualice la pila.

   ```
   RemoteNetworkConfig:
     RemoteNodeNetworks: []
     RemotePodNetworks: []
   ```

### Inhabilitación de los nodos híbridos de EKS en un clúster existente: AWS CLI
<a name="hybrid-nodes-cluster-disable-cli"></a>

1. Ejecute el siguiente comando para eliminar `RemoteNetworkConfig` de su clúster de EKS. Antes de ejecutar el comando, sustituya los siguientes valores por la configuración deseada. Para obtener una lista completa de los ajustes, consulte [UpdateClusterConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateClusterConfig.html) en la *referencia de la API de Amazon EKS*.

   1.  `CLUSTER_NAME`: nombre del clúster de EKS que se va a actualizar.

   1.  `AWS_REGION`: región de AWS en la que se ejecuta el clúster de EKS.

      ```
      aws eks update-cluster-config \
          --name CLUSTER_NAME \
          --region AWS_REGION \
          --remote-network-config '{"remoteNodeNetworks":[],"remotePodNetworks":[]}'
      ```

1. La actualización del clúster puede tardar varios minutos. Puede consultar el estado del clúster con el siguiente comando. Sustituya `CLUSTER_NAME` por el nombre del clúster que va a modificar y `AWS_REGION` por la región de AWS en la que se va a ejecutar el clúster. No continúe con el siguiente paso hasta que la salida devuelta sea `ACTIVE`.

   ```
   aws eks describe-cluster \
       --name CLUSTER_NAME \
       --region AWS_REGION \
       --query "cluster.status"
   ```

### Inhabilitación de los nodos híbridos de EKS en un clúster existente: Consola de administración de AWS
<a name="hybrid-nodes-cluster-disable-console"></a>

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

1. Elija el nombre del clúster para mostrar la información del clúster.

1. En la pestaña **Redes**, elija **Administrar**.

1. En el menú desplegable, elija **Redes remotas**.

1. Seleccione **Configurar redes remotas para habilitar los nodos híbridos** y elimine todos los CIDR que aparecen en `Remote node networks` y `Remote pod networks - Optional`.

1. Elija **Save changes (Guardar cambios)** para terminar. Espere a que el estado del clúster vuelva a ser **Activo**.

# Cómo preparar el acceso al clúster para los nodos híbridos
<a name="hybrid-nodes-cluster-prep"></a>

Antes de conectar los nodos híbridos al clúster de Amazon EKS, debe habilitar el rol de IAM de nodos híbridos con permisos de Kubernetes para unirse al clúster. Consulte [Cómo preparar las credenciales para los nodos híbridos](hybrid-nodes-creds.md) para obtener información sobre cómo crear el rol de IAM de nodos híbridos. Amazon EKS admite dos formas de asociar entidades principales de IAM al control de acceso basado en roles (RBAC) de Kubernetes: las entradas de acceso de Amazon EKS y `aws-auth` ConfigMap. Para obtener más información sobre la administración del acceso a Amazon EKS, consulte [Concesión a los usuarios y roles de IAM de acceso a las API de Kubernetes](grant-k8s-access.md).

Utilice los siguientes procedimientos para asociar el rol de IAM de nodos híbridos a los permisos de Kubernetes. Para utilizar las entradas de acceso de Amazon EKS, el clúster se debe haber creado con los modos de autenticación `API` o `API_AND_CONFIG_MAP`. Para utilizar `aws-auth` ConfigMap, el clúster se debe haber creado con el modo de autenticación `API_AND_CONFIG_MAP`. El modo de autenticación solo con `CONFIG_MAP` no es compatible con los clústeres de Amazon EKS habilitados para nodos híbridos.

## Uso de entradas de acceso de Amazon EKS para el rol de IAM de nodos híbridos
<a name="_using_amazon_eks_access_entries_for_hybrid_nodes_iam_role"></a>

Existe un tipo de entrada de acceso de Amazon EKS para nodos híbridos denominado HYBRID\$1LINUX que se puede utilizar con un rol de IAM. Con este tipo de entrada de acceso, el nombre de usuario se establece automáticamente en system:node:\$1\$1SessionName\$1\$1. Para obtener más información sobre cómo crear entradas de acceso, consulte [Creación de entradas de acceso](creating-access-entries.md).

### AWS CLI
<a name="shared_aws_cli"></a>

1. Debe tener la versión más reciente de AWS CLI instalada y configurada en el dispositivo. Para comprobar su versión actual, utilice `aws --version`. Los administradores de paquetes, tales como yum, apt-get o Homebrew para macOS suelen estar atrasados varias versiones respecto de la versión de AWS CLI más reciente. Para instalar la versión más reciente, consulte Instalación y configuración rápida con aws configure en la Guía del usuario de la interfaz de línea de comandos de AWS.

1. Cree la entrada de acceso con el siguiente comando. Sustituya CLUSTER\$1NAME por el nombre del clúster y HYBRID\$1NODES\$1ROLE\$1ARN por el ARN del rol que creó en los pasos para [Cómo preparar las credenciales para los nodos híbridos](hybrid-nodes-creds.md).

   ```
   aws eks create-access-entry --cluster-name CLUSTER_NAME \
       --principal-arn HYBRID_NODES_ROLE_ARN \
       --type HYBRID_LINUX
   ```

### Consola de administración de AWS
<a name="hybrid-nodes-cluster-prep-console"></a>

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

1. Elija el nombre del clúster habilitado para nodos híbridos.

1. Elija la pestaña **Acceso**.

1. Elija **Crear entrada de acceso**.

1. En **entidad principal de IAM**, seleccione el rol de IAM de nodos híbridos que creó en los pasos correspondientes a [Cómo preparar las credenciales para los nodos híbridos](hybrid-nodes-creds.md).

1. En **Tipo**, seleccione **Hybrid Linux**.

1. (Opcional) En **Etiquetas**, asigne etiquetas a la entrada de acceso. Por ejemplo, para facilitar la búsqueda de todos los recursos con la misma etiqueta.

1. Elija **Omitir para revisar y crear**. No puede agregar políticas a la entrada de acceso de Hybrid Linux ni cambiar su alcance de acceso.

1. Revise la configuración de su entrada de acceso. Si algo parece incorrecto, seleccione **Anterior** para volver a repasar los pasos y corregir el error. Si la configuración es correcta, seleccione **Crear**.

## Uso de aws-auth ConfigMap para el rol de IAM de nodos híbridos
<a name="_using_aws_auth_configmap_for_hybrid_nodes_iam_role"></a>

En los siguientes pasos, creará o actualizará `aws-auth` ConfigMap con el ARN del rol de IAM de nodos híbridos que creó en los pasos correspondientes a [Cómo preparar las credenciales para los nodos híbridos](hybrid-nodes-creds.md).

1. Compruebe si cuenta con `aws-auth` ConfigMap existente para el clúster. Tenga en cuenta que si utiliza un archivo `kubeconfig` específico, debe utilizar la marca `--kubeconfig`.

   ```
   kubectl describe configmap -n kube-system aws-auth
   ```

1. Si aparece un `aws-auth` ConfigMap, actualícelo según sea necesario.

   1. Abra el ConfigMap para fines de edición.

      ```
      kubectl edit -n kube-system configmap/aws-auth
      ```

   1. Añada una nueva entrada de `mapRoles` según sea necesario. Sustituya `HYBRID_NODES_ROLE_ARN` por el ARN del rol de IAM de nodos híbridos. Tenga en cuenta que `{{SessionName}}` es el formato de plantilla correcto para guardar en el ConfigMap. No lo sustituya por otros valores.

      ```
      data:
        mapRoles: |
        - groups:
          - system:bootstrappers
          - system:nodes
          rolearn: HYBRID_NODES_ROLE_ARN
          username: system:node:{{SessionName}}
      ```

   1. Guarde el archivo y salga del editor de texto.

1. Si no existe un `aws-auth` ConfigMap para el clúster, créelo con el siguiente comando. Sustituya `HYBRID_NODES_ROLE_ARN` por el ARN del rol de IAM de nodos híbridos. Tenga en cuenta que `{{SessionName}}` es el formato de plantilla correcto para guardar en el ConfigMap. No lo sustituya por otros valores.

   ```
   kubectl apply -f=/dev/stdin <<-EOF
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: aws-auth
     namespace: kube-system
   data:
     mapRoles: |
     - groups:
       - system:bootstrappers
       - system:nodes
       rolearn: HYBRID_NODES_ROLE_ARN
       username: system:node:{{SessionName}}
   EOF
   ```

# Ejecución de cargas de trabajo en las instalaciones en nodos híbridos
<a name="hybrid-nodes-tutorial"></a>

En un clúster de EKS con nodos híbridos habilitados, es posible ejecutar aplicaciones en las instalaciones y periféricas en una infraestructura propia con los mismos clústeres, características y herramientas de Amazon EKS que se utilizan en la nube de AWS.

En las siguientes secciones se ofrecen instrucciones paso a paso sobre cómo se utilizan los nodos híbridos.

**Topics**
+ [Cómo conectar nodos híbridos](hybrid-nodes-join.md)
+ [Conexión de nodos híbridos con Bottlerocket](hybrid-nodes-bottlerocket.md)
+ [Actualización de nodos híbridos](hybrid-nodes-upgrade.md)
+ [Aplicación de revisiones a nodos híbridos](hybrid-nodes-security.md)
+ [Cómo eliminar nodos híbridos](hybrid-nodes-remove.md)

# Cómo conectar nodos híbridos
<a name="hybrid-nodes-join"></a>

**nota**  
Los siguientes pasos se aplican a nodos híbridos que ejecutan sistemas operativos compatibles, con excepción de Bottlerocket. Para conocer los pasos para conectar un nodo híbrido que ejecute Bottlerocket, consulte [Conexión de nodos híbridos con Bottlerocket](hybrid-nodes-bottlerocket.md).

En este tema se explica cómo conectar nodos híbridos a un clúster de Amazon EKS. Una vez que los nodos híbridos se unan al clúster, aparecerán con el estado No listos en la consola de Amazon EKS y en las herramientas compatibles con Kubernetes, como kubectl. Tras completar los pasos que se indican en esta página, proceda a [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md) para preparar los nodos híbridos para ejecutar aplicaciones.

## Requisitos previos
<a name="_prerequisites"></a>

Antes de conectar los nodos híbridos al clúster de Amazon EKS, compruebe que se cumplen los requisitos previos indicados.
+ Dispone de conectividad de red entre el entorno en las instalaciones con la región de AWS que aloja el clúster de Amazon EKS. Para obtener más información, consulte [Cómo preparar las redes para los nodos híbridos](hybrid-nodes-networking.md).
+ Dispone de un sistema operativo compatible con los nodos híbridos instalado en los hosts en las instalaciones. Para obtener más información, consulte [Cómo preparar el sistema operativo para los nodos híbridos](hybrid-nodes-os.md).
+ Ha creado el rol de IAM de los nodos híbridos y ha configurado el proveedor de credenciales en las instalaciones (activaciones híbridas de AWS Systems Manager o AWS IAM Roles Anywhere). Para obtener más información, consulte [Cómo preparar las credenciales para los nodos híbridos](hybrid-nodes-creds.md).
+ Ha creado el clúster de Amazon EKS habilitado para nodos híbridos. Para obtener más información, consulte [Cómo crear un clúster de Amazon EKS con nodos híbridos](hybrid-nodes-cluster-create.md).
+ Ha asociado el rol de IAM de nodos híbridos a los permisos de control de acceso basado en roles (RBAC) de Kubernetes. Para obtener más información, consulte [Cómo preparar el acceso al clúster para los nodos híbridos](hybrid-nodes-cluster-prep.md).

## Paso 1: Instalación de la CLI (`nodeadm`) de nodos híbridos en cada host en las instalaciones
<a name="_step_1_install_the_hybrid_nodes_cli_nodeadm_on_each_on_premises_host"></a>

Si incluye la CLI (`nodeadm`) de los Nodos híbridos de Amazon EKS en las imágenes prediseñadas del sistema operativo, puede omitir este paso. Para obtener más información acerca de la versión de los nodos híbridos de `nodeadm`, consulte [Referencia de `nodeadm` de nodos híbridos](hybrid-nodes-nodeadm.md).

La versión de nodos híbridos de `nodeadm` está alojada en Amazon S3, con Amazon CloudFront como frontend. Para instalar `nodeadm` en cada host en las instalaciones, puede ejecutar el siguiente comando desde los hosts en las instalaciones.

 **Para los hosts x86\$164:** 

```
curl -OL 'https://hybrid-assets.eks.amazonaws.com/releases/latest/bin/linux/amd64/nodeadm'
```

 **Para los hosts ARM** 

```
curl -OL 'https://hybrid-assets.eks.amazonaws.com/releases/latest/bin/linux/arm64/nodeadm'
```

Agregue permiso de archivo ejecutable al binario descargado en cada host.

```
chmod +x nodeadm
```

## Paso 2: Instalación de las dependencias de los nodos híbridos con `nodeadm`
<a name="_step_2_install_the_hybrid_nodes_dependencies_with_nodeadm"></a>

Si va a instalar las dependencias de los nodos híbridos en las imágenes prediseñadas del sistema operativo, puede omitir este paso. El comando `nodeadm install` se puede usar para instalar todas las dependencias necesarias para los nodos híbridos. Las dependencias de los nodos híbridos incluyen containerd, kubelet, kubectl y los componentes de AWS SSM o AWS IAM Roles Anywhere. Consulte [Referencia de `nodeadm` de nodos híbridos](hybrid-nodes-nodeadm.md) para obtener más información sobre los componentes y las ubicaciones de los archivos instalados por `nodeadm install`. Consulte [Cómo preparar las redes para los nodos híbridos](hybrid-nodes-networking.md) para nodos híbridos para obtener más información sobre los dominios que se deben permitir en el firewall en las instalaciones durante el proceso de `nodeadm install`.

Ejecute el siguiente comando para instalar las dependencias de los nodos híbridos en el host en las instalaciones. El comando que aparece a continuación se debe ejecutar con un usuario que tenga privilegios de raíz/sudo en el host.

**importante**  
La CLI (`nodeadm`) de nodos híbridos se debe ejecutar con un usuario que tenga acceso sudo/raíz en el host.
+ Sustituya `K8S_VERSION` por la versión secundaria de Kubernetes del clúster de Amazon EKS, por ejemplo `1.31`. Consulte las [versiones compatibles de Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) para obtener una lista de las versiones de Kubernetes compatibles.
+ Sustituya `CREDS_PROVIDER` por el proveedor de credenciales en las instalaciones que utiliza. Los valores válidos son `ssm` para AWS SSM y `iam-ra` para AWS IAM Roles Anywhere.

```
nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER
```

## Paso 3: Conexión de los nodos híbridos al clúster
<a name="_step_3_connect_hybrid_nodes_to_your_cluster"></a>

Antes de conectar los nodos híbridos al clúster, asegúrese de haber permitido el acceso necesario en el firewall en las instalaciones y en el grupo de seguridad del clúster para la comunicación entre el plano de control de Amazon EKS y el nodo híbrido. La mayoría de los problemas de este paso están relacionados con la configuración del firewall, la configuración del grupo de seguridad o la configuración de los roles de IAM de los nodos híbridos.

**importante**  
La CLI (`nodeadm`) de nodos híbridos se debe ejecutar con un usuario que tenga acceso sudo/raíz en el host.

1. Cree un archivo `nodeConfig.yaml` en cada host con los valores de la implementación. Para obtener una descripción completa de los ajustes de configuración disponibles, consulte [Referencia de `nodeadm` de nodos híbridos](hybrid-nodes-nodeadm.md). Si el rol de IAM de los nodos híbridos no tiene permiso para la acción `eks:DescribeCluster`, debe proporcionar el punto de conexión de la API de Kubernetes, el paquete CA del clúster y el CIDR IPv4 del servicio de Kubernetes en la sección del clúster del `nodeConfig.yaml`.

   1. Utilice el `nodeConfig.yaml` de ejemplo que aparece a continuación si utiliza activaciones híbridas de AWS SSM para el proveedor de credenciales en las instalaciones.

      1. Reemplace `CLUSTER_NAME` por el nombre del clúster.

      1. Sustituya `AWS_REGION` por la región de AWS en la que se aloja el clúster. Por ejemplo, `us-west-2`.

      1. Sustituya `ACTIVATION_CODE` por el código de activación que recibió al crear la activación híbrida de AWS SSM. Para obtener más información, consulte [Cómo preparar las credenciales para los nodos híbridos](hybrid-nodes-creds.md).

      1. Sustituya `ACTIVATION_ID` por el ID de activación que recibió al crear la activación híbrida de AWS SSM. Puede recuperar esta información desde la consola de AWS Systems Manager o desde el comando `aws ssm describe-activations` de AWS CLI.

         ```
         apiVersion: node.eks.aws/v1alpha1
         kind: NodeConfig
         spec:
           cluster:
             name: CLUSTER_NAME
             region: AWS_REGION
           hybrid:
             ssm:
               activationCode: ACTIVATION_CODE
               activationId: ACTIVATION_ID
         ```

   1. Utilice el `nodeConfig.yaml` de ejemplo que aparece a continuación si utiliza AWS IAM Roles Anywhere para el proveedor de credenciales en las instalaciones.

      1. Reemplace `CLUSTER_NAME` por el nombre del clúster.

      1. Sustituya `AWS_REGION` por la región de AWS en la que se aloja el clúster. Por ejemplo, `us-west-2`.

      1. Sustituya `NODE_NAME` por el nombre del nodo. El nombre del nodo debe coincidir con el CN del certificado del host si configuró la política de confianza del rol de IAM de nodos híbridos con la condición de recurso `"sts:RoleSessionName": "${aws:PrincipalTag/x509Subject/CN}"`. El `nodeName` que utilice no puede tener más de 64 caracteres.

      1. Sustituya `TRUST_ANCHOR_ARN` por el ARN del anclaje de veracidad que configuró en los pasos que se indican en Cómo preparar credenciales para nodos híbridos.

      1. Sustituya `PROFILE_ARN` por el ARN del anclaje de veracidad que configuró en los pasos de [Cómo preparar las credenciales para los nodos híbridos](hybrid-nodes-creds.md).

      1. Sustituya `ROLE_ARN` por el ARN del rol de IAM de nodos híbridos.

      1. Sustituya `CERTIFICATE_PATH` por la ruta en disco al certificado del nodo. Si no se especifica, el valor predeterminado es `/etc/iam/pki/server.pem`.

      1. Sustituya `KEY_PATH` por la ruta en disco a la clave privada del certificado. Si no se especifica, el valor predeterminado es `/etc/iam/pki/server.key`.

         ```
         apiVersion: node.eks.aws/v1alpha1
         kind: NodeConfig
         spec:
           cluster:
             name: CLUSTER_NAME
             region: AWS_REGION
           hybrid:
             iamRolesAnywhere:
               nodeName: NODE_NAME
               trustAnchorArn: TRUST_ANCHOR_ARN
               profileArn: PROFILE_ARN
               roleArn: ROLE_ARN
               certificatePath: CERTIFICATE_PATH
               privateKeyPath: KEY_PATH
         ```

1. Ejecute el comando `nodeadm init` con el `nodeConfig.yaml` para conectar los nodos híbridos al clúster de Amazon EKS.

   ```
   nodeadm init -c file://nodeConfig.yaml
   ```

Si el comando anterior se ejecuta correctamente, el nodo híbrido se habrá unido a su clúster de Amazon EKS. Puede verificar esto en la consola de Amazon EKS. Para ello, vaya a la pestaña Computación del clúster ([asegúrese de que la entidad principal de IAM tenga permisos de visualización](view-kubernetes-resources.md#view-kubernetes-resources-permissions)) o con `kubectl get nodes`.

**importante**  
Los nodos tendrán el estado `Not Ready`, que es el esperado, y se debe a la falta de una CNI que se ejecute en los nodos híbridos. Si los nodos no se unieron al clúster, consulte [Solución de problemas relacionados con los nodos híbridos](hybrid-nodes-troubleshooting.md).

## Paso 4: Configuración de una CNI para los nodos híbridos
<a name="_step_4_configure_a_cni_for_hybrid_nodes"></a>

Para que los nodos híbridos estén preparados para ejecutar aplicaciones, continúe con los pasos que se indican en [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md).

# Conexión de nodos híbridos con Bottlerocket
<a name="hybrid-nodes-bottlerocket"></a>

Este tema describe cómo conectar nodos híbridos que ejecutan Bottlerocket a un clúster de Amazon EKS. [Bottlerocket](https://aws.amazon.com/bottlerocket/) es una distribución de Linux de código abierto patrocinada y respaldada por AWS. Bottlerocket está diseñado específicamente para alojar cargas de trabajo de contenedores. Con Bottlerocket, puede mejorar la disponibilidad de las implementaciones en contenedores y reducir los costos operativos mediante la automatización de las actualizaciones de la infraestructura de contenedores. Bottlerocket incluye solo el software esencial para ejecutar los contenedores, lo que mejora el uso de los recursos, reduce las amenazas a la seguridad y reduce los gastos de administración.

Solo se admiten las variantes de VMware de Bottlerocket a partir de la versión v1.37.0 con los Nodos híbridos de EKS. Las variantes de VMware de Bottlerocket están disponibles para las versiones v1.28 y posteriores de Kubernetes. Las imágenes del sistema operativo para estas variantes incluyen kubelet, containerd, aws-iam-authenticator y otros requisitos previos de software para los Nodos híbridos de EKS. Puede configurar estos componentes mediante un archivo de [configuración](https://github.com/bottlerocket-os/bottlerocket#settings) de Bottlerocket que incluya datos de usuario codificados en base64 para los contenedores de arranque y administración de Bottlerocket. Configurar estos ajustes permite que Bottlerocket utilice el proveedor de credenciales de los nodos híbridos para autenticarlos en el clúster. Después de que los nodos híbridos se unan al clúster, aparecerán con el estado `Not Ready` en la consola de Amazon EKS y en herramientas compatibles con Kubernetes, como `kubectl`. Tras completar los pasos que se indican en esta página, proceda a [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md) para preparar los nodos híbridos para ejecutar aplicaciones.

## Requisitos previos
<a name="_prerequisites"></a>

Antes de conectar los nodos híbridos al clúster de Amazon EKS, compruebe que se cumplen los requisitos previos indicados.
+ Dispone de conectividad de red entre el entorno en las instalaciones con la región de AWS que aloja el clúster de Amazon EKS. Para obtener más información, consulte [Cómo preparar las redes para los nodos híbridos](hybrid-nodes-networking.md).
+ Ha creado el rol de IAM de los nodos híbridos y ha configurado el proveedor de credenciales en las instalaciones (activaciones híbridas de AWS Systems Manager o AWS IAM Roles Anywhere). Para obtener más información, consulte [Cómo preparar las credenciales para los nodos híbridos](hybrid-nodes-creds.md).
+ Ha creado el clúster de Amazon EKS habilitado para nodos híbridos. Para obtener más información, consulte [Cómo crear un clúster de Amazon EKS con nodos híbridos](hybrid-nodes-cluster-create.md).
+ Ha asociado el rol de IAM de nodos híbridos a los permisos de control de acceso basado en roles (RBAC) de Kubernetes. Para obtener más información, consulte [Cómo preparar el acceso al clúster para los nodos híbridos](hybrid-nodes-cluster-prep.md).

## Paso 1: creación del archivo TOML de configuración de Bottlerocket
<a name="_step_1_create_the_bottlerocket_settings_toml_file"></a>

Para configurar Bottlerocket para nodos híbridos, debe crear un archivo `settings.toml` con la configuración necesaria. El contenido del archivo TOML variará según el proveedor de credenciales que utilice (SSM o IAM Roles Anywhere). Este archivo se transferirá como datos de usuario al aprovisionar la instancia de Bottlerocket.

**nota**  
Los archivos TOML que se proporcionan a continuación solo representan la configuración mínima necesaria para inicializar una máquina VMWare de Bottlerocket como un nodo en un clúster de EKS. Bottlerocket ofrece una amplia gama de opciones de configuración para abordar varios casos de uso diferentes, por lo que, para obtener más opciones de configuración además de la inicialización del nodo híbrido, consulte la [documentación de Bottlerocket](https://bottlerocket.dev/en) a fin de obtener una lista completa de todas las configuraciones documentadas para la versión de Bottlerocket que esté utilizando (por ejemplo, [aquí](https://bottlerocket.dev/en/os/1.51.x/api/settings-index) están todas las configuraciones disponibles para Bottlerocket 1.51.x).

### SSM
<a name="_ssm"></a>

Si utiliza AWS Systems Manager como proveedor de credenciales, cree un archivo `settings.toml` con el siguiente contenido:

```
[settings.kubernetes]
cluster-name = "<cluster-name>"
api-server = "<api-server-endpoint>"
cluster-certificate = "<cluster-certificate-authority>"
hostname-override = "<hostname>"
provider-id = "eks-hybrid:///<region>/<cluster-name>/<hostname>"
authentication-mode = "aws"
cloud-provider = ""
server-tls-bootstrap = true

[settings.network]
hostname = "<hostname>"

[settings.aws]
region = "<region>"

[settings.kubernetes.credential-providers.ecr-credential-provider]
enabled = true
cache-duration = "12h"
image-patterns = [
    "*.dkr.ecr.*.amazonaws.com",
    "*.dkr.ecr.*.amazonaws.com.rproxy.goskope.com.cn",
    "*.dkr.ecr.*.amazonaws.eu",
    "*.dkr.ecr-fips.*.amazonaws.com",
    "*.dkr.ecr-fips.*.amazonaws.eu",
    "public.ecr.aws"
]

[settings.kubernetes.node-labels]
"eks.amazonaws.com/compute-type" = "hybrid"
"eks.amazonaws.com/hybrid-credential-provider" = "ssm"

[settings.host-containers.admin]
enabled = true
user-data = "<base64-encoded-admin-container-userdata>"

[settings.bootstrap-containers.eks-hybrid-setup]
mode = "always"
user-data = "<base64-encoded-bootstrap-container-userdata>"

[settings.host-containers.control]
enabled = true
```

Reemplace los marcadores de posición con los siguientes valores:
+  `<cluster-name>`: el nombre del clúster de Amazon EKS.
+  `<api-server-endpoint>`: el punto de conexión del servidor API del clúster.
+  `<cluster-certificate-authority>`: el paquete CA codificado en base64 del clúster.
+  `<region>`: la región de AWS donde se aloja el clúster, por ejemplo, “us-east-1”.
+  `<hostname>`: el nombre de host de la instancia de Bottlerocket, que se utilizará también como nombre del nodo. Puede ser cualquier valor único de su elección, pero debe cumplir con las [convenciones de nomenclatura de objetos de Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names). Además, el nombre de host que utilice no puede tener más de 64 caracteres. NOTA: Al utilizar el proveedor SSM, este nombre de host y nombre de nodo serán reemplazados por el ID de instancia administrada (por ejemplo, ID `mi-*`) después de que la instancia se registre en SSM.
+  `<base64-encoded-admin-container-userdata>`: el contenido codificado en base64 de la configuración del contenedor de administración de Bottlerocket. Al habilitar el contenedor de administración, se puede conectar a la instancia de Bottlerocket mediante SSH para explorar y depurar el sistema. Aunque esta configuración no es obligatoria, recomendamos habilitarla para facilitar la resolución de problemas. Consulte la [documentación del contenedor de administración de Bottlerocket](https://github.com/bottlerocket-os/bottlerocket-admin-container#authenticating-with-the-admin-container) para obtener más información sobre cómo autenticarse con el contenedor de administración. El contenedor de administración acepta entradas de usuario y clave SSH en formato JSON, por ejemplo,

```
{
  "user": "<ssh-user>",
  "ssh": {
    "authorized-keys": [
      "<ssh-authorized-key>"
    ]
  }
}
```
+  `<base64-encoded-bootstrap-container-userdata>`: el contenido codificado en base64 de la configuración del contenedor de arranque Bottlerocket. Consulte la [documentación del contenedor de arranque de Bottlerocket](https://github.com/bottlerocket-os/bottlerocket-bootstrap-container) para obtener más información sobre su configuración. El contenedor de arranque se encarga de registrar la instancia como una instancia administrada de AWS SSM y de unirla como nodo de Kubernetes en el clúster de Amazon EKS. Los datos de usuario que se transmiten al contenedor de arranque adoptan la forma de una invocación de comando que acepta como entrada el código de activación híbrida SSM y el ID que creó previamente:

```
eks-hybrid-ssm-setup --activation-id=<activation-id> --activation-code=<activation-code> --region=<region>
```

### IAM Roles Anywhere
<a name="_iam_roles_anywhere"></a>

Si utiliza AWS IAM Roles Anywhere como proveedor de credenciales, cree un archivo `settings.toml` con el siguiente contenido:

```
[settings.kubernetes]
cluster-name = "<cluster-name>"
api-server = "<api-server-endpoint>"
cluster-certificate = "<cluster-certificate-authority>"
hostname-override = "<hostname>"
provider-id = "eks-hybrid:///<region>/<cluster-name>/<hostname>"
authentication-mode = "aws"
cloud-provider = ""
server-tls-bootstrap = true

[settings.network]
hostname = "<hostname>"

[settings.aws]
region = "<region>"
config = "<base64-encoded-aws-config-file>"

[settings.kubernetes.credential-providers.ecr-credential-provider]
enabled = true
cache-duration = "12h"
image-patterns = [
    "*.dkr.ecr.*.amazonaws.com",
    "*.dkr.ecr.*.amazonaws.com.rproxy.goskope.com.cn",
    "*.dkr.ecr.*.amazonaws.eu",
    "*.dkr.ecr-fips.*.amazonaws.com",
    "*.dkr.ecr-fips.*.amazonaws.eu",
    "public.ecr.aws"
]

[settings.kubernetes.node-labels]
"eks.amazonaws.com/compute-type" = "hybrid"
"eks.amazonaws.com/hybrid-credential-provider" = "iam-ra"

[settings.host-containers.admin]
enabled = true
user-data = "<base64-encoded-admin-container-userdata>"

[settings.bootstrap-containers.eks-hybrid-setup]
mode = "always"
user-data = "<base64-encoded-bootstrap-container-userdata>"
```

Reemplace los marcadores de posición con los siguientes valores:
+  `<cluster-name>`: el nombre del clúster de Amazon EKS.
+  `<api-server-endpoint>`: el punto de conexión del servidor API del clúster.
+  `<cluster-certificate-authority>`: el paquete CA codificado en base64 del clúster.
+  `<region>`: la región de AWS que aloja el clúster (por ejemplo, “us-east-1”)
+  `<hostname>`: el nombre de host de la instancia de Bottlerocket, que se utilizará también como nombre del nodo. Puede ser cualquier valor único de su elección, pero debe cumplir con las [convenciones de nomenclatura de objetos de Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names). Además, el nombre de host que utilice no puede tener más de 64 caracteres. NOTA: Cuando se utiliza el proveedor IAM-RA, el nombre del nodo debe coincidir con el CN del certificado en el host si ha configurado la política de confianza del rol de IAM de Nodos híbridos con la condición de recurso `"sts:RoleSessionName": "${aws:PrincipalTag/x509Subject/CN}"`.
+  AWS: el contenido codificado en base64 del archivo de configuración de `<base64-encoded-aws-config-file>`. El contenido del archivo debe ser el siguiente:

```
[default]
credential_process = aws_signing_helper credential-process --certificate /root/.aws/node.crt --private-key /root/.aws/node.key --profile-arn <profile-arn> --role-arn <role-arn> --trust-anchor-arn <trust-anchor-arn> --role-session-name <role-session-name>
```
+  `<base64-encoded-admin-container-userdata>`: el contenido codificado en base64 de la configuración del contenedor de administración de Bottlerocket. Al habilitar el contenedor de administración, se puede conectar a la instancia de Bottlerocket mediante SSH para explorar y depurar el sistema. Aunque esta configuración no es obligatoria, recomendamos habilitarla para facilitar la resolución de problemas. Consulte la [documentación del contenedor de administración de Bottlerocket](https://github.com/bottlerocket-os/bottlerocket-admin-container#authenticating-with-the-admin-container) para obtener más información sobre cómo autenticarse con el contenedor de administración. El contenedor de administración acepta entradas de usuario y clave SSH en formato JSON, por ejemplo,

```
{
  "user": "<ssh-user>",
  "ssh": {
    "authorized-keys": [
      "<ssh-authorized-key>"
    ]
  }
}
```
+  `<base64-encoded-bootstrap-container-userdata>`: el contenido codificado en base64 de la configuración del contenedor de arranque Bottlerocket. Consulte la [documentación del contenedor de arranque de Bottlerocket](https://github.com/bottlerocket-os/bottlerocket-bootstrap-container) para obtener más información sobre su configuración. El contenedor de arranque se encarga de crear el certificado de host de IAM Roles Anywhere y los archivos de clave privada del certificado en la instancia. Estas serán consumidas por el `aws_signing_helper` para obtener credenciales temporales para autenticarse con el clúster de Amazon EKS. Los datos de usuario que se transmiten al contenedor de arranque adoptan la forma de una invocación de comando que acepta como entrada el contenido del certificado y la clave privada que creó previamente:

```
eks-hybrid-iam-ra-setup --certificate=<certificate> --key=<private-key>
```

## Paso 2: aprovisionamiento de la máquina virtual Bottlerocket vSphere con datos de usuario
<a name="_step_2_provision_the_bottlerocket_vsphere_vm_with_user_data"></a>

Una vez que haya creado el archivo TOML, transmítalo como datos de usuario durante la creación de la máquina virtual en vSphere. Tenga en cuenta que los datos de usuario se deben configurar antes de que la máquina virtual se encienda por primera vez. Por lo tanto, deberá proporcionarlos al crear la instancia o, si desea crear la máquina virtual con anticipación, esta debe permanecer en estado apagado (poweredOff) hasta que configure los datos de usuario. Por ejemplo, si utiliza la CLI de `govc`:

### Cómo crear la máquina virtual por primera vez
<a name="_creating_vm_for_the_first_time"></a>

```
govc vm.create \
  -on=true \
  -c=2 \
  -m=4096 \
  -net.adapter=<network-adapter> \
  -net=<network-name> \
  -e guestinfo.userdata.encoding="base64" \
  -e guestinfo.userdata="$(base64 -w0 settings.toml)" \
  -template=<template-name> \
  <vm-name>
```

### Cómo actualizar los datos de usuario de una máquina virtual existente
<a name="_updating_user_data_for_an_existing_vm"></a>

```
govc vm.create \
    -on=false \
    -c=2 \
    -m=4096 \
    -net.adapter=<network-adapter> \
    -net=<network-name> \
    -template=<template-name> \
    <vm-name>

govc vm.change
    -vm <vm-name> \
    -e guestinfo.userdata="$(base64 -w0 settings.toml)" \
    -e guestinfo.userdata.encoding="base64"

govc vm.power -on <vm-name>
```

En las secciones anteriores, la opción `-e guestinfo.userdata.encoding="base64"` especifica que los datos de usuario están codificados en base64. La opción `-e guestinfo.userdata` transmite el contenido codificado en base64 del archivo `settings.toml` como datos de usuario a la instancia de Bottlerocket. Reemplace los marcadores de posición con los valores específicos, como la plantilla OVA de Bottlerocket y los detalles de la red.

## Paso 3: verificación de la conexión del nodo híbrido
<a name="_step_3_verify_the_hybrid_node_connection"></a>

Después de que la instancia de Bottlerocket inicie, intentará unirse al clúster de Amazon EKS. Para verificar la conexión, ingrese a la consola de Amazon EKS y diríjase a la pestaña Computación del clúster o ejecute el siguiente comando:

```
kubectl get nodes
```

**importante**  
Los nodos tendrán el estado `Not Ready`, que es el esperado, y se debe a la falta de una CNI que se ejecute en los nodos híbridos. Si los nodos no se unieron al clúster, consulte [Solución de problemas relacionados con los nodos híbridos](hybrid-nodes-troubleshooting.md).

## Paso 4: Configuración de una CNI para los nodos híbridos
<a name="_step_4_configure_a_cni_for_hybrid_nodes"></a>

Para que los nodos híbridos estén preparados para ejecutar aplicaciones, continúe con los pasos que se indican en [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md).

# Actualización de nodos híbridos para el clúster
<a name="hybrid-nodes-upgrade"></a>

Las instrucciones para actualizar los nodos híbridos son similares a aquellas de los nodos autoadministrados de Amazon EKS que se ejecutan en Amazon EC2. Le recomendamos crear nuevos nodos híbridos en la versión de Kubernetes de destino, migrar correctamente las aplicaciones existentes a los nodos híbridos de la nueva versión de Kubernetes y eliminar los nodos híbridos de la versión antigua de Kubernetes del clúster. Asegúrese de revisar las [Prácticas recomendadas de Amazon EKS](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html) para actualizaciones antes de iniciar una actualización. Los Nodos híbridos de Amazon EKS cuentan con el mismo [soporte para versiones de Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) que los clústeres de Amazon EKS con nodos en la nube, incluidos el soporte estándar y ampliado.

Los Nodos híbridos de Amazon EKS siguen la misma [política de discrepancia de versiones](https://kubernetes.io/releases/version-skew-policy/#supported-version-skew) para los nodos que el proyecto fuente de Kubernetes. Los Nodos híbridos de Amazon EKS no pueden estar en una versión más reciente que el plano de control de Amazon EKS, y los nodos híbridos pueden tener hasta tres versiones menores de Kubernetes más antiguas que la versión menor del plano de control de Amazon EKS.

Si no dispone de capacidad de sobra para crear nuevos nodos híbridos en la versión de Kubernetes de destino para una estrategia de actualización de migración de transición, también puede utilizar la CLI de Nodos híbridos de Amazon EKS (`nodeadm`) para actualizar la versión de Kubernetes de los nodos híbridos in situ.

**importante**  
Si actualiza los nodos híbridos in situ con `nodeadm`, se produce un tiempo de inactividad del nodo durante el proceso en el que se apaga la versión anterior de los componentes de Kubernetes y se instalan e inician los componentes de la nueva versión de Kubernetes.

## Requisitos previos
<a name="_prerequisites"></a>

Antes de efectuar la actualización, asegúrese de que cumple los siguientes requisitos previos.
+ La versión de Kubernetes de destino para la actualización de los nodos híbridos debe ser igual o inferior a la versión del plano de control de Amazon EKS.
+ Si sigue una estrategia de actualización de migración de transición, los nuevos nodos híbridos que instale en la versión de Kubernetes de destino deben cumplir los requisitos [Configuración previa requerida para los nodos híbridos](hybrid-nodes-prereqs.md). Esto implica contar con direcciones IP dentro del CIDR de red de nodos remotos que transmitió durante la creación del clúster de Amazon EKS.
+ Tanto para la migración de transición como para las actualizaciones en las instalaciones, los nodos híbridos deben tener acceso a los [dominios necesarios](hybrid-nodes-networking.md#hybrid-nodes-networking-on-prem) para obtener las nuevas versiones de las dependencias de los nodos híbridos.
+ Debe tener kubectl instalado en la máquina local o en la instancia que utilice para interactuar con el punto de conexión de la API de Kubernetes de Amazon EKS.
+ La versión de la CNI debe ser compatible con la versión de Kubernetes a la que se actualiza. En caso contrario, actualice la versión de la CNI antes de actualizar los nodos híbridos. Para obtener más información, consulte [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md).

## Actualizaciones de migración por transición (azul/verde)
<a name="hybrid-nodes-upgrade-cutover"></a>

 Las *actualizaciones de migración por transición* se refieren al proceso de crear nuevos nodos híbridos en hosts nuevos con la versión de destino de Kubernetes, migrar de forma controlada las aplicaciones existentes a los nuevos nodos híbridos con la versión de destino de Kubernetes y eliminar del clúster los nodos híbridos con la versión anterior de Kubernetes. Esta estrategia también se conoce como una migración azul/verde.

1. Siga los siguientes pasos [Cómo conectar nodos híbridos](hybrid-nodes-join.md) para conectar los nuevos hosts como nodos híbridos. Al ejecutar el comando `nodeadm install`, utilice la versión de Kubernetes de destino.

1. Habilite la comunicación entre los nuevos nodos híbridos en la versión de Kubernetes de destino y los nodos híbridos en la versión antigua de Kubernetes. Esta configuración permite que los pods se comuniquen entre sí mientras la carga de trabajo se migra a los nodos híbridos de la versión de Kubernetes de destino.

1. Confirme que los nodos híbridos de la versión de Kubernetes de destino se han unido correctamente al clúster y que se encuentran en estado Preparado.

1. Utilice el siguiente comando para marcar como no programables cada uno de los nodos que desea eliminar. Esto es para que los nuevos pods no se programen ni se vuelvan a programar en los nodos que se van a reemplazar. Para obtener más información, consulte [kubectl cordon](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_cordon/) en la documentación de Kubernetes. Sustituya `NODE_NAME` por el nombre de los nodos híbridos en la versión anterior de Kubernetes.

   ```
   kubectl cordon NODE_NAME
   ```

   Puede identificar y marcar como no programables todos los nodos de una versión específica de Kubernetes (en este caso, la `1.28`) con el siguiente fragmento de código.

   ```
   K8S_VERSION=1.28
   for node in $(kubectl get nodes -o json | jq --arg K8S_VERSION "$K8S_VERSION" -r '.items[] | select(.status.nodeInfo.kubeletVersion | match("\($K8S_VERSION)")).metadata.name')
   do
       echo "Cordoning $node"
       kubectl cordon $node
   done
   ```

1. Si la implementación actual ejecuta menos de dos réplicas de CoreDNS en los nodos híbridos, escale horizontalmente la implementación a al menos dos réplicas. Le recomendamos ejecutar al menos dos réplicas de CoreDNS en nodos híbridos para garantizar la resistencia durante las operaciones normales.

   ```
   kubectl scale deployments/coredns --replicas=2 -n kube-system
   ```

1. Vacíe cada uno de los nodos híbridos de la versión antigua de Kubernetes que desee eliminar del clúster con el siguiente comando. Para obtener más información sobre el vaciado de nodos, consulte [Vaciado seguro de nodos](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) en la documentación de Kubernetes. Sustituya `NODE_NAME` por el nombre de los nodos híbridos en la versión anterior de Kubernetes.

   ```
   kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data
   ```

   Puede identificar todos los nodos de una versión concreta de Kubernetes (en este caso, `1.28`) y vaciarlos con el siguiente fragmento de código.

   ```
   K8S_VERSION=1.28
   for node in $(kubectl get nodes -o json | jq --arg K8S_VERSION "$K8S_VERSION" -r '.items[] | select(.status.nodeInfo.kubeletVersion | match("\($K8S_VERSION)")).metadata.name')
   do
       echo "Draining $node"
       kubectl drain $node --ignore-daemonsets --delete-emptydir-data
   done
   ```

1. Puede usar `nodeadm` para detener y eliminar los artefactos de los nodos híbridos del host. Debe ejecutar `nodeadm` con un usuario que tenga privilegios raíz/sudo. De forma predeterminada, `nodeadm uninstall` no procederá si quedan pods en el nodo. Para obtener más información, consulte [Referencia de `nodeadm` de nodos híbridos](hybrid-nodes-nodeadm.md).

   ```
   nodeadm uninstall
   ```

1. Una vez que los artefactos de los nodos híbridos estén detenidos y desinstalados, elimine el recurso de nodo del clúster.

   ```
   kubectl delete node node-name
   ```

   Puede identificar todos los nodos de una versión concreta de Kubernetes (en este caso, `1.28`) y eliminarlos con el siguiente fragmento de código.

   ```
   K8S_VERSION=1.28
   for node in $(kubectl get nodes -o json | jq --arg K8S_VERSION "$K8S_VERSION" -r '.items[] | select(.status.nodeInfo.kubeletVersion | match("\($K8S_VERSION)")).metadata.name')
   do
       echo "Deleting $node"
       kubectl delete node $node
   done
   ```

1. Según la CNI que elija, es posible que, aún después de ejecutar los pasos anteriores, queden artefactos en los nodos híbridos. Para obtener más información, consulte [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md).

## Actualizaciones locales
<a name="hybrid-nodes-upgrade-inplace"></a>

El proceso de actualización in situ consiste en utilizar `nodeadm upgrade` para actualizar la versión de Kubernetes para nodos híbridos sin utilizar nuevos hosts físicos o virtuales ni una estrategia de migración de transición. El proceso `nodeadm upgrade` apaga los componentes de Kubernetes antiguos existentes que se ejecutan en el nodo híbrido, desinstala los componentes de Kubernetes antiguos existentes, instala los nuevos componentes de Kubernetes de destino e inicia los nuevos componentes de Kubernetes de destino. Se recomienda enfáticamente actualizar un nodo a la vez para minimizar el impacto en las aplicaciones que se ejecutan en los nodos híbridos. La duración de este proceso depende del ancho de banda y la latencia de la red.

1. Utilice el siguiente comando para marcar como no programable el nodo que está en proceso de actualizar. Esto es para que los nuevos pods no se programen o reprogramen en el nodo que se actualiza. Para obtener más información, consulte [kubectl cordon](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_cordon/) en la documentación de Kubernetes. Sustituya `NODE_NAME` por el nombre del nodo híbrido que se actualiza

   ```
   kubectl cordon NODE_NAME
   ```

1. Vacíe el nodo que se actualiza con el siguiente comando. Para obtener más información sobre el vaciado de nodos, consulte [Vaciado seguro de nodos](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) en la documentación de Kubernetes. Sustituya `NODE_NAME` por el nombre del nodo híbrido que se actualiza.

   ```
   kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data
   ```

1. Ejecute `nodeadm upgrade` en el nodo híbrido que se actualiza. Debe ejecutar `nodeadm` con un usuario que tenga privilegios raíz/sudo. El nombre del nodo se conserva durante la actualización para los proveedores de credenciales de AWS SSM y AWS IAM Roles Anywhere. No es posible cambiar de proveedor de credenciales durante el proceso de actualización. Consulte [Referencia de `nodeadm` de nodos híbridos](hybrid-nodes-nodeadm.md) para conocer los valores de configuración de `nodeConfig.yaml`. Sustituya `K8S_VERSION` por la versión de Kubernetes de destino a la que se actualiza.

   ```
   nodeadm upgrade K8S_VERSION -c file://nodeConfig.yaml
   ```

1. Para permitir que los pods se programen en el nodo después de la actualización, escriba lo siguiente. Sustituya `NODE_NAME` por el nombre del nodo.

   ```
   kubectl uncordon NODE_NAME
   ```

1. Observe el estado de los nodos híbridos y espere a que se apaguen y reinicien en la nueva versión de Kubernetes con el estado Preparado.

   ```
   kubectl get nodes -o wide -w
   ```

# Aplicación de revisiones de actualizaciones de seguridad para nodos híbridos
<a name="hybrid-nodes-security"></a>

Este tema describe el procedimiento para aplicar revisiones de actualizaciones de seguridad en el lugar para paquetes y dependencias específicos que se ejecutan en los nodos híbridos. Como buena práctica, recomendamos actualizar periódicamente los nodos híbridos para recibir actualizaciones relacionadas con vulnerabilidades (CVE) y revisiones de seguridad.

Para conocer los pasos para actualizar la versión de Kubernetes, consulte [Actualización de nodos híbridos para el clúster](hybrid-nodes-upgrade.md).

Un ejemplo de software que podría requerir revisiones de seguridad es `containerd`.

## `Containerd`
<a name="_containerd"></a>

 `containerd` es el tiempo de ejecución de contenedores estándar de Kubernetes y una dependencia fundamental para los nodos híbridos de EKS. Se encarga de administrar el ciclo de vida de los contenedores, incluida la extracción de imágenes y la ejecución de los contenedores. En un nodo híbrido, puede instalar `containerd` mediante la [CLI de nodeadm](https://docs.aws.amazon.com/eks/latest/userguide/hybrid-nodes-nodeadm.html) o de forma manual. Según el sistema operativo del nodo, `nodeadm` instalará `containerd` desde el paquete distribuido por el sistema operativo o desde el paquete de Docker.

Si se publica un CVE en `containerd`, tendrá las siguientes opciones para actualizar a la versión revisada de `containerd` en los nodos híbridos.

## Paso 1: Cómo comprobar si la revisión se ha publicado en los administradores de paquetes
<a name="_step_1_check_if_the_patch_published_to_package_managers"></a>

Para verificar si la revisión de la CVE de `containerd` ha sido publicada en el administrador de paquetes de cada sistema operativo, puede consultar los boletines de seguridad correspondientes:
+  [Amazon Linux 2023](https://alas.aws.amazon.com/alas2023.html) 
+  [RHEL](https://access.redhat.com/security/security-updates/security-advisories) 
+  [Ubuntu 20.04](https://ubuntu.com/security/notices?order=newest&release=focal) 
+  [Ubuntu 22.04](https://ubuntu.com/security/notices?order=newest&release=jammy) 
+  [Ubuntu 24.04](https://ubuntu.com/security/notices?order=newest&release=noble) 

Si utiliza el repositorio de Docker como origen de `containerd`, puede consultar los [Anuncios de seguridad de Docker](https://docs.docker.com/security/security-announcements/) para verificar la disponibilidad de la versión revisada en el repositorio de Docker.

## Paso 2: Cómo elegir el método para instalar la revisión
<a name="_step_2_choose_the_method_to_install_the_patch"></a>

Existen tres métodos para aplicar revisiones e instalar actualizaciones de seguridad en el lugar en los nodos. El método que puede utilizar depende de si la revisión está disponible en el administrador de paquetes del sistema operativo.

1. Instale revisiones con las `nodeadm upgrade` publicadas en los administradores de paquetes. Consulte el [Paso 2.a](#hybrid-nodes-security-nodeadm).

1. Instale revisiones directamente con los administradores de paquetes. Consulte el [Paso 2.b](#hybrid-nodes-security-package).

1. Instale revisiones personalizadas que no estén publicadas en los administradores de paquetes. Tenga en cuenta que existen consideraciones especiales para las revisiones personalizadas de `containerd`. Consulte el [Paso 2.c](#hybrid-nodes-security-manual).

## Paso 2.a: Aplicación de revisiones con `nodeadm upgrade`
<a name="hybrid-nodes-security-nodeadm"></a>

Una vez que haya confirmado que la revisión de la CVE de `containerd` ha sido publicada en los repositorios del sistema operativo o de Docker (ya sea Apt o RPM), puede utilizar el comando `nodeadm upgrade` para actualizar a la última versión de `containerd`. Como no se trata de una actualización de versión de Kubernetes, debe proporcionar la versión actual de Kubernetes al comando de actualización `nodeadm`.

```
nodeadm upgrade K8S_VERSION --config-source file:///root/nodeConfig.yaml
```

## Paso 2.b: Aplicación de revisiones con los administradores de paquetes del sistema operativo
<a name="hybrid-nodes-security-package"></a>

Como alternativa, también puede actualizar a través del administrador de paquetes correspondiente y usarlo para actualizar el paquete de `containerd` de la siguiente manera.

 **Amazon Linux 2023** 

```
sudo yum update -y
sudo yum install -y containerd
```

 **RHEL** 

```
sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
sudo yum update -y
sudo yum install -y containerd
```

 **Ubuntu** 

```
sudo mkdir -p /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update -y
sudo apt install -y --only-upgrade containerd.io
```

## Paso 2.c: Revisión de CVE de `Containerd` no publicada en los administradores de paquetes
<a name="hybrid-nodes-security-manual"></a>

Si la versión revisada de `containerd` solo está disponible por otros medios, en lugar de en el administrador de paquetes; por ejemplo, en las publicaciones de GitHub, puede instalar `containerd` desde el sitio oficial de GitHub.

1. Si la máquina ya se ha unido al clúster como un nodo híbrido, entonces debe ejecutar el comando `nodeadm uninstall`.

1. Instale los binarios oficiales de `containerd`. Puede seguir los [pasos de instalación oficiales](https://github.com/containerd/containerd/blob/main/docs/getting-started.md#option-1-from-the-official-binaries) disponibles en GitHub.

1. Ejecute el comando `nodeadm install` con el argumento `--containerd-source` establecido en `none`, lo que omitirá la instalación de `containerd` a través de `nodeadm`. Puede usar el valor de `none` en el origen de `containerd` para cualquier sistema operativo que el nodo ejecute.

   ```
   nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER --containerd-source none
   ```

# Cómo eliminar nodos híbridos
<a name="hybrid-nodes-remove"></a>

En este tema se explica cómo eliminar nodos híbridos del clúster de Amazon EKS. Debe eliminar los nodos híbridos con las herramientas compatibles con Kubernetes que elija, como [kubectl](https://kubernetes.io/docs/reference/kubectl/). El cobro por los nodos híbridos se detiene cuando el objeto del nodo se elimina del clúster de Amazon EKS. Para obtener más información sobre los precios de los nodos híbridos, consulte los [Precios de Amazon EKS](https://aws.amazon.com/eks/pricing/).

**importante**  
La eliminación de nodos interrumpe las cargas de trabajo en ejecución en el nodo. Antes de eliminar los nodos híbridos, le recomendamos vaciar primero el nodo para trasladar los pods a otro nodo activo. Para obtener más información sobre el vaciado de nodos, consulte [Vaciado seguro de nodos](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) en la documentación de Kubernetes.

Ejecute los pasos de kubectl que se indican a continuación desde la máquina o instancia local que utilice para interactuar con el punto de conexión de la API de Kubernetes del clúster de Amazon EKS. Si utiliza un archivo `kubeconfig` específico, utilice la marca `--kubeconfig`.

## Paso 1: Enumeración de los nodos
<a name="_step_1_list_your_nodes"></a>

```
kubectl get nodes
```

## Paso 2: Vaciado del nodo
<a name="_step_2_drain_your_node"></a>

Consulte [Vaciado de kubectl](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_drain/) en la documentación de Kubernetes para obtener más información sobre el comando `kubectl drain`.

```
kubectl drain --ignore-daemonsets <node-name>
```

## Paso 3: Detención y desinstalación de artefactos de nodos híbridos
<a name="_step_3_stop_and_uninstall_hybrid_nodes_artifacts"></a>

Puede usar la CLI (`nodeadm`) de los Nodos híbridos de Amazon EKS para detener y eliminar los artefactos de nodos híbridos del host. Debe ejecutar `nodeadm` con un usuario que tenga privilegios raíz/sudo. De forma predeterminada, `nodeadm uninstall` no procederá si quedan pods en el nodo. Si utiliza AWS Systems Manager (SSM) como proveedor de credenciales, el comando `nodeadm uninstall` anula el registro del host como instancia administrada por AWS SSM. Para obtener más información, consulte [Referencia de `nodeadm` de nodos híbridos](hybrid-nodes-nodeadm.md).

```
nodeadm uninstall
```

## Paso 4: Cómo eliminar el nodo del clúster
<a name="_step_4_delete_your_node_from_the_cluster"></a>

Una vez que los artefactos de los nodos híbridos estén detenidos y desinstalados, elimine el recurso de nodo del clúster.

```
kubectl delete node <node-name>
```

## Paso 5: Cómo comprobar si hay artefactos restantes
<a name="_step_5_check_for_remaining_artifacts"></a>

Según la CNI que elija, es posible que, aún después de ejecutar los pasos anteriores, queden artefactos en los nodos híbridos. Para obtener más información, consulte [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md).

# Configuración de redes de aplicaciones, complementos y webhooks para nodos híbridos
<a name="hybrid-nodes-configure"></a>

Después de crear un clúster de EKS para nodos híbridos, configure capacidades adicionales para las redes de aplicaciones (CNI, BGP, entrada, equilibrio de carga, políticas de red), complementos, webhooks y configuraciones de proxy. Para ver la lista completa de los complementos de EKS y de la comunidad que son compatibles con los nodos híbridos, consulte [Cómo configurar complementos para nodos híbridos](hybrid-nodes-add-ons.md).

 **Información del clúster de EKS:** EKS incluye comprobaciones de información para detectar errores en la configuración de los nodos híbridos que puedan afectar a la funcionalidad del clúster o de las cargas de trabajo. Para obtener más información sobre información del clúster, consulte [Preparación para las actualizaciones de las versiones de Kubernetes y solución de problemas de configuración incorrecta con información sobre clústeres](cluster-insights.md).

A continuación, se enumeran las capacidades y complementos comunes que puede utilizar con los nodos híbridos:
+  **Interfaz de red de contenedores (CNI)**: AWS admite [Cilium](https://docs.cilium.io/en/stable/index.html) como CNI para nodos híbridos. Para obtener más información, consulte [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md). Tenga en cuenta que la CNI de AWS VPC no se puede utilizar con nodos híbridos.
+  **CoreDNS y `kube-proxy`**: CoreDNS y `kube-proxy` se instalan automáticamente cuando los nodos híbridos se unen al clúster de EKS. Estos complementos se pueden administrar como complementos de EKS tras la creación del clúster.
+  **Entrada y equilibrio de carga**: puede utilizar el Controlador del equilibrador de carga de AWS y el Equilibrador de carga de aplicación (ALB) o el Equilibrador de carga de red (NLB) con el tipo de destino `ip` para las cargas de trabajo que se ejecutan en nodos híbridos. AWS es compatible con las características integradas de equilibrio de carga de entrada, puerta de enlace y el servicio de Kubernetes de Cilium para las cargas de trabajo que se ejecutan en nodos híbridos. Para obtener más información, consulte [Configuración de Kubernetes Ingress para nodos híbridos](hybrid-nodes-ingress.md) y [Configuración de servicios del tipo LoadBalancer para nodos híbridos](hybrid-nodes-load-balancing.md).
+  **Métricas**: puede utilizar raspadores sin agente de Amazon Managed Service para Prometheus (AMP), AWS Distro para Open Telemetry (ADOT) y el agente de observabilidad de Amazon CloudWatch con nodos híbridos. Para utilizar los raspadores sin agente de AMP para métricas de pods en nodos híbridos, los pods deben ser accesibles desde la VPC que se utiliza para el clúster de EKS.
+  **Registros**: puede habilitar el registro del plano de control de EKS para clústeres habilitados para nodos híbridos. Puede utilizar el complemento ADOT de EKS y el complemento de agente de observabilidad de Amazon CloudWatch para EKS para el registro de nodos híbridos y pods.
+  **Pod Identities y los IRSA**: puede usar Pod Identities de EKS y roles de IAM para cuentas de servicio (IRSA) con aplicaciones que se ejecutan en nodos híbridos para permitir un acceso detallado para los pods que se ejecutan en nodos híbridos con otros servicios de AWS.
+  **Webhooks**: si ejecuta webhooks, consulte [Configuración de webhooks para nodos híbridos](hybrid-nodes-webhooks.md) para conocer las consideraciones y los pasos para ejecutarlos opcionalmente en nodos en la nube, en caso de que no sea posible enrutar las redes de pods en las instalaciones.
+  **Proxy**: si utiliza un servidor proxy en el entorno en las instalaciones para el tráfico que sale del centro de datos o del entorno periférico, puede configurar los nodos híbridos y el clúster de modo que utilicen el servidor proxy. Para obtener más información, consulte [Configuración del proxy para nodos híbridos](hybrid-nodes-proxy.md).

**Topics**
+ [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md)
+ [Cómo configurar complementos para nodos híbridos](hybrid-nodes-add-ons.md)
+ [Configuración de webhooks para nodos híbridos](hybrid-nodes-webhooks.md)
+ [Configuración del proxy para nodos híbridos](hybrid-nodes-proxy.md)
+ [Configuración del BGP de Cilium para nodos híbridos](hybrid-nodes-cilium-bgp.md)
+ [Configuración de Kubernetes Ingress para nodos híbridos](hybrid-nodes-ingress.md)
+ [Configuración de servicios del tipo LoadBalancer para nodos híbridos](hybrid-nodes-load-balancing.md)
+ [Configuración de políticas de red de Kubernetes para nodos híbridos](hybrid-nodes-network-policies.md)

# Configuración de una CNI para nodos híbridos
<a name="hybrid-nodes-cni"></a>

Cilium es la interfaz de red de contenedores (CNI) compatible con AWS para los Nodos híbridos de Amazon EKS. Debe instalar una CNI para que los nodos híbridos estén listos para atender cargas de trabajo. Los nodos híbridos aparecen con el estado `Not Ready` hasta que una CNI está en ejecución. Puede administrar la CNI con las herramientas que elija, como Helm. Las instrucciones de esta página tratan la administración del ciclo de vida de Cilium (instalar, actualizar, eliminar). Consulte [Información general sobre Cilium Ingress y Cilium Gateway](hybrid-nodes-ingress.md#hybrid-nodes-ingress-cilium), [LoadBalancer del tipo de servicio](hybrid-nodes-ingress.md#hybrid-nodes-ingress-cilium-loadbalancer) y [Configuración de políticas de red de Kubernetes para nodos híbridos](hybrid-nodes-network-policies.md) para saber cómo configurar Cilium para las políticas de entrada, equilibrio de carga y red.

Cilium no es compatibles con AWS cuando se ejecuta en nodos en la nube de AWS. La CNI de Amazon VPC no es compatible con los nodos híbridos y está configurada con antiafinidad para la etiqueta `eks.amazonaws.com/compute-type: hybrid`.

La documentación de Calico que aparecía anteriormente en esta página se ha trasladado al [repositorio de ejemplos de Nodos híbridos de EKS](https://github.com/aws-samples/eks-hybrid-examples).

## Compatibilidad de versiones
<a name="hybrid-nodes-cilium-version-compatibility"></a>

Las versiones `v1.17.x` y `v1.18.x` de Cilium son compatibles con los Nodos híbridos de EKS para todas las versiones de Kubernetes compatibles con Amazon EKS.

**nota**  
 **Requisito del kernel de Cilium v1.18.3**: debido a los requisitos del kernel (kernel de Linux >= 5.10), Cilium v1.18.3 no es compatible con:
+ Ubuntu 20.04
+ Red Hat Enterprise Linux (RHEL) 8

Para conocer los requisitos del sistema, consulte los [requisitos del sistema de Cilium](https://docs.cilium.io/en/stable/operations/system_requirements/).

Consulte la [compatibilidad de versiones de Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) para ver las versiones que admite Amazon EKS. Los Nodos híbridos de EKS tienen la misma compatibilidad de versiones de Kubernetes que los clústeres de Amazon EKS con nodos en la nube.

## Capacidades compatibles
<a name="hybrid-nodes-cilium-support"></a>

 AWS mantiene versiones de Cilium para los Nodos híbridos de EKS que se basan en el proyecto de código abierto [Cilium](https://github.com/cilium/cilium). Para recibir soporte de AWS para Cilium, debe utilizar las versiones de Cilium mantenidas por AWS y las versiones compatibles de Cilium.

 AWS ofrece soporte técnico para las configuraciones predeterminadas de las siguientes capacidades de Cilium para su uso con Nodos híbridos de EKS. Si planea utilizar la funcionalidad fuera del ámbito del soporte de AWS, es recomendable obtener soporte comercial alternativo para Cilium o contar con expertos internos que puedan resolver problemas y contribuir con correcciones al proyecto de Cilium.


| Característica Cilium | Compatible con AWS  | 
| --- | --- | 
|  Conformidad de la red Kubernetes  |  Sí  | 
|  Conectividad del clúster principal  |  Sí  | 
|  Familia de IP  |  IPv4  | 
|  Administración del ciclo de vida  |  Helm  | 
|  Modos de redes  |  Encapsulación mediante VXLAN  | 
|  Administración de direcciones IP (IPAM)  |  Ámbito del clúster de IPAM de Cilium  | 
|  Política de red  |  Política de red de Kubernetes  | 
|  Protocolo de puerta de enlace fronteriza (BGP)  |  Cilium BGP Control Plane  | 
|  Kubernetes Ingress  |  Cilium Ingress, Cilium Gateway  | 
|  Asignación de IP de LoadBalancer de servicio  |  Cilium Load Balancer IPAM  | 
|  Anuncio de dirección IP de LoadBalancer de servicio  |  Cilium BGP Control Plane  | 
|  Reemplazo de kube-proxy  |  Sí  | 

## Consideraciones sobre Cilium
<a name="hybrid-nodes-cilium-considerations"></a>
+  **Repositorio de Helm**: AWS aloja el gráfico de Helm de Cilium en Amazon Elastic Container Registry Público (Amazon ECR Público) en [Amazon EKS Cilium/Cilium](https://gallery.ecr.aws/eks/cilium/cilium). Las versiones disponibles incluyen lo siguiente:
  + Cilium v1.17.9: `oci://public.ecr.aws/eks/cilium/cilium:1.17.9-0` 
  + Cilium v1.18.3: `oci://public.ecr.aws/eks/cilium/cilium:1.18.3-0` 

    Los comandos de este tema utilizan este repositorio. Tenga en cuenta que ciertos comandos `helm repo` no son válidos para los repositorios de Helm en Amazon ECR Público, por lo que no puede hacer referencia a este repositorio desde un nombre de repositorio de Helm local. En su lugar, use el URI completo en la mayoría de los comandos.
+ De forma predeterminada, Cilium está configurado para ejecutarse en modo de superposición/túnel con VXLAN como [método de encapsulación](https://docs.cilium.io/en/stable/network/concepts/routing/#encapsulation). Este modo es el que impone menos requisitos a la red física subyacente.
+ De forma predeterminada, Cilium [enmascara](https://docs.cilium.io/en/stable/network/concepts/masquerading/) la dirección IP de origen de todo el tráfico de pods que sale del clúster, asignándole la dirección IP del nodo. Si desactiva el enmascarado, los CIDR de los pods deben ser enrutables en la red en las instalaciones.
+ Si ejecuta webhooks en nodos híbridos, los CIDR de los pods deben ser enrutable en la red en las instalaciones. Si los CIDR de los pods no son enrutables en la red en las instalaciones, se recomienda ejecutar los webhooks en los nodos en la nube del mismo clúster. Para obtener más información, consulte [Configuración de webhooks para nodos híbridos](hybrid-nodes-webhooks.md) y [Cómo preparar las redes para los nodos híbridos](hybrid-nodes-networking.md).
+  AWS recomienda usar la funcionalidad del BGP integrada de Cilium para hacer que los CIDR de los pods sean enrutables en la red en las instalaciones. Para obtener más información sobre cómo configurar el BGP de Cilium con nodos híbridos, consulte [Configuración del BGP de Cilium para nodos híbridos](hybrid-nodes-cilium-bgp.md).
+ La administración de direcciones IP (IPAM) predeterminada en Cilium se llama [Ámbito del clúster](https://docs.cilium.io/en/stable/network/concepts/ipam/cluster-pool/), donde el operador de Cilium asigna direcciones IP para cada nodo en función de los CIDR de pods configurados por el usuario.

## Cómo instalar Cilium en nodos híbridos
<a name="hybrid-nodes-cilium-install"></a>

### Procedimiento
<a name="_procedure"></a>

1. Cree un archivo YAML denominado `cilium-values.yaml`. En el siguiente ejemplo se configura Cilium para que se ejecute únicamente en nodos híbridos. Para ello, establece afinidad para la etiqueta `eks.amazonaws.com/compute-type: hybrid` para el operador y el agente de Cilium.
   + Configure `clusterPoolIpv4PodCIDRList` con los mismos CIDR de los pods que configuró para las *redes de pods remotas* del clúster de EKS. Por ejemplo, `10.100.0.0/24`. El operador de Cilium asigna segmentos de direcciones IP desde el espacio de IP `clusterPoolIpv4PodCIDRList` configurado. El CIDR de los pods no debe superponerse con el CIDR de los nodos en las instalaciones, el CIDR de las VPC o el CIDR de los servicios de Kubernetes.
   + Configure `clusterPoolIpv4MaskSize` según los pods requeridos por nodo. Por ejemplo, `25` para un tamaño de segmento /25 de 128 pods por nodo.
   + No cambie `clusterPoolIpv4PodCIDRList` ni `clusterPoolIpv4MaskSize` después de implementar Cilium en su clúster. Consulte [Expanding the cluster pool](https://docs.cilium.io/en/stable/network/concepts/ipam/cluster-pool/#expanding-the-cluster-pool) para obtener más información.
   + Si está ejecutando Cilium en el modo de reemplazo de kube-proxy, configure `kubeProxyReplacement: "true"` en sus valores de Helm y asegúrese de que no tenga ninguna implementación de kube-proxy existente en ejecución en los mismos nodos que Cilium.
   + En el siguiente ejemplo se desactiva el proxy de capa 7 (L7) de Envoy que Cilium utiliza para las políticas de red y el ingreso de la capa 7. Para obtener más información, consulte [Configuración de políticas de red de Kubernetes para nodos híbridos](hybrid-nodes-network-policies.md) y [Información general sobre Cilium Ingress y Cilium Gateway](hybrid-nodes-ingress.md#hybrid-nodes-ingress-cilium).
   + En el siguiente ejemplo se configura `loadBalancer.serviceTopology`: `true` para que la distribución del tráfico del servicio funcione correctamente si la configura para sus servicios. Para obtener más información, consulte [Configurar la distribución de tráfico del servicio](hybrid-nodes-webhooks.md#hybrid-nodes-mixed-service-traffic-distribution).
   + Para obtener una lista completa de los valores de Helm para Cilium, consulte la [referencia de Helm](https://docs.cilium.io/en/stable/helm-reference/) en la documentación de Cilium.

     ```
     affinity:
       nodeAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
           nodeSelectorTerms:
           - matchExpressions:
             - key: eks.amazonaws.com/compute-type
               operator: In
               values:
               - hybrid
     ipam:
       mode: cluster-pool
       operator:
         clusterPoolIPv4MaskSize: 25
         clusterPoolIPv4PodCIDRList:
         - POD_CIDR
     loadBalancer:
       serviceTopology: true
     operator:
       affinity:
         nodeAffinity:
           requiredDuringSchedulingIgnoredDuringExecution:
             nodeSelectorTerms:
             - matchExpressions:
               - key: eks.amazonaws.com/compute-type
                 operator: In
                 values:
                   - hybrid
       unmanagedPodWatcher:
         restart: false
     loadBalancer:
       serviceTopology: true
     envoy:
       enabled: false
     kubeProxyReplacement: "false"
     ```

1. Instale Cilium en el clúster.
   + Sustituya `CILIUM_VERSION` por una versión de Cilium (por ejemplo, `1.17.9-0` o `1.18.3-0`). Se recomienda utilizar la versión más reciente del parche para la versión secundaria de Cilium.
   + Asegúrese de que los nodos cumplan los requisitos del kernel para la versión que elija. Cilium v1.18.3 requiere un kernel de Linux >= 5.10.
   + Si va a utilizar un archivo kubeconfig específico, utilice la marca `--kubeconfig` con el comando de instalación de Helm.

     ```
     helm install cilium oci://public.ecr.aws/eks/cilium/cilium \
         --version CILIUM_VERSION \
         --namespace kube-system \
         --values cilium-values.yaml
     ```

1. Confirme que la instalación de Cilium se haya realizado correctamente con los siguientes comandos. Debería ver la implementación del `cilium-operator` y el `cilium-agent` en ejecución en cada uno de los nodos híbridos. Además, los nodos híbridos se deben encontrar en el estado `Ready`. Para obtener información sobre cómo configurar el BGP de Cilium para anunciar los CIDR de los pods en la red en las instalaciones, continúe con [Configuración del BGP de Cilium para nodos híbridos](hybrid-nodes-cilium-bgp.md).

   ```
   kubectl get pods -n kube-system
   ```

   ```
   NAME                              READY   STATUS    RESTARTS   AGE
   cilium-jjjn8                      1/1     Running   0          11m
   cilium-operator-d4f4d7fcb-sc5xn   1/1     Running   0          11m
   ```

   ```
   kubectl get nodes
   ```

   ```
   NAME                   STATUS   ROLES    AGE   VERSION
   mi-04a2cf999b7112233   Ready    <none>   19m   v1.31.0-eks-a737599
   ```

## Cómo actualizar Cilium en nodos híbridos
<a name="hybrid-nodes-cilium-upgrade"></a>

Antes de actualizar la implementación de Cilium, revise detenidamente la [documentación de actualización de Cilium](https://docs.cilium.io/en/v1.17/operations/upgrade/) y las notas de actualización para comprender los cambios en la versión de destino de Cilium.

1. Asegúrese de haber instalado `helm` CLI en el entorno de línea de comandos. Consulte la [documentación de Helm](https://helm.sh/docs/intro/quickstart/) para consultar las instrucciones de instalación.

1. Ejecute la comprobación previa a la actualización de Cilium. Sustituya `CILIUM_VERSION` por la versión de destino de Cilium. Le recomendamos ejecutar la versión más reciente del parche para la versión secundaria de Cilium. Puede encontrar la versión más reciente de la revisión de una versión secundaria determinada de Cilium en la sección [Versiones estables](https://github.com/cilium/cilium#stable-releases) de la documentación de Cilium.

   ```
   helm install cilium-preflight oci://public.ecr.aws/eks/cilium/cilium --version CILIUM_VERSION \
     --namespace=kube-system \
     --set preflight.enabled=true \
     --set agent=false \
     --set operator.enabled=false
   ```

1. Después de aplicar `cilium-preflight.yaml`, asegúrese de que la cantidad de pods `READY` sea la misma que la cantidad de pods de Cilium en ejecución.

   ```
   kubectl get ds -n kube-system | sed -n '1p;/cilium/p'
   ```

   ```
   NAME                      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
   cilium                    2         2         2       2            2           <none>          1h20m
   cilium-pre-flight-check   2         2         2       2            2           <none>          7m15s
   ```

1. Una vez que la cantidad de pods en READY sea igual, asegúrese de que la implementación de verificación previa de Cilium también esté marcada como READY 1/1. Si aparece READY 0/1, consulte la sección [Validación del CNP](https://docs.cilium.io/en/v1.17/operations/upgrade/#cnp-validation) y resuelva los problemas relacionados con la implementación antes de continuar con la actualización.

   ```
   kubectl get deployment -n kube-system cilium-pre-flight-check -w
   ```

   ```
   NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
   cilium-pre-flight-check   1/1     1            0           12s
   ```

1. Elimine la verificación previa

   ```
   helm uninstall cilium-preflight --namespace kube-system
   ```

1. Antes de ejecutar el comando `helm upgrade`, conserve los valores de la implementación en `existing-cilium-values.yaml` o utilice las opciones de línea de comandos de `--set` para la configuración al ejecutar el comando de actualización. La operación de actualización sobrescribe el ConfigMap de Cilium, por lo que es fundamental que se transmitan los valores de configuración al realizar la actualización.

   ```
   helm get values cilium --namespace kube-system -o yaml > existing-cilium-values.yaml
   ```

1. Durante las operaciones normales del clúster, todos los componentes de Cilium deben ejecutar la misma versión. En los siguientes pasos se describe cómo actualizar todos los componentes de una versión estable a una versión estable posterior. Al actualizar de una versión secundaria a otra secundaria, se recomienda actualizar primero a la versión de revisión más reciente para la versión secundaria de Cilium existente. Para minimizar las interrupciones, la opción `upgradeCompatibility` se debe establecer en la versión inicial de Cilium que instaló en este clúster.

   ```
   helm upgrade cilium oci://public.ecr.aws/eks/cilium/cilium --version CILIUM_VERSION \
     --namespace kube-system \
     --set upgradeCompatibility=1.X \
     -f existing-cilium-values.yaml
   ```

1. (Opcional) Si necesita revertir la actualización debido a problemas, ejecute los siguientes comandos.

   ```
   helm history cilium --namespace kube-system
   helm rollback cilium [REVISION] --namespace kube-system
   ```

## Elimine Cilium de los nodos híbridos
<a name="hybrid-nodes-cilium-delete"></a>

1. Ejecute el siguiente comando para desinstalar todos los componentes de Cilium del clúster. Tenga en cuenta que desinstalar el CNI podría afectar el estado de los nodos y pods, y no debería realizarse en clústeres de producción.

   ```
   helm uninstall cilium --namespace kube-system
   ```

   Las interfaces y rutas configuradas por Cilium no se eliminan de forma predeterminada cuando se elimina la CNI del clúster; consulte la [edición de GitHub](https://github.com/cilium/cilium/issues/34289) para obtener más información.

1. Para limpiar los archivos de configuración y recursos en disco, si utiliza los directorios de configuración estándar, puede eliminar los archivos como se indica el [script `cni-uninstall.sh`](https://github.com/cilium/cilium/blob/main/plugins/cilium-cni/cni-uninstall.sh) proporcionado en el repositorio de Cilium en GitHub.

1. Para eliminar las definiciones de recursos personalizadas (CRD) de Cilium del clúster, puede ejecutar los siguientes comandos.

   ```
   kubectl get crds -oname | grep "cilium" | xargs kubectl delete
   ```

# Cómo configurar complementos para nodos híbridos
<a name="hybrid-nodes-add-ons"></a>

En esta página se presentan consideraciones importantes para la ejecución de complementos de AWS y de la comunidad en Nodos híbridos de Amazon EKS. Para obtener más información sobre los complementos de Amazon EKS y los procesos para crearlos, actualizarlos o eliminarlos del clúster, consulte [Complementos de Amazon EKS](eks-add-ons.md). Salvo que se indique lo contrario en esta página, los procesos para crear, actualizar y eliminar complementos de Amazon EKS son los mismos tanto para los clústeres con nodos híbridos como para los clústeres de Amazon EKS con nodos en ejecución en la nube de AWS. Solo los complementos incluidos en esta página han sido validados para garantizar su compatibilidad con Nodos híbridos de Amazon EKS.

Los siguientes complementos de AWS son compatibles con Nodos híbridos de Amazon EKS.


|  Complemento de AWS | Versiones del complemento compatibles | 
| --- | --- | 
|  kube-proxy  |  v1.25.14-eksbuild.2 y versiones posteriores  | 
|  CoreDNS  |  v1.9.3-eksbuild.7 y versiones posteriores  | 
|   AWS Distro para OpenTelemetry (ADOT)  |  v0.102.1-eksbuild.2 y versiones posteriores  | 
|  Agente de observabilidad de CloudWatch  |  v2.2.1-eksbuild.1 y versiones posteriores  | 
|  Agente de Pod Identity de EKS  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/hybrid-nodes-add-ons.html)  | 
|  Agente de supervisión de nodos  |  v1.2.0-eksbuild.1 y versiones posteriores  | 
|  Controlador de instantáneas CSI  |  v8.1.0-eksbuild.1 y versiones posteriores  | 
|   Conector de AWS Private CA para Kubernetes  |  v1.6.0-eksbuild.1 y versiones posteriores  | 
|  Controlador CSI de Amazon FSx  |  v1.7.0-eksbuild.1 y versiones posteriores  | 
|   Proveedor de AWS para el controlador CSI del Almacén de secretos  |  v2.1.1-eksbuild.1 y versiones posteriores  | 

Los siguientes complementos de la comunidad son compatibles con Nodos híbridos de Amazon EKS. Para obtener más información sobre los complementos de la comunidad, consulte [Complementos de la comunidad](community-addons.md).


| Complemento de la comunidad | Versiones del complemento compatibles | 
| --- | --- | 
|  Servidor de métricas de Kubernetes  |  v0.7.2-eksbuild.1 y versiones superiores  | 
|  cert-manager  |  v1.17.2-eksbuild.1 y versiones posteriores  | 
|  Exportador de nodos de Prometheus  |  v1.9.1-eksbuild.2 y versiones posteriores  | 
|  kube-state-metrics  |  v2.15.0-eksbuild.4 y versiones posteriores  | 
|  DNS externo  |  v0.19.0-eksbuild.1 y versiones posteriores  | 

Además de los complementos de Amazon EKS que se indican en las tablas anteriores, [Amazon Managed Service para Prometheus Collector](prometheus.md) y el [Controlador del equilibrador de carga de AWS](aws-load-balancer-controller.md) para el [ingreso de la aplicación](alb-ingress.md) (HTTP) y el [equilibrio de carga](network-load-balancing.md) (TCP/UDP) son compatibles con los nodos híbridos.

Existen complementos de AWS y complementos de la comunidad que no son compatibles con los Nodos híbridos de Amazon EKS. Las versiones más recientes de estos complementos incluyen una regla de antiafinidad para la etiqueta predeterminada `eks.amazonaws.com/compute-type: hybrid` aplicada a los nodos híbridos. Esto impide que se ejecuten en nodos híbridos cuando se implementan en los clústeres. Si tiene clústeres con nodos híbridos y nodos que se ejecutan en la nube de AWS, puede implementar estos complementos en el clúster en los nodos que se ejecutan en la nube de AWS. La CNI de Amazon VPC no es compatible con los nodos híbridos, y Cilium y Calico se admiten como interfaces de red de contenedores (CNI) para los Nodos híbridos de Amazon EKS. Para obtener más información, consulte [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md).

## Complementos de AWS
<a name="hybrid-nodes-add-ons-aws-add-ons"></a>

Las siguientes secciones describen las diferencias entre ejecutar complementos de AWS compatibles en nodos híbridos y ejecutarlos en otros tipos de computación de Amazon EKS.

## kube-proxy y CoreDNS
<a name="hybrid-nodes-add-ons-core"></a>

EKS instala kube-proxy y CoreDNS como complementos autoadministrados de forma predeterminada cuando se crea un clúster de EKS mediante la API de AWS y los SDK de AWS, incluida AWS CLI. Puede sobrescribir estos complementos con complementos de Amazon EKS después de la creación del clúster. Consulte la documentación de EKS para obtener más información sobre [Administración de `kube-proxy` en clústeres de Amazon EKS](managing-kube-proxy.md) y[Administración de CoredNS para DNS en clústeres de Amazon EKS](managing-coredns.md). Si ejecuta un clúster en modo mixto con nodos híbridos y nodos en la nube de AWS, AWS le recomienda tener al menos una réplica de CoreDNS en los nodos híbridos y al menos una réplica de CoreDNS en los nodos en la nube de AWS. Consulte [Configuración de réplicas de CoreDNS](hybrid-nodes-webhooks.md#hybrid-nodes-mixed-coredns) para conocer los pasos de configuración.

## Agente de observabilidad de CloudWatch
<a name="hybrid-nodes-add-ons-cw"></a>

El operador del agente de observabilidad de CloudWatch utiliza [webhooks](https://kubernetes.io/docs/reference/access-authn-authz/webhook/). Si se ejecuta el operador en nodos híbridos, el CIDR de pods en las instalaciones debe ser enrutable en la red en las instalaciones, y se debe configurar el clúster de EKS con la red de pods remota. Para obtener más información, consulte [Configuración de webhooks para nodos híbridos](hybrid-nodes-webhooks.md).

Las métricas a nivel de nodo no se encuentran disponibles para los nodos híbridos porque [Información de contenedores de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) depende de la disponibilidad del [servicio de metadatos de instancias (IMDS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) para las métricas a nivel de nodo. Las métricas de nivel del clúster, de la carga de trabajo, del pod y del contenedor están disponibles para los nodos híbridos.

Tras instalar el complemento según los pasos descritos en [Instalación del agente de CloudWatch con Observabilidad de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Observability-EKS-addon.html), se debe actualizar el manifiesto del complemento para que el agente se pueda ejecutar correctamente en nodos híbridos. Edite el recurso `amazoncloudwatchagents` en el clúster para agregar la variable de entorno `RUN_WITH_IRSA`, tal y como se muestra a continuación.

```
kubectl edit amazoncloudwatchagents -n amazon-cloudwatch cloudwatch-agent
```

```
apiVersion: v1
items:
- apiVersion: cloudwatch.aws.amazon.com/v1alpha1
  kind: AmazonCloudWatchAgent
  metadata:
    ...
    name: cloudwatch-agent
    namespace: amazon-cloudwatch
    ...
  spec:
    ...
    env:
    - name: RUN_WITH_IRSA # <-- Add this
      value: "True" # <-- Add this
    - name: K8S_NODE_NAME
      valueFrom:
        fieldRef:
          fieldPath: spec.nodeName
          ...
```

## Recopilador administrado de Amazon Managed para Prometheus para nodos híbridos
<a name="hybrid-nodes-add-ons-amp"></a>

Un recopilador administrado de Amazon Managed Service para Prometheus (AMP) consta de un raspador que descubre y recopila métricas de los recursos en un clúster de Amazon EKS. AMP administra el raspador en su nombre, por lo que no tendrá que administrar instancias, agentes o raspadores.

Puede utilizar los recopiladores administrados de AMP sin ninguna configuración adicional específica para los nodos híbridos. Sin embargo, se debe poder acceder a los puntos de conexión métricos de las aplicaciones en los nodos híbridos desde la VPC, incluidas las rutas desde la VPC a los CIDR de la red de pods remotos y los puertos abiertos en el firewall en las instalaciones. Además, el clúster debe tener [acceso privado al punto de conexión del clúster](cluster-endpoint.md).

Siga los pasos que se indican en [Uso de un recopilador administrado de AWS](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html) en la Guía del usuario de Amazon Managed Service para Prometheus.

## AWS Distro para OpenTelemetry (ADOT)
<a name="hybrid-nodes-add-ons-adot"></a>

Puede utilizar el complemento AWS Distro para OpenTelemetry (ADOT) para recopilar métricas, registros y datos de trazado de las aplicaciones en ejecución en nodos híbridos. ADOT utiliza [webhooks](https://kubernetes.io/docs/reference/access-authn-authz/webhook/) de admisión para modificar y validar las solicitudes del recurso personalizado del recolector. Si ejecuta el operador ADOT en nodos híbridos, el CIDR de pods en las instalaciones debe ser enrutable en la red en las instalaciones y debe configurar el clúster de EKS con la red de pods remota. Para obtener más información, consulte [Configuración de webhooks para nodos híbridos](hybrid-nodes-webhooks.md).

Siga los pasos que se indican en [Introducción a AWS Distro para OpenTelemetry con complementos de EKS](https://aws-otel.github.io/docs/getting-started/adot-eks-add-on) en la documentación de * AWS Distro para OpenTelemetry*.

## AWS Controlador del equilibrador de carga de
<a name="hybrid-nodes-add-ons-lbc"></a>

Puede utilizar el [controlador del equilibrador de carga de AWS](aws-load-balancer-controller.md) y el equilibrador de carga de aplicación (ALB) o el equilibrador de carga de red (NLB) con el tipo de destino `ip` para cargas de trabajo en nodos híbridos. Las direcciones IP de destino utilizadas con el ALB o NLB deben ser enrutables desde AWS. El controlador del equilibrador de carga de AWS también utiliza [webhooks](https://kubernetes.io/docs/reference/access-authn-authz/webhook/). Si ejecuta el operador del controlador de equilibrador de carga de AWS en nodos híbridos, el CIDR de pods en las instalaciones debe ser enrutable en la red en las instalaciones y debe configurar el clúster de EKS con la red de pods remota. Para obtener más información, consulte [Configuración de webhooks para nodos híbridos](hybrid-nodes-webhooks.md).

Para instalar el Controlador del equilibrador de carga de AWS, siga los pasos que se indican en [Equilibrador de carga de aplicación de AWS](hybrid-nodes-ingress.md#hybrid-nodes-ingress-alb) o [Equilibrador de carga de red de AWS](hybrid-nodes-load-balancing.md#hybrid-nodes-service-lb-nlb).

Para el ingreso con ALB, debe especificar las anotaciones que aparecen a continuación. Para obtener más información, consulte [Redirección de tráfico de aplicaciones y HTTP con los equilibradores de carga de aplicaciones](alb-ingress.md).

```
alb.ingress.kubernetes.io/target-type: ip
```

Para el equilibrio de carga con ALB, debe especificar las anotaciones que aparecen a continuación. Para obtener más información, consulte [Dirija el tráfico de TCP y UDP con equilibradores de carga de red](network-load-balancing.md).

```
service.beta.kubernetes.io/aws-load-balancer-type: "external"
service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"
```

## Agente de Pod Identity de EKS
<a name="hybrid-nodes-add-ons-pod-id"></a>

**nota**  
Para implementar correctamente el complemento del agente de EKS Pod Identity en los nodos híbridos que ejecutan Bottlerocket, asegúrese de que la versión de Bottlerocket sea la v1.39.0 como mínimo. El agente de Pod Identity no es compatible con versiones anteriores de Bottlerocket en entornos de nodos híbridos.

El DaemonSet original del Agente de Pod Identity de Amazon EKS depende de la disponibilidad del IMDS de EC2 en el nodo para obtener las credenciales de AWS necesarias. Dado que IMDS no está disponible en nodos híbridos, a partir de la versión 1.3.3-eksbuild.1, el complemento del agente de Pod Identity implementa opcionalmente un DaemonSet que monta las credenciales necesarias. Los nodos híbridos que ejecutan Bottlerocket requieren un método diferente para montar las credenciales y, a partir de la versión 1.3.7-eksbuild.2, el complemento del agente de Pod Identity implementa opcionalmente un DaemonSet dirigido específicamente a nodos híbridos de Bottlerocket. En las siguientes secciones se describe el proceso de activación de los DaemonSets opcionales.

### Ubuntu, RHEL y AL2023
<a name="_ubunturhelal2023"></a>

1. Para utilizar el agente de Pod Identity en nodos híbrido de Ubuntu, RHEL y Al2023, configure `enableCredentialsFile: true` en la sección híbrida de la configuración de `nodeadm`, tal como se muestra a continuación:

   ```
   apiVersion: node.eks.aws/v1alpha1
   kind: NodeConfig
   spec:
       hybrid:
           enableCredentialsFile: true # <-- Add this
   ```

   Esto configurará `nodeadm` para crear un archivo de credenciales que se configurará en el nodo bajo `/eks-hybrid/.aws/credentials`, que utilizarán los pods de `eks-pod-identity-agent`. Este archivo de credenciales contendrá credenciales de AWS temporales que se actualizarán periódicamente.

1. Tras actualizar la configuración de `nodeadm` en *cada* nodo, ejecute el siguiente comando `nodeadm init` con el `nodeConfig.yaml` para unir los nodos híbridos al clúster de Amazon EKS. Si los nodos se han unido al clúster anteriormente, vuelva a ejecutar el comando `nodeadm init`.

   ```
   nodeadm init -c file://nodeConfig.yaml
   ```

1. Instale `eks-pod-identity-agent` con la compatibilidad con nodos híbridos activada, mediante la AWS CLI o la Consola de administración de AWS.

   1.  AWS CLI: desde la máquina que utilice para administrar el clúster, ejecute el siguiente comando para instalar `eks-pod-identity-agent` con la compatibilidad con nodos híbridos habilitada. Reemplace `my-cluster` por el nombre del clúster.

      ```
      aws eks create-addon \
          --cluster-name my-cluster \
          --addon-name eks-pod-identity-agent \
          --configuration-values '{"daemonsets":{"hybrid":{"create": true}}}'
      ```

   1.  Consola de administración de AWS: si va a instalar el complemento del agente de Pod Identity a través de la consola de AWS, agregue lo siguiente a la configuración opcional para implementar el DaemonSet dirigido a los nodos híbridos.

      ```
      {"daemonsets":{"hybrid":{"create": true}}}
      ```

### Bottlerocket
<a name="_bottlerocket"></a>

1. Para usar el agente de Pod Identity en los nodos híbridos de Bottlerocket, agregue la marca `--enable-credentials-file=true` al comando utilizado para los datos de usuario del contenedor de arranque de Bottlerocket, tal como se describe en [Conexión de nodos híbridos con Bottlerocket](hybrid-nodes-bottlerocket.md).

   1. Si utiliza el proveedor de credenciales de SSM, el comando debería tener este aspecto:

      ```
      eks-hybrid-ssm-setup --activation-id=<activation-id> --activation-code=<activation-code> --region=<region> --enable-credentials-file=true
      ```

   1. Si utiliza el proveedor de credenciales de IAM Roles Anywhere, el comando debería tener este aspecto:

      ```
      eks-hybrid-iam-ra-setup --certificate=<certificate> --key=<private-key> --enable-credentials-file=true
      ```

      Esto configurará el script de arranque para crear un archivo de credenciales en el nodo de `/var/eks-hybrid/.aws/credentials`, que utilizarán los pods `eks-pod-identity-agent`. Este archivo de credenciales contendrá credenciales de AWS temporales que se actualizarán periódicamente.

1. Instale `eks-pod-identity-agent` con la compatibilidad con nodos híbridos de Bottlerocket activada, mediante la AWS CLI o la Consola de administración de AWS.

   1.  AWS CLI: desde la máquina que utilice para administrar el clúster, ejecute el siguiente comando para instalar `eks-pod-identity-agent` con la compatibilidad con nodos híbridos de Bottlerocket activada. Reemplace `my-cluster` por el nombre del clúster.

      ```
      aws eks create-addon \
          --cluster-name my-cluster \
          --addon-name eks-pod-identity-agent \
          --configuration-values '{"daemonsets":{"hybrid-bottlerocket":{"create": true}}}'
      ```

   1.  Consola de administración de AWS: si va a instalar el complemento del agente de Pod Identity a través de la consola de AWS, agregue lo siguiente a la configuración opcional para implementar el DaemonSet dirigido a los nodos híbridos de Bottlerocket.

      ```
      {"daemonsets":{"hybrid-bottlerocket":{"create": true}}}
      ```

## Controlador de instantáneas CSI
<a name="hybrid-nodes-add-ons-csi-snapshotter"></a>

A partir de la versión `v8.1.0-eksbuild.2`, el [complemento de controlador de instantáneas de CSI](csi-snapshot-controller.md) aplica una regla de antiafinidad flexible para los nodos híbridos y prefiere que el controlador `deployment` se ejecute en EC2 en la misma región de AWSque el plano de control de Amazon EKS. La coubicación de `deployment` en la misma región de AWS que el plano de control de Amazon EKS mejora la latencia.

## Complementos de la comunidad
<a name="hybrid-nodes-add-ons-community"></a>

Las secciones siguientes describen las diferencias entre ejecutar complementos de la comunidad compatibles en nodos híbridos y en otros tipos de computación de Amazon EKS.

## Servidor de métricas de Kubernetes
<a name="hybrid-nodes-add-ons-metrics-server"></a>

El plano de control necesita acceder a la dirección IP del pod de Metrics Server (o a la dirección IP del nodo si se habilita hostNetwork). Por lo tanto, a menos que ejecute Metrics Server en modo hostNetwork, debe configurar una red de pods remota al crear el clúster de Amazon EKS y debe hacer que las direcciones IP de los pods sean enrutables. Implementar el protocolo de puerta de enlace fronteriza (BGP) con la CNI es una forma común de hacer que las direcciones IP de los pods sean enrutables.

## cert-manager
<a name="hybrid-nodes-add-ons-cert-manager"></a>

 `cert-manager` utiliza [webhooks](https://kubernetes.io/docs/reference/access-authn-authz/webhook/). Si ejecuta `cert-manager` en nodos híbridos, el CIDR de pods en las instalaciones debe ser enrutable en la red en las instalaciones y debe configurar el clúster de EKS con la red de pods remotos. Para obtener más información, consulte [Configuración de webhooks para nodos híbridos](hybrid-nodes-webhooks.md).

# Configuración de webhooks para nodos híbridos
<a name="hybrid-nodes-webhooks"></a>

Esta página presenta consideraciones importantes para la ejecución de webhooks con nodos híbridos. Los webhooks se utilizan en aplicaciones de Kubernetes y en proyectos de código abierto, como Controlador del equilibrador de carga de AWS y el agente de observabilidad de CloudWatch, para realizar funciones de mutación y validación en tiempo de ejecución.

 **Redes de pods enrutables** 

Si puede configurar el CIDR del pod en las instalaciones para que sea enrutable en la red en las instalaciones, puede ejecutar webhooks en los nodos híbridos. Existen varias técnicas que puede utilizar para hacer que el CIDR de los pods en las instalaciones sea enrutable en la red en las instalaciones, como el protocolo de puerta de enlace fronteriza (BGP), rutas estáticas u otras soluciones de enrutamiento personalizadas. BGP es la solución recomendada, ya que es más escalable y fácil de administrar que las soluciones alternativas que requieren configuración manual o personalizada de rutas. AWS admite las capacidades de BGP de Cilium y Calico para anunciar los CIDR de los pods. Consulte [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md) y [CIDR de pod remoto enrutable](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-pod-cidrs) para obtener más información.

 **Redes de pods no enrutables** 

Si *no* puede hacer que el CIDR del pod en las instalaciones sea enrutable en la red en las instalaciones y necesita ejecutar webhooks, le recomendamos que ejecute todos los webhooks en los nodos de la nube en el mismo clúster de EKS que los nodos híbridos.

## Consideraciones para clústeres en modo mixto
<a name="hybrid-nodes-considerations-mixed-mode"></a>

 *Los clústeres en modo mixto* se definen como clústeres de EKS que tienen tanto nodos híbridos como nodos que se ejecutan en la nube de AWS. Al ejecutar un clúster en modo mixto, tenga en cuenta las siguientes recomendaciones:
+ Ejecute la CNI de la VPC en los nodos en la nube de AWS y Cilium o Calico en nodos híbridos. Cilium y Calico no son compatibles con AWS cuando se ejecutan en nodos en la nube de AWS.
+ Configure los webhooks para que se ejecuten en los nodos en la nube de AWS. Consulte [Configuración de webhooks para complementos](#hybrid-nodes-webhooks-add-ons) para saber cómo configurar los webhooks para AWS y los complementos de la comunidad.
+ Si las aplicaciones requieren que los pods que se ejecutan en nodos en la nube de AWS se comuniquen directamente con los pods en nodos híbridos (“comunicación este-oeste”), y utiliza la CNI de la VPC en los nodos en la nube de AWS, junto con Cilium o Calico en los nodos híbridos, entonces el CIDR de los pods en las instalaciones debe ser enrutable en la red en las instalaciones.
+ Ejecute al menos una réplica de CoreDNS en los nodos de la nube de AWS y al menos una réplica de CoreDNS en los nodos híbridos.
+ Configure la distribución de tráfico del servicio para mantener el tráfico del servicio local en la zona de la que se origina. Para obtener más información sobre la distribución de tráfico del servicio, consulte [Configurar la distribución de tráfico del servicio](#hybrid-nodes-mixed-service-traffic-distribution).
+ Si utiliza equilibradores de carga de aplicaciones (ALB) o equilibradores de carga de red (NLB) de AWS para el tráfico de las cargas de trabajo que se ejecutan en nodos híbridos, las direcciones IP de destino utilizadas con el ALB o NLB deben ser enrutable desde AWS.
+ El complemento Metrics Server requiere conectividad desde el plano de control de EKS hasta la dirección IP del pod de Metrics Server. Si ejecuta el complemento Metrics Server en nodos híbridos, el CIDR de pods en las instalaciones debe ser enrutable dentro de la red en las instalaciones.
+ Para recopilar métricas de nodos híbridos con los recolectores administrados por Amazon Managed Service para Prometheus (AMP), el CIDR de pods en las instalaciones debe ser enrutable en la red en las instalaciones. De otro modo, puede utilizar el recopilador administrado de AMP para las métricas del plano de control de EKS y de los recursos que se ejecutan en la nube de AWS, y el complemento AWS Distro para OpenTelemetry (ADOT) para recopilar métricas de los nodos híbridos.

## Configurar clústeres en modo mixto
<a name="hybrid-nodes-mixed-mode"></a>

Para ver los webhooks de mutación y validación que se ejecutan en el clúster, puede consultar el tipo de recurso **Extensiones** en el panel de **Recursos** de la consola de EKS, o usar los siguientes comandos. EKS también reporta métricas de webhooks en el panel de observabilidad del clúster. Consulte [Supervisión del clúster con el panel de observabilidad](observability-dashboard.md) para obtener más información.

```
kubectl get mutatingwebhookconfigurations
```

```
kubectl get validatingwebhookconfigurations
```

### Configurar la distribución de tráfico del servicio
<a name="hybrid-nodes-mixed-service-traffic-distribution"></a>

Cuando ejecute clústeres de modo mixto, le recomendamos que utilice la [https://kubernetes.io/docs/reference/networking/virtual-ips/#traffic-distribution](https://kubernetes.io/docs/reference/networking/virtual-ips/#traffic-distribution) para mantener el tráfico del servicio local en la zona de la que se origina. La distribución de tráfico del servicio (disponible para versiones de Kubernetes 1.31 y posteriores en EKS) es la solución recomendada en lugar del [enrutamiento consciente de la topología](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/), ya que ofrece un comportamiento más predecible. Con la distribución de tráfico del servicio, los puntos de conexión en buen estado dentro de una zona recibirán todo el tráfico correspondiente a esa zona. Con el enrutamiento consciente de la topología, cada servicio debe cumplir varias condiciones en esa zona para que se aplique el enrutamiento personalizado; de lo contrario, el tráfico se distribuye de manera equitativa entre todos los puntos de conexión.

Si utiliza Cilium como CNI, debe ejecutar la CNI con la opción `enable-service-topology` establecida en `true` para habilitar la distribución del tráfico de servicios. Puede transmitir esta configuración con el indicador de instalación de Helm `--set loadBalancer.serviceTopology=true` o puede actualizar una instalación existente con el comando de la CLI de Cilium `cilium config set enable-service-topology true`. El agente de Cilium que se ejecuta en cada nodo se debe reiniciar después de actualizar la configuración de una instalación existente.

En la siguiente sección se muestra un ejemplo de cómo configurar la distribución de tráfico del servicio para el servicio CoreDNS, y le recomendamos que habilite la misma para todos los servicios del clúster a fin de evitar el tráfico no deseado entre entornos.

### Configuración de réplicas de CoreDNS
<a name="hybrid-nodes-mixed-coredns"></a>

Si ejecuta un clúster en modo mixto tanto con nodos híbridos como con nodos en la nube de AWS, se recomienda contar con al menos una réplica de CoreDNS en los nodos híbridos y otra en los nodos ubicados en la nube de AWS. Para evitar problemas de latencia y de red en un clúster en modo mixto, puede configurar el servicio CoreDNS de modo que prefiera la réplica de CoreDNS más cercana mediante la [distribución de tráfico del servicio](https://kubernetes.io/docs/reference/networking/virtual-ips/#traffic-distribution).

 La *distribución de tráfico del servicio* (disponible para versiones de Kubernetes 1.31 y posteriores en EKS) es la solución recomendada en lugar del [enrutamiento consciente de la topología](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/), ya que ofrece un comportamiento más predecible. En la distribución de tráfico del servicio, los puntos de conexión en buen estado dentro de una zona recibirán todo el tráfico correspondiente a esa zona. En el enrutamiento consciente de la topología, cada servicio debe cumplir varias condiciones en esa zona para que se aplique el enrutamiento personalizado; de lo contrario, el tráfico se distribuye de manera equitativa entre todos los puntos de conexión. A continuación, se describen los pasos para configurar la distribución de tráfico del servicio.

Si utiliza Cilium como CNI, debe ejecutar la CNI con la opción `enable-service-topology` establecida en `true` para habilitar la distribución del tráfico de servicios. Puede transmitir esta configuración con el indicador de instalación de Helm `--set loadBalancer.serviceTopology=true` o puede actualizar una instalación existente con el comando de la CLI de Cilium `cilium config set enable-service-topology true`. El agente de Cilium que se ejecuta en cada nodo se debe reiniciar después de actualizar la configuración de una instalación existente.

1. Agregue una etiqueta de zona de topología para cada uno de los nodos híbridos, por ejemplo `topology.kubernetes.io/zone: onprem`. O bien, puede establecer la etiqueta en la fase `nodeadm init`. Para ello, especifíquela en la configuración `nodeadm` (consulte [Configuración de nodos para personalizar kubelet (opcional)](hybrid-nodes-nodeadm.md#hybrid-nodes-nodeadm-kubelet)). Nota: Los nodos que se ejecutan en la nube de AWS reciben automáticamente una etiqueta de zona de topología que corresponde a la zona de disponibilidad (AZ) del nodo.

   ```
   kubectl label node hybrid-node-name topology.kubernetes.io/zone=zone
   ```

1. Agregue `podAntiAffinity` a la implementación de CoreDNS con la clave de zona de topología. De otro modo, puede configurar la implementación de CoreDNS durante la instalación con complementos de EKS.

   ```
   kubectl edit deployment coredns -n kube-system
   ```

   ```
   spec:
     template:
       spec:
         affinity:
          ...
           podAntiAffinity:
             preferredDuringSchedulingIgnoredDuringExecution:
             - podAffinityTerm:
                 labelSelector:
                   matchExpressions:
                   - key: k8s-app
                     operator: In
                     values:
                     - kube-dns
                 topologyKey: kubernetes.io/hostname
               weight: 100
             - podAffinityTerm:
                 labelSelector:
                   matchExpressions:
                   - key: k8s-app
                     operator: In
                     values:
                     - kube-dns
                 topologyKey: topology.kubernetes.io/zone
               weight: 50
         ...
   ```

1. Añada el ajuste `trafficDistribution: PreferClose` a la configuración del servicio de `kube-dns` para habilitar la distribución de tráfico del servicio.

   ```
   kubectl patch svc kube-dns -n kube-system --type=merge -p '{
     "spec": {
       "trafficDistribution": "PreferClose"
     }
   }'
   ```

1. Para confirmar que la distribución del tráfico del servicio está habilitada, puede consultar los segmentos de puntos de conexión del servicio `kube-dns`. Los segmentos de puntos de conexión deben mostrar las `hints` de las etiquetas de zona topológica, lo que confirma que la distribución del tráfico del servicio está habilitada. Si no ve la `hints` para cada dirección de punto de conexión, significa que la distribución del tráfico del servicio no está habilitada.

   ```
   kubectl get endpointslice -A | grep "kube-dns"
   ```

   ```
   kubectl get endpointslice [.replaceable]`kube-dns-<id>`  -n kube-system -o yaml
   ```

   ```
   addressType: IPv4
   apiVersion: discovery.k8s.io/v1
   endpoints:
   - addresses:
     - <your-hybrid-node-pod-ip>
     hints:
       forZones:
       - name: onprem
     nodeName: <your-hybrid-node-name>
     zone: onprem
   - addresses:
     - <your-cloud-node-pod-ip>
     hints:
       forZones:
       - name: us-west-2a
     nodeName: <your-cloud-node-name>
     zone: us-west-2a
   ```

### Configuración de webhooks para complementos
<a name="hybrid-nodes-webhooks-add-ons"></a>

Los siguientes complementos utilizan webhooks y son compatibles para su uso con nodos híbridos.
+  Controlador del equilibrador de carga de AWS 
+ Agente de observabilidad de Amazon CloudWatch
+  AWS Distro para OpenTelemetry (ADOT)
+  `cert-manager` 

Consulte las secciones que aparecen a continuación para configurar los webhooks que estos complementos utilizan para que se ejecuten en nodos en la nube de AWS.

#### Controlador del equilibrador de carga de AWS
<a name="hybrid-nodes-mixed-lbc"></a>

Para utilizar el controlador del equilibrador de carga de AWS en una configuración de clúster de modo mixto, debe ejecutar el controlador en nodos en la nube de AWS. Para ello, agregue lo siguiente a la configuración de valores de Helm o especifique los valores mediante la configuración del complemento de EKS.

```
affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: eks.amazonaws.com/compute-type
          operator: NotIn
          values:
          - hybrid
```

#### Agente de observabilidad de Amazon CloudWatch
<a name="hybrid-nodes-mixed-cwagent"></a>

El complemento del agente de observabilidad de CloudWatch tiene un operador de Kubernetes que utiliza webhooks. Para ejecutar el operador en nodos en la nube de AWS dentro de una configuración de clúster en modo mixto, edite la configuración del operador del agente de observabilidad de CloudWatch. No es posible configurar la afinidad del operador durante la instalación con Helm y los complementos de EKS (consulte [incidencia n.º 2431 containers-roadmap](https://github.com/aws/containers-roadmap/issues/2431)).

```
kubectl edit -n amazon-cloudwatch deployment amazon-cloudwatch-observability-controller-manager
```

```
spec:
  ...
  template:
    ...
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: eks.amazonaws.com/compute-type
                operator: NotIn
                values:
                - hybrid
```

#### AWS Distro para OpenTelemetry (ADOT)
<a name="hybrid-nodes-mixed-adot"></a>

El complemento de AWS Distro para OpenTelemetry (ADOT) tiene un operador de Kubernetes que utiliza webhooks. Para ejecutar el operador en nodos en la nube de AWS dentro de una configuración de clúster en modo mixto, agregue lo siguiente a la configuración de valores de Helm o especifique los valores mediante la configuración del complemento de EKS.

```
affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: eks.amazonaws.com/compute-type
          operator: NotIn
          values:
          - hybrid
```

Si el CIDR de pods no es enrutable en la red en las instalaciones, el recopilador de ADOT se debe ejecutar en los nodos híbridos para obtener las métricas de los nodos híbridos y de las cargas de trabajo que se ejecutan en estos. Para ello, edite la definición de recurso personalizado (CRD).

```
kubectl -n opentelemetry-operator-system edit opentelemetrycollectors.opentelemetry.io adot-col-prom-metrics
```

```
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: eks.amazonaws.com/compute-type
            operator: In
            values:
            - hybrid
```

Puede configurar el recopilador de ADOT para que obtenga únicamente métricas de los nodos híbridos y de los recursos que se ejecutan en estos. Para ello, agregeue las siguientes `relabel_configs` a cada `scrape_configs` en la configuración de CRD del recopilador de ADOT.

```
relabel_configs:
  - action: keep
    regex: hybrid
    source_labels:
    - __meta_kubernetes_node_label_eks_amazonaws_com_compute_type
```

El complemento ADOT tiene como requisito previo instalar `cert-manager` para los certificados TLS utilizados por el webhook del operador de ADOT. `cert-manager` también ejecuta webhooks y se puede configurar de manera que se ejecute en nodos en la nube de AWS con la siguiente configuración de valores de Helm.

```
affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: eks.amazonaws.com/compute-type
          operator: NotIn
          values:
          - hybrid
webhook:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: eks.amazonaws.com/compute-type
            operator: NotIn
            values:
            - hybrid
cainjector:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: eks.amazonaws.com/compute-type
            operator: NotIn
            values:
            - hybrid
startupapicheck:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: eks.amazonaws.com/compute-type
            operator: NotIn
            values:
            - hybrid
```

#### `cert-manager`
<a name="hybrid-nodes-mixed-cert-manager"></a>

El complemento `cert-manager` ejecuta webhooks y se puede configurar de manera que se ejecute en nodos en la nube de AWS con la siguiente configuración de valores de Helm.

```
affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: eks.amazonaws.com/compute-type
          operator: NotIn
          values:
          - hybrid
webhook:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: eks.amazonaws.com/compute-type
            operator: NotIn
            values:
            - hybrid
cainjector:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: eks.amazonaws.com/compute-type
            operator: NotIn
            values:
            - hybrid
startupapicheck:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: eks.amazonaws.com/compute-type
            operator: NotIn
            values:
            - hybrid
```

# Configuración del proxy para nodos híbridos
<a name="hybrid-nodes-proxy"></a>

Si utiliza un servidor proxy en el entorno en las instalaciones para el tráfico que sale del centro de datos o del entorno periférico, debe configurar por separado los nodos y el clúster para usar el servidor proxy.

Clúster  
En el clúster, debe configurar `kube-proxy` para usar el servidor proxy. Debe configurar `kube-proxy` después de crear el clúster de Amazon EKS.

Nodos  
En los nodos, debe configurar el sistema operativo, `containerd`, `kubelet` y el agente Amazon SSM para usar el servidor proxy. Puede realizar estos cambios durante el proceso de creación de las imágenes del sistema operativo o antes de ejecutar `nodeadm init` en cada nodo híbrido.

## Configuración a nivel de nodo
<a name="_node_level_configuration"></a>

Debe aplicar las siguientes configuraciones ya sea en las imágenes de sistema operativo o antes de ejecutar `nodeadm init` en cada nodo híbrido.

### Configuración del proxy `containerd`
<a name="_containerd_proxy_configuration"></a>

 `containerd` es el tiempo de ejecución de administración de contenedores predeterminado para Kubernetes. Si utiliza un proxy para acceder a Internet, debe configurar `containerd` de modo que pueda extraer las imágenes de contenedor necesarias para Kubernetes y Amazon EKS.

Cree un archivo en cada nodo híbrido llamado `http-proxy.conf` en el directorio `/etc/systemd/system/containerd.service.d` con el siguiente contenido. Sustituya `proxy-domain` y `port` por los valores correspondientes al entorno.

```
[Service]
Environment="HTTP_PROXY=http://proxy-domain:port"
Environment="HTTPS_PROXY=http://proxy-domain:port"
Environment="NO_PROXY=localhost"
```

#### Configuración de `containerd` a partir de datos de usuarios
<a name="_containerd_configuration_from_user_data"></a>

Será necesario crear el directorio `containerd.service.d` para este archivo. Tendrá que volver a cargar systemd para recuperar el archivo de configuración sin necesidad de reiniciar. En AL2023, es probable que el servicio ya esté en ejecución cuando se ejecute el script, por lo que también tendrá que reiniciarlo.

```
mkdir -p /etc/systemd/system/containerd.service.d
echo '[Service]' > /etc/systemd/system/containerd.service.d/http-proxy.conf
echo 'Environment="HTTP_PROXY=http://proxy-domain:port"' >> /etc/systemd/system/containerd.service.d/http-proxy.conf
echo 'Environment="HTTPS_PROXY=http://proxy-domain:port"' >> /etc/systemd/system/containerd.service.d/http-proxy.conf
echo 'Environment="NO_PROXY=localhost"' >> /etc/systemd/system/containerd.service.d/http-proxy.conf
systemctl daemon-reload
systemctl restart containerd
```

### Configuración del proxy `kubelet`
<a name="_kubelet_proxy_configuration"></a>

 `kubelet` es el agente de nodos de Kubernetes que se ejecuta en cada nodo de Kubernetes y es responsable de administrar el nodo y los pods que se ejecutan en este. Si utiliza un proxy en el entorno en las instalaciones, debe configurar el `kubelet` para que pueda comunicarse con los puntos de conexión públicos o privados del clúster de Amazon EKS.

Cree un archivo en cada nodo híbrido llamado `http-proxy.conf` en el directorio `/etc/systemd/system/kubelet.service.d/` con el siguiente contenido. Sustituya `proxy-domain` y `port` por los valores correspondientes al entorno.

```
[Service]
Environment="HTTP_PROXY=http://proxy-domain:port"
Environment="HTTPS_PROXY=http://proxy-domain:port"
Environment="NO_PROXY=localhost"
```

#### Configuración de `kubelet` a partir de datos de usuarios
<a name="_kubelet_configuration_from_user_data"></a>

Se debe crear el directorio `kubelet.service.d` para este archivo. Tendrá que volver a cargar systemd para recuperar el archivo de configuración sin necesidad de reiniciar. En AL2023, es probable que el servicio ya esté en ejecución cuando se ejecute el script, por lo que también tendrá que reiniciarlo.

```
mkdir -p /etc/systemd/system/kubelet.service.d
echo '[Service]' > /etc/systemd/system/kubelet.service.d/http-proxy.conf
echo 'Environment="HTTP_PROXY=http://proxy-domain:port"' >> /etc/systemd/system/kubelet.service.d/http-proxy.conf
echo 'Environment="HTTPS_PROXY=http://proxy-domain:port"' >> /etc/systemd/system/kubelet.service.d/http-proxy.conf
echo 'Environment="NO_PROXY=localhost"' >> /etc/systemd/system/kubelet.service.d/http-proxy.conf
systemctl daemon-reload
systemctl restart kubelet
```

### Configuración del proxy `ssm`
<a name="_ssm_proxy_configuration"></a>

 `ssm` es uno de los proveedores de credenciales que se pueden utilizar para inicializar un nodo híbrido. `ssm` es responsable de autenticarse con AWS y generar credenciales temporales que son utilizadas por `kubelet`. Si utiliza un proxy en el entorno en las instalaciones y usa `ssm` como proveedor de credenciales en el nodo, debe configurar `ssm` para que pueda comunicarse con los puntos de conexión del servicio de Amazon SSM.

Cree un archivo en cada nodo híbrido llamado `http-proxy.conf` en la siguiente ruta, según el sistema operativo
+ Ubuntu - `/etc/systemd/system/snap.amazon-ssm-agent.amazon-ssm-agent.service.d/http-proxy.conf` 
+ Amazon Linux 2023 y Red Hat Enterprise Linux - `/etc/systemd/system/amazon-ssm-agent.service.d/http-proxy.conf` 

Rellene el archivo con el siguiente contenido. Sustituya `proxy-domain` y `port` por los valores correspondientes al entorno.

```
[Service]
Environment="HTTP_PROXY=http://proxy-domain:port"
Environment="HTTPS_PROXY=http://proxy-domain:port"
Environment="NO_PROXY=localhost"
```

#### Configuración de `ssm` a partir de datos de usuarios
<a name="_ssm_configuration_from_user_data"></a>

Es necesario crear el directorio para el archivo de servicio systemd de `ssm`. La ruta del directorio depende del sistema operativo utilizado en el nodo.
+ Ubuntu - `/etc/systemd/system/snap.amazon-ssm-agent.amazon-ssm-agent.service.d` 
+ Amazon Linux 2023 y Red Hat Enterprise Linux - `/etc/systemd/system/amazon-ssm-agent.service.d` 

Reemplace el nombre del servicio systemd en el comando de reinicio a continuación, en función del sistema operativo utilizado en el nodo.
+ Ubuntu - `snap.amazon-ssm-agent.amazon-ssm-agent` 
+ Amazon Linux 2023 y Red Hat Enterprise Linux - `amazon-ssm-agent` 

```
mkdir -p systemd-service-file-directory
echo '[Service]' > [.replaceable]#systemd-service-file-directory/http-proxy.conf
echo 'Environment="HTTP_PROXY=http://[.replaceable]#proxy-domain:port"' >> systemd-service-file-directory/http-proxy.conf
echo 'Environment="HTTPS_PROXY=http://[.replaceable]#proxy-domain:port"' >> [.replaceable]#systemd-service-file-directory/http-proxy.conf
echo 'Environment="NO_PROXY=localhost"' >> [.replaceable]#systemd-service-file-directory/http-proxy.conf
systemctl daemon-reload
systemctl restart [.replaceable]#systemd-service-name
```

### Configuración del proxy del sistema operativo
<a name="_operating_system_proxy_configuration"></a>

Si utiliza un proxy para acceder a Internet, debe configurar el sistema operativo de modo que pueda extraer las dependencias de los nodos híbridos del administrador de paquetes del sistema operativo.

 **Ubuntu** 

1. Configure `snap` para usar el proxy con los siguientes comandos:

   ```
   sudo snap set system proxy.https=http://proxy-domain:port
   sudo snap set system proxy.http=http://proxy-domain:port
   ```

1. Para habilitar el proxy para `apt`, cree un archivo llamado `apt.conf` en el directorio `/etc/apt/`. Sustituya proxy-domain y puerto por los valores correspondientes al entorno.

   ```
   Acquire::http::Proxy "http://proxy-domain:port";
   Acquire::https::Proxy "http://proxy-domain:port";
   ```

 **Amazon Linux 2023** 

1. Configure `dnf` para utilizar el proxy. Cree un archivo `/etc/dnf/dnf.conf` con los valores proxy-domain y de puerto correspondientes al entorno.

   ```
   proxy=http://proxy-domain:port
   ```

 **Red Hat Enterprise Linux** 

1. Configure `yum` para utilizar el proxy. Cree un archivo `/etc/yum.conf` con los valores proxy-domain y de puerto correspondientes al entorno.

   ```
   proxy=http://proxy-domain:port
   ```

### Configuración del proxy de IAM Roles Anywhere
<a name="_iam_roles_anywhere_proxy_configuration"></a>

El servicio de proveedor de credenciales de IAM Roles Anywhere se ocupa de actualizar las credenciales cuando se utiliza IAM Roles Anywhere con la marca `enableCredentialsFile` (consulte [Agente de Pod Identity de EKS](hybrid-nodes-add-ons.md#hybrid-nodes-add-ons-pod-id)). Si utiliza un proxy en el entorno en las instalaciones, debe configurar el servicio para que pueda comunicarse con los puntos de conexión de IAM Roles Anywhere.

Cree un archivo llamado `http-proxy.conf` en el directorio `/etc/systemd/system/aws_signing_helper_update.service.d/` con el siguiente contenido. Sustituya `proxy-domain` y `port` por los valores correspondientes al entorno.

```
[Service]
Environment="HTTP_PROXY=http://proxy-domain:port"
Environment="HTTPS_PROXY=http://proxy-domain:port"
Environment="NO_PROXY=localhost"
```

## Configuración de todo el clúster
<a name="_cluster_wide_configuration"></a>

Las configuraciones de esta sección se deben aplicar después de crear el clúster de Amazon EKS y antes de ejecutar `nodeadm init` en cada nodo híbrido.

### Configuración del proxy kube-proxy
<a name="_kube_proxy_proxy_configuration"></a>

Amazon EKS instala automáticamente `kube-proxy` en cada nodo híbrido como DaemonSet cuando los nodos híbridos se unen al clúster. `kube-proxy` permite el enrutamiento entre servicios respaldados por pods en clústeres de Amazon EKS. Para configurar cada host, `kube-proxy` requiere la resolución DNS para el punto de conexión del clúster de Amazon EKS.

1. Edite el DaemonSet `kube-proxy` con el siguiente comando

   ```
   kubectl -n kube-system edit ds kube-proxy
   ```

   Esto abrirá la definición del DaemonSet `kube-proxy` en el editor configurado.

1. Agregue las variables de entorno para `HTTP_PROXY` y `HTTPS_PROXY`. Tenga en cuenta que la variable de entorno `NODE_NAME` ya debe existir en la configuración. Sustituya `proxy-domain` y `port` por los valores correspondientes al entorno.

   ```
   containers:
     - command:
       - kube-proxy
       - --v=2
       - --config=/var/lib/kube-proxy-config/config - --hostname-override=$(NODE_NAME)
       env:
       - name: HTTP_PROXY
         value: http://proxy-domain:port
       - name: HTTPS_PROXY
         value: http://proxy-domain:port
       - name: NODE_NAME
         valueFrom:
           fieldRef:
             apiVersion: v1
             fieldPath: spec.nodeName
   ```

# Configuración del BGP de Cilium para nodos híbridos
<a name="hybrid-nodes-cilium-bgp"></a>

En este tema se describe cómo configurar el protocolo de puerta de enlace fronteriza (BGP) de Cilium para los nodos híbridos de Amazon EKS. La funcionalidad del BGP de Cilium se denomina [Cilium BGP Control Plane](https://docs.cilium.io/en/stable/network/bgp-control-plane/bgp-control-plane/) y se puede utilizar para anunciar las direcciones de los pods y los servicios en la red en las instalaciones. Para ver métodos alternativos para hacer que los CIDR de los pods sean enrutables en la red en las instalaciones, consulte [CIDR de pod remoto enrutable](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-pod-cidrs).

## Configuración del BGP de Cilium
<a name="hybrid-nodes-cilium-bgp-configure"></a>

### Requisitos previos
<a name="_prerequisites"></a>
+ Se instaló Cilium según las instrucciones de [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md).

### Procedimiento
<a name="_procedure"></a>

1. Para usar el BGP con Cilium a fin de anunciar las direcciones de los pods o los servicios en la red en las instalaciones, debe haber instalado Cilium con `bgpControlPlane.enabled: true`. Si activa BGP para una implementación de Cilium existente, debe reiniciar el operador de Cilium para aplicar la configuración de BGP si BGP no se activó anteriormente. Puede configurar `operator.rollOutPods` como `true` en sus valores de Helm para reiniciar el operador de Cilium como parte del proceso de instalación o actualización de Helm.

   ```
   helm upgrade cilium oci://public.ecr.aws/eks/cilium/cilium \
     --namespace kube-system \
     --reuse-values \
     --set operator.rollOutPods=true \
     --set bgpControlPlane.enabled=true
   ```

1. Confirme que el operador y los agentes de Cilium se hayan reiniciado y estén funcionando.

   ```
   kubectl -n kube-system get pods --selector=app.kubernetes.io/part-of=cilium
   ```

   ```
   NAME                               READY   STATUS    RESTARTS   AGE
   cilium-grwlc                       1/1     Running   0          4m12s
   cilium-operator-68f7766967-5nnbl   1/1     Running   0          4m20s
   cilium-operator-68f7766967-7spfz   1/1     Running   0          4m20s
   cilium-pnxcv                       1/1     Running   0          6m29s
   cilium-r7qkj                       1/1     Running   0          4m12s
   cilium-wxhfn                       1/1     Running   0          4m1s
   cilium-z7hlb                       1/1     Running   0          6m30s
   ```

1. Cree un archivo llamado `cilium-bgp-cluster.yaml` con una definición `CiliumBGPClusterConfig`. Es posible que deba obtener la siguiente información de su administrador de red.
   + Configure `localASN` con el ASN para los nodos que ejecutan Cilium.
   + Configure `peerASN` con el ASN de su enrutador en las instalaciones.
   + Configure `peerAddress` con la IP del enrutador en las instalaciones con la que se emparejará cada nodo que ejecute Cilium.

     ```
     apiVersion: cilium.io/v2alpha1
     kind: CiliumBGPClusterConfig
     metadata:
       name: cilium-bgp
     spec:
       nodeSelector:
         matchExpressions:
         - key: eks.amazonaws.com/compute-type
           operator: In
           values:
           - hybrid
       bgpInstances:
       - name: "rack0"
         localASN: NODES_ASN
         peers:
         - name: "onprem-router"
           peerASN: ONPREM_ROUTER_ASN
           peerAddress: ONPREM_ROUTER_IP
           peerConfigRef:
             name: "cilium-peer"
     ```

1. Aplique la configuración de clúster del BGP de Cilium al clúster.

   ```
   kubectl apply -f cilium-bgp-cluster.yaml
   ```

1. Cree un archivo denominado `cilium-bgp-peer.yaml` con el recurso `CiliumBGPPeerConfig` que define una configuración de emparejamiento del BGP. Varios pares pueden compartir la misma configuración y proporcionar una referencia al recurso `CiliumBGPPeerConfig` común. Consulte [BGP Peer configuration](https://docs.cilium.io/en/latest/network/bgp-control-plane/bgp-control-plane-v2/#bgp-peer-configuration) en la documentación de Cilium para obtener una lista completa de las opciones de configuración.

   Los valores de las siguientes configuraciones de emparejamiento de Cilium deben coincidir con los del router en las instalaciones con el que se empareja.
   + Configure `holdTimeSeconds` para determinar cuánto tiempo espera un emparejamiento del BGP a recibir un mensaje de mantenimiento o actualización antes de declarar la sesión inactiva. El valor predeterminado es de 90 segundos.
   + Configure `keepAliveTimeSeconds` para determinar si aún se puede acceder a un emparejamiento del BGP y si la sesión del BGP está activa. El valor predeterminado es de 30 segundos.
   + Configure `restartTimeSeconds` para determinar el momento en que se espera que el plano de control del BGP de Cilium restablezca la sesión del BGP tras un reinicio. El valor predeterminado es de 120 segundos.

     ```
     apiVersion: cilium.io/v2alpha1
     kind: CiliumBGPPeerConfig
     metadata:
       name: cilium-peer
     spec:
       timers:
         holdTimeSeconds: 90
         keepAliveTimeSeconds: 30
       gracefulRestart:
         enabled: true
         restartTimeSeconds: 120
       families:
         - afi: ipv4
           safi: unicast
           advertisements:
             matchLabels:
               advertise: "bgp"
     ```

1. Aplique la configuración de emparejamiento del BGP de Cilium al clúster.

   ```
   kubectl apply -f cilium-bgp-peer.yaml
   ```

1. Cree un archivo llamado `cilium-bgp-advertisement-pods.yaml` con un recurso `CiliumBGPAdvertisement` para anunciar los CIDR de pods en su red en las instalaciones.
   + El recurso `CiliumBGPAdvertisement` se utiliza para definir varios tipos de anuncios y los atributos asociados a estos. En el siguiente ejemplo, se configura Cilium para que anuncie únicamente los CIDR de pods. Consulte los ejemplos de [LoadBalancer del tipo de servicio](hybrid-nodes-ingress.md#hybrid-nodes-ingress-cilium-loadbalancer) y [Equilibrio de carga en el clúster de Cilium](hybrid-nodes-load-balancing.md#hybrid-nodes-service-lb-cilium) para obtener más información sobre la configuración de Cilium para anunciar las direcciones de los servicios.
   + Cada nodo híbrido que ejecuta el agente de Cilium se empareja con el router ascendente compatible con el BGP. Cada nodo anuncia el rango de CIDR del pod que posee cuando el `advertisementType` de Cilium está configurado en `PodCIDR` como en el ejemplo siguiente. Consulte [BGP Advertisements configuration](https://docs.cilium.io/en/stable/network/bgp-control-plane/bgp-control-plane-v2/#bgp-advertisements) en la documentación de Cilium para obtener más información.

     ```
     apiVersion: cilium.io/v2alpha1
     kind: CiliumBGPAdvertisement
     metadata:
       name: bgp-advertisement-pods
       labels:
         advertise: bgp
     spec:
       advertisements:
         - advertisementType: "PodCIDR"
     ```

1. Aplique la configuración de anuncio de BGP de Cilium al clúster.

   ```
   kubectl apply -f cilium-bgp-advertisement-pods.yaml
   ```

1. Puede confirmar que el emparejamiento de BGP funcionó con la [CLI de Cilium](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/#install-the-cilium-cli) mediante el comando `cilium bgp peers`. Debería ver los valores correctos en la salida del entorno y el estado de la sesión como `established`. Consulte la [Guía de solución de problemas y operaciones](https://docs.cilium.io/en/latest/network/bgp-control-plane/bgp-control-plane/#troubleshooting-and-operation-guide) en la documentación de Cilium para obtener más información sobre la solución de problemas.

   En los ejemplos siguientes, hay cinco nodos híbridos que ejecutan el agente de Cilium y cada nodo anuncia el rango de CIDR de pods que posee.

   ```
   cilium bgp peers
   ```

   ```
   Node                   Local AS    Peer AS               Peer Address        Session State   Uptime     Family         Received   Advertised
   mi-026d6a261e355fba7   NODES_ASN
                     ONPREM_ROUTER_ASN
                     ONPREM_ROUTER_IP    established     1h18m58s   ipv4/unicast   1          2
   mi-082f73826a163626e   NODES_ASN
                     ONPREM_ROUTER_ASN
                     ONPREM_ROUTER_IP    established     1h19m12s   ipv4/unicast   1          2
   mi-09183e8a3d755abf6   NODES_ASN
                     ONPREM_ROUTER_ASN
                     ONPREM_ROUTER_IP    established     1h18m47s   ipv4/unicast   1          2
   mi-0d78d815980ed202d   NODES_ASN
                     ONPREM_ROUTER_ASN
                     ONPREM_ROUTER_IP    established     1h19m12s   ipv4/unicast   1          2
   mi-0daa253999fe92daa   NODES_ASN
                     ONPREM_ROUTER_ASN
                     ONPREM_ROUTER_IP    established     1h18m58s   ipv4/unicast   1          2
   ```

   ```
   cilium bgp routes
   ```

   ```
   Node                   VRouter       Prefix           NextHop   Age         Attrs
   mi-026d6a261e355fba7   NODES_ASN     10.86.2.0/26     0.0.0.0   1h16m46s   [{Origin: i} {Nexthop: 0.0.0.0}]
   mi-082f73826a163626e   NODES_ASN     10.86.2.192/26   0.0.0.0   1h16m46s   [{Origin: i} {Nexthop: 0.0.0.0}]
   mi-09183e8a3d755abf6   NODES_ASN     10.86.2.64/26    0.0.0.0   1h16m46s   [{Origin: i} {Nexthop: 0.0.0.0}]
   mi-0d78d815980ed202d   NODES_ASN     10.86.2.128/26   0.0.0.0   1h16m46s   [{Origin: i} {Nexthop: 0.0.0.0}]
   mi-0daa253999fe92daa   NODES_ASN     10.86.3.0/26     0.0.0.0   1h16m46s   [{Origin: i} {Nexthop: 0.0.0.0}]
   ```

# Configuración de Kubernetes Ingress para nodos híbridos
<a name="hybrid-nodes-ingress"></a>

En este tema se describe cómo configurar Kubernetes Ingress para las cargas de trabajo que se ejecutan en Nodos híbridos de Amazon EKS. [Kubernetes Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) expone las rutas HTTP y HTTPS desde fuera del clúster a los servicios del clúster. Para utilizar los recursos de Ingress, se necesita un controlador de Kubernetes Ingress a fin de configurar la infraestructura de red y los componentes que sirven al tráfico de la red.

 AWS es compatible con el Equilibrador de carga de aplicación (ALB) de AWS y Cilium for Kubernetes Ingress para cargas de trabajo que se ejecutan en Nodos híbridos de EKS. La decisión de utilizar ALB o Cilium para la entrada se basa en el origen del tráfico de aplicaciones. Si el tráfico de aplicaciones se origina en una región de AWS, AWS recomienda utilizar el ALB de AWS y el Controlador del equilibrador de carga de AWS. Si el tráfico de aplicaciones se origina en un entorno local en las instalaciones o en la periferia, AWS recomienda utilizar las funciones de entrada integradas de Cilium, que se pueden utilizar con o sin una infraestructura de equilibradores de carga en su entorno.

![\[Entrada de Nodos híbridos de EKS\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/hybrid-nodes-ingress.png)


## Equilibrador de carga de aplicación de AWS
<a name="hybrid-nodes-ingress-alb"></a>

Puede usar el [Controlador del equilibrador de carga de AWS](aws-load-balancer-controller.md) y el Equilibrador de carga de aplicación (ALB) con el tipo de destino `ip` para cargas de trabajo que se ejecutan en nodos híbridos. Cuando se utiliza el tipo de destino `ip`, el ALB reenvía el tráfico directamente a los pods, sin pasar por la ruta de red de la capa de servicio. Para que el ALB llegue a los destinos de IP de pods en nodos híbridos, el CIDR de pods en las instalaciones debe ser enrutable en la red en las instalaciones. Además, el Controlador del equilibrador de carga de AWS utiliza webhooks y requiere una comunicación directa desde el plano de control de EKS. Para obtener más información, consulte [Configuración de webhooks para nodos híbridos](hybrid-nodes-webhooks.md).

### Consideraciones
<a name="_considerations"></a>
+ Consulte [Redirección de tráfico de aplicaciones y HTTP con los equilibradores de carga de aplicaciones](alb-ingress.md) y [Instalación del Controlador del equilibrador de carga de AWS con Helm](lbc-helm.md) para obtener más información sobre el Equilibrador de carga de aplicación de AWS y Controlador del equilibrador de carga de AWS.
+ Consulte [Best Practices for Load Balancing](https://docs.aws.amazon.com/eks/latest/best-practices/load-balacing.html) para obtener información sobre cómo elegir entre el Equilibrador de carga de aplicación de AWS y el Equilibrador de carga de red de AWS.
+ Consulte [AWS Load Balancer Controller Ingress annotations](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/annotations/) para obtener la lista de anotaciones que se pueden configurar para los recursos de entrada con el Equilibrador de carga de aplicación de AWS.

### Requisitos previos
<a name="_prerequisites"></a>
+ Se instaló Cilium según las instrucciones de [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md).
+ Cilium BGP Control Plane está activado según las instrucciones de [Configuración del BGP de Cilium para nodos híbridos](hybrid-nodes-cilium-bgp.md). Si no desea usar el BGP, debe usar un método alternativo para que los CIDR de pods en las instalaciones sean enrutables dentro de la red en las instalaciones. Si no hace que los CIDR de sus pods en las instalaciones sean enrutables, el ALB no podrá registrar los destinos de IP de su pod ni contactar con ellos.
+ Si tiene Helm instalado en su entorno de línea de comandos, consulte las [instrucciones de configuración de Helm](helm.md) para obtener más información.
+ Si tiene eksctl instalado en su entorno de línea de comandos, consulte las [instrucciones de instalación de eksctl](install-kubectl.md#eksctl-install-update) para obtener más información.

### Procedimiento
<a name="_procedure"></a>

1. Descargue una política de IAM para el Controlador del equilibrador de carga de AWS que le permita realizar llamadas a las API de AWS en su nombre.

   ```
   curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/refs/heads/main/docs/install/iam_policy.json
   ```

1. Cree una política de IAM con la política descargada en el paso anterior.

   ```
   aws iam create-policy \
       --policy-name AWSLoadBalancerControllerIAMPolicy \
       --policy-document file://iam_policy.json
   ```

1. Sustituya el valor del nombre del clúster (`CLUSTER_NAME`), la región de AWS (`AWS_REGION`) y el ID de la cuenta de AWS (`AWS_ACCOUNT_ID`) por su configuración y ejecute el siguiente comando.

   ```
   eksctl create iamserviceaccount \
       --cluster=CLUSTER_NAME \
       --namespace=kube-system \
       --name=aws-load-balancer-controller \
       --attach-policy-arn=arn:aws:iam::AWS_ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy \
       --override-existing-serviceaccounts \
       --region AWS_REGION \
       --approve
   ```

1. Agregue el repositorio de gráficos de Helm y actualice el repositorio local para asegurarse de que cuenta con los gráficos más recientes.

   ```
   helm repo add eks https://aws.github.io/eks-charts
   ```

   ```
   helm repo update eks
   ```

1. Instale el Controlador del equilibrador de carga de AWS. Sustituya el valor del nombre del clúster (`CLUSTER_NAME`), la región de AWS (`AWS_REGION`), el ID de VPC (`VPC_ID`) y la versión del gráfico de Helm del Controlador del equilibrador de carga de AWS (`AWS_LBC_HELM_VERSION`) por su configuración y ejecute el siguiente comando. Si ejecuta un clúster en modo mixto con nodos híbridos y nodos en la nube de AWS, puede ejecutar el Controlador del equilibrador de carga de AWS en los nodos en la nube según las instrucciones de [Controlador del equilibrador de carga de AWS](hybrid-nodes-webhooks.md#hybrid-nodes-mixed-lbc).
   + Para encontrar la versión más reciente del gráfico de Helm, ejecute `helm search repo eks/aws-load-balancer-controller --versions`.

     ```
     helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
       -n kube-system \
       --version AWS_LBC_HELM_VERSION \
       --set clusterName=CLUSTER_NAME \
       --set region=AWS_REGION \
       --set vpcId=VPC_ID \
       --set serviceAccount.create=false \
       --set serviceAccount.name=aws-load-balancer-controller
     ```

1. Compruebe que el Controlador del equilibrador de carga de AWS se haya instalado correctamente.

   ```
   kubectl get -n kube-system deployment aws-load-balancer-controller
   ```

   ```
   NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
   aws-load-balancer-controller   2/2     2            2           84s
   ```

1. Cree una aplicación de muestra. En el siguiente ejemplo, se utiliza la aplicación de microservicios de ejemplo [Istio BookInfo](https://istio.io/latest/docs/examples/bookinfo/).

   ```
   kubectl apply -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/bookinfo/platform/kube/bookinfo.yaml
   ```

1. Cree un archivo denominado `my-ingress-alb.yaml` con el siguiente contenido.

   ```
   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: my-ingress
     namespace: default
     annotations:
       alb.ingress.kubernetes.io/load-balancer-name: "my-ingress-alb"
       alb.ingress.kubernetes.io/target-type: "ip"
       alb.ingress.kubernetes.io/scheme: "internet-facing"
       alb.ingress.kubernetes.io/healthcheck-path: "/details/1"
   spec:
     ingressClassName: alb
     rules:
     - http:
         paths:
         - backend:
             service:
               name: details
               port:
                 number: 9080
           path: /details
           pathType: Prefix
   ```

1. Aplique la configuración de entrada al clúster.

   ```
   kubectl apply -f my-ingress-alb.yaml
   ```

1. El aprovisionamiento del ALB para el recurso de entrada puede tardar unos minutos. Una vez aprovisionado el ALB, el recurso de entrada tendrá asignada una dirección que se corresponderá con el nombre de DNS de la implementación del ALB. La dirección tendrá el formato `<alb-name>-<random-string>.<region>.elb.amazonaws.com`.

   ```
   kubectl get ingress my-ingress
   ```

   ```
   NAME         CLASS   HOSTS   ADDRESS                                                     PORTS   AGE
   my-ingress   alb     *       my-ingress-alb-<random-string>.<region>.elb.amazonaws.com   80      23m
   ```

1. Acceda al servicio con la dirección del ALB.

   ```
   curl -s http//my-ingress-alb-<random-string>.<region>.elb.amazonaws.com:80/details/1 | jq
   ```

   ```
   {
     "id": 1,
     "author": "William Shakespeare",
     "year": 1595,
     "type": "paperback",
     "pages": 200,
     "publisher": "PublisherA",
     "language": "English",
     "ISBN-10": "1234567890",
     "ISBN-13": "123-1234567890"
     "details": "This is the details page"
   }
   ```

## Información general sobre Cilium Ingress y Cilium Gateway
<a name="hybrid-nodes-ingress-cilium"></a>

Las capacidades de entrada de Cilium están integradas en la arquitectura de Cilium y se pueden administrar con API de Gateway o la API de Kubernetes Ingress. Si no tiene recursos de entrada existentes, AWS recomienda que comience con la API de Gateway, ya que es una forma más expresiva y flexible de definir y administrar los recursos de red de Kubernetes. La [API de Kubernetes Gateway](https://gateway-api.sigs.k8s.io/) tiene como objetivo estandarizar la forma en que se definen y administran los recursos de red de entrada, equilibrador de carga y malla de servicios en los clústeres de Kubernetes.

Al activar las características de entrada o puerta de enlace de Cilium, el operador de Cilium reconcilia los objetos de entrada y puerta de enlace del clúster y los proxies de Envoy de cada nodo procesan el tráfico de red de capa 7 (L7). Cilium no aprovisiona directamente la infraestructura de entrada y puerta de enlace, como los equilibradores de carga. Si planea usar Cilium Ingress o Gateway con un equilibrador de carga, debe usar las herramientas del equilibrador de carga, normalmente un controlador de entrada o puerta de enlace, para implementar y administrar la infraestructura del equilibrador de carga.

Para el tráfico de entrada o puerta de enlace, Cilium gestiona el tráfico de la red principal y el cumplimiento de las políticas de L3/L4, y los proxies de Envoy integrados procesan el tráfico de red de L7. Con Cilium Ingress o Gateway, Envoy es responsable de aplicar las reglas de enrutamiento de capa 7, las políticas y la manipulación de solicitudes, la administración avanzada del tráfico, como la división y duplicación del tráfico, y la terminación y el origen del TLS. Los proxies de Envoy de Cilium se implementan como un DaemonSet (`cilium-envoy`) independiente de forma predeterminada, lo que permite a Envoy y el agente de Cilium actualizarse, escalarse y administrarse por separado.

Para obtener más información sobre cómo funcionan Cilium Ingress y Cilium Gateway, consulte las páginas [Cilium Ingress](https://docs.cilium.io/en/stable/network/servicemesh/ingress/) y [Cilium Gateway](https://docs.cilium.io/en/stable/network/servicemesh/gateway-api/gateway-api/) en la documentación de Cilium.

## Comparación entre Cilium Ingress y Gateway
<a name="hybrid-nodes-ingress-cilium-comparison"></a>

En la siguiente tabla se resumen las características de Cilium Ingress y Cilium Gateway de la **versión 1.17.x de Cilium**.


| Característica | Ingress | Puerta de enlace | 
| --- | --- | --- | 
|  LoadBalancer del tipo de servicio  |  Sí  |  Sí  | 
|  NodePort del tipo de servicio  |  Sí  |  No1   | 
|  Red del host  |  Sí  |  Sí  | 
|  Equilibrador de carga compartido  |  Sí  |  Sí  | 
|  Equilibrador de carga dedicado  |  Sí  |  No2   | 
|  Políticas de red  |  Sí  |  Sí  | 
|  Protocolos  |  Capa 7 (HTTP(S), gRPC)  |  Capa 7 (HTTP(S), gRPC)3   | 
|  Acceso directo de TLS  |  Sí  |  Sí  | 
|  Administración del tráfico  |  Enrutamiento de rutas y hosts  |  Enrutamiento de rutas y hosts, redirección y reescritura de URL, división de tráfico, modificación de encabezados  | 

 1 Está prevista la compatibilidad de Cilium Gateway con servicios NodePort en la versión 1.18.x ([\$127273](https://github.com/cilium/cilium/pull/27273)) de Cilium

 2 Compatibilidad de Cilium Gateway con equilibradores de carga dedicados ([\$125567](https://github.com/cilium/cilium/issues/25567))

 3 Compatibilidad de Cilium Gateway con TCP/UDP ([\$121929](https://github.com/cilium/cilium/issues/21929))

## Instalación de Cilium Gateway
<a name="hybrid-nodes-ingress-cilium-gateway-install"></a>

### Consideraciones
<a name="_considerations_2"></a>
+ Cilium debe configurarse con `nodePort.enabled` establecido en `true`, como se muestra en los ejemplos siguientes. Si utiliza la característica de reemplazo de kube-proxy de Cilium, no necesita configurar `nodePort.enabled` en `true`.
+ Cilium debe configurarse con `envoy.enabled` establecido en `true`, como se muestra en los ejemplos siguientes.
+ Cilium Gateway se puede implementar en modo de equilibrador de carga (predeterminado) o en modo de red host.
+ Cuando se utiliza Cilium Gateway en modo de equilibrador de carga, la anotación `service.beta.kubernetes.io/aws-load-balancer-type: "external"` debe estar configurada en el recurso de puerta de enlace para evitar que el proveedor de nube de AWS heredado cree un Equilibrador de carga clásico para el servicio del tipo LoadBalancer que Cilium crea para el recurso de puerta de enlace.
+ Cuando se utiliza Cilium Gateway en el modo de red host, el servicio del tipo LoadBalancer está desactivado. El modo de red host es útil para entornos que no tienen una infraestructura de equilibrador de carga. Consulte [Red del host](#hybrid-nodes-ingress-cilium-host-network) para obtener más información.

### Requisitos previos
<a name="_prerequisites_2"></a>

1. Si tiene Helm instalado en su entorno de línea de comandos, consulte las [instrucciones de configuración de Helm](helm.md).

1. Se instaló Cilium según las instrucciones de [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md).

### Procedimiento
<a name="_procedure_2"></a>

1. Instale las definiciones de recursos personalizados (CRD) de la API de Kubernetes Gateway.

   ```
   kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.2.1/config/crd/standard/gateway.networking.k8s.io_gatewayclasses.yaml
   kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.2.1/config/crd/standard/gateway.networking.k8s.io_gateways.yaml
   kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.2.1/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml
   kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.2.1/config/crd/standard/gateway.networking.k8s.io_referencegrants.yaml
   kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.2.1/config/crd/standard/gateway.networking.k8s.io_grpcroutes.yaml
   ```

1. Cree un archivo denominado `cilium-gateway-values.yaml` con el siguiente contenido. En el siguiente ejemplo se configura Cilium Gateway para usar el modo de equilibrador de carga predeterminado y usar un DaemonSet `cilium-envoy` independiente para los proxies de Envoy configurados para que se ejecuten solo en nodos híbridos.

   ```
   gatewayAPI:
     enabled: true
     # uncomment to use host network mode
     # hostNetwork:
     #   enabled: true
   nodePort:
     enabled: true
   envoy:
     enabled: true
     affinity:
       nodeAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
           nodeSelectorTerms:
           - matchExpressions:
             - key: eks.amazonaws.com/compute-type
               operator: In
               values:
               - hybrid
   ```

1. Aplique el archivo de valores de Helm al clúster.

   ```
   helm upgrade cilium oci://public.ecr.aws/eks/cilium/cilium \
     --namespace kube-system \
     --reuse-values \
     --set operator.rollOutPods=true \
     --values cilium-gateway-values.yaml
   ```

1. Confirme que el operador, el agente y los pods de Envoy de Cilium estén en ejecución.

   ```
   kubectl -n kube-system get pods --selector=app.kubernetes.io/part-of=cilium
   ```

   ```
   NAME                               READY   STATUS    RESTARTS   AGE
   cilium-envoy-5pgnd                 1/1     Running   0          6m31s
   cilium-envoy-6fhg4                 1/1     Running   0          6m30s
   cilium-envoy-jskrk                 1/1     Running   0          6m30s
   cilium-envoy-k2xtb                 1/1     Running   0          6m31s
   cilium-envoy-w5s9j                 1/1     Running   0          6m31s
   cilium-grwlc                       1/1     Running   0          4m12s
   cilium-operator-68f7766967-5nnbl   1/1     Running   0          4m20s
   cilium-operator-68f7766967-7spfz   1/1     Running   0          4m20s
   cilium-pnxcv                       1/1     Running   0          6m29s
   cilium-r7qkj                       1/1     Running   0          4m12s
   cilium-wxhfn                       1/1     Running   0          4m1s
   cilium-z7hlb                       1/1     Running   0          6m30s
   ```

## Configuración de Cilium Gateway
<a name="hybrid-nodes-ingress-cilium-gateway-configure"></a>

Cilium Gateway se activa en objetos de puerta de enlace mediante la configuración de `gatewayClassName` como `cilium`. El servicio que Cilium crea para los recursos de puerta de enlace se puede configurar con los campos del objeto de puerta de enlace. Las anotaciones habituales que utilizan los controladores de puerta de enlace para configurar la infraestructura del equilibrador de carga se pueden configurar con el campo `infrastructure` del objeto de puerta de enlace. Cuando se utiliza el IPAM LoadBalancer de Cilium (consulte el ejemplo de [LoadBalancer del tipo de servicio](#hybrid-nodes-ingress-cilium-loadbalancer)), la dirección IP que se utilizará para el servicio del tipo LoadBalancer se puede configurar en el campo `addresses` del objeto de puerta de enlace. Para obtener más información sobre la configuración de la puerta de enlace, consulte la [especificación de la API de Kubernetes Gateway](https://gateway-api.sigs.k8s.io/reference/spec/#gateway).

```
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
spec:
  gatewayClassName: cilium
  infrastructure:
    annotations:
      service.beta.kubernetes.io/...
      service.kuberentes.io/...
  addresses:
  - type: IPAddress
    value: <LoadBalancer IP address>
  listeners:
  ...
```

Cilium y la especificación de Kubernetes Gateway admiten los recursos GatewayClass, de puerta de enlace, HTTPRoute, GRPCRoute y ReferenceGrant.
+ Consulte las especificaciones de [HTTPRoute](https://gateway-api.sigs.k8s.io/api-types/httproute/HTTPRoute) y [GRPCRoute](https://gateway-api.sigs.k8s.io/api-types/grpcroute/GRPCRoute) para ver la lista de campos disponibles.
+ Consulte los ejemplos de la sección [Implementación de Cilium Gateway](#hybrid-nodes-ingress-cilium-gateway-deploy) a continuación y los ejemplos de la [documentación de Cilium](https://docs.cilium.io/en/stable/network/servicemesh/gateway-api/gateway-api/#examples) para saber cómo utilizar y configurar estos recursos.

## Implementación de Cilium Gateway
<a name="hybrid-nodes-ingress-cilium-gateway-deploy"></a>

1. Cree una aplicación de muestra. En el siguiente ejemplo, se utiliza la aplicación de microservicios de ejemplo [Istio BookInfo](https://istio.io/latest/docs/examples/bookinfo/).

   ```
   kubectl apply -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/bookinfo/platform/kube/bookinfo.yaml
   ```

1. Compruebe que la aplicación se esté ejecutando correctamente.

   ```
   kubectl get pods
   ```

   ```
   NAME                              READY   STATUS    RESTARTS   AGE
   details-v1-766844796b-9965p       1/1     Running   0          81s
   productpage-v1-54bb874995-jmc8j   1/1     Running   0          80s
   ratings-v1-5dc79b6bcd-smzxz       1/1     Running   0          80s
   reviews-v1-598b896c9d-vj7gb       1/1     Running   0          80s
   reviews-v2-556d6457d-xbt8v        1/1     Running   0          80s
   reviews-v3-564544b4d6-cpmvq       1/1     Running   0          80s
   ```

1. Cree un archivo denominado `my-gateway.yaml` con el siguiente contenido. En el ejemplo siguiente se utiliza la anotación `service.beta.kubernetes.io/aws-load-balancer-type: "external"` para evitar que el proveedor de nube de AWS heredado cree un Equilibrador de carga clásico para el servicio del tipo LoadBalancer que Cilium crea para el recurso de puerta de enlace.

   ```
   ---
   apiVersion: gateway.networking.k8s.io/v1
   kind: Gateway
   metadata:
     name: my-gateway
   spec:
     gatewayClassName: cilium
     infrastructure:
       annotations:
         service.beta.kubernetes.io/aws-load-balancer-type: "external"
     listeners:
     - protocol: HTTP
       port: 80
       name: web-gw
       allowedRoutes:
         namespaces:
           from: Same
   ---
   apiVersion: gateway.networking.k8s.io/v1
   kind: HTTPRoute
   metadata:
     name: http-app-1
   spec:
     parentRefs:
     - name: my-gateway
       namespace: default
     rules:
     - matches:
       - path:
           type: PathPrefix
           value: /details
       backendRefs:
       - name: details
         port: 9080
   ```

1. Aplique el recurso de puerta de enlace al clúster.

   ```
   kubectl apply -f my-gateway.yaml
   ```

1. Confirme que se hayan creado el recurso de puerta de enlace y el servicio correspondiente. En esta fase, se espera que el campo `ADDRESS` del recurso de puerta de enlace no se complete con una dirección IP o un nombre de host y que el servicio del tipo LoadBalancer para el recurso de puerta de enlace tampoco tenga una dirección IP o un nombre de host asignados.

   ```
   kubectl get gateway my-gateway
   ```

   ```
   NAME         CLASS    ADDRESS   PROGRAMMED   AGE
   my-gateway   cilium             True         10s
   ```

   ```
   kubectl get svc cilium-gateway-my-gateway
   ```

   ```
   NAME                        TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
   cilium-gateway-my-gateway   LoadBalancer   172.16.227.247   <pending>     80:30912/TCP   24s
   ```

1. Continúe con [LoadBalancer del tipo de servicio](#hybrid-nodes-ingress-cilium-loadbalancer) para configurar el recurso de puerta de enlace a fin de que utilice una dirección IP asignada por Cilium Load Balancer IPAM, y con [NodePort del tipo de servicio](#hybrid-nodes-ingress-cilium-nodeport) o [Red del host](#hybrid-nodes-ingress-cilium-host-network) para configurar el recurso de puerta de enlace a fin de que utilice direcciones de red de NodePort o host.

## Instalación de Cilium Ingress
<a name="hybrid-nodes-ingress-cilium-ingress-install"></a>

### Consideraciones
<a name="_considerations_3"></a>
+ Cilium debe configurarse con `nodePort.enabled` establecido en `true`, como se muestra en los ejemplos siguientes. Si utiliza la característica de reemplazo de kube-proxy de Cilium, no necesita configurar `nodePort.enabled` en `true`.
+ Cilium debe configurarse con `envoy.enabled` establecido en `true`, como se muestra en los ejemplos siguientes.
+ Si se establece `ingressController.loadbalancerMode` en `dedicated`, Cilium crea servicios dedicados para cada recurso de entrada. Si se establece `ingressController.loadbalancerMode` en `shared`, Cilium crea un servicio compartido del tipo LoadBalancer para todos los recursos de entrada del clúster. Cuando se utiliza el modo de equilibrador de carga `shared`, la configuración del servicio compartido como `labels`, `annotations`, `type` y `loadBalancerIP` se configura en la sección `ingressController.service` de valores de Helm. Consulte la [referencia de valores de Helm de Cilium](https://github.com/cilium/cilium/blob/v1.17.6/install/kubernetes/cilium/values.yaml#L887) para obtener más información.
+ Si se establece `ingressController.default` en `true`, Cilium se configura como el controlador de entrada predeterminado para el clúster y creará entradas incluso cuando no se especifique `ingressClassName` en los recursos de entrada.
+ Cilium Ingress se puede implementar en modo de equilibrador de carga (predeterminado), puerto de nodos o red host. Cuando Cilium se instala en el modo de red host, los modos de servicio del tipo LoadBalancer y NodePort están desactivados. Para obtener más información, consulte [Red del host](#hybrid-nodes-ingress-cilium-host-network).
+ Establezca siempre `ingressController.service.annotations` como `service.beta.kubernetes.io/aws-load-balancer-type: "external"` en los valores de Helm para evitar que el proveedor de nube de AWS heredado cree un Equilibrador de carga clásico para el servicio de `cilium-ingress` predeterminado creado por el [gráfico de Helm de Cilium](https://github.com/cilium/cilium/blob/main/install/kubernetes/cilium/templates/cilium-ingress-service.yaml).

### Requisitos previos
<a name="_prerequisites_3"></a>

1. Si tiene Helm instalado en su entorno de línea de comandos, consulte las [instrucciones de configuración de Helm](helm.md).

1. Se instaló Cilium según las instrucciones de [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md).

### Procedimiento
<a name="_procedure_3"></a>

1. Cree un archivo denominado `cilium-ingress-values.yaml` con el siguiente contenido. En el siguiente ejemplo se configura Cilium Ingress para usar el modo `dedicated` del equilibrador de carga predeterminado y usar un DaemonSet de `cilium-envoy` independiente para los proxies de Envoy configurados para que se ejecuten solo en nodos híbridos.

   ```
   ingressController:
     enabled: true
     loadbalancerMode: dedicated
     service:
       annotations:
         service.beta.kubernetes.io/aws-load-balancer-type: "external"
   nodePort:
     enabled: true
   envoy:
     enabled: true
     affinity:
       nodeAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
           nodeSelectorTerms:
           - matchExpressions:
             - key: eks.amazonaws.com/compute-type
               operator: In
               values:
               - hybrid
   ```

1. Aplique el archivo de valores de Helm al clúster.

   ```
   helm upgrade cilium oci://public.ecr.aws/eks/cilium/cilium \
     --namespace kube-system \
     --reuse-values \
     --set operator.rollOutPods=true \
     --values cilium-ingress-values.yaml
   ```

1. Confirme que el operador, el agente y los pods de Envoy de Cilium estén en ejecución.

   ```
   kubectl -n kube-system get pods --selector=app.kubernetes.io/part-of=cilium
   ```

   ```
   NAME                               READY   STATUS    RESTARTS   AGE
   cilium-envoy-5pgnd                 1/1     Running   0          6m31s
   cilium-envoy-6fhg4                 1/1     Running   0          6m30s
   cilium-envoy-jskrk                 1/1     Running   0          6m30s
   cilium-envoy-k2xtb                 1/1     Running   0          6m31s
   cilium-envoy-w5s9j                 1/1     Running   0          6m31s
   cilium-grwlc                       1/1     Running   0          4m12s
   cilium-operator-68f7766967-5nnbl   1/1     Running   0          4m20s
   cilium-operator-68f7766967-7spfz   1/1     Running   0          4m20s
   cilium-pnxcv                       1/1     Running   0          6m29s
   cilium-r7qkj                       1/1     Running   0          4m12s
   cilium-wxhfn                       1/1     Running   0          4m1s
   cilium-z7hlb                       1/1     Running   0          6m30s
   ```

## Configuración de Cilium Ingress
<a name="hybrid-nodes-ingress-cilium-ingress-configure"></a>

Cilium Ingress se activa en objetos de entrada mediante la configuración de `ingressClassName` como `cilium`. Los servicios que Cilium crea para los recursos de entrada se pueden configurar con anotaciones en los objetos de entrada cuando se utiliza el modo `dedicated` del equilibrador de carga y en la configuración de Cilium o Helm cuando se utiliza el modo `shared` del equilibrador de carga. Los controladores de entrada suelen utilizar estas anotaciones para configurar la infraestructura del equilibrador de carga u otros atributos del servicio, como el tipo de servicio, el modo del equilibrador de carga, los puertos y los accesos directos a TLS. Las anotaciones clave se describen a continuación. Para obtener una lista completa de las anotaciones admitidas, consulte las [anotaciones de Cilium Ingress](https://docs.cilium.io/en/stable/network/servicemesh/ingress/#supported-ingress-annotations) en la documentación de Cilium.


| Anotación | Descripción | 
| --- | --- | 
|   `ingress.cilium.io/loadbalancer-mode`   |   `dedicated`: servicio dedicado del tipo LoadBalancer para cada recurso de entrada (predeterminado).  `shared`: servicio único del tipo LoadBalancer para todos los recursos de entrada.  | 
|   `ingress.cilium.io/service-type`   |   `LoadBalancer`: el servicio será del tipo LoadBalancer (predeterminado).  `NodePort`: el servicio será del tipo NodePort.  | 
|   `service.beta.kubernetes.io/aws-load-balancer-type`   |   `"external"`: evite que un proveedor de nube de AWS heredado aprovisione el Equilibrador de carga clásico para servicios del tipo LoadBalancer.  | 
|   `lbipam.cilium.io/ips`   |  Lista de direcciones IP para asignar desde el IPAM LoadBalancer de Cilium  | 

La especificación de Cilium y Kubernetes Ingress admiten reglas de coincidencia exactas, de prefijo y específicas de implementación para las rutas de entrada. Cilium admite las expresiones regulares como regla de coincidencia específica de la implementación. Para obtener más información, consulte [Ingress path types and precedence](https://docs.cilium.io/en/stable/network/servicemesh/ingress/#ingress-path-types-and-precedence) y [Path types examples](https://docs.cilium.io/en/stable/network/servicemesh/path-types/) en la documentación de Cilium, así como los ejemplos de la sección [Implementación de Cilium Ingress](#hybrid-nodes-ingress-cilium-ingress-deploy) de esta página.

A continuación, se muestra un ejemplo de objeto de Cilium Ingress.

```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    service.beta.kuberentes.io/...
    service.kuberentes.io/...
spec:
  ingressClassName: cilium
  rules:
  ...
```

## Implementación de Cilium Ingress
<a name="hybrid-nodes-ingress-cilium-ingress-deploy"></a>

1. Cree una aplicación de muestra. En el siguiente ejemplo, se utiliza la aplicación de microservicios de ejemplo [Istio BookInfo](https://istio.io/latest/docs/examples/bookinfo/).

   ```
   kubectl apply -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/bookinfo/platform/kube/bookinfo.yaml
   ```

1. Compruebe que la aplicación se esté ejecutando correctamente.

   ```
   kubectl get pods
   ```

   ```
   NAME                              READY   STATUS    RESTARTS   AGE
   details-v1-766844796b-9965p       1/1     Running   0          81s
   productpage-v1-54bb874995-jmc8j   1/1     Running   0          80s
   ratings-v1-5dc79b6bcd-smzxz       1/1     Running   0          80s
   reviews-v1-598b896c9d-vj7gb       1/1     Running   0          80s
   reviews-v2-556d6457d-xbt8v        1/1     Running   0          80s
   reviews-v3-564544b4d6-cpmvq       1/1     Running   0          80s
   ```

1. Cree un archivo denominado `my-ingress.yaml` con el siguiente contenido. En el ejemplo siguiente se utiliza la anotación `service.beta.kubernetes.io/aws-load-balancer-type: "external"` para evitar que el proveedor de nube de AWS heredado cree un Equilibrador de carga clásico para el servicio del tipo LoadBalancer que Cilium crea para el recurso de entrada.

   ```
   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: my-ingress
     namespace: default
     annotations:
       service.beta.kubernetes.io/aws-load-balancer-type: "external"
   spec:
     ingressClassName: cilium
     rules:
     - http:
         paths:
         - backend:
             service:
               name: details
               port:
                 number: 9080
           path: /details
           pathType: Prefix
   ```

1. Aplique el recurso de entrada al clúster.

   ```
   kubectl apply -f my-ingress.yaml
   ```

1. Confirme que se hayan creado el recurso de entrada y el servicio correspondiente. En esta fase, se espera que el campo `ADDRESS` del recurso de entrada no se complete con una dirección IP o un nombre de host y que el servicio compartido o dedicado del tipo LoadBalancer para el recurso de entrada tampoco tenga una dirección IP o un nombre de host asignados.

   ```
   kubectl get ingress my-ingress
   ```

   ```
   NAME         CLASS    HOSTS   ADDRESS   PORTS   AGE
   my-ingress   cilium   *                 80      8s
   ```

   Para el modo del equilibrador de carga `shared` 

   ```
   kubectl -n kube-system get svc cilium-ingress
   ```

   ```
   NAME             TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
   cilium-ingress   LoadBalancer   172.16.217.48   <pending>     80:32359/TCP,443:31090/TCP   10m
   ```

   Para el modo del equilibrador de carga `dedicated` 

   ```
   kubectl -n default get svc cilium-ingress-my-ingress
   ```

   ```
   NAME                        TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
   cilium-ingress-my-ingress   LoadBalancer   172.16.193.15   <pending>     80:32088/TCP,443:30332/TCP   25s
   ```

1. Continúe con [LoadBalancer del tipo de servicio](#hybrid-nodes-ingress-cilium-loadbalancer) para configurar el recurso de entrada a fin de que utilice una dirección IP asignada por Cilium Load Balancer IPAM, y con [NodePort del tipo de servicio](#hybrid-nodes-ingress-cilium-nodeport) o [Red del host](#hybrid-nodes-ingress-cilium-host-network) para configurar el recurso de entrada a fin de que utilice direcciones de red de NodePort o host.

## LoadBalancer del tipo de servicio
<a name="hybrid-nodes-ingress-cilium-loadbalancer"></a>

### Infraestructura del equilibrador de carga existente
<a name="_existing_load_balancer_infrastructure"></a>

De forma predeterminada, tanto para Cilium Ingress como para Cilium Gateway, Cilium crea los servicios de Kubernetes del tipo LoadBalancer para los recursos de entrada o puerta de enlace. Los atributos de los servicios que crea Cilium se pueden configurar mediante los recursos de entrada y puerta de enlace. Al crear recursos de entrada o puerta de enlace, la dirección IP expuesta externamente o los nombres de host de dicha entrada o puerta de enlace se asignan desde la infraestructura del equilibrador de carga, que se suele aprovisionar mediante un controlador de entrada o puerta de enlace.

Muchos controladores de entrada y puerta de enlace utilizan anotaciones para detectar y configurar la infraestructura del equilibrador de carga. Las anotaciones de estos controladores de entrada y puerta de enlace se configuran en los recursos de entrada o puerta de enlace, como se muestra en los ejemplos anteriores. Consulte la documentación del controlador de entrada o puerta de enlace para ver las anotaciones compatibles, así como la [documentación de Kubernetes Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/) y [la documentación de Kubernetes Gateway](https://gateway-api.sigs.k8s.io/implementations/) para ver una lista de controladores populares.

**importante**  
Cilium Ingress y Gateway no se pueden usar con el Controlador del equilibrador de carga de AWS y los Equilibradores de carga de red de AWS con Nodos híbridos de EKS. Al intentar usarlos juntos, los destinos no se registran, ya que el NLB intenta conectarse directamente a las IP del pod que respaldan el servicio del tipo LoadBalancer cuando el `target-type` del NLB está configurado en `ip` (requisito para usar el NLB con cargas de trabajo que se ejecutan en Nodos híbridos de EKS).

### Sin infraestructura del equilibrador de carga
<a name="_no_load_balancer_infrastructure"></a>

Si no tienen ninguna infraestructura del equilibrador de carga y el controlador de entrada o puerta de enlace correspondiente en su entorno, los recursos de entrada o puerta de enlace y los servicios correspondientes del tipo LoadBalancer se pueden configurar para utilizar las direcciones IP asignadas por [Load Balancer IP address management](https://docs.cilium.io/en/stable/network/lb-ipam/) (LB IPAM) de Cilium. LB IPAM de Cilium se puede configurar con rangos de direcciones IP conocidos de su entorno en las instalaciones y puede utilizar la compatibilidad integrada con el protocolo de puerta de enlace fronteriza (BGP) de Cilium o los anuncios de L2 para anunciar las direcciones IP del LoadBalancer en su red en las instalaciones.

En el siguiente ejemplo se muestra cómo configurar LB IPAM de Cilium con una dirección IP para utilizarla en los recursos de entrada o puerta de enlace, y cómo configurar Cilium BGP Control Plane para anunciar la dirección IP del LoadBalancer en la red en las instalaciones. La característica LB IPAM de Cilium está activada de forma predeterminada, pero no se activa hasta que se crea un recurso `CiliumLoadBalancerIPPool`.

#### Requisitos previos
<a name="_prerequisites_4"></a>
+ Se ha instalado Cilium Ingress o Gateway según las instrucciones de [Instalación de Cilium Ingress](#hybrid-nodes-ingress-cilium-ingress-install) o [Instalación de Cilium Gateway](#hybrid-nodes-ingress-cilium-gateway-install).
+ Se han implementado los recursos de Cilium Ingress o Gateway con una aplicación de ejemplo según las instrucciones de [Implementación de Cilium Ingress](#hybrid-nodes-ingress-cilium-ingress-deploy) o [Implementación de Cilium Gateway](#hybrid-nodes-ingress-cilium-gateway-deploy).
+ Cilium BGP Control Plane está activado según las instrucciones de [Configuración del BGP de Cilium para nodos híbridos](hybrid-nodes-cilium-bgp.md). Si no desea utilizar el BGP, puede omitir este requisito previo, pero no podrá acceder a su recurso de entrada o puerta de enlace hasta que la dirección IP del LoadBalancer asignada por LB IPAM de Cilium se pueda enrutar en su red en las instalaciones.

#### Procedimiento
<a name="_procedure_4"></a>

1. Opcionalmente, parchee el recurso de entrada o puerta de enlace para solicitar una dirección IP específica para usarla en el servicio del tipo LoadBalancer. Si no solicita ninguna dirección IP específica, Cilium asignará una dirección IP del rango de direcciones IP configurado en el recurso `CiliumLoadBalancerIPPool` en el paso siguiente. En los comandos siguientes, sustituya `LB_IP_ADDRESS` por la dirección IP para solicitar el servicio del tipo LoadBalancer.

    **Puerta de enlace** 

   ```
   kubectl patch gateway -n default my-gateway --type=merge -p '{
     "spec": {
       "addresses": [{"type": "IPAddress", "value": "LB_IP_ADDRESS"}]
     }
   }'
   ```

    **Ingreso** 

   ```
   kubectl patch ingress my-ingress --type=merge -p '{
     "metadata": {"annotations": {"lbipam.cilium.io/ips": "LB_IP_ADDRESS"}}
   }'
   ```

1. Cree un archivo llamado `cilium-lbip-pool-ingress.yaml` con un recurso `CiliumLoadBalancerIPPool` para configurar el rango de direcciones IP del equilibrador de carga para los recursos de entrada o puerta de enlace.
   + Si utiliza Cilium Ingress, Cilium aplica automáticamente la etiqueta `cilium.io/ingress: "true"` a los servicios que crea para los recursos de entrada. Puede utilizar esta etiqueta en el campo `serviceSelector` de la definición del recurso `CiliumLoadBalancerIPPool` para seleccionar los servicios aptos para LB IPAM.
   + Si utiliza Cilium Gateway, puede utilizar la etiqueta `gateway.networking.k8s.io/gateway-name` en los campos `serviceSelector` de la definición del recurso `CiliumLoadBalancerIPPool` para seleccionar los recursos de puerta de enlace aptos para LB IPAM.
   + Reemplace `LB_IP_CIDR` por el rango de direcciones IP para utilizar las direcciones IP del equilibrador de carga. Para seleccionar una sola dirección IP, use un CIDR `/32`. Para obtener más información, consulte [LoadBalancer IP Address Management](https://docs.cilium.io/en/stable/network/lb-ipam/) en la documentación de Cilium.

     ```
     apiVersion: cilium.io/v2alpha1
     kind: CiliumLoadBalancerIPPool
     metadata:
       name: bookinfo-pool
     spec:
       blocks:
       - cidr: "LB_IP_CIDR"
       serviceSelector:
         # if using Cilium Gateway
         matchExpressions:
           - { key: gateway.networking.k8s.io/gateway-name, operator: In, values: [ my-gateway ] }
         # if using Cilium Ingress
         matchLabels:
           cilium.io/ingress: "true"
     ```

1. Aplique el recurso `CiliumLoadBalancerIPPool` al clúster.

   ```
   kubectl apply -f cilium-lbip-pool-ingress.yaml
   ```

1. Confirme que se haya asignado una dirección IP desde LB IPAM de Cilium para el recurso de entrada o puerta de enlace.

    **Puerta de enlace** 

   ```
   kubectl get gateway my-gateway
   ```

   ```
   NAME         CLASS    ADDRESS        PROGRAMMED   AGE
   my-gateway   cilium   LB_IP_ADDRESS    True         6m41s
   ```

    **Ingreso** 

   ```
   kubectl get ingress my-ingress
   ```

   ```
   NAME         CLASS    HOSTS   ADDRESS        PORTS   AGE
   my-ingress   cilium   *       LB_IP_ADDRESS   80      10m
   ```

1. Cree un archivo llamado `cilium-bgp-advertisement-ingress.yaml` con un recurso `CiliumBGPAdvertisement` para anunciar la dirección IP del LoadBalancer para los recursos de entrada o puerta de enlace. Si no utiliza el BGP de Cilium, puede saltarse este paso. La dirección IP del LoadBalancer utilizada para el recurso de entrada o puerta de enlace debe poder enrutarse en la red en las instalaciones para que pueda consultar el servicio en el siguiente paso.

   ```
   apiVersion: cilium.io/v2alpha1
   kind: CiliumBGPAdvertisement
   metadata:
     name: bgp-advertisement-lb-ip
     labels:
       advertise: bgp
   spec:
     advertisements:
       - advertisementType: "Service"
         service:
           addresses:
             - LoadBalancerIP
         selector:
           # if using Cilium Gateway
           matchExpressions:
             - { key: gateway.networking.k8s.io/gateway-name, operator: In, values: [ my-gateway ] }
           # if using Cilium Ingress
           matchLabels:
             cilium.io/ingress: "true"
   ```

1. Aplique el recurso `CiliumBGPAdvertisement` al clúster.

   ```
   kubectl apply -f cilium-bgp-advertisement-ingress.yaml
   ```

1. Acceda al servicio mediante la dirección IP asignada desde LB IPAM de Cilium.

   ```
   curl -s http://LB_IP_ADDRESS:80/details/1 | jq
   ```

   ```
   {
     "id": 1,
     "author": "William Shakespeare",
     "year": 1595,
     "type": "paperback",
     "pages": 200,
     "publisher": "PublisherA",
     "language": "English",
     "ISBN-10": "1234567890",
     "ISBN-13": "123-1234567890"
   }
   ```

## NodePort del tipo de servicio
<a name="hybrid-nodes-ingress-cilium-nodeport"></a>

Si no tiene ninguna infraestructura del equilibrador de carga y el controlador de entrada correspondiente en su entorno, o si autoadministra su infraestructura del equilibrador de carga o utiliza un equilibrador de carga basado en DNS, puede configurar Cilium Ingress para crear servicios del tipo NodePort para los recursos de entrada. Cuando se utiliza NodePort con Cilium Ingress, el servicio del tipo NodePort se expone en un puerto de cada nodo en el rango de puertos 30000-32767. En este modo, cuando el tráfico llega a cualquier nodo del clúster de NodePort, se reenvía a un pod que respalda el servicio, que puede estar en el mismo nodo o en un nodo diferente.

**nota**  
Está prevista la compatibilidad de Cilium Gateway con servicios NodePort en la versión 1.18.x ([\$127273](https://github.com/cilium/cilium/pull/27273)) de Cilium

### Requisitos previos
<a name="_prerequisites_5"></a>
+ Se ha instalado Cilium Ingress según las instrucciones de [Instalación de Cilium Ingress](#hybrid-nodes-ingress-cilium-ingress-install).
+ Se han implementado los recursos de Cilium Ingress con una aplicación de ejemplo según las instrucciones de [Implementación de Cilium Ingress](#hybrid-nodes-ingress-cilium-ingress-deploy).

### Procedimiento
<a name="_procedure_5"></a>

1. Parchee el recurso `my-ingress` de entrada existente para cambiarlo del tipo de servicio LoadBalancer a NodePort.

   ```
   kubectl patch ingress my-ingress --type=merge -p '{
       "metadata": {"annotations": {"ingress.cilium.io/service-type": "NodePort"}}
   }'
   ```

   Si no ha creado el recurso de entrada, puede aplicar la siguiente definición de entrada al clúster para crearlo. Tenga en cuenta que la siguiente definición de entrada utiliza la aplicación de ejemplo Istio BookInfo descrita en [Implementación de Cilium Ingress](#hybrid-nodes-ingress-cilium-ingress-deploy).

   ```
   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: my-ingress
     namespace: default
     annotations:
       service.beta.kubernetes.io/aws-load-balancer-type: "external"
       "ingress.cilium.io/service-type": "NodePort"
   spec:
     ingressClassName: cilium
     rules:
     - http:
         paths:
         - backend:
             service:
               name: details
               port:
                 number: 9080
           path: /details
           pathType: Prefix
   ```

1. Confirme que el servicio del recurso de entrada se haya actualizado para usar el tipo de servicio NodePort. Anote el puerto del protocolo HTTP en la salida. En el siguiente ejemplo, el puerto HTTP es `32353`, que se utilizará en un paso posterior para consultar el servicio. La ventaja de utilizar Cilium Ingress con un servicio del tipo NodePort es que puede aplicar un enrutamiento basado en rutas y hosts, así como políticas de red para el tráfico de entrada, lo que no puede hacer con un servicio estándar del tipo NodePort sin entrada.

   ```
   kubectl -n default get svc cilium-ingress-my-ingress
   ```

   ```
   NAME                        TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
   cilium-ingress-my-ingress   NodePort   172.16.47.153   <none>        80:32353/TCP,443:30253/TCP   27m
   ```

1. Obtenga las direcciones IP de los nodos en el clúster.

   ```
   kubectl get nodes -o wide
   ```

   ```
   NAME                   STATUS   ROLES    AGE   VERSION               INTERNAL-IP     EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION       CONTAINER-RUNTIME
   mi-026d6a261e355fba7   Ready    <none>   23h   v1.32.3-eks-473151a   10.80.146.150   <none>        Ubuntu 22.04.5 LTS   5.15.0-142-generic   containerd://1.7.27
   mi-082f73826a163626e   Ready    <none>   23h   v1.32.3-eks-473151a   10.80.146.32    <none>        Ubuntu 22.04.4 LTS   5.15.0-142-generic   containerd://1.7.27
   mi-09183e8a3d755abf6   Ready    <none>   23h   v1.32.3-eks-473151a   10.80.146.33    <none>        Ubuntu 22.04.4 LTS   5.15.0-142-generic   containerd://1.7.27
   mi-0d78d815980ed202d   Ready    <none>   23h   v1.32.3-eks-473151a   10.80.146.97    <none>        Ubuntu 22.04.4 LTS   5.15.0-142-generic   containerd://1.7.27
   mi-0daa253999fe92daa   Ready    <none>   23h   v1.32.3-eks-473151a   10.80.146.100   <none>        Ubuntu 22.04.4 LTS   5.15.0-142-generic   containerd://1.7.27
   ```

1. Acceda al servicio del tipo NodePort con las direcciones IP de sus nodos y el NodePort capturado anteriormente. En el siguiente ejemplo, la dirección IP del nodo utilizada es `10.80.146.32`, mientras que el NodePort es `32353`. Sustitúyalos por los valores correspondientes al entorno.

   ```
   curl -s http://10.80.146.32:32353/details/1 | jq
   ```

   ```
   {
     "id": 1,
     "author": "William Shakespeare",
     "year": 1595,
     "type": "paperback",
     "pages": 200,
     "publisher": "PublisherA",
     "language": "English",
     "ISBN-10": "1234567890",
     "ISBN-13": "123-1234567890"
   }
   ```

## Red del host
<a name="hybrid-nodes-ingress-cilium-host-network"></a>

Al igual que en el servicio del tipo NodePort, si no tiene ninguna infraestructura del equilibrador de carga ni un controlador de entrada o puerta de enlace, o si autoadministra el equilibrio de carga con un equilibrador de carga externo, puede configurar Cilium Ingress y Cilium Gateway para exponer los recursos de entrada y puerta de enlace directamente en la red host. Cuando el modo de red host está activado para un recurso de entrada o puerta de enlace, los modos de servicio del tipo LoadBalancer y NodePort se desactivan automáticamente, el modo de red host se excluye mutuamente con estos modos alternativos para cada recurso de entrada o puerta de enlace. En comparación con el modo del servicio del tipo NodePort, el modo de red host ofrece flexibilidad adicional para el rango de puertos que se pueden usar (no está restringido al rango NodePort 30000-32767) y puede configurar un subconjunto de nodos donde los proxies de Envoy se ejecutan en la red host.

### Requisitos previos
<a name="_prerequisites_6"></a>
+ Se ha instalado Cilium Ingress o Gateway según las instrucciones de [Instalación de Cilium Ingress](#hybrid-nodes-ingress-cilium-ingress-install) o [Instalación de Cilium Gateway](#hybrid-nodes-ingress-cilium-gateway-install).

### Procedimiento
<a name="_procedure_6"></a>

#### Puerta de enlace
<a name="_gateway"></a>

1. Cree un archivo llamado `cilium-gateway-host-network.yaml` con el siguiente contenido.

   ```
   gatewayAPI:
     enabled: true
     hostNetwork:
       enabled: true
       # uncomment to restrict nodes where Envoy proxies run on the host network
       # nodes:
       #   matchLabels:
       #     role: gateway
   ```

1. Aplique la configuración de Cilium Gateway de red host al clúster.

   ```
   helm upgrade cilium oci://public.ecr.aws/eks/cilium/cilium \
     --namespace kube-system \
     --reuse-values \
     --set operator.rollOutPods=true \
     -f cilium-gateway-host-network.yaml
   ```

   Si no ha creado el recurso de puerta de enlace, puede aplicar la siguiente definición de puerta de enlace al clúster para crearlo. La siguiente definición de puerta de enlace utiliza la aplicación de ejemplo Istio BookInfo descrita en [Implementación de Cilium Gateway](#hybrid-nodes-ingress-cilium-gateway-deploy). En el siguiente ejemplo, el recurso de puerta de enlace está configurado para usar el puerto `8111` del oyente HTTP, que es el puerto de oyente compartido para los proxies de Envoy que se ejecutan en la red host. Si utiliza un puerto privilegiado (inferior a 1023) para el recurso de puerta de enlace, consulte la [documentación de Cilium](https://docs.cilium.io/en/stable/network/servicemesh/gateway-api/gateway-api/#bind-to-privileged-port) para obtener instrucciones.

   ```
   ---
   apiVersion: gateway.networking.k8s.io/v1
   kind: Gateway
   metadata:
     name: my-gateway
   spec:
     gatewayClassName: cilium
     listeners:
     - protocol: HTTP
       port: 8111
       name: web-gw
       allowedRoutes:
         namespaces:
           from: Same
   ---
   apiVersion: gateway.networking.k8s.io/v1
   kind: HTTPRoute
   metadata:
     name: http-app-1
   spec:
     parentRefs:
     - name: my-gateway
       namespace: default
     rules:
     - matches:
       - path:
           type: PathPrefix
           value: /details
       backendRefs:
       - name: details
         port: 9080
   ```

   Puede observar la configuración de Envoy de Cilium aplicada con el siguiente comando.

   ```
   kubectl get cec cilium-gateway-my-gateway -o yaml
   ```

   Puede obtener el puerto de oyente de Envoy para el servicio `cilium-gateway-my-gateway` con el siguiente comando. En este ejemplo, el puerto de oyente compartido es `8111`.

   ```
   kubectl get cec cilium-gateway-my-gateway -o jsonpath={.spec.services[0].ports[0]}
   ```

1. Obtenga las direcciones IP de los nodos en el clúster.

   ```
   kubectl get nodes -o wide
   ```

   ```
   NAME                   STATUS   ROLES    AGE   VERSION               INTERNAL-IP     EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION       CONTAINER-RUNTIME
   mi-026d6a261e355fba7   Ready    <none>   23h   v1.32.3-eks-473151a   10.80.146.150   <none>        Ubuntu 22.04.5 LTS   5.15.0-142-generic   containerd://1.7.27
   mi-082f73826a163626e   Ready    <none>   23h   v1.32.3-eks-473151a   10.80.146.32    <none>        Ubuntu 22.04.4 LTS   5.15.0-142-generic   containerd://1.7.27
   mi-09183e8a3d755abf6   Ready    <none>   23h   v1.32.3-eks-473151a   10.80.146.33    <none>        Ubuntu 22.04.4 LTS   5.15.0-142-generic   containerd://1.7.27
   mi-0d78d815980ed202d   Ready    <none>   23h   v1.32.3-eks-473151a   10.80.146.97    <none>        Ubuntu 22.04.4 LTS   5.15.0-142-generic   containerd://1.7.27
   mi-0daa253999fe92daa   Ready    <none>   23h   v1.32.3-eks-473151a   10.80.146.100   <none>        Ubuntu 22.04.4 LTS   5.15.0-142-generic   containerd://1.7.27
   ```

1. Acceda al servicio mediante las direcciones IP de sus nodos y el puerto de oyente del recurso `cilium-gateway-my-gateway`. En el siguiente ejemplo, la dirección IP del nodo utilizada es `10.80.146.32`, mientras que el puerto de oyente es `8111`. Sustitúyalos por los valores correspondientes al entorno.

   ```
   curl -s http://10.80.146.32:8111/details/1 | jq
   ```

   ```
   {
     "id": 1,
     "author": "William Shakespeare",
     "year": 1595,
     "type": "paperback",
     "pages": 200,
     "publisher": "PublisherA",
     "language": "English",
     "ISBN-10": "1234567890",
     "ISBN-13": "123-1234567890"
   }
   ```

#### Ingress
<a name="_ingress"></a>

Debido a un problema de Cilium con el proceso ascendente ([\$134028](https://github.com/cilium/cilium/issues/34028)), Cilium Ingress en modo de red host requiere el uso de `loadbalancerMode: shared`, que crea un solo servicio del tipo ClusterIP para todos los recursos de entrada en el clúster. Si utiliza un puerto privilegiado (inferior a 1023) para el recurso de entrada, consulte la [documentación de Cilium](https://docs.cilium.io/en/stable/network/servicemesh/ingress/#bind-to-privileged-port) para obtener instrucciones.

1. Cree un archivo llamado `cilium-ingress-host-network.yaml` con el siguiente contenido.

   ```
   ingressController:
     enabled: true
     loadbalancerMode: shared
     # This is a workaround for the upstream Cilium issue
     service:
       externalTrafficPolicy: null
       type: ClusterIP
     hostNetwork:
       enabled: true
       # ensure the port does not conflict with other services on the node
       sharedListenerPort: 8111
       # uncomment to restrict nodes where Envoy proxies run on the host network
       # nodes:
       #   matchLabels:
       #     role: ingress
   ```

1. Aplique la configuración de Cilium Ingress de red host al clúster.

   ```
   helm upgrade cilium oci://public.ecr.aws/eks/cilium/cilium \
     --namespace kube-system \
     --reuse-values \
     --set operator.rollOutPods=true \
     -f cilium-ingress-host-network.yaml
   ```

   Si no ha creado el recurso de entrada, puede aplicar la siguiente definición de entrada al clúster para crearlo. La siguiente definición de entrada utiliza la aplicación de ejemplo Istio BookInfo descrita en [Implementación de Cilium Ingress](#hybrid-nodes-ingress-cilium-ingress-deploy).

   ```
   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: my-ingress
     namespace: default
   spec:
     ingressClassName: cilium
     rules:
     - http:
         paths:
         - backend:
             service:
               name: details
               port:
                 number: 9080
           path: /details
           pathType: Prefix
   ```

   Puede observar la configuración de Envoy de Cilium aplicada con el siguiente comando.

   ```
   kubectl get cec -n kube-system cilium-ingress -o yaml
   ```

   Puede obtener el puerto de oyente de Envoy para el servicio `cilium-ingress` con el siguiente comando. En este ejemplo, el puerto de oyente compartido es `8111`.

   ```
   kubectl get cec -n kube-system cilium-ingress -o jsonpath={.spec.services[0].ports[0]}
   ```

1. Obtenga las direcciones IP de los nodos en el clúster.

   ```
   kubectl get nodes -o wide
   ```

   ```
   NAME                   STATUS   ROLES    AGE   VERSION               INTERNAL-IP     EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION       CONTAINER-RUNTIME
   mi-026d6a261e355fba7   Ready    <none>   23h   v1.32.3-eks-473151a   10.80.146.150   <none>        Ubuntu 22.04.5 LTS   5.15.0-142-generic   containerd://1.7.27
   mi-082f73826a163626e   Ready    <none>   23h   v1.32.3-eks-473151a   10.80.146.32    <none>        Ubuntu 22.04.4 LTS   5.15.0-142-generic   containerd://1.7.27
   mi-09183e8a3d755abf6   Ready    <none>   23h   v1.32.3-eks-473151a   10.80.146.33    <none>        Ubuntu 22.04.4 LTS   5.15.0-142-generic   containerd://1.7.27
   mi-0d78d815980ed202d   Ready    <none>   23h   v1.32.3-eks-473151a   10.80.146.97    <none>        Ubuntu 22.04.4 LTS   5.15.0-142-generic   containerd://1.7.27
   mi-0daa253999fe92daa   Ready    <none>   23h   v1.32.3-eks-473151a   10.80.146.100   <none>        Ubuntu 22.04.4 LTS   5.15.0-142-generic   containerd://1.7.27
   ```

1. Acceda al servicio mediante las direcciones IP de sus nodos y el `sharedListenerPort` del recurso `cilium-ingress`. En el siguiente ejemplo, la dirección IP del nodo utilizada es `10.80.146.32`, mientras que el puerto de oyente es `8111`. Sustitúyalos por los valores correspondientes al entorno.

   ```
   curl -s http://10.80.146.32:8111/details/1 | jq
   ```

   ```
   {
     "id": 1,
     "author": "William Shakespeare",
     "year": 1595,
     "type": "paperback",
     "pages": 200,
     "publisher": "PublisherA",
     "language": "English",
     "ISBN-10": "1234567890",
     "ISBN-13": "123-1234567890"
   }
   ```

# Configuración de servicios del tipo LoadBalancer para nodos híbridos
<a name="hybrid-nodes-load-balancing"></a>

En este tema se describe cómo configurar el equilibrio de carga de capa 4 (L4) para las aplicaciones que se ejecutan en Nodos híbridos de Amazon EKS. Los servicios de Kubernetes del tipo LoadBalancer se utilizan para exponer las aplicaciones de Kubernetes externas al clúster. Los servicios del tipo LoadBalancer se suelen utilizar con la infraestructura del equilibrador de carga físico en la nube o en un entorno en las instalaciones para atender el tráfico de la carga de trabajo. Esta infraestructura de equilibrador de carga suele aprovisionarse con un controlador específico del entorno.

 AWS es compatible con Equilibradores de carga de red de AWS y Cilium para servicios del tipo LoadBalancer que se ejecutan en Nodos híbridos de EKS. La decisión de utilizar NLB o Cilium se basa en el origen del tráfico de aplicaciones. Si el tráfico de aplicaciones se origina en una región de AWS, AWS recomienda utilizar el NLB de AWS y el Controlador del equilibrador de carga de AWS. Si el tráfico de aplicaciones se origina en un entorno local en las instalaciones o en la periferia, AWS recomienda utilizar las funciones de equilibrio de carga integradas de Cilium, que se pueden utilizar con o sin una infraestructura de equilibradores de carga en su entorno.

Para obtener información sobre el equilibrio de carga de tráfico de aplicaciones de capa 7 (L7), consulte [Configuración de Kubernetes Ingress para nodos híbridos](hybrid-nodes-ingress.md). Para obtener información general sobre el equilibrio de carga con EKS, consulte las [prácticas recomendadas para el equilibrio de carga](https://docs.aws.amazon.com/eks/latest/best-practices/load-balancing.html).

## Equilibrador de carga de red de AWS
<a name="hybrid-nodes-service-lb-nlb"></a>

Puede usar el [Controlador del equilibrador de carga de AWS](aws-load-balancer-controller.md) y el NLB con el tipo de destino `ip` para cargas de trabajo que se ejecutan en nodos híbridos. Cuando se utiliza el tipo de destino `ip`, el NLB reenvía el tráfico directamente a los pods, sin pasar por la ruta de red de la capa de servicio. Para que el NLB llegue a los destinos de IP de pods en nodos híbridos, los CIDR de pods en las instalaciones deben ser enrutables en la red en las instalaciones. Además, el Controlador del equilibrador de carga de AWS utiliza webhooks y requiere una comunicación directa desde el plano de control de EKS. Para obtener más información, consulte [Configuración de webhooks para nodos híbridos](hybrid-nodes-webhooks.md).
+ Consulte [Dirija el tráfico de TCP y UDP con equilibradores de carga de red](network-load-balancing.md) para ver los requisitos de configuración de la subred, así como [Instalación del Controlador del equilibrador de carga de AWS con Helm](lbc-helm.md) y [Best Practices for Load Balancing](https://docs.aws.amazon.com/eks/latest/best-practices/load-balancing.html) para obtener información adicional sobre el Equilibrador de carga de red de AWS y el Controlador del equilibrador de carga de AWS.
+ Consulte [AWS Load Balancer Controller NLB configurations](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/nlb/) para obtener configuraciones que se pueden aplicar a servicios del tipo `LoadBalancer` con el Equilibrador de carga de red de AWS.

### Requisitos previos
<a name="_prerequisites"></a>
+ Se instaló Cilium según las instrucciones de [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md).
+ Cilium BGP Control Plane está activado según las instrucciones de [Configuración del BGP de Cilium para nodos híbridos](hybrid-nodes-cilium-bgp.md). Si no desea usar el BGP, debe usar un método alternativo para que los CIDR de pods en las instalaciones sean enrutables dentro de la red en las instalaciones. Consulte [CIDR de pod remoto enrutable](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-pod-cidrs) para obtener más información.
+ Si tiene Helm instalado en su entorno de línea de comandos, consulte las [instrucciones de configuración de Helm](helm.md).
+ Si tiene eksctl instalado en su entorno de línea de comandos, consulte las [instrucciones de configuración de eksctl](install-kubectl.md#eksctl-install-update).

### Procedimiento
<a name="_procedure"></a>

1. Descargue una política de IAM para el Controlador del equilibrador de carga de AWS que le permita realizar llamadas a las API de AWS en su nombre.

   ```
   curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/refs/heads/main/docs/install/iam_policy.json
   ```

1. Cree una política de IAM con la política descargada en el paso anterior.

   ```
   aws iam create-policy \
       --policy-name AWSLoadBalancerControllerIAMPolicy \
       --policy-document file://iam_policy.json
   ```

1. Sustituya los valores del nombre del clúster (`CLUSTER_NAME`), la región de AWS (`AWS_REGION`) y el ID de la cuenta de AWS (`AWS_ACCOUNT_ID`) por su configuración y ejecute el siguiente comando.

   ```
   eksctl create iamserviceaccount \
       --cluster=CLUSTER_NAME \
       --namespace=kube-system \
       --name=aws-load-balancer-controller \
       --attach-policy-arn=arn:aws:iam::AWS_ACCOUNT_ID:policy/AWSLoadBalancerControllerIAMPolicy \
       --override-existing-serviceaccounts \
       --region AWS_REGION \
       --approve
   ```

1. Agregue el repositorio de gráficos de Helm eks-charts. AWS mantiene este repositorio en GitHub.

   ```
   helm repo add eks https://aws.github.io/eks-charts
   ```

1. Actualice el repositorio de Helm local para asegurarse de que cuenta con los gráficos más recientes.

   ```
   helm repo update eks
   ```

1. Instale el Controlador del equilibrador de carga de AWS. Sustituya los valores del nombre del clúster (`CLUSTER_NAME`), la región de AWS (`AWS_REGION`), el ID de VPC (`VPC_ID`) y la versión del gráfico de Helm del Controlador del equilibrador de carga de AWS (`AWS_LBC_HELM_VERSION`) por su configuración. Para encontrar la versión más reciente del gráfico de Helm, ejecute `helm search repo eks/aws-load-balancer-controller --versions`. Si ejecuta un clúster en modo mixto con nodos híbridos y nodos en la nube de AWS, puede ejecutar el Controlador del equilibrador de carga de AWS en los nodos en la nube según las instrucciones de [Controlador del equilibrador de carga de AWS](hybrid-nodes-webhooks.md#hybrid-nodes-mixed-lbc).

   ```
   helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
     -n kube-system \
     --version AWS_LBC_HELM_VERSION \
     --set clusterName=CLUSTER_NAME \
     --set region=AWS_REGION \
     --set vpcId=VPC_ID \
     --set serviceAccount.create=false \
     --set serviceAccount.name=aws-load-balancer-controller
   ```

1. Compruebe que el Controlador del equilibrador de carga de AWS se haya instalado correctamente.

   ```
   kubectl get -n kube-system deployment aws-load-balancer-controller
   ```

   ```
   NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
   aws-load-balancer-controller   2/2     2            2           84s
   ```

1. Defina una aplicación de ejemplo en un archivo denominado `tcp-sample-app.yaml`. El siguiente ejemplo usa una implementación simple de NGINX con un puerto TCP.

   ```
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: tcp-sample-app
     namespace: default
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         labels:
           app: nginx
       spec:
         containers:
           - name: nginx
             image: public.ecr.aws/nginx/nginx:1.23
             ports:
               - name: tcp
                 containerPort: 80
   ```

1. Aplique la implementación al clúster.

   ```
   kubectl apply -f tcp-sample-app.yaml
   ```

1. Defina un servicio del tipo LoadBalancer para la implementación en un archivo llamado `tcp-sample-service.yaml`.

   ```
   apiVersion: v1
   kind: Service
   metadata:
     name: tcp-sample-service
     namespace: default
     annotations:
       service.beta.kubernetes.io/aws-load-balancer-type: external
       service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
       service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
   spec:
     ports:
       - port: 80
         targetPort: 80
         protocol: TCP
     type: LoadBalancer
     selector:
       app: nginx
   ```

1. Aplique la configuración del servicio al clúster.

   ```
   kubectl apply -f tcp-sample-service.yaml
   ```

1. El aprovisionamiento del NLB para el servicio puede tardar unos minutos. Una vez aprovisionado el NLB, el servicio tendrá asignada una dirección que se corresponderá con el nombre de DNS de la implementación del NLB.

   ```
   kubectl get svc tcp-sample-service
   ```

   ```
   NAME                 TYPE           CLUSTER-IP       EXTERNAL-IP                                                                    PORT(S)        AGE
   tcp-sample-service   LoadBalancer   172.16.115.212   k8s-default-tcpsampl-xxxxxxxxxx-xxxxxxxxxxxxxxxx.elb.<region>.amazonaws.com   80:30396/TCP   8s
   ```

1. Acceda al servicio con la dirección del NLB.

   ```
   curl k8s-default-tcpsampl-xxxxxxxxxx-xxxxxxxxxxxxxxxx.elb.<region>.amazonaws.com
   ```

   A continuación se muestra un ejemplo de salida.

   ```
   <!DOCTYPE html>
   <html>
   <head>
   <title>Welcome to nginx!</title>
   [...]
   ```

1. Limpie los recursos de que ha creado.

   ```
   kubectl delete -f tcp-sample-service.yaml
   kubectl delete -f tcp-sample-app.yaml
   ```

## Equilibrio de carga en el clúster de Cilium
<a name="hybrid-nodes-service-lb-cilium"></a>

Cilium se puede utilizar como un equilibrador de cargas integrado en el clúster para las cargas de trabajo que se ejecutan en Nodos híbridos de EKS, lo que puede resultar útil para entornos que no tienen una infraestructura de equilibrador de carga. Las capacidades de equilibrio de carga de Cilium constan de una combinación de características de Cilium, que incluyen la sustitución de kube-proxy, Load Balancer IP Address Management (IPAM) y BGP Control Plane. Las responsabilidades de estas características se detallan a continuación:
+  **Sustitución del kube-proxy de Cilium**: gestiona el enrutamiento del tráfico del servicio a los pods de backend.
+  **Cilium Load Balancer IPAM**: administra las direcciones IP que se pueden asignar a servicios del tipo `LoadBalancer`.
+  **Cilium BGP Control Plane**: anuncia direcciones IP asignadas por Load Balancer IPAM a la red en las instalaciones.

Si no utiliza la sustitución de kube-proxy de Cilium, puede seguir utilizando Cilium Load Balancer IPAM y BGP Control Plane para asociar y asignar direcciones IP para los servicios del tipo LoadBalancer. Si no utilizas la sustitución de kube-proxy de Cilium, el equilibrio de carga para los servicios y los pods de backend se gestiona mediante reglas de kube-proxy e iptables de forma predeterminada en EKS.

### Requisitos previos
<a name="_prerequisites_2"></a>
+ Cilium se instala según las instrucciones de [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md) con o sin la sustitución de kube-proxy activada. La sustitución de kube-proxy de Cilium requiere ejecutar un sistema operativo con un kernel de Linux al menos tan reciente como las versiones 4.19.57, 5.1.16 o 5.2.0. Todas las versiones recientes de los sistemas operativos compatibles para su uso con nodos híbridos cumplen estos requisitos, con la excepción de Red Hat Enterprise Linux (RHEL) 8.x.
+ Cilium BGP Control Plane está activado según las instrucciones de [Configuración del BGP de Cilium para nodos híbridos](hybrid-nodes-cilium-bgp.md). Si no desea usar el BGP, debe usar un método alternativo para que los CIDR de pods en las instalaciones sean enrutables dentro de la red en las instalaciones. Consulte [CIDR de pod remoto enrutable](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-pod-cidrs) para obtener más información.
+ Si tiene Helm instalado en su entorno de línea de comandos, consulte las [instrucciones de configuración de Helm](helm.md).

### Procedimiento
<a name="_procedure_2"></a>

1. Cree un archivo llamado `cilium-lbip-pool-loadbalancer.yaml` con un recurso `CiliumLoadBalancerIPPool` para configurar el rango de direcciones IP del equilibrador de carga para los servicios del tipo LoadBalancer.
   + Reemplace `LB_IP_CIDR` por el rango de direcciones IP para utilizar las direcciones IP del equilibrador de carga. Para seleccionar una sola dirección IP, use un CIDR `/32`. Para obtener más información, consulte [LoadBalancer IP Address Management](https://docs.cilium.io/en/stable/network/lb-ipam/) en la documentación de Cilium.
   + El campo `serviceSelector` está configurado para que coincida con el nombre del servicio que creará en un paso posterior. Con esta configuración, las IP de este grupo solo se asignarán a los servicios con el nombre `tcp-sample-service`.

     ```
     apiVersion: cilium.io/v2alpha1
     kind: CiliumLoadBalancerIPPool
     metadata:
       name: tcp-service-pool
     spec:
       blocks:
       - cidr: "LB_IP_CIDR"
       serviceSelector:
         matchLabels:
           io.kubernetes.service.name: tcp-sample-service
     ```

1. Aplique el recurso `CiliumLoadBalancerIPPool` al clúster.

   ```
   kubectl apply -f cilium-lbip-pool-loadbalancer.yaml
   ```

1. Confirme que haya al menos una dirección IP disponible en el grupo.

   ```
   kubectl get ciliumloadbalancerippools.cilium.io
   ```

   ```
   NAME               DISABLED   CONFLICTING   IPS AVAILABLE   AGE
   tcp-service-pool   false      False         1               24m
   ```

1. Cree un archivo llamado `cilium-bgp-advertisement-loadbalancer.yaml` con un recurso `CiliumBGPAdvertisement` para anunciar la dirección IP del equilibrador de carga para el servicio que creará en el siguiente paso. Si no utiliza el BGP de Cilium, puede saltarse este paso. La dirección IP del equilibrador de carga utilizada para el servicio debe poder enrutarse en la red en las instalaciones para que pueda consultar el servicio en el paso final.
   + El campo `advertisementType` está configurado como `Service` y `service.addresses` está configurado como `LoadBalancerIP` para anunciar solo `LoadBalancerIP` para los servicios del tipo `LoadBalancer`.
   + El campo `selector` está configurado para que coincida con el nombre del servicio que creará en un paso posterior. Con esta configuración, solo se anunciará `LoadBalancerIP` para servicios con el nombre `tcp-sample-service`.

     ```
     apiVersion: cilium.io/v2alpha1
     kind: CiliumBGPAdvertisement
     metadata:
       name: bgp-advertisement-tcp-service
       labels:
         advertise: bgp
     spec:
       advertisements:
         - advertisementType: "Service"
           service:
             addresses:
               - LoadBalancerIP
           selector:
             matchLabels:
               io.kubernetes.service.name: tcp-sample-service
     ```

1. Aplique el recurso `CiliumBGPAdvertisement` al clúster. Si no utiliza el BGP de Cilium, puede saltarse este paso.

   ```
   kubectl apply -f cilium-bgp-advertisement-loadbalancer.yaml
   ```

1. Defina una aplicación de ejemplo en un archivo denominado `tcp-sample-app.yaml`. El siguiente ejemplo usa una implementación simple de NGINX con un puerto TCP.

   ```
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: tcp-sample-app
     namespace: default
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         labels:
           app: nginx
       spec:
         containers:
           - name: nginx
             image: public.ecr.aws/nginx/nginx:1.23
             ports:
               - name: tcp
                 containerPort: 80
   ```

1. Aplique la implementación al clúster.

   ```
   kubectl apply -f tcp-sample-app.yaml
   ```

1. Defina un servicio del tipo LoadBalancer para la implementación en un archivo llamado `tcp-sample-service.yaml`.
   + Puede solicitar una dirección IP específica del grupo de IP del equilibrador de carga con la anotación `lbipam.cilium.io/ips` en el objeto del servicio. Puede eliminar esta anotación si no desea solicitar una dirección IP específica para el servicio.
   + El campo de especificaciones `loadBalancerClass` es obligatorio para evitar que el proveedor de nube de AWS heredado cree un Equilibrador de carga clásico para el servicio. En el siguiente ejemplo, está configurado como `io.cilium/bgp-control-plane` para usar BGP Control Plane de Cilium como clase del equilibrador de carga. Como alternativa, este campo se puede configurar como `io.cilium/l2-announcer` para utilizar la [característica L2 Announcements](https://docs.cilium.io/en/latest/network/l2-announcements/) de Cilium (actualmente en versión beta y no compatible oficialmente con AWS).

     ```
     apiVersion: v1
     kind: Service
     metadata:
       name: tcp-sample-service
       namespace: default
       annotations:
         lbipam.cilium.io/ips: "LB_IP_ADDRESS"
     spec:
       loadBalancerClass: io.cilium/bgp-control-plane
       ports:
         - port: 80
           targetPort: 80
           protocol: TCP
       type: LoadBalancer
       selector:
         app: nginx
     ```

1. Aplique el servicio al clúster. El servicio se creará con una dirección IP externa que podrá utilizar para acceder a la aplicación.

   ```
   kubectl apply -f tcp-sample-service.yaml
   ```

1. Compruebe que el servicio se haya creado correctamente y que tenga asignada una IP diferente al `CiliumLoadBalancerIPPool` creado en el paso anterior.

   ```
   kubectl get svc tcp-sample-service
   ```

   ```
   NAME                 TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)        AGE
   tcp-sample-service   LoadBalancer   172.16.117.76   LB_IP_ADDRESS   80:31129/TCP   14m
   ```

1. Si utiliza Cilium en el modo de sustitución de kube-proxy, puede confirmar que Cilium se encarga del equilibrio de carga del servicio mediante la ejecución del siguiente comando. En el siguiente resultado, las direcciones `10.86.2.x` son las direcciones IP de los pods de backend del servicio.

   ```
   kubectl -n kube-system exec ds/cilium -- cilium-dbg service list
   ```

   ```
   ID   Frontend               Service Type   Backend
   ...
   41   LB_IP_ADDRESS:80/TCP   LoadBalancer   1 => 10.86.2.76:80/TCP (active)
                                              2 => 10.86.2.130:80/TCP (active)
                                              3 => 10.86.2.141:80/TCP (active)
   ```

1. Confirme que Cilium anuncie la dirección IP en la red en las instalaciones mediante BGP. En el siguiente ejemplo, hay cinco nodos híbridos, cada uno de los cuales anuncia `LB_IP_ADDRESS` del servicio `tcp-sample-service` en la red en las instalaciones.

   ```
   Node                   VRouter      Prefix             NextHop   Age     Attrs
   mi-026d6a261e355fba7   NODES_ASN
                     LB_IP_ADDRESS/32   0.0.0.0   12m3s   [{Origin: i} {Nexthop: 0.0.0.0}]
   mi-082f73826a163626e   NODES_ASN
                     LB_IP_ADDRESS/32   0.0.0.0   12m3s   [{Origin: i} {Nexthop: 0.0.0.0}]
   mi-09183e8a3d755abf6   NODES_ASN
                     LB_IP_ADDRESS/32   0.0.0.0   12m3s   [{Origin: i} {Nexthop: 0.0.0.0}]
   mi-0d78d815980ed202d   NODES_ASN
                     LB_IP_ADDRESS/32   0.0.0.0   12m3s   [{Origin: i} {Nexthop: 0.0.0.0}]
   mi-0daa253999fe92daa   NODES_ASN
                     LB_IP_ADDRESS/32   0.0.0.0   12m3s   [{Origin: i} {Nexthop: 0.0.0.0}]
   ```

1. Acceda al servicio con la dirección IP del equilibrador de carga asignada.

   ```
   curl LB_IP_ADDRESS
   ```

   A continuación se muestra un ejemplo de salida.

   ```
   <!DOCTYPE html>
   <html>
   <head>
   <title>Welcome to nginx!</title>
   [...]
   ```

1. Limpie los recursos de que ha creado.

   ```
   kubectl delete -f tcp-sample-service.yaml
   kubectl delete -f tcp-sample-app.yaml
   kubectl delete -f cilium-lb-ip-pool.yaml
   kubectl delete -f cilium-bgp-advertisement.yaml
   ```

# Configuración de políticas de red de Kubernetes para nodos híbridos
<a name="hybrid-nodes-network-policies"></a>

 AWS admite las políticas de red de Kubernetes (capa 3 o 4) para el tráfico de entrada y salida de los pods cuando se utiliza Cilium como CNI con Nodos híbridos EKS. Si ejecuta clústeres de EKS con nodos en la nube de AWS, AWS es compatible con las [políticas de red de la CNI de Amazon VPC para Kubernetes](cni-network-policy.md).

En este tema se explica cómo configurar las políticas de red de Cilium y Kubernetes con Nodos híbridos de EKS. Para obtener información detallada sobre las políticas de red de Kubernetes, consulte [Kubernetes Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) en la documentación de Kubernetes.

## Configurar políticas de red
<a name="hybrid-nodes-configure-network-policies"></a>

### Consideraciones
<a name="_considerations"></a>
+  AWS es compatible con las políticas de red ascendentes de Kubernetes y la especificación para la entrada y salida de pods. AWS actualmente no es compatible con `CiliumNetworkPolicy` ni `CiliumClusterwideNetworkPolicy`.
+ El valor de Helm `policyEnforcementMode` se puede utilizar para controlar el comportamiento de aplicación predeterminado de las políticas de Cilium. El comportamiento predeterminado permite todo el tráfico de entrada y salida. Cuando una política de red selecciona un punto de conexión, pasa a un estado de denegación predeterminado, en el que solo se permite el tráfico explícitamente permitido. Consulte la documentación de Cilium para obtener más información sobre el [modo de políticas predeterminados](https://docs.cilium.io/en/stable/security/policy/intro/#policy-mode-default) y los [modos de aplicación de políticas](https://docs.cilium.io/en/stable/security/policy/intro/#policy-enforcement-modes).
+ Si cambia `policyEnforcementMode` para una instalación de Cilium existente, debe reiniciar el DaemonSet del agente de Cilium para aplicar el nuevo modo de aplicación de políticas.
+ Utilice `namespaceSelector` y `podSelector` para permitir o denegar el tráfico hacia o desde los espacios de nombres y los pods con etiquetas coincidentes. `namespaceSelector` y `podSelector` se pueden usar con `matchLabels` o `matchExpressions` para seleccionar espacios de nombres y pods en función de sus etiquetas.
+ Utilice `ingress.ports` y `egress.ports` para permitir o denegar el tráfico hacia o desde puertos y protocolos.
+ El campo `ipBlock` no se puede utilizar para permitir o denegar de forma selectiva el tráfico hacia o desde las direcciones IP de los pods ([\$19209](https://github.com/cilium/cilium/issues/9209)). El uso de selectores `ipBlock` para las IP de los nodos es una característica en versión beta de Cilium y no es compatible con AWS.
+ Consulte [NetworkPolicy resource](https://kubernetes.io/docs/concepts/services-networking/network-policies/#networkpolicy-resource) en la documentación de Kubernetes para obtener información sobre los campos disponibles para las políticas de red de Kubernetes.

### Requisitos previos
<a name="_prerequisites"></a>
+ Se instaló Cilium según las instrucciones de [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md).
+ Si tiene Helm instalado en su entorno de línea de comandos, consulte las [instrucciones de configuración de Helm](helm.md).

### Procedimiento
<a name="_procedure"></a>

El siguiente procedimiento configura las políticas de red para una aplicación de microservicios de ejemplo, de modo que los componentes solo pueden comunicarse con otros componentes necesarios para que la aplicación funcione. El procedimiento utiliza la aplicación de microservicios de ejemplo [Istio BookInfo](https://istio.io/latest/docs/examples/bookinfo/).

La aplicación BookInfo consta de cuatro microservicios independientes con las siguientes relaciones:
+  **productpage**. El microservicio productpage llama a los microservicios details y reviews para rellenar la página.
+  **details**. El microservicio details contiene información sobre libros.
+  **reviews**. El microservicio reviews contiene reseñas de libros. También llama al microservicio ratings.
+  **ratings**. El microservicio ratings contiene información de clasificación de libros que acompaña a la reseña de un libro.

  1. Cree la aplicación de ejemplo.

     ```
     kubectl apply -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/bookinfo/platform/kube/bookinfo.yaml
     ```

  1. Confirme que la aplicación se esté ejecutando correctamente y anote la dirección IP del pod del microservicio productpage. Utilizará la dirección IP de este pod para consultar cada microservicio en los pasos siguientes.

     ```
     kubectl get pods -o wide
     ```

     ```
     NAME                              READY   STATUS    RESTARTS   AGE   IP            NODE
     details-v1-766844796b-9wff2       1/1     Running   0          7s    10.86.3.7     mi-0daa253999fe92daa
     productpage-v1-54bb874995-lwfgg   1/1     Running   0          7s    10.86.2.193   mi-082f73826a163626e
     ratings-v1-5dc79b6bcd-59njm       1/1     Running   0          7s    10.86.2.232   mi-082f73826a163626e
     reviews-v1-598b896c9d-p2289       1/1     Running   0          7s    10.86.2.47    mi-026d6a261e355fba7
     reviews-v2-556d6457d-djktc        1/1     Running   0          7s    10.86.3.58    mi-0daa253999fe92daa
     reviews-v3-564544b4d6-g8hh4       1/1     Running   0          7s    10.86.2.69    mi-09183e8a3d755abf6
     ```

  1. Cree un pod que se utilizará en todo momento para probar las políticas de red. Tenga en cuenta que el pod se crea en el espacio de nombres `default` con la etiqueta `access: true`.

     ```
     kubectl run curl-pod --image=curlimages/curl -i --tty --labels=access=true --namespace=default --overrides='{"spec": { "nodeSelector": {"eks.amazonaws.com/compute-type": "hybrid"}}}' -- /bin/sh
     ```

  1. Pruebe el acceso al microservicio productpage. En el siguiente ejemplo, utilizamos la dirección IP del pod productpage (`10.86.2.193`) para consultar el microservicio. Sustitúyala por la dirección IP del pod productpage de su entorno.

     ```
     curl -s http://10.86.2.193:9080/productpage | grep -o "<title>.*</title>"
     ```

     ```
     <title>Simple Bookstore App</title>
     ```

  1. Para salir del pod curl de prueba, puede escribir `exit`. Para volver a conectarse al pod, ejecute el siguiente comando.

     ```
     kubectl attach curl-pod -c curl-pod -i -t
     ```

  1. Para demostrar los efectos de las políticas de red en los siguientes pasos, primero creamos una política de red que deniegue todo el tráfico de los microservicios de BookInfo. Cree un archivo llamado `network-policy-deny-bookinfo.yaml` que defina la política de red de denegación.

     ```
     apiVersion: networking.k8s.io/v1
     kind: NetworkPolicy
     metadata:
       name: deny-bookinfo
       namespace: default
     spec:
       podSelector:
         matchExpressions:
         - key: app
           operator: In
           values: ["productpage", "details", "reviews", "ratings"]
       policyTypes:
       - Ingress
       - Egress
     ```

  1. Aplique la política de red de denegación al clúster.

     ```
     kubectl apply -f network-policy-default-deny-bookinfo.yaml
     ```

  1. Pruebe el acceso a la aplicación BookInfo. En el siguiente ejemplo, utilizamos la dirección IP del pod productpage (`10.86.2.193`) para consultar el microservicio. Sustitúyala por la dirección IP del pod productpage de su entorno.

     ```
     curl http://10.86.2.193:9080/productpage --max-time 10
     ```

     ```
     curl: (28) Connection timed out after 10001 milliseconds
     ```

  1. Cree un archivo llamado `network-policy-productpage.yaml` que defina la política de red de productpage. La política tiene las siguientes reglas:
     + Permite la entrada de tráfico desde los pods con la etiqueta `access: true` (el pod curl creado en el paso anterior).
     + Permite el tráfico TCP de salida en el puerto `9080` para los microservicios details, reviews y ratings.
     + Permite el tráfico TCP/UDP de salida en el puerto `53` para CoreDNS que se ejecuta en el espacio de nombres `kube-system`.

       ```
       apiVersion: networking.k8s.io/v1
       kind: NetworkPolicy
       metadata:
         name: productpage-policy
         namespace: default
       spec:
         podSelector:
           matchLabels:
             app: productpage
         policyTypes:
         - Ingress
         - Egress
         ingress:
         - from:
           - podSelector:
               matchLabels:
                 access: "true"
         egress:
         - to:
           - podSelector:
               matchExpressions:
               - key: app
                 operator: In
                 values: ["details", "reviews", "ratings"]
           ports:
           - port: 9080
             protocol: TCP
         - to:
           - namespaceSelector:
               matchLabels:
                 kubernetes.io/metadata.name: kube-system
             podSelector:
               matchLabels:
                 k8s-app: kube-dns
           ports:
           - port: 53
             protocol: UDP
           - port: 53
             protocol: TCP
       ```

  1. Aplique la política de red de productpage a su clúster.

     ```
     kubectl apply -f network-policy-productpage.yaml
     ```

  1. Conéctese al pod curl y pruebe el acceso a la aplicación BookInfo. Ahora se permite el acceso al microservicio productpage, pero se sigue denegando el acceso a los demás microservicios porque siguen sujetos a la política de red de denegación. En los siguientes ejemplos, utilizamos la dirección IP del pod productpage (`10.86.2.193`) para consultar el microservicio. Sustitúyala por la dirección IP del pod productpage de su entorno.

     ```
     kubectl attach curl-pod -c curl-pod -i -t
     ```

     ```
     curl -s http://10.86.2.193:9080/productpage | grep -o "<title>.*</title>"
     <title>Simple Bookstore App</title>
     ```

     ```
     curl -s http://10.86.2.193:9080/api/v1/products/1
     {"error": "Sorry, product details are currently unavailable for this book."}
     ```

     ```
     curl -s http://10.86.2.193:9080/api/v1/products/1/reviews
     {"error": "Sorry, product reviews are currently unavailable for this book."}
     ```

     ```
     curl -s http://10.86.2.193:9080/api/v1/products/1/ratings
     {"error": "Sorry, product ratings are currently unavailable for this book."}
     ```

  1. Cree un archivo llamado `network-policy-details.yaml` que defina la política de red de details. La política solo permite la entrada de tráfico desde el microservicio productpage.

     ```
     apiVersion: networking.k8s.io/v1
     kind: NetworkPolicy
     metadata:
       name: details-policy
       namespace: default
     spec:
       podSelector:
         matchLabels:
           app: details
       policyTypes:
       - Ingress
       ingress:
       - from:
         - podSelector:
             matchLabels:
               app: productpage
     ```

  1. Cree un archivo llamado `network-policy-reviews.yaml` que defina la política de red de reviews. La política solo permite el tráfico de entrada desde el microservicio productpage y solo el tráfico de salida hacia el microservicio ratings y CoreDNS.

     ```
     apiVersion: networking.k8s.io/v1
     kind: NetworkPolicy
     metadata:
       name: reviews-policy
       namespace: default
     spec:
       podSelector:
         matchLabels:
           app: reviews
       policyTypes:
       - Ingress
       - Egress
       ingress:
       - from:
         - podSelector:
             matchLabels:
               app: productpage
       egress:
       - to:
         - podSelector:
             matchLabels:
               app: ratings
       - to:
         - namespaceSelector:
             matchLabels:
               kubernetes.io/metadata.name: kube-system
           podSelector:
             matchLabels:
               k8s-app: kube-dns
         ports:
         - port: 53
           protocol: UDP
         - port: 53
           protocol: TCP
     ```

  1. Cree un archivo llamado `network-policy-ratings.yaml` que defina la política de red de ratings. La política solo permite la entrada de tráfico desde los microservicios productpage y reviews.

     ```
     apiVersion: networking.k8s.io/v1
     kind: NetworkPolicy
     metadata:
       name: ratings-policy
       namespace: default
     spec:
       podSelector:
         matchLabels:
           app: ratings
       policyTypes:
       - Ingress
       ingress:
       - from:
         - podSelector:
             matchExpressions:
             - key: app
               operator: In
               values: ["productpage", "reviews"]
     ```

  1. Aplique al clúster las políticas de red de details, reviews y ratings.

     ```
     kubectl apply -f network-policy-details.yaml
     kubectl apply -f network-policy-reviews.yaml
     kubectl apply -f network-policy-ratings.yaml
     ```

  1. Conéctese al pod curl y pruebe el acceso a la aplicación BookInfo. En los siguientes ejemplos, utilizamos la dirección IP del pod productpage (`10.86.2.193`) para consultar el microservicio. Sustitúyala por la dirección IP del pod productpage de su entorno.

     ```
     kubectl attach curl-pod -c curl-pod -i -t
     ```

     Pruebe el microservicio details.

     ```
     curl -s http://10.86.2.193:9080/api/v1/products/1
     ```

     ```
     {"id": 1, "author": "William Shakespeare", "year": 1595, "type": "paperback", "pages": 200, "publisher": "PublisherA", "language": "English", "ISBN-10": "1234567890", "ISBN-13": "123-1234567890"}
     ```

     Pruebe el microservicio reviews.

     ```
     curl -s http://10.86.2.193:9080/api/v1/products/1/reviews
     ```

     ```
     {"id": "1", "podname": "reviews-v1-598b896c9d-p2289", "clustername": "null", "reviews": [{"reviewer": "Reviewer1", "text": "An extremely entertaining play by Shakespeare. The slapstick humour is refreshing!"}, {"reviewer": "Reviewer2", "text": "Absolutely fun and entertaining. The play lacks thematic depth when compared to other plays by Shakespeare."}]}
     ```

     Pruebe el microservicio ratings.

     ```
     curl -s http://10.86.2.193:9080/api/v1/products/1/ratings
     ```

     ```
     {"id": 1, "ratings": {"Reviewer1": 5, "Reviewer2": 4}}
     ```

  1. Limpie los recursos que ha creado en este procedimiento.

     ```
     kubectl delete -f network-policy-deny-bookinfo.yaml
     kubectl delete -f network-policy-productpage.yaml
     kubectl delete -f network-policy-details.yaml
     kubectl delete -f network-policy-reviews.yaml
     kubectl delete -f network-policy-ratings.yaml
     kubectl delete -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/bookinfo/platform/kube/bookinfo.yaml
     kubectl delete pod curl-pod
     ```

# Conceptos de nodos híbridos
<a name="hybrid-nodes-concepts"></a>

Con los *nodos híbridos de Amazon EKS*, puede unir máquinas físicas o virtuales que se ejecutan en entornos en las instalaciones o periféricos a clústeres de Amazon EKS que se ejecutan en la nube de AWS. Este enfoque aporta muchas ventajas, pero también introduce nuevos conceptos y arquitecturas de red para quienes estén familiarizados con la ejecución de clústeres de Kubernetes en un único entorno de red.

En las siguientes secciones, se profundiza en los conceptos de Kubernetes y redes para los nodos híbridos de EKS y se detalla cómo fluye el tráfico a través de la arquitectura híbrida. Para comprender estas secciones, es necesario que tenga los conocimientos básicos de redes de Kubernetes, como los conceptos de pods, nodos, servicios, plano de control de Kubernetes, kubelet y kube-proxy.

Recomendamos leer estas páginas en orden, empezando por [Conceptos relacionados con las redes para nodos híbridos](hybrid-nodes-concepts-networking.md), luego por [Conceptos de Kubernetes para nodos híbridos](hybrid-nodes-concepts-kubernetes.md) y, por último, por [Flujos de tráfico de red para nodos híbridos](hybrid-nodes-concepts-traffic-flows.md).

**Topics**
+ [Conceptos relacionados con las redes para nodos híbridos](hybrid-nodes-concepts-networking.md)
+ [Conceptos de Kubernetes para nodos híbridos](hybrid-nodes-concepts-kubernetes.md)
+ [Flujos de tráfico de red para nodos híbridos](hybrid-nodes-concepts-traffic-flows.md)

# Conceptos relacionados con las redes para nodos híbridos
<a name="hybrid-nodes-concepts-networking"></a>

En esta sección, se detallan los conceptos básicos sobre redes y las restricciones que debe tener en cuenta al diseñar la topología de red para los nodos híbridos de EKS.

## Conceptos relacionados con las redes para los nodos híbridos de EKS
<a name="_networking_concepts_for_eks_hybrid_nodes"></a>

![\[Diagrama de red de nodos híbridos de alto nivel\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/hybrid-nodes-highlevel-network.png)


 **VPC como hub de red** 

Todo el tráfico que cruza los límites de la nube pasa por su VPC. Esto incluye el tráfico entre el plano de control de EKS o los pods que se ejecutan en AWS hasta los nodos híbridos o los pods que se ejecutan en ellos. Puede pensar en la VPC de su clúster como el hub de red entre los nodos híbridos y el resto del clúster. Esta arquitectura le proporciona un control total del tráfico y su enrutamiento, pero también le confiere la responsabilidad de configurar correctamente las rutas, los grupos de seguridad y los firewalls para la VPC.

 **Del plano de control de EKS a la VPC** 

El plano de control de EKS conecta las **interfaces de red elástica (ENI)** a su VPC. Estas ENI gestionan el tráfico hacia y desde el servidor de la API de EKS. Usted controla la ubicación de las ENI del plano de control de EKS al configurar el clúster, ya que EKS conecta las ENI a las subredes por las que pasa durante la creación del clúster.

EKS asocia los grupos de seguridad a las ENI que EKS conecta a las subredes. Estos grupos de seguridad permiten el tráfico hacia y desde el plano de control de EKS. Esto es importante para los nodos híbridos de EKS porque debe permitir el tráfico de los nodos híbridos y los pods que se ejecutan en ellos hacia las ENI del plano de control de EKS.

 **Redes de nodos remotos** 

Las redes de nodos remotos, específicamente los CIDR de nodos remotos, son los rangos de IP asignados a las máquinas que se utilizan como nodos híbridos. Cuando aprovisiona nodos híbridos, residen en su centro de datos en las instalaciones o ubicación periférica, que es un dominio de red diferente al del plano de control de EKS y la VPC. Cada nodo híbrido tiene una o varias direcciones IP de un CIDR de nodo remoto que es distinta de las subredes de la VPC.

Usted configura el clúster de EKS con estos CIDR de nodos remotos para que EKS sepa enrutar todo el tráfico destinado a las IP de los nodos híbridos a través de la VPC de su clúster, como las solicitudes a la API de kubelet. Las conexiones a la API `kubelet` se utilizan en los comandos `kubectl attach`, `kubectl cp`, `kubectl exec`, `kubectl logs` y `kubectl port-forward`.

 **Redes de pods remotos** 

Las redes de pods remotos son los rangos de IP asignados a los pods que se ejecutan en los nodos híbridos. Por lo general, se configura la CNI con estos rangos, y la funcionalidad del administrador de direcciones IP (IPAM) de la CNI se encarga de asignar un segmento de estos rangos a cada nodo híbrido. Al crear un pod, la CNI asigna una IP al pod desde el segmento asignado al nodo en el que se programó el pod.

El clúster de EKS se configura con estos CIDR de pod remotos para que el plano de control de EKS sepa cómo enrutar todo el tráfico destinado a los pods que se ejecutan en los nodos híbridos a través de la VPC del clúster, por ejemplo, la comunicación con webhooks.

![\[Redes de pods remotos\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/hybrid-nodes-remote-pod-cidrs.png)


 **Desde las instalaciones a la VPC** 

La red en las instalaciones que utilice para los nodos híbridos debe enrutarse a la VPC que utilice para el clúster de EKS. Existen varias [opciones de conectividad desde la red a la VPC de Amazon](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html) disponibles para conectar la red en las instalaciones a una VPC. También puede utilizar su propia solución de VPN.

Es importante que configure el enrutamiento correctamente en el lado de la nube de AWS, en la VPC y en la red en las instalaciones, de modo que ambas redes enruten el tráfico correcto a través de la conexión de las dos redes.

En la VPC, todo el tráfico que va a las redes del nodo remoto y del pod remoto debe enrutarse a través de la conexión a la red en las instalaciones (denominada “puerta de enlace”). Si algunas de sus subredes tienen tablas de enrutamiento diferentes, debe configurar cada una de ellas con las rutas de los nodos híbridos y los pods que se ejecutan en ellos. Esto es válido para las subredes a las que están conectadas las ENI del plano de control de EKS y para las subredes que contienen nodos o pods de EC2 que deben comunicarse con los nodos híbridos.

En la red en las instalaciones, debe configurar la red para permitir el tráfico hacia y desde la VPC del clúster de EKS y los demás servicios de AWS necesarios para los nodos híbridos. El tráfico del clúster de EKS atraviesa la puerta de enlace en ambas direcciones.

## Limitaciones de las redes
<a name="_networking_constraints"></a>

 **Red totalmente enrutada** 

La principal limitación es que el plano de control de EKS y todos los nodos, ya sean nodos en la nube o híbridos, deben formar una red **totalmente enrutada**. Esto significa que todos los nodos deben poder comunicarse entre sí en la capa tres, mediante la dirección IP.

El plano de control de EKS y los nodos de la nube ya son accesibles entre sí porque se encuentran en una red plana (la VPC). Sin embargo, los nodos híbridos se encuentran en un dominio de red diferente. Por este motivo, debe configurar un enrutamiento adicional en la VPC y en la red en las instalaciones para enrutar el tráfico entre los nodos híbridos y el resto del clúster. Si se puede acceder a los nodos híbridos entre sí y desde la VPC, los nodos híbridos pueden estar en una sola red plana o en varias redes segmentadas.

 **CIDR de pod remoto enrutable** 

Para que el plano de control de EKS se comunique con los pods que se ejecutan en nodos híbridos (por ejemplo, webhooks o el servidor de métricas) o para que los pods que se ejecutan en nodos de la nube se comuniquen con los pods que se ejecutan en nodos híbridos (comunicación entre la carga de trabajo de este a oeste), el CIDR del pod remoto debe poder enrutarse desde la VPC. Esto significa que la VPC debe poder enrutar el tráfico de los CIDR del pod a través de la puerta de enlace a la red en las instalaciones y que la red local debe poder enrutar el tráfico de un pod al nodo correcto.

Es importante tener en cuenta la distinción entre los requisitos de enrutamiento de los pods en la VPC y en las instalaciones. La VPC solo necesita saber que todo el tráfico que vaya a un pod remoto debe pasar por la puerta de enlace. Si solo tiene un CIDR de pod remoto, solo necesita una ruta.

Este requisito se aplica a todos los saltos de la red en las instalaciones hasta el enrutador local en la misma subred que los nodos híbridos. Este es el único enrutador que debe conocer el segmento CIDR del pod asignado a cada nodo para asegurarse de que el tráfico de un pod en particular llegue al nodo en el que se programó el pod.

Si bien no es necesario, puede optar por propagar estas rutas para los CIDR de los pods en las instalaciones desde su enrutador en las instalaciones hasta las tablas de enrutamiento de la VPC. Aunque no es común que suceda, si los CIDR de los pods en las instalaciones cambian con frecuencia y las tablas de enrutamiento de la VPC deben actualizarse para reflejar los cambios en los CIDR de los pods, le recomendamos que propague los CIDR de los pods en las instalaciones a las tablas de enrutamiento de la VPC.

Tenga en cuenta que la restricción para hacer que los CIDR de los pods en las instalaciones sean enrutables es opcional. Si no necesita ejecutar webhooks en los nodos híbridos ni hacer que los pods de los nodos en la nube se comuniquen con los pods de los nodos híbridos, no es necesario configurar el enrutamiento de los CIDR de los pods de la red en las instalaciones.

 *¿Por qué los CIDR de los pods en las instalaciones deben poder enrutarse con nodos híbridos?* 

Al usar EKS con la CNI de la VPC para los nodos en la nube, la CNI de la VPC asigna las IP directamente de la VPC a los pods. Esto significa que no es necesario ningún enrutamiento especial, ya que tanto los pods en la nube como el plano de control de EKS pueden acceder directamente a las IP de los pods.

Cuando se ejecuta en las instalaciones (y con otros CNI en la nube), los pods se suelen ejecutar dentro de una red superpuesta aislada, y el CNI se encarga de suministrar el tráfico entre pods. Por lo general, esto se hace mediante encapsulación: la CNI convierte el tráfico de pod a pod en tráfico de nodo a nodo y se encarga de encapsular y desencapsular ambos extremos. De esta manera, no se requiere configuración adicional en los nodos ni en los enrutadores.

La red con nodos híbridos es única porque presenta una combinación de ambas topologías: el plano de control de EKS y los nodos en la nube (con la CNI de la VPC) esperan una red plana que incluya nodos y pods, mientras que los pods que se ejecutan en nodos híbridos están en una red superpuesta mediante VXLAN para la encapsulación (de forma predeterminada en Cilium). Los pods que se ejecutan en nodos híbridos pueden llegar al plano de control de EKS y a los pods que se ejecutan en nodos en la nube, siempre que la red en las instalaciones pueda enrutarse a la VPC. Sin embargo, sin el enrutamiento de los CIDR de los pods en la red en las instalaciones, cualquier tráfico que regrese a la IP de un pod en las instalaciones se eliminará eventualmente si la red no sabe cómo llegar a la red superpuesta y enrutarse a los nodos correctos.

# Conceptos de Kubernetes para nodos híbridos
<a name="hybrid-nodes-concepts-kubernetes"></a>

En esta página, se detallan los conceptos clave de Kubernetes que sustentan la arquitectura del sistema de nodos híbridos de EKS.

## Plano de control de EKS en la VPC
<a name="hybrid-nodes-concepts-k8s-api"></a>

Las IP de las ENI del plano de control de EKS se almacenan en el objeto `kubernetes` `Endpoints` del espacio de nombres `default`. Cuando EKS crea nuevas ENI o elimina las antiguas, EKS actualiza este objeto para que la lista de IP esté siempre actualizada.

Puede utilizar estos puntos de conexión a través del servicio de `kubernetes`, también en el espacio de nombres `default`. A este servicio, del tipo `ClusterIP`, siempre se le asigna la primera IP del CIDR del servicio del clúster. Por ejemplo, para el servicio de CIDR `172.16.0.0/16`, la IP del servicio será `172.16.0.1`.

Por lo general, así es como los pods (independientemente de si se ejecutan en la nube o en nodos híbridos) acceden al servidor de la API de Kubernetes de EKS. Los pods utilizan la IP del servicio como IP de destino, que se traduce en las IP reales de una de las ENI del plano de control de EKS. La excepción principal es `kube-proxy`, porque configura la traducción.

## Punto de conexión del servidor de la API de EKS
<a name="hybrid-nodes-concepts-k8s-eks-api"></a>

La IP del servicio de `kubernetes` no es la única forma de acceder al servidor de la API de EKS. EKS también crea un nombre de DNS Route53 cuando crea el clúster. Este es el campo `endpoint` de su clúster de EKS al llamar a la acción de la API `DescribeCluster` de EKS.

```
{
    "cluster": {
        "endpoint": "https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com",
        "name": "my-cluster",
        "status": "ACTIVE"
    }
}
```

En un clúster de acceso a puntos de conexión públicos o públicos y privados, sus nodos híbridos convertirán este nombre de DNS en una IP pública de forma predeterminada, enrutable a través de Internet. En un clúster de acceso a puntos de conexión privados, el nombre de DNS se convierte en las IP privadas de las ENI del plano de control de EKS.

Así es como `kubelet` y `kube-proxy` acceden al servidor de la API de Kubernetes. Si desea que todo el tráfico del clúster de Kubernetes fluya a través de la VPC, debe configurar el clúster en modo de acceso privado o modificar el servidor de DNS en las instalaciones para resolver el punto de conexión del clúster de EKS en las IP privadas de las ENI del plano de control de EKS.

## Punto de conexión de `kubelet`
<a name="hybrid-nodes-concepts-k8s-kubelet-api"></a>

El `kubelet` expone varios puntos de conexión REST, lo que permite que otras partes del sistema interactúen con cada nodo y recopilen información de él. En la mayoría de los clústeres, la mayor parte del tráfico al servidor `kubelet` proviene del plano de control, pero algunos agentes de supervisión también pueden interactuar con él.

A través de esta interfaz, el `kubelet` gestiona varias solicitudes: buscar registros (`kubectl logs`), ejecutar comandos dentro de contenedores (`kubectl exec`) y reenviar el tráfico de puertos (`kubectl port-forward`). Cada una de estas solicitudes interactúa con el tiempo de ejecución del contenedor subyacente durante todo el `kubelet`, lo que resulta perfecto para los administradores y desarrolladores del clúster.

El consumidor más habitual de esta API es el servidor de la API de Kubernetes. Cuando utiliza alguno de los comandos de `kubectl` mencionados anteriormente, `kubectl` realiza una solicitud de API al servidor de la API, que luego llama a la API de `kubelet` del nodo en el que se está ejecutando el pod. Esta es la razón principal por la que es necesario poder acceder a la IP del nodo desde el plano de control de EKS y por la que, aunque sus pods estén en ejecución, no podrá acceder a sus registros o `exec` si la ruta del nodo está mal configurada.

 **IP de los nodos** 

Cuando el plano de control EKS se comunica con un nodo, utiliza una de las direcciones indicadas en el estado del objeto `Node` (`status.addresses`).

En el caso de los nodos en la nube de EKS, es habitual que el kubelet registre la IP privada de la instancia EC2 como `InternalIP` durante el registro del nodo. A continuación, el administrador de controladores en la nube (CCM) valida esta IP para asegurarse de que pertenece a la instancia EC2. Además, el CCM suele añadir las IP públicas (como `ExternalIP`) y los nombres de DNS (`InternalDNS` y `ExternalDNS`) de la instancia al estado del nodo.

Sin embargo, no hay ningún CCM para los nodos híbridos. Al registrar un nodo híbrido con la CLI (`nodeadm`) de los nodos híbridos de EKS, se configura el kubelet para que indique la IP de la máquina directamente en el estado del nodo, sin el CCM.

```
apiVersion: v1
kind: Node
metadata:
  name: my-node-1
spec:
  providerID: eks-hybrid:///us-west-2/my-cluster/my-node-1
status:
  addresses:
  - address: 10.1.1.236
    type: InternalIP
  - address: my-node-1
    type: Hostname
```

Si su máquina tiene varias IP, el kubelet seleccionará una de ellas siguiendo su propia lógica. Puede controlar la IP seleccionada con la advertencia `--node-ip`, que puede introducir en la configuración de `nodeadm` en `spec.kubelet.flags`. Solo la IP indicada en el objeto `Node` necesita una ruta desde la VPC. Sus máquinas pueden tener otras IP a las que no se pueda acceder desde la nube.

## `kube-proxy`
<a name="hybrid-nodes-concepts-k8s-kube-proxy"></a>

 `kube-proxy` es responsable de implementar la abstracción del servicio en la capa de red de cada nodo. Actúa como proxy de red y equilibrador de carga para el tráfico destinado a los servicios de Kubernetes. Al vigilar continuamente el servidor de la API de Kubernetes para detectar cambios relacionados con los servicios y los puntos de conexión, `kube-proxy` actualiza dinámicamente las reglas de red del host subyacente para garantizar que el tráfico se dirija correctamente.

En el modo `iptables`, `kube-proxy` programa varias cadenas `netfilter` para administrar el tráfico del servicio. Las reglas forman la siguiente jerarquía:

1.  **Cadena KUBE-SERVICES**: el punto de entrada de todo el tráfico del servicio. Tiene reglas que coinciden con cada `ClusterIP` y puerto del servicio.

1.  **Cadenas KUBE-SVC-XXX**: las cadenas específicas del servicio tienen reglas de equilibrio de carga para cada servicio.

1.  **Cadenas KUBE-SEP-XXX**: las cadenas específicas del punto de conexión tienen las reglas `DNAT` reales.

Analicemos qué ocurre con un `test-server` de servicio en el espacio de nombres `default`: \$1 ClusterIP del servicio: `172.16.31.14` \$1 Puerto del servicio: `80` \$1 Pods de respaldo: `10.2.0.110`, `10.2.1.39` y `10.2.2.254` 

Cuando inspeccionamos las reglas `iptables` (con `iptables-save –0— grep -A10 KUBE-SERVICES`):

1. En la cadena **KUBE-SERVICES**, encontramos una regla que coincide con el servicio:

   ```
   -A KUBE-SERVICES -d 172.16.31.14/32 -p tcp -m comment --comment "default/test-server cluster IP" -m tcp --dport 80 -j KUBE-SVC-XYZABC123456
   ```
   + Esta regla coincide con los paquetes destinados a 172.16.31.14:80
   + El comentario indica para qué sirve esta regla: `default/test-server cluster IP` 
   + Los paquetes coincidentes pasan a la cadena `KUBE-SVC-XYZABC123456`

1. La cadena **KUBE-SVC-XYZABC123456** tiene reglas de equilibrio de carga basadas en probabilidades:

   ```
   -A KUBE-SVC-XYZABC123456 -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-POD1XYZABC
   -A KUBE-SVC-XYZABC123456 -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-POD2XYZABC
   -A KUBE-SVC-XYZABC123456 -j KUBE-SEP-POD3XYZABC
   ```
   + Primera regla: 33,3 % de probabilidad de saltar a `KUBE-SEP-POD1XYZABC` 
   + Segunda regla: 50 % de probabilidades de que el tráfico restante (el 33,3 % del total) salte a `KUBE-SEP-POD2XYZABC` 
   + Última regla: todo el tráfico restante (el 33,3 % del total) salta a `KUBE-SEP-POD3XYZABC` 

1. Las cadenas **KUBE-SEP-XXX** individuales realizan la DNAT (NAT de destino):

   ```
   -A KUBE-SEP-POD1XYZABC -p tcp -m tcp -j DNAT --to-destination 10.2.0.110:80
   -A KUBE-SEP-POD2XYZABC -p tcp -m tcp -j DNAT --to-destination 10.2.1.39:80
   -A KUBE-SEP-POD3XYZABC -p tcp -m tcp -j DNAT --to-destination 10.2.2.254:80
   ```
   + Estas reglas de DNAT reescriben la IP y el puerto de destino para dirigir el tráfico a pods específicos.
   + Cada regla gestiona aproximadamente el 33,3 % del tráfico, lo que proporciona un equilibrio de carga uniforme entre `10.2.0.110`, `10.2.1.39` y `10.2.2.254`.

Esta estructura de cadena de varios niveles permite que `kube-proxy` implemente de manera eficiente el equilibrio y la redirección de la carga de servicios mediante la manipulación de paquetes a nivel del núcleo, sin necesidad de un proceso proxy en la ruta de datos.

### Impacto en las operaciones de Kubernetes
<a name="hybrid-nodes-concepts-k8s-operations"></a>

Si hay un `kube-proxy` roto en un nodo, impide que ese nodo enrute correctamente el tráfico del servicio, lo que provoca tiempos de espera o fallos en las conexiones de los pods que dependen de los servicios del clúster. Esto puede ser especialmente perjudicial cuando se registra un nodo por primera vez. La CNI necesita hablar con el servidor de la API de Kubernetes para obtener información, como el CIDR del pod del nodo, antes de poder configurar cualquier red de pods. Para ello, utiliza la IP del servicio de `kubernetes`. Sin embargo, si `kube-proxy` no se ha podido iniciar o no se han establecido las reglas `iptables` correctas, las solicitudes que se envían a la IP del servicio de `kubernetes` no se traducen a las IP reales de las ENI del plano de control de EKS. Como consecuencia, la CNI entrará en un círculo vicioso y ninguno de los pods podrá funcionar correctamente.

Sabemos que los pods utilizan la IP del servicio de `kubernetes` para comunicarse con el servidor de la API de Kubernetes, pero primero `kube-proxy` debe establecer reglas `iptables` para que funcione.

¿Cómo se comunica `kube-proxy` con el servidor de la API?

`kube-proxy` debe configurarse para usar las IP reales del servidor de la API de Kubernetes o un nombre de DNS que las resuelva. En el caso de EKS, este servicio configura el valor de `kube-proxy` predeterminado para que apunte al nombre DNS de Route53 que EKS genera al crear el clúster. Puede ver este valor en el ConfigMap del `kube-proxy`, en el espacio de nombres `kube-system`. El contenido de este ConfigMap es un `kubeconfig` que se inyecta en el pod de `kube-proxy`, así que debe buscar el campo `clusters–0—.cluster.server`. Este valor coincidirá con el campo `endpoint` de su clúster de EKS (al llamar a la API `DescribeCluster` de EKS).

```
apiVersion: v1
data:
  kubeconfig: |-
    kind: Config
    apiVersion: v1
    clusters:
    - cluster:
        certificate-authority: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        server: https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com
      name: default
    contexts:
    - context:
        cluster: default
        namespace: default
        user: default
      name: default
    current-context: default
    users:
    - name: default
      user:
        tokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
kind: ConfigMap
metadata:
  name: kube-proxy
  namespace: kube-system
```

## CIDR de pod remoto enrutable
<a name="hybrid-nodes-concepts-k8s-pod-cidrs"></a>

En la página [Conceptos relacionados con las redes para nodos híbridos](hybrid-nodes-concepts-networking.md), se detallan los requisitos para ejecutar webhooks en nodos híbridos o para que los pods que se ejecutan en nodos de la nube se comuniquen con los pods que se ejecutan en nodos híbridos. El requisito clave es que el enrutador en las instalaciones debe saber qué nodo es responsable de la IP de un pod concreto. Existen varias formas de lograrlo, como el protocolo de puerta de enlace fronteriza (BGP), las rutas estáticas y el uso de proxies con el protocolo de resolución de direcciones (ARP). Estos pasos se detallan en las siguientes secciones.

 **Protocolo de puerta de enlace fronteriza (BGP)** 

Si su CNI lo admite (por ejemplo, Cilium y Calico), puede utilizar el modo de BGP de su CNI para propagar las rutas a los CIDR de cada pod del nodo desde los nodos hasta el enrutador local. Al utilizar el modo de BGP de la CNI, esta actúa como un enrutador virtual, por lo que el enrutador local cree que el CIDR del pod pertenece a una subred diferente y que el nodo es la puerta de enlace a esa subred.

![\[Enrutamiento de BGP de los nodos híbridos\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/hybrid-nodes-bgp.png)


 **Rutas estáticas** 

De otro modo, puede configurar rutas estáticas en el enrutador local. Esta es la forma más sencilla de enrutar el CIDR del pod en las instalaciones a su VPC, pero también es la más propensa a errores y la más difícil de mantener. Debe asegurarse de que las rutas estén siempre actualizadas con los nodos existentes y sus CIDR de pod asignados. Si su número de nodos es pequeño y la infraestructura es estática, esta es una opción viable y elimina la necesidad de admitir BGP en su enrutador. Si elige esta opción, le recomendamos que configure su CNI con el segmento CIDR del pod que desee asignar a cada nodo, en lugar de dejar que su IPAM decida.

![\[Enrutamiento estático de los nodos híbridos\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/hybrid-nodes-static-routes.png)


 **Uso de proxy del protocolo de resolución de direcciones (ARP)** 

El uso de proxy de ARP es otro enfoque para hacer que las IP de los pods en las instalaciones sean enrutables, lo que resulta especialmente útil cuando los nodos híbridos se encuentran en la misma red de capa 2 que el enrutador local. Con el proxy de ARP habilitado, un nodo responde a las solicitudes de ARP de las IP de los pods que aloja, aunque esas IP pertenezcan a una subred diferente.

Cuando un dispositivo de la red local intenta acceder a la IP de un pod, primero envía una solicitud de ARP en la que pregunta “¿Quién tiene esta IP?”. El nodo híbrido que aloja ese pod responderá con su propia dirección MAC y dirá: “Puedo gestionar el tráfico de esa IP”. Esto crea una ruta directa entre los dispositivos de la red local y los pods sin necesidad de configurar el enrutador.

Para que esto funcione, su CNI debe ser compatible con la funcionalidad de ARP del proxy. Cilium cuenta con compatibilidad integrada para el ARP del proxy que se puede activar mediante la configuración. La consideración clave es que el CIDR del pod no debe superponerse con ninguna otra red de su entorno, ya que esto podría provocar conflictos de enrutamiento.

Este enfoque tiene varias ventajas: \$1 No es necesario configurar el enrutador con un BGP ni mantener rutas estáticas \$1 Funciona bien en entornos en los que no se tiene control de la configuración del enrutador.

![\[Uso de proxy de ARP en los nodos híbridos\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/hybrid-nodes-arp-proxy.png)


## Encapsulación de pod a pod
<a name="hybrid-nodes-concepts-k8s-pod-encapsulation"></a>

En los entornos en las instalaciones, las CNI suelen utilizar protocolos de encapsulación para crear redes superpuestas que puedan funcionar sobre la red física sin necesidad de volver a configurarla. En esta sección, se explica cómo funciona esta encapsulación. Tenga en cuenta que algunos de los detalles pueden variar en función de la CNI que utilice.

La encapsulación envuelve los paquetes de red del pod originales dentro de otro paquete de red que se puede enrutar a través de la red física subyacente. Esto permite que los pods se comuniquen entre nodos que ejecutan la misma CNI sin necesidad de que la red física sepa cómo enrutar esos CIDR de los pods.

El protocolo de encapsulación más común que se utiliza con Kubernetes es la LAN virtual extensible (VXLAN), aunque también hay otros (por ejemplo, `Geneve`) disponibles en función de la CNI.

### Encapsulación mediante VXLAN
<a name="_vxlan_encapsulation"></a>

VXLAN encapsula las tramas Ethernet de capa 2 dentro de los paquetes UDP. Cuando un pod envía tráfico a otro pod en un nodo diferente, la CNI realiza lo siguiente:

1. La CNI intercepta los paquetes del pod A.

1. La CNI envuelve el paquete original en un encabezado de VXLAN.

1. Este paquete envuelto se envía luego a través de la pila de red normal del nodo al nodo de destino.

1. La CNI del nodo de destino desenvuelve el paquete y lo entrega al pod B.

Esto es lo que ocurre con la estructura del paquete durante la encapsulación mediante VXLAN:

Paquete original de pod a pod:

```
+-----------------+---------------+-------------+-----------------+
| Ethernet Header | IP Header     | TCP/UDP     | Payload         |
| Src: Pod A MAC  | Src: Pod A IP | Src Port    |                 |
| Dst: Pod B MAC  | Dst: Pod B IP | Dst Port    |                 |
+-----------------+---------------+-------------+-----------------+
```

Después de la encapsulación mediante VXLAN:

```
+-----------------+-------------+--------------+------------+---------------------------+
| Outer Ethernet  | Outer IP    | Outer UDP    | VXLAN      | Original Pod-to-Pod       |
| Src: Node A MAC | Src: Node A | Src: Random  | VNI: xx    | Packet (unchanged         |
| Dst: Node B MAC | Dst: Node B | Dst: 4789    |            | from above)               |
+-----------------+-------------+--------------+------------+---------------------------+
```

El identificador de red de VXLAN (VNI) distingue entre diferentes redes superpuestas.

### Escenarios de comunicación por pod
<a name="_pod_communication_scenarios"></a>

 **Pods en el mismo nodo híbrido** 

Cuando los pods del mismo nodo híbrido se comunican, normalmente no es necesaria la encapsulación. La CNI configura rutas locales que dirigen el tráfico entre los pods a través de las interfaces virtuales internas del nodo:

```
Pod A -> veth0 -> node's bridge/routing table -> veth1 -> Pod B
```

El paquete nunca sale del nodo y no requiere encapsulación.

 **Pods en diferentes nodos híbridos** 

La comunicación entre los pods de diferentes nodos híbridos requiere encapsulación:

```
Pod A -> CNI -> [VXLAN encapsulation] -> Node A network -> router or gateway -> Node B network -> [VXLAN decapsulation] -> CNI -> Pod B
```

Esto permite que el tráfico del pod atraviese la infraestructura de red física sin necesidad de que la red física comprenda el enrutamiento de la IP del pod.

# Flujos de tráfico de red para nodos híbridos
<a name="hybrid-nodes-concepts-traffic-flows"></a>

En esta página, se detallan los flujos de tráfico de red para los nodos híbridos de EKS con diagramas que muestran las rutas de red de extremo a extremo para los diferentes tipos de tráfico.

Se tratan los siguientes flujos de tráfico:
+  [Del `kubelet` del nodo híbrido al plano de control de EKS](#hybrid-nodes-concepts-traffic-flows-kubelet-to-cp) 
+  [Del plano de control de EKS al nodo híbrido (servidor de `kubelet`)](#hybrid-nodes-concepts-traffic-flows-cp-to-kubelet) 
+  [Desde pods que se ejecutan en nodos híbridos hasta el plano de control de EKS](#hybrid-nodes-concepts-traffic-flows-pods-to-cp) 
+  [Del plano de control de EKS a los pods que se ejecutan en un nodo híbrido (webhooks)](#hybrid-nodes-concepts-traffic-flows-cp-to-pod) 
+  [De pod a pod que se ejecuta en nodos híbridos](#hybrid-nodes-concepts-traffic-flows-pod-to-pod) 
+  [De pods de nodos en la nube a pods de nodos híbridos (tráfico de este a oeste)](#hybrid-nodes-concepts-traffic-flows-east-west) 

## Del `kubelet` del nodo híbrido al plano de control de EKS
<a name="hybrid-nodes-concepts-traffic-flows-kubelet-to-cp"></a>

![\[Del kubelet del nodo híbrido al plano de control de EKS\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/hybrid-nodes-kubelet-to-cp-public.png)


### Solicitud
<a name="_request"></a>

 **1. `kubelet` Inicia la solicitud** 

Cuando el `kubelet` de un nodo híbrido necesita comunicarse con el plano de control de EKS (por ejemplo, para informar del estado del nodo u obtener las especificaciones del pod), utiliza el archivo `kubeconfig` proporcionado durante el registro del nodo. Este `kubeconfig` tiene la URL del punto de conexión del servidor de la API (el nombre DNS de Route53) en lugar de direcciones IP directas.

El `kubelet` realiza una consulta de DNS para el punto de conexión (por ejemplo, `https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com`). En un clúster con acceso público, esto se resuelve en una dirección IP pública (por ejemplo, `54.239.118.52`) que pertenece al servicio de EKS que se ejecuta en AWS. Luego, el `kubelet` crea una solicitud HTTPS segura para este punto de conexión. El paquete inicial tiene un aspecto similar al siguiente:

```
+--------------------+---------------------+-----------------+
| IP Header          | TCP Header          | Payload         |
| Src: 10.80.0.2     | Src: 52390 (random) |                 |
| Dst: 54.239.118.52 | Dst: 443            |                 |
+--------------------+---------------------+-----------------+
```

 **2. Enrutamiento del enrutador local** 

Como la IP de destino es una dirección IP pública y no forma parte de la red local, el `kubelet` envía este paquete a su puerta de enlace predeterminada (el enrutador en las instalaciones). El enrutador examina la IP de destino y determina que es una dirección IP pública.

En el caso del tráfico público, el enrutador normalmente reenvía el paquete a una puerta de enlace de Internet o a un enrutador fronterizo que gestiona el tráfico saliente a Internet. Esto se omite en el diagrama y dependerá de la configuración de la red en las instalaciones. El paquete atraviesa la infraestructura de red en las instalaciones y, finalmente, llega a la red de su proveedor de servicios de Internet.

 **3. Entrega al plano de control de EKS** 

El paquete atraviesa Internet y redes de tránsito públicas hasta llegar a la red de AWS, donde se dirige al punto de conexión del servicio de EKS en la región correspondiente. Cuando el paquete llega al servicio de EKS, se reenvía al plano de control de EKS real del clúster.

Este enrutamiento a través de la Internet pública es diferente de la ruta privada enrutada por la VPC que veremos en otros flujos de tráfico. La diferencia clave es que, cuando se utiliza el modo de acceso público, el tráfico desde el `kubelet` en las instalaciones (aunque no desde los pods) hasta el plano de control de EKS no pasa por la VPC, sino que utiliza la infraestructura global de Internet.

### Respuesta
<a name="_response"></a>

Una vez que el plano de control de EKS procesa la solicitud de `kubelet`, envía una respuesta:

 **3. El plano de control de EKS envía una respuesta** 

El plano de control de EKS genera un paquete de respuesta. Este paquete tiene como origen la IP pública y como destino la IP del nodo híbrido:

```
+--------------------+---------------------+-----------------+
| IP Header          | TCP Header          | Payload         |
| Src: 54.239.118.52 | Src: 443            |                 |
| Dst: 10.80.0.2     | Dst: 52390          |                 |
+--------------------+---------------------+-----------------+
```

 **2. Enrutamiento de Internet** 

El paquete de respuesta regresa a través de Internet, siguiendo la ruta de enrutamiento determinada por los proveedores de servicios de Internet, hasta llegar al enrutador periférico de la red en las instalaciones.

 **1. Entrega local** 

El enrutador en las instalaciones recibe el paquete y reconoce que la IP de destino (`10.80.0.2`) pertenece a la red local. Reenvía el paquete a través de la infraestructura de red local hasta que llega al nodo híbrido de destino, donde el `kubelet` recibe y procesa la respuesta.

## Del `kube-proxy` del nodo híbrido al plano de control de EKS
<a name="_hybrid_node_kube_proxy_to_eks_control_plane"></a>

Si habilita el acceso al punto de conexión público para el clúster, el tráfico de retorno utilizará Internet pública. Este tráfico se origina en el `kube-proxy` del nodo híbrido hacia el plano de control de EKS y sigue la misma ruta que el tráfico del `kubelet` hacia el plano de control de EKS.

## Del plano de control de EKS al nodo híbrido (servidor de `kubelet`)
<a name="hybrid-nodes-concepts-traffic-flows-cp-to-kubelet"></a>

![\[Del plano de control de EKS al nodo híbrido\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/hybrid-nodes-cp-to-kubelet.png)


### Solicitud
<a name="_request_2"></a>

 **1. El servidor de la API de Kubernetes de EKS inicia la solicitud** 

El servidor de la API de Kubernetes en EKS obtiene la dirección IP del nodo (`10.80.0.2`) a partir del estado del objeto del nodo. Luego dirige esta solicitud a través de la ENI en la VPC, ya que la IP de destino pertenece al CIDR de nodo remoto configurado (`10.80.0.0/16`). El paquete inicial tiene un aspecto similar al siguiente:

```
+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.0.0.132 | Src: 67493 (random) |                 |
| Dst: 10.80.0.2  | Dst: 10250          |                 |
+-----------------+---------------------+-----------------+
```

 **2. Procesamiento de redes de la VPC** 

El paquete sale de la ENI y entra en la capa de red de la VPC, donde se dirige a la puerta de enlace de la subred para su posterior enrutamiento.

 **3. Búsqueda en la tabla de enrutamiento de la VPC** 

La tabla de enrutamiento de la VPC para la subred que contiene la ENI del plano de control de EKS tiene una ruta específica (la segunda del diagrama) para el CIDR del nodo remoto. Según esta regla de enrutamiento, el paquete se dirige a la puerta de enlace de VPC a la red en las instalaciones.

 **4. Tránsito transfronterizo** 

La puerta de enlace transfiere el paquete a través de los límites de la nube mediante la conexión establecida (como Direct Connect o VPN) a la red en las instalaciones.

 **5. Recepción de la red en las instalaciones** 

El paquete llega al enrutador en las instalaciones que gestiona el tráfico de la subred en la que se encuentran los nodos híbridos.

 **6. Entrega final** 

El enrutador local identifica que la dirección IP de destino (`10.80.0.2`) pertenece a su red directamente conectada y reenvía el paquete directamente al nodo híbrido de destino, donde el `kubelet` lo recibe y procesa la solicitud.

### Respuesta
<a name="_response_2"></a>

Una vez que el `kubelet` del nodo híbrido procesa la solicitud, envía una respuesta siguiendo la misma ruta a la inversa:

```
+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.80.0.2  | Src: 10250          |                 |
| Dst: 10.0.0.132 | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+
```

 **6. `kubelet` Envía una respuesta** 

El `kubelet` en el nodo híbrido (`10.80.0.2`) crea un paquete de respuesta con la IP de origen original como destino. El destino no pertenece a la red local, por lo que se envía a la puerta de enlace predeterminada del host, que es el enrutador local.

 **5. Enrutamiento del enrutador local** 

El enrutador determina que la IP de destino (`10.0.0.132`) pertenece a `10.0.0.0/16`, que tiene una ruta que apunta a la puerta de enlace que conecta con AWS.

 **4. Retorno transfronterizo** 

El paquete regresa a través de la misma conexión en las instalaciones a la VPC (como Direct Connect o VPN) y cruza el límite de la nube en la dirección opuesta.

 **3. Enrutamiento de la VPC** 

Cuando el paquete llega a la VPC, las tablas de enrutamiento identifican que la IP de destino pertenece a un CIDR de la VPC. El paquete se enruta dentro de la VPC.

 **2. Entrega en la red de la VPC** 

La capa de red de la VPC reenvía el paquete a la subred con la ENI del plano de control de EKS (`10.0.0.132`).

 **1. Recepción de la ENI** 

El paquete llega a la ENI del plano de control de EKS conectado al servidor de la API de Kubernetes y completa el viaje de ida y vuelta.

## Desde pods que se ejecutan en nodos híbridos hasta el plano de control de EKS
<a name="hybrid-nodes-concepts-traffic-flows-pods-to-cp"></a>

![\[Desde pods que se ejecutan en nodos híbridos hasta el plano de control de EKS\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/hybrid-nodes-pod-to-cp.png)


### Sin NAT de la CNI
<a name="_without_cni_nat"></a>

### Solicitud
<a name="_request_3"></a>

Por lo general, los pods se comunican con el servidor de la API de Kubernetes a través del servicio de `kubernetes`. La IP del servicio es la primera IP del CIDR del servicio del clúster. Esta convención permite que los pods que deben ejecutarse antes de que CoreDNS esté disponible lleguen al servidor de la API, por ejemplo, la CNI. Las solicitudes salen del pod con la IP del servicio como destino. Por ejemplo, si el CIDR del servicio es `172.16.0.0/16`, la IP del servicio será `172.16.0.1`.

 **1. El pod inicia la solicitud** 

El pod envía una solicitud a la IP del servicio de `kubernetes` (`172.16.0.1`) en el puerto del servidor de la API (443) desde un puerto de origen aleatorio. El paquete tiene un aspecto similar al siguiente:

```
+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.85.1.56 | Src: 67493 (random) |                 |
| Dst: 172.16.0.1 | Dst: 443            |                 |
+-----------------+---------------------+-----------------+
```

 **2. Procesamiento de la CNI** 

La CNI detecta que la IP de destino no pertenece a ningún CIDR de pod que administre. Como la **NAT saliente está deshabilitada**, la CNI pasa el paquete a la pila de la red del host sin modificarlo.

 **3. Procesamiento de la red del nodo** 

El paquete entra en la pila de red del nodo, donde los enlaces `netfilter` activan las reglas `iptables` establecidas por kube-proxy. Se aplican varias reglas en el siguiente orden:

1. El paquete llega primero a la cadena `KUBE-SERVICES`, que contiene reglas que coinciden con el ClusterIP y el puerto de cada servicio.

1. La regla coincidente salta a la cadena `KUBE-SVC-XXX` del servicio de `kubernetes` (paquetes destinados a `172.16.0.1:443`), que contiene reglas de equilibrio de carga.

1. La regla de equilibrio de carga selecciona aleatoriamente una de las cadenas `KUBE-SEP-XXX` para las IP (`10.0.0.132` o `10.0.1.23`) de la ENI del plano de control.

1. La cadena `KUBE-SEP-XXX` seleccionada tiene la regla en sí que cambia la IP de destino de la IP de servicio a la IP seleccionada. Esto se conoce como traducción de direcciones de red de destino (DNAT).

Una vez aplicadas estas reglas, suponiendo que la IP de la ENI del plano de control de EKS seleccionada sea `10.0.0.132`, el paquete tendrá el siguiente aspecto:

```
+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.85.1.56 | Src: 67493 (random) |                 |
| Dst: 10.0.0.132 | Dst: 443            |                 |
+-----------------+---------------------+-----------------+
```

El nodo reenvía el paquete a su puerta de enlace predeterminada porque la IP de destino no está en la red local.

 **4. Enrutamiento del enrutador local** 

El enrutador local determina que la IP de destino (`10.0.0.132`) pertenece al CIDR de la VPC (`10.0.0.0/16`) y la reenvía a la puerta de enlace que conecta con AWS.

 **5. Tránsito transfronterizo** 

El paquete viaja mediante la conexión establecida (como Direct Connect o la VPN) a través del límite de la nube hasta la VPC.

 **6. Entrega en la red de la VPC** 

La capa de red de la VPC dirige el paquete a la subred correcta donde se encuentra la ENI (`10.0.0.132`) del plano de control de EKS.

 **7. Recepción de la ENI** 

El paquete llega a la ENI del plano de control de EKS conectado al servidor de la API de Kubernetes.

### Respuesta
<a name="_response_3"></a>

Una vez que el plano de control de EKS procesa la solicitud, envía una respuesta al pod:

 **7. El servidor de la API envía una respuesta** 

El servidor de la API de Kubernetes de EKS crea un paquete de respuesta con la IP de origen original como destino. El paquete tiene un aspecto similar al siguiente:

```
+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.0.0.132 | Src: 443            |                 |
| Dst: 10.85.1.56 | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+
```

Como la IP de destino pertenece al CIDR del pod remoto configurado (`10.85.0.0/16`), la envía a través de su ENI en la VPC con el enrutador de la subred como siguiente salto.

 **6. Enrutamiento de la VPC** 

La tabla de enrutamiento de la VPC contiene una entrada para el CIDR del pod remoto (`10.85.0.0/16`), que dirige este tráfico a la puerta de enlace de la VPC a la red en las instalaciones.

 **5. Tránsito transfronterizo** 

La puerta de enlace transfiere el paquete a través de los límites de la nube mediante la conexión establecida (como Direct Connect o VPN) a la red en las instalaciones.

 **4. Recepción de la red en las instalaciones** 

El paquete llega a su enrutador en las instalaciones.

 **3. Entrega al nodo** 

La tabla del enrutador tiene una entrada para `10.85.1.0/24` con `10.80.0.2` como siguiente salto, que entrega el paquete a nuestro nodo.

 **2. Procesamiento de la red del nodo** 

A medida que el paquete es procesado por la pila de red del nodo, `conntrack` (que forma parte de `netfilter`) encuentra una coincidencia con la conexión que el pod estableció inicialmente. Como se aplicó DNAT originalmente, `kubernetes` revierte el DNAT. Para ello, reescribe la IP de origen y reemplaza la IP de la ENI del plano de control de EKS por la IP del servicio de `conntrack`.

```
+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 172.16.0.1 | Src: 443            |                 |
| Dst: 10.85.1.56 | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+
```

 **1. Procesamiento de la CNI** 

La CNI identifica que la IP de destino pertenece a un pod de su red y entrega el paquete al espacio de nombres de la red del pod correcto.

Este flujo muestra por qué los CIDR de pods remotos deben poder enrutarse correctamente desde la VPC hasta el nodo específico que aloja cada pod; toda la ruta de retorno depende del enrutamiento correcto de las IP de los pods en las redes en las instalaciones y en la nube.

### Con NAT de la CNI
<a name="_with_cni_nat"></a>

Este flujo es muy similar al que *no tiene la NAT de la CNI*, pero con una diferencia clave: la CNI aplica la NAT de origen (SNAT) al paquete antes de enviarlo a la pila de red del nodo. Esto cambia la IP de origen del paquete por la IP del nodo, lo que permite que el paquete se enrute de vuelta al nodo sin requerir una configuración de enrutamiento adicional.

### Solicitud
<a name="_request_4"></a>

 **1. El pod inicia la solicitud** 

El pod envía una solicitud a la IP del servicio de `kubernetes` (`172.16.0.1`) del puerto del servidor de la API de Kubernetes de EKS (443) desde un puerto de origen aleatorio. El paquete tiene un aspecto similar al siguiente:

```
+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.85.1.56 | Src: 67493 (random) |                 |
| Dst: 172.16.0.1 | Dst: 443            |                 |
+-----------------+---------------------+-----------------+
```

 **2. Procesamiento de la CNI** 

La CNI detecta que la IP de destino no pertenece a ningún CIDR de pod que administre. Como la **NAT saliente está habilitada**, la CNI aplica la SNAT al paquete y cambia la IP de origen por la IP del nodo antes de pasarla a la pila de redes del nodo:

```
+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.80.0.2  | Src: 67493 (random) |                 |
| Dst: 172.16.0.1 | Dst: 443            |                 |
+-----------------+---------------------+-----------------+
```

Nota: La CNI y `iptables` se muestran en el ejemplo como bloques separados para mayor claridad, pero en la práctica, es posible que algunas CNI utilicen `iptables` para aplicar la NAT.

 **3. Procesamiento de la red del nodo** 

En este caso, las reglas `iptables` establecidas por `kube-proxy` se comportan igual que en el ejemplo anterior, equilibrando la carga del paquete con una de las ENI del plano de control de EKS. El paquete ahora tiene un aspecto similar al siguiente:

```
+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.80.0.2  | Src: 67493 (random) |                 |
| Dst: 10.0.0.132 | Dst: 443            |                 |
+-----------------+---------------------+-----------------+
```

El nodo reenvía el paquete a su puerta de enlace predeterminada porque la IP de destino no está en la red local.

 **4. Enrutamiento del enrutador local** 

El enrutador local determina que la IP de destino (`10.0.0.132`) pertenece al CIDR de la VPC (`10.0.0.0/16`) y la reenvía a la puerta de enlace que conecta con AWS.

 **5. Tránsito transfronterizo** 

El paquete viaja mediante la conexión establecida (como Direct Connect o la VPN) a través del límite de la nube hasta la VPC.

 **6. Entrega en la red de la VPC** 

La capa de red de la VPC dirige el paquete a la subred correcta donde se encuentra la ENI (`10.0.0.132`) del plano de control de EKS.

 **7. Recepción de la ENI** 

El paquete llega a la ENI del plano de control de EKS conectado al servidor de la API de Kubernetes.

### Respuesta
<a name="_response_4"></a>

Una vez que el plano de control de EKS procesa la solicitud, envía una respuesta al pod:

 **7. El servidor de la API envía una respuesta** 

El servidor de la API de Kubernetes de EKS crea un paquete de respuesta con la IP de origen original como destino. El paquete tiene un aspecto similar al siguiente:

```
+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.0.0.132 | Src: 443            |                 |
| Dst: 10.80.0.2  | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+
```

Como la IP de destino pertenece al CIDR de nodo remoto configurado (`10.80.0.0/16`), la envía por su ENI en la VPC y establece como siguiente salto el enrutador de la subred.

 **6. Enrutamiento de la VPC** 

La tabla de enrutamiento de la VPC contiene una entrada para el CIDR del nodo remoto (`10.80.0.0/16`), que dirige este tráfico a la puerta de enlace de la VPC a la red en las instalaciones.

 **5. Tránsito transfronterizo** 

La puerta de enlace transfiere el paquete a través de los límites de la nube mediante la conexión establecida (como Direct Connect o VPN) a la red en las instalaciones.

 **4. Recepción de la red en las instalaciones** 

El paquete llega a su enrutador en las instalaciones.

 **3. Entrega al nodo** 

El enrutador local identifica que la dirección IP (`10.80.0.2`) de destino pertenece a su red conectada directamente y reenvía el paquete directamente al nodo híbrido de destino.

 **2. Procesamiento de la red del nodo** 

A medida que la pila de red del nodo procesa el paquete, `conntrack` (una parte de `netfilter`) hace coincidir el paquete con la conexión que el pod estableció inicialmente y, dado que originalmente se utilizó la DNAT, invierte esta situación reescribiendo la IP de origen desde la IP de la ENI del plano de control de EKS a la IP del servicio de `kubernetes`:

```
+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 172.16.0.1 | Src: 443            |                 |
| Dst: 10.80.0.2  | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+
```

 **1. Procesamiento de la CNI** 

La CNI identifica que este paquete pertenece a una conexión en la que ha aplicado previamente la SNAT. Invierte la SNAT y vuelve a cambiar la IP de destino por la IP del pod:

```
+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 172.16.0.1 | Src: 443            |                 |
| Dst: 10.85.1.56 | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+
```

La CNI detecta que la IP de destino pertenece a un pod de su red y entrega el paquete al espacio de nombres de la red del pod correcto.

Este flujo muestra cómo la NAT de la CNI puede simplificar la configuración porque permite que los paquetes se enruten de vuelta al nodo sin requerir un enrutamiento adicional para los CIDR del pod.

## Del plano de control de EKS a los pods que se ejecutan en un nodo híbrido (webhooks)
<a name="hybrid-nodes-concepts-traffic-flows-cp-to-pod"></a>

![\[Del plano de control de EKS a los pods que se ejecutan en un nodo híbrido\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/hybrid-nodes-cp-to-pod.png)


Este patrón de tráfico se observa con mayor frecuencia en los webhooks, donde el plano de control de EKS debe iniciar directamente las conexiones a los servidores de webhooks que se ejecutan en pods en nodos híbridos. Algunos ejemplos son la validación y la mutación de los webhooks de admisión, a los que el servidor de la API invoca durante los procesos de validación o mutación de recursos.

### Solicitud
<a name="_request_5"></a>

 **1. El servidor de la API de Kubernetes de EKS inicia la solicitud** 

Cuando se configura un webhook en el clúster y se activa una operación de API relevante, el servidor de la API de Kubernetes de EKS necesita establecer una conexión directa con el pod del servidor del webhook. El servidor de la API busca primero la dirección IP del pod en el recurso de servicio o punto de conexión asociado al webhook.

Si el pod del webhook se ejecuta en un nodo híbrido con la IP `10.85.1.23`, el servidor de la API de Kubernetes de EKS crea una solicitud HTTPS al punto de conexión del webhook. El paquete inicial se envía a través de la ENI del plano de control de EKS de la VPC porque la IP de destino `10.85.1.23` pertenece al CIDR del pod remoto configurado (`10.85.0.0/16`). El paquete tiene un aspecto similar al siguiente:

```
+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.0.0.132 | Src: 41892 (random) |                 |
| Dst: 10.85.1.23 | Dst: 8443           |                 |
+-----------------+---------------------+-----------------+
```

 **2. Procesamiento de redes de la VPC** 

El paquete sale de la ENI del plano de control de EKS y entra en la capa de red de la VPC con el enrutador de la subred como siguiente salto.

 **3. Búsqueda en la tabla de enrutamiento de la VPC** 

La tabla de enrutamiento de la VPC para la subred que contiene la ENI del plano de control de EKS tiene una ruta específica para el CIDR del pod remoto (`10.85.0.0/16`). Esta regla de enrutamiento dirige el paquete a la puerta de enlace de la VPC a local (por ejemplo, una puerta de enlace privada virtual para conexiones de Direct Connect o la VPN):

```
Destination     Target
10.0.0.0/16     local
10.85.0.0/16    vgw-id (VPC-to-onprem gateway)
```

 **4. Tránsito transfronterizo** 

La puerta de enlace transfiere el paquete a través de los límites de la nube mediante la conexión establecida (como Direct Connect o VPN) a la red en las instalaciones. El paquete mantiene sus direcciones IP de origen y destino originales a medida que atraviesa esta conexión.

 **5. Recepción de la red en las instalaciones** 

El paquete llega a su enrutador en las instalaciones. El enrutador consulta su tabla de enrutamiento para determinar cómo llegar a la dirección 10.85.1.23. Para que esto funcione, la red en las instalaciones debe tener rutas para los CIDR del pod que dirijan el tráfico al nodo híbrido correspondiente.

En este caso, la tabla de enrutamiento del enrutador contiene una entrada que indica que se puede acceder a la subred `10.85.1.0/24` a través del nodo híbrido con la IP `10.80.0.2`:

```
Destination     Next Hop
10.85.1.0/24    10.80.0.2
```

 **6. Entrega al nodo** 

Según la entrada de la tabla de enrutamiento, el enrutador reenvía el paquete al nodo híbrido (`10.80.0.2`). Cuando el paquete llega al nodo, tiene el mismo aspecto que cuando lo envió el servidor de la API de Kubernetes de EKS, pero la IP de destino sigue siendo la IP del pod.

 **7. Procesamiento de la CNI** 

La pila de red del nodo recibe el paquete y, al ver que la IP de destino no es la propia IP del nodo, lo pasa a la CNI para su procesamiento. La CNI identifica que la IP de destino pertenece a un pod que se ejecuta localmente en este nodo y reenvía el paquete al pod correcto a través de las interfaces virtuales adecuadas:

```
Original packet -> node routing -> CNI -> Pod's network namespace
```

El servidor del webhook del pod recibe la solicitud y la procesa.

### Respuesta
<a name="_response_5"></a>

Una vez que el pod del webhook procesa la solicitud, envía una respuesta siguiendo la misma ruta a la inversa:

 **7. El pod envía una respuesta** 

El pod del webhook crea un paquete de respuesta con su propia IP como origen y el solicitante original (la ENI del plano de control de EKS) como destino:

```
+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.85.1.23 | Src: 8443           |                 |
| Dst: 10.0.0.132 | Dst: 41892          |                 |
+-----------------+---------------------+-----------------+
```

El CNI identifica que este paquete se dirige a una red externa (no a un pod local) y lo entrega a la pila de red del nodo con la IP de origen original intacta.

 **6. Procesamiento de la red del nodo** 

El nodo determina que la IP de destino (`10.0.0.132`) no está en la red local y reenvía el paquete a su puerta de enlace predeterminada (el enrutador local).

 **5. Enrutamiento del enrutador local** 

El enrutador local consulta su tabla de enrutamiento y determina que la IP de destino (`10.0.0.132`) pertenece al CIDR de la VPC (`10.0.0.0/16`). Reenvía el paquete a la puerta de enlace que se conecta a AWS.

 **4. Tránsito transfronterizo** 

El paquete regresa a través de la misma conexión en las instalaciones a la VPC y cruza el límite de la nube en la dirección opuesta.

 **3. Enrutamiento de la VPC** 

Cuando el paquete llega a la VPC, las tablas de enrutamiento identifican que la IP de destino pertenece a una subred de la VPC. El paquete se enruta en consecuencia dentro de la VPC.

 **2. y 1. Recepción de la ENI del plano de control de EKS** 

El paquete llega a la ENI conectada al servidor de la API de Kubernetes de EKS y completa el viaje de ida y vuelta. El servidor de la API recibe la respuesta del webhook y continúa procesando la solicitud de la API original en función de esta respuesta.

Este flujo de tráfico demuestra por qué los CIDR de los pods remotos deben configurarse y enrutarse correctamente:
+ La VPC debe tener rutas para los CIDR del pod remoto que apunten a la puerta de enlace en las instalaciones.
+ La red en las instalaciones debe tener rutas para los CIDR de los pods que dirijan el tráfico a los nodos específicos que alojan esos pods.
+ Sin esta configuración de enrutamiento, no se podría acceder a los webhooks y otros servicios similares que se ejecutan en pods en nodos híbridos desde el plano de control de EKS.

## De pod a pod que se ejecuta en nodos híbridos
<a name="hybrid-nodes-concepts-traffic-flows-pod-to-pod"></a>

![\[De pod a pod que se ejecuta en nodos híbridos\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/hybrid-nodes-pod-to-pod.png)


En esta sección, se explica cómo los pods que se ejecutan en diferentes nodos híbridos se comunican entre sí. En este ejemplo, se supone que su CNI utiliza VXLAN para la encapsulación, lo que es habitual en CNI como Cilium o Calico. El proceso general es similar al de otros protocolos de encapsulación, como Geneve o IP-en-IP.

### Solicitud
<a name="_request_6"></a>

 **1. El pod A inicia la comunicación** 

El pod A (`10.85.1.56`) del nodo 1 quiere enviar tráfico al pod B (`10.85.2.67`) del nodo 2. El paquete inicial tiene un aspecto similar al siguiente:

```
+------------------+-----------------+-------------+-----------------+
| Ethernet Header  | IP Header       | TCP/UDP     | Payload         |
| Src: Pod A MAC   | Src: 10.85.1.56 | Src: 43721  |                 |
| Dst: Gateway MAC | Dst: 10.85.2.67 | Dst: 8080   |                 |
+------------------+-----------------+-------------+-----------------+
```

 **2. La CNI intercepta y procesa el paquete** 

Cuando el paquete del pod A abandona el espacio de nombres de la red, la CNI lo intercepta. La CNI consulta su tabla de enrutamiento y determina: - La IP de destino (`10.85.2.67`) pertenece al CIDR del pod - Esta IP no está en el nodo local sino que pertenece al nodo 2 (`10.80.0.3`) - El paquete se debe encapsular con VXLAN.

La decisión de encapsular es fundamental porque la red física subyacente no sabe cómo enrutar los CIDR de los pods directamente, sino que solo sabe cómo enrutar el tráfico entre las IP de los nodos.

La CNI encapsula todo el paquete original dentro de una trama VXLAN. Esto crea efectivamente un “paquete dentro de un paquete” con nuevos encabezados:

```
+-----------------+----------------+--------------+------------+---------------------------+
| Outer Ethernet  | Outer IP       | Outer UDP    | VXLAN      | Original Pod-to-Pod       |
| Src: Node1 MAC  | Src: 10.80.0.2 | Src: Random  | VNI: 42    | Packet (unchanged         |
| Dst: Router MAC | Dst: 10.80.0.3 | Dst: 8472    |            | from above)               |
+-----------------+----------------+--------------+------------+---------------------------+
```

Puntos clave sobre esta encapsulación: - El paquete externo se dirige del nodo 1 (`10.80.0.2`) al nodo 2 (`10.80.0.3`) - El puerto UDP `8472`es el puerto VXLAN que Cilium utiliza de forma predeterminada - El identificador de red de VXLAN (VNI) identifica a qué red superpuesta pertenece este paquete - Todo el paquete original (con la IP del pod A como origen y la IP del pod B como destino) se conserva intacto en su interior

El paquete encapsulado entra ahora en la pila de red normal del nodo 1 y se procesa de la misma forma que cualquier otro paquete:

1.  **Procesamiento de red de nodos**: la pila de red del nodo 1 enruta el paquete en función de su destino (`10.80.0.3`)

1.  **Entrega a través de la red local**:
   + Si ambos nodos están en la misma red de capa 2, el paquete se envía directamente al nodo 2.
   + Si están en subredes diferentes, el paquete se reenvía primero al enrutador local.

1.  **Manejo del enrutador**: el enrutador reenvía el paquete en función de su tabla de enrutamiento y lo entrega al nodo 2.

 **3. Procesamiento del nodo receptor** 

Cuando el paquete encapsulado llega al nodo 2 (`10.80.0.3`):

1. La pila de red del nodo lo recibe y lo identifica como un paquete VXLAN (puerto UDP `4789`).

1. El paquete se pasa a la interfaz VXLAN de la CNI para su procesamiento.

 **4. Desencapsulación de VXLAN** 

La CNI del nodo 2 procesa el paquete VXLAN:

1. Elimina los encabezados externos (Ethernet, IP, UDP y VXLAN).

1. Extrae el paquete interno original.

1. El paquete ha vuelto a su forma original:

```
+------------------+-----------------+-------------+-----------------+
| Ethernet Header  | IP Header       | TCP/UDP     | Payload         |
| Src: Pod A MAC   | Src: 10.85.1.56 | Src: 43721  |                 |
| Dst: Gateway MAC | Dst: 10.85.2.67 | Dst: 8080   |                 |
+------------------+-----------------+-------------+-----------------+
```

La CNI del nodo 2 examina la IP de destino (`10.85.2.67`) y:

1. Identifica que esta IP pertenece a un pod local.

1. Enruta el paquete a través de las interfaces virtuales adecuadas.

1. Envía el paquete al espacio de nombres de red del Pod B.

### Respuesta
<a name="_response_6"></a>

Cuando el Pod B responde al Pod A, todo el proceso ocurre a la inversa:

1. El Pod B envía un paquete al Pod A (`10.85.1.56`)

1. La CNI del nodo 2 lo encapsula con VXLAN y establece el destino en el nodo 1 (`10.80.0.2`)

1. El paquete encapsulado se entrega al nodo 1.

1. La CNI del nodo 1 lo desencapsula y envía la respuesta original al pod A.

## De pods de nodos en la nube a pods de nodos híbridos (tráfico de este a oeste)
<a name="hybrid-nodes-concepts-traffic-flows-east-west"></a>

![\[De pods de nodos en la nube a pods de nodos híbridos\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/hybrid-nodes-east-west.png)


### Solicitud
<a name="_request_7"></a>

 **1. El pod A inicia la comunicación** 

El pod A (`10.0.0.56`) del nodo EC2 quiere enviar tráfico al pod B (`10.85.1.56`) del nodo híbrido. El paquete inicial tiene un aspecto similar al siguiente:

```
+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.0.0.56  | Src: 52390 (random) |                 |
| Dst: 10.85.1.56 | Dst: 8080           |                 |
+-----------------+---------------------+-----------------+
```

Con la CNI de la VPC, el pod A tiene una IP del CIDR de la VPC y se conecta directamente a una ENI de la instancia EC2. El espacio de nombres de la red del pod está conectado a la red de la VPC, por lo que el paquete entra directamente en la infraestructura de enrutamiento de la VPC.

 **2. Enrutamiento de la VPC** 

La tabla de enrutamiento de la VPC contiene una ruta específica para el CIDR del pod remoto (`10.85.0.0/16`), que dirige este tráfico a la puerta de enlace de VPC a local:

```
Destination     Target
10.0.0.0/16     local
10.85.0.0/16    vgw-id (VPC-to-onprem gateway)
```

Según esta regla de enrutamiento, el paquete se dirige hacia la puerta de enlace que se conecta a la red en las instalaciones.

 **3. Tránsito transfronterizo** 

La puerta de enlace transfiere el paquete a través de los límites de la nube mediante la conexión establecida (como Direct Connect o VPN) a la red en las instalaciones. El paquete mantiene sus direcciones IP de origen y destino originales durante todo este tránsito.

 **4. Recepción de la red en las instalaciones** 

El paquete llega a su enrutador en las instalaciones. El enrutador consulta su tabla de enrutamiento para determinar el siguiente salto para llegar a la dirección 10.85.1.56. El enrutador en las instalaciones debe tener rutas para los CIDR del pod que dirijan el tráfico al nodo híbrido correspondiente.

La tabla del enrutador tiene una entrada que indica que la subred `10.85.1.0/24` es accesible a través del nodo híbrido con IP `10.80.0.2`:

```
Destination     Next Hop
10.85.1.0/24    10.80.0.2
```

 **5. Procesamiento de la red del nodo** 

El enrutador reenvía el paquete al nodo híbrido (`10.80.0.2`). Cuando el paquete llega al nodo, todavía tiene la IP del pod A como origen y la IP del pod B como destino.

 **6. Procesamiento de la CNI** 

La pila de red del nodo recibe el paquete y, al ver que la IP de destino no es la suya propia, lo pasa a la CNI para su procesamiento. La CNI identifica que la IP de destino pertenece a un pod que se ejecuta localmente en este nodo y reenvía el paquete al pod correcto a través de las interfaces virtuales adecuadas:

```
Original packet -> node routing -> CNI -> Pod B's network namespace
```

El pod B recibe el paquete y lo procesa según sea necesario.

### Respuesta
<a name="_response_7"></a>

 **6. El pod B envía una respuesta** 

El pod B crea un paquete de respuesta con su propia IP como origen y la IP del pod A como destino:

```
+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.85.1.56 | Src: 8080           |                 |
| Dst: 10.0.0.56  | Dst: 52390          |                 |
+-----------------+---------------------+-----------------+
```

La CNI identifica que este paquete está destinado a una red externa y lo pasa a la pila de redes del nodo.

 **5. Procesamiento de la red del nodo** 

El nodo determina que la IP de destino (`10.0.0.56`) no pertenece a la red local y reenvía el paquete a su puerta de enlace predeterminada (el enrutador local).

 **4. Enrutamiento del enrutador local** 

El enrutador local consulta su tabla de enrutamiento y determina que la IP de destino (`10.0.0.56`) pertenece al CIDR de la VPC (`10.0.0.0/16`). Reenvía el paquete a la puerta de enlace que se conecta a AWS.

 **3. Tránsito transfronterizo** 

El paquete regresa a través de la misma conexión en las instalaciones a la VPC y cruza el límite de la nube en la dirección opuesta.

 **2. Enrutamiento de la VPC** 

Cuando el paquete llega a la VPC, el sistema de enrutamiento identifica que la IP de destino pertenece a una subred de la VPC. El paquete se enruta a través de la red de la VPC hacia la instancia EC2 que aloja el pod A.

 **1. El pod A recibe la respuesta** 

El paquete llega a la instancia EC2 y se entrega directamente al pod A a través de la ENI adjunta. Como la CNI de la VPC no utiliza redes superpuestas para los pods de la VPC, no es necesaria ninguna desencapsulación adicional: el paquete llega con sus encabezados originales intactos.

Este flujo de tráfico de este a oeste demuestra por qué los CIDR del pod remoto deben estar configurados correctamente y poder enrutarse desde ambas direcciones:
+ La VPC debe tener rutas para los CIDR del pod remoto que apunten a la puerta de enlace en las instalaciones.
+ La red en las instalaciones debe tener rutas para los CIDR del pod que dirijan el tráfico a los nodos específicos que alojan esos pods.

# Referencia de `nodeadm` de nodos híbridos
<a name="hybrid-nodes-nodeadm"></a>

La CLI (`nodeadm`) de los nodos híbridos de Amazon EKS simplifica la instalación, la configuración, el registro y la desinstalación de los componentes de los nodos híbridos. Puede incluir `nodeadm` en las imágenes de su sistema operativo para automatizar el arranque de los nodos híbridos; consulte [Cómo preparar el sistema operativo para los nodos híbridos](hybrid-nodes-os.md) para obtener más información.

La versión `nodeadm` para los nodos híbridos es distinta de la versión de `nodeadm` utilizada para arrancar instancias de Amazon EC2 como nodos en clústeres de Amazon EKS. Siga la documentación y las referencias para obtener la versión de `nodeadm` adecuada. Esta página de documentación es para la versión `nodeadm` de los nodos híbridos.

El código fuente de `nodeadm` de los nodos híbridos se publica en el repositorio de GitHub https://github.com/aws/eks-hybrid.

**importante**  
Debe ejecutar `nodeadm` con un usuario que tenga privilegios raíz/sudo.

## Descargue `nodeadm`
<a name="_download_nodeadm"></a>

La versión de nodos híbridos de `nodeadm` está alojada en Amazon S3, con Amazon CloudFront como frontend. Para instalar `nodeadm` en cada host en las instalaciones, puede ejecutar el siguiente comando desde los hosts en las instalaciones.

 **Para los hosts x** 

```
curl -OL 'https://hybrid-assets.eks.amazonaws.com/releases/latest/bin/linux/amd64/nodeadm'
```

 **Para los hosts ARM** 

```
curl -OL 'https://hybrid-assets.eks.amazonaws.com/releases/latest/bin/linux/arm64/nodeadm'
```

Agregue permiso de archivo ejecutable al binario descargado en cada host.

```
chmod +x nodeadm
```

## `nodeadm install`
<a name="_nodeadm_install"></a>

El comando `nodeadm install` se utiliza para instalar los artefactos y dependencias necesarios para ejecutar y unir nodos híbridos a un clúster de Amazon EKS. El comando `nodeadm install` se puede ejecutar de forma individual en cada nodo híbrido o se puede ejecutar durante las canalizaciones de creación de imágenes para preinstalar las dependencias de los nodos híbridos en las imágenes del sistema operativo.

 **Uso** 

```
nodeadm install [KUBERNETES_VERSION] [flags]
```

 **Argumentos de posición** 

(Obligatorio) `KUBERNETES_VERSION` La versión major.minor de Kubernetes de EKS que se va a instalar, por ejemplo `1.32` 

 **Indicadores** 


| Nombre | Obligatorio | Descripción | 
| --- | --- | --- | 
|   `-p`,  `--credential-provider`   |  TRUE  |  Proveedor de credenciales para instalar. Los valores admitidos son `iam-ra` y `ssm`. Para obtener más información, consulte [Cómo preparar las credenciales para los nodos híbridos](hybrid-nodes-creds.md).  | 
|   `-s`,  `--containerd-source`   |  FALSO  |  Origen de `containerd`. `nodeadm` admite la instalación de `containerd` desde la distribución del sistema operativo, los paquetes de Docker y la omisión de `containerd` de la instalación.  **Valores**   `distro`: es el valor predeterminado. `nodeadm` instalará el paquete de `containerd` más reciente distribuido por el sistema operativo del nodo que sea compatible con la versión de Kubernetes de EKS. `distro` no es un valor compatible con los sistemas operativos Red Hat Enterprise Linux (RHEL).  `docker`: `nodeadm` instalará el paquete de `containerd` más reciente creado y distribuido por Docker que sea compatible con la versión de Kubernetes de EKS. `docker` no es un valor compatible con Amazon Linux 2023.  `none`: `nodeadm` no instalará el paquete `containerd`. Debe instalar `containerd` manualmente antes de ejecutar `nodeadm init`.  | 
|   `-r`,  `--region`   |  FALSO  |  Especifica la región de AWS para descargar artefactos, como el agente SSM. El valor predeterminado es `us-west-2`.  | 
|   `-t`,  `--timeout`   |  FALSO  |  Duración máxima del comando de instalación. La entrada sigue el formato de duración. Por ejemplo: . `1h23m`. El tiempo de espera de descarga predeterminado del domando de instalación está establecido en 20 minutos.  | 
|   `-h`, `--help`   |  FALSO  |  Muestra un mensaje de ayuda con los parámetros disponibles de indicadores, subcomandos y valores posicionales.  | 

 **Ejemplos** 

Instale la versión `1.32` de Kubernetes con AWS Systems Manager (SSM) como proveedor de credenciales

```
nodeadm install 1.32 --credential-provider ssm
```

Instale la versión `1.32` de Kubernetes con AWS Systems Manager (SSM) como proveedor de credenciales y Docker como origen de containerd, con un tiempo de espera de descarga de 20 minutos.

```
nodeadm install 1.32 --credential-provider ssm --containerd-source docker --timeout 20m
```

Instale la versión `1.32` de Kubernetes con AWS IAM Roles Anywhere como proveedor de credenciales

```
nodeadm install 1.32 --credential-provider iam-ra
```

## `nodeadm config check`
<a name="_nodeadm_config_check"></a>

El comando `nodeadm config check` comprueba si hay errores en la configuración de nodo proporcionada. Este comando se puede utilizar para verificar un archivo de configuración de nodo híbrido y validar si es correcto.

 **Uso** 

```
nodeadm config check [flags]
```

 **Flags** 


| Nombre | Obligatorio | Descripción | 
| --- | --- | --- | 
|   `-c`,  `--config-source`   |  TRUE  |  Origen de la configuración de nodeadm. En el caso de los nodos híbridos, la entrada debe seguir un URI con un esquema de archivos.  | 
|   `-h`, `--help`   |  FALSO  |  Muestra un mensaje de ayuda con los parámetros disponibles de indicadores, subcomandos y valores posicionales.  | 

 **Ejemplos** 

```
nodeadm config check -c file://nodeConfig.yaml
```

## `nodeadm init`
<a name="_nodeadm_init"></a>

El comando `nodeadm init` inicia y conecta el nodo híbrido con el clúster de Amazon EKS configurado. Consulte [Configuración de nodo para activaciones híbridas de SSM](#hybrid-nodes-node-config-ssm) o [Configuración de nodos para IAM Roles Anywhere](#hybrid-nodes-node-config-iamra) para obtener detalles sobre cómo configurar el archivo `nodeConfig.yaml`.

 **Uso** 

```
nodeadm init [flags]
```

 **Flags** 


| Nombre | Obligatorio | Descripción | 
| --- | --- | --- | 
|   `-c`,  `--config-source`   |  TRUE  |  Origen de la configuración de `nodeadm`. En el caso de los nodos híbridos, la entrada debe seguir un URI con un esquema de archivos.  | 
|   `-s`,  `--skip`   |  FALSO  |  Las fases de `init` que se van a omitir. No se recomienda omitir ninguna de las fases a menos que ayude a solucionar un problema.  **Valores**   `install-validation` omite la verificación de si el comando de instalación anterior se ejecutó correctamente.  `cni-validation` omite la verificación de si los puertos VXLAN de las CNI Cilium o Calico están abiertos cuando el firewall está habilitado en el nodo.  `node-ip-validation` omite la verificación de si la IP del nodo se encuentra dentro de un CIDR en las redes de nodos remotos  | 
|   `-h`, `--help`   |  FALSO  |  Muestra un mensaje de ayuda con los parámetros disponibles de indicadores, subcomandos y valores posicionales.  | 

 **Ejemplos** 

```
nodeadm init -c file://nodeConfig.yaml
```

## `nodeadm upgrade`
<a name="_nodeadm_upgrade"></a>

El comando `nodeadm upgrade` actualiza todos los artefactos instalados a la versión más reciente y arranca el nodo para configurar los artefactos actualizados y unirlos al clúster de EKS en AWS. La actualización es un comando que interrumpe las cargas de trabajo que se ejecutan en el nodo. Traslade las cargas de trabajo a otro nodo antes de ejecutar la actualización.

 **Uso** 

```
nodeadm upgrade [KUBERNETES_VERSION] [flags]
```

 **Argumentos de posición** 

(Obligatorio) `KUBERNETES_VERSION` La versión major.minor de Kubernetes de EKS que se va a instalar, por ejemplo `1.32` 

 **Indicadores** 


| Nombre | Obligatorio | Descripción | 
| --- | --- | --- | 
|   `-c`,  `--config-source`   |  TRUE  |  Origen de la configuración de `nodeadm`. En el caso de los nodos híbridos, la entrada debe seguir un URI con un esquema de archivos.  | 
|   `-t`,  `--timeout`   |  FALSO  |  Tiempo de espera para descargar artefactos. La entrada sigue el formato de duración. Por ejemplo, 1h23m. El tiempo de espera de descarga predeterminado del domando de actualización está establecido en 10 minutos.  | 
|   `-s`,  `--skip`   |  FALSO  |  Las fases de la actualización que se van a omitir. No se recomienda omitir ninguna de las fases a menos que ayude a solucionar un problema.  **Valores**   `pod-validation` omite comprobar si todos los pods se ejecutan en el nodo, excepto los conjuntos de daemon y los pods estáticos.  `node-validation` omite comprobar si el nodo ha sido acordonado.  `init-validation` omite comprobar si el nodo se ha inicializado correctamente antes de ejecutar la actualización.  `containerd-major-version-upgrade` impide las actualizaciones de las versiones principales de containerd durante la actualización del nodo.  | 
|   `-h`, `--help`   |  FALSO  |  Muestra un mensaje de ayuda con los parámetros disponibles de indicadores, subcomandos y valores posicionales.  | 

 **Ejemplos** 

```
nodeadm upgrade 1.32 -c file://nodeConfig.yaml
```

```
nodeadm upgrade 1.32 -c file://nodeConfig.yaml --timeout 20m
```

## `nodeadm uninstall`
<a name="_nodeadm_uninstall"></a>

El comando `nodeadm uninstall` detiene y elimina los artefactos que `nodeadm` instala durante la `nodeadm install`, incluidos el kubelet y el containerd. Tenga en cuenta que el comando de desinstalación no vacía ni elimina los nodos híbridos del clúster. Debe ejecutar las operaciones de vaciado y eliminación por separado. Consulte [Cómo eliminar nodos híbridos](hybrid-nodes-remove.md) para obtener más información. De forma predeterminada, `nodeadm uninstall` no procederá si quedan pods en el nodo. Del mismo modo, `nodeadm uninstall` no elimina las dependencias del CNI ni las dependencias de otros complementos de Kubernetes que ejecute en el clúster. Para eliminar por completo la instalación de CNI del host, consulte las instrucciones que aparecen en [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md). Si utiliza activaciones híbridas de AWS SSM como proveedor de credenciales en las instalaciones, el comando `nodeadm uninstall` anula el registro de los hosts como instancias administradas por AWS SSM.

 **Uso** 

```
nodeadm uninstall [flags]
```

 **Flags** 


| Nombre | Obligatorio | Descripción | 
| --- | --- | --- | 
|   `-s`,  `--skip`   |  FALSO  |  Las fases de desinstalación que se van a omitir. No se recomienda omitir ninguna de las fases a menos que ayude a solucionar un problema.  **Valores**   `pod-validation` omite comprobar si todos los pods se ejecutan en el nodo, excepto los conjuntos de daemon y los pods estáticos.  `node-validation` omite comprobar si el nodo ha sido acordonado.  `init-validation` omite comprobar si el nodo se ha inicializado correctamente antes de ejecutar la desinstalación.  | 
|   `-h`,  `--help`   |  FALSO  |  Muestra un mensaje de ayuda con los parámetros disponibles de indicadores, subcomandos y valores posicionales.  | 
|   `-f`,  `--force`   |  FALSO  |  Fuerce la eliminación de directorios adicionales que puedan contener archivos restantes de los componentes de Kubernetes y CNI.  **ADVERTENCIA**  Esto eliminará todo el contenido de los directorios predeterminados de Kubernetes y CNI (`/var/lib/cni`, `/etc/cni/net.d`, etc.). No utilice esta marca si almacena sus propios datos en estas ubicaciones. A partir de nodeadm `v1.0.9`, el comando `./nodeadm uninstall --skip node-validation,pod-validation --force` ya no elimina el directorio `/var/lib/kubelet`. Esto se debe a que puede contener volúmenes de Pod y directorios de subrutas de volúmenes que, a veces, incluyen el sistema de archivos del nodo montado.  **Consejos para un manejo seguro**  - La eliminación de rutas montadas puede llevar a la eliminación accidental del sistema de archivos del nodo montado real. Antes de eliminar manualmente el directorio `/var/lib/kubelet`, inspeccione cuidadosamente todos los montajes activos y desmonte los volúmenes de forma segura para evitar la pérdida de datos.  | 

 **Ejemplos** 

```
nodeadm uninstall
```

```
nodeadm uninstall --skip node-validation,pod-validation
```

## `nodeadm debug`
<a name="_nodeadm_debug"></a>

El comando `nodeadm debug` se puede utilizar para solucionar problemas de nodos híbridos mal configurados o en mal estado. Valida que se cumplan los siguientes requisitos.
+ El nodo tiene acceso de red a las API de AWS necesarias para obtener las credenciales;
+ El nodo puede obtener credenciales de AWS para el rol de IAM de nodos híbridos configurado;
+ El nodo tiene acceso de red al punto de conexión de la API de Kubernetes de EKS y la validez del certificado de punto de conexión de la API de Kubernetes de EKS;
+ El nodo se puede autenticar con el clúster de EKS; su identidad en el clúster es válida; y cuenta con acceso al clúster de EKS a través de la VPC configurada para el clúster de EKS.

Si se encuentran errores, el resultado del comando sugiere los pasos para solucionar el problema. Algunos pasos de validación muestran los procesos secundarios. Si fallan, el resultado aparece en una sección stderr debajo del error de validación.

 **Uso** 

```
nodeadm debug [flags]
```

 **Flags** 


| Nombre | Obligatorio | Descripción | 
| --- | --- | --- | 
|   `-c`, `--config-source`   |  TRUE  |  Origen de la configuración de `nodeadm`. En el caso de los nodos híbridos, la entrada debe seguir un URI con un esquema de archivos.  | 
|   `--no-color`   |  FALSO  |  Desactiva la salida en color. Útil para la automatización.  | 
|   `-h`, `--help`   |  FALSO  |  Muestra un mensaje de ayuda con los parámetros disponibles de indicadores, subcomandos y valores posicionales.  | 

 **Ejemplos** 

```
nodeadm debug -c file://nodeConfig.yaml
```

## Ubicaciones de archivos de nodeadm
<a name="_nodeadm_file_locations"></a>

### instalación de nodeadm
<a name="_nodeadm_install_2"></a>

Cuando se ejecuta `nodeadm install`, se configuran los siguientes archivos y ubicaciones de archivos.


| Artefacto | Ruta | 
| --- | --- | 
|  CLI de IAM Roles Anywhere  |  /usr/local/bin/aws\$1signing\$1helper  | 
|  Kubelet binario  |  /usr/bin/kubelet  | 
|  Kubectl binario  |  usr/local/bin/kubectl  | 
|  Proveedor de credenciales de ECR  |  /etc/eks/image-credential-provider/ecr-credential-provider  | 
|   Autenticador de AWS IAM  |  /usr/local/bin/aws-iam-authenticator  | 
|  CLI de configuración de SSM  |  /opt/ssm/ssm-setup-cli  | 
|  SSM Agent  |  En Ubuntu: /snap/amazon-ssm-agent/current/amazon-ssm-agent En RHEL y AL2023: /usr/bin/amazon-ssm-agent  | 
|  Containerd  |  En Ubuntu y AL2023: /usr/bin/containerd En RHEL: /bin/containerd  | 
|  Iptables  |  En Ubuntu y AL2023: /usr/sbin/iptables En RHEL: /sbin/iptables  | 
|  Complementos de CNI  |  /opt/cni/bin  | 
|  rastreador de artefactos instalados  |  /opt/nodeadm/tracker  | 

### nodeadm init
<a name="_nodeadm_init_2"></a>

Cuando se ejecuta `nodeadm init`, se configuran los siguientes archivos y ubicaciones de archivos.


| Nombre | Ruta | 
| --- | --- | 
|  kubeconfig de Kubelet  |  /var/lib/kubelet/kubeconfig  | 
|  Configuración de Kubelet  |  /etc/kubernetes/kubelet/config.json  | 
|  Unidad systemd de Kubelet  |  /etc/systemd/system/kubelet.service  | 
|  Configuración del proveedor de credenciales de imágenes  |  /etc/eks/image-credential-provider/config.json  | 
|  Archivo env de Kubelet  |  /etc/eks/kubelet/environment  | 
|  Certificados de Kubelet  |  /etc/kubernetes/pki/ca.crt  | 
|  Configuración de containerd  |  /etc/containerd/config.toml  | 
|  Configuración de los módulos del núcleo de containerd  |  /etc/modules-load.d/contianerd.conf  | 
|   AWSArchivo de configuración de   |  /etc/aws/hybrid/config  | 
|   Archivo de credenciales de AWS (si está habilitado el archivo de credenciales)  |  /eks-hybrid/.aws/credentials  | 
|   Unidad de sistema auxiliar de firma de AWS  |  /etc/systemd/system/aws\$1signing\$1helper\$1update.service  | 
|  Archivo conf de Sysctl  |  /etc/sysctl.d/99-nodeadm.conf  | 
|  Ca-certificates  |  /etc/ssl/certs/ca-certificates.crt  | 
|  Archivo de clave de Gpg  |  /etc/apt/keyrings/docker.asc  | 
|  Archivo de origen del repositorio de Docker  |  /etc/apt/sources.list.d/docker.list  | 

## Configuración de nodo para activaciones híbridas de SSM
<a name="hybrid-nodes-node-config-ssm"></a>

El siguiente es un `nodeConfig.yaml` de ejemplo al utilizar activaciones híbridas de AWS SSM para credenciales de nodos híbridos.

```
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name:             # Name of the EKS cluster
    region:           # AWS Region where the EKS cluster resides
  hybrid:
    ssm:
      activationCode: # SSM hybrid activation code
      activationId:   # SSM hybrid activation id
```

## Configuración de nodos para IAM Roles Anywhere
<a name="hybrid-nodes-node-config-iamra"></a>

El siguiente es un `nodeConfig.yaml` de ejemplo para nodos híbridos de AWS IAM Roles Anywhere.

Si utiliza AWS IAM Roles Anywhere como proveedor de credenciales en las instalaciones, el `nodeName` que utilice en la configuración de `nodeadm` debe coincidir con los permisos que haya definido para el rol de IAM de nodos híbridos. Por ejemplo, si los permisos para el rol de IAM de nodos híbridos solo permiten que AWS IAM Roles Anywhere asuma el rol cuando el nombre de la sesión del rol es igual al CN del certificado de host, entonces el `nodeName` de la configuración de `nodeadm` debe ser el mismo que el CN de los certificados. El `nodeName` que utilice no puede tener más de 64 caracteres. Para obtener más información, consulte [Cómo preparar las credenciales para los nodos híbridos](hybrid-nodes-creds.md).

```
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name:              # Name of the EKS cluster
    region:            # AWS Region where the EKS cluster resides
  hybrid:
    iamRolesAnywhere:
      nodeName:        # Name of the node
      trustAnchorArn:  # ARN of the IAM Roles Anywhere trust anchor
      profileArn:      # ARN of the IAM Roles Anywhere profile
      roleArn:         # ARN of the Hybrid Nodes IAM role
      certificatePath: # Path to the certificate file to authenticate with the IAM Roles Anywhere trust anchor
      privateKeyPath:  # Path to the private key file for the certificate
```

## Configuración de nodos para personalizar kubelet (opcional)
<a name="hybrid-nodes-nodeadm-kubelet"></a>

Puede transmitir la configuración y los indicadores de kubelet en la configuración de `nodeadm`. Consulte el ejemplo que aparece a continuación sobre cómo agregar una etiqueta de nodo adicional `abc.amazonaws.com/test-label` y configurar para establecer `shutdownGracePeriod` en 30 segundos.

```
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name:             # Name of the EKS cluster
    region:           # AWS Region where the EKS cluster resides
  kubelet:
    config:           # Map of kubelet config and values
       shutdownGracePeriod: 30s
    flags:            # List of kubelet flags
       - --node-labels=abc.company.com/test-label=true
  hybrid:
    ssm:
      activationCode: # SSM hybrid activation code
      activationId:   # SSM hybrid activation id
```

## Configuración de nodos para personalizar containerd (opcional)
<a name="_node_config_for_customizing_containerd_optional"></a>

Puede transmitir la configuración de containerd personalizada en la configuración de `nodeadm`. La configuración de containerd para `nodeadm` acepta TOML en línea. Consulte el ejemplo que aparece a continuación para ver cómo configurar containerd para desactivar la eliminación de capas de imágenes desempaquetadas en el almacén de contenido de containerd.

```
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name:             # Name of the EKS cluster
    region:           # AWS Region where the EKS cluster resides
  containerd:
    config: |         # Inline TOML containerd additional configuration
       [plugins."io.containerd.grpc.v1.cri".containerd]
       discard_unpacked_layers = false
  hybrid:
    ssm:
      activationCode: # SSM hybrid activation code
      activationId:   # SSM hybrid activation id
```

**nota**  
Las versiones 1.x y 2.x de containerd utilizan diferentes formatos de configuración. containerd 1.x usa la versión de configuración 2, mientras que containerd 2.x usa la versión de configuración 3. Aunque containerd 2.x sigue siendo compatible con versiones anteriores de la versión de configuración 2, se recomienda la versión de configuración 3 para obtener un rendimiento óptimo. Compruebe la versión de containerd con `containerd --version` o consulte los registros de instalación de `nodeadm`. Para obtener más información sobre el control de versiones de configuración, consulte https://containerd.io/releases/

Además, puede utilizar la configuración de containerd para habilitar la compatibilidad con SELinux. Con SELinux habilitado en containerd, asegúrese de que los pods programados en el nodo tengan habilitados securityContext y seLinuxOptions adecuados. Puede encontrar más información sobre la configuración de un contexto de seguridad en la [documentación de Kubernetes](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/).

**nota**  
Red Hat Enterprise Linux (RHEL) 8 y RHEL 9 tienen SELinux habilitado de forma predeterminada y establecido en el modo estricto en el host. De forma predeterminada, SELinux está habilitado y configurado en modo permisivo en Amazon Linux 2023. Cuando SELinux está configurado en modo permisivo en el host, al activarlo en containerd no se bloquearán las solicitudes, sino que se hará el registro de acuerdo con la configuración de SELinux en el host.

```
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name:             # Name of the EKS cluster
    region:           # AWS Region where the EKS cluster resides
  containerd:
    config: |         # Inline TOML containerd additional configuration
       [plugins."io.containerd.grpc.v1.cri"]
       enable_selinux = true
  hybrid:
    ssm:
      activationCode: # SSM hybrid activation code
      activationId:   # SSM hybrid activation id
```

# Solución de problemas relacionados con los nodos híbridos
<a name="hybrid-nodes-troubleshooting"></a>

En este tema se tratan algunos errores habituales que pueden aparecer al utilizar los Nodos híbridos de Amazon EKS y cómo solucionarlos. Para obtener información adicional sobre la solución de problemas, consulte [Solución de problemas con los clústeres y nodos de Amazon EKS](troubleshooting.md) la [Etiqueta del Centro de conocimientos para Amazon EKS](https://repost.aws/tags/knowledge-center/TA4IvCeWI1TE66q4jEj4Z9zg/amazon-elastic-kubernetes-service) en * AWS re:Post*. Si no puede resolver el problema, contacte a AWS Support.

 **Solución de problemas del nodo con `nodeadm debug`:** puede ejecutar el comando `nodeadm debug` desde los nodos híbridos para comprobar que se cumplan los requisitos de red y credenciales. Para obtener más información acerca del comando `nodeadm debug`, consulte [Referencia de `nodeadm` de nodos híbridos](hybrid-nodes-nodeadm.md).

 **Detección de problemas con los nodos híbridos mediante la información sobre clústeres:** la información sobre clústeres de Amazon EKS incluye *comprobaciones de información* que detectan problemas comunes con la configuración de los nodos híbridos de EKS en el clúster. Puede ver los resultados de todas las comprobaciones de información desde la Consola de administración de AWS, la AWS CLI y los AWS SDK. Para obtener más detalles acerca de la información del clúster, consulte [Preparación para las actualizaciones de las versiones de Kubernetes y solución de problemas de configuración incorrecta con información sobre clústeres](cluster-insights.md).

## Solución de problemas de instalación de nodos híbridos
<a name="hybrid-nodes-troubleshooting-install"></a>

Los siguientes temas de solución de problemas están relacionados con la instalación de las dependencias de los nodos híbridos en los hosts mediante el comando `nodeadm install`.

 ** `nodeadm` El comando falló `must run as root` ** 

El comando `nodeadm install` se debe ejecutar con un usuario que tenga privilegios de raíz o `sudo` en el host. Si ejecuta `nodeadm install` con un usuario que no tiene privilegios de raíz o `sudo`, el siguiente error aparecerá en el resultado de `nodeadm`.

```
"msg":"Command failed","error":"must run as root"
```

 **No se puede conectar a las dependencias** 

El comando `nodeadm install` instala las dependencias necesarias para los nodos híbridos. Algunas de las dependencias de los nodos híbridos son `containerd`, `kubelet`, `kubectl` y AWS SSM o componentes de AWS IAM Roles Anywhere. Debe tener acceso desde el lugar donde ejecuta `nodeadm install` para descargar estas dependencias. Para obtener más información sobre la lista de ubicaciones a las que debe tener acceso, consulte [Cómo preparar las redes para los nodos híbridos](hybrid-nodes-networking.md). Si no tiene acceso, se producirán errores similares a los siguientes en el resultado de `nodeadm install`.

```
"msg":"Command failed","error":"failed reading file from url: ...: max retries achieved for http request"
```

 **No se pudo actualizar el administrador de paquetes** 

El comando `nodeadm install` ejecuta `apt update`, `yum update` o `dnf update` antes de instalar las dependencias de los nodos híbridos. Si este paso no se realiza correctamente, es posible que se produzcan errores similares a los siguientes. Para solucionarlo, puede ejecutar `apt update`, `yum update` o `dnf update` antes de ejecutar `nodeadm install`. De otro modo, puede intentar volver a ejecutar `nodeadm install`.

```
failed to run update using package manager
```

 **Se ha superado el tiempo de espera o el plazo de contexto** 

Al ejecutar `nodeadm install`, si observa problemas en distintas etapas del proceso de instalación con errores que indiquen un tiempo de espera agotado o que se superó el plazo de contexto, es posible que tenga una conexión lenta que impide la instalación de las dependencias de los nodos híbridos antes de que se cumplan los tiempos de espera. Para solucionar estos problemas, puede intentar utilizar la marca `--timeout` en `nodeadm` para prolongar los tiempos de espera para descargar las dependencias.

```
nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER --timeout 20m0s
```

## Solución de problemas de conexión de nodos híbridos
<a name="hybrid-nodes-troubleshooting-connect"></a>

Los temas de solución de problemas de esta sección están relacionados con el proceso de conexión de nodos híbridos a clústeres de EKS mediante el comando `nodeadm init`.

 **Errores de operaciones o esquemas no compatibles** 

Si al ejecutar `nodeadm init` aparecen errores relacionados con `operation error` o `unsupported scheme`, compruebe `nodeConfig.yaml` para garantizar que tenga el formato correcto y que se ha transmitido a `nodeadm`. Para obtener más información sobre el formato y las opciones para `nodeConfig.yaml`, consulte [Referencia de `nodeadm` de nodos híbridos](hybrid-nodes-nodeadm.md).

```
"msg":"Command failed","error":"operation error ec2imds: GetRegion, request canceled, context deadline exceeded"
```

 **El rol de IAM de los Nodos híbridos carece de permisos para la acción `eks:DescribeCluster`** 

Cuando se ejecuta `nodeadm init`, `nodeadm` intenta recopilar información sobre el clúster de EKS mediante una llamada a la acción `DescribeCluster` de EKS. Si el rol de IAM de Nodos híbridos no tiene permiso para la acción `eks:DescribeCluster`, deberá transmitir el punto de conexión de la API de Kubernetes, el paquete de CA del clúster y el CIDR IPv4 del servicio a la configuración de nodos que transmite a `nodeadm` al ejecutar `nodeadm init`. Para obtener más información sobre los permisos necesarios para el rol de IAM de los Nodos híbridos, consulte [Cómo preparar las credenciales para los nodos híbridos](hybrid-nodes-creds.md).

```
"msg":"Command failed","error":"operation error EKS: DescribeCluster, https response error StatusCode: 403 ... AccessDeniedException"
```

 **El rol de IAM de los Nodos híbridos carece de permisos para la acción `eks:ListAccessEntries`** 

Cuando se ejecuta `nodeadm init`, `nodeadm` intenta validar si el clúster de EKS tiene una entrada de acceso del tipo `HYBRID_LINUX` asociada al rol de IAM de Nodos híbridos mediante una llamada a la acción `ListAccessEntries` de EKS. Si el rol de IAM de Nodos híbridos no tiene permiso para la acción `eks:ListAccessEntries`, debe transmitir el indicador `--skip cluster-access-validation` al ejecutar el comando `nodeadm init`. Para obtener más información sobre los permisos necesarios para el rol de IAM de los Nodos híbridos, consulte [Cómo preparar las credenciales para los nodos híbridos](hybrid-nodes-creds.md).

```
"msg":"Command failed","error":"operation error EKS: ListAccessEntries, https response error StatusCode: 403 ... AccessDeniedException"
```

 **La IP del nodo no está dentro del CIDR de la red del nodo remoto** 

Al ejecutar `nodeadm init`, se podría producir un error si la dirección IP del nodo no se encuentra dentro de los CIDR de red de nodos remotos especificados. El error tendrá un aspecto similar al siguiente ejemplo:

```
node IP 10.18.0.1 is not in any of the remote network CIDR blocks [10.0.0.0/16 192.168.0.0/16]
```

Este ejemplo muestra un nodo con la IP 10.18.0.1 que intenta unirse a un clúster con CIDR de red remota 10.0.0.0/16 y 192.168.0.0/16. El error se produce porque la IP 10.18.0.1 no se encuentra dentro de ninguno de los rangos.

Confirme que haya configurado correctamente las `RemoteNodeNetworks` para incluir todas las direcciones IP de los nodos. Para obtener más información sobre la configuración de la red, consulte [Cómo preparar las redes para los nodos híbridos](hybrid-nodes-networking.md).
+ Ejecute el siguiente comando en la región en la que se encuentra el clúster para comprobar las configuraciones de `RemoteNodeNetwork`. Verifique que los bloques de CIDR que aparecen en la salida incluyan el rango de IP del nodo y coincidan con los bloques de CIDR mencionados en el mensaje de error. Si no coinciden, confirme que el nombre del clúster y la región especificados en el archivo `nodeConfig.yaml` correspondan al clúster previsto.

```
aws eks describe-cluster --name CLUSTER_NAME --region REGION_NAME --query cluster.remoteNetworkConfig.remoteNodeNetworks
```
+ Verifique que el nodo sea el previsto:
  + Para confirmar que se trata del nodo correcto, verifique que el nombre de host y la dirección IP coincidan con los que desea registrar en el clúster.
  + Confirme que este nodo se encuentra en la red en las instalaciones correcta (aquella cuyo rango de CIDR se registró como `RemoteNodeNetwork` durante la configuración del clúster).

Si la IP del nodo aún no es la esperada, verifique lo siguiente:
+ Si utiliza IAM Roles Anywhere, `kubelet` realiza una consulta de DNS sobre el `nodeName` de IAM Roles Anywhere y usa una IP asociada con el nombre de nodo si está disponible. Si dispone de entradas de DNS para los nodos, confirme que dichas entradas apunten a direcciones IP que se encuentren dentro de los CIDR de la red de nodos remotos.
+ Si el nodo tiene múltiples interfaces de red, `kubelet` podría elegir como predeterminada una interfaz cuya dirección IP no esté dentro de los CIDR de la red de nodos remotos. Para utilizar una interfaz diferente, especifique su dirección IP con la marca `--node-ip` `kubelet` en el archivo `nodeConfig.yaml`. Para obtener más información, consulte [Referencia de `nodeadm` de nodos híbridos](hybrid-nodes-nodeadm.md). Para ver las interfaces de red del nodo y sus direcciones IP, ejecute el siguiente comando en el nodo:

```
ip addr show
```

 **Los nodos híbridos no aparecen en el clúster de EKS** 

Si ejecutó `nodeadm init` y se completó, pero los nodos híbridos no aparecen en el clúster, es posible que haya problemas con la conexión de red entre los nodos híbridos y el plano de control de EKS, que no tenga configurados los permisos de grupo de seguridad necesarios o que no tenga la asignación necesaria del rol de IAM de nodos híbridos al control de acceso basado en roles (RBAC) de Kubernetes. Para iniciar el proceso de depuración, puede utilizar los siguientes comandos para comprobar el estado de `kubelet` y los registros de `kubelet`. Ejecute los siguientes comandos desde los nodos híbridos que no se pudieron unir al clúster.

```
systemctl status kubelet
```

```
journalctl -u kubelet -f
```

 **No se puede establecer comunicación con el clúster** 

Si el nodo híbrido no se pudo comunicar con el plano de control del clúster, es posible que se produzcan registros similares a los siguientes.

```
"Failed to ensure lease exists, will retry" err="Get ..."
```

```
"Unable to register node with API server" err="Post ..."
```

```
Failed to contact API server when waiting for CSINode publishing ... dial tcp <ip address>: i/o timeout
```

Si aparecen estos mensajes, compruebe lo siguiente para asegurarse de que cumple con los requisitos de los nodos híbridos que se indican en [Cómo preparar las redes para los nodos híbridos](hybrid-nodes-networking.md).
+ Confirme que la VPC trasladada al clúster de EKS tenga rutas a la puerta de enlace de tránsito (TGW) o puerta de enlace privada virtual (VGW) para el nodo en las instalaciones y, opcionalmente, los CIDR del pod.
+ Confirme que cuenta con un grupo de seguridad adicional para el clúster de EKS que tenga reglas de entrada para los CIDR de los nodos en las instalaciones y, opcionalmente, los CIDR de los pods.
+ Confirme que el enrutador en las instalaciones esté configurado para permitir el tráfico hacia y desde el plano de control de EKS.

 **No autorizado** 

Si el nodo híbrido se pudo comunicar con el plano de control de EKS pero no se pudo registrar, es posible que vea registros similares a los siguientes. Tenga en cuenta que la diferencia clave en los mensajes de registro que aparecen a continuación es el error `Unauthorized`. Esto indica que el nodo no pudo realizar sus tareas porque no tiene los permisos necesarios.

```
"Failed to ensure lease exists, will retry" err="Unauthorized"
```

```
"Unable to register node with API server" err="Unauthorized"
```

```
Failed to contact API server when waiting for CSINode publishing: Unauthorized
```

Si aparecen estos mensajes, compruebe lo siguiente para asegurarse de que cumple con los requisitos de los nodos híbridos que se indican en [Cómo preparar las credenciales para los nodos híbridos](hybrid-nodes-creds.md) y [Cómo preparar el acceso al clúster para los nodos híbridos](hybrid-nodes-cluster-prep.md).
+ Confirme que la identidad de los nodos híbridos coincide con el rol de IAM previsto para los nodos híbridos. Para ello, se puede ejecutar `sudo aws sts get-caller-identity` desde los nodos híbridos.
+ Compruebe que el rol de IAM de los Nodos híbridos tiene los permisos necesarios.
+ Confirme que en el clúster tiene una entrada de acceso a EKS para el rol de IAM de los Nodos híbridos o confirme que el ConfigMap de `aws-auth` tiene una entrada para el rol de IAM de los Nodos híbridos. Si utiliza entradas de acceso a EKS, confirme que la entrada de acceso para el rol de IAM de los Nodos híbridos sea del tipo de acceso `HYBRID_LINUX`. Si utiliza ConfigMap de `aws-auth`, confirme que la entrada para el rol de IAM de los Nodos híbridos cumpla con los requisitos y el formato que se detallan en [Cómo preparar el acceso al clúster para los nodos híbridos](hybrid-nodes-cluster-prep.md).

### Los nodos híbridos están registrados en el clúster de EKS, pero aparecen en estado `Not Ready`
<a name="hybrid-nodes-troubleshooting-not-ready"></a>

Si los nodos híbridos se registraron correctamente en el clúster de EKS, pero los nodos híbridos aparecen en estado `Not Ready`, lo primero que hay que comprobar es el estado de la interfaz de red de contenedores (CNI). Si no ha instalado una CNI, lo normal es que los nodos híbridos se encuentren en estado `Not Ready`. Una vez que una CNI se instala y se ejecuta correctamente, los nodos se actualizan al estado `Ready`. Si ha intentado instalar una CNI, pero no se ejecuta correctamente, consulte [Solución de problemas de la CNI de nodos híbridos](#hybrid-nodes-troubleshooting-cni) en esta página.

 **Las solicitudes de firma de certificados (CSR) están atascadas en estado Pendiente** 

Después de conectar nodos híbridos al clúster de EKS, si ve que hay CSR pendientes correspondientes a los nodos híbridos, significa que los nodos híbridos no cumplen los requisitos para la aprobación automática. Las CSR para nodos híbridos se aprueban y emiten automáticamente si las CSR para nodos híbridos fueron creadas por un nodo con etiqueta `eks.amazonaws.com/compute-type: hybrid`, y la CSR tiene los siguientes nombres alternativos de asunto (SAN): al menos un SAN de DNS igual al nombre del nodo y los SAN de IP pertenecen a los CIDR de la red de nodos remotos.

 **Ya existe un perfil híbrido** 

Si ha cambiado la configuración de `nodeadm` e intenta volver a registrar el nodo con la nueva configuración, es posible que aparezca un error que indica que el perfil híbrido ya existe, pero su contenido ha cambiado. En lugar de ejecutar `nodeadm init` entre los cambios de configuración, ejecute `nodeadm uninstall` seguido de `nodeadm install` y `nodeadm init`. Esto garantiza una limpieza adecuada con los cambios en la configuración.

```
"msg":"Command failed","error":"hybrid profile already exists at /etc/aws/hybrid/config but its contents do not align with the expected configuration"
```

 **El nodo híbrido no pudo resolver la API privada** 

Después de ejecutar `nodeadm init`, si aparece un error en los registros de `kubelet` que indique que no se ha establecido contacto con el servidor de la API de Kubernetes de EKS debido a que `no such host`, es posible que tenga que cambiar la entrada de DNS del punto de conexión de la API de Kubernetes de EKS en la red en las instalaciones o a nivel de host. Consulte [Reenvío de consultas de DNS entrantes a la VPC](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-forwarding-inbound-queries.html) en la *documentación de AWS Route53*.

```
Failed to contact API server when waiting for CSINode publishing: Get ... no such host
```

 **No se pueden ver los nodos híbridos en la consola de EKS** 

Si ha registrado los nodos híbridos, pero no puede verlos en la consola de EKS, compruebe los permisos de la entidad principal de IAM que utiliza para ver la consola. La entidad principal de IAM que utiliza debe tener permisos mínimos específicos de IAM y Kubernetes para ver los recursos de la consola. Para obtener más información, consulte [Visualización de los recursos de Kubernetes en la Consola de administración de AWS](view-kubernetes-resources.md).

## Solución de problemas de ejecución de nodos híbridos
<a name="_running_hybrid_nodes_troubleshooting"></a>

Si los nodos híbridos registrados en el clúster de EKS se encontraban en estado `Ready` y, posteriormente, pasaron al estado `Not Ready`, existe una amplia gama de problemas que pueden haber contribuido al mal estado, como que el nodo carezca de recursos suficientes para la CPU, la memoria o el espacio en disco disponible, o que el nodo esté desconectado del plano de control de EKS. Puede seguir los pasos que se indican a continuación para solucionar los problemas de los nodos y, si no puede resolver el problema, contacte a AWS Support.

Ejecute `nodeadm debug` desde los nodos híbridos para comprobar que se cumplen los requisitos de red y credenciales. Para obtener más información acerca del comando `nodeadm debug`, consulte [Referencia de `nodeadm` de nodos híbridos](hybrid-nodes-nodeadm.md).

 **Obtención del estado de los nodos** 

```
kubectl get nodes -o wide
```

 **Comprobación de las condiciones y los eventos de nodos** 

```
kubectl describe node NODE_NAME
```

 **Obtención del estado de los pods** 

```
kubectl get pods -A -o wide
```

 **Comprobación de las condiciones y los eventos de pods** 

```
kubectl describe pod POD_NAME
```

 **Comprobación de los registros de pods** 

```
kubectl logs POD_NAME
```

 **Comprobar los registros de `kubectl`** 

```
systemctl status kubelet
```

```
journalctl -u kubelet -f
```

 **Las sondas de actividad del pod fallan o los webhooks no funcionan** 

Si las aplicaciones, complementos o webhooks que se ejecutan en los nodos híbridos no se inician correctamente, es posible que existan problemas de red que bloqueen la comunicación con los pods. Para que el plano de control de EKS se ponga en contacto con los webhooks que se ejecutan en nodos híbridos, debe configurar el clúster de EKS con una red de pods remotos y disponer de rutas para el CIDR de pods en las instalaciones en la tabla de enrutamiento de VPC con el destino como la puerta de enlace de tránsito (TGW), la puerta de enlace virtual privada (VPW) u otra puerta de enlace que utilice para conectar la VPC con la red en las instalaciones. Para obtener más información sobre los requisitos de red para los nodos híbridos, consulte [Cómo preparar las redes para los nodos híbridos](hybrid-nodes-networking.md). Además, debe permitir este tráfico en el firewall en las instalaciones y asegurarse de que el enrutador puede dirigir correctamente el tráfico a los pods. Consulte [Configuración de webhooks para nodos híbridos](hybrid-nodes-webhooks.md) para obtener más información sobre los requisitos para ejecutar webhooks en nodos híbridos.

A continuación aparece un mensaje de registro de pod común para este escenario, en el que ip-address es la IP del clúster del servicio de Kubernetes.

```
dial tcp <ip-address>:443: connect: no route to host
```

 **Los comandos `kubectl logs` o `kubectl exec` no funcionan (comandos de la API de `kubelet`)** 

Si los comandos `kubectl attach`, `kubectl cp`, `kubectl exec`, `kubectl logs` y `kubectl port-forward` agotan el tiempo de espera mientras otros comandos `kubectl` se ejecutan correctamente, es probable que el problema esté relacionado con la configuración de la red remota. Estos comandos se conectan a través del clúster al punto de conexión de `kubelet` en el nodo. Para obtener más información consulte () [Punto de conexión de `kubelet`](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-kubelet-api).

Verifique que las direcciones IP de los nodos y pods se encuentren dentro de los CIDR de la red de nodos remotos y de la red de pods remotos configurados para el clúster. Use los siguientes comandos para examinar las asignaciones de IP.

```
kubectl get nodes -o wide
```

```
kubectl get pods -A -o wide
```

Compare estas direcciones IP con los CIDR de red remota configurados para asegurarse de que el enrutamiento sea correcto. Para consultar los requisitos de configuración de red, consulte [Cómo preparar las redes para los nodos híbridos](hybrid-nodes-networking.md).

## Solución de problemas de la CNI de nodos híbridos
<a name="hybrid-nodes-troubleshooting-cni"></a>

Si tiene problemas al iniciar Cilium o Calico al principio con nodos híbridos, la mayoría de las veces se debe a problemas de red entre los nodos híbridos o los pods de la CNI que se ejecutan en los nodos híbridos y el plano de control de EKS. Asegúrese de que el entorno cumpla los requisitos que se indican en Cómo preparar las redes para los nodos híbridos. Resulta útil dividir el problema en partes.

Configuración del clúster de EKS  
¿Son correctas las configuraciones de RemoteNodeNetwork y RemotePodNetwork?

Configuración de la VPC  
¿Existen rutas para RemoteNodeNetwork y RemotePodNetwork en la tabla de enrutamiento de la VPC con el destino de la puerta de enlace de tránsito o la puerta de enlace virtual privada?

Configuración del grupo de seguridad  
¿Existen reglas de entrada y salida para RemoteNodeNetwork y RemotePodNetwork?

Red on-premise  
¿Existen rutas y acceso hacia y desde el plano de control de EKS, así como hacia y desde los nodos híbridos y los pods que se ejecutan en estos?

Configuración de la CNI  
Si se utiliza una red superpuesta, ¿la configuración del grupo de IP de la CNI coincide la RemotePodNetwork configurada para el clúster de EKS si se utilizan webhooks?

 **El nodo híbrido se encuentra en estado `Ready` sin una CNI instalada** 

Si los nodos híbridos se encuentran en el estado `Ready`, pero no ha instalado una CNI en el clúster, es posible que haya artefactos de CNI antiguos en los nodos híbridos. De forma predeterminada, al desinstalar Cilium y Calico con herramientas como Helm, los recursos del disco no se eliminan de las máquinas físicas o virtuales. Además, es posible que las definiciones de recursos personalizados (CRD) de estas CNI aún estén presentes en el clúster a partir de una instalación anterior. Para obtener más información, consulte las secciones Cómo eliminar Cilio y Cómo eliminar Calico en [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md).

 **Solución de problemas de Cilium** 

Si tiene problemas al ejecutar Cilium en nodos híbridos, consulte los [pasos de solución de problemas](https://docs.cilium.io/en/stable/operations/troubleshooting/) en la documentación de Cilium. Las secciones siguientes tratan problemas que pueden ser particulares de la implementación de Cilium en nodos híbridos.

 **Cilium no se inicia** 

Si los agentes de Cilium que se ejecutan en cada nodo híbrido no se inician, compruebe si hay errores en los registros de los pods de agentes de Cilium. El agente de Cilium requiere conectividad con el punto de conexión de la API de Kubernetes de EKS para poder iniciarse. Se producirá un error al iniciar el agente de Cilium si la conectividad no está configurada correctamente. En este caso, aparecerán mensajes de registro similares a los siguientes en los registros del pod del agente de Cilium.

```
msg="Unable to contact k8s api-server"
level=fatal msg="failed to start: Get \"https://<k8s-cluster-ip>:443/api/v1/namespaces/kube-system\": dial tcp <k8s-cluster-ip>:443: i/o timeout"
```

El agente de Cilium se ejecuta en la red host. El clúster de EKS debe estar configurado con `RemoteNodeNetwork` para la conectividad con Cilium. Confirme que cuenta con un grupo de seguridad adicional para el clúster de EKS con una regla de entrada para la `RemoteNodeNetwork`, que dispone de rutas en la VPC para la `RemoteNodeNetwork` y que la red en las instalaciones está configurada correctamente para permitir la conectividad con el plano de control de EKS.

Si el operador de Cilium está en ejecución y algunos de los agentes de Cilium se ejecutan, pero no la totalidad, confirme que tiene direcciones IP de pod disponibles para asignarlas a todos los nodos del clúster. El tamaño de los CIDR de pods asignables se configura al usar la administración de IP del grupo del clúster con `clusterPoolIPv4PodCIDRList` en la configuración de Cilium. El tamaño del CIDR por nodo se configura con el ajuste `clusterPoolIPv4MaskSize` de la configuración de Cilium. Consulte [Ampliación del grupo de clústeres](https://docs.cilium.io/en/stable/network/concepts/ipam/cluster-pool/#expanding-the-cluster-pool) en la documentación de Cilium para obtener más información.

 **El BGP de Cilium no funciona** 

Si utiliza el plano de control de BGP de Cilium para anunciar las direcciones de los pods o servicios en la red en las instalaciones, puede utilizar los siguientes comandos de la CLI de Cilium para comprobar si BGP anuncia las rutas a los recursos. Para conocer los pasos que se deben seguir para instalar la CLI de Cilium, consulte [Instalación de la CLI de Cilium](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/#install-the-cilium-cli) en la documentación de Cilium.

Si BGP funciona correctamente, debería ver los nodos híbridos con el estado de sesión `established` en el resultado. Es posible que necesite trabajar con el equipo de redes para identificar los valores correctos para el AS local, el AS del vecino y la dirección del vecino del entorno.

```
cilium bgp peers
```

```
cilium bgp routes
```

Si utiliza el BGP de Cilium para anunciar las IP de los servicios con el tipo `LoadBalancer`, debe tener la misma etiqueta tanto en el `CiliumLoadBalancerIPPool` como en el servicio, que se debe utilizar en el selector del `CiliumBGPAdvertisement`. A continuación se muestra un ejemplo. Tenga en cuenta que, si utiliza el BGP de Cilium para anunciar las IP de los servicios del tipo LoadBalancer, es posible que las rutas de BGP se interrumpan durante el reinicio del agente de Cilium. Para obtener más información, consulte los [Escenarios de error](https://docs.cilium.io/en/latest/network/bgp-control-plane/bgp-control-plane-operation/#failure-scenarios) en la documentación de Cilium.

 **Servicio de** 

```
kind: Service
apiVersion: v1
metadata:
  name: guestbook
  labels:
    app: guestbook
spec:
  ports:
  - port: 3000
    targetPort: http-server
  selector:
    app: guestbook
  type: LoadBalancer
```

 **CiliumLoadBalancerIPPool** 

```
apiVersion: cilium.io/v2alpha1
kind: CiliumLoadBalancerIPPool
metadata:
  name: guestbook-pool
  labels:
    app: guestbook
spec:
  blocks:
  - cidr: <CIDR to advertise>
  serviceSelector:
    matchExpressions:
      - { key: app, operator: In, values: [ guestbook ] }
```

 **CiliumBGPAdvertisement** 

```
apiVersion: cilium.io/v2alpha1
kind: CiliumBGPAdvertisement
metadata:
  name: bgp-advertisements-guestbook
  labels:
    advertise: bgp
spec:
  advertisements:
    - advertisementType: "Service"
      service:
        addresses:
          - ExternalIP
          - LoadBalancerIP
      selector:
        matchExpressions:
          - { key: app, operator: In, values: [ guestbook ] }
```

 **Solución de problemas de Calico** 

Si tiene problemas al ejecutar Cilium en nodos híbridos, consulte los [pasos de solución de problemas](https://docs.tigera.io/calico/latest/operations/troubleshoot/) en la documentación de Calico. En las siguientes secciones se describen los problemas que pueden ser exclusivos de la implementación de Calico en nodos híbridos.

En la siguiente tabla se resumen los componentes de Calico y se indica si se ejecutan en la red de nodos o de pods de forma predeterminada. Si configuró Calico para usar NAT para el tráfico de pods saliente, la red en las instalaciones debe estar configurada para dirigir el tráfico al CIDR del nodo en las instalaciones. Además, las tablas de enrutamiento de la VPC deben estar configuradas con una ruta para el CIDR del nodo en las instalaciones con la puerta de enlace de tránsito (TGW) o la puerta de enlace privada virtual (VGW) como destino. Si no va a configurar Calico para usar NAT para el tráfico de pods saliente, la red en las instalaciones debe estar configurada para dirigir el tráfico al CIDR del pod en las instalaciones. Además, las tablas de enrutamiento de la VPC deben estar configuradas con una ruta para el CIDR del pod en las instalaciones con la puerta de enlace de tránsito (TGW) o la puerta de enlace privada virtual (VGW) como destino.


| Componente | Network | 
| --- | --- | 
|  Servidor de la API de Calico  |  Nodo  | 
|  Controladores de Calicon para Kubernetes  |  Pod  | 
|  Agende de nodos de Calico  |  Nodo  | 
|  Calico `typha`   |  Nodo  | 
|  Controlador de nodos de CSI de Calico  |  Pod  | 
|  Operador de Calico  |  Nodo  | 

 **Los recursos de Calico están programados o se ejecutan en nodos acordonados** 

Los recursos de Calico que no se ejecutan como un DaemonSet tienen tolerancias flexibles de forma predeterminada gracias a las cuales es posible programarlos en nodos acordonados que no están preparados para programar o ejecutar pods. Para ajustar las tolerancias para los recursos de Calico que no son de DaemonSet, puede cambiar la instalación del operador de modo que incluya lo siguiente.

```
installation:
  ...
  controlPlaneTolerations:
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  calicoKubeControllersDeployment:
    spec:
      template:
        spec:
          tolerations:
          - effect: NoExecute
            key: node.kubernetes.io/unreachable
            operator: Exists
            tolerationSeconds: 300
          - effect: NoExecute
            key: node.kubernetes.io/not-ready
            operator: Exists
            tolerationSeconds: 300
  typhaDeployment:
    spec:
      template:
        spec:
          tolerations:
          - effect: NoExecute
            key: node.kubernetes.io/unreachable
            operator: Exists
            tolerationSeconds: 300
          - effect: NoExecute
            key: node.kubernetes.io/not-ready
            operator: Exists
            tolerationSeconds: 300
```

## Solución de problemas de credenciales
<a name="hybrid-nodes-troubleshooting-creds"></a>

Tanto para las activaciones híbridas de AWS SSM como para AWS IAM Roles Anywhere, puede validar que las credenciales del rol de IAM de los Nodos híbridos estén configuradas correctamente en los nodos híbridos. Para ello, ejecute el siguiente comando desde los nodos híbridos. Confirme que el nombre del nodo y el nombre del rol de IAM de los Nodos híbridos son los esperados.

```
sudo aws sts get-caller-identity
```

```
{
    "UserId": "ABCDEFGHIJKLM12345678910:<node-name>",
    "Account": "<aws-account-id>",
    "Arn": "arn:aws:sts::<aws-account-id>:assumed-role/<hybrid-nodes-iam-role/<node-name>"
}
```

 ** AWS Solución problemas de Systems Manager (SSM** 

Si utiliza activaciones híbridas de AWS SSM para las credenciales de nodos híbridos, tenga en cuenta los siguientes directorios y artefactos de SSM que `nodeadm` instala en los nodos híbridos. Para obtener más información sobre el agente de SSM, consulte [Uso del agente de SSM](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html) en la *Guía del usuario de AWS Systems Manager*.


| Descripción | Ubicación | 
| --- | --- | 
|  Agente de SSM  |  Ubuntu: `/snap/amazon-ssm-agent/current/amazon-ssm-agent` RHEL y AL2023: `/usr/bin/amazon-ssm-agent`   | 
|  Registros de SSM Agent  |   `/var/log/amazon/ssm`   | 
|   AWSCredenciales de   |   `/root/.aws/credentials`   | 
|  CLI de configuración de SSM  |   `/opt/ssm/ssm-setup-cli`   | 

 **Reinicio del agente de SSM** 

Para resolver algunos problemas, se puede reiniciar el agente de SSM. Puede utilizar los comandos que aparecen a continuación para reiniciarlo.

 **AL2023 y otros sistemas operativos** 

```
systemctl restart amazon-ssm-agent
```

 **Ubuntu** 

```
systemctl restart snap.amazon-ssm-agent.amazon-ssm-agent
```

 **Compruebe la conectividad con los puntos de conexión de SSM** 

Confirme que se puede conectar a los puntos de conexión de SSM desde los nodos híbridos. Para obtener una lista de los puntos de conexión de SSM, consulte [Puntos de conexión y cuotas de AWS Systems Manager](https://docs.aws.amazon.com/general/latest/gr/ssm.html). Sustituya `us-west-2` en el comando que aparece a continuación por la región de AWS de activación híbrida de AWS SSM.

```
ping ssm.us-west-2.amazonaws.com
```

 **Visualización del estado de la conexión de las instancias de SSM registradas** 

Puede comprobar el estado de conexión de las instancias que están registradas en las activaciones híbridas de SSM con el siguiente comando de la AWS CLI. Sustituya el ID de máquina por el ID de máquina de la instancia.

```
aws ssm get-connection-status --target mi-012345678abcdefgh
```

 **Falta de coincidencia de la suma de comprobación de la CLI de configuración de SSM** 

Al ejecutar `nodeadm install`, si detecta un problema de falta de coincidencia de la suma de comprobación de `ssm-setup-cli`, deberá confirmar que no haya instalaciones de SSM más antiguas en el host. Si hay instalaciones de SSM antiguas en el host, elimínelas y vuelva a ejecutar `nodeadm install` para resolver el problema.

```
Failed to perform agent-installation/on-prem registration: error while verifying installed ssm-setup-cli checksum: checksum mismatch with latest ssm-setup-cli.
```

 **De SSM `InvalidActivation` ** 

Si aparece un error al registrar la instancia en AWS SSM, confirme que la `region`, `activationCode` y `activationId` en el `nodeConfig.yaml` son correctos. La región de AWS del clúster de EKS debe coincidir con la región de activación híbrida de SSM. Si estos valores están mal configurados, es posible que aparezca un error similar al siguiente.

```
ERROR Registration failed due to error registering the instance with AWS SSM. InvalidActivation
```

 **`ExpiredTokenException` de SSM: el token de seguridad incluido en la solicitud ha vencido** 

Si el agente de SSM no puede actualizar las credenciales, es posible que aparezca una `ExpiredTokenException`. En este escenario, si se puede conectar a los puntos de conexión de SSM desde los nodos híbridos, es posible que tenga que reiniciar el agente de SSM para forzar la actualización de credenciales.

```
"msg":"Command failed","error":"operation error SSM: DescribeInstanceInformation, https response error StatusCode: 400, RequestID: eee03a9e-f7cc-470a-9647-73d47e4cf0be, api error ExpiredTokenException: The security token included in the request is expired"
```

 **Error de SSM al ejecutar el comando de registro de la máquina** 

Si aparece un error al registrar la máquina en SSM, es posible que tenga que volver a ejecutar `nodeadm install` para asegurarse de que todas las dependencias de SSM están instaladas correctamente.

```
"error":"running register machine command: , error: fork/exec /opt/aws/ssm-setup-cli: no such file or directory"
```

 **De SSM `ActivationExpired` ** 

Al ejecutar `nodeadm init`, si aparece un error al registrar la instancia en SSM debido a que la activación ha caducado, tendrá que crear una nueva activación híbrida de SSM, actualizar `nodeConfig.yaml` con el `activationCode` y el `activationId` de la nueva activación híbrida de SSM y volver a ejecutar `nodeadm init`.

```
"msg":"Command failed","error":"SSM activation expired. Please use a valid activation"
```

```
ERROR Registration failed due to error registering the instance with AWS SSM. ActivationExpired
```

 **SSM no pudo actualizar las credenciales almacenadas en caché** 

Si se presenta un error al actualizar las credenciales almacenadas en caché, es posible que el archivo `/root/.aws/credentials` se haya eliminado del host. En primer lugar, compruebe la activación híbrida de SSM y asegúrese de que esté activa y de que los nodos híbridos estén configurados correctamente para utilizar la activación. Compruebe los registros del agente de SSM en `/var/log/amazon/ssm` y vuelva a ejecutar el comando `nodeadm init` una vez que haya resuelto el problema del SSM.

```
"Command failed","error":"operation error SSM: DescribeInstanceInformation, get identity: get credentials: failed to refresh cached credentials"
```

 **Limpie SSM** 

Para eliminar el agente de SSM del host, puede ejecutar los siguientes comandos.

```
dnf remove -y amazon-ssm-agent
sudo apt remove --purge amazon-ssm-agent
snap remove amazon-ssm-agent
rm -rf /var/lib/amazon/ssm/Vault/Store/RegistrationKey
```

 ** AWS Solución de problemas de IAM Roles Anywhere** 

Si utiliza AWS IAM Roles Anywhere para las credenciales de nodos híbridos, tenga en cuenta los siguientes directorios y artefactos que `nodeadm` instala en los nodos híbridos. Para obtener más información sobre la solución de problemas de IAM Roles Anywhere, consulte [Solución de problemas de identidad y acceso de AWS IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/security_iam_troubleshoot.html) en la Guía del usuario de *AWS IAM Roles Anywhere*.


| Descripción | Ubicación | 
| --- | --- | 
|  CLI de IAM Roles Anywhere  |   `/usr/local/bin/aws_signing_helper`   | 
|  Ubicación y nombre predeterminados del certificado  |   `/etc/iam/pki/server.pem`   | 
|  Ubicación y nombre predeterminados de la clave  |   `/etc/iam/pki/server.key`   | 

 **IAM Roles Anywhere no pudo volver a refrescar las credenciales almacenadas en caché** 

Si detecta un error al refrescar las credenciales almacenadas en caché, revise el contenido de `/etc/aws/hybrid/config` y confirme que IAM Roles Anywhere se ha configurado correctamente en la configuración de `nodeadm`. Confirme que `/etc/iam/pki` existe. Cada nodo debe tener un certificado y una clave únicos. De forma predeterminada, cuando se utiliza IAM Roles Anywhere como proveedor de credenciales, `nodeadm` utiliza `/etc/iam/pki/server.pem` para la ubicación y el nombre del certificado, y `/etc/iam/pki/server.key` para la clave privada. Es posible que tenga que crear los directorios antes de colocar los certificados y las claves en los directorios con `sudo mkdir -p /etc/iam/pki`. Puede comprobar el contenido del certificado con el siguiente comando.

```
openssl x509 -text -noout -in server.pem
```

```
open /etc/iam/pki/server.pem: no such file or directory
could not parse PEM data
Command failed {"error": "... get identity: get credentials: failed to refresh cached credentials, process provider error: error in credential_process: exit status 1"}
```

 **IAM Roles Anywhere no está autorizado para realizar `sts:AssumeRole` ** 

Si se presenta un problema de acceso denegado en los registros de `kubelet` para la operación `sts:AssumeRole` al utilizar IAM Roles Anywhere, compruebe la política de confianza del rol de IAM de Nodos híbridos para confirmar que la entidad principal del servicio de IAM Roles Anywhere puede asumir el rol de IAM de Nodos híbridos. Además, confirme que el ARN del anclaje de veracidad esté configurado correctamente en la política de confianza del rol de IAM de Nodos híbridos y que el rol de IAM de Nodos híbridos se haya agregado al perfil de IAM Roles Anywhere.

```
could not get token: AccessDenied: User: ... is not authorized to perform: sts:AssumeRole on resource: ...
```

 **IAM Roles Anywhere no está autorizado para definir `roleSessionName` ** 

Si se presenta un problema de acceso denegado en los registros de `kubelet` al configurar el `roleSessionName`, confirme que `acceptRoleSessionName` se ha establecido en verdadero para el perfil de IAM Roles Anywhere.

```
AccessDeniedException: Not authorized to set roleSessionName
```

## Solución de problemas del sistema operativo
<a name="hybrid-nodes-troubleshooting-os"></a>

### RHEL
<a name="_rhel"></a>

 **Fallos en el registro del administrador de derechos o suscripciones** 

Si ejecuta `nodeadm install` y se produce un error al instalar las dependencias de los nodos híbridos debido a problemas de registro de derechos, asegúrese de haber configurado correctamente el nombre de usuario y la contraseña de Red Hat en el host.

```
This system is not registered with an entitlement server
```

### Ubuntu
<a name="_ubuntu"></a>

 **No se encontró GLIBC** 

Si utiliza Ubuntu para el sistema operativo e IAM Roles Anywhere para el proveedor de credenciales con nodos híbridos y se presenta el problema de que no se encontró GLIBC, puede instalar esa dependencia manualmente para resolver el problema.

```
GLIBC_2.32 not found (required by /usr/local/bin/aws_signing_helper)
```

Ejecute los siguientes comandos para instalar la dependencia.

```
ldd --version
sudo apt update && apt install libc6
sudo apt install glibc-source
```

### Bottlerocket
<a name="_bottlerocket"></a>

Si tiene activado el contenedor de administración de Bottlerocket, puede acceder a este mediante SSH para realizar tareas avanzadas de depuración y resolución de problemas con privilegios elevados. Las siguientes secciones contienen comandos que se deben ejecutar en el contexto del host de Bottlerocket. Una vez que esté en el contenedor de administración, puede ejecutar `sheltie` para obtener un intérprete de comandos raíz completo en el host de Bottlerocket.

```
sheltie
```

Para ejecutar los comandos de las siguientes secciones desde el intérprete de comandos del contenedor de administración, también puede agregar el prefijo `sudo chroot /.bottlerocket/rootfs` a cada comando.

```
sudo chroot /.bottlerocket/rootfs <command>
```

 **Cómo utilizar logdog en la recopilación de registros** 

Bottlerocket proporciona la utilidad `logdog` para recopilar de manera eficiente los registros y la información del sistema con fines de resolución de problemas.

```
logdog
```

La utilidad `logdog` recopila registros de varias ubicaciones en un host de Bottlerocket y los combina en un archivo tarball. De forma predeterminada, el archivo tarball se creará en `/var/log/support/bottlerocket-logs.tar.gz`, y se podrá acceder a este desde los contenedores del host en `/.bottlerocket/support/bottlerocket-logs.tar.gz`.

 **Cómo acceder a los registros del sistema con journalctl** 

Puede utilizar los siguientes comandos para comprobar el estado de los distintos servicios del sistema, como `kubelet` o `containerd`, entre otros, así como para ver sus registros. La marca `-f` seguirá los registros en tiempo real.

Para comprobar el estado del servicio `kubelet` y recuperar los registros de `kubelet`, puede ejecutar:

```
systemctl status kubelet
journalctl -u kubelet -f
```

Para comprobar el estado del servicio `containerd` y recuperar los registros de la instancia orquestada de `containerd`, puede ejecutar:

```
systemctl status containerd
journalctl -u containerd -f
```

Para comprobar el estado del servicio `host-containerd` y recuperar los registros de la instancia host de `containerd`, puede ejecutar:

```
systemctl status host-containerd
journalctl -u host-containerd -f
```

Para recuperar los registros de los contenedores de arranque y los contenedores host, puede ejecutar:

```
journalctl _COMM=host-ctr -f
```