**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.
# Automatización de la infraestructura de clústeres con el modo automático de EKS
**sugerencia**
[Regístrese](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) en los próximos talleres del modo automático de EKS.
El modo automático de EKS amplía la administración de AWS de los clústeres de Kubernetes más allá del propio clúster, para permitir que AWS también configure y administre la infraestructura que permite el buen funcionamiento de las cargas de trabajo. Puede delegar decisiones clave de infraestructura y aprovechar la experiencia y los conocimientos de AWS para las operaciones cotidianas. La infraestructura de clúster administrada por AWS incluye numerosas capacidades de Kubernetes como componentes principales, en lugar de complementos, como el escalado automático de computación, las redes de pods y servicios, el equilibrio de carga de aplicaciones, el DNS de clúster, el almacenamiento en bloque y la compatibilidad con GPU.
Para comenzar, puede implementar un nuevo clúster de modo automático de EKS o habilitar el modo automático de EKS en un clúster existente. Puede implementar, actualizar o modificar los clústeres del modo automático de EKS mediante eksctl, la AWS CLI, la Consola de administración de AWS, las API de EKS o las herramientas de infraestructura como código que prefiera.
Con el modo automático de EKS, aún podrá utilizar las herramientas compatibles con Kubernetes que prefiera. El modo automático de EKS se integra con servicios de AWS, como Amazon EC2, Amazon EBS y ELB, y aprovecha los recursos en la nube AWS que siguen las prácticas recomendadas. Estos recursos se escalan automáticamente, se optimizan en costos y se actualizan periódicamente para ayudar a minimizar los costos operativos y los gastos generales.
## Características
El modo automático de EKS ofrece las siguientes características de alto nivel:
**Optimización de la administración de clústeres de Kubernetes**: el modo automático de EKS optimiza la administración de EKS al proporcionar clústeres listos para la producción con una sobrecarga operativa mínima. Con el modo automático de EKS, puede ejecutar cargas de trabajo exigentes y dinámicas con confianza, sin necesidad de tener conocimientos profundos sobre EKS.
**Disponibilidad de las aplicaciones**: El modo automático de EKS agrega o elimina nodos dinámicamente en el clúster de EKS en función de la demanda de las aplicaciones de Kubernetes. Esto minimiza la necesidad de planificar manualmente la capacidad y garantiza la disponibilidad de las aplicaciones.
**Eficiencia**: el modo automático de EKS se diseñó para optimizar los costos de computación a la vez que se adhiere a la flexibilidad definida por el NodePool y los requisitos de la carga de trabajo. Además, termina las instancias que no se utilizan y consolida las cargas de trabajo en otros nodos con el fin de mejorar la rentabilidad.
**Seguridad**: el modo automático de EKS utiliza AMI que se tratan como inmutables para los nodos. Estas AMI aplican software bloqueado, habilitan controles de acceso obligatorios SELinux y proporcionan sistemas de archivos raíz de solo lectura. Además, los nodos lanzados por el modo automático de EKS tienen una vida útil máxima de 21 días (que se puede reducir), tras lo cual se sustituyen automáticamente por nuevos nodos. Este enfoque mejora la postura de seguridad mediante la rotación periódica de los nodos, en línea con las prácticas recomendadas ya adoptadas por un gran número de clientes.
**Actualizaciones automatizadas**: el modo automático de EKS mantiene actualizados el clúster de Kubernetes, los nodos y los componentes relacionados con las revisiones más recientes, a la vez que respeta los presupuestos de interrupción de pods (PDB) y los presupuestos de interrupción de NodePool (NDB) configurados. Es posible que sea necesario intervenir hasta los 21 días de vida útil máxima si los presupuestos de interrupción de pods de bloqueo u otras configuraciones impiden las actualizaciones.
**Componentes administrados**: el modo automático de EKS incluye Kubernetes y características en la nube de AWS como componentes principales que, de otro modo, tendrían que administrarse como complementos. Esto incluye soporte integrado para asignaciones de direcciones IP de pods, políticas de red de pods, servicios de DNS locales, complementos de GPU, comprobadores de estado y almacenamiento EBS CSI.
**NodePools y NodeClasses personalizables**: si la carga de trabajo requiere cambios en las configuraciones de almacenamiento, computación o redes, puede crear NodePools y NodeClasses personalizados mediante el modo automático de EKS. Si bien no se deben editar los NodePools y NodeClasses predeterminados, puede agregar nuevos NodePools o NodeClasses personalizados junto con las configuraciones predeterminadas para satisfacer requisitos específicos.
## Componentes automatizados
El modo automático de EKS optimiza el funcionamiento de los clústeres de Amazon EKS mediante la automatización de los componentes clave de la infraestructura. La habilitación del modo automático de EKS reduce aún más las tareas de administración de los clústeres de EKS.
A continuación, se enumeran los componentes del plano de datos que están automatizados:
+ **Computación**: en el caso de muchas cargas de trabajo, gracias al modo automático de EKS, se podrá desentender de muchos aspectos de la computación de los clústeres de EKS. Entre ellos se incluyen:
+ **Nodos**: los nodos del modo automático de EKS se diseñaron para ser tratados como aparatos. El modo automático de EKS se encarga de lo siguiente:
+ Elige una AMI adecuada que esté configurada con numerosos servicios necesarios para ejecutar las cargas de trabajo sin intervención.
+ Restringe el acceso a los archivos en la AMI mediante el modo de aplicación forzada de SELinux y un sistema de archivos raíz en modo solo lectura.
+ Impide el acceso directo a los nodos mediante la denegación de acceso SSH o SSM.
+ Incluye compatibilidad con GPU, a través de complementos y controladores de kernel independientes para GPU NVIDIA y Neuron, con lo que se consiguen cargas de trabajo de alto rendimiento.
+ Gestiona automáticamente los [avisos de interrupción de las instancias de spot de EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html) y los eventos de estado de las instancias de EC2
+ **Escalado automático**: al basarse en el escalado automático de [Karpenter](https://karpenter.sh/docs/), el modo automático de EKS supervisa los pods no programables y hace posible que se implementen nuevos nodos para ejecutar esos pods. A medida que se terminan las cargas de trabajo, el modo automático de EKS interrumpe y termina dinámicamente los nodos cuando dejan de ser necesarios, lo que optimiza el uso de los recursos.
+ **Actualizaciones**: al tener el control sobre los nodos, se agiliza la capacidad del modo automático de EKS a la hora de proporcionar revisiones de seguridad y actualizaciones tanto del sistema operativo como de los componentes, según sea necesario. Estas actualizaciones se diseñaron para minimizar las interrupciones de las cargas de trabajo. El modo automático de EKS impone una vida útil máxima del nodo de 21 días para garantizar que el software y las API se mantengan actualizados.
+ **Equilibrio de carga**: el modo automático de EKS agiliza el equilibrio de carga mediante la integración con el servicio Elastic Load Balancing de Amazon, con lo que se automatiza el aprovisionamiento y la configuración de los equilibradores de carga para los servicios Kubernetes y los recursos de Ingress. Admite características avanzadas para los equilibradores de carga de aplicaciones y de red, administra su ciclo de vida y los escala para satisfacer las demandas de los clústeres. Esta integración aporta una solución de equilibrio de carga lista para producción que se adhiere a las prácticas recomendadas de AWS, con lo que es posible centrarse en las aplicaciones en lugar de en la administración de la infraestructura.
+ **Almacenamiento**: el modo automático de EKS configura el almacenamiento efímero en su nombre y configura los tipos y tamaños de los volúmenes, las políticas de cifrado y las políticas de eliminación tras la terminación del nodo.
+ **Redes**: el modo automático de EKS automatiza las tareas críticas de red para la conectividad de los pods y los servicios. Esto incluye la compatibilidad con IPv4/IPv6 y el uso de bloques de CIDR secundarios para ampliar los espacios de direcciones IP.
+ **Administración de identidades y accesos**: no es necesario instalar el agente de Pod Identity de EKS en los clústeres del modo automático de EKS.
Para obtener más información sobre estas propiedades, consulte [Más información sobre cómo funciona el modo automático de EKS](auto-reference.md).
## Configuración
Aunque el modo automático de EKS administrará eficazmente la mayoría de los servicios del plano de datos sin necesidad de que intervenga, es posible que en ocasiones desee cambiar el modo en que se comportan algunos de esos servicios. Puede modificar la configuración de los clústeres del modo automático de EKS de las siguientes maneras:
+ **Daemonsets de Kubernetes**: en lugar de modificar los servicios instalados en los nodos, puede utilizar DaemonSets de Kubernetes. Los Daemonsets se diseñaron para ser administrados por Kubernetes, pero se ejecutan en cada nodo del clúster. De este modo, puede agregar servicios especiales para supervisar o vigilar los nodos de otro modo.
+ **NodePools y NodeClasses personalizados**: los NodePools y NodeClasses predeterminados son configurados por el modo automático de EKS y no se deben editar. Para personalizar el comportamiento de los nodos, se pueden crear NodePools o NodeClasses adicionales para casos de uso como:
+ Selección de tipos de instancia específicos (por ejemplo, procesadores acelerados o instancias de spot de EC2).
+ Aislar cargas de trabajo por motivos de seguridad o seguimiento de costos.
+ Configuración de ajustes de almacenamiento efímero, como IOPS, tamaño y rendimiento.
+ **Equilibrio de carga**: algunos servicios, como el equilibrio de carga, que el modo automático de EKS ejecuta como objetos de Kubernetes, se pueden configurar directamente en los clústeres del modo automático de EKS.
Para obtener más información sobre las opciones de configuración del modo automático de EKS, consulte [Configuración de los ajustes del modo automático de EKS](settings-auto.md).
## Modelo de responsabilidad compartida
El modelo de responsabilidad compartida de AWS define las responsabilidades de seguridad y cumplimiento entre AWS y los clientes. Las imágenes y el texto que aparecen a continuación comparan y contrastan cómo difieren las responsabilidades del cliente y de AWS entre el modo automático de EKS y el modo estándar de EKS.
![\[Modelo de responsabilidad compartida con el modo automático y el modo estándar de EKS\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/eksautosrm.png)
El modo automático de EKS transfiere gran parte de la responsabilidad compartida de la infraestructura de Kubernetes de los clientes a AWS. Con el modo automático de EKS, AWS asume una mayor responsabilidad por la seguridad de la nube, que antes era responsabilidad del cliente y ahora es compartida. Los clientes ahora pueden centrarse más en sus aplicaciones mientras AWS administra la infraestructura subyacente.
**Responsabilidad del cliente**
Con el modo automático de EKS, los clientes siguen siendo responsables de los contenedores de aplicaciones, incluida la disponibilidad, la seguridad y la supervisión. También mantienen el control sobre la infraestructura de VPC y la configuración del clúster de EKS. Este modelo permite a los clientes concentrarse en las preocupaciones específicas de la aplicación mientras delegan la administración de la infraestructura del clúster a AWS. Las características opcionales por nodo se pueden incluir en los clústeres mediante complementos de AWS.
** AWS Responsabilidad de**
Con el modo automático de EKS, AWS amplía su responsabilidad para incluir la administración de varios componentes críticos adicionales, en comparación con los que ya se administraban en los clústeres de EKS que no utilizan el modo automático. En concreto, el modo automático de EKS se encarga de la configuración, la administración, la seguridad y el escalado de las instancias de EC2 lanzadas, así como de las capacidades de los clústeres para el equilibrio de carga, la administración de direcciones IP, la política de redes y el almacenamiento en bloque. AWS administra los siguientes componentes en el modo automático de EKS:
+ **Instancias de EC2 lanzadas en el modo automático**: AWS gestiona el ciclo de vida completo de los nodos al aprovechar las instancias administradas por Amazon EC2. Las instancias administradas de EC2 asumen la responsabilidad de la configuración, la aplicación de parches, la supervisión y el mantenimiento del estado del sistema operativo. En este modelo, AWS es responsable tanto de la propia instancia como del sistema operativo huésped que se ejecuta en ella. Los nodos utilizan variantes de las AMI de [Bottlerocket](https://aws.amazon.com/bottlerocket) optimizadas para ejecutar contenedores. Las AMI de Bottlerocket tienen un software bloqueado, sistemas de archivos raíz inmutables y un acceso seguro a la red (para evitar las comunicaciones directas a través de SSH o SSM).
+ **Capacidades de clúster**: AWS administra el escalado automático de cómputo, las redes de pods con la aplicación de políticas de red, la integración de Elastic Load Balancing y la configuración de los controladores de almacenamiento.
+ **Plano de control de los clústeres**: AWS sigue administrando el servidor de la API de Kubernetes, los ENI multicuenta y la base de datos etcd, como ocurre con el EKS estándar.
+ **Servicios básicos e infraestructura global**: AWS conserva la responsabilidad de los servicios subyacentes de computación, almacenamiento, redes y supervisión, así como de la infraestructura global de regiones, zonas locales y ubicaciones periféricas.
# Cómo crear un clúster con el modo automático de Amazon EKS
En este capítulo se describe cómo crear un clúster de Amazon EKS con el modo automático habilitado mediante diversas herramientas e interfaces. El modo automático simplifica la creación de clústeres al configurar y administrar automáticamente la infraestructura de computación, redes y almacenamiento del clúster. Aprenderá a crear un clúster del modo automático mediante la AWS CLI, la Consola de administración de AWS o la herramienta de línea de comandos eksctl.
**nota**
El modo automático de EKS requiere la versión 1.29 o superior de Kubernetes.
Elija la herramienta que mejor se adapte a sus necesidades: la Consola de administración de AWS proporciona una interfaz visual ideal para explorar las características del modo automático de EKS y crear clústeres individuales. AWS CLI es ideal para tareas de creación de scripts y automatización, especialmente al integrar la creación de clústeres en flujos de trabajo existentes o en canalizaciones de CI/CD. La CLI de eksctl ofrece una experiencia nativa de Kubernetes y se recomienda para usuarios familiarizados con las herramientas de Kubernetes que deseen realizar operaciones simplificadas en la línea de comandos con configuraciones predeterminadas adecuadas.
Antes de comenzar, asegúrese de tener instalados y configurados los requisitos previos necesarios, incluidos los permisos de IAM correspondientes para crear clústeres de EKS. Para obtener información sobre cómo instalar herramientas de CLI, como `kubectl``aws` y `eksctl`, consulte [Configuración para usar Amazon EKS](setting-up.md).
Puede usar la AWS CLI, la Consola de administración de AWS o la CLI de eksctl para crear un clúster con el modo automático de Amazon EKS.
**Topics**
+ [Creación de un clúster de modo automático de EKS con la CLI de eksctl](automode-get-started-eksctl.md)
+ [Cómo crear un clúster de modo automático de EKS con AWS CLI](automode-get-started-cli.md)
+ [Creación de un clúster del modo automático de EKS con la Consola de administración de AWS](automode-get-started-console.md)
# Creación de un clúster de modo automático de EKS con la CLI de eksctl
En este tema se muestra cómo crear un clúster de modo automático de Amazon EKS mediante la interfaz de la línea de comandos (CLI) de eksctl. Puede crear un clúster de modo automático o bien mediante la ejecución de un único comando de la CLI o a través de la aplicación de un archivo de configuración YAML. Ambos métodos ofrecen la misma funcionalidad, aunque el enfoque YAML ofrece un control más detallado de la configuración del clúster.
La CLI de eksctl simplifica el proceso de creación y administración de clústeres de modo automático de EKS al encargarse de la creación y configuración de los recursos de AWS subyacentes. Antes de continuar, asegúrese de que cuenta con las credenciales y permisos de AWS necesarios configurados en la máquina local. En esta guía se presupone que conoce los conceptos básicos de Amazon EKS y que ya ha instalado las herramientas de la CLI necesarias.
**nota**
Debe instalar la versión `0.195.0` o superior de eksctl. Para obtener más información, consulte [Versiones de eksctl](https://github.com/eksctl-io/eksctl/releases) en GitHub.
## Creación de un clúster de modo automático de EKS con un comando de la CLI
Debe tener las herramientas `aws` y `eksctl` instaladas. Debe iniciar sesión en AWS CLI con permisos suficientes para administrar recursos de AWS, incluidos: instancias de EC2, redes de EC2, clústeres de EKS y roles de IAM. Para obtener más información, consulte [Configuración para usar Amazon EKS](setting-up.md).
Ejecute el siguiente comando para crear un nuevo clúster de modo automático de EKS con
```
eksctl create cluster --name= --enable-auto-mode
```
## Creación de un clúster de modo automático de EKS con un archivo YAML
Debe tener las herramientas `aws` y `eksctl` instaladas. Debe iniciar sesión en AWS CLI con permisos suficientes para administrar recursos de AWS, incluidos: instancias de EC2, redes de EC2, clústeres de EKS y roles de IAM. Para obtener más información, consulte [Configuración para usar Amazon EKS](setting-up.md).
Revise las opciones de configuración del modo automático de EKS en el recurso ClusterConfig de ejemplo que aparece a continuación. Para conocer la especificación completa de ClusterConfig, consulte la [documentación de eksctl](https://eksctl.io/usage/creating-and-managing-clusters/).
AWS sugiere habilitar el modo automático de EKS. Si es la primera vez que crea un clúster de modo automático de EKS, deje el `nodeRoleARN` sin especificar para crear un rol de IAM de nodo para el modo automático de EKS. Si ya tiene un rol de IAM de nodo en la cuenta de AWS, AWS sugiere que se vuelva a utilizar.
AWS sugiere no especificar ningún valor para `nodePools`. El modo automático de EKS creará grupos de nodos predeterminados. Puede utilizar la API de Kubernetes para crear grupos de nodos adicionales.
```
# cluster.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name:
region:
iam:
# ARN of the Cluster IAM Role
# optional, eksctl creates a new role if not supplied
# suggested to use one Cluster IAM Role per account
serviceRoleARN:
autoModeConfig:
# defaults to false
enabled: boolean
# optional, defaults to [general-purpose, system].
# suggested to leave unspecified
# To disable creation of nodePools, set it to the empty array ([]).
nodePools: []string
# optional, eksctl creates a new role if this is not supplied
# and nodePools are present.
nodeRoleARN: string
```
Guarde el archivo `ClusterConfig` como `cluster.yaml` y use el siguiente comando para crear el clúster:
```
eksctl create cluster -f cluster.yaml
```
# Cómo crear un clúster de modo automático de EKS con AWS CLI
Los clústeres del modo automático de EKS automatizan las tareas rutinarias de administración de clústeres para computación, almacenamiento y redes. Por ejemplo, los clústeres del modo automático de EKS detectan automáticamente cuándo se necesitan nodos adicionales y aprovisionan nuevas instancias de EC2 a fin de satisfacer las demandas de la carga de trabajo.
En este tema se ofrece orientación para crear un nuevo clúster de modo automático de EKS mediante AWS CLI y, opcionalmente, implementar una carga de trabajo de muestra.
## Requisitos previos
+ 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`. Para instalar la versión más reciente, consulte [Instalación](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) y [Configuración rápida con aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config) en la Guía del usuario de la interfaz de la línea de comandos de AWS.
+ Inicie sesión en la CLI con permisos de IAM suficientes para crear recursos de AWS, como políticas de IAM, roles de IAM y clústeres de EKS.
+ La herramienta de línea de comandos kubectl instalada en el dispositivo. AWS sugiere que utilice la misma versión de kubectl que la versión de Kubernetes del clúster de EKS. Para instalar o actualizar kubectl, consulte [Configuración de `kubectl` y `eksctl`](install-kubectl.md).
## Cómo especificar las subredes de la VPC
El modo automático de Amazon EKS implementa nodos en las subredes de la VPC. Al crear un clúster de EKS, debe especificar las subredes de la VPC en las que se implementarán los nodos. Puede utilizar las subredes de la VPC predeterminadas en la cuenta de AWS o crear una VPC dedicada para cargas de trabajo críticas.
+ AWS sugiere crear una VPC dedicada para el clúster. Información sobre cómo [Creación de una Amazon VPC para su clúster de Amazon EKS](creating-a-vpc.md).
+ La consola de EKS ayuda a crear una nueva VPC. Información sobre cómo [Creación de un clúster del modo automático de EKS con la Consola de administración de AWS](automode-get-started-console.md).
+ Como alternativa, puede utilizar la VPC predeterminada de la cuenta de AWS. Siga las siguientes instrucciones para encontrar los ID de subred.
### Para encontrar los ID de subred de la VPC predeterminada
**Uso de AWS CLI:**
1. Ejecute el siguiente comando para enumerar la VPC predeterminada y sus subredes:
```
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$(aws ec2 describe-vpcs --query 'Vpcs[?IsDefault==`true`].VpcId' --output text)" --query 'Subnets[*].{ID:SubnetId,AZ:AvailabilityZone}' --output table
```
1. Guarde el resultado y anote los **ID de subred**.
Código de salida de ejemplo:
```
----------------------------------------
| DescribeSubnets |
----------------------------------------
| SubnetId | AvailabilityZone |
|--------------------|---------------------|
| subnet-012345678 | us-west-2a |
| subnet-234567890 | us-west-2b |
| subnet-345678901 | us-west-2c |
----------------------------------------
```
## Roles de IAM para clústeres de modo automático de EKS
### Rol de IAM de clúster
El modo automático de EKS requiere un rol de IAM de clúster para realizar acciones en la cuenta de AWS, como el aprovisionamiento de nuevas instancias de EC2. Debe crear este rol para conceder a EKS los permisos necesarios. AWS recomienda asociar las siguientes políticas administradas de AWS al rol de IAM del clúster:
+ [AmazonEKSComputePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy)
+ [AmazonEKSBlockStoragePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)
+ [AmazonEKSLoadBalancingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)
+ [AmazonEKSNetworkingPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)
+ [AmazonEKSClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy)
### Rol de IAM del nodo
Al crear un clúster de modo automático de EKS, se especifica un rol de IAM del nodo. Cuando el modo automático de EKS crea nodos para procesar cargas de trabajo pendientes, a cada nuevo nodo de instancia de EC2 se le asigna el rol de IAM del nodo. Este rol permite que el nodo se comunique con EKS, pero generalmente las cargas de trabajo que se ejecutan en el nodo no acceden a este.
Si desea conceder permisos a las cargas de trabajo que se ejecutan en un nodo, utilice EKS Pod Identity. Para obtener más información, consulte [Más información sobre cómo Pod Identity de EKS concede a los pods acceso a los servicios de AWS](pod-identities.md).
Debe crear este rol y asociar la siguiente política administrada de AWS:
+ [AmazonEKSWorkerNodeMinimalPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)
+ [AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly)
El modo automático de EKS también requiere un rol vinculado al servicio, que AWS crea y configura automáticamente. Para obtener más información, consulte [AWSServiceRoleForAmazonEKS](using-service-linked-roles-eks.md).
## Cómo crear un rol de IAM de clúster de modo automático de EKS
### Paso 1: Creación de la política de confianza
Cree una política de confianza que permita al servicio de Amazon EKS asumir el rol. Guarde la política como `trust-policy.json`:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
### Paso 2: Creación del rol de IAM
Utilice la política de confianza para crear el rol de IAM del clúster:
```
aws iam create-role \
--role-name AmazonEKSAutoClusterRole \
--assume-role-policy-document file://trust-policy.json
```
### Paso 3: Cómo anotar el ARN del rol
Recupere y guarde el ARN del nuevo rol para utilizarlo en pasos posteriores:
```
aws iam get-role --role-name AmazonEKSAutoClusterRole --query "Role.Arn" --output text
```
### Paso 4: Asociación de las políticas requeridas
Asocie las siguientes políticas administradas por AWS al rol de IAM del clúster para conceder los permisos necesarios:
**AmazonEKSClusterPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
```
**AmazonEKSComputePolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSComputePolicy
```
**AmazonEKSBlockStoragePolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSBlockStoragePolicy
```
**AmazonEKSLoadBalancingPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSLoadBalancingPolicy
```
**AmazonEKSNetworkingPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSNetworkingPolicy
```
## Cómo crear un rol de IAM de nodo del modo automático de EKS
### Paso 1: Creación de la política de confianza
Cree una política de confianza que permita al servicio de Amazon EKS asumir el rol. Guarde la política como `node-trust-policy.json`:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
#### Paso 2: Creación del rol de IAM del nodo
Utilice el archivo **node-trust-policy.json** del paso anterior para definir qué entidades pueden asumir el rol. Ejecute el siguiente comando para crear el rol de IAM del nodo:
```
aws iam create-role \
--role-name AmazonEKSAutoNodeRole \
--assume-role-policy-document file://node-trust-policy.json
```
#### Paso 3: Cómo anotar el ARN del rol
Después de crear el rol, recupere y guarde el ARN del rol de IAM del nodo. Necesitará este ARN en los pasos siguientes. Utilice el siguiente comando para obtener el ARN:
```
aws iam get-role --role-name AmazonEKSAutoNodeRole --query "Role.Arn" --output text
```
#### Paso 4: Asociación de las políticas requeridas
Asocie las siguientes políticas administradas por AWS al rol de IAM del nodo para proporcionar los permisos necesarios:
**AmazonEKSWorkerNodeMinimalPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodeMinimalPolicy
```
**AmazonEC2ContainerRegistryPullOnly**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly
```
## Cómo crear un clúster de modo automático de EKS
### Descripción general
Para crear un clúster de modo automático de EKS mediante AWS CLI, necesitará los siguientes parámetros:
+ `cluster-name`: el nombre del clúster.
+ `k8s-version`: la versión de Kubernetes (p. ej., 1.31).
+ `subnet-ids`: los ID de subred identificados en los pasos anteriores.
+ `cluster-role-arn`: ARN del rol de IAM del clúster.
+ `node-role-arn`: ARN del rol de IAM del nodo.
#### Configuraciones de clúster predeterminadas
Revise las características y los valores predeterminados antes de crear el clúster:
+ `nodePools`: el modo automático de EKS incluye grupos de nodos de uso general y predeterminados del sistema. Más información sobre los [grupos de nodos](create-node-pool.md).
**Nota:** Los grupos de nodos del modo automático de EKS se diferencian de los grupos de nodos administrados de Amazon EKS, pero pueden coexistir en el mismo clúster.
+ `computeConfig.enabled`: automatiza las tareas de computación rutinarias, como la creación y eliminación de instancias de EC2.
+ `kubernetesNetworkConfig.elasticLoadBalancing.enabled`: automatiza las tareas de equilibrio de carga, incluida la creación y eliminación de equilibradores de carga elásticos.
+ `storageConfig.blockStorage.enabled`: automatiza las tareas de almacenamiento, como la creación y eliminación de volúmenes de Amazon EBS.
+ `accessConfig.authenticationMode`: requiere entradas de acceso de EKS. Más información sobre los [modos de autenticación de EKS](grant-k8s-access.md).
#### Ejecute el comando
Utilice el siguiente comando para crear el clúster:
```
aws eks create-cluster \
--region ${AWS_REGION} \
--cli-input-json \
"{
\"name\": \"${CLUSTER_NAME}\",
\"version\": \"${K8S_VERSION}\",
\"roleArn\": \"${CLUSTER_ROLE_ARN}\",
\"resourcesVpcConfig\": {
\"subnetIds\": ${SUBNETS_JSON},
\"endpointPublicAccess\": true,
\"endpointPrivateAccess\": true
},
\"computeConfig\": {
\"enabled\": true,
\"nodeRoleArn\":\"${NODE_ROLE_ARN}\",
\"nodePools\": [\"general-purpose\", \"system\"]
},
\"kubernetesNetworkConfig\": {
\"elasticLoadBalancing\": {
\"enabled\": true
}
},
\"storageConfig\": {
\"blockStorage\": {
\"enabled\": true
}
},
\"accessConfig\": {
\"authenticationMode\": \"API\"
}
}"
```
### Cómo comprobar el estado del clúster
#### Paso 1: Comprobación de la creación del clúster
Ejecute el siguiente comando para comprobar el estado del clúster. La creación del clúster generalmente tarda unos 15 minutos:
```
aws eks describe-cluster --name "${CLUSTER_NAME}" --output json
```
#### Paso 2: Actualización de kubeconfig
Una vez que el clúster esté listo, actualice el archivo kubeconfig local para permitir que `kubectl` se comunique con el clúster. Esta configuración utiliza AWS CLI para la autenticación.
```
aws eks update-kubeconfig --name "${CLUSTER_NAME}"
```
#### Paso 3: Verificación de los grupos de nodos
Enumere los grupos de nodos del clúster con el siguiente comando:
```
kubectl get nodepools
```
## Siguientes pasos
+ Aprenda a [implementar una carga de trabajo de muestra](automode-workload.md) en el nuevo clúster de modo automático de EKS.
# Creación de un clúster del modo automático de EKS con la Consola de administración de AWS
La creación de un clúster del modo automático de EKS en la Consola de administración de AWS requiere menos configuración que otras opciones. EKS se integra con AWS IAM y las redes de VPC para ayudar a crear los recursos asociados a un clúster de EKS.
Existen dos opciones para crear un clúster en la consola:
+ Configuración rápida (con el modo automático de EKS)
+ Configuración personalizada
En este tema, aprenderá a crear un clúster de modo automático de EKS mediante la opción de configuración rápida.
## Creación de un modo automático de EKS mediante la opción de configuración rápida
Debe iniciar sesión en la Consola de administración de AWS con permisos suficientes para administrar recursos de AWS, incluidos los siguientes: instancias de EC2, redes de EC2, clústeres de EKS y roles de IAM.
1. Vaya a la consola de EKS
1. Haga clic en **Crear clúster**
1. **Confirme que la opción de configuración rápida esté seleccionada**
1. Determine los siguientes valores o utilice los valores predeterminados para un clúster de prueba.
+ **Nombre** del clúster
+ Versión de Kubernetes
1. Seleccione el rol IAM del clúster. Si es la primera vez que crea un clúster de modo automático de EKS, utilice la opción **Crear rol recomendado**.
+ Opcionalmente, puede volver a utilizar un único rol de IAM de clúster en la cuenta de AWS para todos los clústeres de modo automático de EKS.
+ El rol de IAM de clúster incluye los permisos necesarios para que el modo automático de EKS administre los recursos, incluidas las instancias de EC2, los volúmenes de EBS y los equilibradores de carga de EC2.
+ La opción **Crear rol recomendado** completa previamente todos los campos con valores recomendados. Seleccione **Siguiente** y, a continuación, **Crear**. El rol usará el nombre de `AmazonEKSAutoClusterRole` sugerido.
+ Si ha creado recientemente un nuevo rol, utilice el icono **Actualizar** para recargar el menú desplegable de selección de roles.
1. Seleccione el rol de IAM del nodo. Si es la primera vez que crea un clúster de modo automático de EKS, utilice la opción **Crear rol recomendado**.
+ Opcionalmente, puede volver a utilizar un único rol de IAM de nodo en la cuenta de AWS para todos los clústeres de modo automático de EKS.
+ El rol de IAM de nodo incluye los permisos necesarios para que los nodos del modo automático se conecten al clúster. El rol de IAM del nodo debe incluir permisos para recuperar imágenes de ECR para los contenedores.
+ La opción **Crear rol recomendado** completa previamente todos los campos con valores recomendados. Seleccione **Siguiente** y, a continuación, **Crear**. El rol usará el nombre de `AmazonEKSAutoNodeRole` sugerido.
+ Si ha creado recientemente un nuevo rol, utilice el icono **Actualizar** para recargar el menú desplegable de selección de roles.
1. Seleccione la VPC para el clúster de modo automático de EKS. Elija **Crear VPC** para crear una nueva VPC para EKS, o elija una VPC que haya creado previamente para EKS.
+ Si utiliza la Consola de la VPC para crear una nueva VPC, AWS sugiere crear al menos una puerta de enlace NAT por zona de disponibilidad. De lo contrario, puede utilizar todos los demás valores predeterminados.
+ Para obtener más información y detalles sobre los requisitos del clúster de IPv6, consulte [Creación de una Amazon VPC para su clúster de Amazon EKS](creating-a-vpc.md).
1. (opcional) El modo automático de EKS completa automáticamente las subredes privadas de la VPC seleccionada. Puede eliminar las subredes no deseadas.
+ EKS selecciona automáticamente las subredes privadas de la VPC según las prácticas recomendadas. Opcionalmente, puede seleccionar subredes adicionales de la VPC, como subredes públicas.
1. (opcional) Seleccione **Ver valores predeterminados de configuración rápida** para revisar todos los valores de configuración del nuevo clúster. En la tabla se indica que algunos valores no se pueden editar una vez creado el clúster.
1. Seleccione **Create cluster (Crear clúster)**. Tenga en cuenta que la creación del clúster puede tardar quince minutos en completarse.
## Siguientes pasos
+ Aprenda a [Implementar una carga de trabajo de muestra en el clúster de modo automático de EKS](sample-storage-workload.md)
# Cómo habilitar el modo automático de EKS en clústeres de EKS existentes
Puede habilitar el modo automático de EKS en clústeres de EKS existentes.
** AWS admite las siguientes migraciones:**
+ Migración de Karpenter a los nodos del modo automático de EKS. Para obtener más información, consulte [Migración desde Karpenter al modo automático de EKS mediante kubectl](auto-migrate-karpenter.md).
+ Migración de los grupos de nodos administrados de EKS a los nodos del modo automático de EKS. Para obtener más información, consulte [Migración de grupos de nodos administrados de EKS al modo automático de EKS](auto-migrate-mng.md).
+ Migración de EKS Fargate al modo automático de EKS. Para obtener más información, consulte [Migración de EKS Fargate a los nodos del modo automático de EKS](auto-migrate-fargate.md).
** AWS no admite las siguientes migraciones:**
+ Migración de volúmenes del controlador CSI de EBS (mediante el complemento de Amazon EKS) al controlador CSI de EBS del modo automático de EKS (administrado por el modo automático de EKS). Las PVC hechas con uno no se pueden montar sobre el otro, ya que utilizan dos aprovisionadores de volumen Kubernetes diferentes.
+ [https://github.com/awslabs/eks-auto-mode-ebs-migration-tool](https://github.com/awslabs/eks-auto-mode-ebs-migration-tool) (proyecto AWS Labs) permite la migración entre la StorageClass estándar de CSI de EBS (`ebs.csi.aws.com`) y la StorageClass de CSI de EBS automática de EKS (`ebs.csi.eks.amazonaws.com`). Tenga en cuenta que la migración requiere eliminar y volver a crear los recursos existentes de PersistentVolumeClaim y PersistentVolume, por lo que la validación en un entorno que no sea de producción es esencial antes de la implementación.
+ Migración de los equilibradores de carga del controlador de equilibrio de carga de AWS al modo automático de EKS
Puede instalar el controlador del equilibrador de carga de AWS en un clúster del modo automático de Amazon EKS. Utilice las opciones `IngressClass` o `loadBalancerClass` para asociar los recursos de servicio e ingreso al controlador del equilibrador de carga o al modo automático de EKS.
+ Migración de clústeres de EKS con CNI alternativas u otras configuraciones de red no compatibles
## Referencia para las migraciones
Utilice la siguiente referencia para las migraciones para configurar los recursos de Kubernetes de modo que sean propiedad de controladores autoadministrados o del modo automático de EKS.
| Funcionalidad | Recurso | Campo | Autoadministrado | Modo automático de EKS |
| --- | --- | --- | --- | --- |
| Almacenamiento en bloque | `StorageClass` | `provisioner` | `ebs.csi.aws.com` | `ebs.csi.eks.amazonaws.com` |
| Equilibrio de carga | `Service` | `loadBalancerClass` | `service.k8s.aws/nlb` | `eks.amazonaws.com/nlb` |
| Equilibrio de carga | `IngressClass` | `controller` | `ingress.k8s.aws/alb` | `eks.amazonaws.com/alb` |
| Equilibrio de carga | `IngressClassParams` | `apiversion` | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` |
| Equilibrio de carga | `TargetGroupBinding` | `apiversion` | `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` |
| Computación | `NodeClass` | `apiVersion` | `karpenter.sh/v1` | `eks.amazonaws.com/v1` |
## Migración de volúmenes de EBS
Al migrar las cargas de trabajo al modo automático de EKS, es necesario gestionar la migración de volúmenes de EBS debido a los diferentes aprovisionadores de controladores CSI:
+ Aprovisionador de modo automático de EKS: `ebs.csi.eks.amazonaws.com`
+ Aprovisionador de CSI de EBS de código abierto: `ebs.csi.aws.com`
Siga estos pasos para migrar los volúmenes persistentes:
1. **Modificar la política de retención de volúmenes**: cambie las versiones de la plataforma (PV) existentes `persistentVolumeReclaimPolicy` a `Retain` para garantizar que no se elimine el volumen de EBS subyacente.
1. **Eliminar la PV de Kubernetes**: elimine el recurso de PV anterior y mantenga intacto el volumen real de EBS.
1. **Crear una nueva PV con aprovisionamiento estático**: cree una nueva PV que haga referencia al mismo volumen de EBS, pero que funcione con el controlador CSI de destino.
1. **Adjuntar a una PVC nueva**: cree una nueva PVC que haga referencia específicamente a su PV utilizando el campo `volumeName`.
### Consideraciones
+ Asegúrese de detener las aplicaciones antes de comenzar la migración.
+ Realice copias de seguridad de los datos antes de iniciar el proceso de migración.
+ Este proceso debe realizarse para cada volumen persistente.
+ La carga de trabajo debe actualizarse para usar la nueva PVC.
## Migración de los equilibradores de carga
No se pueden transferir directamente los equilibradores de carga existentes desde el controlador del equilibrador de carga de AWS autoadministrado al modo automático de EKS. En su lugar, debe implementar una estrategia de implementación azul/verde. Esto implica mantener la configuración del equilibrador de carga existente y, al mismo tiempo, crear nuevos equilibradores de carga en el controlador administrado.
Para minimizar las interrupciones del servicio, recomendamos un enfoque de cambio de tráfico basado en el DNS. En primer lugar, cree nuevos equilibradores de carga mediante el modo automático de EKS y, al mismo tiempo, mantenga operativa la configuración actual. A continuación, utilice el enrutamiento de DNS (como Route 53) para desplazar gradualmente el tráfico de los equilibradores de carga antiguos a los nuevos. Una vez que el tráfico se haya migrado correctamente y haya verificado la nueva configuración, podrá retirar los equilibradores de carga y el controlador autoadministrado antiguos.
# Cómo habilitar el modo automático de EKS en un clúster existente
En este tema se describe cómo habilitar el modo automático de Amazon EKS en los clústeres de Amazon EKS existentes. Para habilitar el modo automático en un clúster existente, es necesario actualizar los permisos de IAM y configurar los ajustes principales del modo automático de EKS. Una vez habilitado, podrá comenzar a migrar las cargas de trabajo de computación existentes para aprovechar las operaciones simplificadas y la administración automatizada de la infraestructura del modo automático.
**importante**
Compruebe que tiene instalada la versión mínima requerida de algunos complementos de Amazon EKS antes de habilitar el modo automático de EKS. Para obtener más información, consulte [Versiones del complemento requeridas](#auto-addons-required).
Antes de comenzar, asegúrese de que dispone de acceso de administrador al clúster de Amazon EKS, así como de los permisos para modificar los roles de IAM. Los pasos descritos en este tema sirven de guía para habilitar el modo automático mediante la Consola de administración de AWS o la AWS CLI.
## Consola de administración de AWS
Debe iniciar sesión en la consola de AWS con permiso para administrar los recursos de IAM, EKS y EC2.
**nota**
El rol de IAM de clúster de un clúster de EKS no se podrá modificar una vez creado el clúster. El modo automático de EKS requiere permisos adicionales para este rol. Debe asociar políticas adicionales al rol actual.
### Actualización del rol de IAM de clúster
1. Abra la página de información general del clúster en la Consola de administración de AWS.
1. En el **ARN del rol de IAM de clúster**, seleccione **Ver en IAM**.
1. En la lista desplegable **Agregar permisos**, seleccione **Asociar políticas**.
1. Utilice el cuadro de **búsqueda** para encontrar y seleccionar las siguientes políticas:
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
1. Seleccione **Agregar permisos**.
1. En la pestaña **Relaciones de confianza**, seleccione **Editar política de confianza**
1. Inserte la siguiente política de confianza del rol de IAM del clúster y seleccione **Actualizar política**
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
### Cómo habilitar el modo automático de EKS
1. Abra la página de información general del clúster en la Consola de administración de AWS.
1. En **Modo automático de EKS**, seleccione **Administrar**
1. Active el **Modo automático de EKS**.
1. En el menú desplegable **Grupo de nodos de EKS**, seleccione los grupos de nodos predeterminados que desee crear.
+ Obtenga más información sobre los grupos de nodos en el modo automático de EKS. Para obtener más información, consulte [Creación de un grupo de nodos para el modo automático de EKS](create-node-pool.md).
1. Si ha creado previamente un rol de IAM de nodo de modo automático de EKS en esta cuenta de AWS, selecciónelo en el menú desplegable **Rol de IAM de nodo**. Si no ha creado este rol anteriormente, seleccione **Crear rol recomendado** y siga los pasos.
## AWS CLI
### Requisitos previos
+ El rol de clúster de IAM del clúster de EKS existente debe incluir permisos suficientes para el modo automático de EKS, como las siguientes políticas:
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
+ El rol de IAM de clúster debe tener una política de confianza actualizada que incluya la acción `sts:TagSession`. Para obtener más información sobre cómo crear un rol de IAM de clúster, consulte [Cómo crear un clúster de modo automático de EKS con AWS CLI](automode-get-started-cli.md).
+ `aws` CLI instalada, sesión iniciada y una versión suficiente. Debe tener permiso para administrar recursos de IAM, EKS y EC2. Para obtener más información, consulte [Configuración para usar Amazon EKS](setting-up.md).
### Procedimiento
Utilice los siguientes comandos para habilitar el modo automático de EKS en un clúster existente.
**nota**
Las capacidades de computación, almacenamiento en bloque y equilibrio de carga se deben habilitar o desactivar en la misma solicitud.
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=true \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{"blockStorage":{"enabled": true}}'
```
## Versiones del complemento requeridas
Si desea habilitar el modo automático de EKS en un clúster existente, es posible que deba actualizar algunos complementos. Tenga en cuenta:
+ Esto se aplica únicamente a los clústeres existentes que realicen la transición al modo automático de EKS.
+ Los nuevos clústeres creados con el modo automático de EKS habilitado no necesitan estas actualizaciones.
Si tiene alguno de los siguientes complementos instalados, asegúrese de que tienen la versión mínima especificada:
| Nombre del complemento | Versión mínima requerida |
| --- | --- |
| Complemento CNI de Amazon VPC para Kubernetes | v1.19.0-eksbuild.1 |
| Kube-proxy | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/auto-enable-existing.html) |
| Controlador CSI de Amazon EBS | v1.37.0-eksbuild.1 |
| Controlador de instantáneas CSI | v8.1.0-eksbuild.2 |
| Agente de Pod Identity de EKS | v1.3.4-eksbuild.1 |
Para obtener más información, consulte [Actualización de un complemento de Amazon EKS](updating-an-add-on.md).
## Siguientes pasos
+ Para migrar las cargas de trabajo de Administración de grupo de nodos, consulte [Migración de grupos de nodos administrados de EKS al modo automático de EKS](auto-migrate-mng.md).
+ Para migrar desde Karpenter autoadministrado, consulte [Migración desde Karpenter al modo automático de EKS mediante kubectl](auto-migrate-karpenter.md).
# Migración desde Karpenter al modo automático de EKS mediante kubectl
En este tema se explica el proceso para migrar cargas de trabajo de Karpenter al modo automático de Amazon EKS mediante kubectl. La migración se puede realizar de forma gradual, lo que le permite trasladar las cargas de trabajo a su propio ritmo y, al mismo tiempo, mantener la estabilidad del clúster y la disponibilidad de las aplicaciones durante la transición.
El enfoque paso a paso que se describe a continuación permite ejecutar Karpenter y el modo automático de EKS paralelamente durante el periodo de migración. Esta estrategia de doble operación ayuda a garantizar una transición fluida, ya que permite validar el comportamiento de la carga de trabajo en el modo automático de EKS antes de desmantelar completamente Karpenter. Puede migrar aplicaciones individualmente o en grupos, lo que proporciona flexibilidad para acomodar los requisitos operativos específicos y el nivel de tolerancia al riesgo.
## Requisitos previos
Antes de iniciar la migración, asegúrese de que dispone de:
+ Karpenter v1.1 o posterior instalado en el clúster. Para obtener más información, consulte [Upgrading to 1.1.0\$1](https://karpenter.sh/docs/upgrading/upgrade-guide/#upgrading-to-110) en la documentación de Karpenter.
+ `kubectl` instalado y conectado al clúster. Para obtener más información, consulte [Configuración para usar Amazon EKS](setting-up.md).
En este tema se presupone que ya está familiarizado con Karpenter y NodePools. Para obtener más información, consulte la [documentación de Karpenter](https://karpenter.sh/).
## Paso 1: Habilitación del modo automático de EKS en el clúster
Habilite el modo automático de EKS en el clúster existente mediante AWS CLI o la Consola de administración. Para obtener más información, consulte [Cómo habilitar el modo automático de EKS en un clúster existente](auto-enable-existing.md).
**nota**
Al habilitar el modo automático de EKS, no habilite el nodepool de `general purpose` en esta etapa de la transición. Este grupo de nodos no es selectivo.
Para obtener más información, consulte [Cómo habilitar o desactivar los NodePools integrados](set-builtin-node-pools.md).
## Paso 2: Creación de un NodePool del modo automático de EKS con taints aplicadas
Cree un nuevo NodePool para el modo automático de EKS con una taint. Con esto se garantiza que los pods existentes no se programarán automáticamente en los nuevos nodos del modo automático de EKS. Este grupo de nodos utiliza la `NodeClass` `default` integrada en el modo automático de EKS. Para obtener más información, consulte [Cómo crear una clase de nodos para Amazon EKS](create-node-class.md).
Ejemplo de grupo de nodos con taint aplicada:
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: eks-auto-mode
spec:
template:
spec:
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
taints:
- key: "eks-auto-mode"
effect: "NoSchedule"
```
Actualice los requisitos del grupo de nodos de modo que coincidan con la configuración de Karpenter a partir de la cual se va a migrar. Necesita al menos un requisito.
## Paso 3: Actualización de las cargas de trabajo para la migración
Identifique y actualice las cargas de trabajo que desea migrar al modo automático de EKS. Agregue tanto las tolerancias como los selectores de nodos a estas cargas de trabajo:
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
tolerations:
- key: "eks-auto-mode"
effect: "NoSchedule"
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
Este cambio permite programar la carga de trabajo en los nuevos nodos del modo automático de EKS.
El modo automático de EKS utiliza etiquetas diferentes a las de Karpenter. Las etiquetas relacionadas con las instancias administradas por EC2 comienzan con `eks.amazonaws.com`. Para obtener más información, consulte [Creación de un grupo de nodos para el modo automático de EKS](create-node-pool.md).
## Paso 4: Migración de las cargas de trabajo de forma gradual
Repita el paso 3 para cada carga de trabajo que desee migrar. Esto permite trasladar las cargas de trabajo de forma individual o en grupos, según los requisitos y la tolerancia al riesgo.
## Paso 5: Eliminación del NodePool de Karpenter original
Una vez que se hayan migrado todas las cargas de trabajo, podrá eliminar el NodePool de Karpenter original:
```
kubectl delete nodepool
```
## Paso 6: Eliminación de la taint del NodePool del modo automático de EKS (opcional)
Si desea que el modo automático de EKS se convierta en el modo predeterminado para las nuevas cargas de trabajo, puede eliminar la taint del NodePool del modo automático de EKS:
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: eks-auto-mode
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
# Remove the taints section
```
## Paso 7: Eliminación de los selectores de nodos de las cargas de trabajo (opcional)
Si ha eliminado la taint del NodePool del modo automático de EKS, puede optar por eliminar los selectores de nodos de las cargas de trabajo, ya que el modo automático de EKS es ahora la opción predeterminada:
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
# Remove the nodeSelector section
tolerations:
- key: "eks-auto-mode"
effect: "NoSchedule"
```
## Paso 8: Desinstalación de Karpenter del clúster
Los pasos que se deben seguir para eliminar Karpenter dependen de cómo se haya instalado. Para obtener más información, consulte las [Instrucciones de instalación de Karpenter](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/#create-a-cluster-and-add-karpenter).
# Migración de grupos de nodos administrados de EKS al modo automático de EKS
Al llevar a cabo la transición del clúster de Amazon EKS para usar el modo automático de EKS, las cargas de trabajo existentes se pueden migrar sin problemas desde los grupos de nodos administrados (MNG) mediante la herramienta de la CLI de eksctl. Este proceso garantiza la disponibilidad continua de las aplicaciones, mientras que el modo automático de EKS optimiza los recursos de computación. La migración se puede llevar a cabo con una interrupción mínima de las aplicaciones en ejecución.
En este tema, se explican los pasos que se deben seguir para vaciar de forma segura los pods de los grupos de nodos administrados existentes y permitir que el modo automático de EKS los reprograme en las instancias recién aprovisionadas. Si sigue este procedimiento, podrá aprovechar la consolidación inteligente de la carga de trabajo del modo automático de EKS y, al mismo tiempo, mantener la disponibilidad de la aplicación durante la migración.
## Requisitos previos
+ Clúster de Amazon EKS con el modo automático de EKS habilitado
+ `eksctl` CLI instalada y conectada al clúster. Para obtener más información, consulte [Configuración para usar Amazon EKS](setting-up.md).
+ Karpenter no debe estar instalado en el clúster.
## Procedimiento
Utilice el siguiente comando de `eksctl` CLI para iniciar el vaciado de los pods de las instancias de grupos de nodos administrados existentes. El modo automático de EKS creará nuevos nodos para respaldar los pods desplazados.
```
eksctl delete nodegroup --cluster= --name=
```
Deberá ejecutar este comando para cada grupo de nodos administrado del clúster.
Para obtener información adicional sobre este comando, consulte la sección [Eliminación y drenaje de grupos de nodos](https://eksctl.io/usage/nodegroups/#deleting-and-draining-nodegroups) en la documentación de eksctl.
# Migración de EKS Fargate a los nodos del modo automático de EKS
En esta sección, se explica el proceso para migrar cargas de trabajo de EKS Fargate al modo automático de Amazon EKS mediante `kubectl`. La migración se puede realizar de forma gradual, lo que le permite trasladar las cargas de trabajo a su propio ritmo y, al mismo tiempo, mantener la estabilidad del clúster y la disponibilidad de las aplicaciones durante la transición.
El enfoque paso a paso que se describe a continuación permite ejecutar EKS Fargate y el modo automático de EKS paralelamente durante el periodo de migración. Esta estrategia de doble operación ayuda a garantizar una transición fluida, ya que permite validar el comportamiento de la carga de trabajo en el modo automático de EKS antes de desmantelar completamente EKS Fargate. Puede migrar aplicaciones individualmente o en grupos, lo que proporciona flexibilidad para acomodar los requisitos operativos específicos y el nivel de tolerancia al riesgo.
## Comparación entre el modo automático de Amazon EKS y EKS con AWS Fargate
Amazon EKS con AWS Fargate sigue siendo una opción para los clientes que desean utilizar EKS, pero el modo automático de Amazon EKS es el enfoque recomendado en el futuro. El modo automático de EKS es totalmente compatible con Kubernetes y con todas las primitivas y herramientas de plataforma originales de Kubernetes, como Istio, que Fargate no admite. El modo automático de EKS también es totalmente compatible con todas las opciones de compra en tiempo de ejecución de EC2, incluidas las instancias de GPU y de spot, lo que permite a los clientes aprovechar los descuentos negociados de EC2 y otros mecanismos de ahorro. Estas funciones no están disponibles cuando se utiliza EKS con Fargate.
Además, el modo automático de EKS permite a los clientes lograr el mismo modelo de aislamiento que Fargate, utilizando las capacidades de programación estándar de Kubernetes para garantizar que cada instancia de EC2 ejecute un único contenedor de aplicaciones. Al adoptar el modo automático de Amazon EKS, los clientes pueden aprovechar todas las ventajas de ejecutar Kubernetes en AWS, una plataforma totalmente compatible con Kubernetes que ofrece la flexibilidad necesaria para aprovechar toda la gama de EC2 y las opciones de compra, al tiempo que conserva la facilidad de uso y la abstracción de la administración de infraestructuras que ofrece Fargate.
### Cómo lograr un aislamiento similar a Fargate en el modo automático de EKS
Para replicar el modelo de aislamiento de pods de Fargate, donde cada pod se ejecuta en su propia instancia dedicada, puede utilizar restricciones de dispersión de topología de Kubernetes. Este es el enfoque recomendado para controlar la distribución de pods entre nodos:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: isolated-app
spec:
replicas: 3
selector:
matchLabels:
app: isolated-app
template:
metadata:
labels:
app: isolated-app
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: isolated-app
minDomains: 1
containers:
- name: app
image: nginx
ports:
- containerPort: 80
```
En esta configuración:
+ `maxSkew: 1` garantiza que la diferencia en el número de pods entre cualesquiera dos nodos sea como máximo 1, lo que distribuye efectivamente un pod por nodo.
+ `topologyKey: kubernetes.io/hostname` define el nodo como el dominio de topología
+ `whenUnsatisfiable: DoNotSchedule` impide la programación si no se puede cumplir la restricción
+ `minDomains: 1` garantiza que exista al menos un dominio (nodo) antes de la programación
El modo automático de EKS aprovisionará automáticamente nuevas instancias de EC2 según sea necesario para satisfacer esta restricción, lo que proporciona el mismo modelo de aislamiento que Fargate y da acceso a toda la gama de tipos de instancias de EC2 y opciones de compra.
Como alternativa, puede utilizar reglas de antiafinidad de pods para un aislamiento más estricto:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: isolated-app
spec:
replicas: 3
selector:
matchLabels:
app: isolated-app
template:
metadata:
labels:
app: isolated-app
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- isolated-app
topologyKey: kubernetes.io/hostname
containers:
- name: app
image: nginx
ports:
- containerPort: 80
```
La regla `podAntiAffinity` con `requiredDuringSchedulingIgnoredDuringExecution` garantiza que no se puedan programar dos pods con la etiqueta `app: isolated-app` en el mismo nodo. Este enfoque proporciona garantías estrictas de aislamiento similares a las de Fargate.
## Requisitos previos
Antes de iniciar la migración, asegúrese de que ha hecho lo siguiente:
+ Configurar un clúster con Fargate. Para obtener más información, consulte [Introducción a AWS Fargate para un clúster](fargate-getting-started.md).
+ Instalar y conectar `kubectl` al clúster. Para obtener más información, consulte [Configuración para usar Amazon EKS](setting-up.md).
## Paso 1: Revisión del clúster de Fargate
1. Revise si el clúster de EKS con Fargate está en ejecución:
```
kubectl get node
```
```
NAME STATUS ROLES AGE VERSION
fargate-ip-192-168-92-52.ec2.internal Ready 25m v1.30.8-eks-2d5f260
fargate-ip-192-168-98-196.ec2.internal Ready 24m v1.30.8-eks-2d5f260
```
1. Revise los pods en ejecución:
```
kubectl get pod -A
```
```
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-6659cb98f6-gxpjz 1/1 Running 0 26m
kube-system coredns-6659cb98f6-gzzsx 1/1 Running 0 26m
```
1. Cree una implementación en un archivo llamado `deployment_fargate.yaml`:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
annotations:
eks.amazonaws.com/compute-type: fargate
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
```
1. Aplique la implementación:
```
kubectl apply -f deployment_fargate.yaml
```
```
deployment.apps/nginx-deployment created
```
1. Revise los pods y las implementaciones:
```
kubectl get pod,deploy
```
```
NAME READY STATUS RESTARTS AGE
pod/nginx-deployment-5c7479459b-6trtm 1/1 Running 0 61s
pod/nginx-deployment-5c7479459b-g8ssb 1/1 Running 0 61s
pod/nginx-deployment-5c7479459b-mq4mf 1/1 Running 0 61s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/nginx-deployment 3/3 3 3 61s
```
1. Revise el nodo:
```
kubectl get node -owide
```
```
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
fargate-ip-192-168-111-43.ec2.internal Ready 31s v1.30.8-eks-2d5f260 192.168.111.43 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
fargate-ip-192-168-117-130.ec2.internal Ready 36s v1.30.8-eks-2d5f260 192.168.117.130 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
fargate-ip-192-168-74-140.ec2.internal Ready 36s v1.30.8-eks-2d5f260 192.168.74.140 Amazon Linux 2 5.10.234-225.910.amzn2.x86_64 containerd://1.7.25
```
## Paso 2: Habilitación del modo automático de EKS en el clúster
1. Habilite el modo automático de EKS en el clúster existente mediante AWS CLI o la Consola de administración. Para obtener más información, consulte [Cómo habilitar el modo automático de EKS en un clúster existente](auto-enable-existing.md).
1. Revise el nodepool:
```
kubectl get nodepool
```
```
NAME NODECLASS NODES READY AGE
general-purpose default 1 True 6m58s
system default 0 True 3d14h
```
## Paso 3: Actualización de las cargas de trabajo para la migración
Identifique y actualice las cargas de trabajo que desea migrar al modo automático de EKS.
Para migrar una carga de trabajo de Fargate al modo automático de EKS, aplique la anotación `eks.amazonaws.com/compute-type: ec2`. Esto garantiza que Fargate no programará la carga de trabajo, a pesar del perfil de Fargate, y que lo hará el NodePool del modo automático de EKS. Para obtener más información, consulte [Creación de un grupo de nodos para el modo automático de EKS](create-node-pool.md).
1. Modifique las implementaciones (por ejemplo, el archivo `deployment_fargate.yaml`) para cambiar el tipo de procesamiento a `ec2`:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
annotations:
eks.amazonaws.com/compute-type: ec2
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
```
1. Aplique la implementación. Este cambio permite programar la carga de trabajo en los nuevos nodos del modo automático de EKS:
```
kubectl apply -f deployment_fargate.yaml
```
1. Verifique que la implementación se esté ejecutando en el clúster del modo automático de EKS:
```
kubectl get pod -o wide
```
```
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-deployment-97967b68d-ffxxh 1/1 Running 0 3m31s 192.168.43.240 i-0845aafcb51630ffb
nginx-deployment-97967b68d-mbcgj 1/1 Running 0 2m37s 192.168.43.241 i-0845aafcb51630ffb
nginx-deployment-97967b68d-qpd8x 1/1 Running 0 2m35s 192.168.43.242 i-0845aafcb51630ffb
```
1. Verifique que no haya ningún nodo Fargate en ejecución ni ninguna implementación en ejecución en los nodos administrados del modo automático de EKS:
```
kubectl get node -owide
```
```
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
i-0845aafcb51630ffb Ready 3m30s v1.30.8-eks-3c20087 192.168.41.125 3.81.118.95 Bottlerocket (EKS Auto) 2025.3.14 (aws-k8s-1.30) 6.1.129 containerd://1.7.25+bottlerocket
```
## Paso 4: Migración de las cargas de trabajo de forma gradual
Repita el paso 3 para cada carga de trabajo que desee migrar. Esto permite trasladar las cargas de trabajo de forma individual o en grupos, según los requisitos y la tolerancia al riesgo.
## Paso 5: Eliminación del perfil original de Fargate
Una vez que se hayan migrado todas las cargas de trabajo, podrá eliminar el perfil original de `fargate`. Reemplace ** por el nombre de su perfil de Fargate:
```
aws eks delete-fargate-profile --cluster-name eks-fargate-demo-cluster --fargate-profile-name
```
## Paso 6: Reducción vertical de CoreDNS
Como el modo automático de EKS gestiona CoreDNS, puede reducir la implementación de `coredns` a 0:
```
kubectl scale deployment coredns -n kube-system —-replicas=0
```
# Ejecución de cargas de trabajo de muestra en clústeres del modo automático de EKS
En este capítulo se ofrecen ejemplos de cómo implementar diferentes tipos de cargas de trabajo en clústeres de Amazon EKS que se ejecutan en modo automático. Los ejemplos muestran patrones clave de cargas de trabajo, como aplicaciones de muestra, aplicaciones web con equilibrio de carga, cargas de trabajo con estado que utilizan almacenamiento persistente y cargas de trabajo con requisitos específicos de ubicación de nodos. Cada ejemplo incluye manifiestos completos e instrucciones de implementación paso a paso que se pueden utilizar como plantillas para aplicaciones propias.
Antes de continuar con los ejemplos, asegúrese de que tiene un clúster de EKS en ejecución en modo automático y que ha instalado AWS CLI y kubectl. Para obtener más información, consulte [Configuración para usar Amazon EKS](setting-up.md). Los ejemplos presuponen cierta familiaridad con los conceptos de Kubernetes y los comandos kubectl.
Puede utilizar estas muestras basadas en casos de uso para ejecutar cargas de trabajo en clústeres del modo automático de EKS.
[Implementación de una carga de trabajo de expansión de muestra en un clúster del modo automático de Amazon EKS](automode-workload.md)
Muestra cómo implementar una carga de trabajo de muestra en un clúster de modo automático de EKS mediante comandos `kubectl`.
[Implementación de una carga de trabajo de equilibrador de carga de muestra en el modo automático de EKS](auto-elb-example.md)
Muestra cómo implementar una versión en contenedores del videojuego 2048 en Amazon EKS.
[Implementación de una carga de trabajo con estado de ejemplo en el modo automático de EKS](sample-storage-workload.md)
Muestra cómo implementar una aplicación con estado de muestra en un clúster del modo automático de EKS.
[Implementación de una carga de trabajo acelerada](auto-accelerated.md)
Muestra cómo implementar cargas de trabajo aceleradas por hardware en nodos administrados por el modo automático de EKS.
[Cómo controlar si una carga de trabajo se implementa en nodos del modo automático de EKS](associate-workload.md)
Muestra cómo utilizar una anotación para controlar si una carga de trabajo se implementa en nodos administrados por el modo automático de EKS.
# Implementación de una carga de trabajo de expansión de muestra en un clúster del modo automático de Amazon EKS
En este tutorial, aprenderá a implementar una carga de trabajo de muestra en un clúster del modo automático de EKS y observará cómo se aprovisionan automáticamente los recursos de computación necesarios. Utilizará comandos `kubectl` para observar el comportamiento del clúster y comprobar de primera mano la forma en que el modo automático simplifica las operaciones de Kubernetes en AWS. Al final de este tutorial, comprenderá la forma en que el modo automático de EKS responde a las implementaciones de cargas de trabajo mediante la administración automática de los recursos de computación subyacentes, sin necesidad de configurar manualmente los grupos de nodos.
## Requisitos previos
+ Un clúster del modo automático de Amazon EKS. Anote el nombre y la región de AWS del clúster.
+ Una entidad principal de IAM, como un usuario o rol, con permisos suficientes para administrar recursos de red, computación y EKS.
+ Para obtener más información, consulte [Cómo crear roles y asociar políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html) en la Guía del usuario de IAM.
+ `aws` CLI instalada y configurada con una identidad de IAM.
+ `kubectl` CLI instalada y conectada al clúster.
+ Para obtener más información, consulte [Configuración para usar Amazon EKS](setting-up.md).
## Paso 1: Revisión de los recursos de computación existentes (opcional)
En primer lugar, utilice `kubectl` para enumerar los grupos de nodos en el clúster.
```
kubectl get nodepools
```
Resultado de ejemplo:
```
general-purpose
```
En este tutorial, implementaremos una carga de trabajo configurada para utilizar el grupo de nodos `general-purpose`. Este grupo de nodos está integrado en el modo automático de EKS e incluye valores predeterminados razonables para cargas de trabajo generales, como microservicios y aplicaciones web. Puede crear un grupo de nodos propio. Para obtener más información, consulte [Creación de un grupo de nodos para el modo automático de EKS](create-node-pool.md).
En segundo lugar, utilice `kubectl` para enumerar los nodos conectados al clúster.
```
kubectl get nodes
```
Si acaba de crear un clúster de modo automático de EKS, no tendrá nodos.
En este tutorial, implementará una carga de trabajo de ejemplo. Si no tiene nodos, o la carga de trabajo no cabe en los nodos existentes, el modo automático de EKS aprovisionará un nuevo nodo.
## Paso 2: Implementación de una aplicación de ejemplo en el clúster
Revise la siguiente implementación de Kubernetes y guárdela como `inflate.yaml`
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate
spec:
replicas: 1
selector:
matchLabels:
app: inflate
template:
metadata:
labels:
app: inflate
spec:
terminationGracePeriodSeconds: 0
nodeSelector:
eks.amazonaws.com/compute-type: auto
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
containers:
- name: inflate
image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
resources:
requests:
cpu: 1
securityContext:
allowPrivilegeEscalation: false
```
Tenga en cuenta que el selector `eks.amazonaws.com/compute-type: auto` requiere que la carga de trabajo se implemente en un nodo de modo automático de Amazon EKS.
Aplique la implementación al clúster.
```
kubectl apply -f inflate.yaml
```
## Paso 3: Visualización de los eventos de Kubernetes
Utilice el siguiente comando para ver los eventos de Kubernetes, incluida la creación de un nuevo nodo. Utilice `ctrl+c` para dejar de ver los eventos.
```
kubectl get events -w --sort-by '.lastTimestamp'
```
Utilice `kubectl` para enumerar los nodos conectados al clúster nuevamente. Tenga en cuenta el nodo recién creado.
```
kubectl get nodes
```
## Paso 4: Visualización de nodos e instancias en la consola de AWS
Puede ver los nodos de modo automático de EKS en la consola de EKS, y las instancias de EC2 asociadas en la consola de EC2.
Las instancias de EC2 implementadas por el modo automático de EKS están restringidas. No se pueden ejecutar comandos arbitrarios en los nodos del modo automático de EKS.
## Paso 5: Eliminación de la implementación
Utilice `kubectl` para eliminar la implementación de muestra
```
kubectl delete -f inflate.yaml
```
Si no tiene otras cargas de trabajo implementadas en el clúster, el nodo creado por el modo automático de EKS estará vacío.
En la configuración predeterminada, el modo automático de EKS detecta los nodos que han estado vacíos durante treinta segundos y los termina.
Utilice `kubectl` o la consola de EC2 para confirmar que la instancia asociada se ha eliminado.
# Implementación de una carga de trabajo de equilibrador de carga de muestra en el modo automático de EKS
En esta guía se explica cómo implementar una versión en contenedores del videojuego 2048 en Amazon EKS, con equilibrio de carga y accesibilidad a Internet.
## Requisitos previos
+ Un clúster de modo automático de EKS
+ `kubectl` configurado para interactuar con el clúster
+ Permisos de IAM adecuados para crear recursos del equilibrador de carga de aplicaciones
## Paso 1: Creación del espacio de nombres
En primer lugar, cree un espacio de nombres dedicado para la aplicación del videojuego 2048.
Cree un archivo denominado `01-namespace.yaml`:
```
apiVersion: v1
kind: Namespace
metadata:
name: game-2048
```
Aplique la configuración del espacio de nombres:
```
kubectl apply -f 01-namespace.yaml
```
## Paso 2: Implementación de la aplicación
La aplicación ejecuta varias réplicas del contenedor del videojuego 2048.
Cree un archivo denominado `02-deployment.yaml`:
```
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: game-2048
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 5
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
resources:
requests:
cpu: "0.5"
```
**nota**
Si obtiene un error al cargar la imagen `public.ecr.aws/l6m2t8p7/docker-2048:latest`, confirme que el rol de IAM del nodo tenga los permisos suficientes para extraer imágenes de ECR. Para obtener más información, consulte [Rol de IAM de nodo](auto-learn-iam.md#auto-learn-node-iam-role). Además, la imagen `docker-2048` del ejemplo es una imagen `x86_64` y no se ejecutará en otras arquitecturas.
**Componentes principales:**
+ Implementa 5 réplicas de la aplicación
+ Utiliza una imagen de ECR pública
+ Solicita 0,5 núcleos de CPU por pod
+ Expone el puerto 80 para el tráfico HTTP
Aplique la implementación:
```
kubectl apply -f 02-deployment.yaml
```
## Paso 3: Creación del servicio
El servicio expone la implementación a la red del clúster.
Cree un archivo denominado `03-service.yaml`:
```
apiVersion: v1
kind: Service
metadata:
namespace: game-2048
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
selector:
app.kubernetes.io/name: app-2048
```
**Componentes principales:**
+ Crea un servicio NodePort
+ Asigna el puerto 80 al puerto 80 del contenedor
+ Utiliza el selector de etiquetas para encontrar pods
Aplique el servicio:
```
kubectl apply -f 03-service.yaml
```
## Paso 4: Configuración del equilibrio de carga
Configurará un ingreso para exponer la aplicación a Internet.
Primero, cree la `IngressClass`. Cree un archivo denominado `04-ingressclass.yaml`:
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
labels:
app.kubernetes.io/name: LoadBalancerController
name: alb
spec:
controller: eks.amazonaws.com/alb
```
**nota**
El modo automático de EKS requiere etiquetas de subred para identificar las subredes públicas y privadas.
Si creó el clúster con `eksctl`, ya dispone de estas etiquetas.
Aprenda cómo [Etiquetado de subredes para el modo automático de EKS](tag-subnets-auto.md).
A continuación, cree el recurso de ingreso. Cree un archivo denominado `05-ingress.yaml`:
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: game-2048
name: ingress-2048
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: service-2048
port:
number: 80
```
**Componentes principales:**
+ Creación de un equilibrador de carga de aplicaciones expuesto a Internet
+ Utiliza el tipo de destino de IP para el enrutamiento directo de pods
+ Dirige todo el tráfico (/) al servicio del videojuego
Aplique las configuraciones de ingreso:
```
kubectl apply -f 04-ingressclass.yaml
kubectl apply -f 05-ingress.yaml
```
## Paso 5: Verificación de la implementación
1. Compruebe que todos los pods estén en ejecución:
```
kubectl get pods -n game-2048
```
1. Compruebe que el servicio se haya creado:
```
kubectl get svc -n game-2048
```
1. Obtenga el punto de conexión del equilibrador de carga de aplicaciones:
```
kubectl get ingress -n game-2048
```
El campo ADDRESS en la salida del ingreso mostrará el punto de conexión del equilibrador de carga de aplicaciones. Espere de 2 a 3 minutos para que el equilibrador de carga de aplicaciones aprovisione y registre todos los destinos.
## Paso 6: Acceso al videojuego
Abra el navegador web y vaya a la URL del punto de conexión del equilibrador de carga de aplicaciones del paso anterior. Aparecerá la interfaz del videojuego 2048.
## Paso 7: Efectúe una limpieza
Para eliminar todos los recursos creados en este tutorial:
```
kubectl delete namespace game-2048
```
Esto eliminará todos los recursos del espacio de nombres, incluidos los recursos de implementación, servicio e ingreso.
## Lo que ocurre detrás de las cámaras
1. La implementación crea 5 pods que ejecutan el videojuego 2048
1. El servicio proporciona un acceso de red estable a estos pods
1. Modo automático de EKS:
+ Crea un equilibrador de carga de aplicación en AWS
+ Configura grupos de destino para los pods
+ Establece reglas de enrutamiento para dirigir el tráfico al servicio
## Solución de problemas
Si el videojuego no se carga
+ Asegúrese de que todos los pods se ejecutan: `kubectl get pods -n game-2048`
+ Compruebe el estado del ingreso: `kubectl describe ingress -n game-2048`
+ Verifique las comprobaciones de estado del equilibrador de carga de aplicación: compruebe el estado del grupo de destino en la Consola de AWS
# Implementación de una carga de trabajo con estado de ejemplo en el modo automático de EKS
En este tutorial se explica cómo implementar una aplicación con estado de ejemplo en el clúster de modo automático de EKS. La aplicación escribe marcas de tiempo en un volumen persistente, lo que demuestra las capacidades automáticas de persistencia y aprovisionamiento de volúmenes de EBS del modo automático de EKS.
## Requisitos previos
+ Un clúster de modo automático de EKS
+ AWS CLI configurada con los permisos adecuados
+ `kubectl` instalado y configurado
+ Para obtener más información, consulte [Configuración para usar Amazon EKS](setting-up.md).
## Paso 1: Configuración del entorno
1. Configure las variables de entorno:
```
export CLUSTER_NAME=my-auto-cluster
export AWS_REGION="us-west-2"
```
1. Actualice la kubeconfig:
```
aws eks update-kubeconfig --name "${CLUSTER_NAME}"
```
## Paso 2: Creación de la clase de almacenamiento
La `StorageClass` define cómo el modo automático de EKS aprovisionará los volúmenes de EBS.
El modo automático de EKS no crea una `StorageClass` en su nombre. Debe crear una `StorageClass` que haga referencia a `ebs.csi.eks.amazonaws.com` para utilizar la capacidad de almacenamiento del modo automático de EKS.
1. Cree un archivo denominado `storage-class.yaml`:
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
1. Aplicación de `StorageClass`:
```
kubectl apply -f storage-class.yaml
```
**Componentes principales:**
+ `provisioner: ebs.csi.eks.amazonaws.com`: utiliza el modo automático de EKS
+ `volumeBindingMode: WaitForFirstConsumer`: retrasa la creación del volumen hasta que un pod lo necesite
+ `type: gp3`: especifica el tipo de volumen de EBS
+ `encrypted: "true"`: EBS utilizará la clave de `aws/ebs` predeterminada para cifrar los volúmenes creados con esta clase. Esto es opcional, pero recomendable.
+ `storageclass.kubernetes.io/is-default-class: "true"`: Kubernetes utilizará esta clase de almacenamiento de forma predeterminada, a menos que se especifique una clase de volumen diferente en una reclamación de volumen persistente. Tenga cuidado al establecer este valor si va a migrar desde otro controlador de almacenamiento. (opcional)
## Paso 3: Creación de la reclamación de volumen persistente
La reclamación de volumen persistente solicita almacenamiento a la `StorageClass`.
1. Cree un archivo denominado `pvc.yaml`:
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: auto-ebs-claim
spec:
accessModes:
- ReadWriteOnce
storageClassName: auto-ebs-sc
resources:
requests:
storage: 8Gi
```
1. Aplicación de la reclamación de volumen persistente:
```
kubectl apply -f pvc.yaml
```
**Componentes principales:**
+ `accessModes: ReadWriteOnce`: el volumen se puede montar con un nodo a la vez
+ `storage: 8Gi`: solicita un volumen de 8 GiB
+ `storageClassName: auto-ebs-sc`: hace referencia a la `StorageClass` que creamos
## Paso 4: Implementación de la aplicación
La implementación ejecuta un contenedor que escribe marcas de tiempo en el volumen persistente.
1. Cree un archivo denominado `deployment.yaml`:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate-stateful
spec:
replicas: 1
selector:
matchLabels:
app: inflate-stateful
template:
metadata:
labels:
app: inflate-stateful
spec:
terminationGracePeriodSeconds: 0
nodeSelector:
eks.amazonaws.com/compute-type: auto
containers:
- name: bash
image: public.ecr.aws/docker/library/bash:4.4
command: ["/usr/local/bin/bash"]
args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 60; done"]
resources:
requests:
cpu: "1"
volumeMounts:
- name: persistent-storage
mountPath: /data
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: auto-ebs-claim
```
1. Aplique la implementación:
```
kubectl apply -f deployment.yaml
```
**Componentes principales:**
+ Contenedor bash simple que escribe marcas de tiempo en un archivo
+ Monta la reclamación de volumen persistente en `/data`
+ Solicita 1 núcleo de CPU
+ Utiliza el selector de nodos para los nodos administrados por EKS
## Paso 5: Verificación del modo en que quedó establecido
1. Compruebe que el pod se ejecuta:
```
kubectl get pods -l app=inflate-stateful
```
1. Compruebe que la reclamación de volumen persistente está vinculada:
```
kubectl get pvc auto-ebs-claim
```
1. Compruebe el volumen de EBS:
```
# Get the PV name
PV_NAME=$(kubectl get pvc auto-ebs-claim -o jsonpath='{.spec.volumeName}')
# Describe the EBS volume
aws ec2 describe-volumes \
--filters Name=tag:CSIVolumeName,Values=${PV_NAME}
```
1. Verifique que los datos se escriben:
```
kubectl exec "$(kubectl get pods -l app=inflate-stateful \
-o=jsonpath='{.items[0].metadata.name}')" -- \
cat /data/out.txt
```
## Paso 6: Efectúe una limpieza
Ejecute el siguiente comando para eliminar todos los recursos creados en este tutorial:
```
# Delete all resources in one command
kubectl delete deployment/inflate-stateful pvc/auto-ebs-claim storageclass/auto-ebs-sc
```
## Lo que ocurre detrás de las cámaras
1. La reclamación de volumen persistente solicita almacenamiento a la `StorageClass`.
1. Cuando el pod se ha programado:
1. El modo automático de EKS aprovisiona un volumen de EBS
1. Crea un PersistentVolume
1. Asocia el volumen al nodo
1. El pod monta el volumen y comienza a escribir las marcas de tiempo
## Controlador de instantáneas
El modo automático de EKS es compatible con Kubernetes CSI Snapshotter, también conocido como controlador de instantáneas. Sin embargo, el modo automático de EKS no incluye el controlador de instantáneas. Usted es responsable de instalar y configurar el controlador de instantáneas. Para obtener más información, consulte [Habilitación de la funcionalidad de instantáneas para volúmenes de CSI](csi-snapshot-controller.md).
Revise la siguiente `VolumeSnapshotClass` que hace referencia a la capacidad de almacenamiento del modo automático de EKS.
```
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
name: auto-ebs-vsclass
driver: ebs.csi.eks.amazonaws.com
deletionPolicy: Delete
```
[Más información sobre Kubernetes CSI Snapshotter.](https://github.com/kubernetes-csi/external-snapshotter/blob/master/README.md#usage)
# Implementación de una carga de trabajo acelerada
En este tutorial, se muestra cómo el modo automático de Amazon EKS simplifica el lanzamiento de cargas de trabajo aceleradas por hardware. Con el modo automático, Amazon EKS simplifica las operaciones más allá del propio clúster al automatizar componentes clave de infraestructura, lo que permite contar desde el primer momento con funciones de computación, redes, equilibrio de carga, almacenamiento y administración de identidades y accesos.
El modo automático de Amazon EKS incluye los controladores y los complementos de dispositivo necesarios para determinados tipos de instancias, como los controladores NVIDIA y AWS Neuron. No tiene que instalar ni actualizar estos componentes.
El modo automático de EKS administra automáticamente los controladores de estos aceleradores:
+ [AWS Trainium](https://aws.amazon.com/ai/machine-learning/trainium/)
+ [AWS Inferentia](https://aws.amazon.com/ai/machine-learning/inferentia/)
+ [GPU NVIDIA en instancias aceleradas de Amazon EC2](https://docs.aws.amazon.com/ec2/latest/instancetypes/ac.html)
**nota**
El modo automático de EKS incluye el complemento de dispositivo de NVIDIA para Kubernetes. Este complemento se ejecuta automáticamente y no aparece como un conjunto de daemon en el clúster.
Compatibilidad de red adicional:
+ [Elastic Fabric Adapter (EFA)](https://aws.amazon.com/hpc/efa/)
Con el modo automático, Amazon EKS elimina el trabajo manual y repetitivo de administrar el controlador del acelerador y el complemento del dispositivo.
También puede ahorrar costos al reducir la capacidad del clúster a cero. Puede habilitar el modo automático de EKS para que termine las instancias cuando no haya cargas de trabajo en ejecución. Esto es especialmente útil para cargas de trabajo de inferencia basadas en lotes.
A continuación, se muestra un ejemplo de cómo lanzar cargas de trabajo aceleradas con el modo automático de Amazon EKS.
## Requisitos previos
+ Un clúster de Kubernetes con el modo automático de Amazon EKS configurado.
+ Una clase de nodo `default` de EKS, tal como se crea al habilitar los grupos de nodos administrados de `general-purpose` o del `system`.
## Paso 1: Implementación de una carga de trabajo de GPU
Este ejemplo muestra cómo crear un NodePool para cargas de trabajo basadas en NVIDIA que requieren 45 GB de memoria de GPU. Con el modo automático de EKS, puede usar las restricciones de programación de Kubernetes para especificar los requisitos de instancia.
Para implementar el `NodePool` de Amazon EKS en modo automático junto con la `workload` de ejemplo, revise las siguientes definiciones de NodePool y Pod, y guárdelas como `nodepool-gpu.yaml` y `pod.yaml`.
**nodepool-gpu.yaml**
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
disruption:
budgets:
- nodes: 10%
consolidateAfter: 1h
consolidationPolicy: WhenEmpty
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "kubernetes.io/arch"
operator: In
values: ["amd64"]
- key: "eks.amazonaws.com/instance-family"
operator: In
values:
- g6e
- g6
taints:
- key: nvidia.com/gpu
effect: NoSchedule
terminationGracePeriod: 24h0m0s
```
**pod.yaml**
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
eks.amazonaws.com/compute-type: auto
restartPolicy: OnFailure
containers:
- name: nvidia-smi
image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
args:
- "nvidia-smi"
resources:
requests:
memory: "30Gi"
cpu: "3500m"
nvidia.com/gpu: 1
limits:
memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
Tenga en cuenta que el selector `eks.amazonaws.com/compute-type: auto` requiere que la carga de trabajo se implemente en un nodo de modo automático de Amazon EKS. El NodePool también aplica un taint que solo permite la programación de pods con tolerancias para GPU de NVIDIA.
Aplique el NodePool y la carga de trabajo al clúster.
```
kubectl apply -f nodepool-gpu.yaml
kubectl apply -f pod.yaml
```
Debería ver los siguientes datos de salida:
```
nodepool.karpenter.sh/gpu configured created
pod/nvidia-smi created
```
Espere unos segundos y verifique los nodos del clúster. Ahora debería poder ver un nuevo nodo aprovisionado en el clúster del modo automático de Amazon EKS:
```
> kubectl get nodes
NAME TYPE CAPACITY ZONE NODE READY AGE
gpu-dnknr g6e.2xlarge on-demand us-west-2b i-02315c7d7643cdee6 True 76s
```
## Paso 2: Validación
Puede observar que el modo automático de Amazon EKS lanzó una instancia `g6e.2xlarge` en lugar de una `g6.2xlarge`, ya que la carga de trabajo requería una instancia con `GPU` l40s, conforme a las siguientes restricciones de programación de Kubernetes:
```
...
nodeSelector:
eks.amazonaws.com/instance-gpu-name: l40s
...
requests:
memory: "30Gi"
cpu: "3500m"
nvidia.com/gpu: 1
limits:
memory: "30Gi"
nvidia.com/gpu: 1
```
A continuación, consulte los registros de los contenedores con el siguiente comando:
```
kubectl logs nvidia-smi
```
Código de salida de ejemplo:
```
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.230.02 Driver Version: 535.230.02 CUDA Version: 12.2 |
|-----------------------------------------+----------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+======================+======================|
| 0 NVIDIA L40S On | 00000000:30:00.0 Off | 0 |
| N/A 27C P8 23W / 350W | 0MiB / 46068MiB | 0% Default |
| | | N/A |
+-----------------------------------------+----------------------+----------------------+
+---------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=======================================================================================|
| No running processes found |
+---------------------------------------------------------------------------------------+
```
Puede ver que el contenedor detectó que se ejecuta en una instancia con GPU `NVIDIA` y que no necesitó instalar ningún controlador, ya que el modo automático de Amazon EKS se encarga de ello.
## Paso 3: Limpieza
Para deshacerse de todos los objetos creados, utilice `kubectl` para eliminar la implementación de muestra y NodePool para que se termine el nodo:
```
kubectl delete -f nodepool-gpu.yaml
kubectl delete -f pod.yaml
```
## Ejemplo de referencia de NodePools
### Creación de un NodePool de NVIDIA
El siguiente NodePool define:
+ Lance únicamente instancias de las familias `g6e` y `g6`
+ Consolide los nodos cuando estén vacíos durante 1 hora
+ El valor de 1 hora en `consolodateAfter` está diseñado para admitir cargas de trabajo con picos y reducir la rotación de nodos. Puede ajustar `consolidateAfter` en función de los requisitos de la carga de trabajo.
**Ejemplo de NodePool con una familia de instancias con GPU y consolidación**
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
disruption:
budgets:
- nodes: 10%
consolidateAfter: 1h
consolidationPolicy: WhenEmpty
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "kubernetes.io/arch"
operator: In
values: ["amd64"]
- key: "eks.amazonaws.com/instance-family"
operator: In
values:
- g6e
- g6
terminationGracePeriod: 24h0m0s
```
En lugar de configurar el `eks.amazonaws.com/instance-gpu-name`, puede utilizar `eks.amazonaws.com/instance-family` para especificar la familia de instancias. Para ver otras etiquetas conocidas que influyen en la revisión de la programación, consulte [Etiquetas compatibles con el modo automático de EKS](create-node-pool.md#auto-supported-labels).
Cuando existan requisitos específicos de almacenamiento, es posible ajustar los `iops`, el `size` y el `throughput` del almacenamiento efímero de los nodos mediante la creación de una [NodeClass](create-node-class.md) propia, la cual puede ser referenciada desde el NodePool. Más información sobre las [opciones configurables de NodeClass](create-node-class.md).
**Ejemplo de configuración de almacenamiento de NodeClass**
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
ephemeralStorage:
iops: 3000
size: 80Gi
throughput: 125
```
### Definición de un NodePool de AWS Trainium y AWS Inferentia
El siguiente NodePool cuenta con un conjunto de `eks.amazonaws.com/instance-category` que indica: lanzar únicamente instancias de las familias Inferentia y Trainium.
```
- key: "eks.amazonaws.com/instance-category"
operator: In
values:
- inf
- trn
```
# Configuración de los ajustes del modo automático de EKS
En este capítulo se describe cómo configurar aspectos específicos de los clústeres del modo automático de Amazon Elastic Kubernetes Service (EKS). Aunque el modo automático de EKS administra la mayoría de los componentes de la infraestructura de forma automática, puede personalizar ciertas características para satisfacer los requisitos de la carga de trabajo.
Con las opciones de configuración que se describen en este tema, se pueden modificar los ajustes de red, los recursos de computación y los comportamientos de equilibrio de carga, a la vez que se aprovechan las ventajas que ofrece la administración automatizada de la infraestructura. Antes de realizar cualquier cambio en la configuración, revise las opciones disponibles en las siguientes secciones para determinar qué enfoque se adapta mejor a sus necesidades.
| ¿Qué características desea configurar? | Opción de configuración |
| --- | --- |
| **Redes y almacenamiento de nodos** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/settings-auto.html) | [Cómo crear una clase de nodos para Amazon EKS](create-node-class.md) |
| **Recursos de computación de nodos** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/settings-auto.html) | [Creación de un grupo de nodos para el modo automático de EKS](create-node-pool.md) |
| **Grupos de nodos con capacidad estática** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/settings-auto.html) | [Grupos de nodos con capacidad estática en el modo automático de EKS](auto-static-capacity.md) |
| **Configuración del equilibrador de carga de aplicación** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/settings-auto.html) | [Creación de una IngressClass para configurar el equilibrador de carga de aplicación](auto-configure-alb.md) |
| **Configuración del equilibrador de carga de red** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/settings-auto.html) | [Cómo utilizar las anotaciones de servicio para configurar los equilibradores de carga de red](auto-configure-nlb.md) |
| **Configuración de la clase de almacenamiento** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/settings-auto.html) | [Creación de una clase de almacenamiento](create-storage-class.md) |
| **Control del uso de ODCR** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/settings-auto.html) | [Control de la implementación de las cargas de trabajo en las reservas de capacidad con el modo automático de EKS](auto-odcr.md) |
| **Seguridad avanzada de nodos** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/settings-auto.html) | [Configuración de ajustes avanzados de seguridad para los nodos](auto-advanced-security.md) |
# Cómo crear una clase de nodos para Amazon EKS
Las clases de nodos de Amazon EKS son plantillas que ofrecen un control detallado de la configuración de los nodos administrados del modo automático de EKS. Una clase de nodos define los ajustes a nivel de infraestructura que se aplican a los grupos de nodos del clúster de EKS, incluida la configuración de la red, los ajustes de almacenamiento y el etiquetado de los recursos. En este tema se explica cómo crear y configurar una clase de nodos para cumplir con requisitos operativos específicos.
Si necesita personalizar la forma en que el modo automático de EKS aprovisiona y configura las instancias de EC2 más allá de los ajustes predeterminados, la creación de una clase de nodos permite controlar con precisión los parámetros críticos de la infraestructura. Por ejemplo, puede especificar la ubicación de la subred privada para mejorar la seguridad, configurar el almacenamiento efímero de las instancias para cargas de trabajo sensibles al rendimiento o aplicar un etiquetado personalizado para asignar los costos.
## Cómo crear una clase de nodos
Para crear una `NodeClass`, siga estos pasos:
1. Cree un archivo YAML (por ejemplo, `nodeclass.yaml`) con la configuración de la clase de nodo
1. Aplique la configuración al clúster mediante `kubectl`
1. Haga referencia a la clase de nodos en la configuración del grupo de nodos. Para obtener más información, consulte [Creación de un grupo de nodos para el modo automático de EKS](create-node-pool.md).
Debe tener `kubectl` instalado y configurado. Para obtener más información, consulte [Configuración para usar Amazon EKS](setting-up.md).
### Ejemplo de clase de nodos básica
A continuación, se muestra un ejemplo de clase de nodos:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: private-compute
spec:
subnetSelectorTerms:
- tags:
Name: "private-subnet"
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
ephemeralStorage:
size: "160Gi"
```
Esta NodeClass aumenta la cantidad de almacenamiento efímero en el nodo.
Aplique esta configuración mediante:
```
kubectl apply -f nodeclass.yaml
```
A continuación, haga referencia a la clase de nodos en la configuración del grupo de nodos. Para obtener más información, consulte [Creación de un grupo de nodos para el modo automático de EKS](create-node-pool.md).
## Creación de una entrada de acceso a una clase de nodos
Si crea una clase de nodos personalizada, debe crear una entrada de acceso de EKS para permitir que los nodos se unan al clúster. EKS crea entradas de acceso automáticamente cuando se utilizan la clase de nodos y los grupos de nodos integrados.
Para obtener información sobre cómo funcionan las entradas de acceso, consulte [Concesión de acceso para los usuarios de IAM a las entradas de acceso de Kubernetes con EKS](access-entries.md).
Al crear entradas de acceso para las clases de nodos del modo automático de EKS, debe utilizar el tipo de entrada de acceso `EC2`.
### Creación de una entrada de acceso con la CLI
**Para crear una entrada de acceso para los nodos de EC2 y asociar la política de nodos automáticos de EKS:**
Actualice los siguientes comandos de la CLI con el nombre del clúster y el ARN del rol del nodo. El ARN del rol del nodo se especifica en la clase de nodo YAML.
```
# Create the access entry for EC2 nodes
aws eks create-access-entry \
--cluster-name \
--principal-arn \
--type EC2
# Associate the auto node policy
aws eks associate-access-policy \
--cluster-name \
--principal-arn \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy \
--access-scope type=cluster
```
### Creación de una entrada de acceso con CloudFormation
**Para crear una entrada de acceso para los nodos de EC2 y asociar la política de nodos automáticos de EKS:**
Actualice el siguiente ejemplo de CloudFormation con el nombre de su clúster y el ARN del rol del nodo. El ARN del rol del nodo se especifica en la clase de nodo YAML.
```
EKSAutoNodeRoleAccessEntry:
Type: AWS::EKS::AccessEntry
Properties:
ClusterName:
PrincipalArn:
Type: "EC2"
AccessPolicies:
- AccessScope:
Type: cluster
PolicyArn: arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy
DependsOn: [ ] # previously defined in CloudFormation
```
Para obtener información sobre la implementación de pilas de CloudFormation, consulte [Introducción a CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/GettingStarted.html).
## Especificación de clase de nodos
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Required fields
# role and instanceProfile are mutually exclusive fields.
role: MyNodeRole # IAM role for EC2 instances
# instanceProfile: eks-MyNodeInstanceProfile # IAM instance-profile for EC2 instances
subnetSelectorTerms:
- tags:
Name: "private-subnet"
kubernetes.io/role/internal-elb: "1"
# Alternative using direct subnet ID
# - id: "subnet-0123456789abcdef0"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
# Alternative approaches:
# - id: "sg-0123456789abcdef0"
# - name: "eks-cluster-security-group"
# Optional: Pod subnet selector for advanced networking
podSubnetSelectorTerms:
- tags:
Name: "pod-subnet"
kubernetes.io/role/pod: "1"
# Alternative using direct subnet ID
# - id: "subnet-0987654321fedcba0"
# must include Pod security group selector also
podSecurityGroupSelectorTerms:
- tags:
Name: "eks-pod-sg"
# Alternative using direct security group ID
# - id: "sg-0123456789abcdef0"
# Optional: Selects on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
Name: "targeted-odcr"
# Optional owning account ID filter
owner: "012345678901"
# Optional fields
snatPolicy: Random # or Disabled
networkPolicy: DefaultAllow # or DefaultDeny
networkPolicyEventLogs: Disabled # or Enabled
ephemeralStorage:
size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
iops: 3000 # Range: 3000-16000
throughput: 125 # Range: 125-1000
# Optional KMS key for encryption
kmsKeyID: "arn:aws:kms:region:account:key/key-id"
# Accepted formats:
# KMS Key ID
# KMS Key ARN
# Key Alias Name
# Key Alias ARN
advancedNetworking:
# Optional: Controls whether public IP addresses are assigned to instances that are launched with the nodeclass.
# If not set, defaults to the MapPublicIpOnLaunch setting on the subnet.
associatePublicIPAddress: false
# Optional: Forward proxy, commonly requires certificateBundles as well
# for EC2, see https://repost.aws/knowledge-center/eks-http-proxy-containerd-automation
httpsProxy: http://192.0.2.4:3128 #commonly port 3128 (Squid) or 8080 (NGINX) #Max 255 characters
#httpsProxy: http://[2001:db8::4]:3128 # IPv6 address with port, use []
noProxy: #Max 50 entries
- localhost #Max 255 characters each
- 127.0.0.1
#- ::1 # IPv6 localhost
#- 0:0:0:0:0:0:0:1 # IPv6 localhost
- 169.254.169.254 # EC2 Instance Metadata Service
#- [fd00:ec2::254] # IPv6 EC2 Instance Metadata Service
# Domains to exclude, put all VPC endpoints here
- .internal
- .eks.amazonaws.com
# ipv4PrefixSize is default to Auto which is prefix and fallback to secondary IP. "32" is the secondary IP mode.
ipv4PrefixSize: Auto # or "32"
# enableV4Egress is default to true. Setting it to false when using network policy or blocking IPv4 traffic in IPv6 clusters
enableV4Egress: false
advancedSecurity:
# Optional, US regions only: Specifying `fips: true` will cause nodes in the nodeclass to run FIPS compatible AMIs.
fips: false
# Optional: Custom certificate bundles.
certificateBundles:
- name: "custom-cert"
data: "base64-encoded-cert-data"
# Optional: Additional EC2 tags (with restrictions)
tags:
Environment: "production"
Team: "platform"
# Note: Cannot use restricted tags like:
# - kubernetes.io/cluster/*
# - karpenter.sh/provisioner-name
# - karpenter.sh/nodepool
# - karpenter.sh/nodeclaim
# - karpenter.sh/managed-by
# - eks.amazonaws.com/nodeclass
```
## Consideraciones
+ Si desea verificar cuánto almacenamiento local tiene una instancia, puede describir el nodo para ver el recurso de almacenamiento efímero.
+ **Cifrado de volumen**: EKS utiliza la clave de KMS personalizada configurada para cifrar el volumen raíz de solo lectura de la instancia y el volumen de datos de lectura/escritura.
+ **Sustitución del rol de IAM del nodo:** si cambia el rol de IAM del nodo asociado a una `NodeClass`, tendrá que crear una nueva entrada de acceso. EKS crea automáticamente una entrada de acceso para el rol de IAM del nodo durante la creación del clúster. El rol de IAM del nodo requiere la política de acceso de EKS `AmazonEKSAutoNodePolicy`. Para obtener más información, consulte [Concesión de acceso para los usuarios de IAM a las entradas de acceso de Kubernetes con EKS](access-entries.md).
+ **Densidad máxima de pods:** EKS limita la cantidad máxima de pods en un nodo a 110. Este límite se aplica después del cálculo de la cantidad máxima de pods existente. Para obtener más información, consulte [Elección de un tipo de instancia de nodo de Amazon EC2 óptimo](choosing-instance-type.md).
+ **Etiquetas**: si desea propagar etiquetas de Kubernetes a EC2, debe configurar permisos de IAM adicionales. Para obtener más información, consulte [Más información sobre las identidades y el acceso en el modo automático de EKS](auto-learn-iam.md).
+ **Clase de nodo predeterminada**: no asigne el nombre `default` a su clase de nodo personalizada. Esto se debe a que el modo automático de EKS incluye una `NodeClass` llamada `default` que se aprovisiona automáticamente cuando se habilita al menos una `NodePool` integrada. Para obtener más información sobre la activación de `NodePools` integrados, consulte [Cómo habilitar o desactivar los NodePools integrados](set-builtin-node-pools.md).
+ **Comportamiento de `subnetSelectorTerms` con varias subredes:** si hay varias subredes que coinciden con las condiciones de `subnetSelectorTerms` o que proporciona por ID, el modo automático de EKS crea nodos distribuidos entre las subredes.
+ Si las subredes se encuentran en diferentes zonas de disponibilidad (AZ), puede usar las características de Kubernetes, como las [restricciones de propagación de topología de pods](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#pod-topology-spread-constraints) y el [enrutamiento consciente de la topología](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/), para distribuir los pods y el tráfico entre las zonas, respectivamente.
+ Si hay varias subredes *en la misma AZ* que coincidan con `subnetSelectorTerms`, el modo automático de EKS crea pods en cada nodo distribuidos en las subredes de esa AZ. El modo automático de EKS crea interfaces de red secundarias en cada nodo de las demás subredes de la misma AZ. Elige en función del número de direcciones IP disponibles en cada subred, para utilizar las subredes de manera más eficiente. Sin embargo, no puede especificar qué subred usa el modo automático de EKS para cada pod; si necesita que los pods se ejecuten en subredes específicas, utilice [Subredes y grupos de seguridad independientes para pods](#pod-subnet-selector) en su lugar.
## Subredes y grupos de seguridad independientes para pods
Los campos `podSubnetSelectorTerms` y `podSecurityGroupSelectorTerms` permiten efectuar configuraciones de red avanzadas, ya que permiten que los pods se ejecuten en subredes y grupos de seguridad diferentes a los de sus nodos. Ambos campos deben especificarse juntos. Esta separación proporciona un mayor control sobre el enrutamiento del tráfico de la red y las políticas de seguridad.
**nota**
Esta característica es diferente de la característica [Grupos de seguridad para pods](security-groups-for-pods.md) (SGPP) que se utiliza con el CNI de VPC de AWS para la computación en modo automático que no es de EKS. El modo automático de EKS no admite SGPP. En su lugar, use `podSecurityGroupSelectorTerms` en `NodeClass` para aplicar grupos de seguridad independientes al tráfico del pod. Los grupos de seguridad se aplican a nivel `NodeClass`, es decir, todos los pods de los nodos que utilizan ese `NodeClass` comparten los mismos grupos de seguridad de pods.
### Funcionamiento
Cuando configura `podSubnetSelectorTerms` y `podSecurityGroupSelectorTerms`:
1. El ENI principal del nodo utiliza las subredes y los grupos de seguridad de `subnetSelectorTerms` y `securityGroupSelectorTerms`. Solo la dirección IP del nodo está asignada a esta interfaz.
1. El modo automático de EKS crea ENI secundarios en las subredes coincidentes con `podSubnetSelectorTerms`, con los grupos de seguridad de `podSecurityGroupSelectorTerms` asociados. Las direcciones IP de los pods se asignan desde estos ENI secundarios mediante prefijos /28 de forma predeterminada, y se recurre automáticamente a las IP secundarias (/32) cuando no hay un bloque de prefijos contiguo disponible. Si `ipv4PrefixSize` se establece en `"32"` en `advancedNetworking`, solo se utilizan las IP secundarias.
1. Los grupos de seguridad especificados en `podSecurityGroupSelectorTerms` se aplican al tráfico de pods dentro de la VPC. Para el tráfico destinado fuera de la VPC, los pods utilizan el ENI principal del nodo (y sus grupos de seguridad) porque la traducción de direcciones de red de origen (SNAT) traduce la IP del pod a la IP del nodo. Puede modificar este comportamiento con el campo `snatPolicy` de `NodeClass`.
### Casos de uso
Use `podSubnetSelectorTerms` y `podSecurityGroupSelectorTerms` cuando necesite:
+ Aplicar diferentes grupos de seguridad para controlar el tráfico de los nodos y los pods por separado.
+ Separar el tráfico de infraestructura (comunicación de nodo a nodo) del tráfico de aplicaciones (comunicación de pod a pod).
+ Aplicar configuraciones de red diferentes a las subredes de nodos que a las subredes de pods.
+ Configurar proxies inversos o filtrado de red específicamente para el tráfico de nodos sin afectar al tráfico de los pods. Utilizar `advancedNetworking` y `certificateBundles` para definir su proxy inverso y cualquier certificado autofirmado o privado para el proxy.
### Configuración de ejemplo
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
# Subnets and security groups for EC2 instances (nodes)
subnetSelectorTerms:
- tags:
Name: "node-subnet"
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
# Separate subnets and security groups for Pods
podSubnetSelectorTerms:
- tags:
Name: "pod-subnet"
kubernetes.io/role/pod: "1"
podSecurityGroupSelectorTerms:
- tags:
Name: "eks-pod-sg"
```
### Consideraciones para subredes y grupos de seguridad de pods independientes
+ **Ámbito del grupo de seguridad**: los grupos de seguridad de `podSecurityGroupSelectorTerms` están asociados a los ENI secundarios y se aplican al tráfico del pod dentro de la VPC. Cuando SNAT está habilitado (el valor predeterminado `snatPolicy: Random`), el tráfico que sale de la VPC se traduce a la dirección IP ENI principal del nodo, por lo que los grupos de seguridad `securityGroupSelectorTerms` del nodo se aplican a ese tráfico en su lugar. Si configura `snatPolicy: Disabled`, los pods utilizan sus propias direcciones IP para todo el tráfico y debe asegurarse de que los grupos de enrutamiento y seguridad estén configurados en consecuencia.
+ **Granularidad a nivel de NodeClass**: los grupos de seguridad de los pods se aplican a todos los pods programados en los nodos que utilizan `NodeClass`. Para aplicar diferentes grupos de seguridad a diferentes cargas de trabajo, cree recursos de `NodeClass` y `NodePool` independientes y utilice restricciones, tolerancias o selectores de nodos para programar las cargas de trabajo en los nodos correspondientes.
+ **Densidad de pods reducida**: se pueden ejecutar menos pods en cada nodo, ya que la interfaz de red principal del nodo está reservada para la IP del nodo y no se puede usar para los pods.
+ **Limitaciones del selector de subredes**: las configuraciones `subnetSelectorTerms` y `securityGroupSelectorTerms` estándar no se aplican a la selección de grupos de seguridad y subredes de los pods.
+ **Planificación de la red**: garantice un espacio de direcciones IP adecuado en las subredes de nodos y pods para satisfacer sus requisitos de carga de trabajo.
+ **Configuración de enrutamiento**: compruebe que la tabla de enrutamiento y la lista de control de acceso (ACL) de red de las subredes de pods estén configuradas correctamente para la comunicación entre las subredes de nodos y pods.
+ **Zonas de disponibilidad**: verifique que haya creado subredes de pods en varias AZ. Si está utilizando una subred de pod específica, debe estar en la misma AZ que la subred del nodo.
## Modo de IP secundaria para pods
Los campos `ipv4PrefixSize` permiten configuraciones de red avanzadas al asignar únicamente direcciones IP secundarias a los nodos. Esta característica no asigna prefijos (/28) a los nodos y mantiene solo una IP secundaria como MinimalIPTarget.
### Casos de uso
Use `ipv4PrefixSize` cuando necesite:
+ **Utilización reducida de IP**: solo se precalentará una dirección IP en cada nodo.
+ **Menor tasa de renovación de pods**: la velocidad de creación de pods no es una preocupación principal.
+ **Sin fragmentación de prefijos**: la fragmentación causada por prefijos representa una preocupación importante o un impedimento para utilizar el modo automático.
### Configuración de ejemplo
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
advancedNetworking:
ipv4PrefixSize: "32"
```
### Consideraciones para el modo de IP secundaria
+ **Velocidad reducida de creación de pods**: dado que solo se precalienta una IP secundaria, el servicio IPAM requiere más tiempo para aprovisionar direcciones IP cuando se crean pods adicionales.
## Desactivación de la salida IPv4 desde pods IPv6 en clústeres IPv6.
Los campos `enableV4Egress` es `true` de forma predeterminada. En clústeres IPv6 en modo automático, la característica se puede desactivar para que el modo automático no cree una interfaz IPv4 solo de salida para pods IPv6. Esto es importante porque la interfaz de salida IPv4 no está sujeta a la aplicación de la política de red. Las políticas de red solo se aplican en la interfaz principal del pod (eth0).
### Casos de uso
Use `enableV4Egress` cuando necesite:
+ **Uso de clúster IPv6**: el tráfico de salida IPv4 está permitido de forma predeterminada.
+ **Uso de políticas de red**: actualmente, la política de red de EKS no admite configuración de doble pila. La desactivación de `enableV4Egress` puede impedir que el tráfico del pod salga por IPv4 de forma inesperada.
### Configuración de ejemplo
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
advancedNetworking:
enableV4Egress: false
```
### Consideraciones para desactivar enableV4Egress
+ **Políticas de red en clústeres IPv6**: los clústeres IPv6 permiten tráfico IPv4 de forma predeterminada. Establecer `enableV4Egress: false` bloquea el tráfico de salida IPv4 y proporciona mayor seguridad, especialmente cuando se utiliza junto con políticas de red.
# Creación de un grupo de nodos para el modo automático de EKS
Los grupos de nodos de Amazon EKS ofrecen una forma flexible de administrar los recursos de computación del clúster de Kubernetes. En este tema se muestra cómo crear y configurar grupos de nodos mediante Karpenter, una herramienta de aprovisionamiento de nodos que ayuda a optimizar el escalado del clúster y el uso de los recursos. Con el recurso NodePool de Karpenter, puede definir requisitos específicos para los recursos de computación, como los tipos de instancias, las zonas de disponibilidad, las arquitecturas y los tipos de capacidad.
No puede modificar los grupos de nodos `system` y `general-purpose` integrados. No puede habilitarlos ni deshabilitarlos. Para obtener más información, consulte [Cómo habilitar o desactivar los NodePools integrados](set-builtin-node-pools.md).
La especificación NodePool permite un control detallado de los recursos de computación del clúster de EKS mediante diversas etiquetas y requisitos compatibles. Estas incluyen opciones para especificar las categorías de instancias de EC2, los ajustes de la CPU, las zonas de disponibilidad, las arquitecturas (ARM64 o AMD64) y los tipos de capacidad (spot o bajo demanda). También puede establecer límites de recursos para el uso de la CPU y la memoria, lo que garantiza que el clúster se mantenga dentro de los límites operativos necesarios.
El modo automático de EKS utiliza las conocidas etiquetas de Kubernetes para ofrecer formas uniformes y estandarizadas de identificar las características de los nodos. Estas etiquetas, como `topology.kubernetes.io/zone` de las zonas de disponibilidad y `kubernetes.io/arch` de la arquitectura de la CPU, siguen las convenciones establecidas de Kubernetes. Además, las etiquetas específicas de EKS (con el prefijo `eks.amazonaws.com/`) amplían esta funcionalidad con atributos específicos de AWS, como los tipos de instancias, los fabricantes de CPU, las capacidades de la GPU y las especificaciones de red. Este sistema de etiquetado estandarizado permite una integración perfecta con herramientas de Kubernetes existentes y, al mismo tiempo, proporciona una profunda integración de la infraestructura de AWS.
## Cómo crear un NodePool
Siga estos pasos para crear un NodePool para el clúster de Amazon EKS:
1. Cree un archivo YAML llamado `nodepool.yaml` con la configuración de NodePool necesaria. Puede usar la siguiente configuración de muestra.
1. Aplique el NodePool al clúster:
```
kubectl apply -f nodepool.yaml
```
1. Compruebe que el NodePool se haya creado correctamente:
```
kubectl get nodepools
```
1. (Opcional) Supervise el estado del NodePool:
```
kubectl describe nodepool default
```
Asegúrese de que el NodePool haga referencia a una NodeClass válida que exista en el clúster. La NodeClass define configuraciones específicas de AWS para los recursos de computación. Para obtener más información, consulte [Cómo crear una clase de nodos para Amazon EKS](create-node-class.md).
## NodePool de muestra
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
billing-team: my-team
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b"]
- key: "kubernetes.io/arch"
operator: In
values: ["arm64", "amd64"]
limits:
cpu: "1000"
memory: 1000Gi
```
## Etiquetas compatibles con el modo automático de EKS
El modo automático de EKS es compatible con las siguientes etiquetas conocidas.
**nota**
El modo automático de EKS utiliza etiquetas diferentes a las de Karpenter. Las etiquetas relacionadas con las instancias administradas por EC2 comienzan con `eks.amazonaws.com`.
| Etiqueta | Ejemplo | Descripción |
| --- | --- | --- |
| topology.kubernetes.io/zone | us-east-2a | Región AWS |
| node.kubernetes.io/instance-type | g4dn.8xlarge | Tipo de instancia AWS |
| kubernetes.io/arch | amd64 | Las arquitecturas se definen mediante [valores GOARCH](https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go#L58) de la instancia |
| karpenter.sh/capacity-type | spot | Los tipos de capacidad incluyen `spot` y `on-demand` |
| eks.amazonaws.com/instance-hypervisor | nitro | Tipos de instancias que usan un hipervisor específico |
| eks.amazonaws.com/compute-type | auto | Identifica los nodos administrados del modo automático de EKS |
| eks.amazonaws.com/instance-encryption-in-transit-supported | true | Tipos de instancias que admiten (o no) el cifrado en tránsito |
| eks.amazonaws.com/instance-category | g | Tipos de instancias de la misma categoría, generalmente la cadena antes del número de generación. |
| eks.amazonaws.com/instance-generation | 4 | Número de generación del tipo de instancia dentro de una categoría de instancias |
| eks.amazonaws.com/instance-family | g4dn | Tipos de instancias de propiedades similares, pero con diferentes cantidades de recursos |
| eks.amazonaws.com/instance-size | 8xlarge | Tipos de instancias con cantidades de recursos similares, pero con propiedades diferentes |
| eks.amazonaws.com/instance-cpu | 32 | Cantidad de CPU en la instancia |
| eks.amazonaws.com/instance-cpu-manufacturer | `aws` | Nombre del fabricante de la CPU |
| eks.amazonaws.com/instance-memory | 131072 | Cantidad de mebibytes de memoria de la instancia |
| eks.amazonaws.com/instance-ebs-bandwidth | 9500 | Cantidad [máxima de megabits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html#ebs-optimization-performance) de EBS disponibles en la instancia |
| eks.amazonaws.com/instance-network-bandwidth | 131072 | Cantidad de [megabits de referencia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html) disponibles en la instancia |
| eks.amazonaws.com/instance-gpu-name | t4 | Nombre de la GPU de la instancia, si está disponible |
| eks.amazonaws.com/instance-gpu-manufacturer | nvidia | Nombre del fabricante de la GPU |
| eks.amazonaws.com/instance-gpu-count | 1 | Cantidad de GPU en la instancia |
| eks.amazonaws.com/instance-gpu-memory | 16384 | Cantidad de mebibytes de memoria de la GPU |
| eks.amazonaws.com/instance-local-nvme | 900 | Cantidad de gibibytes de almacenamiento nvme local en la instancia |
**nota**
El modo automático de EKS solo es compatible con determinadas instancias y tiene requisitos de tamaño mínimo. Para obtener más información, consulte [Referencia de instancias compatibles con el modo automático de EKS](automode-learn-instances.md#auto-supported-instances).
## Etiquetas no compatibles con el modo automático de EKS
El modo automático de EKS no es compatible con las siguientes marcas.
+ El modo automático de EKS solo es compatible con Linux
+ `node.kubernetes.io/windows-build`
+ `kubernetes.io/os`
## Desactivación de los grupos de nodos integrados
Si crea grupos de nodos personalizados, puede deshabilitar los grupos de nodos integrados. Para obtener más información, consulte [Cómo habilitar o desactivar los NodePools integrados](set-builtin-node-pools.md).
## Clúster sin grupos de nodos integrados
Puede crear un clúster sin los grupos de nodos integrados. Esta opción resulta útil cuando la organización ha creado grupos de nodos personalizados.
**nota**
Al crear un clúster sin grupos de nodos integrados, la NodeClass `default` no se aprovisiona automáticamente. Deberá crear una NodeClass personalizada. Para obtener más información, consulte [Cómo crear una clase de nodos para Amazon EKS](create-node-class.md).
**Información general:**
1. Cree un clúster de EKS con los valores `nodePools` y `nodeRoleArn` vacíos.
+ Ejemplo de `autoModeConfig` de eksctl:
```
autoModeConfig:
enabled: true
nodePools: []
# Do not set a nodeRoleARN
```
Para obtener más información, consulte [Creación de un clúster de modo automático de EKS con la CLI de eksctl](automode-get-started-eksctl.md)
1. Creación de una clase de nodos personalizada con un ARN de rol del nodo
+ Para obtener más información, consulte [Cómo crear una clase de nodos para Amazon EKS](create-node-class.md)
1. Creación de una entrada de acceso para la clase de nodos personalizada
+ Para obtener más información, consulte [Creación de una entrada de acceso a una clase de nodos](create-node-class.md#auto-node-access-entry)
1. Creación de un grupo de nodos personalizado, como se ha descrito anteriormente.
## Interrupción
Puede configurar el modo automático de EKS para interrumpir los nodos que atraviesan su NodePool de varias formas. Puede utilizar `spec.disruption.consolidationPolicy`, `spec.disruption.consolidateAfter` o `spec.template.spec.expireAfter`. También puede limitar la frecuencia de las interrupciones del modo automático de EKS a través de `spec.disruption.budgets` del NodePool. También puede controlar los intervalos de tiempo y el número de nodos simultáneos interrumpidos. Para obtener instrucciones sobre cómo configurar este comportamiento, consulte [Disruption](https://karpenter.sh/docs/concepts/disruption/) en la documentación de Karpenter.
Puede configurar la interrupción de los grupos de nodos para:
+ Identificar cuándo están infrautilizadas las instancias y consolidar las cargas de trabajo.
+ Crear un presupuesto de interrupciones del grupo de nodos para limitar las terminaciones de nodos a causa de desviaciones, vacíos y consolidaciones.
De forma predeterminada, el modo automático de EKS:
+ Consolida las instancias infrautilizadas.
+ Termina las instancias después de 336 horas.
+ Establece un presupuesto único de interrupciones del 10 % de los nodos.
+ Permite reemplazar los nodos debido a la desviación cuando se lanza una nueva AMI en modo automático, lo que ocurre aproximadamente una vez por semana.
## Periodo de gracia por terminación
Cuando no se define explícitamente un `terminationGracePeriod` en el NodePool del modo automático de EKS, el sistema aplica automáticamente un periodo de gracia por terminación predeterminado de 24 horas al NodeClaim asociado. Si bien los clientes del modo automático de EKS no verán un `terminationGracePeriod` predeterminado en sus configuraciones personalizadas de NodePool, sí lo podrán ver en el NodeClaim. La funcionalidad permanece constante tanto si el periodo de gracia se establece explícitamente en el NodePool como si se establece de forma predeterminada en el NodeClaim, lo que garantiza un comportamiento predecible de terminación de nodos en todo el clúster.
# Grupos de nodos con capacidad estática en el modo automático de EKS
El modo automático de Amazon EKS admite grupos de nodos con capacidad estática que mantienen un número fijo de nodos independientemente de la demanda de los pods. Los grupos de nodos con capacidad estática son útiles para las cargas de trabajo que requieren una capacidad predecible, instancias reservadas o requisitos de cumplimiento específicos cuando es necesario mantener una huella de la infraestructura coherente.
A diferencia de los grupos de nodos dinámicos que escalan en función de las exigencias de programación de los pods, los grupos de nodos con capacidad estática mantienen la cantidad de nodos que ha configurado.
## Configuración de un grupo de nodos con capacidad estática
Para crear un grupo de nodos con capacidad estática, defina el campo `replicas` en la especificación de NodePool. El campo `replicas` define el número exacto de nodos que conservará el grupo de nodos. Consulte [Ejemplos](#static-capacity-examples) para saber cómo configurar `replicas`.
## Consideraciones de los grupos de nodos con capacidad estática
Los grupos de nodos con capacidad estática tienen varias restricciones y comportamientos importantes:
**Restricciones de configuración:**
+ **No se puede cambiar de modo**: una vez que haya configurado `replicas` en un grupo de nodos, no puede eliminarlo. El grupo de nodos no puede cambiar entre los modos estático y dinámico.
+ **Límites de recursos limitados**: solo se admite el campo `limits.nodes` en la sección de límites. Los límites de CPU y memoria no son aplicables.
+ **Campo sin peso**: el campo `weight` no se puede configurar en grupos de nodos con capacidad estática, ya que la selección de nodos no se basa en la prioridad.
**Comportamiento operativo:**
+ **Sin consolidación**: los nodos de los grupos con capacidad estática no se tienen en cuenta para la consolidación en función del uso.
+ **Operaciones de escalado**: las operaciones de escalado eluden los presupuestos de interrupción de nodos, pero siguen respetando los PodDisruptionBudgets.
+ **Sustitución de nodos**: los nodos se siguen sustituyendo por desviación (como las actualizaciones de la AMI) y vencimiento en función de la configuración.
## Prácticas recomendadas
**Planificación de la capacidad:**
+ Establezca un valor de `limits.nodes` superior a `replicas` para permitir el escalado temporal durante las operaciones de sustitución de nodos.
+ Tenga en cuenta la capacidad máxima necesaria durante la desviación de nodos o las actualizaciones de la AMI al establecer los límites.
**Selección de instancias:**
+ Utilice tipos de instancias específicos cuando tenga instancias reservadas o requisitos de hardware específicos.
+ Evite los requisitos demasiado restrictivos que puedan limitar la disponibilidad de las instancias durante el escalado.
**Administración de interrupciones:**
+ Configure los presupuestos de interrupciones adecuados para equilibrar la disponibilidad con las operaciones de mantenimiento.
+ Tenga en cuenta la tolerancia de la aplicación con respecto a la sustitución de nodos al establecer los porcentajes del presupuesto.
**Supervisión de:**
+ Supervise el campo `status.nodes` periódicamente para garantizar que se mantenga la capacidad deseada.
+ Configure alertas para cuando el recuento real de nodos se desvíe de las réplicas deseadas.
**Distribución en zonas:**
+ Distribuya la capacidad estática en varias zonas de disponibilidad para una mayor disponibilidad.
+ Al crear un grupo de nodos con capacidad estática que abarca varias zonas de disponibilidad, el modo automático de EKS distribuye los nodos entre las zonas especificadas, pero no se garantiza que la distribución sea uniforme.
+ Para lograr una distribución predecible y uniforme entre las zonas de disponibilidad, cree grupos de nodos con capacidad estática independientes, cada uno fijado a una zona de disponibilidad específica según el requisito `topology.kubernetes.io/zone`.
+ Si necesita 12 nodos distribuidos uniformemente en 3 zonas, cree 3 grupos de nodos con 4 réplicas cada uno, en lugar de un grupo de nodos con 12 réplicas en 3 zonas.
## Escalado de un grupo de nodos con capacidad estática
Puede cambiar el número de réplicas de un grupo de nodos con capacidad estática mediante el comando `kubectl scale`:
```
# Scale down to 5 nodes
kubectl scale nodepool static-nodepool --replicas=5
```
Al reducir verticalmente, el modo automático de EKS terminará los nodos correctamente: respetará los PodDisruptionBudgets y permitirá reprogramar los pods en ejecución para los nodos restantes.
## Supervisión de grupos de nodos con capacidad estática
Utilice los siguientes comandos para supervisar los grupos de nodos con capacidad estática:
```
# View node pool status
kubectl get nodepool static-nodepool
# Get detailed information including current node count
kubectl describe nodepool static-nodepool
# Check the current number of nodes
kubectl get nodepool static-nodepool -o jsonpath='{.status.nodes}'
```
El campo `status.nodes` muestra el número actual de nodos administrados por el grupo de nodos, que debería coincidir con el recuento de `replicas` deseado en condiciones normales.
## Solución de problemas
**Nodos que no llegan a las réplicas deseadas:**
+ Compruebe si el valor de `limits.nodes` es suficiente.
+ Compruebe que los requisitos no restrinjan demasiado la selección de instancias.
+ Revise las AWS Service Quotas para los tipos de instancias y las regiones que utiliza.
**Sustitución del nodo que tarda demasiado tiempo:**
+ Ajuste los presupuestos de interrupción para permitir más sustituciones simultáneas.
+ Compruebe si los PodDisruptionBudgets impiden la terminación del nodo.
**Terminación inesperada del nodo:**
+ Revise las configuraciones `expireAfter` y `terminationGracePeriod`.
+ Compruebe si hay terminaciones manuales del nodo o eventos de mantenimiento de AWS.
## Ejemplos
### Grupo de nodos básico con capacidad estática
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: basic-static
spec:
replicas: 5
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["m"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a"]
limits:
nodes: 8 # Allow scaling up to 8 during operations
```
### Capacidad estática con tipos de instancias específicos
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: reserved-instances
spec:
replicas: 20
template:
metadata:
labels:
instance-type: reserved
cost-center: production
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "node.kubernetes.io/instance-type"
operator: In
values: ["m5.2xlarge"] # Specific instance type
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
limits:
nodes: 25
disruption:
# Conservative disruption for production workloads
budgets:
- nodes: 10%
```
### Grupo de nodos con capacidad estática multizona
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: multi-zone-static
spec:
replicas: 12 # Will be distributed across specified zones
template:
metadata:
labels:
availability: high
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["8", "16"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
limits:
nodes: 15
disruption:
budgets:
- nodes: 25%
```
### Capacidad estática con reserva de capacidad
En el siguiente ejemplo se muestra cómo utilizar un grupo de nodos con capacidad estática con una reserva de capacidad de EC2. Para obtener más información sobre el uso de las reservas de capacidad de EC2 con el modo automático de EKS, consulte [Control de la implementación de las cargas de trabajo en las reservas de capacidad con el modo automático de EKS](auto-odcr.md).
`NodeClass` que define `capacityReservationSelectorTerms`
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: capacity-reservation-nodeclass
spec:
role: AmazonEKSNodeRole
securityGroupSelectorTerms:
- id: sg-0123456789abcdef0
subnetSelectorTerms:
- id: subnet-0123456789abcdef0
capacityReservationSelectorTerms:
- id: cr-0123456789abcdef0
```
`NodePool` que hace referencia al `NodeClass` anterior y utiliza `karpenter.sh/capacity-type: reserved`.
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: static-capacity-reservation-nodepool
spec:
replicas: 5
limits:
nodes: 8 # Allow scaling up to 8 during operations
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: capacity-reservation-nodeclass
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ['reserved']
```
# Creación de una IngressClass para configurar el equilibrador de carga de aplicación
El modo automático de EKS automatiza las tareas rutinarias de equilibrio de carga, incluida la exposición de las aplicaciones del clúster a Internet.
AWS sugiere usar equilibradores de carga de aplicación (ALB) para atender el tráfico HTTP y HTTPS. Los equilibradores de carga de aplicación pueden dirigir las solicitudes en función del contenido de la solicitud. Para obtener más información sobre los equilibradores de carga de aplicación, consulte [¿Qué es un equilibrador de carga de aplicación?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
El modo automático de EKS crea y configura equilibradores de carga de aplicación (ALB). Por ejemplo, el modo automático de EKS crea un equilibrador de carga cuando se crea un objeto de Kubernetes de `Ingress` y lo configura de modo que dirija el tráfico a la carga de trabajo del clúster.
**Información general**
1. Cree una carga de trabajo que desea exponer a Internet.
1. Cree un recurso de `IngressClassParams` y especifique los valores de configuración específicos de AWS, como el certificado que se utilizará para SSL/TLS y las subredes de la VPC.
1. Cree un recurso de `IngressClass` y especifique que el modo automático de EKS será el controlador del recurso.
1. Cree un recurso de `Ingress` que asocie una ruta HTTP y un puerto a una carga de trabajo de clúster.
El modo automático de EKS creará un equilibrador de carga de aplicación que apunte a la carga de trabajo especificada en el recurso de `Ingress`, con la configuración del equilibrador de carga especificada en el recurso de `IngressClassParams`.
## Requisitos previos
+ El modo automático de EKS habilitado en un clúster de Amazon EKS
+ Kubectl configurado para establecer conexión con el clúster
+ Puede utilizar `kubectl apply -f ` para aplicar al clúster los archivos YAML de configuración de ejemplo que aparecen a continuación.
**nota**
El modo automático de EKS requiere etiquetas de subred para identificar las subredes públicas y privadas.
Si creó el clúster con `eksctl`, ya dispone de estas etiquetas.
Información sobre cómo [Etiquetado de subredes para el modo automático de EKS](tag-subnets-auto.md).
## Paso 1: creación de una carga de trabajo
Para comenzar, cree una carga de trabajo que desee exponer a Internet. Puede ser cualquier recurso de Kubernetes que sirva tráfico HTTP, como una implementación o un servicio.
En este ejemplo, se utiliza un servicio HTTP simple llamado `service-2048` que escucha en el puerto `80`. Para crear este servicio y su implementación, aplique el siguiente manifiesto, `2048-deployment-service.yaml`:
```
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 2
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: app-2048
```
Aplique la configuración al clúster:
```
kubectl apply -f 2048-deployment-service.yaml
```
Los recursos enumerados anteriormente se crearán en el espacio de nombres predeterminado. Para verificarlo, ejecute el siguiente comando:
```
kubectl get all -n default
```
## Paso 2: creación de IngressClassParams
Cree un objeto de `IngressClassParams` para especificar opciones de configuración específicas de AWS para el equilibrador de carga de aplicación. En este ejemplo, creamos un recurso `IngressClassParams` denominado `alb` (que utilizará en el siguiente paso) que especifica el esquema del equilibrador de carga, tal como se muestra `internet-facing` en un archivo llamado `alb-ingressclassparams.yaml`.
```
apiVersion: eks.amazonaws.com/v1
kind: IngressClassParams
metadata:
name: alb
spec:
scheme: internet-facing
```
Aplique la configuración al clúster:
```
kubectl apply -f alb-ingressclassparams.yaml
```
## Paso 3: creación de IngressClass
Cree una `IngressClass` que haga referencia a los valores de configuración específicos de AWS establecidos en el recurso `IngressClassParams` en un archivo llamado `alb-ingressclass.yaml`. Anote el nombre de la `IngressClass`. En este ejemplo, se asigna el nombre de `alb` tanto a la `IngressClass` como a los `IngressClassParams`.
Utilice la anotación `is-default-class` para controlar si los recursos de `Ingress` deben usar esta clase de forma predeterminada.
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: alb
annotations:
# Use this annotation to set an IngressClass as Default
# If an Ingress doesn't specify a class, it will use the Default
ingressclass.kubernetes.io/is-default-class: "true"
spec:
# Configures the IngressClass to use EKS Auto Mode
controller: eks.amazonaws.com/alb
parameters:
apiGroup: eks.amazonaws.com
kind: IngressClassParams
# Use the name of the IngressClassParams set in the previous step
name: alb
```
Para obtener más información acerca de las opciones de configuración, consulte [Referencia de IngressClassParams](#ingress-reference).
Aplique la configuración al clúster:
```
kubectl apply -f alb-ingressclass.yaml
```
## Paso 4: creación del ingreso
Cree un recurso `Ingress` en un archivo llamado `alb-ingress.yaml`. El propósito de este recurso es asociar las rutas y los puertos del equilibrador de carga de aplicación a las cargas de trabajo del clúster. Para este ejemplo, creamos un recurso `Ingress` denominado `2048-ingress` que enruta el tráfico a un servicio denominado `service-2048` en el puerto 80.
Para obtener más información sobre la configuración de este recurso, consulte [Ingreso](https://kubernetes.io/docs/concepts/services-networking/ingress/) en la documentación de Kubernetes.
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: 2048-ingress
spec:
# this matches the name of IngressClass.
# this can be omitted if you have a default ingressClass in cluster: the one with ingressclass.kubernetes.io/is-default-class: "true" annotation
ingressClassName: alb
rules:
- http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: service-2048
port:
number: 80
```
Aplique la configuración al clúster:
```
kubectl apply -f alb-ingress.yaml
```
## Paso 5: comprobación del estado
Utilice `kubectl` para encontrar el estado de `Ingress`. El equilibrador de carga puede tardar unos minutos en estar disponible.
Utilice el nombre del recurso de `Ingress` que definió en el paso anterior. Por ejemplo:
```
kubectl get ingress 2048-ingress
```
Una vez que el recurso esté listo, recupere el nombre de dominio del equilibrador de carga.
```
kubectl get ingress 2048-ingress -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
```
Para ver el servicio en un navegador web, revise el puerto y la ruta especificados en el recurso de `Ingress`.
## Paso 6: Efectúe una limpieza
Para limpiar el equilibrador de carga, utilice el siguiente comando:
```
kubectl delete ingress 2048-ingress
kubectl delete ingressclass alb
kubectl delete ingressclassparams alb
```
El modo automático de EKS eliminará automáticamente el equilibrador de carga asociado en la cuenta de AWS.
## Referencia de IngressClassParams
La siguiente tabla es una referencia rápida de las opciones de configuración que se utilizan con mayor frecuencia.
| Campo | Descripción | Ejemplo de valor |
| --- | --- | --- |
| `scheme` | Define si el equilibrador de carga de aplicación es interno o está orientado a Internet | `internet-facing` |
| `namespaceSelector` | Restringe los espacios de nombres que pueden usar esta IngressClass | `environment: prod` |
| `group.name` | Agrupa varios ingresos para compartir un único equilibrador de carga de aplicación | `retail-apps` |
| `ipAddressType` | Establece el tipo de dirección IP para el equilibrador de carga de aplicación | `dualstack` |
| `subnets.ids` | Lista de identificadores de subred para la implementación del equilibrador de carga de aplicación | `subnet-xxxx, subnet-yyyy` |
| `subnets.tags` | Etiquete los filtros para seleccionar las subredes del equilibrador de carga de aplicación | `Environment: prod` |
| `certificateARNs` | Los ARN de los certificados SSL que se van a utilizar | ` arn:aws:acm:region:account:certificate/id` |
| `tags` | Etiquetas personalizadas para los recursos de AWS | `Environment: prod, Team: platform` |
| `loadBalancerAttributes` | Atributos específicos del equilibrador de carga | `idle_timeout.timeout_seconds: 60` |
## Consideraciones
+ No puede usar las anotaciones en una IngressClass para configurar los equilibradores de carga con el modo automático de EKS. La configuración de IngressClass debe realizarse a través de IngressClassParams. Sin embargo, puede usar anotaciones en los recursos de entrada individuales para configurar el comportamiento del equilibrador de carga (por ejemplo, `alb.ingress.kubernetes.io/security-group-prefix-lists` o `alb.ingress.kubernetes.io/conditions.*`).
+ No puede configurar [ListenerAttribute](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_ListenerAttribute.html) con el Modo automático de EKS.
+ Debe actualizar el rol de IAM del clúster para permitir la propagación de etiquetas desde Kubernetes a los recursos del equilibrador de carga de AWS. Para obtener más información, consulte [Etiquetas personalizadas de AWS para los recursos del modo automático de EKS](auto-learn-iam.md#tag-prop).
+ Para obtener información sobre la asociación de recursos con el modo automático de EKS o con el controlador del equilibrador de carga de AWS autoadministrado, consulte [Referencia para las migraciones](migrate-auto.md#migration-reference).
+ Para obtener información sobre cómo solucionar problemas con los equilibradores de carga, consulte [Solución de problemas del modo automático de EKS](auto-troubleshoot.md).
+ Para conocer más aspectos a tener en cuenta a la hora de utilizar la capacidad de equilibrio de carga del modo automático de EKS, consulte [Equilibrio de carga](auto-networking.md#auto-lb-consider).
Las siguientes tablas proporcionan una comparación detallada de los cambios en las configuraciones de IngressClassParams, Ingress Annotations y TargetGroupBinding para el modo automático de EKS. Estas tablas destacan las principales diferencias entre la capacidad de equilibrio de carga del modo automático de EKS y el controlador del equilibrador de carga de código abierto, incluidos los cambios en la versión de la API, las características obsoletas y la actualización de los nombres de los parámetros.
### IngressClassParams
| Anteriores | New | Descripción |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Cambio de versión de la API |
| `spec.certificateArn` | `spec.certificateARNs` | Compatibilidad con múltiples ARN de certificados |
| `spec.subnets.tags` | `spec.subnets.matchTags` | Se modificó el esquema de coincidencia de subredes |
| `spec.listeners.listenerAttributes` | No admitido | Etiquetas que aún no son compatibles con el Modo automático de EKS |
### Anotaciones de ingreso
| Anteriores | New | Descripción |
| --- | --- | --- |
| `kubernetes.io/ingress.class` | No admitido | Utilice `spec.ingressClassName` en objetos de ingreso |
| `alb.ingress.kubernetes.io/group.name` | No admitido | Especifique grupos en IngressClass únicamente |
| `alb.ingress.kubernetes.io/waf-acl-id` | No admitido | En su lugar, utilice WAF v2 |
| `alb.ingress.kubernetes.io/web-acl-id` | No admitido | En su lugar, utilice WAF v2 |
| `alb.ingress.kubernetes.io/shield-advanced-protection` | No admitido | Integración de Shield desactivada |
| `alb.ingress.kubernetes.io/auth-type: oidc` | No admitido | Actualmente, no se admite el tipo de autenticación OIDC |
### TargetGroupBinding
| Anteriores | New | Descripción |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Cambio de versión de la API |
| `spec.targetType` opcional | `spec.targetType` obligatorio | Especificación explícita del tipo de destino |
| `spec.networking.ingress.from` | No admitido | Ya no es compatible con equilibradores de carga de red sin grupos de seguridad |
Para utilizar la característica TargetGroupBinding personalizada, debe etiquetar el grupo de destino con la etiqueta eks:eks-cluster-name con el nombre del clúster para conceder al controlador los permisos de IAM necesarios. Tenga en cuenta que el controlador eliminará el grupo de destino cuando se elimine el recurso TargetGroupBinding o el clúster.
# Cómo utilizar las anotaciones de servicio para configurar los equilibradores de carga de red
Aprenda a configurar los equilibradores de carga de red (NLB) en Amazon EKS mediante anotaciones de servicio de Kubernetes. En este tema se explican las anotaciones que admite el modo automático de EKS para personalizar el comportamiento de los NLB, incluidos los modos de accesibilidad a Internet, las comprobaciones de estado, la terminación de SSL/TLS y la segmentación por IP.
Al crear un servicio de Kubernetes de tipo `LoadBalancer` en el modo automático de EKS, EKS aprovisiona y configura automáticamente un equilibrador de carga de red de AWS en función de las anotaciones que especifique. Este enfoque declarativo permite administrar las configuraciones del equilibrador de carga directamente a través de los manifiestos de Kubernetes, manteniendo las prácticas de infraestructura como código.
El modo automático de EKS administra el aprovisionamiento del equilibrador de carga de red de forma predeterminada para todos los servicios del tipo LoadBalancer, sin necesidad de instalar ni configurar ningún controlador adicional. La especificación `loadBalancerClass: eks.amazonaws.com/nlb` se establece automáticamente como la predeterminada del clúster, lo que agiliza el proceso de implementación y garantiza la compatibilidad con las cargas de trabajo de Kubernetes existentes.
**nota**
El modo automático de EKS requiere etiquetas de subred para identificar las subredes públicas y privadas.
Si creó el clúster con `eksctl`, ya dispone de estas etiquetas.
Información sobre cómo [Etiquetado de subredes para el modo automático de EKS](tag-subnets-auto.md).
## Ejemplo de servicio
Para obtener más información sobre el recurso `Service` de Kubernetes, consulte la [documentación de Kubernetes](https://kubernetes.io/docs/concepts/services-networking/service/).
Revise el recurso de `Service` de muestra que aparece a continuación:
```
apiVersion: v1
kind: Service
metadata:
name: echoserver
annotations:
# Specify the load balancer scheme as internet-facing to create a public-facing Network Load Balancer (NLB)
service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
spec:
selector:
app: echoserver
ports:
- port: 80
targetPort: 8080
protocol: TCP
type: LoadBalancer
# Specify the new load balancer class for NLB as part of EKS Auto Mode feature
# For clusters with Auto Mode enabled, this field can be omitted as it's the default
loadBalancerClass: eks.amazonaws.com/nlb
```
## Anotaciones de uso frecuente
En la siguiente tabla se enumeran las anotaciones más utilizadas compatibles con el modo automático de EKS. Tenga en cuenta que es posible que el modo automático de EKS no admita todas las anotaciones.
**sugerencia**
Todas las anotaciones que aparecen a continuación deben ir precedidas de `service.beta.kubernetes.io/`
| Campo | Descripción | Ejemplo |
| --- | --- | --- |
| `aws-load-balancer-type` | Especifica el tipo de equilibrador de carga. Utilice `external` para nuevas implementaciones. | `external` |
| `aws-load-balancer-nlb-target-type` | Especifica si se debe dirigir el tráfico a las instancias de los nodos o directamente a las IP de los pods. Utilice `instance` para implementaciones estándar o `ip` para el enrutamiento directo a los pods. | `instance` |
| `aws-load-balancer-scheme` | Controla si el equilibrador de carga es interno o está expuesto a Internet. | `internet-facing` |
| `aws-load-balancer-healthcheck-protocol` | Protocolo de comprobación de estado correspondiente al grupo de destino. Las opciones más comunes son `TCP` (predeterminada) o `HTTP`. | `HTTP` |
| `aws-load-balancer-healthcheck-path` | La ruta HTTP para las comprobaciones de estado cuando se utiliza el protocolo HTTP/HTTPS. | `/healthz` |
| `aws-load-balancer-healthcheck-port` | El puerto que se utiliza para las comprobaciones de estado. Puede ser un número de puerto específico o `traffic-port`. | `traffic-port` |
| `aws-load-balancer-subnets` | Especifica en qué subredes se va a crear el equilibrador de carga. Puede usar nombres o ID de subred. | `subnet-xxxx, subnet-yyyy` |
| `aws-load-balancer-ssl-cert` | ARN del certificado SSL de AWS Certificate Manager para HTTPS/TLS. | ` arn:aws:acm:region:account:certificate/cert-id` |
| `aws-load-balancer-ssl-ports` | Especifica qué puertos deben usar SSL/TLS. | `443, 8443` |
| `load-balancer-source-ranges` | Los rangos de CIDR permiten acceder al equilibrador de carga. | `10.0.0.0/24, 192.168.1.0/24` |
| `aws-load-balancer-additional-resource-tags` | Etiquetas de AWS adicionales para aplicarlas al equilibrador de carga y a los recursos relacionados. | `Environment=prod,Team=platform` |
| `aws-load-balancer-ip-address-type` | Especifica si el equilibrador de carga usa IPv4 o pila dual (IPv4 \$1 IPv6). | `ipv4` o `dualstack` |
## Consideraciones
+ Debe actualizar el rol de IAM del clúster para permitir la propagación de etiquetas desde Kubernetes a los recursos del equilibrador de carga de AWS. Para obtener más información, consulte [Etiquetas personalizadas de AWS para los recursos del modo automático de EKS](auto-learn-iam.md#tag-prop).
+ Para obtener información sobre la asociación de recursos con el modo automático de EKS o con el controlador del equilibrador de carga de AWS autoadministrado, consulte [Referencia para las migraciones](migrate-auto.md#migration-reference).
+ Para obtener información sobre cómo solucionar problemas con los equilibradores de carga, consulte [Solución de problemas del modo automático de EKS](auto-troubleshoot.md).
+ Para conocer más aspectos a tener en cuenta a la hora de utilizar la capacidad de equilibrio de carga del modo automático de EKS, consulte [Equilibrio de carga](auto-networking.md#auto-lb-consider).
Al migrar al modo automático de EKS para el equilibrio de carga, es necesario realizar varios cambios en las anotaciones de servicio y las configuraciones de recursos. En las tablas que aparecen a continuación se describen las principales diferencias entre las implementaciones anteriores y las nuevas, incluidas las opciones no compatibles y las alternativas recomendadas.
### Anotaciones del servicio
| Anteriores | New | Descripción |
| --- | --- | --- |
| `service.beta.kubernetes.io/load-balancer-source-ranges` | No admitido | Utilice `spec.loadBalancerSourceRanges` en el servicio |
| `service.beta.kubernetes.io/aws-load-balancer-type` | No admitido | Utilice `spec.loadBalancerClass` en el servicio |
| `service.beta.kubernetes.io/aws-load-balancer-internal` | No admitido | Uso de `service.beta.kubernetes.io/aws-load-balancer-scheme` |
| `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol` | No admitido | En su lugar, use `service.beta.kubernetes.io/aws-load-balancer-target-group-attributes` |
| Varios atributos del equilibrador de carga | No admitido | Uso de `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled` | No admitido | En su lugar, use `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` | No admitido | En su lugar, use `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix` | No admitido | En su lugar, use `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled` | No admitido | En su lugar, use `service.beta.kubernetes.io/aws-load-balancer-attributes` |
Para migrar desde anotaciones de atributos del equilibrador de cargas obsoletas, consolide estos ajustes en la anotación `service.beta.kubernetes.io/aws-load-balancer-attributes`. Esta anotación acepta una lista separada por comas de pares de clave y valor para varios atributos del equilibrador de carga. Por ejemplo, para especificar el registro de acceso y el equilibrio de carga entre zonas, utilice el siguiente formato:
```
service.beta.kubernetes.io/aws-load-balancer-attributes: access_logs.s3.enabled=true,access_logs.s3.bucket=my-bucket,access_logs.s3.prefix=my-prefix,load_balancing.cross_zone.enabled=true
```
Este formato consolidado proporciona una forma más coherente y flexible de configurar los atributos del equilibrador de carga y, al mismo tiempo, reduce la cantidad de anotaciones individuales necesarias. Revise las configuraciones de servicio existentes y actualícelas para usar este formato consolidado.
### TargetGroupBinding
| Anteriores | New | Descripción |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Cambio de versión de la API |
| `spec.targetType` opcional | `spec.targetType` obligatorio | Especificación explícita del tipo de destino |
| `spec.networking.ingress.from` | No admitido | Ya no es compatible con equilibradores de carga de red sin grupos de seguridad |
Nota: Para utilizar la característica TargetGroupBinding personalizada, debe etiquetar el grupo de destino con la etiqueta `eks:eks-cluster-name` con el nombre del clúster para conceder al controlador los permisos de IAM necesarios. Tenga en cuenta que el controlador eliminará el grupo de destino cuando se elimine el recurso TargetGroupBinding o el clúster.
# Creación de una clase de almacenamiento
Una `StorageClass` en el modo automático de EKS define cómo se aprovisionan automáticamente los volúmenes de Amazon EBS cuando las aplicaciones solicitan almacenamiento persistente. En esta página se explica cómo crear y configurar una `StorageClass` que funcione con el modo automático de Amazon EKS para aprovisionar volúmenes de EBS.
Al configurar una `StorageClass`, puede especificar la configuración predeterminada para los volúmenes de EBS, incluidos el tipo de volumen, el cifrado, las IOPS y otros parámetros de almacenamiento. También puede configurar `StorageClass` para que utilice claves de AWS KMS para la administración del cifrado.
El modo automático de EKS no crea una `StorageClass` en su nombre. Debe crear una `StorageClass` que haga referencia a `ebs.csi.eks.amazonaws.com` para utilizar la capacidad de almacenamiento del modo automático de EKS.
Primero, cree un archivo denominado `storage-class.yaml`:
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
allowedTopologies:
- matchLabelExpressions:
- key: eks.amazonaws.com/compute-type
values:
- auto
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
En segundo lugar, aplique la clase de almacenamiento al clúster.
```
kubectl apply -f storage-class.yaml
```
**Componentes principales:**
+ `provisioner: ebs.csi.eks.amazonaws.com`: utiliza el modo automático de EKS
+ `allowedTopologies`: al especificar `matchLabelExpressions` para que coincida con `eks.amazonaws.com/compute-type:auto`, se asegurará de que los pods no se programarán en nodos no automáticos si sus pods necesitan que un volumen se aprovisione automáticamente con el Modo automático.
+ `volumeBindingMode: WaitForFirstConsumer`: retrasa la creación del volumen hasta que un pod lo necesite
+ `type: gp3`: especifica el tipo de volumen de EBS
+ `encrypted: "true"`: EBS cifrará todos los volúmenes creados con la `StorageClass`. EBS utilizará el alias de clave de `aws/ebs` predeterminado. Para obtener más información, consulte [Cómo funciona el cifrado de Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/how-ebs-encryption-works.html) en la Guía del usuario de Amazon EBS. Este valor es opcional, pero recomendado.
+ `storageclass.kubernetes.io/is-default-class: "true"`: Kubernetes utilizará esta clase de almacenamiento de forma predeterminada, a menos que se especifique una clase de volumen diferente en una reclamación de volumen persistente. Este valor es opcional. Tenga cuidado al establecer este valor si va a migrar desde un controlador de almacenamiento diferente.
## Utilice una clave de KMS autoadministrada para cifrar los volúmenes de EBS
Para utilizar una clave de KMS autoadministrada para cifrar los volúmenes de EBS automatizados mediante el modo automático de EKS, deberá:
1. Crear una clave de KMS autoadministrada.
+ Para obtener más información, consulte [Cómo crear una clave de KMS de cifrado simétrico](https://docs.aws.amazon.com/kms/latest/developerguide/create-symmetric-cmk.html) o [Cómo Amazon Elastic Block Store (Amazon EBS) usa KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services-ebs.html) en la Guía del usuario de KMS.
1. Cree una nueva política que permita el acceso a la clave de KMS.
+ Utilice la política de IAM de muestra que aparece a continuación para crear la política. Inserte el ARN de la nueva clave de KMS autoadministrada. Para obtener más información, consulte [Cómo crear roles y asociar políticas (consola)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html) en la Guía de usuario de IAM AWS.
1. Asocie la política al rol de clúster de EKS.
+ Utilice la consola de AWS para buscar el ARN del rol de clúster de EKS. La información del rol aparece en la sección **Descripción general**. Para obtener más información, consulte [Rol de IAM del clúster de Amazon EKS](cluster-iam-role.md).
1. Actualice la `StorageClass` de modo que haga referencia al ID de la clave de KMS en el campo `parameters.kmsKeyId`.
### Ejemplo de política de IAM de KMS autoadministrada
Actualice los siguientes valores de la política que aparece a continuación:
+ ``: el ID de la cuenta de AWS, como `111122223333`
+ ``: la región de AWS del clúster, como `us-west-2`
```
{
"Version":"2012-10-17",
"Id": "key-auto-policy-3",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow access through EBS for all principals in the account that are authorized to use EBS",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:CallerAccount": "123456789012",
"kms:ViaService": "ec2.us-east-1.amazonaws.com"
}
}
}
]
}
```
### Ejemplo de `StorageClass` de KMS autoadministrada
```
parameters:
type: gp3
encrypted: "true"
kmsKeyId:
```
## Referencia de los parámetros de `StorageClass`
Para obtener información general sobre los recursos de `StorageClass` de Kubernetes, consulte [Clases de almacenamiento](https://kubernetes.io/docs/concepts/storage/storage-classes/) en la documentación de Kubernetes.
La sección `parameters` del recurso `StorageClass` es específica de AWS. Utilice la siguiente tabla para revisar las opciones disponibles.
| Parameters | Valores | Predeterminado | Descripción |
| --- | --- | --- | --- |
| “csi.storage.k8s.io/fstype” | xfs, ext2, ext3, ext4 | ext4 | Tipo de sistema de archivos que se formateará durante la creación del volumen. Este parámetro distingue entre mayúsculas y minúsculas. |
| “tipo” | io1, io2, gp2, gp3, sc1, st1, standard, sbp1, sbg1 | gp3 | Tipo de volumen de EBS. |
| “iopsPerGB” | | | Operaciones de E/S por segundo por GiB. Se puede especificar para los volúmenes IO1, IO2 y GP3. |
| “allowAutoIOPSPerGBIncrease” | true, false | false | Si es `"true"`, el controlador CSI aumenta las IOPS de un volumen si `iopsPerGB * ` es demasiado bajo para ajustarse en el rango de IOPS admitido por AWS. Esto permite que el aprovisionamiento dinámico siempre se realice correctamente, incluso si el usuario especifica una capacidad de PVC o un valor de `iopsPerGB` demasiado bajo. Por otro lado, esto puede generar costos adicionales, ya que dichos volúmenes tienen IOPS más altas que las solicitadas en `iopsPerGB`. |
| “iops” | | | Operaciones de E/S por segundo. Se puede especificar para los volúmenes IO1, IO2 y GP3. |
| “rendimiento” | | 125 | El rendimiento se indica en MB/s. Solo es efectivo cuando se especifica el tipo de volumen gp3. |
| “cifrado” | true, false | false | Especifica si el volumen debe estar cifrado o no. Los valores válidos son “verdadero” o “falso”. |
| “blockExpress” | true, false | false | Habilita la creación de volúmenes io2 Block Express. |
| “kmsKeyId” | | | El ARN completo de la clave que se va a utilizar al cifrar el volumen. Si no se especifica, AWS utilizará la clave de KMS predeterminada para la región en la que se encuentra el volumen. Será una clave generada automáticamente y se llamará `/aws/ebs`, si no se modifica. |
| “blockSize” | | | El tamaño del bloque que se utilizará al formatear el sistema de archivos subyacente. Solo se admite en nodos de Linux y con fstype `ext2`, `ext3`, `ext4` o `xfs`. |
| “inodeSize” | | | El tamaño del nodo de índice que se utilizará al formatear el sistema de archivos subyacente. Solo se admite en nodos de Linux y con fstype `ext2`, `ext3`, `ext4` o `xfs`. |
| “bytesPerInode” | | | Los `bytes-per-inode` que se utilizarán al formatear el sistema de archivos subyacente. Solo se admite en nodos de Linux y con fstype `ext2`, `ext3` y `ext4`. |
| “numberOfInodes” | | | Los `number-of-inodes` que se utilizarán al formatear el sistema de archivos subyacente. Solo se admite en nodos de Linux y con fstype `ext2`, `ext3` y `ext4`. |
| “ext4BigAlloc” | true, false | false | Cambia el sistema de archivos `ext4` de modo que utilice la asignación de bloques en clústeres, para lo que habilita la opción de formateo `bigalloc`. Advertencia: es posible que `bigalloc` no sea completamente compatible con el núcleo de Linux del nodo. |
| “ext4ClusterSize” | | | El tamaño del clúster que se utilizará al formatear un sistema de archivos `ext4`cuando la característica `bigalloc` esté habilitada. Nota: El parámetro `ext4BigAlloc` debe estar establecido en “verdadero”. |
Para obtener más información, consulte [Controlador de CSI de AWS EBS](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/parameters.md) en GitHub.
## Consideraciones
**nota**
Solo puede implementar cargas de trabajo que dependan de las clases de almacenamiento del modo automático de EKS en los nodos del modo automático de EKS. Si tiene un clúster con varios tipos de nodos, debe configurar sus cargas de trabajo para que se ejecuten únicamente en los nodos del modo automático de EKS. Para obtener más información, consulte [Cómo controlar si una carga de trabajo se implementa en nodos del modo automático de EKS](associate-workload.md).
La capacidad de almacenamiento en bloques del modo automático de EKS es diferente a la del controlador de CSI de EBS.
+ Aprovisionamiento estático
+ Si desea utilizar volúmenes de EBS creados externamente con el modo automático de EKS, tendrá que agregar manualmente una etiqueta `eks:eks-cluster-name` con la clave AWS y el valor del nombre del clúster.
+ Taint de inicio de nodos
+ No puede usar la característica de taint de inicio de nodos para evitar la programación de pods antes de que la capacidad de almacenamiento esté lista.
+ Etiquetas personalizadas en volúmenes aprovisionados dinámicamente
+ No puede utilizar la marca de la CLI de etiquetas adicionales para configurar etiquetas personalizadas en volúmenes de EBS aprovisionados dinámicamente
+ Puede utilizar el etiquetado de `StorageClass` para agregar etiquetas personalizadas. El modo automático de EKS agregará etiquetas a los recursos de AWS asociados. Deberá actualizar el rol de IAM del clúster para las etiquetas personalizadas. Para obtener más información, consulte [Etiquetas personalizadas de AWS para los recursos del modo automático de EKS](auto-learn-iam.md#tag-prop).
+ Métricas de rendimiento detalladas de EBS
+ No puede acceder a las métricas de Prometheus para obtener el rendimiento detallado de EBS
## Instale el complemento de controlador de instantáneas de CSI
El modo automático de EKS es compatible con el complemento de Amazon EKS de controlador de instantáneas de CSI.
AWS sugiere configurar este complemento para que se ejecute en el grupo de nodos del `system` integrado.
Para obtener más información, consulte:
+ [Ejecución de complementos esenciales en instancias dedicadas](critical-workload.md)
+ [Cómo habilitar o desactivar los NodePools integrados](set-builtin-node-pools.md)
+ [Habilitación de la funcionalidad de instantáneas para volúmenes de CSI](csi-snapshot-controller.md)
### Para instalar el controlador de instantáneas en el grupo de nodos del sistema
1. Abra el clúster de EKS en la consola de AWS
1. En la pestaña **Complementos**, seleccione **Obtener más complementos**
1. Seleccione el **Controlador de instantáneas de CSI** y luego **Siguiente**
1. En la página **Configuración de los ajustes de los complementos seleccionados**, seleccione **Ajustes de configuración opcionales** para ver el **Esquema de configuración del complemento**
1. Inserte el siguiente yaml para asociar el controlador de instantáneas al grupo de nodos del `system`. El controlador de instantáneas incluye una tolerancia a la taint `CriticalAddonsOnly`.
```
{
"nodeSelector": {
"karpenter.sh/nodepool": "system"
}
}
```
1. Seleccione **Siguiente**.
1. Revise la configuración del complemento y, a continuación, seleccione **Crear**
# Cómo desactivar el modo automático de EKS
Puede desactivar el modo automático de EKS en un clúster de EKS existente. Se trata de una operación destructiva.
+ EKS terminará todas las instancias de EC2 operadas por el modo automático de EKS.
+ EKS eliminará todos los equilibradores de carga operados por el modo automático de EKS.
+ EKS **no** eliminará los volúmenes de EBS aprovisionados por el modo automático de EKS.
El modo automático de EKS está diseñado para administrar completamente los recursos que crea. Las intervenciones manuales podrían provocar que el modo automático de EKS no limpie completamente esos recursos cuando está desactivado. Por ejemplo, si ha hecho referencia a un grupo de seguridad administrado desde las reglas de un grupo de seguridad externo y se olvida de eliminar esa referencia antes de desactivar el modo automático de EKS para un clúster, el grupo de seguridad administrado no se eliminará y quedará residual. Los siguientes pasos describen cómo eliminar un grupo de seguridad residual en caso de que eso ocurra.
## Desactivación del modo automático de EKS (Consola de AWS)
1. Abra la página de información general del clúster en la Consola de administración de AWS.
1. En **Modo automático de EKS**, seleccione **Administrar**
1. Desactivar el **Modo automático de EKS** con la opción `off`.
Si un grupo de seguridad administrado no se elimina al final de este proceso, podrá eliminarlo manualmente con las descripciones de [Eliminar un grupo de seguridad](https://docs.aws.amazon.com/vpc/latest/userguide/deleting-security-groups.html).
## Desactivación del modo automático de EKS (AWS CLI)
Utilice el siguiente comando para desactivar el modo automático de EKS en un clúster existente.
Debe tener `aws` CLI instalada y haber iniciado sesión con los permisos suficientes para administrar los clústeres de EKS. Para obtener más información, consulte [Configuración para usar Amazon EKS](setting-up.md).
**nota**
Las capacidades de computación, almacenamiento en bloque y equilibrio de carga se deben habilitar o desactivar en la misma solicitud.
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=false \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": false}}' \
--storage-config '{"blockStorage":{"enabled": false}}'
```
Puede verificar si un grupo de seguridad del modo automático de EKS quedó residual y no se eliminó después de desactivar el modo automático de EKS de la siguiente manera:
```
aws ec2 describe-security-groups \
--filters Name=tag:eks:eks-cluster-name,Values= Name=tag-key,Values=ingress.eks.amazonaws.com/resource,service.eks.amazonaws.com/resource --query "SecurityGroups[*].[GroupName]"
```
Para después eliminar el grupo de seguridad:
```
aws ec2 delete-security-group --group-name=
```
# Actualización de la versión de Kubernetes de un clúster del modo automático de EKS
En este tema se explica cómo actualizar la versión de Kubernetes del clúster del modo automático. El modo automático simplifica el proceso de actualización de versiones al gestionar la coordinación de las actualizaciones del plano de control con las sustituciones de nodos, mientras mantiene la disponibilidad de la carga de trabajo gracias a los presupuestos de interrupción de pods.
Al actualizar un clúster del modo automático, muchos componentes que tradicionalmente requerían actualizaciones manuales ahora se administran como parte del servicio. Entender los aspectos automatizados del proceso de actualización y las responsabilidades asociadas contribuye a asegurar una transición de versión fluida para el clúster.
## Más información sobre las actualizaciones con el modo automático de EKS
Una vez iniciada la actualización del plano de control, el modo automático de EKS comenzará a actualizar los nodos del clúster. A medida que los nodos expiren, el modo automático de EKS los reemplazará con nodos nuevos. Los nuevos nodos cuentan con la nueva versión de Kubernetes correspondiente. El modo automático de EKS respeta los presupuestos de interrupción de pods al actualizar nodos.
Además, ya no tendrá que actualizar componentes como:
+ CNI de Amazon VPC
+ Controlador del equilibrador de carga de AWS
+ CoreDNS
+ `kube-proxy`
+ Karpenter
+ Controlador CSI de AWS EBS
El modo automático de EKS sustituye estos componentes por funciones de servicio.
Aún es responsable de la actualización de:
+ Aplicaciones y cargas de trabajo implementadas en el clúster
+ Complementos y controladores autoadministrados
+ Complementos de Amazon EKS
+ Información sobre cómo [Actualización de un complemento de Amazon EKS](updating-an-add-on.md)
Más información sobre las [prácticas recomendadas para la actualización de clústeres](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html)
## Cómo iniciar la actualización del clúster
Para iniciar una actualización del clúster, consulte [Actualización del clúster existente a la nueva versión de Kubernetes](update-cluster.md).
# Cómo habilitar o desactivar los NodePools integrados
El modo automático de EKS tiene dos NodePools integrados. Puede habilitar o desactivar estos NodePools mediante la consola de AWS, la CLI o la API.
## Referencia de NodePool integrado
+ `system`
+ Este NodePool tiene una taint `CriticalAddonsOnly`. Muchos complementos de EKS, como CoreDNS, toleran esta taint. Utilice este grupo de nodos del sistema para separar las aplicaciones críticas del clúster.
+ Admite tanto arquitecturas `amd64` como `arm64`.
+ `general-purpose`
+ Este NodePool admite el lanzamiento de nodos para cargas de trabajo de uso general en el clúster.
+ Utiliza solo la arquitectura `amd64`.
Ambos NodePools integrados:
+ Utilizan la NodeClass de EKS predeterminada
+ Utilizan únicamente la capacidad de EC2 bajo demanda
+ Utilizan las familias de instancias C, M y R de EC2
+ Exigen instancias de EC2 de generación 5 o posterior
**nota**
Es necesario habilitar al menos un NodePool integrado para que EKS aprovisione la NodeClass “predeterminada”. Si desactiva todos los NodePools integrados, tendrá que crear una NodeClass personalizada y configurar un NodePool para usarla. Para obtener más información acerca de NodeClasses, consulte [Cómo crear una clase de nodos para Amazon EKS](create-node-class.md).
## Procedimiento
### Requisitos previos
+ 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`. Para instalar la versión más reciente, consulte [Instalación](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) y [Configuración rápida con aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config) en la Guía del usuario de la interfaz de la línea de comandos de AWS.
+ Inicie sesión en la CLI con permisos de IAM suficientes para crear recursos de AWS, como políticas de IAM, roles de IAM y clústeres de EKS.
### Habilitar con la CLI de AWS
Utilice el siguiente comando para habilitar ambos NodePools integrados:
```
aws eks update-cluster-config \
--name \
--compute-config '{
"nodeRoleArn": "",
"nodePools": ["general-purpose", "system"],
"enabled": true
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}
}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
Puede modificar el comando para habilitar los NodePools de forma selectiva.
### Desactivar con la CLI de AWS
Utilice el siguiente comando para desactivar ambos NodePools integrados:
```
aws eks update-cluster-config \
--name \
--compute-config '{
"enabled": true,
"nodePools": []
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
# Cómo controlar si una carga de trabajo se implementa en nodos del modo automático de EKS
Al ejecutar cargas de trabajo en un clúster de EKS con el modo automático de EKS, es posible que deba controlar si determinadas cargas de trabajo se ejecutan en nodos del modo automático de EKS o en otros tipos de computación. En este tema se describe cómo usar los selectores de nodos y las reglas de afinidad para garantizar que las cargas de trabajo estén programadas en la infraestructura de computación prevista.
Los ejemplos de este tema muestran cómo utilizar la etiqueta `eks.amazonaws.com/compute-type` para exigir o impedir la implementación de la carga de trabajo en los nodos del modo automático de EKS. Esto resulta especialmente útil en clústeres de modo mixto en los que se ejecutan tanto el modo automático de EKS como otros tipos de computación, como los aprovisionadores Karpenter autoadministrados o los grupos de nodos administrados por EKS.
Los nodos del modo automático de EKS han establecido el valor de la etiqueta `eks.amazonaws.com/compute-type` en `auto`. Muestra cómo utilizar esta marca para controlar si una carga de trabajo se implementa en nodos administrados por el modo automático de EKS.
## Es necesario implementar una carga de trabajo en los nodos del modo automático de EKS
**nota**
Este valor de `nodeSelector` no es obligatorio para el modo automático de EKS. Este valor de `nodeSelector` es relevante únicamente si ejecuta un clúster en un modo mixto, con tipos de nodos no administrados por el modo automático de EKS. Por ejemplo, es posible que haya capacidad de computación estática implementada en el clúster con grupos de nodos administrados por EKS, así como una capacidad de computación dinámica administrada por el modo automático de EKS.
Puede agregar este `nodeSelector` a las implementaciones u otras cargas de trabajo para exigir a Kubernetes que las programe en los nodos del modo automático de EKS.
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
## Requiere que una carga de trabajo no se implemente en nodos del modo automático de EKS.
Puede agregar esta `nodeAffinity` a las implementaciones u otras cargas de trabajo para exigir a Kubernetes que **no** las programe en los nodos del modo automático de EKS.
```
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- auto
```
# Ejecución de complementos esenciales en instancias dedicadas
En este tema, aprenderá a implementar una carga de trabajo con una tolerancia `CriticalAddonsOnly` para que el modo automático de EKS la programe en el grupo de nodos de `system`.
El grupo de nodos del `system` integrado del modo automático de EKS está diseñado para ejecutar complementos esenciales en instancias dedicadas. Esta división asegura que los componentes esenciales dispongan de recursos dedicados y se mantengan aislados de las cargas de trabajo generales, mejorando así la estabilidad y el rendimiento global del clúster.
Esta guía muestra cómo implementar complementos en el grupo de nodos del `system` mediante la tolerancia `CriticalAddonsOnly` y los selectores de nodos adecuados. Si sigue estos pasos, podrá asegurarse de que las aplicaciones críticas se programen en los nodos dedicados del `system`, aprovechando las ventajas de aislamiento y asignación de recursos que ofrece la estructura especializada de grupos de nodos del modo automático de EKS.
El modo automático de EKS tiene dos grupos de nodos integrados: `general-purpose` y `system`. Para obtener más información, consulte [Cómo habilitar o desactivar los NodePools integrados](set-builtin-node-pools.md).
El propósito del grupo de nodos del `system` es segregar los complementos críticos en diferentes nodos. Los nodos aprovisionados por el grupo de nodos del `system` tienen una taint de Kubernetes `CriticalAddonsOnly`. Kubernetes solo programará los pods en estos nodos si tienen la tolerancia correspondiente. 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.
## Requisitos previos
+ Clúster de modo automático de EKS con el grupo de nodos de `system` integrado habilitado. Para obtener más información, consulte [Cómo habilitar o desactivar los NodePools integrados](set-builtin-node-pools.md)
+ `kubectl` instalado y configurado Para obtener más información, consulte [Configuración para usar Amazon EKS](setting-up.md).
## Procedimiento
Revise el ejemplo de yaml que aparece a continuación. Tenga en cuenta las siguientes condiciones:
+ `nodeSelector`: esto asocia la carga de trabajo con el grupo de nodos integrado del `system`. Este grupo de nodos debe estar habilitado con la API AWS. Para obtener más información, consulte [Cómo habilitar o desactivar los NodePools integrados](set-builtin-node-pools.md).
+ `tolerations`: esta tolerancia supera la taint de `CriticalAddonsOnly` en los nodos del grupo de nodos del `system`.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample-app
spec:
replicas: 3
selector:
matchLabels:
app: sample-app
template:
metadata:
labels:
app: sample-app
spec:
nodeSelector:
karpenter.sh/nodepool: system
tolerations:
- key: "CriticalAddonsOnly"
operator: "Exists"
containers:
- name: app
image: nginx:latest
resources:
requests:
cpu: "500m"
memory: "512Mi"
```
Para actualizar una carga de trabajo de modo que se ejecute en el grupo de nodos del `system`, deberá:
1. Actualizar la carga de trabajo existente para agregar las siguientes configuraciones descritas anteriormente:
+ `nodeSelector`
+ `tolerations`
1. Implementar la carga de trabajo actualizada en el clúster con `kubectl apply`
Tras actualizar la carga de trabajo, se ejecutará en nodos dedicados.
# Cómo utilizar las políticas de red con el modo automático de EKS
## Descripción general
A medida que los clientes escalan sus entornos de aplicaciones mediante EKS, el aislamiento del tráfico de la red se vuelve cada vez más fundamental para evitar el acceso no autorizado a los recursos tanto dentro como fuera del clúster. Esto es especialmente importante en un entorno de varios inquilinos con varias cargas de trabajo no relacionadas que se ejecutan en paralelo en el clúster. Las políticas de red de Kubernetes le permiten mejorar la posición de seguridad de la red para sus cargas de trabajo de Kubernetes y sus integraciones con los puntos de conexión externos al clúster. El modo automático de EKS admite distintos tipos de políticas de red.
### Aislamiento de las capas 3 y 4
Las políticas de red estándar de Kubernetes operan en las capas 3 y 4 del modelo de red OSI y le permiten controlar el flujo de tráfico en la dirección IP o el puerto dentro del clúster de Amazon EKS.
#### Casos de uso
+ Segmente el tráfico de red entre las cargas de trabajo para garantizar que solo las aplicaciones relacionadas puedan comunicarse entre sí.
+ Aísle los inquilinos del espacio de nombres mediante políticas que impongan la separación de la red.
### Aplicación basada en DNS
Los clientes suelen implementar cargas de trabajo en EKS que forman parte de un entorno distribuido más amplio, algunas de las cuales tienen que comunicarse con sistemas y servicios externos al clúster (tráfico en dirección norte). Estos sistemas y servicios pueden estar en la nube de AWS o completamente fuera de AWS. Las políticas basadas en el sistema de nombres de dominio (DNS) le permiten reforzar su posición de seguridad mediante la adopción de un enfoque más estable y predecible para evitar el acceso no autorizado desde los pods a los recursos o puntos de conexión externos al clúster. Este mecanismo elimina la necesidad de hacer un seguimiento manual de direcciones IP específicas y permitir incluirlas en una lista. Al proteger los recursos con un enfoque basado en DNS, también tiene más flexibilidad para actualizar la infraestructura externa sin tener que flexibilizar la posición de seguridad ni modificar las políticas de red en caso de cambios en los servidores y hosts ascendentes. Puede filtrar el tráfico de salida hacia puntos de conexión externos mediante un nombre de dominio completo (FQDN) o un patrón coincidente para un nombre de dominio de DNS. Esto le ofrece la flexibilidad adicional de ampliar el acceso a varios subdominios asociados a un punto de conexión externo al clúster en particular.
#### Casos de uso
+ Estandarice según un enfoque basado en DNS para filtrar el acceso desde un entorno de Kubernetes a los puntos de conexión externos al clúster.
+ Proteja el acceso a los servicios de AWS en un entorno de varios inquilinos.
+ Administre el acceso a la red desde los pods hasta las cargas de trabajo en las instalaciones en sus entornos de nube híbrida.
### Reglas de administración (o según el ámbito del clúster)
En algunos casos, como en los escenarios de varios inquilinos, es posible que los clientes tengan que aplicar un estándar de seguridad de red a todo el clúster. En lugar de definir y mantener de forma repetitiva una política distinta para cada espacio de nombres, puede usar una política única para administrar de forma centralizada los controles de acceso a la red para las diferentes cargas de trabajo del clúster, independientemente de su espacio de nombres. Estos tipos de políticas le permiten ampliar el ámbito de aplicación de las reglas de filtrado de red que se aplican en las capas 3 y 4 y cuando se utilizan las reglas de DNS.
#### Casos de uso
+ Administre de forma centralizada los controles de acceso a la red para todas las cargas de trabajo (o un subconjunto de ellas) del clúster de EKS.
+ Defina una posición de seguridad de red predeterminada en todo el clúster.
+ Amplíe los estándares de seguridad de la organización al ámbito del clúster de una manera más eficiente desde el punto de vista operativo.
## Introducción
### Requisitos previos
+ Un clúster de Amazon EKS con el modo automático de EKS habilitado
+ kubectl configurado para conectarse al clúster
### Paso 1: Habilitación del controlador de políticas de red
Para utilizar las políticas de red con el modo automático de EKS, primero debe habilitar el controlador de políticas de red, para lo cual se aplica un ConfigMap al clúster.
1. Cree un archivo denominado `enable-network-policy.yaml` con el siguiente contenido:
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-network-policy-controller: "true"
```
1. Aplique el ConfigMap al clúster
```
kubectl apply -f enable-network-policy.yaml
```
### Paso 2: Cómo crear y probar políticas de red
El clúster del modo automático de EKS ya está configurado para admitir las políticas de red de Kubernetes. Puede probar esto con la [Demostración de Stars de política de red para Amazon EKS](network-policy-stars-demo.md).
### Paso 3: Ajustar la configuración del agente de políticas de red en la clase de nodo (opcional)
Opcionalmente, puede crear una nueva clase de nodo para cambiar el comportamiento predeterminado del agente de políticas de red en los nodos o habilitar el registro de eventos de políticas de red. Para ello, sigue estos pasos:
1. Cree o edite un archivo YAML de Clase de nodo (por ejemplo, `nodeclass-network-policy.yaml`) con el siguiente contenido:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: network-policy-config
spec:
# Optional: Changes default network policy behavior
networkPolicy: DefaultAllow
# Optional: Enables logging for network policy events
networkPolicyEventLogs: Enabled
# Include other Node Class configurations as needed
```
1. Aplique la configuración de Clase de nodo al clúster:
```
kubectl apply -f nodeclass-network-policy.yaml
```
1. Verifique que se haya creado la Clase de nodo:
```
kubectl get nodeclass network-policy-config
```
1. Actualice el Grupo de nodos para utilizar esta Clase de nodo. Para obtener más información, consulte [Creación de un grupo de nodos para el modo automático de EKS](create-node-pool.md).
## ¿Cómo funciona?
### Política de red basada en DNS
![\[Ilustración del flujo de trabajo cuando se aplica una política basada en DNS al modo automático de EKS\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/apply-dns-policy-1.png)
![\[Ilustración del flujo de trabajo cuando se aplica una política basada en DNS al modo automático de EKS\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/apply-dns-policy-2.png)
1. El equipo de la plataforma aplica una política basada en DNS al clúster de EKS.
1. El controlador de políticas de red es responsable de supervisar la creación de políticas dentro del clúster y, a continuación, conciliar los puntos de conexión de las políticas. En este caso de uso, el controlador de políticas de red indica al agente de nodos que filtre las solicitudes de DNS en función de los dominios permitidos en la política creada. Los nombres de dominio se enumeran en la lista de dominios permitidos mediante el FQDN o un nombre de dominio que coincida con un patrón definido en la configuración de recursos de Kubernetes.
1. La carga de trabajo A intenta resolver la IP de un punto de conexión externo al clúster. La solicitud de DNS pasa primero por un proxy que filtra dichas solicitudes en función de la lista de solicitudes permitidas aplicada a través de la política de red.
1. Una vez que la solicitud de DNS pasa por la lista de filtros de DNS permitidos, se envía por proxy a CoreDNS.
1. A su vez, CoreDNS envía la solicitud al Solucionador de DNS externo (Amazon Route 53 Resolver) para obtener la lista de direcciones IP detrás del nombre de dominio.
1. Las IP resueltas con TTL se devuelven en respuesta a la solicitud de DNS. A continuación, estas direcciones IP se escriben en un mapa de eBPF que se utiliza en el siguiente paso para la aplicación de la capa de IP.
1. A continuación, las sondas de eBPF conectadas a la interfaz veth del pod filtrarán el tráfico de salida de la carga de trabajo A al punto de conexión externo del clúster en función de las reglas vigentes. Esto garantiza que los pods solo puedan enviar tráfico externo al clúster a las IP de los dominios de la lista de dominios permitidos. La validez de estas IP se basa en el TTL obtenido del Solucionador de DNS externo (Amazon Route 53 Resolver).
#### Uso de la política de red de la aplicación
La `ApplicationNetworkPolicy` combina las capacidades de las políticas de red estándar de Kubernetes con el filtrado basado en DNS del espacio de nombres mediante una única definición de recursos personalizados (CRD). Por lo tanto, `ApplicationNetworkPolicy` se puede utilizar para:
1. Definir las restricciones en las capas 3 y 4 de la pila de red mediante bloques de IP y números de puerto.
1. Definir reglas que operen en la capa 7 de la pila de red y permitir filtrar el tráfico en función de los FQDN.
**importante**
Las reglas basadas en DNS definidas mediante `ApplicationNetworkPolicy` solo se aplican a las cargas de trabajo que se ejecutan en instancias de EC2 lanzadas por el modo automático de EKS. `ApplicationNetworkPolicy` admite todos los campos de la `NetworkPolicy` de Kubernetes estándar, con un filtro de FQDN adicional para las reglas de salida.
**aviso**
No utilice el mismo nombre para una `ApplicationNetworkPolicy` y una `NetworkPolicy` dentro del mismo espacio de nombres. Si los nombres colisionan, es posible que los objetos `PolicyEndpoints` resultantes no reflejen ninguna de las políticas correctamente. Ambos recursos se aceptan sin errores, lo que dificulta el diagnóstico de este problema.
Para resolver un conflicto de nomenclatura, cambie el nombre de `ApplicationNetworkPolicy` o de `NetworkPolicy` para que sean únicos dentro del espacio de nombres y, a continuación, compruebe que los objetos `PolicyEndpoints` correspondientes se hayan actualizado correctamente.
#### Ejemplo
Tiene una carga de trabajo en el clúster del modo automático de EKS que necesita comunicarse con una aplicación en las instalaciones que se encuentra detrás de un equilibrador de carga con un nombre de DNS. Para ello, puede utilizar la siguiente política de red:
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
name: my-onprem-app-egress
namespace: galaxy
spec:
podSelector:
matchLabels:
role: backend
policyTypes:
- Egress
egress:
- to:
- domainNames:
- "myapp.mydomain.com"
ports:
- protocol: TCP
port: 8080
```
En la red de Kubernetes, esto permitiría salir de cualquier pod del espacio de nombres “galaxy” etiquetado con `role: backend` para conectarse al nombre de dominio **myapp.mydomain.com** en el puerto TCP 8080. Además, tendría que configurar la conectividad de red para el tráfico de salida de la VPC al centro de datos corporativo.
![\[Ilustración de la carga de trabajo en el modo automático de EKS que se comunica con las aplicaciones en las instalaciones\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/eks-auto-to-on-prem.png)
### Política de red de administración (o del clúster)
![\[Ilustración del orden de evaluación de las políticas de red en EKS\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/evaluation-order.png)
#### Uso de la política de red del clúster
Cuando se usa una `ClusterNetworkPolicy`, las políticas del nivel de administración se evalúan primero y no se pueden anular. Una vez evaluadas las políticas del nivel de administración, se utilizan las políticas estándar del ámbito del espacio de nombres para ejecutar las reglas de segmentación de red aplicadas. Esto se puede lograr mediante el uso de `ApplicationNetworkPolicy` o `NetworkPolicy`. Por último, se aplicarán las reglas del nivel de línea de base que definen las restricciones de red predeterminadas para las cargas de trabajo de los clústeres. Si es necesario, las políticas del ámbito del espacio de nombres **pueden** anular estas reglas del nivel de línea de base.
#### Ejemplo
Tiene una aplicación en el clúster que desea aislar de las cargas de trabajo de otros inquilinos. Puede bloquear de forma explícita el tráfico del clúster desde otros espacios de nombres para impedir el acceso de la red al espacio de nombres confidencial de la carga de trabajo.
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: protect-sensitive-workload
spec:
tier: Admin
priority: 10
subject:
namespaces:
matchLabels:
kubernetes.io/metadata.name: earth
ingress:
- action: Deny
from:
- namespaces:
matchLabels: {} # Match all namespaces.
name: select-all-deny-all
```
## Consideraciones
### Descripción del orden de evaluación de políticas
Las capacidades de políticas de red compatibles con EKS se evalúan en un orden específico para garantizar una administración del tráfico predecible y segura. Por lo tanto, es importante comprender el flujo de evaluación para diseñar una posición de seguridad de red efectiva para el entorno.
1. **Políticas del nivel de administración (se evalúan primero)**: todas las ClusterNetworkPolicies del nivel de administración se evalúan antes que cualquier otra política. En el nivel de administración, las políticas se procesan por orden de prioridad (se comienza por el número de prioridad más baja). El tipo de acción determina lo que sucede a continuación.
+ **Acción de denegación (máxima prioridad)**: cuando una política de administración con una acción de denegación coincide con el tráfico, ese tráfico se bloquea inmediatamente, independientemente de cualquier otra política. No se procesan más reglas de ClusterNetworkPolicy ni NetworkPolicy. Esto garantiza que las políticas del espacio de nombres no puedan anular los controles de seguridad de toda la organización.
+ **Acción de permiso**: una vez evaluadas las reglas de denegación, las políticas de administración que incluyen acciones de permiso se procesan por orden de prioridad (se comienza por el número de prioridad más baja). Cuando una acción de permiso coincide, se acepta el tráfico y no se lleva a cabo ninguna otra evaluación de la política. Estas políticas pueden conceder el acceso a varios espacios de nombres en función de los selectores de etiquetas, lo que proporciona un control centralizado sobre qué cargas de trabajo pueden acceder a recursos específicos.
+ **Acción de transferencia**: las acciones de transferencia en las políticas del nivel de administración delegan la toma de decisiones a los niveles inferiores. Cuando el tráfico coincide con una regla de transferencia, la evaluación omite todas las reglas del nivel de administración restantes para ese tráfico y continúa directamente con el nivel de la NetworkPolicy. Esto permite a los administradores delegar explícitamente el control de determinados patrones de tráfico a los equipos de aplicaciones. Por ejemplo, puede usar reglas de transferencia para delegar la administración del tráfico dentro del espacio de nombres a los administradores del espacio de nombres y, al mismo tiempo, mantener controles estrictos sobre el acceso externo.
1. **Nivel de política de red**: si ninguna política del nivel de administración coincide con ninguna acción de denegación o permiso, o si coincide con una acción de transferencia, se evalúan los recursos de la ApplicationNetworkPolicy y de la NetworkPolicy tradicional del ámbito del espacio de nombres. Estas políticas proporcionan un control detallado dentro de los espacios de nombres individuales y las administran los equipos de aplicaciones. Las políticas relacionadas con el espacio de nombres solo pueden ser más restrictivas que las políticas de administración. No pueden anular ninguna decisión de denegación de una política de administración, pero pueden restringir aún más el tráfico permitido o transferido por las políticas de administración.
1. **Políticas de administración del nivel de línea de base**: si ninguna política de administración o del ámbito del espacio de nombres coincide con el tráfico, se evalúan las ClusterNetworkPolicies del nivel de línea de base. Proporcionan posiciones de seguridad predeterminadas que pueden ser anuladas por políticas del ámbito del espacio de nombres, lo que permite a los administradores establecer valores predeterminados para toda la organización y, al mismo tiempo, ofrecer a los equipos la flexibilidad necesaria para personalizarlas según sea necesario. Las políticas de referencia se evalúan por orden de prioridad (se comienza por el número de prioridad más baja).
1. **Denegación de forma predeterminada (si ninguna política coincide)**: este comportamiento de denegación de forma predeterminada garantiza que solo se permitan las conexiones explícitamente permitidas, lo que mantiene una posición de seguridad sólida.
### Aplicación del principio de privilegio mínimo
+ **Inicio con políticas restrictivas y adición de permisos gradualmente según sea necesario**: comience por implementar políticas de denegación de forma predeterminada en el clúster y, a continuación, agregue reglas de autorización de forma gradual según valide los requisitos de conectividad legítimos. Este enfoque obliga a los equipos a justificar de forma explícita cada conexión externa, lo que crea un entorno más seguro y auditable.
+ **Auditoría y eliminación periódicas de las reglas de políticas no utilizadas**: las políticas de red pueden acumularse con el tiempo a medida que las aplicaciones evolucionan y dejar atrás reglas obsoletas que amplían innecesariamente la superficie expuesta a ataques. Implemente un proceso de revisión periódico para identificar y eliminar las reglas de políticas que ya no sean necesarias, lo que garantiza que su posición de seguridad siga siendo estricta y fácil de mantener.
+ **Uso de nombres de dominio específico en lugar de patrones amplios cuando sea posible**: si bien los patrones de comodines como `*.amazonaws.com` proporcionan conveniencia, también otorgan acceso a una amplia gama de servicios. Siempre que sea posible, especifique nombres de dominio exactos como `s3.us-west-2.amazonaws.com` para limitar el acceso solo a los servicios específicos que requieren las aplicaciones, lo que reduce el riesgo de movimientos laterales si la carga de trabajo se ve comprometida.
### Uso de políticas basadas en DNS en EKS
+ Las reglas basadas en DNS definidas mediante la `ApplicationNetworkPolicy` solo se aplican a las cargas de trabajo que se ejecutan en instancias de EC2 lanzadas por el modo automático de EKS. Si ejecuta un clúster de modo mixto (compuesto por nodos de trabajo del modo automático de EKS y nodos que no son del modo automático de EKS), las reglas basadas en DNS solo son efectivas en los nodos de trabajo del modo automático de EKS (instancias administradas de EC2).
### Validación de las políticas de DNS
+ **Uso de clústeres de almacenamiento provisional que reflejen la topología de la red de producción para llevar a cabo pruebas**: el entorno de pruebas debe replicar la arquitectura de la red, las dependencias externas y los patrones de conectividad de la producción para garantizar la precisión de las pruebas de políticas. Esto incluye configuraciones de VPC coincidentes, comportamiento de resolución de DNS y acceso a los mismos servicios externos que requieren las cargas de trabajo de producción.
+ **Implementación de pruebas automatizadas para rutas de red críticas**: cree pruebas automatizadas que validen la conectividad con los servicios externos esenciales como parte del proceso de CI/CD. Estas pruebas deben verificar que se permiten los flujos de tráfico legítimos mientras se bloquean las conexiones no autorizadas, lo que permite validar continuamente que las políticas de red mantengan la posición de seguridad correcta a medida que la infraestructura evoluciona.
+ **Supervisión del comportamiento de las aplicaciones tras los cambios en las políticas**: tras implementar políticas de red nuevas o modificadas en el entorno de producción, supervise de cerca los registros de las aplicaciones, las tasas de errores y las métricas de rendimiento para identificar rápidamente cualquier problema de conectividad. Establezca procedimientos de reversión claros para poder revertir rápidamente los cambios en las políticas si provocan un comportamiento inesperado de las aplicaciones o interrupciones en el servicio.
### Interacción con el firewall de DNS de Amazon Route 53
Las políticas de administración y de red de EKS se evalúan primero en el pod cuando se inicia el tráfico. Si una política de red de EKS permite la salida a un dominio específico, el pod lleva a cabo una consulta de DNS que llega a Route 53 Resolver. En este punto, se evalúan las reglas de firewall de DNS de Route 53. Si el firewall de DNS bloquea la consulta del dominio, se produce un error en la resolución de DNS y no se puede establecer la conexión, aunque la política de red de EKS lo permita. Esto crea capas de seguridad complementarias: las políticas de red basadas en DNS de EKS proporcionan un control de salida de pods para los requisitos de acceso específicos de la aplicación y los límites de seguridad de varios inquilinos, mientras que el firewall de DNS proporciona protección en toda la VPC contra los dominios maliciosos conocidos y aplica las listas de bloqueo en toda la organización.
# Etiquetado de subredes para el modo automático de EKS
Si utiliza la capacidad de equilibrio de carga del modo automático de EKS, debe agregar etiquetas de AWS a las subredes de la VPC.
## Introducción
Estas etiquetas identifican las subredes como asociadas al clúster y, lo que es más importante, si la subred es pública o privada.
Las subredes públicas tienen acceso directo a Internet a través de una puerta de enlace de Internet. Se utilizan para recursos que deben ser de acceso público, como los equilibradores de carga.
Las subredes privadas no tienen acceso directo a Internet y utilizan puertas de enlace de NAT para el tráfico saliente. Se utilizan para recursos internos, como los nodos de EKS, que no necesitan direcciones IP públicas.
Para obtener más información sobre las puertas de enlace de NAT y las puertas de enlace de Internet, consulte [Conectar la VPC a otras redes](https://docs.aws.amazon.com/vpc/latest/userguide/extend-intro.html) en la Guía del usuario de Amazon Virtual Private Cloud (VPC).
## Requisito
En este momento, las subredes que utiliza el modo automático de EKS para equilibrar la carga deben tener una de las siguientes etiquetas.
### Subredes públicas
Las subredes públicas se utilizan para los equilibradores de carga expuestos a Internet. Estas subredes deben tener las siguientes etiquetas:
| Clave | Valor |
| --- | --- |
| `kubernetes.io/role/elb` | `1` o `` |
### Subredes privadas
Las subredes privadas se utilizan para los equilibradores de carga internos. Estas subredes deben tener las siguientes etiquetas:
| Clave | Valor |
| --- | --- |
| `kubernetes.io/role/internal-elb` | `1` o `` |
## Procedimiento
Antes de empezar, identifique qué subredes son públicas (con acceso a través de puertas de enlace de Internet) y cuáles son privadas (a través de puertas de enlace de NAT). Necesitará permisos para modificar los recursos de la VPC.
### Consola de administración de AWS
1. Abra la consola de Amazon VPC y vaya a **Subredes**.
1. Seleccione la subred que desea etiquetar.
1. Elija la pestaña **Etiquetas** y seleccione **Agregar etiqueta**.
1. Agregue la etiqueta adecuada:
+ Para subredes públicas: Clave=`kubernetes.io/role/elb`
+ Para subredes privadas: Clave=`kubernetes.io/role/internal-elb`
1. Defina el **Valor** en `1` o déjelo en blanco.
1. Guarde y repita el proceso para las subredes restantes.
### AWS CLI
Para subredes públicas:
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/elb,Value=1
```
Para subredes privadas:
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/internal-elb,Value=1
```
Sustituya `subnet-ID` por su ID de subred real.
# Generación de informes de cumplimiento con el CIS desde los nodos de Kubernetes mediante la depuración de kubectl
En esta sección, se describe cómo generar informes de cumplimientos con el CIS (Center for Internet Security) para los nodos de Amazon EKS mediante el comando `kubectl debug`. El comando le permite crear temporalmente un contenedor de depuración en un nodo de Kubernetes y ejecutar comprobaciones de cumplimiento con el CIS mediante la herramienta `apiclient`. La herramienta `apiclient` forma parte del sistema operativo Bottlerocket, utilizado por los nodos del modo automático de EKS.
## Requisitos previos
Antes de comenzar, asegúrese de que dispone de lo siguiente:
+ Acceso a un clúster de Amazon EKS con `kubectl` configurado (la versión debe ser al menos la v1.32.0; escriba `kubectl version` para comprobarlo).
+ Los permisos de IAM adecuados para depurar los nodos.
+ Un perfil válido que permita realizar operaciones de depuración (por ejemplo, `sysadmin`).
Para obtener más información sobre el uso de perfiles de depuración con `kubectl`, consulte [Depuración de un pod o nodo durante la aplicación de un perfil](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#debugging-profiles) en la documentación de Kubernetes.
## Procedimiento
1. Determine el ID de instancia de AWS del nodo en el que quiere ejecutar el informe. Use el siguiente comando para enumerar todos los nodos en el clúster. El ID de instancia se encuentra en la columna de nombre y comienza por `i-`:
```
kubectl get nodes
```
```
NAME STATUS ROLES AGE VERSION
i-0ea0ba0f8ef9ad609 Ready 62s v1.30.10-eks-1a9dacd
```
1. Ejecute el siguiente comando y reemplace `` con el ID de instancia del nodo que desea consultar:
```
kubectl debug node/ -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023 -- bash -c "yum install -q -y util-linux-core; nsenter -t 1 -m apiclient report cis --level 1 --format text"
```
Los componentes de este comando incluyen los siguientes:
+ `kubectl debug node/`: crea una sesión de depuración en el ID de instancia EC2 especificado.
+ `-it`: asigna un TTY (intérprete de línea de comandos) y mantiene stdin abierto para su uso interactivo.
+ `--profile=sysadmin`: utiliza el perfil `kubectl` especificado con los permisos adecuados.
+ `--image=public.ecr.aws/amazonlinux/amazonlinux:2023`: utiliza `amazonlinux:2023` como imagen contenedora para la depuración.
+ `bash -c "…"`: ejecuta los siguientes comandos en un intérprete de comandos bash:
+ `yum install -q -y util-linux-core`: instala silenciosamente el paquete de utilidades necesario.
+ `nsenter -t 1 -m`: ejecuta `nsenter` para introducir el espacio de nombres del proceso del host (PID 1).
+ `apiclient report cis --level 1 --format text`: ejecuta el informe de conformidad con el CIS en el nivel 1 con salida de texto.
1. Revise el resultado de texto del informe.
## Interpretación del resultado
El comando genera un informe basado en texto que muestra el estado de cumplimiento de varios controles del CIS. El resultado incluye lo siguiente:
+ ID de control del CIS individual
+ Descripción de cada control
+ Estado de aprobación, rechazo u omisión de cada comprobación
+ Detalles que explican cualquier problema de cumplimiento
Este es un ejemplo del resultado del informe ejecutado en una instancia de Bottlerocket:
```
Benchmark name: CIS Bottlerocket Benchmark
Version: v1.0.0
Reference: https://www.cisecurity.org/benchmark/bottlerocket
Benchmark level: 1
Start time: 2025-04-11T01:40:39.055623436Z
[SKIP] 1.2.1 Ensure software update repositories are configured (Manual)
[PASS] 1.3.1 Ensure dm-verity is configured (Automatic)[PASS] 1.4.1 Ensure setuid programs do not create core dumps (Automatic)
[PASS] 1.4.2 Ensure address space layout randomization (ASLR) is enabled (Automatic)
[PASS] 1.4.3 Ensure unprivileged eBPF is disabled (Automatic)
[PASS] 1.5.1 Ensure SELinux is configured (Automatic)
[SKIP] 1.6 Ensure updates, patches, and additional security software are installed (Manual)
[PASS] 2.1.1.1 Ensure chrony is configured (Automatic)
[PASS] 3.2.5 Ensure broadcast ICMP requests are ignored (Automatic)
[PASS] 3.2.6 Ensure bogus ICMP responses are ignored (Automatic)
[PASS] 3.2.7 Ensure TCP SYN Cookies is enabled (Automatic)
[SKIP] 3.4.1.3 Ensure IPv4 outbound and established connections are configured (Manual)
[SKIP] 3.4.2.3 Ensure IPv6 outbound and established connections are configured (Manual)
[PASS] 4.1.1.1 Ensure journald is configured to write logs to persistent disk (Automatic)
[PASS] 4.1.2 Ensure permissions on journal files are configured (Automatic)
Passed: 11
Failed: 0
Skipped: 4
Total checks: 15
```
Para obtener más información sobre los valores de referencia, consulte [Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) del Center for Internet Security (CIS).
## Recursos relacionados
+ [Bottlerocket CIS Benchmark](https://bottlerocket.dev/en/os/1.34.x/api/reporting/cis/) en la documentación del sistema operativo Bottlerocket.
+ [Depurar pods en ejecución](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/) en la documentación de Kubernetes.
+ [Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) del Center for Internet Security (CIS)
# Habilitación del cifrado de volúmenes de EBS con claves de KMS administradas por el cliente para el modo automático de EKS
Puede cifrar el volumen raíz efímero de las instancias en el modo automático de EKS con una clave de KMS administrada por el cliente.
El modo automático de Amazon EKS utiliza roles vinculados a servicios para delegar permisos a otros servicios de AWS al administrar volúmenes de EBS cifrados para los clústeres de Kubernetes. Este tema describe cómo configurar la política de claves que necesita al especificar una clave administrada por el cliente para el cifrado de Amazon EBS con el modo automático de EKS.
Consideraciones:
+ El modo automático de EKS no necesita autorización adicional para usar la clave administrada por AWS predeterminada para proteger los volúmenes cifrados en la cuenta.
+ Este tema aborda el cifrado de volúmenes efímeros, es decir, los volúmenes raíz de las instancias de EC2. Para obtener más información sobre el cifrado de volúmenes de datos utilizados para cargas de trabajo, consulte [Creación de una clase de almacenamiento](create-storage-class.md).
## Descripción general
Las siguientes claves de AWS KMS se pueden utilizar para el cifrado del volumen raíz de Amazon EBS cuando el modo automático de EKS lanza instancias:
+ **Clave administrada por AWS**: una clave de cifrado en la cuenta que Amazon EBS crea, posee y administra. Esta es la clave de cifrado predeterminada en las cuentas nuevas.
+ **Clave administrada por el cliente**: una clave de cifrado personalizada que usted crea, posee y administra.
**nota**
La clave debe ser simétrica. Amazon EBS no es compatible con claves asimétricas administradas por el cliente.
## Paso 1: configuración de la política de claves
Las claves de KMS deben tener una política de claves que permita al modo automático de EKS lanzar instancias con volúmenes de Amazon EBS cifrados mediante una clave administrada por el cliente.
Configure la política de claves con la siguiente estructura:
**nota**
Esta política solo incluye permisos para el modo automático de EKS. Es posible que la política de claves necesite permisos adicionales si otras identidades deben usar la clave o administrar concesiones.
```
{
"Version":"2012-10-17",
"Id": "MyKeyPolicy",
"Statement": [
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
]
}
```
Asegúrese de reemplazar `` con el ID real de cuenta de AWS.
Al configurar la política de claves:
+ El `ClusterServiceRole` debe tener los permisos necesarios de IAM para usar la clave de KMS en operaciones de cifrado.
+ La condición `kms:GrantIsForAWSResource` garantiza que las concesiones solo se puedan crear para servicios de AWS.
## Paso 2: configuración de NodeClass con la clave administrada por el cliente
Después de configurar la política de claves, haga referencia a la clave de KMS en la configuración de NodeClass del modo automático de EKS:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Insert existing configuration
ephemeralStorage:
size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
iops: 3000 # Range: 3000-16000
throughput: 125 # Range: 125-1000
# KMS key for encryption
kmsKeyID: "arn:aws:kms:::key/"
```
Sustituya los valores de marcador de posición por los valores reales.
+ `` por la región de AWS
+ `` por el ID de cuenta de AWS
+ `` por el ID de la clave de KMS
Puede especificar la clave de KMS con cualquiera de los siguientes formatos:
+ ID de clave de KMS: `1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ ARN de clave de KMS: ` arn:aws:kms:us-west-2:111122223333:key/1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ Nombre del alias de la clave: `alias/eks-auto-mode-key`
+ ARN del alias de la clave: ` arn:aws:kms:us-west-2:111122223333:alias/eks-auto-mode-key`
Use kubectl para aplicar la configuración de NodeClass:
```
kubectl apply -f nodeclass.yaml
```
## Activos relacionados
+ [Creación de una clase de nodo para Amazon EKS](create-node-class.md)
+ Consulte más información en la Guía para desarrolladores de AWS Key Management Service
+ [Permisos para servicios de AWS en políticas de claves](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-services.html)
+ [Cómo cambiar una política de claves](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html)
+ [Concesiones en AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)
# Actualización de los controles de organización para el modo automático de EKS
Algunos controles de organización pueden impedir que el modo automático de EKS funcione correctamente. Si es así, debe actualizar estos controles para permitir que el modo automático de EKS disponga de los permisos necesarios para administarr las instancias de EC2 en su nombre.
El modo automático de EKS utiliza un rol de servicio para ejecutar las instancias de EC2 que respaldan los nodos del modo automático de EKS. Un rol de servicio es un [rol de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que se crea en su cuenta y que un servicio asume para realizar acciones en su nombre. [Las políticas de control de servicio](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCP) siempre se aplican a las acciones realizadas con los roles de servicio. Esto permite que una SCP inhiba las operaciones del modo automático. Lo más común es cuando se utiliza una SCP para restringir las imágenes de máquina de Amazon (AMI) que se pueden ejecutar. Para permitir el funcionamiento del modo automático de EKS, modifique la SCP para permitir la ejecución de las AMI desde las cuentas del modo automático de EKS.
También puede utilizar la característica de [AMI permitidas por EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-allowed-amis.html) para limitar la visibilidad de las AMI en otras cuentas. Si utiliza esta característica, debe ampliar los criterios de imagen para incluir también las cuentas de AMI del modo automático de EKS en las regiones de interés.
## Ejemplo de SCP para bloquear todas las AMI excepto las AMI del modo automático de EKS
La siguiente SCP impide realizar llamadas a `ec2:RunInstances` a menos que la AMI pertenezca a la cuenta de AMI del modo automático de EKS para us-west-2 o us-east-1.
**nota**
Es importante **no** utilizar la clave de contexto `ec2:Owner`. Amazon es propietario de las cuentas AMI del modo automático de EKS y el valor de esta clave siempre será `amazon`. Crear una SCP que permita ejecutar AMI si `ec2:Owner` es `amazon` permitirá ejecutar cualquier AMI propiedad de Amazon, no solo las del modo automático de EKS.\$1
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAMI",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:*:ec2:*::image/ami-*",
"Condition": {
"StringNotEquals": {
"aws:ResourceAccount": [
"767397842682",
"992382739861"
]
}
}
}
]
}
```
## Cuentas de AMI de modo automático de EKS
Cuentas de AWS que varían según la región alojan las AMI públicas del modo automático de EKS.
| | |
| --- |--- |
| Región de AWS | Cuenta |
| af-south-1 | 471112993317 |
| ap-east-1 | 590183728416 |
| ap-east-2 | 381492200852 |
| ap-northeast-1 | 851725346105 |
| ap-northeast-2 | 992382805010 |
| ap-northeast-3 | 891377407544 |
| ap-south-1 | 975049899075 |
| ap-south-2 | 590183737426 |
| ap-southeast-1 | 339712723301 |
| ap-southeast-2 | 058264376476 |
| ap-southeast-3 | 471112941769 |
| ap-southeast-4 | 590183863144 |
| ap-southeast-5 | 654654202513 |
| ap-southeast-6 | 905418310314 |
| ap-southeast-7 | 533267217478 |
| ca-central-1 | 992382439851 |
| ca-west-1 | 767397959864 |
| eu-central-1 | 891376953411 |
| eu-central-2 | 381492036002 |
| eu-north-1 | 339712696471 |
| eu-south-1 | 975049955519 |
| eu-south-2 | 471112620929 |
| eu-west-1 | 381492008532 |
| eu-west-2 | 590184142468 |
| eu-west-3 | 891376969258 |
| il-central-1 | 590183797093 |
| me-central-1 | 637423494195 |
| me-south-1 | 905418070398 |
| mx-central-1 | 211125506622 |
| sa-east-1 | 339712709251 |
| us-east-1 | 992382739861 |
| us-east-2 | 975050179949 |
| us-west-1 | 975050035094 |
| us-west-2 | 767397842682 |
| us-gov-east-1 | 446077414359 |
| us-gov-west-1 | 446098668741 |
## Asociación de direcciones IP públicas
Cuando se llama a `ec2:RunInstances`, el campo `AssociatePublicIpAddress` para el lanzamiento de una instancia se determina automáticamente en función del tipo de subred en la que se lanza la instancia. Se puede usar una SCP para exigir que este valor se establezca explícitamente en falso, independientemente del tipo de subred en la que se lance. En este caso, el campo `spec.advancedNetworking.associatePublicIPAddress` de NodeClass también se puede establecer en falso para cumplir con los requisitos de la SCP.
```
{
"Sid": "DenyPublicEC2IPAddesses",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:network-interface/*",
"Condition": {
"BoolIfExists": {
"ec2:AssociatePublicIpAddress": "true"
}
}
}
```
# Control de la implementación de las cargas de trabajo en las reservas de capacidad con el modo automático de EKS
Puede controlar la implementación de las cargas de trabajo en las [reservas de capacidad](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html). El modo automático de EKS admite reservas de capacidad bajo demanda (ODCR) de EC2 y bloques de capacidad de EC2 para ML.
**sugerencia**
De forma predeterminada, el modo automático de EKS se puede iniciar en los ODCR abiertos mediante la coincidencia abierta, pero no los prioriza. Las instancias lanzadas mediante una coincidencia abierta se etiquetan con `karpenter.sh/capacity-type: on-demand`, no con `reserved`. Para priorizar el uso de ODCR y etiquetar las instancias con `karpenter.sh/capacity-type: reserved`, configure `capacityReservationSelectorTerms` en la definición de NodeClass. Los bloques de capacidad para ML siempre requieren `capacityReservationSelectorTerms` y no se utilizan automáticamente.
## Reservas de capacidad bajo demanda (ODCR) de EC2
Las reservas de capacidad bajo demanda (ODCR) de EC2 le permiten reservar capacidad de computación para sus instancias de Amazon EC2 en una zona de disponibilidad específica por cualquier período. Cuando utilice el modo automático de EKS, le recomendamos controlar si sus cargas de trabajo de Kubernetes se implementan en estas instancias reservadas para maximizar la utilización de la capacidad previamente adquirida o para garantizar que las cargas de trabajo críticas tengan acceso a los recursos garantizados.
De forma predeterminada, el modo automático de EKS se inicia automáticamente en las ODCR abiertas. Sin embargo, cuando configura `capacityReservationSelectorTerms` en una NodeClass, puede controlar de forma explícita cuáles ODCR utilizan sus cargas de trabajo. Los nodos aprovisionados mediante ODCR configuradas tendrán `karpenter.sh/capacity-type: reserved` y se priorizarán frente a los nodos bajo demanda y nodos de spot. Una vez habilitada esta característica, el modo automático de EKS ya no utilizará automáticamente las ODCR abiertas; deben seleccionarse explícitamente mediante una NodeClass, lo que le permite controlar con precisión el uso de las reservas de capacidad en todo el clúster.
**aviso**
Si configura `capacityReservationSelectorTerms` en una NodeClass de un clúster, el modo automático de EKS ya no utilizará automáticamente las ODCR abiertas para *ninguna* NodeClass del clúster.
### Ejemplo de NodeClass
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
spec:
# Optional: Selects upon on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
app: "my-app"
# Optional owning account ID filter
owner: "012345678901"
```
Este ejemplo de NodeClass muestra dos enfoques para seleccionar las ODCR. El primer método hace referencia directamente a una ODCR específica mediante su ID (`cr-56fac701cc1951b03`). El segundo método utiliza la selección basada en etiquetas y se dirige a las ODCR con la etiqueta `Name: "targeted-odcr"`. También puede filtrar opcionalmente por la cuenta de AWS propietaria de la reserva, lo cual es particularmente útil en escenarios de varias cuentas o cuando se trabaja con reservas de capacidad compartida.
## Bloques de capacidad de EC2 para ML
Los bloques de capacidad para ML reservan instancias de computación acelerada basadas en GPU en una fecha futura para admitir cargas de trabajo de machine learning (ML) de corta duración. Las instancias que se ejecutan en un bloque de capacidad se colocan automáticamente cerca dentro de Amazon EC2 UltraClusters para conseguir redes que no generen bloqueos, de escala de petabits y de baja latencia.
Para obtener más información acerca de las plataformas y los tipos de instancias compatibles, consulte [Bloques de capacidad para ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) en la Guía del usuario de EC2.
Puede crear una NodeClass del modo automático EKS que utilice un bloque de capacidad para ML, similar a una ODCR (descrita anteriormente).
Los siguientes ejemplos de definiciones crean tres recursos:
1. Una NodeClass que hace referencia a la reserva del bloque de capacidad
1. Un NodePool que usa la NodeClass y aplica una taint
1. Una especificación de pod que tolera la taint y solicita recursos de la GPU
### Ejemplo de NodeClass
Esta NodeClass hace referencia a un bloque de capacidad específico para ML mediante su ID de reserva. Puede obtener este ID en la consola de EC2.
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
# Specify your Capacity Block reservation ID
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
```
Para obtener más información, consulte [Cómo crear una clase de nodos para Amazon EKS](create-node-class.md).
### NodePool de muestra
Este NodePool hace referencia a la NodeClass `gpu` y especifica una configuración importante:
+ **Solo** usa la capacidad reservada mediante la configuración `karpenter.sh/capacity-type: reserved`.
+ Solicita familias de instancias de GPU específicas adecuadas para las cargas de trabajo de ML.
+ Aplica una taint `nvidia.com/gpu` para garantizar que solo las cargas de trabajo de GPU estén programadas en estos nodos
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: gpu
requirements:
- key: eks.amazonaws.com/instance-family
operator: In
values:
- g6
- p4d
- p4de
- p5
- p5e
- p5en
- p6
- p6-b200
- key: karpenter.sh/capacity-type
operator: In
values:
- reserved
# Enable other capacity types
# - on-demand
# - spot
taints:
- effect: NoSchedule
key: nvidia.com/gpu
```
Para obtener más información, consulte [Creación de un grupo de nodos para el modo automático de EKS](create-node-pool.md).
### Pod de ejemplo
Este pod de ejemplo muestra cómo configurar una carga de trabajo para que se ejecute en los nodos del bloque de capacidad:
+ Utiliza un **nodeSelector** para usar como destino tipos de GPU específicos (en este caso, GPU H200).
+ Incluye una **tolerancia** a la taint `nvidia.com/gpu` aplicada por el NodePool.
+ **Solicita explícitamente los recursos de la GPU** mediante el tipo de recurso `nvidia.com/gpu`.
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
# Select specific GPU type - uncomment as needed
# eks.amazonaws.com/instance-gpu-name: l4
# eks.amazonaws.com/instance-gpu-name: a100
eks.amazonaws.com/instance-gpu-name: h200
# eks.amazonaws.com/instance-gpu-name: b200
eks.amazonaws.com/compute-type: auto
restartPolicy: OnFailure
containers:
- name: nvidia-smi
image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
args:
- "nvidia-smi"
resources:
requests:
# Uncomment if needed
# memory: "30Gi"
# cpu: "3500m"
nvidia.com/gpu: 1
limits:
# Uncomment if needed
# memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
Para obtener más información, consulte [Pods](https://kubernetes.io/docs/concepts/workloads/pods/) en la documentación de Kubernetes.
### Activos relacionados
+ [Bloques de capacidad para ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) en la Guía del usuario de Amazon EC2
+ [Búsqueda y compra de bloques de capacidad](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-purchase.html) en la Guía del usuario de Amazon EC2
+ [Administración de los recursos computacionales para las cargas de trabajo de IA/ML en Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/ml-compute-management.html)
+ [Optimización de recursos de GPU y administración de costos](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html#_gpu_resource_optimization_and_cost_management) en la Guía de prácticas recomendadas de EKS
# Implementación de nodos del modo automático de EKS en Zonas locales
El modo automático de EKS proporciona una administración de clústeres simplificada con aprovisionamiento automático de nodos. Las Zonas locales de AWS amplían la infraestructura de AWS a ubicaciones geográficas más cercanas a los usuarios finales, lo que reduce la latencia de las aplicaciones sensibles a la latencia. En esta guía, obtendrá los pasos del proceso de implementación de nodos del modo automático de EKS en Zonas locales de AWS, lo que le permite ejecutar aplicaciones en contenedores con una latencia más baja para los usuarios de áreas geográficas específicas.
Además, también se muestra cómo utilizar taints y tolerancias de Kubernetes para garantizar que solo se ejecuten cargas de trabajo específicas en los nodos de Zonas locales, lo que lo ayuda a controlar los costos y optimizar el uso de recursos.
## Requisitos previos
Antes de comenzar a implementar los nodos del modo automático de EKS en Zonas Locales, asegúrese de cumplir los siguientes requisitos previos.
+ [Un clúster del modo automático de EKS existente](create-auto.md)
+ [Uso de la Zona local en su cuenta de AWS](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-find-local-zone)
## Paso 1: creación de la subred de la Zona local
El primer paso para implementar los nodos del modo automático de EKS en una Zona local es crear una subred en esa Zona local. Esta subred proporciona la infraestructura de red para los nodos y les permite comunicarse con el resto de la VPC. Siga las instrucciones de [Creación de una subred de Zona local](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-create-local-zone-subnet) (en la Guía del usuario de Zonas locales de AWS) para crear una subred en la Zona local que elija.
**sugerencia**
Anote el nombre de la subred de la Zona local.
## Paso 2: creación de NodeClass para la subred de la Zona local
Después de crear la subred de la zona local, debe definir una NodeClass que haga referencia a esta subred. NodeClass es un recurso personalizado de Kubernetes que especifica los atributos de infraestructura de los nodos, lo que incluye las subredes, los grupos de seguridad y las configuraciones de almacenamiento que se deben utilizar. En el siguiente ejemplo, creamos una NodeClass llamada “local-zone” que tiene como destino una subred de la Zona local basada en su nombre. También puede usar el ID de la subred. Deberá adaptar esta configuración para que su destino sea la subred de la Zona local.
Para obtener más información, consulte [Cómo crear una clase de nodos para Amazon EKS](create-node-class.md).
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: local-zone
spec:
subnetSelectorTerms:
- id:
```
## Paso 3: creación de NodePool con NodeClass y Taint
Con la NodeClass configurada, ahora debe crear un NodePool que use esta NodeClass. Un NodePool define las características de computación de los nodos, lo que incluye los tipos de instancias. El NodePool usa la NodeClass como referencia para determinar dónde se lanzarán las instancias.
En el siguiente ejemplo, creamos un NodePool que hace referencia a nuestra NodeClass “local-zone”. También agregamos una taint a los nodos para asegurarnos de que solo se puedan programar los pods con una tolerancia coincidente en estos nodos de la Zona local. Esto es especialmente importante para los nodos de la Zona local, que suelen tener costos más elevados y solo deberían utilizarlos las cargas de trabajo que se beneficien específicamente de la reducción de la latencia.
Para obtener más información, consulte [Creación de un grupo de nodos para el modo automático de EKS](create-node-pool.md).
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
node-type: local-zone
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: local-zone
taints:
- key: "aws.amazon.com/local-zone"
value: "true"
effect: NoSchedule
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
```
La taint con la clave `aws.amazon.com/local-zone` y el efecto `NoSchedule` garantiza que los pods que no tengan una tolerancia igual no se programen en estos nodos. De este modo, se evita que las cargas de trabajo normales se ejecuten accidentalmente en la Zona local, lo que podría generar costos inesperados.
## Paso 4: implementación de cargas de trabajo con tolerancia y afinidad de nodos
Para tener un control óptimo de la ubicación de la carga de trabajo en los nodos de la Zona local, utilice simultáneamente taints y tolerancias con la afinidad de nodos. A continuación se enumeran las ventajas de este enfoque combinado:
1. **Control de costos**: esta taint garantiza que solo los grupos con tolerancias explícitas puedan utilizar recursos de la Zona local que podrían resultar costosos.
1. **Ubicación garantizada**: la afinidad de nodos garantiza que las aplicaciones sensibles a la latencia se ejecuten exclusivamente en la Zona local, no en los nodos normales de un clúster.
A continuación se muestra un ejemplo de una implementación configurada para ejecutarse específicamente en los nodos de la Zona local:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: low-latency-app
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: low-latency-app
template:
metadata:
labels:
app: low-latency-app
spec:
tolerations:
- key: "aws.amazon.com/local-zone"
operator: "Equal"
value: "true"
effect: "NoSchedule"
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: "node-type"
operator: "In"
values: ["local-zone"]
containers:
- name: application
image: my-low-latency-app:latest
resources:
limits:
cpu: "1"
memory: "1Gi"
requests:
cpu: "500m"
memory: "512Mi"
```
Esta implementación tiene dos configuraciones de programación clave:
1. La **tolerancia** permite programar los pods en los nodos con la taint `aws.amazon.com/local-zone`.
1. El requisito de **afinidad de nodos** garantiza que estos pods solo se ejecuten en los nodos con la etiqueta `node-type: local-zone`.
En conjunto, garantizan que la aplicación sensible a la latencia se ejecute solo en los nodos de la Zona local y que las aplicaciones normales no consuman los recursos de la Zona local a menos que estén configuradas explícitamente para hacerlo.
## Paso 5: verificar con la consola de AWS
Tras configurar la NodeClass, el NodePool y las implementaciones, debe comprobar que los nodos se aprovisionen en la Zona local según lo previsto y que las cargas de trabajo se ejecuten en ellos. Puede usar la Consola de administración de AWS para comprobar que las instancias de EC2 se estén lanzando en la subred de la Zona local correcta.
Además, puede consultar la lista de nodos de Kubernetes que utilizan `kubectl get nodes -o wide` para confirmar que los nodos se unen al clúster con las etiquetas y los caracteres correctos:
```
kubectl get nodes -o wide
kubectl describe node | grep -A 5 Taints
```
También puede verificar que los pods de las cargas de trabajo estén programados en los nodos de la Zona local:
```
kubectl get pods -o wide
```
Este enfoque garantiza que solo las cargas de trabajo que toleren específicamente la taint de la Zona local se programen en estos nodos, lo que lo ayuda a controlar los costos y a hacer un uso más eficiente de los recursos de la Zona local.
# Configuración de ajustes avanzados de seguridad para los nodos
En este tema, se describe cómo configurar ajustes avanzados de seguridad para nodos del modo automático de Amazon EKS mediante la especificación `advancedSecurity` en la clase de nodo.
## Requisitos previos
Antes de comenzar, asegúrese de que dispone de lo siguiente:
+ Un clúster del modo automático de Amazon EKS. Para obtener más información, consulte [Cómo crear un clúster con el modo automático de Amazon EKS](create-auto.md).
+ `kubectl` instalado y configurado Para obtener más información, consulte [Configuración para usar Amazon EKS](setting-up.md).
+ Explicación sobre la configuración de la clase de nodo. Para obtener más información, consulte [Cómo crear una clase de nodos para Amazon EKS](create-node-class.md).
## Configuración de ajustes avanzados de seguridad
Para configurar ajustes avanzados de seguridad para los nodos, establezca los campos `advancedSecurity` en la especificación de la clase de nodo:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: security-hardened
spec:
role: MyNodeRole
subnetSelectorTerms:
- tags:
Name: "private-subnet"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
advancedSecurity:
# Enable FIPS-compliant AMIs (US regions only)
fips: true
# Configure kernel lockdown mode
kernelLockdown: "integrity"
```
Aplique esta configuración:
```
kubectl apply -f nodeclass.yaml
```
Haga referencia a esta clase de nodo en la configuración del grupo de nodos. Para obtener más información, consulte [Creación de un grupo de nodos para el modo automático de EKS](create-node-pool.md).
## Descripción del campo
+ `fips` (booleano, opcional): cuando se establece en `true`, aprovisiona nodos con AMI que incluyen módulos criptográficos validados conforme a FIPS 140-2. Este ajuste selecciona AMI compatibles con FIPS; los clientes son responsables de administrar sus requisitos de cumplimiento. Para obtener más información, consulte [Cumplimiento de FIPS en AWS](https://aws.amazon.com/compliance/fips/). Valor predeterminado: `false`.
+ `kernelLockdown` (cadena, opcional): controla el modo del módulo de seguridad de bloqueo del kernel. Valores aceptados:
+ `integrity`: bloquea los métodos para sobrescribir la memoria del kernel o modificar el código del kernel. Impide la carga de módulos del kernel sin firma.
+ `none`: desactiva la protección de bloqueo del kernel.
Para obtener más información, consulte la [documentación sobre el bloqueo del kernel de Linux](https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html).
## Consideraciones
+ Las AMI compatibles con FIPS están disponibles en las regiones de AWS Este/Oeste de EE. UU., AWS GovCloud (EE. UU.) y AWS Canadá (centro/oeste). Para obtener más información, consulte [Cumplimiento de FIPS en AWS](https://aws.amazon.com/compliance/fips/).
+ Cuando utilice `kernelLockdown: "integrity"`, asegúrese de que las cargas de trabajo no requieran cargar módulos del kernel sin firma ni modificar la memoria del kernel.
## Recursos relacionados
+ [Cómo crear una clase de nodos para Amazon EKS](create-node-class.md): guía completa de configuración de la clase de nodo
+ [Creación de un grupo de nodos para el modo automático de EKS](create-node-pool.md): configuración del grupo de nodos
# Más información sobre cómo funciona el modo automático de EKS
Utilice este capítulo para aprender cómo funcionan los componentes de los clústeres del modo automático de Amazon EKS.
**Topics**
+ [Más información sobre las instancias administradas del modo automático de Amazon EKS](automode-learn-instances.md)
+ [Más información sobre las identidades y el acceso en el modo automático de EKS](auto-learn-iam.md)
+ [Más información sobre las redes de VPC y el equilibrio de carga en el modo automático de EKS](auto-networking.md)
# Más información sobre las instancias administradas del modo automático de Amazon EKS
En este tema se explica la forma en que el modo automático de Amazon EKS administra las instancias de Amazon EC2 en el clúster de EKS. Al habilitar el modo automático de EKS, EKS aprovisiona y administra automáticamente los recursos de computación del clúster, lo que cambia la forma en que se interactúa con las instancias de EC2 que se desempeñan como nodos en el clúster.
Comprender la forma en que el modo automático de Amazon EKS administra las instancias es esencial para planificar la estrategia de implementación de cargas de trabajo y los procedimientos operativos. A diferencia de las instancias de EC2 tradicionales o los grupos de nodos administrados, estas instancias siguen un modelo de ciclo de vida diferente en el que EKS asume la responsabilidad de varios aspectos operativos, a la vez que restringe ciertos tipos de acceso y personalización.
El modo automático de Amazon EKS automatiza las tareas rutinarias de creación de nuevas instancias de EC2, a las que asocia como nodos al clúster de EKS. El modo automático de EKS detecta cuándo una carga de trabajo no cabe en los nodos existentes y crea una nueva instancia de EC2.
El modo automático de Amazon EKS se encarga de crear y eliminar instancias de EC2, así como de aplicarles revisiones. Usted es responsable de los contenedores y pods implementados en la instancia.
Las Instancias de EC2 creadas por el modo automático de EKS son diferentes de otras instancias de EC2, ya que se trata de instancias administradas. Estas instancias administradas son propiedad de EKS y tienen más restricciones. No puede acceder directamente ni instalar software en instancias administradas por el modo automático de EKS.
AWS sugiere ejecutar el modo automático de EKS o el Karpenter autoadministrado. Puede instalar ambos durante una migración o en una configuración avanzada. Si ambos están instalados, configure los grupos de nodos de modo que las cargas de trabajo se asocien a Karpenter o al modo automático de EKS.
Para obtener más información, consulte [Instancias administradas de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-ec2-managed-instances.html) en la Guía del usuario de Amazon EC2.
## Tabla de comparación
| Instancia de EC2 estándar | Instancia administrada del modo automático de EKS |
| --- | --- |
| Usted es responsable de aplicar revisiones a la instancia y de actualizarla. | AWS aplica revisiones y actualizaciones a la instancia de forma automática. |
| EKS no se hace responsable del software presente en la instancia. | EKS es responsable de cierto software en la instancia, como `kubelet`, el tiempo de ejecución del contenedor y el sistema operativo. |
| Puede eliminar la Instancia de EC2 mediante la API de EC2. | EKS determina la cantidad de instancias implementadas en la cuenta. Si elimina una carga de trabajo, EKS reducirá la cantidad de instancias en la cuenta. |
| Puede utilizar SSH para acceder a la Instancia de EC2. | Puede implementar pods y contenedores en la instancia administrada. |
| Usted determina el sistema operativo y la imagen (AMI). | AWS determina el sistema operativo y la imagen |
| Puede implementar cargas de trabajo que se basen en la funcionalidad de Windows o Ubuntu. | Puede implementar contenedores basados en Linux, pero sin dependencias específicas del sistema operativo. |
| Usted determina qué tipo de instancia y familia lanzar. | AWS determina qué tipo de instancia y familia lanzar. Puede utilizar un grupo de nodos para limitar los tipos de instancias de los que el modo automático de EKS puede seleccionar. |
La siguiente funcionalidad funciona tanto para instancias administradas como para instancias de EC2 estándar:
+ Puede ver la instancia en la consola de AWS.
+ Puede usar el almacenamiento de instancias como almacenamiento efímero para las cargas de trabajo.
### Soporte de AMI
Con el modo automático de EKS, AWS determina la imagen (AMI) utilizada para los nodos de computación. AWS supervisa el despliegue de las nuevas versiones de la AMI del modo automático de EKS. Si tiene problemas de carga de trabajo relacionados con una versión de la AMI, cree un caso de soporte. Para obtener más información, consulte [Creating support cases and case management](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html) en la Guía del usuario de AWS Support.
Por lo general, EKS lanza una nueva AMI cada semana que contiene correcciones de seguridad y CVE.
## Referencia de instancias compatibles con el modo automático de EKS
El modo automático de EKS solo crea instancias de los tipos compatibles y que cumplen con un requisito de tamaño mínimo.
El modo automático de EKS admite los siguientes tipos de instancias:
| Familia | Tipos de instancias |
| --- | --- |
| Optimizadas para la computación (C) | c8i, c8i-flex, c8gd, c8gn, c8g, c7a, c7g, c7gn, c7gd, c7i, c7i-flex, c6a, c6g, c6i, c6gn, c6id, c6in, c6gd, c5, c5a, c5d, c5ad, c5n, c4 |
| Uso general (M) | m8i, m8i-flex, m8a, m8gn, m8gb, m8gd, m8g, m7i, m7a, m7g, m7gd, m7i-flex, m6a, m6i, m6in, m6g, m6idn, m6id, m6gd, m5, m5a, m5ad, m5n, m5dn, m5d, m5zn, m4 |
| Optimizada para memoria (R) | r8i, r8i-flex, r8gn, r8gb, r8gd, r8g, r7a, r7iz, r7gd, r7i, r7g, r6a, r6i, r6id, r6in, r6idn, r6g, r6gd, r5, r5n, r5a, r5dn, r5b, r5ad, r5d, r4 |
| Ampliable (T) | t4g, t3, t3a, t2 |
| Memoria elevada (Z/X) | z1d, x8g, x2gd |
| Optimizadas para el almacenamiento (I/D) | i8ge, i7i, i8g, i7ie, i4g, i4i, i3, i3en, is4gen, d3, d3en, im4gn |
| Computación acelerada (P/G/Inf/Trn) | p5, p4d, p4de, p3, p3dn, gr6, g6, g6e, g5g, g5, g4dn, inf2, inf1, trn1, trn1n |
| Computación de alto rendimiento (X2) | x2iezn, x2iedn, x2idn |
Además, el modo automático de EKS solo creará instancias de EC2 que cumplan los siguientes requisitos:
+ Más de 1 CPU
+ El tamaño de la instancia no es nano, micro ni pequeño
Para obtener más información, consulte [Convenciones de nomenclatura de tipos de instancias de Amazon EC2](https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-type-names.html).
## Servicio de metadatos de instancias
+ El modo automático de EKS aplica IMDSv2 con un límite de saltos de 1 de forma predeterminada, siguiendo las prácticas recomendadas de seguridad de AWS.
+ Esta configuración predeterminada no se puede modificar en el modo automático.
+ Para los complementos que normalmente requieren acceso al IMDS, proporcione parámetros (como la región de AWS) durante la instalación para evitar búsquedas en el IMDS. Para obtener más información, consulte [Determinación de los campos que se pueden personalizar para los complementos de Amazon EKS](kubernetes-field-management.md).
+ Si un pod requiere acceso al IMDS cuando se ejecuta en modo automático, debe configurar el pod para que se ejecute con `hostNetwork: true`. Esto permite que el pod acceda directamente al servicio de metadatos de la instancia.
+ Tenga en cuenta las implicaciones de seguridad a la hora de conceder a los pods acceso a los metadatos de la instancia.
Para obtener más información acerca del servicio de metadatos de instancias (IMDS) de Amazon EC2, consulte [Configuración de las opciones del servicio de metadatos de instancias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html) en la *Guía del usuario de Amazon EC2*.
## Consideraciones
+ Si el almacenamiento efímero configurado en NodeClass es más pequeño que el almacenamiento local NVMe de la instancia, el modo automático de EKS elimina la necesidad de realizar una configuración manual, ya que toma automáticamente las siguientes medidas:
+ Utiliza un volumen de datos de Amazon EBS más pequeño (20 GiB) para reducir los costos.
+ Formatea y configura el almacenamiento local NVMe para el uso efímero de datos. Esto incluye configurar una matriz RAID 0 si hay varias unidades NVMe.
+ Cuando `ephemeralStorage.size` iguala o supera la capacidad de NVMe local, se producen las siguientes acciones:
+ El Modo automático omite el volumen pequeño de EBS.
+ Las unidades NVMe se exponen directamente a su carga de trabajo.
+ El modo automático de Amazon EKS no admite las siguientes acciones del servicio de inyección de errores de AWS:
+ `ec2:RebootInstances`
+ `ec2:SendSpotInstanceInterruptions`
+ `ec2:StartInstances`
+ `ec2:StopInstances`
+ `ec2:TerminateInstances`
+ `ec2:PauseVolumeIO`
+ El modo automático de Amazon EKS admite las acciones de pods de EKS del servicio de inyección de errores de AWS. Para obtener más información, consulte [Administración de experimentos del servicio de inyección de errores](https://docs.aws.amazon.com/resilience-hub/latest/userguide/testing.html) y [Uso de las acciones aws:eks:pod del FID de AWS](https://docs.aws.amazon.com/fis/latest/userguide/eks-pod-actions.html#configure-service-account) en la Guía del usuario de AWS Resilience Hub.
+ No es necesario instalar el `Neuron Device Plugin` en los nodos del modo automático de EKS.
Si tiene otros tipos de nodos en el clúster, deberá configurar el complemento Neuron Device de modo que no se ejecute en nodos de modo automático. Para obtener más información, consulte [Cómo controlar si una carga de trabajo se implementa en nodos del modo automático de EKS](associate-workload.md).
# Más información sobre las identidades y el acceso en el modo automático de EKS
En este tema se describen los roles y permisos de Identity and Access Management (IAM) que se necesitan para utilizar el modo automático de EKS. El modo automático de EKS utiliza dos roles de IAM principales: un rol de IAM de clúster y un rol de IAM del nodo. Estos roles funcionan conjuntamente con EKS Pod Identity y las entradas de acceso de EKS para proporcionar una administración de acceso completa para los clústeres de EKS.
Al configurar el modo automático de EKS, deberá establecer estos roles de IAM con permisos específicos que permitan a los servicios de AWS interactuar con los recursos del clúster. Esto incluye permisos para administrar recursos de computación, volúmenes de almacenamiento, equilibradores de carga y componentes de red. Comprender estas configuraciones de roles resulta esencial para el correcto funcionamiento y la seguridad del clúster.
En el modo automático de EKS, los roles de AWS IAM se asignan automáticamente a los permisos de Kubernetes a través de las entradas de acceso de EKS, por lo que no es necesario configurar manualmente ConfigMaps `aws-auth` ni vínculos personalizados. Al crear un nuevo clúster en modo automático, EKS crea automáticamente los permisos de Kubernetes correspondientes mediante entradas de acceso, lo que garantiza que los servicios de AWS y los componentes del clúster cuenten con los niveles de acceso adecuados en los sistemas de autorización de AWS y Kubernetes. Esta integración automatizada reduce la complejidad de la configuración y ayuda a evitar los problemas relacionados con los permisos que se producen por lo general al administrar clústeres de EKS.
## Rol de IAM de clúster
El rol de IAM del clúster es un rol de AWS Identity and Access Management (IAM) que Amazon EKS utiliza para administrar los permisos de los clústeres de Kubernetes. Este rol concede a Amazon EKS los permisos necesarios para interactuar con otros servicios de AWS en nombre del clúster y se configura automáticamente con los permisos de Kubernetes mediante las entradas de acceso de EKS.
+ Debe asociar las políticas de AWS IAM a este rol.
+ El modo automático de EKS asigna permisos de Kubernetes a este rol automáticamente mediante entradas de acceso de EKS.
+ Con el modo automático de EKS, AWS sugiere crear un único rol de IAM de clúster por cuenta de AWS.
+ AWS sugiere asignar el nombre `AmazonEKSAutoClusterRole` a este rol.
+ Este rol requiere permisos para varios servicios de AWS para administrar recursos, incluidos volúmenes de EBS, equilibradores de carga elásticos e instancias de EC2.
+ La configuración sugerida para este rol incluye múltiples políticas de IAM administradas de AWS, relacionadas con las diferentes capacidades del modo automático de EKS.
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
Para obtener más información sobre el rol de IAM de clúster y las políticas de IAM administradas por AWS, consulte:
+ [Políticas administradas de AWS para Amazon Elastic Kubernetes Service](security-iam-awsmanpol.md)
+ [Rol de IAM del clúster de Amazon EKS](cluster-iam-role.md)
Para obtener más información sobre el acceso a Kubernetes, consulte:
+ [Revisión de los permisos de la política de acceso](access-policy-permissions.md)
## Rol de IAM de nodo
El rol de IAM del nodo es un rol de AWS Identity and Access Management (IAM) utilizado por Amazon EKS para administrar los permisos de los nodos de trabajo en los clústeres de Kubernetes. Este rol concede a las instancias de EC2 que se ejecutan como nodos de Kubernetes los permisos necesarios para interactuar con servicios y recursos de AWS, y se configura automáticamente con permisos RBAC de Kubernetes mediante entradas de acceso de EKS.
+ Debe asociar las políticas de AWS IAM a este rol.
+ El modo automático de EKS asigna permisos de RBAC de Kubernetes a este rol automáticamente mediante entradas de acceso de EKS.
+ AWS sugiere asignar el nombre `AmazonEKSAutoNodeRole` a este rol.
+ Con el modo automático de EKS, AWS sugiere crear un único rol de IAM del nodo por cuenta de AWS.
+ Este rol tiene permisos limitados. Los permisos clave incluyen asumir un rol de Pod Identity y extraer imágenes de ECR.
+ AWS sugiere las siguientes políticas de IAM administradas por AWS:
+ `AmazonEKSWorkerNodeMinimalPolicy`
+ `AmazonEC2ContainerRegistryPullOnly`
Para obtener más información sobre el rol de IAM de clúster y las políticas de IAM administradas por AWS, consulte:
+ [Políticas administradas de AWS para Amazon Elastic Kubernetes Service](security-iam-awsmanpol.md)
+ [Rol de IAM de nodo de Amazon EKS](create-node-role.md)
Para obtener más información sobre el acceso a Kubernetes, consulte:
+ [Revisión de los permisos de la política de acceso](access-policy-permissions.md)
## Rol vinculado a servicios
Amazon EKS utiliza un rol vinculado al servicio (SLR) para determinadas operaciones. Un rol vinculado a servicios es un tipo único de rol de IAM que se encuentra vinculado directamente a Amazon EKS. Los roles vinculados a servicios se encuentran predefinidos por Amazon EKS e incluyen todos los permisos que el servicio requiere para llamar a otros servicios de AWS en su nombre.
AWS crea y configura automáticamente el SLR. Solo puede eliminar un SLR después de haber eliminado primero sus recursos relacionados. De esta forma, se protegen los recursos de Amazon EKS, ya que se evita que se puedan eliminar accidentalmente permisos de acceso a los recursos.
La política del SLR concede a Amazon EKS permisos para observar y eliminar componentes básicos de la infraestructura: recursos de EC2 (instancias, interfaces de red, grupos de seguridad), recursos de ELB (equilibradores de carga, grupos de destino), capacidades de CloudWatch (registro y métricas) y roles de IAM con prefijo “eks”. También permite la conexión en red de puntos de conexión privados mediante la asociación de VPC/zonas alojadas e incluye permisos para la supervisión de EventBridge y la limpieza de recursos etiquetados con EKS.
Para obtener más información, consulte:
+ [Política administrada de AWS: AmazonEKSServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksservicerolepolicy)
+ [Permisos de roles vinculados a servicios para Amazon EKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks)
## Etiquetas personalizadas de AWS para los recursos del modo automático de EKS
De forma predeterminada, las políticas administradas relacionadas con el modo automático de EKS no permiten aplicar etiquetas definidas por el usuario a los recursos de AWS aprovisionados en modo automático. Si desea aplicar etiquetas definidas por el usuario a los recursos de AWS, debe asociar permisos adicionales al rol de IAM del clúster con permisos suficientes para crear y modificar etiquetas en los recursos de AWS. A continuación, aparece un ejemplo de política que permitirá el acceso sin restricciones al etiquetado:
### Ver ejemplo de política de etiquetas personalizadas
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Compute",
"Effect": "Allow",
"Action": [
"ec2:CreateFleet",
"ec2:RunInstances",
"ec2:CreateLaunchTemplate"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
},
"StringLike": {
"aws:RequestTag/eks:kubernetes-node-class-name": "*",
"aws:RequestTag/eks:kubernetes-node-pool-name": "*"
}
}
},
{
"Sid": "Storage",
"Effect": "Allow",
"Action": [
"ec2:CreateVolume",
"ec2:CreateSnapshot"
],
"Resource": [
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:snapshot/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "Networking",
"Effect": "Allow",
"Action": "ec2:CreateNetworkInterface",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
},
"StringLike": {
"aws:RequestTag/eks:kubernetes-cni-node-name": "*"
}
}
},
{
"Sid": "LoadBalancer",
"Effect": "Allow",
"Action": [
"elasticloadbalancing:CreateLoadBalancer",
"elasticloadbalancing:CreateTargetGroup",
"elasticloadbalancing:CreateListener",
"elasticloadbalancing:CreateRule",
"ec2:CreateSecurityGroup"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "ShieldProtection",
"Effect": "Allow",
"Action": [
"shield:CreateProtection"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
},
{
"Sid": "ShieldTagResource",
"Effect": "Allow",
"Action": [
"shield:TagResource"
],
"Resource": "arn:aws:shield::*:protection/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}"
}
}
}
]
}
```
## Referencia de política de acceso
Para obtener más información sobre los permisos de Kubernetes utilizados por el modo automático de EKS, consulte [Revisión de los permisos de la política de acceso](access-policy-permissions.md).
# Más información sobre las redes de VPC y el equilibrio de carga en el modo automático de EKS
En este tema se explica cómo configurar las características de red y equilibrio de carga de la nube privada virtual (VPC) en el modo automático de EKS. Aunque el modo automático de EKS administra la mayoría de los componentes de red automáticamente, aún puede personalizar ciertos aspectos de la configuración de red del clúster a través de los recursos `NodeClass` y las anotaciones del equilibrador de carga.
Al utilizar el modo automático de EKS, AWS administra la configuración de la interfaz de red de contenedores (CNI) de la VPC y el aprovisionamiento del equilibrador de carga de su clúster. Para influir en los comportamientos de red, puede definir objetos `NodeClass` y aplicar anotaciones específicas a los recursos de servicio y de ingreso, al tiempo que mantiene el modelo operativo automatizado que proporciona el modo automático de EKS.
## Capacidad de redes
El modo automático de EKS tiene una nueva capacidad de red que gestiona las redes de nodos y pods. Para configurarla, puede crear un objeto `NodeClass` de Kubernetes.
Las opciones de configuración de la CNI de AWS VPC anterior no se aplicarán al modo automático de EKS.
### Configuración de las redes con una `NodeClass`
El recurso `NodeClass` del modo automático de EKS permite personalizar ciertos aspectos de la capacidad de la red. A través de `NodeClass`, puede especificar selecciones de grupos de seguridad, controlar la colocación de nodos a través de subredes de la VPC, establecer políticas SNAT, configurar políticas de red y habilitar el registro de eventos de red. Este enfoque mantiene el modelo operativo automatizado del modo automático de EKS a la vez que ofrece flexibilidad a la hora de personalizar la red.
Puede utilizar `NodeClass` para:
+ Seleccionar un grupo de seguridad para los nodos
+ Controlar cómo se colocan los nodos en las subredes de la VPC
+ Establecer la política SNAT del nodo en `random` o `disabled`
+ Habilite las *políticas de red* de Kubernetes, que incluyen:
+ Establecer la política de red en Denegar de forma predeterminada o Permitir de forma predeterminada
+ Habilitar el registro de eventos de red en un archivo.
+ Conectar los pods a diferentes subredes para aislar el tráfico de los pods del tráfico de los nodos.
Más información sobre la [Creación de una NodeClass de Amazon EKS](create-node-class.md).
### Consideraciones
El modo automático de EKS admite:
+ Políticas de red de EKS.
+ Las opciones `HostPort` y `HostNetwork` para los pods de Kubernetes.
+ Nodos y pods en subredes públicas o privadas.
+ Almacenamiento en caché de las consultas de DNS en el nodo.
El modo automático de EKS **no** admite:
+ Grupos de seguridad por pod (SGPP). Para aplicar grupos de seguridad independientes al tráfico del pod en modo automático, use `podSecurityGroupSelectorTerms` en `NodeClass` en su lugar. Para obtener más información, consulte [Subredes y grupos de seguridad independientes para pods](create-node-class.md#pod-subnet-selector).
+ Redes personalizadas en `ENIConfig`. Puede colocar los pods en varias subredes o aislarlos exclusivamente del tráfico del nodo con [Subredes y grupos de seguridad independientes para pods](create-node-class.md#pod-subnet-selector).
+ Configuraciones de IP en calentamiento, prefijos en calentamiento y ENI en calentamiento.
+ Configuración mínima de destinos de la IP.
+ Otras configuraciones admitidas por la CNI de VPC de AWS de código abierto.
+ Configuraciones de políticas de red, como la personalización del temporizador conntrack (el valor predeterminado es 300s).
+ Cómo exportar registros de eventos de red a CloudWatch.
### Administración de recursos de red
El modo automático de EKS gestiona la administración de prefijos, direcciones IP e interfaces de red mediante la supervisión de los recursos de NodeClass para las configuraciones de red. El servicio realiza varias operaciones clave de forma automática:
**Delegación de prefijos**
El modo automático de EKS utiliza de forma predeterminada la delegación de prefijos (prefijos /28) para las redes de pods y mantiene un grupo de calentamiento predefinido de recursos de IP que se escala en función del número de pods programados. Cuando se detecta la fragmentación de la subred de los pods, el modo automático aprovisiona direcciones IP secundarias (/32). Gracias a este algoritmo de red de pods predeterminado, el modo automático calcula el número máximo de pods por nodo en función del número de ENI e IP que se admiten por tipo de instancia (con la suposición del peor de los casos de fragmentación). Para obtener más información sobre la cantidad máxima de ENI e IP que se admiten por tipo de instancia, consulte [Máximo de direcciones IP por interfaz de red](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AvailableIpPerENI.html) en la Guía del usuario de Amazon EC2. Las familias de instancias de nueva generación (Nitro v6 y versiones posteriores) suelen tener más ENI e IP por tipo de instancia, y el modo automático ajusta el cálculo del número máximo de pods en consecuencia.
En el caso de los clústeres IPv6, solo se utiliza la delegación de prefijos y el modo automático siempre utiliza un límite máximo de 110 pods por nodo.
**Gestión de la recuperación**
El servicio implementa un conjunto de recuperación para los prefijos o las direcciones IPv4 secundarias que ya no se utilizan. Una vez transcurrido el periodo de recuperación, estos recursos se devuelven a la VPC. Sin embargo, si los pods reutilizan estos recursos durante el periodo de recuperación, se restauran del conjunto de recuperación.
**Compatibilidad con IPv6**
Para los clústeres de IPv6, el modo automático de EKS proporciona un prefijo de IPv6 `/80` por nodo en la interfaz de red principal. Cuando se usa `podSubnetSelectorTerms`, el prefijo se asigna en una interfaz de red secundaria en la subred del pod en su lugar.
El servicio también garantiza una administración adecuada y la recopilación de elementos no utilizados de todas las interfaces de red.
## Equilibrio de carga
Se configuran los equilibradores de carga elásticos de AWS aprovisionados por el modo automático de EKS mediante anotaciones en los recursos de servicio y de ingreso.
Para obtener más información, consulte [Creación de una IngressClass para configurar el equilibrador de carga de aplicación](auto-configure-alb.md) o [Cómo utilizar las anotaciones de servicio para configurar los equilibradores de carga de red](auto-configure-nlb.md).
### Consideraciones para el equilibrio de carga con el modo automático de EKS
+ El modo de asignación de destino predeterminado es el modo de IP, no el modo de instancia.
+ El modo automático de EKS solo admite el modo de grupo de seguridad para los equilibradores de carga de red.
+ AWS no admite la migración de los equilibradores de carga del controlador del equilibrador de carga de AWS autoadministrado a la administración mediante el modo automático de EKS.
+ No se admite el campo `networking.ingress.ipBlock` en la especificación `TargetGroupBinding`.
+ Si los nodos de trabajo utilizan grupos de seguridad personalizados (no un patrón de nomenclatura `eks-cluster-sg- `), el rol del clúster necesitará permisos de IAM adicionales. La política administrada por EKS predeterminada solo permite a EKS modificar los grupos de seguridad denominados `eks-cluster-sg-`. Sin permiso para modificar los grupos de seguridad personalizados, EKS no podrá agregar las reglas de ingreso necesarias que permitan que el tráfico del equilibrado de carga de aplicaciones y del equilibrador de carga de red (ALB/NLB) llegue a los pods.
#### Consideraciones de CoreDNS
El modo automático de EKS no utiliza la implementación tradicional de CoreDNS para proporcionar resolución de DNS dentro del clúster. En cambio, los nodos del modo automático utilizan CoreDNS que se ejecuta como un servicio del sistema directamente en cada nodo. Si está llevando a cabo la transición de un clúster tradicional al modo automático, puede eliminar la implementación de CoreDNS del clúster una vez que las cargas de trabajo se hayan trasladado a los nodos del modo automático.
**importante**
Si tiene previsto mantener un clúster con nodos del modo automático y nodos que no lo sean, debe retener la implementación de CoreDNS. Los nodos que no son del modo automático dependen de los pods de CoreDNS tradicionales para la resolución de DNS, ya que no pueden acceder al servicio de DNS del nodo que proporciona el modo automático.
# Observabilidad para el modo automático de EKS
Utilice este capítulo para conocer las opciones de observabilidad para los clústeres de EKS en modo automático.
**Topics**
+ [Acceso a los registros de componentes administrados por AWS para EKS Auto](auto-managed-component-logs.md)
# Acceso a los registros de componentes administrados por AWS para EKS Auto
Puede acceder a los registros de componentes administrados por AWS desde el modo automático de EKS para obtener mayor observabilidad de las operaciones del clúster. El modo automático de EKS admite registros de los siguientes orígenes:
+ Escalado automático de computación: Karpenter
+ Almacenamiento en bloques: EBS CSI
+ Equilibrio de carga: Controlador de equilibrador de carga de AWS
+ Red de pods: administración de direcciones IP de VPC CNI
Los registros se pueden enviar al [destino de entrega](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html) que elija.
Al crear un clúster de EKS Auto, tiene la opción de habilitar el registro del plano de control (servidor de API, auditoría, autenticador, administrador de controladores, programador). Los registros de los componentes administrados de EKS Auto (como computación, almacenamiento en bloques, equilibrio de carga e IPAM) requieren una configuración independiente mediante la entrega de registros.
## Configuración de entrega de registros
Para configurar la entrega de registros de componentes administrados por AWS para el clúster en modo automático de EKS, utilice la API de Registros de Amazon CloudWatch. Para obtener instrucciones detalladas de configuración, consulte [Habilitación del registro desde servicios de AWS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-vended-logs-permissions-V2.html) en la Guía del usuario de Registros de Amazon CloudWatch. Cada capacidad del modo automático se puede configurar como un origen individual de entrega de registros suministrados de CloudWatch, lo que le permite seleccionar a qué registros desea tener acceso.
El modo automático de EKS admite los siguientes tipos de registros:
+ **AUTO\$1MODE\$1COMPUTE\$1LOGS**
+ **AUTO\$1MODE\$1BLOCK\$1STORAGE\$1LOGS**
+ **AUTO\$1MODE\$1LOAD\$1BALANCING\$1LOGS**
+ **AUTO\$1MODE\$1IPAM\$1LOGS**
### Uso de las API de Amazon CloudWatch
La configuración del registro requiere tres pasos:
1. Crear un origen de entrega para la capacidad mediante la API PutDeliverySource de CloudWatch
1. Crear un destino de entrega mediante PutDeliveryDestination
1. Crear una entrega para conectar el origen y el destino mediante CreateDelivery
Puede configurar los detalles del destino para los registros del modo automático mediante el objeto deliveryDestinationConfiguration en la API PutDeliveryDestination de CloudWatch. Se requiere el ARN de un grupo de registro de CloudWatch, un bucket de S3 o una secuencia de entrega de Kinesis Data Firehose.
Puede configurar una única capacidad del modo automático (origen de entrega) para enviar registros a varios destinos mediante la creación de múltiples entregas. También puede crear múltiples entregas para configurar varios orígenes de entrega que envíen registros al mismo destino de entrega.
### Permisos de IAM
Según el destino seleccionado, es posible que deba configurar políticas o roles de IAM para el grupo de registro de CloudWatch, el bucket de S3 o Kinesis Data Firehose a fin de garantizar la entrega correcta de los registros. Además, si envía registros entre cuentas de AWS, deberá utilizar la API PutDeliveryDestinationPolicy para configurar una política de IAM que permita la entrega al destino. Para obtener más información, consulte la [documentación sobre permisos de Registros suministrados de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-logs-infrastructure-V2-CloudWatchLogs).
## Visualización de los registros
Una vez configurada la entrega de registros, los registros se enviarán al destino que haya especificado. El método para acceder a los registros depende del tipo de destino elegido:
+ **Registros de CloudWatch**: vea los registros en la consola de Registros de CloudWatch, utilice comandos de la CLI de AWS o realice consultas con Información de registros de CloudWatch.
+ **Amazon S3**: acceda a los registros como objetos en el bucket de S3 mediante la consola de S3, la CLI de AWS o herramientas de análisis, como Amazon Athena.
+ **Amazon Data Firehose**: los registros se transmiten al destino de Firehose configurado (como S3, OpenSearch Service, Redshift, etc.)
## Precios
Se aplican cargos por Registros suministrados de CloudWatch por la entrega y el almacenamiento de registros según el destino de entrega seleccionado. Registros suministrados de CloudWatch permite una entrega de registros confiable y segura con autenticación y autorización integradas de AWS, a un costo reducido en comparación con los Registros de CloudWatch estándar. Consulte la sección [Registros suministrados en la página de precios de CloudWatch](https://aws.amazon.com/cloudwatch/pricing/) para obtener más detalles.
### Activos relacionados
+ [Registro de plano de control de Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html)
+ [API PutDeliverySource](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliverySource.html) en la Referencia de la API de Registros de CloudWatch
+ [API PutDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html) en la Referencia de la API de Registros de CloudWatch
+ [API CreateDelivery](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html) en la Referencia de la API de Registros de CloudWatch
# Solución de problemas del modo automático de EKS
Con el modo automático de EKS, AWS asume más responsabilidad por las instancias de EC2 de la cuenta de AWS. EKS asume la responsabilidad del tiempo de ejecución del contenedor en los nodos, el sistema operativo en los nodos y determinados controladores. Incluye un controlador de almacenamiento en bloque, un controlador de equilibrio de carga y un controlador de computación.
Debe utilizar las API de Kubernetes y AWS para solucionar problemas en los nodos. Puede hacer lo siguiente:
+ Utilice un recurso `NodeDiagnostic` de Kubernetes para recuperar registros de nodos mediante el [Agente de supervisión de nodos](#auto-node-monitoring-agent). Para ver más pasos, consulte [Recuperación de los registros de nodos de un nodo administrado mediante kubectl y S3](auto-get-logs.md).
+ Utilice el comando AWS de la CLI de `get-console-output` EC2 para recuperar la salida de la consola de los nodos. Para ver más pasos, consulte [Obtenga la salida de la consola de una instancia administrada por EC2 mediante la CLI de AWS EC2](#auto-node-console).
+ Utilice *contenedores de depuración* de Kubernetes para recuperar registros de nodos. Para ver más pasos, consulte [Obtenga los registros de los nodos mediante *contenedores de depuración* y la `kubectl` CLI](#auto-node-debug-logs).
**nota**
El modo automático de EKS utiliza instancias administradas por EC2. No puede acceder directamente a las instancias administradas por EC2, ni siquiera mediante SSH.
Es posible que tenga los siguientes problemas con soluciones específicas para los componentes del modo automático de EKS:
+ Los pods están atascados en el estado `Pending` y no están programados en los nodos del modo automático. Para obtener soluciones, consulte [Solución de problemas de pods que no se pueden programar en el nodo del modo automático](#auto-troubleshoot-schedule).
+ Instancias administradas de EC2 que no se unen al clúster como nodos de Kubernetes. Para obtener soluciones, consulte [Solución de problemas de un nodo que no se une al clúster](#auto-troubleshoot-join).
+ Errores y problemas con los `NodePools`, `PersistentVolumes` y `Services` que utilizan los controladores incluidos en el modo automático de EKS. Para obtener soluciones, consulte [Solución de problemas de los controladores incluidos en el modo automático](#auto-troubleshoot-controllers).
+ La seguridad mejorada de los pods impide compartir volúmenes entre pods. Para obtener soluciones, consulte [Cómo compartir volúmenes entre pods](#auto-troubleshoot-share-pod-volumes).
Puede utilizar los siguientes métodos para solucionar problemas de los componentes del modo automático de EKS:
+ [Obtenga la salida de la consola de una instancia administrada por EC2 mediante la CLI de AWS EC2](#auto-node-console)
+ [Obtenga los registros de los nodos mediante *contenedores de depuración* y la `kubectl` CLI](#auto-node-debug-logs)
+ [Consulte los recursos asociados al modo automático de EKS en la consola de AWS](#auto-node-ec2-web)
+ [Consulte los errores de IAM en la cuenta de AWS](#auto-node-iam)
+ [Detección de problemas de conectividad de los nodos con el `VPC Reachability Analyzer`](#auto-node-reachability)
## Agente de supervisión de nodos
El modo automático de EKS incluye el agente de supervisión de nodos de Amazon EKS. Puede utilizar este agente para ver información de solución de problemas y depuración relativa a los nodos. El agente de supervisión de nodos publica `events` de Kubernetes y `conditions` de nodos. 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).
## Obtenga la salida de la consola de una instancia administrada por EC2 mediante la CLI de AWS EC2
Este procedimiento ayuda a solucionar problemas en el arranque o a nivel del kernel.
En primer lugar, debe determinar el ID de la instancia de EC2 asociada a la carga de trabajo. En segundo lugar, utilice AWS CLI para recuperar la salida de la consola.
1. Confirme que `kubectl` se encuentra instalado y conectado al clúster
1. (Opcional) Utilice el nombre de una implementación de Kubernetes para enumerar los pods asociados.
```
kubectl get pods -l app=
```
1. Utilice el nombre del pod de Kubernetes para determinar el ID de instancia de EC2 del nodo asociado.
```
kubectl get pod -o wide
```
1. Utilice el ID de instancia de EC2 para recuperar la salida de la consola.
```
aws ec2 get-console-output --instance-id --latest --output text
```
## Obtenga los registros de los nodos mediante *contenedores de depuración* y la `kubectl` CLI
La forma recomendada de recuperar los registros de un nodo del modo automático de EKS es utilizar el recurso `NodeDiagnostic`. Para ver los pasos, consulte [Recuperación de los registros de nodos de un nodo administrado mediante kubectl y S3](auto-get-logs.md).
Sin embargo, puede transmitir los registros activos desde una instancia mediante el comando `kubectl debug node`. Este comando lanza un nuevo pod en el nodo que desea depurar y que puede usar de forma interactiva.
1. Lance un contenedor de depuración. El siguiente comando usa `i-01234567890123456` para el ID de instancia del nodo, `-it` asigna `tty` y adjunta `stdin` para el uso interactivo y utiliza el perfil `sysadmin` del archivo kubeconfig.
```
kubectl debug node/i-01234567890123456 -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023
```
Un ejemplo de salida sería el siguiente.
```
Creating debugging pod node-debugger-i-01234567890123456-nxb9c with container debugger on node i-01234567890123456.
If you don't see a command prompt, try pressing enter.
bash-5.2#
```
1. Desde el intérprete de comandos, ahora puede instalar `util-linux-core`, que proporciona el comando `nsenter`. Use `nsenter` para ingresar el espacio de nombres de montaje del PID 1 (`init`) en el host y ejecutar el comando `journalctl` para transmitir los registros desde el `kubelet`:
```
yum install -y util-linux-core
nsenter -t 1 -m journalctl -f -u kubelet
```
Por motivos de seguridad, la imagen del contenedor de Amazon Linux no instala muchos binarios de forma predeterminada. Puede usar el comando `yum whatprovides` a fin de identificar el paquete que debe instalarse para proporcionar un binario determinado.
```
yum whatprovides ps
```
```
Last metadata expiration check: 0:03:36 ago on Thu Jan 16 14:49:17 2025.
procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo : @System
Matched from:
Filename : /usr/bin/ps
Provide : /bin/ps
procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo : amazonlinux
Matched from:
Filename : /usr/bin/ps
Provide : /bin/ps
```
## Consulte los recursos asociados al modo automático de EKS en la consola de AWS
Puede utilizar la consola de AWS para ver el estado de los recursos asociados al clúster del modo automático de EKS.
+ [Volúmenes de EBS](https://console.aws.amazon.com/ec2/home#Volumes)
+ Para ver los volúmenes del modo automático de EKS, busque la clave de etiqueta `eks:eks-cluster-name`
+ [Balanceadores de carga](https://console.aws.amazon.com/ec2/home#LoadBalancers)
+ Para ver los equilibradores de carga del modo automático de EKS, busque la clave de etiqueta `eks:eks-cluster-name`
+ [Instancias de EC2](https://console.aws.amazon.com/ec2/home#Instances)
+ Para ver las instancias del modo automático de EKS, busque la clave de etiqueta `eks:eks-cluster-name`
## Consulte los errores de IAM en la cuenta de AWS
1. Vaya a la consola de CloudTrail
1. Seleccione “Historial de eventos” en el panel de navegación izquierdo
1. Aplique filtros de códigos de error:
+ AccessDenied
+ UnauthorizedOperation
+ InvalidClientTokenId
Busque errores relacionados con el clúster de EKS. Utilice los mensajes de error para actualizar las entradas de acceso de EKS, el rol de IAM del clúster o el rol de IAM del nodo. Es posible que tenga que asociar una nueva política a estos roles con permisos para el modo automático de EKS.
## Solución de problemas de pods que no se pueden programar en el nodo del modo automático
Si el estado de los pods es `Pending` y no se programan en un nodo del modo automático, verifique si el manifiesto de implementación o el pod tiene `nodeSelector`. Si `nodeSelector` está presente, asegúrese de que use `eks.amazonaws.com/compute-type: auto` para programar en los nodos creados con el modo automático de EKS. Para obtener más información sobre las etiquetas de nodos utilizadas por el modo automático de EKS, consulte [Cómo controlar si una carga de trabajo se implementa en nodos del modo automático de EKS](associate-workload.md).
## Solución de problemas de un nodo que no se une al clúster
El modo automático de EKS configura automáticamente las nuevas instancias de EC2 con la información correcta para que se unan al clúster, lo que incluye el punto de conexión del clúster y la autoridad de certificación (CA) del clúster. Sin embargo, es posible que estas instancias sigan sin unirse al clúster de EKS como nodo. Ejecute los siguientes comandos para identificar las instancias que no se unieron al clúster:
1. Ejecute `kubectl get nodeclaim` para buscar `NodeClaims` con `Ready = False`.
```
kubectl get nodeclaim
```
1. Ejecute `kubectl describe nodeclaim ` y busque en **Estado** cualquier problema que impida que el nodo se una al clúster.
```
kubectl describe nodeclaim
```
**Mensajes de error comunes:**
`Error getting launch template configs`
Es posible que reciba este error si configura etiquetas personalizadas en `NodeClass` con los permisos predeterminados del rol de IAM del clúster. Consulte [Más información sobre las identidades y el acceso en el modo automático de EKS](auto-learn-iam.md).
`Error creating fleet`
Es posible que exista algún problema de autorización al hacer la llamada `RunInstances` desde la API de EC2. Compruebe si hay errores en AWS CloudTrail y consulte en [Rol de IAM del clúster del modo automático de Amazon EKS](auto-cluster-iam-role.md) los permisos de IAM requeridos.
### Detección de problemas de conectividad de los nodos con el `VPC Reachability Analyzer`
**nota**
Se le cobrará por cada análisis que ejecute el Analizador de accesibilidad de VPC. Para obtener más información sobre precios, consulte [Precios de Amazon VPC](https://aws.amazon.com/vpc/pricing/).
Una de las razones por las que una instancia no se unió al clúster es un problema de conectividad de red que le impide acceder al servidor de API. Para diagnosticar este problema, puede usar el [Analizador de accesibilidad de VPC](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) para efectuar un análisis de la conectividad entre un nodo que no puede unirse al clúster y el servidor de API. Necesitará dos datos:
+ **ID de instancia** de un nodo que no puede unirse al clúster
+ Dirección IP del **punto de conexión del servidor de API de Kubernetes**
Para obtener el **ID de instancia**, tendrá que crear una carga de trabajo en el clúster para que el modo automático de EKS lance una instancia de EC2. Esto también crea un objeto `NodeClaim` en el clúster que tendrá el ID de la instancia. Ejecute `kubectl get nodeclaim -o yaml` para imprimir todas las `NodeClaims` del clúster. Cada `NodeClaim` contiene el ID de instancia como un campo y, de nuevo, en ProviderID:
```
kubectl get nodeclaim -o yaml
```
Un ejemplo de salida sería el siguiente.
```
nodeName: i-01234567890123456
providerID: aws:///us-west-2a/i-01234567890123456
```
Puede determinar el **punto de conexión del servidor de API de Kubernetes** mediante la ejecución de `kubectl get endpoint kubernetes -o yaml`. Las direcciones se encuentran en el campo de direcciones:
```
kubectl get endpoints kubernetes -o yaml
```
Un ejemplo de salida sería el siguiente.
```
apiVersion: v1
kind: Endpoints
metadata:
name: kubernetes
namespace: default
subsets:
- addresses:
- ip: 10.0.143.233
- ip: 10.0.152.17
ports:
- name: https
port: 443
protocol: TCP
```
Con estos dos datos, puede efectuar el análisis s. Primero, vaya al Analizador de accesibilidad de VPC en la Consola de administración de AWS.
1. Haga clic en “Crear y analizar ruta”.
1. Proporcione un nombre para el análisis (por ejemplo, “Error en la unión de nodos”).
1. En “Tipo de origen” seleccione “Instancias”.
1. Ingrese el ID de instancia del nodo que falla como “Origen”.
1. En “Destino de ruta”, seleccione “Dirección IP”.
1. Ingrese una de las direcciones IP del servidor de API como “Dirección de destino”.
1. Amplíe la sección “Configuración de encabezados de paquetes adicionales”.
1. Ingrese 443 como “Puerto de destino”.
1. Seleccione “Protocolo” como TCP si aún no está seleccionado.
1. Haga clic en “Crear y analizar ruta”.
1. El análisis puede tardar unos minutos en completarse. Si los resultados del análisis indican un error de accesibilidad, indicarán dónde se produjo el error en la ruta de la red para que pueda resolver el problema.
## Cómo compartir volúmenes entre pods
Los nodos del modo automático de EKS se configuran con SELinux en modo de aplicación, lo que proporciona un mayor aislamiento entre los pods que se ejecutan en el mismo nodo. Cuando SELinux está habilitado, a la mayoría de los pods no privilegiados se les aplicará automáticamente su propia etiqueta de seguridad multicategoría (MCS). Esta etiqueta MCS es única para cada pod y está diseñada para garantizar que el proceso de un pod no pueda manipular el proceso de ningún otro pod o del host. Incluso si un pod etiquetado funciona como raíz y tiene acceso al sistema de archivos del host, no podrá manipular los archivos, hacer llamadas confidenciales del sistema desde el host, acceder al tiempo de ejecución del contenedor ni obtener la clave secreta del kubelet.
Por este motivo, es posible que tenga problemas al intentar compartir datos entre pods. Por ejemplo, una `PersistentVolumeClaim` con el modo de acceso `ReadWriteOnce` no permitirá que varios pods accedan al volumen simultáneamente.
Para habilitar este uso compartido entre pods, puede usar `seLinuxOptions` de los pods para configurar la misma etiqueta MCS en esos pods. En este ejemplo, asignamos las tres categorías `c123,c456,c789` al pod. Esto no entrará en conflicto con ninguna de las categorías que se asignen automáticamente a los pods en el nodo, ya que solo se les asignarán dos categorías.
```
securityContext:
seLinuxOptions:
level: "s0:c123,c456,c789"
```
## Visualización de los eventos de Karpenter en los registros del plano de control
En el caso de los clústeres de EKS con los registros del plano de control habilitados, puede obtener información sobre las acciones y el proceso de toma de decisiones de Karpenter consultándolos. Esto puede resultar especialmente útil para solucionar problemas del modo automático de EKS relacionados con el aprovisionamiento, el escalado y la terminación de los nodos. Para ver los eventos relacionados con Karpenter, utilice la siguiente consulta de CloudWatch Logs Insights:
```
fields @timestamp, @message
| filter @logStream like /kube-apiserver-audit/
| filter @message like 'DisruptionBlocked'
or @message like 'DisruptionLaunching'
or @message like 'DisruptionTerminating'
or @message like 'DisruptionWaitingReadiness'
or @message like 'Unconsolidatable'
or @message like 'FailedScheduling'
or @message like 'NoCompatibleInstanceTypes'
or @message like 'NodeRepairBlocked'
or @message like 'Disrupted'
or @message like 'Evicted'
or @message like 'FailedDraining'
or @message like 'TerminationGracePeriodExpiring'
or @message like 'TerminationFailed'
or @message like 'FailedConsistencyCheck'
or @message like 'InsufficientCapacityError'
or @message like 'UnregisteredTaintMissing'
or @message like 'NodeClassNotReady'
| sort @timestamp desc
```
Esta consulta filtra [eventos específicos relacionados con Karpenter](https://github.com/kubernetes-sigs/karpenter/blob/main/pkg/events/reason.go) en los registros de auditoría de kube-apiserver. Los eventos incluyen varios estados de interrupción, errores de programación, problemas de capacidad y problemas relacionados con los nodos. Al analizar estos registros, puede comprender mejor lo siguiente:
+ Por qué Karpenter está tomando ciertas medidas.
+ Cualquier problema que impida el aprovisionamiento, el escalado o la terminación adecuados de los nodos.
+ Posibles problemas de capacidad o compatibilidad con los tipos de instancias.
+ Eventos del ciclo de vida de los nodos, como interrupciones, expulsiones o terminaciones.
Para usar esta consulta, siga estos pasos:
1. Diríjase a la consola de CloudWatch.
1. Seleccione “Logs Insights” en el panel de navegación izquierdo.
1. Elija el grupo de registros para los registros del plano de control de su clúster de EKS.
1. Pegue la consulta en el editor de consultas.
1. Ajuste el intervalo de tiempo según sea necesario.
1. Ejecute la consulta
Los resultados le mostrarán una cronología de los eventos relacionados con Karpenter, lo que le ayudará a solucionar problemas y a comprender el comportamiento del modo automático EKS en su clúster. Para revisar las acciones de Karpenter en un nodo específico, puede añadir el siguiente filtro de línea que especifica el ID de la instancia a la consulta antes mencionada:
```
|filter @message like /[.replaceable]`i-12345678910123456`/
```
**nota**
Para utilizar esta consulta, el registro del plano de control debe estar habilitado en el clúster de EKS. Si aún no lo ha hecho, consulte [Envío de los registros del plano de control a Registros de CloudWatch](control-plane-logs.md).
## Solución de problemas de los controladores incluidos en el modo automático
Si surge un problema con un controlador, averigüe lo siguiente:
+ Si los recursos asociados a ese controlador tienen el formato adecuado y son válidos.
+ Si los recursos RBAC de Kubernetes y AWS IAM están configurados correctamente para el clúster. Para obtener más información, consulte [Más información sobre las identidades y el acceso en el modo automático de EKS](auto-learn-iam.md).
## Recursos relacionados
Use estos artículos de AWS re:Post para obtener pasos avanzados de solución de problemas:
+ [¿Cómo se solucionan los problemas de escalado más comunes en el modo automático de EKS?](https://repost.aws/articles/ARLpQOknr5Rb-w5iAT9sUBpQ)
+ [¿Cómo soluciono los problemas de aprovisionamiento de grupos de nodos personalizados y clases de nodos en el modo automático de Amazon EKS?](https://repost.aws/articles/ARPcmFS1POTgqPCBdcZFp6BQ)
+ [¿Cómo soluciono los problemas de los grupos de nodos integrados en el modo automático de EKS con un estado desconocido?](https://repost.aws/en/articles/ARLhrdl45TRASGkvViwtBG0Q)
# Revisión de las notas de la versión del modo automático de EKS
En esta página, se documentan las actualizaciones del modo automático de Amazon EKS. Puede consultar periódicamente esta página para ver anuncios sobre características, correcciones de errores, problemas conocidos y funciones obsoletas.
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/automode/auto-change.adoc.atom
```
## 2 de febrero de 2026
**Característica**: se agregó compatibilidad para desactivar el tráfico de salida v4 (v4Egress) desde pods IPv6 en clústeres IPv6 del modo automático de EKS. Para obtener más información, consulte [Desactivación de la salida IPv4 desde pods IPv6 en clústeres IPv6.](create-node-class.md#enableV4Egress).
## 19 de diciembre de 2025
**Característica**: se agregó compatibilidad con el modo de IP secundaria, que aprovisiona direcciones IP secundarias en lugar de prefijos para nodos automáticos. El modo mantiene una IP secundaria como MinimalIPTarget y conserva recursos de IP para los clientes que no necesitan precalentar más IP secundarias ni prefijos. Para obtener más información, consulte [Especificación de clase de nodos](create-node-class.md#auto-node-class-spec) y [Modo de IP secundaria para pods](create-node-class.md#secondary-IP-mode).
## 19 de noviembre de 2025
**Característica**: se activó el desempaquetado y la extracción en paralelo de Seekable OCI (SOCI) para instancias de las familias G, P y Trn con almacenamiento de NVMe local. El desempaquetado y la extracción en paralelo de SOCI siempre se usa para estas familias de instancias con el modo automático de EKS y no se requieren cambios en la configuración activarlo. Para obtener más información sobre SOCI, consulte el [blog de lanzamiento](https://aws.amazon.com/blogs/containers/introducing-seekable-oci-parallel-pull-mode-for-amazon-eks/).
## 19 de noviembre de 2025
**Característica:** se agregó soporte para grupos de nodos con capacidad estática que mantienen un número fijo de nodos. Para obtener más información, consulte [Grupos de nodos con capacidad estática en el modo automático de EKS](auto-static-capacity.md).
## 23 de octubre de 2025
**Característica:** los usuarios con clústeres en las regiones de EE. UU. ahora pueden solicitar AMI compatibles con FIPS si especifican `spec.advancedSecurity.fips` en su definición de NodeClass.
## 1 de octubre de 2025
**Característica:** el modo automático de EKS ahora admite la implementación de nodos en Zonas locales de AWS. Para obtener más información, consulte [Implementación de nodos del modo automático de EKS en Zonas locales](auto-local-zone.md).
## 30 de septiembre de 2025
**Característica:** se agregó soporte para instanceProfile a la NodeClass `spec.instanceProfile` que se excluye mutuamente del campo `spec.role`.
## 29 de septiembre de 2025
Actualmente, el modo automático de EKS no admite DRA.
## 10 de septiembre de 2025
**Tarea:** los eventos activados desde el controlador de computación del modo automático ahora usarán el nombre `eks-auto-mode/compute` en lugar de `karpenter`.
## 24 de agosto de 2025
**Corrección de errores:** las VPC que utilizaban un conjunto de opciones de DHCP con un nombre de dominio personalizado que contenía letras en mayúscula hacían que los nodos no pudieran unirse al clúster debido a la generación de un nombre de host no válido. Este problema se ha resuelto y los nombres de dominio con letras en mayúscula ahora funcionan correctamente.
## 15 de agosto de 2025
**Corrección de errores:** el agente de Pod Identity ahora solo escucha en la dirección local del enlace IPv4 en un clúster de EKS IPv4 para evitar problemas en los que el pod no puede alcanzar la dirección IPv6.
## 6 de agosto de 2025
**Característica:** se agregó una nueva configuración en la NodeClass `spec.advancedNetworking.associatePublicIPAddress` que se puede usar para evitar que se asignen direcciones IP públicas a los nodos de modo automático de EKS.
## 30 de junio de 2025
**Característica:** la NodeClass del Modo automático ahora utiliza la clave de KMS personalizada configurada para cifrar el volumen raíz de solo lectura de la instancia, además del volumen de datos de lectura y escritura. Anteriormente, la clave de KMS personalizada solo se utilizaba para cifrar el volumen de datos.
## 20 de junio de 2025
**Característica:** compatibilidad para controlar la implementación de cargas de trabajo en reservas de capacidad bajo demanda (ODCR) de EC2. Esto añade la clave opcional `capacityReservationSelectorTerms` a la NodeClass, lo que le permite controlar explícitamente cuáles ODCR utilizan sus cargas de trabajo. Para obtener más información, consulte [Control de la implementación de las cargas de trabajo en las reservas de capacidad con el modo automático de EKS](auto-odcr.md).
## 13 de junio de 2025
**Característica:** compatibilidad con subredes de pods independientes en `NodeClass`. Esto agrega las claves opcionales ``podSubnetSelectorTerms` y `podSecurityGroupSelectorTerms` para configurar las subredes y los grupos de seguridad de los pods. Para obtener más información, consulte [Subredes y grupos de seguridad independientes para pods](create-node-class.md#pod-subnet-selector).
## 30 de abril de 2025
**Característica:** compatibilidad con proxys de red directa en el `NodeClass`. Esto agrega la clave opcional `advancedNetworking` para configurar el proxy HTTPS. Para obtener más información, consulte [Especificación de clase de nodos](create-node-class.md#auto-node-class-spec).
## 18 de abril de 2025
**Característica:** soporte para resolver dominios .local (normalmente reservado para DNS de multidifusión) mediante DNS de unidifusión.
## 11 de abril de 2025
**Característica:** se agregó `certificateBundles` y `ephemeralStorage.kmsKeyID` a `NodeClass`. Para obtener más información, consulte [Especificación de clase de nodos](create-node-class.md#auto-node-class-spec).
**Característica:** se mejoró la velocidad de extracción de imágenes, especialmente para los tipos de instancias con almacenamiento de instancias local que pueden aprovechar la descompresión de imágenes más rápida.
**Corrección de errores:** se resolvió una condición de carrera que provocaba el error FailedCreatePodSandBox. Al marcar tcp 127.0.0.1:50051: connect:, la conexión a veces fallaba para pods que se programaban en un nodo inmediatamente después del arranque.
## 4 de abril de 2025
**Característica:** aumento de `registryPullQPS` de 5 a 25 y de `registryBurst` de 10 a 50 para reducir la limitación de extracción de imágenes impuesta por el cliente (`Failed to pull image xyz: pull QPS exceeded`).
## 31 de marzo de 2025
**Corrección de error:** soluciona un problema por el que, si un pod de DNS principal se estaba ejecutando en un nodo de modo automático, las consultas de DNS de los pods del nodo llegaban a ese pod de DNS principal en lugar de llegar al servidor de DNS local del nodo. Las consultas de DNS de los pods de un nodo de modo automático siempre irán al DNS local del nodo.
## 21 de marzo de 2025
**Corrección de error:** los nodos del modo automático ahora resuelven `kube-dns.kube-system.svc.cluster.local` correctamente cuando no hay ningún servicio de `kube-dns` instalado en el clúster. Aborda el problema [\$12546](https://github.com/aws/containers-roadmap/issues/2546) de GitHub.
## 14 de marzo de 2025
**Característica**: la salida de `IPv4` está habilitada en los clústeres `IPv6`. El tráfico de `IPv4` que sale de los clústeres `IPv6` del modo automático ahora se traducirá automáticamente a la dirección `v4` de la ENI principal del nodo.