**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.
# Ciclo de vida y configuración del clúster de Amazon EKS
En esta sección, se proporciona una guía detallada sobre la administración del ciclo de vida completo de los clústeres de Kubernetes y las diferentes formas de configurarlos. Abarca la creación de clústeres, la supervisión de su estado, la actualización de las versiones de Kubernetes y la eliminación de clústeres. También se incluyen temas avanzados sobre cómo configurar el acceso a los puntos de conexión, activar o desactivar la compatibilidad con Windows, configurar clústeres privados, implementar el escalado automático y cómo mejorar la resiliencia con el cambio de zona para la redirección del tráfico en configuraciones multi-AZ.
**Topics**
+ [Cómo crear un clúster del modo automático de Amazon EKS](create-cluster-auto.md)
+ [Creación de un clúster de Amazon EKS](create-cluster.md)
+ [Plano de control aprovisionado de Amazon EKS](eks-provisioned-control-plane.md)
+ [Preparación para las actualizaciones de las versiones de Kubernetes y solución de problemas de configuración incorrecta con información sobre clústeres](cluster-insights.md)
+ [Actualización del clúster existente a la nueva versión de Kubernetes](update-cluster.md)
+ [Eliminar un clúster](delete-cluster.md)
+ [Punto de conexión del servidor de API del clúster](cluster-endpoint.md)
+ [Implementación de nodos de Windows en clústeres de EKS](windows-support.md)
+ [Deshabilitar la compatibilidad con Windows](disable-windows-support.md)
+ [Implementación de clústeres privados con acceso limitado a Internet](private-clusters.md)
+ [Escale la computación en clústeres con Karpenter y el Escalador automático de clústeres](autoscaling.md)
+ [Información sobre el cambio de zona del Controlador de recuperación de aplicaciones de Amazon (ARC) en Amazon EKS](zone-shift.md)
+ [Activación del cambio de zona de EKS para evitar zonas de disponibilidad deterioradas](zone-shift-enable.md)
# Cómo crear un clúster del modo automático de Amazon EKS
En este tema se ofrecen instrucciones detalladas para crear un clúster del modo automático de Amazon EKS mediante opciones de configuración avanzadas. Abarca los requisitos previos, las opciones de red y las configuraciones de complementos. El proceso incluye la configuración de roles de IAM, la configuración de los ajustes de los clústeres, la especificación de los parámetros de red y la selección de complementos. Los usuarios pueden crear clústeres a través de la Consola de administración de AWS o de la AWS CLI, con instrucciones paso a paso para ambos métodos.
Para los usuarios que busquen un proceso de configuración menos complejo, consulte los siguientes pasos simplificados para la creación de clústeres:
+ [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)
Esta guía de configuración avanzada está dirigida a usuarios que requieren un control más detallado sobre la configuración del clúster del modo automático de EKS y que están familiarizados con los conceptos y requisitos de Amazon EKS. Antes de continuar con la configuración avanzada, asegúrese de haber cumplido con todos los requisitos previos y de tener un conocimiento completo de los requisitos de red y IAM para los clústeres del modo automático de EKS.
El modo automático de EKS requiere permisos de IAM adicionales. Para obtener más información, consulte:
+ [Roles de IAM para clústeres de modo automático de EKS](automode-get-started-cli.md#auto-mode-create-roles)
+ [Más información sobre las identidades y el acceso en el modo automático de EKS](auto-learn-iam.md)
**nota**
Si desea crear un clúster sin el modo automático de EKS, consulte [Creación de un clúster de Amazon EKS](create-cluster.md).
En este tema se trata la configuración avanzada. Si desea comenzar a utilizar el modo automático de EKS, consulte [Cómo crear un clúster con el modo automático de Amazon EKS](create-auto.md).
## Requisitos previos
+ Una VPC y subredes existentes que cumplen con los [Requisitos de Amazon EKS](network-reqs.md). Antes de implementar un clúster para su uso en producción, le recomendamos que conozca a fondo los requisitos de VPC y subred. Si no tiene una VPC y subredes, puede crearlas mediante una [plantilla de AWS CloudFormation proporcionada por Amazon EKS](creating-a-vpc.md).
+ La herramienta de línea de comandos de `kubectl` está instalada en su dispositivo o AWS CloudShell. La versión puede ser la misma o hasta una versión secundaria anterior o posterior a la versión de Kubernetes de su clúster. Por ejemplo, si la versión del clúster es `1.29`, puede usar la versión `1.28`, `1.29` o `1.30` de `kubectl` con él. Para instalar o actualizar `kubectl`, consulte [Configuración de `kubectl` y `eksctl`](install-kubectl.md).
+ La versión `2.12.3` o posterior, o bien, la versión `1.27.160` o posterior de la AWS interfaz de la línea de comandos (AWS CLI) instalada y configurada en su dispositivo o AWS CloudShell. 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/cli-chap-install.html) y [Configuración rápida con aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) en la *Guía del usuario de la interfaz de la línea de comandos de AWS*.
+ Una [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) con permisos para crear y modificar los recursos de EKS e IAM.
## Crear un clúster: consola de AWS
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Elija **Agregar clúster** y, a continuación, elija **Crear**.
1. En *Opciones de configuración*, seleccione **Configuración personalizada**.
+ En este tema se trata la configuración personalizada. Para obtener información sobre la configuración rápida, consulte [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).
1. Confirme que la opción **Usar el modo automático de EKS** esté habilitada.
+ En este tema se trata la creación de clústeres con el modo automático de EKS. Para obtener más información sobre la creación de clústeres sin el modo automático de EKS, consulte [Creación de un clúster de Amazon EKS](create-cluster.md).
1. En la página **Configurar clúster** rellene los siguientes campos:
+ **Nombre**: un nombre único para el clúster. El nombre solo puede contener caracteres alfanuméricos (con distinción de mayúsculas y minúsculas) y guiones bajos. Debe comenzar con un carácter alfanumérico y no puede tener más de 100 caracteres. El nombre debe ser único dentro de la región de AWS y la cuenta de AWS en las que va a crear el clúster.
+ **Rol de IAM del clúster**: elija el rol de IAM del clúster de Amazon EKS que creó para permitir que el plano de control de Kubernetes administre los recursos de AWS en su nombre. Si no ha creado previamente un rol de IAM de clúster para el modo automático de EKS, seleccione el botón **Crear rol recomendado** para crear el rol con los permisos necesarios en la consola de IAM.
+ **Versión de Kubernetes**: la versión de Kubernetes que debe utilizarse para el clúster. Le recomendamos que seleccione la versión más reciente, a menos que necesite una versión anterior.
+ **Política de actualización**: la política de la versión de Kubernetes que desea establecer para el clúster. Si quiere que el clúster solo se ejecute en una versión de soporte estándar, puede elegir **Estándar**. Si quiere que el clúster entre en el soporte extendido al final del soporte estándar de una versión, puede elegir **Extendido**. Si selecciona una versión de Kubernetes que actualmente tenga soporte extendido, no podrá seleccionar el soporte estándar como opción.
1. En la sección **Computación en modo automático** de la página de configuración del clúster, introduzca los siguientes campos:
+ **Grupos de nodos**: determine si desea utilizar 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).
+ **Rol de IAM de nodo**: si habilita alguno de los grupos de nodos integrados, debe seleccionar un rol de IAM de nodo. El modo automático de EKS asignará este rol a los nuevos nodos. No podrá cambiar este valor después de crear el clúster. Si no ha creado previamente un rol IAM de nodo para el modo automático de EKS, seleccione el botón Crear rol recomendado para crear el rol con los permisos necesarios. Para obtener más información acerca de este rol, consulte [Más información sobre las identidades y el acceso en el modo automático de EKS](auto-learn-iam.md).
1. En la sección **Acceso al clúster** de la página de configuración del clúster, introduzca los siguientes campos:
+ **Acceso de administrador al clúster de arranque**: el creador del clúster se convierte automáticamente en un administrador de Kubernetes. Si desea desactivar esta opción, seleccione **Denegar acceso de administrador al clúster**.
+ **Modo de autenticación del clúster**: el modo automático de EKS requiere entradas de acceso de EKS, el modo de autenticación de la API de EKS. Si lo desea, puede habilitar el modo de autenticación `ConfigMap`. Para ello, seleccione **API de EKS y ConfigMap**.
1. Ingrese los campos restantes en la página de configuración del clúster:
+ **Cifrado de secretos**: (opcional) elija habilitar el cifrado de secretos de los secretos de Kubernetes con una clave de KMS. También puede habilitarlo después de crear el clúster. Antes de habilitar esta capacidad, asegúrese de estar familiarizado con la información de [Cifrado de los secretos de Kubernetes con KMS en los clústeres existentes](enable-kms.md).
+ **Cambio de zona de ARC**: el modo automático de EKS no admite el cambio de zona de ARC.
+ **Etiquetas**: (opcional) agregue las etiquetas a su clúster. Para obtener más información, consulte [Organización de los recursos de Amazon EKS con etiquetas](eks-using-tags.md).
Cuando haya terminado con esta página, seleccione **Siguiente**.
1. En la página **Especificar red** seleccione valores para los siguientes campos:
+ **VPC:** Elija una VPC existente que cumpla con los [Requisitos de Amazon EKS VPC](network-reqs.md#network-requirements-vpc) en el que crear el clúster. Antes de elegir una VPC, le recomendamos que se haya familiarizado con todos los requisitos y consideraciones de [Requisitos de red de Amazon EKS para VPC y subredes](network-reqs.md). No puede cambiar la VPC que desea utilizar después de crear un clúster. Si no hay ninguna VPC en la lista, debe crear una primero. Para obtener más información, consulte [Creación de una Amazon VPC para su clúster de Amazon EKS](creating-a-vpc.md).
+ **Subredes**: de forma predeterminada, se preseleccionan todas las subredes disponibles de la VPC especificada en el campo anterior. Debe seleccionar al menos dos.
Las subredes que elija deben cumplir los [Requisitos de subred de Amazon EKS](network-reqs.md#network-requirements-subnets). Antes de seleccionar subredes, recomendamos que esté familiarizado con todas las [Consideraciones y requisitos de subred y VPC de Amazon EKS](network-reqs.md).
**Grupos de seguridad**: (opcional) especifique uno o varios grupos de seguridad que desea que Amazon EKS asocie a las interfaces de red que crea.
Independientemente de que elija grupos de seguridad o no, Amazon EKS crea un grupo de seguridad que permite la comunicación entre el clúster y la VPC. Amazon EKS asocia este grupo de seguridad, y el que elija, a las interfaces de red que crea. Para obtener más información acerca del grupo de seguridad de clúster que crea Amazon EKS, consulte [Revisión de requisitos de grupos de seguridad de Amazon EKS para clústeres](sec-group-reqs.md). Puede modificar las reglas del grupo de seguridad en el clúster que crea Amazon EKS.
+ **Elija la familia de direcciones IP del clúster**: Puede elegir **IPv4** e **IPv6**.
Kubernetes asigna direcciones `IPv4` a sus pods y servicios de manera predeterminada. Antes de decidir utilizar la familia `IPv6`, asegúrese de estar familiarizado con todas las consideraciones y requisitos en los temas [Requisitos y consideraciones de la VPC](network-reqs.md#network-requirements-vpc), [Requisitos y consideraciones de la subred](network-reqs.md#network-requirements-subnets), [Revisión de requisitos de grupos de seguridad de Amazon EKS para clústeres](sec-group-reqs.md) y [Información sobre la asignación de direcciones IPv6 a clústeres, pods y servicios](cni-ipv6.md). Si elige la familia `IPv6`, no puede especificar un rango de direcciones para que Kubernetes asigne direcciones de servicio `IPv6` desde el mismo origen que para la familia `IPv4`. Kubernetes asigna direcciones de servicio del rango de direcciones local exclusivo (`fc00::/7`).
+ (Opcional) Elija **Configuración del rango de direcciones IP de Kubernetes Service** y especifique un **Rango de servicio `IPv4`**.
Especificar su propio intervalo puede ayudar a evitar conflictos entre servicios de Kubernetes y otras redes interconectadas o conectadas a la VPC. Escriba un rango en notación de CIDR. Por ejemplo: `10.2.0.0/16`.
El bloque de CIDR debe cumplir los siguientes requisitos:
+ Se encuentra dentro de una de las siguientes gamas: `10.0.0.0/8`, `172.16.0.0/12` o `192.168.0.0/16`.
+ Tiene un tamaño mínimo de `/24` y un tamaño máximo de `/12`.
+ No se superponen con el rango de la VPC de los recursos de Amazon EKS.
Solo se puede especificar esta opción cuando se utiliza la familia `IPv4` de direcciones y solo en la creación de clústeres. Si no especifica esto, Kubernetes asignará direcciones IP de servicio desde los bloques de CIDR `10.100.0.0/16` o `172.20.0.0/16`.
+ Para el **Acceso al punto de conexión del clúster**, seleccione una opción. Una vez que se crea el clúster, puede cambiar esta opción. Antes de seleccionar una opción no predeterminada, asegúrese de familiarizarse con las opciones y sus implicaciones. Para obtener más información, consulte [Punto de conexión del servidor de API del clúster](cluster-endpoint.md).
Cuando haya terminado con esta página, seleccione **Siguiente**.
1. (Opcional) En la página **Configurar la observabilidad**, seleccione qué opciones de **métricas** y **registro de planos de control** quiere activar. De forma predeterminada, cada tipo de registro está desactivado.
+ Para obtener más información sobre la opción de las métricas de Prometheus, consulte [Paso 1: activación de métricas de Prometheus](prometheus.md#turn-on-prometheus-metrics).
+ Para obtener más información sobre las opciones de **registro de plano de control**, consulte [Envío de los registros del plano de control a Registros de CloudWatch](control-plane-logs.md).
+ Cuando haya terminado con esta página, seleccione **Siguiente**.
1. En la página **Seleccionar complementos**, elija los complementos que desea agregar al clúster. Puede elegir tantos **complementos de Amazon EKS** y **complementos de Marketplace de AWS** como necesite. Si los **complementos de AWS Marketplace** que desea instalar no aparecen en la lista, puede hacer clic en la numeración de páginas para ver resultados de páginas adicionales o buscar complementos disponibles en **AWS Marketplace** al ingresar texto en el cuadro de búsqueda. También puede filtrar por **categoría**, **proveedor** o **modelo de precios** y, a continuación, elegir los complementos en los resultados de la búsqueda. Al crear un clúster, puede ver, seleccionar e instalar cualquier complemento compatible con EKS Pod Identities, como se detalla en [Más información sobre cómo Pod Identity de EKS concede a los pods acceso a los servicios de AWS](pod-identities.md).
+ El modo automático de EKS automatiza la funcionalidad de algunos complementos. Si tiene previsto implementar grupos de nodos administrados de EKS en el clúster del modo automático de EKS, seleccione **Complementos adicionales de Amazon EKS** y revise las opciones. Es posible que necesite instalar complementos, como CoreDNS y kube-proxy. EKS solo instalará los complementos de esta sección en nodos y grupos de nodos autoadministrados.
+ Cuando haya terminado con esta página, seleccione **Siguiente**.
1. En la página **Configurar las opciones de complementos seleccionados**, seleccione la versión que desee instalar. Siempre puede actualizar a una versión posterior después de crear el clúster.
En cuanto a los complementos compatibles con EKS Pod Identities, puede utilizar la consola para generar automáticamente el rol con el nombre, la política administrada por AWS y la política de confianza previamente insertados para cada complemento. Puede reutilizar roles existentes o crear nuevos roles para los complementos compatibles. Si desea conocer los pasos que hay que seguir en la consola para crear roles para complementos compatibles con EKS Pod Identities, consulte [Creación de complemento (consola de AWS)](creating-an-add-on.md#create_add_on_console). Si un complemento no es compatible con EKS Pod Identity, aparecerá un mensaje con instrucciones sobre cómo utilizar el asistente para crear los roles de IAM para cuentas de servicio (IRSA) después de crear el clúster.
Puede actualizar la configuración de cada complemento después de crear el clúster. Para obtener más información acerca de la configuración de complementos, consulte [Actualización de un complemento de Amazon EKS](updating-an-add-on.md). Cuando haya terminado con esta página, seleccione **Siguiente**.
1. En la página **Revisar y crear**, revise la información que introdujo o seleccionó en las páginas anteriores. Si necesita realizar cambios, seleccione **Edit** (Editar). Cuando esté satisfecho, seleccione **Crear**. El campo **Estado** muestra **CREANDO** mientras se aprovisiona el clúster.
**nota**
Es posible que reciba un error que indique que una de las zonas de disponibilidad de la solicitud no tiene la capacidad suficiente para crear un clúster de Amazon EKS. Si esto ocurre, el mensaje de error indicará las zonas de disponibilidad que admiten un clúster nuevo. Intente crear el clúster de nuevo con al menos dos subredes ubicadas en las zonas de disponibilidad admitidas para su cuenta. Para obtener más información, consulte [Capacidad insuficiente](troubleshooting.md#ice).
El aprovisionamiento de clústeres tarda varios minutos.
## Crear clúster: AWS CLI
Las siguientes instrucciones de la CLI cubren la creación de recursos de IAM y la creación del clúster.
### 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
```
### Creación de un clúster
1. Creación del clúster con el siguiente comando. Antes de ejecutar el comando, realice los siguientes reemplazos:
+ Reemplace *region-code* por la región de AWS en la que desea crear su clúster.
+ Reemplace *my-cluster* por el nombre de su clúster. El nombre solo puede contener caracteres alfanuméricos (con distinción de mayúsculas y minúsculas) y guiones bajos. Debe comenzar con un carácter alfanumérico y no puede tener más de 100 caracteres. El nombre debe ser único dentro de la región de AWS y la cuenta de AWS en las que va a crear el clúster.
+ Reemplace *1.30* por cualquier [versión compatible con Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
+ Reemplace *111122223333* por el ID de su cuenta.
+ Si ha creado roles de IAM con nombres diferentes para los roles de clúster y nodo, sustituya los ARN.
+ Reemplace los valores `subnetIds` con valores propios. También puede agregar identificadores adicionales. Debe especificar al menos dos ID de subredes.
Las subredes que elija deben cumplir los [Requisitos de subred de Amazon EKS](network-reqs.md#network-requirements-subnets). Antes de seleccionar subredes, recomendamos que esté familiarizado con todas las [Consideraciones y requisitos de subred y VPC de Amazon EKS](network-reqs.md).
+ Si no desea especificar un ID de grupo de seguridad, elimine `,securityGroupIds=sg-` del comando. Si desea especificar uno o varios ID de grupo de seguridad, sustituya los valores de `securityGroupIds` con la suya propia. También puede agregar identificadores adicionales.
Independientemente de que elija grupos de seguridad o no, Amazon EKS crea un grupo de seguridad que permite la comunicación entre el clúster y la VPC. Amazon EKS asocia este grupo de seguridad, y el que elija, a las interfaces de red que crea. Para obtener más información acerca del grupo de seguridad de clúster que crea Amazon EKS, consulte [Revisión de requisitos de grupos de seguridad de Amazon EKS para clústeres](sec-group-reqs.md). Puede modificar las reglas del grupo de seguridad en el clúster que crea Amazon EKS.
```
aws eks create-cluster \
--region region-code \
--name my-cluster \
--kubernetes-version 1.30 \
--role-arn arn:aws:iam::111122223333:role/AmazonEKSAutoClusterRole \
--resources-vpc-config '{"subnetIds": ["subnet-ExampleID1","subnet-ExampleID2"], "securityGroupIds": ["sg-ExampleID1"], "endpointPublicAccess": true, "endpointPrivateAccess": true}' \
--compute-config '{"enabled": true, "nodeRoleArn": "arn:aws:iam::111122223333:role/AmazonEKSAutoNodeRole", "nodePools": ["general-purpose", "system"]}' \
--kubernetes-network-config '{"elasticLoadBalancing": {"enabled": true}}' \
--storage-config '{"blockStorage": {"enabled": true}}' \
--access-config '{"authenticationMode": "API"}'
```
**nota**
Es posible que reciba un error que indique que una de las zonas de disponibilidad de la solicitud no tiene la capacidad suficiente para crear un clúster de Amazon EKS. Si esto ocurre, el mensaje de error indicará las zonas de disponibilidad que admiten un clúster nuevo. Intente crear el clúster de nuevo con al menos dos subredes ubicadas en las zonas de disponibilidad admitidas para su cuenta. Para obtener más información, consulte [Capacidad insuficiente](troubleshooting.md#ice).
A continuación se muestra una configuración opcional que, si es necesario, debe agregarse al comando anterior. Solo puede habilitar estas opciones al crear el clúster, no después.
+ Si quiere especificar desde qué bloque de enrutamiento entre dominios sin clase (CIDR) Kubernetes `IPv4` asigna direcciones IP de servicio, debe especificarlo agregando el `--kubernetes-network-config serviceIpv4Cidr=` al siguiente comando.
Especificar su propio intervalo puede ayudar a evitar conflictos entre servicios de Kubernetes y otras redes interconectadas o conectadas a la VPC. Escriba un rango en notación de CIDR. Por ejemplo: `10.2.0.0/16`.
El bloque de CIDR debe cumplir los siguientes requisitos:
+ Se encuentra dentro de una de las siguientes gamas: `10.0.0.0/8`, `172.16.0.0/12` o `192.168.0.0/16`.
+ Tiene un tamaño mínimo de `/24` y un tamaño máximo de `/12`.
+ No se superponen con el rango de la VPC de los recursos de Amazon EKS.
Solo se puede especificar esta opción cuando se utiliza la familia `IPv4` de direcciones y solo en la creación de clústeres. Si no especifica esto, Kubernetes asignará direcciones IP de servicio desde los bloques de CIDR `10.100.0.0/16` o `172.20.0.0/16`.
+ Si está creando un clúster y desea que el clúster asigne direcciones `IPv6` a pods y servicios en lugar de direcciones `IPv4`, agregue `--kubernetes-network-config ipFamily=ipv6` al siguiente comando.
Kubernetes asigna direcciones `IPv4` a sus pods y servicios de manera predeterminada. Antes de decidir utilizar la familia `IPv6`, asegúrese de estar familiarizado con todas las consideraciones y requisitos en los temas [Requisitos y consideraciones de la VPC](network-reqs.md#network-requirements-vpc), [Requisitos y consideraciones de la subred](network-reqs.md#network-requirements-subnets), [Revisión de requisitos de grupos de seguridad de Amazon EKS para clústeres](sec-group-reqs.md) y [Información sobre la asignación de direcciones IPv6 a clústeres, pods y servicios](cni-ipv6.md). Si elige la familia `IPv6`, no puede especificar un rango de direcciones para que Kubernetes asigne direcciones de servicio `IPv6` desde el mismo origen que para la familia `IPv4`. Kubernetes asigna direcciones de servicio del rango de direcciones local exclusivo (`fc00::/7`).
1. La provisión del clúster puede tardar varios minutos. Puede consultar el estado del clúster con el siguiente comando.
```
aws eks describe-cluster --region region-code --name my-cluster --query "cluster.status"
```
## Siguientes pasos
+ [Conexión de kubectl a un clúster de EKS mediante la creación de un archivo kubeconfig](create-kubeconfig.md)
+ [Concesión de acceso para los usuarios de IAM a las entradas de acceso de Kubernetes con EKS](access-entries.md)
+ [Habilitación del cifrado de secretos para su clúster](enable-kms.md).
+ [Configure el registro para el clúster](control-plane-logs.md).
+ [Agregue nodos al clúster](eks-compute.md).
# Creación de un clúster de Amazon EKS
**nota**
En este tema, se trata la creación de clústeres de Amazon EKS sin el modo automático de EKS.
Para obtener instrucciones detalladas sobre la creación de un clúster del modo automático de EKS, consulte [Cómo crear un clúster del modo automático de Amazon EKS](create-cluster-auto.md).
Para comenzar a utilizar el modo automático de EKS, consulte [Introducción a Amazon EKS: modo automático de EKS](getting-started-automode.md).
En este tema, se ofrece información general de las opciones disponibles y se describe qué debe tener en cuenta al crear un clúster de Amazon EKS. Si necesita crear un clúster con la infraestructura en las instalaciones como computación para los nodos, consulte [Cómo crear un clúster de Amazon EKS con nodos híbridos](hybrid-nodes-cluster-create.md). Si es la primera vez que crea un clúster de Amazon EKS, recomendamos que siga una de nuestras guías en [Introducción a Amazon EKS](getting-started.md). Estas guías le ayudan a crear un clúster simple y predeterminado sin expandirse a todas las opciones disponibles.
## Requisitos previos
+ Una VPC y subredes existentes que cumplen con los [Requisitos de Amazon EKS](network-reqs.md). Antes de implementar un clúster para su uso en producción, le recomendamos que conozca a fondo los requisitos de VPC y subred. Si no tiene una VPC y subredes, puede crearlas mediante una [plantilla de AWS CloudFormation proporcionada por Amazon EKS](creating-a-vpc.md).
+ La herramienta de línea de comandos de `kubectl` está instalada en su dispositivo o AWS CloudShell. La versión puede ser la misma o hasta una versión secundaria anterior o posterior a la versión de Kubernetes de su clúster. Para instalar o actualizar `kubectl`, consulte [Configuración de `kubectl` y `eksctl`](install-kubectl.md).
+ La versión `2.12.3` o posterior, o bien, la versión `1.27.160` o posterior de la AWS interfaz de la línea de comandos (AWS CLI) instalada y configurada en su dispositivo o AWS CloudShell. Para comprobar su versión actual, utilice `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Los administradores de paquetes, como `yum`, `apt-get` o Homebrew para macOS, suelen estar atrasados varias versiones respecto de la versión de la AWS CLI más reciente. Para instalar la versión más reciente, consulte [Instalación](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) y [Configuración rápida con aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) en la *Guía del usuario de la interfaz de la línea de comandos de AWS*. La versión de AWS CLI instalada en AWS CloudShell también puede estar atrasada varias versiones respecto de la versión más reciente. Para actualizarla, consulte [Instalación de la CLI de AWS en su directorio principal](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) en la *Guía del usuario de AWS CloudShell*.
+ Una [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) con permisos para `create` y `describe` un clúster de Amazon EKS. Para obtener más información, consulte [Creación de un clúster local de Kubernetes en un Outpost](security-iam-id-based-policy-examples.md#policy-create-local-cluster) y [Enumeración o descripción de todos los clústeres](security-iam-id-based-policy-examples.md#policy-example2).
## Paso 1: creación de un rol de IAM del clúster
1. Si ya tiene un rol de IAM del clúster o va a crear su clúster con `eksctl`, puede omitir este paso. Por defecto, `eksctl` crea un rol.
1. Ejecute el siguiente comando para crear un archivo de política de confianza JSON de IAM.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Creación del rol de IAM del clúster de Amazon EKS. Si es necesario, introduzca *eks-cluster-role-trust-policy.json* con la ruta del equipo en la que escribió el archivo en el paso anterior. El comando asocia la política de confianza creada en el paso anterior al rol. Para crear un rol de IAM, a la [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que está creando el rol se le debe asignar la acción `iam:CreateRole` (permiso).
```
aws iam create-role --role-name myAmazonEKSClusterRole --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
```
1. Puede asignar la política administrada de Amazon EKS o bien crear su propia política personalizada. Para conocer los permisos mínimos que debe utilizar en su política personalizada, consulte [Rol de IAM del clúster de Amazon EKS](cluster-iam-role.md).
Adjunte la política administrada de Amazon EKS llamada [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json) al rol. Para adjuntar una política de IAM a una [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal), se debe asignar una de las siguientes acciones de IAM (permisos) a la entidad principal que adjunta la política: `iam:AttachUserPolicy` o `iam:AttachRolePolicy`.
```
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy --role-name myAmazonEKSClusterRole
```
### Función vinculada a un servicio
Amazon EKS crea automáticamente un rol vinculado al servicio llamado `AWSServiceRoleForAmazonEKS`.
Esto es además del rol de IAM del clúster. Un rol vinculado a servicios es un tipo único de rol de IAM que se encuentra vinculado directamente a Amazon EKS. El rol permite a Amazon EKS administrar clústeres de la cuenta. Para obtener más información, consulte [Utilizar roles para clústeres de Amazon EKS](using-service-linked-roles-eks.md).
La identidad de IAM que utilice para crear el clúster de EKS debe tener permiso para crear el rol vinculado al servicio. Esto incluye el permiso `iam:CreateServiceLinkedRole`.
Si el rol vinculado al servicio aún no existe y el rol de IAM actual no tiene los permisos suficientes para crearlo, se producirá un error en la operación de creación del clúster.
## Paso 2: creación de un clúster
Puede crear un clúster mediante:
+ [`eksctl`](#step2-eksctl)
+ [la Consola de administración de AWS](#step2-console)
+ [La CLI de AWS](#step2-cli)
### Crear un clúster: eksctl
1. Necesita la versión `0.215.0` o posterior de la herramienta de la línea de comandos de `eksctl` instalada en su dispositivo o AWS CloudShell. Para instalar o actualizar `eksctl`, consulte la sección de [Instalación](https://eksctl.io/installation) en la documentación de `eksctl`.
1. Cree un clúster `IPv4` de Amazon EKS con la versión más reciente de Kubernetes de Amazon EKS en su región de AWS predeterminada. Antes de ejecutar el comando, realice los siguientes reemplazos:
1. Reemplace *region-code* por la región de AWS en la que desea crear su clúster.
1. Reemplace *my-cluster* por el nombre de su clúster. El nombre solo puede contener caracteres alfanuméricos (con distinción de mayúsculas y minúsculas) y guiones. Debe comenzar con un carácter alfanumérico y no puede tener más de 100 caracteres. El nombre debe ser único dentro de la región de AWS y la cuenta de AWS en las que va a crear el clúster.
1. Reemplace *1.35* por cualquier [versión compatible con Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
1. Cambie los valores de `vpc-private-subnets` para satisfacer sus necesidades. También puede agregar identificadores adicionales. Debe especificar al menos dos ID de subredes. Si prefiere especificar subredes públicas, puede cambiar `--vpc-private-subnets` a `--vpc-public-subnets`. Las subredes públicas tienen una tabla de enrutamiento asociada a una ruta a una puerta de enlace de Internet, pero las subredes privadas no tienen una tabla de enrutamiento asociada. Recomendamos utilizar subredes privadas siempre que sea posible.
Las subredes que elija deben cumplir los [Requisitos de subred de Amazon EKS](network-reqs.md#network-requirements-subnets). Antes de seleccionar subredes, recomendamos que esté familiarizado con todas las [Consideraciones y requisitos de subred y VPC de Amazon EKS](network-reqs.md).
1. Use el siguiente comando:
```
eksctl create cluster --name my-cluster --region region-code --version 1.35 --vpc-private-subnets subnet-ExampleID1,subnet-ExampleID2 --without-nodegroup
```
El aprovisionamiento de clústeres tarda varios minutos. Mientras se crea el clúster, aparecen varias líneas de salida. La última línea de salida es similar a la siguiente línea de ejemplo.
```
[✓] EKS cluster "my-cluster" in "region-code" region is ready
```
1. Continúe con [Paso 3: actualización de kubeconfig](#step3)
#### Optional Settings
Para ver la mayoría de las opciones que se pueden especificar al crear un clúster con `eksctl`, utilice el comando `eksctl create cluster --help`. Para ver todas las opciones disponibles, puede utilizar un archivo `config`. Para obtener más información, consulte [Uso de archivos de configuración](https://eksctl.io/usage/creating-and-managing-clusters/#using-config-files) y el [esquema de archivos de configuración](https://eksctl.io/usage/schema/) en la documentación de `eksctl`. Puede encontrar [ejemplos de archivos de configuración](https://github.com/weaveworks/eksctl/tree/master/examples) en GitHub.
A continuación se muestra una configuración opcional que, si es necesario, debe agregarse al comando anterior. Solo puede habilitar estas opciones al crear el clúster, no después. Si necesita especificar estas opciones, debe crear el clúster con un [archivo de configuración eksctl](https://eksctl.io/usage/creating-and-managing-clusters/#using-config-files) y especifique la configuración, en lugar de utilizar el comando anterior.
+ Si desea especificar uno o varios grupos de seguridad que Amazon EKS asigna a las interfaces de red que crea, especifique la opción [securityGroup](https://eksctl.io/usage/schema/#vpc-securityGroup).
Independientemente de que elija grupos de seguridad o no, Amazon EKS crea un grupo de seguridad que permite la comunicación entre el clúster y la VPC. Amazon EKS asocia este grupo de seguridad, y el que elija, a las interfaces de red que crea. Para obtener más información acerca del grupo de seguridad de clúster que crea Amazon EKS, consulte [Revisión de requisitos de grupos de seguridad de Amazon EKS para clústeres](sec-group-reqs.md). Puede modificar las reglas del grupo de seguridad en el clúster que crea Amazon EKS.
+ Si quiere especificar desde qué bloque de enrutamiento entre dominios sin clases (CIDR) `IPv4` de Kubernetes asigna direcciones IP de servicio, especifique la opción [serviceIPv4CIDR](https://eksctl.io/usage/schema/#kubernetesNetworkConfig-serviceIPv4CIDR).
Especificar su propio intervalo puede ayudar a evitar conflictos entre servicios de Kubernetes y otras redes interconectadas o conectadas a la VPC. Escriba un rango en notación de CIDR. Por ejemplo: `10.2.0.0/16`.
El bloque de CIDR debe cumplir los siguientes requisitos:
+ Se encuentra dentro de una de las siguientes gamas: `10.0.0.0/8`, `172.16.0.0/12` o `192.168.0.0/16`.
+ Tiene un tamaño mínimo de `/24` y un tamaño máximo de `/12`.
+ No se superponen con el rango de la VPC de los recursos de Amazon EKS.
Solo se puede especificar esta opción cuando se utiliza la familia `IPv4` de direcciones y solo en la creación de clústeres. Si no especifica esto, Kubernetes asignará direcciones IP de servicio desde los bloques de CIDR `10.100.0.0/16` o `172.20.0.0/16`.
+ Si va a crear un clúster y desea que el clúster asigne direcciones `IPv6` a pods y servicios en lugar de direcciones `IPv4`, especifique la opción [ipFamily](https://eksctl.io/usage/schema/#kubernetesNetworkConfig-ipFamily).
Kubernetes asigna direcciones `IPv4` a sus pods y servicios de manera predeterminada. Antes de decidir utilizar la familia `IPv6`, asegúrese de haberse familiarizado con todas las consideraciones y requisitos en los temas [Requisitos y consideraciones de la VPC](network-reqs.md#network-requirements-vpc), [Requisitos y consideraciones de la subred](network-reqs.md#network-requirements-subnets), [Revisión de requisitos de grupos de seguridad de Amazon EKS para clústeres](sec-group-reqs.md) y [Información sobre la asignación de direcciones IPv6 a clústeres, pods y servicios](cni-ipv6.md). Si elige la familia `IPv6`, no puede especificar un rango de direcciones para que Kubernetes asigne direcciones de servicio `IPv6` desde el mismo origen que para la familia `IPv4`. Kubernetes asigna direcciones de servicio del rango de direcciones local exclusivo (`fc00::/7`).
### Crear un clúster: consola de AWS
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Elija **Agregar clúster** y, a continuación, elija **Crear**.
1. En **Opciones de configuración**, seleccione **Configuración personalizada**.
+ Para obtener información sobre cómo crear rápidamente un clúster con el modo automático de EKS, consulte [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).
1. En **Modo automático de EKS**, desactive **Usar el modo automático de EKS**.
+ Para obtener más información acerca de cómo crear un clúster del modo automático de EKS con una configuración personalizada, consulte [Cómo crear un clúster del modo automático de Amazon EKS](create-cluster-auto.md).
1. En la página **Configurar clúster** rellene los siguientes campos:
+ **Nombre**: un nombre único para el clúster. El nombre solo puede contener caracteres alfanuméricos (con distinción de mayúsculas y minúsculas) y guiones bajos. Debe comenzar con un carácter alfanumérico y no puede tener más de 100 caracteres. El nombre debe ser único dentro de la región de AWS y la cuenta de AWS en las que va a crear el clúster.
+ **Rol de IAM del clúster**: elija el rol de IAM del clúster de Amazon EKS que creó para permitir que el plano de control de Kubernetes administre los recursos de AWS en su nombre.
+ **Versión de Kubernetes**: la versión de Kubernetes que debe utilizarse para el clúster. Le recomendamos que seleccione la versión más reciente, a menos que necesite una versión anterior.
+ **Tipo de soporte**: la política de la versión de Kubernetes que se establecerá para su clúster. Si quiere que su clúster solo se ejecute en una versión de soporte estándar, puede elegir **Soporte estándar**. Si quiere que su clúster entre en el soporte extendido al final del soporte estándar de una versión, puede elegir **Soporte extendido**. Si selecciona una versión de Kubernetes que actualmente tenga soporte extendido, no podrá seleccionar el soporte estándar como opción.
+ **Cifrado de secretos**: (opcional) elija habilitar el cifrado de secretos de los secretos de Kubernetes con una clave de KMS. También puede habilitarlo después de crear el clúster. Antes de habilitar esta capacidad, asegúrese de estar familiarizado con la información de [Cifrado de los secretos de Kubernetes con KMS en los clústeres existentes](enable-kms.md).
+ **Etiquetas**: (opcional) agregue las etiquetas a su clúster. Para obtener más información, consulte [Organización de los recursos de Amazon EKS con etiquetas](eks-using-tags.md).
+ **Cambio de zona de ARC**: (opcional) puede utilizar el controlador de recuperación de aplicaciones de Route53 para mitigar las zonas de disponibilidad afectadas. Para obtener más información, consulte [Información sobre el cambio de zona del Controlador de recuperación de aplicaciones de Amazon (ARC) en Amazon EKS](zone-shift.md).
1. En la sección **Acceso al clúster** de la página de configuración del clúster, introduzca los siguientes campos:
+ **Acceso de administrador al clúster de arranque**: el creador del clúster se convierte automáticamente en un administrador de Kubernetes. Si desea desactivar esta opción, seleccione **Denegar acceso de administrador al clúster**.
+ **Modo de autenticación de clústeres**: determine cómo quiere conceder a los usuarios y roles de IAM el acceso a las API de Kubernetes. Para obtener más información, consulte [Establecimiento de nodos de autenticación del clúster](grant-k8s-access.md#set-cam).
Cuando haya terminado con esta página, seleccione **Siguiente**.
1. En la página **Especificar red** seleccione valores para los siguientes campos:
+ **VPC:** Elija una VPC existente que cumpla con los [Requisitos de Amazon EKS VPC](network-reqs.md#network-requirements-vpc) en el que crear el clúster. Antes de elegir una VPC, le recomendamos que se haya familiarizado con todos los requisitos y consideraciones de [Requisitos de red de Amazon EKS para VPC y subredes](network-reqs.md). No puede cambiar la VPC que desea utilizar después de crear un clúster. Si no hay ninguna VPC en la lista, debe crear una primero. Para obtener más información, consulte [Creación de una Amazon VPC para su clúster de Amazon EKS](creating-a-vpc.md).
+ **Subredes**: de forma predeterminada, se preseleccionan todas las subredes disponibles de la VPC especificada en el campo anterior. Debe seleccionar al menos dos.
Las subredes que elija deben cumplir los [Requisitos de subred de Amazon EKS](network-reqs.md#network-requirements-subnets). Antes de seleccionar subredes, recomendamos que esté familiarizado con todas las [Consideraciones y requisitos de subred y VPC de Amazon EKS](network-reqs.md).
**Grupos de seguridad**: (opcional) especifique uno o varios grupos de seguridad que desea que Amazon EKS asocie a las interfaces de red que crea.
Independientemente de que elija grupos de seguridad o no, Amazon EKS crea un grupo de seguridad que permite la comunicación entre el clúster y la VPC. Amazon EKS asocia este grupo de seguridad, y el que elija, a las interfaces de red que crea. Para obtener más información acerca del grupo de seguridad de clúster que crea Amazon EKS, consulte [Revisión de requisitos de grupos de seguridad de Amazon EKS para clústeres](sec-group-reqs.md). Puede modificar las reglas del grupo de seguridad en el clúster que crea Amazon EKS.
+ **Elija la familia de direcciones IP del clúster**: Puede elegir **IPv4** e **IPv6**.
Kubernetes asigna direcciones `IPv4` a sus pods y servicios de manera predeterminada. Antes de decidir utilizar la familia `IPv6`, asegúrese de estar familiarizado con todas las consideraciones y requisitos en los temas [Requisitos y consideraciones de la VPC](network-reqs.md#network-requirements-vpc), [Requisitos y consideraciones de la subred](network-reqs.md#network-requirements-subnets), [Revisión de requisitos de grupos de seguridad de Amazon EKS para clústeres](sec-group-reqs.md) y [Información sobre la asignación de direcciones IPv6 a clústeres, pods y servicios](cni-ipv6.md). Si elige la familia `IPv6`, no puede especificar un rango de direcciones para que Kubernetes asigne direcciones de servicio `IPv6` desde el mismo origen que para la familia `IPv4`. Kubernetes asigna direcciones de servicio del rango de direcciones local exclusivo (`fc00::/7`).
+ (Opcional) Elija **Configuración del rango de direcciones IP de Kubernetes Service** y especifique un **Rango de servicio `IPv4`**.
Especificar su propio intervalo puede ayudar a evitar conflictos entre servicios de Kubernetes y otras redes interconectadas o conectadas a la VPC. Escriba un rango en notación de CIDR. Por ejemplo: `10.2.0.0/16`.
El bloque de CIDR debe cumplir los siguientes requisitos:
+ Se encuentra dentro de una de las siguientes gamas: `10.0.0.0/8`, `172.16.0.0/12` o `192.168.0.0/16`.
+ Tiene un tamaño mínimo de `/24` y un tamaño máximo de `/12`.
+ No se superponen con el rango de la VPC de los recursos de Amazon EKS.
Solo se puede especificar esta opción cuando se utiliza la familia `IPv4` de direcciones y solo en la creación de clústeres. Si no especifica esto, Kubernetes asignará direcciones IP de servicio desde los bloques de CIDR `10.100.0.0/16` o `172.20.0.0/16`.
+ Para el **Acceso al punto de conexión del clúster**, seleccione una opción. Una vez que se crea el clúster, puede cambiar esta opción. Antes de seleccionar una opción no predeterminada, asegúrese de familiarizarse con las opciones y sus implicaciones. Para obtener más información, consulte [Punto de conexión del servidor de API del clúster](cluster-endpoint.md).
Cuando haya terminado con esta página, seleccione **Siguiente**.
1. (Opcional) En la página **Configurar la observabilidad**, seleccione qué opciones de **métricas** y **registro de planos de control** quiere activar. De forma predeterminada, cada tipo de registro está desactivado.
+ Para obtener más información sobre la opción de las métricas de Prometheus, consulte [Paso 1: activación de métricas de Prometheus](prometheus.md#turn-on-prometheus-metrics).
+ Para obtener más información sobre las opciones de **registro de plano de control**, consulte [Envío de los registros del plano de control a Registros de CloudWatch](control-plane-logs.md).
Cuando haya terminado con esta página, seleccione **Siguiente**.
1. En la página **Seleccionar complementos**, elija los complementos que desea agregar al clúster. Algunos complementos están preseleccionados. Puede elegir tantos **complementos de Amazon EKS** y **complementos de Marketplace de AWS** como necesite. Si los **complementos de AWS Marketplace** que desea instalar no aparecen en la lista, puede hacer clic en la numeración de páginas para ver resultados de páginas adicionales o buscar complementos disponibles en **AWS Marketplace** al ingresar texto en el cuadro de búsqueda. También puede filtrar por **categoría**, **proveedor** o **modelo de precios** y, a continuación, elegir los complementos en los resultados de la búsqueda. Al crear un clúster, puede ver, seleccionar e instalar cualquier complemento compatible con EKS Pod Identities, como se detalla en [Más información sobre cómo Pod Identity de EKS concede a los pods acceso a los servicios de AWS](pod-identities.md).
Cuando haya terminado con esta página, seleccione **Siguiente**.
Algunos complementos, como la CNI de Amazon VPC, CoreDNS y kube-proxy, se instalan de forma predeterminada. Si desactiva alguno de los complementos predeterminados, esto puede afectar a su capacidad para ejecutar aplicaciones de Kubernetes.
1. En la página **Configurar las opciones de complementos seleccionados**, seleccione la versión que desee instalar. Siempre puede actualizar a una versión posterior después de crear el clúster.
En cuanto a los complementos compatibles con EKS Pod Identities, puede utilizar la consola para generar automáticamente el rol con el nombre, la política administrada por AWS y la política de confianza previamente insertados para cada complemento. Puede reutilizar roles existentes o crear nuevos roles para los complementos compatibles. Si desea conocer los pasos que hay que seguir en la consola para crear roles para complementos compatibles con EKS Pod Identities, consulte [Creación de complemento (consola de AWS)](creating-an-add-on.md#create_add_on_console). Si un complemento no es compatible con EKS Pod Identity, aparecerá un mensaje con instrucciones sobre cómo utilizar el asistente para crear los roles de IAM para cuentas de servicio (IRSA) después de crear el clúster.
Puede actualizar la configuración de cada complemento después de crear el clúster. Para obtener más información acerca de la configuración de complementos, consulte [Actualización de un complemento de Amazon EKS](updating-an-add-on.md). Cuando haya terminado con esta página, seleccione **Siguiente**.
1. En la página **Revisar y crear**, revise la información que introdujo o seleccionó en las páginas anteriores. Si necesita realizar cambios, seleccione **Edit** (Editar). Cuando esté satisfecho, seleccione **Crear**. El campo **Estado** muestra **CREANDO** mientras se aprovisiona el clúster.
**nota**
Es posible que reciba un error que indique que una de las zonas de disponibilidad de la solicitud no tiene la capacidad suficiente para crear un clúster de Amazon EKS. Si esto ocurre, el mensaje de error indicará las zonas de disponibilidad que admiten un clúster nuevo. Intente crear el clúster de nuevo con al menos dos subredes ubicadas en las zonas de disponibilidad admitidas para su cuenta. Para obtener más información, consulte [Capacidad insuficiente](troubleshooting.md#ice).
El aprovisionamiento de clústeres tarda varios minutos.
1. Continúe con [Paso 3: actualización de kubeconfig](#step3)
### Crear clúster: AWS CLI
1. Creación del clúster con el siguiente comando. Antes de ejecutar el comando, realice los siguientes reemplazos:
+ Reemplace *region-code* por la región de AWS en la que desea crear su clúster.
+ Reemplace *my-cluster* por el nombre de su clúster. El nombre solo puede contener caracteres alfanuméricos (con distinción de mayúsculas y minúsculas) y guiones bajos. Debe comenzar con un carácter alfanumérico y no puede tener más de 100 caracteres. El nombre debe ser único dentro de la región de AWS y la cuenta de AWS en las que va a crear el clúster.
+ Reemplace *1.35* por cualquier [versión compatible con Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
+ Reemplace *111122223333* por el ID de su cuenta y *myAmazonEKSClusterRole* por el nombre de su rol de IAM del clúster.
+ Reemplace los valores `subnetIds` con valores propios. También puede agregar identificadores adicionales. Debe especificar al menos dos ID de subredes.
Las subredes que elija deben cumplir los [Requisitos de subred de Amazon EKS](network-reqs.md#network-requirements-subnets). Antes de seleccionar subredes, recomendamos que esté familiarizado con todas las [Consideraciones y requisitos de subred y VPC de Amazon EKS](network-reqs.md).
+ Si no desea especificar un ID de grupo de seguridad, elimine `,securityGroupIds=sg-` del comando. Si desea especificar uno o varios ID de grupo de seguridad, sustituya los valores de `securityGroupIds` con la suya propia. También puede agregar identificadores adicionales.
Independientemente de que elija grupos de seguridad o no, Amazon EKS crea un grupo de seguridad que permite la comunicación entre el clúster y la VPC. Amazon EKS asocia este grupo de seguridad, y el que elija, a las interfaces de red que crea. Para obtener más información acerca del grupo de seguridad de clúster que crea Amazon EKS, consulte [Revisión de requisitos de grupos de seguridad de Amazon EKS para clústeres](sec-group-reqs.md). Puede modificar las reglas del grupo de seguridad en el clúster que crea Amazon EKS.
```
aws eks create-cluster --region region-code --name my-cluster --kubernetes-version 1.35 \
--role-arn arn:aws:iam::111122223333:role/myAmazonEKSClusterRole \
--resources-vpc-config subnetIds=subnet-ExampleID1,subnet-ExampleID2,securityGroupIds=sg-ExampleID1
```
**nota**
Es posible que reciba un error que indique que una de las zonas de disponibilidad de la solicitud no tiene la capacidad suficiente para crear un clúster de Amazon EKS. Si esto ocurre, el mensaje de error indicará las zonas de disponibilidad que admiten un clúster nuevo. Intente crear el clúster de nuevo con al menos dos subredes ubicadas en las zonas de disponibilidad admitidas para su cuenta. Para obtener más información, consulte [Capacidad insuficiente](troubleshooting.md#ice).
A continuación se muestra una configuración opcional que, si es necesario, debe agregarse al comando anterior. Solo puede habilitar estas opciones al crear el clúster, no después.
+ De forma predeterminada, EKS instala varios complementos de red durante la creación del clúster. Esto incluye la CNI de Amazon VPC, CoreDNS y kube-proxy.
Si desea desactivar la instalación de estos complementos de red predeterminados, utilice el siguiente parámetro. Esto se puede usar para CNI alternativos, como Cilium. Para obtener más información, consulte la [Referencia de la API de EKS](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateCluster.html).
`aws eks create-cluster --no-bootstrap-self-managed-addons …`
+ Si quiere especificar desde qué bloque de enrutamiento entre dominios sin clase (CIDR) Kubernetes `IPv4` asigna direcciones IP de servicio, debe especificarlo agregando el `--kubernetes-network-config serviceIpv4Cidr=` al siguiente comando.
Especificar su propio intervalo puede ayudar a evitar conflictos entre servicios de Kubernetes y otras redes interconectadas o conectadas a la VPC. Escriba un rango en notación de CIDR. Por ejemplo: `10.2.0.0/16`.
El bloque de CIDR debe cumplir los siguientes requisitos:
+ Se encuentra dentro de una de las siguientes gamas: `10.0.0.0/8`, `172.16.0.0/12` o `192.168.0.0/16`.
+ Tiene un tamaño mínimo de `/24` y un tamaño máximo de `/12`.
+ No se superponen con el rango de la VPC de los recursos de Amazon EKS.
Solo se puede especificar esta opción cuando se utiliza la familia `IPv4` de direcciones y solo en la creación de clústeres. Si no especifica esto, Kubernetes asignará direcciones IP de servicio desde los bloques de CIDR `10.100.0.0/16` o `172.20.0.0/16`.
+ Si está creando un clúster y desea que el clúster asigne direcciones `IPv6` a pods y servicios en lugar de direcciones `IPv4`, agregue `--kubernetes-network-config ipFamily=ipv6` al siguiente comando.
Kubernetes asigna direcciones `IPv4` a sus pods y servicios de manera predeterminada. Antes de decidir utilizar la familia `IPv6`, asegúrese de estar familiarizado con todas las consideraciones y requisitos en los temas [Requisitos y consideraciones de la VPC](network-reqs.md#network-requirements-vpc), [Requisitos y consideraciones de la subred](network-reqs.md#network-requirements-subnets), [Revisión de requisitos de grupos de seguridad de Amazon EKS para clústeres](sec-group-reqs.md) y [Información sobre la asignación de direcciones IPv6 a clústeres, pods y servicios](cni-ipv6.md). Si elige la familia `IPv6`, no puede especificar un rango de direcciones para que Kubernetes asigne direcciones de servicio `IPv6` desde el mismo origen que para la familia `IPv4`. Kubernetes asigna direcciones de servicio del rango de direcciones local exclusivo (`fc00::/7`).
1. La provisión del clúster puede tardar varios minutos. Puede consultar el estado del clúster con el siguiente comando.
```
aws eks describe-cluster --region region-code --name my-cluster --query "cluster.status"
```
No continúe con el siguiente paso hasta que la salida devuelta sea `ACTIVE`.
1. Continúe con [Paso 3: actualización de kubeconfig](#step3)
## Paso 3: actualización de kubeconfig
1. Si ha creado el clúster mediante `eksctl`, puede omitir este paso. Esto se debe a que `eksctl` ya ha completado este paso. Habilite `kubectl` para comunicarse con el clúster agregando un nuevo contexto al archivo `kubectl` `config`. Para obtener más información acerca de cómo crear y actualizar el archivo, consulte [Conexión de kubectl a un clúster de EKS mediante la creación de un archivo kubeconfig](create-kubeconfig.md).
```
aws eks update-kubeconfig --region region-code --name my-cluster
```
Un ejemplo de salida sería el siguiente.
```
Added new context arn:aws:eks:region-code:111122223333:cluster/my-cluster to /home/username/.kube/config
```
1. Confirme la comunicación con el clúster ejecutando el siguiente comando.
```
kubectl get svc
```
Un ejemplo de salida sería el siguiente.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.100.0.1 443/TCP 28h
```
## Paso 4: configuración del clúster
1. (Recomendado) Para utilizar algunos complementos de Amazon EKS o a fin de permitir que las cargas de trabajo individuales de Kubernetes cuenten con permisos de AWS Identity and Access Management (IAM) específicos, [cree un proveedor de OpenID Connect de IAM (OIDC)](enable-iam-roles-for-service-accounts.md) para el clúster. Solo necesita crear un proveedor de OIDC de IAM para su clúster una vez. Para obtener más información sobre los complementos de Amazon EKS, consulte [Complementos de Amazon EKS](eks-add-ons.md). Para obtener más información sobre la asignación de permisos de IAM específicos a sus cargas de trabajo, consulte [Roles de IAM para cuentas de servicio](iam-roles-for-service-accounts.md).
1. (Recomendado) Configure el clúster para el complemento CNI de Amazon VPC para Kubernetes antes de implementar nodos de Amazon EC2 en su clúster. De forma predeterminada, el complemento se instaló con el clúster. Cuando agrega nodos de Amazon EC2 a su clúster, el complemento se implementa automáticamente en cada nodo de Amazon EC2 que agregue. El complemento requiere que adjunte una de las siguientes políticas de IAM a un rol de IAM. Si el clúster usa la familia `IPv4`, utilice la política de IAM administrada [AmazonEKS\$1CNI\$1Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html). Si el clúster utiliza la familia `IPv6`, utilice una [política de IAM que cree](cni-iam-role.md#cni-iam-role-create-ipv6-policy).
El rol de IAM al que adjunta la política puede ser el rol de IAM de nodo o un rol dedicado que se usa solo para el complemento. Recomendamos adjuntar la política a este rol. Para obtener más información sobre la creación del rol, consulte [Configuración del complemento de CNI de Amazon VPC para utilizar IRSA](cni-iam-role.md) o [Rol de IAM de nodo de Amazon EKS](create-node-role.md).
1. Si ha implementado el clúster mediante el Consola de administración de AWS, puede omitir este paso. La Consola de administración de AWS implementa los complementos CNI de Amazon VPC para Kubernetes, CoreDNS y `kube-proxy` de Amazon EKS de forma predeterminada.
Si implementa el clúster mediante `eksctl` o la AWS CLI, se implementan los complementos CNI de Amazon VPC para Kubernetes, CoreDNS y `kube-proxy` autoadministrados. Puede migrar los complementos CNI de Amazon VPC para Kubernetes, CoreDNS y `kube-proxy` que se implementan con su clúster en complementos de Amazon EKS. Para obtener más información, consulte [Complementos de Amazon EKS](eks-add-ons.md).
1. (Opcional) Si aún no lo ha hecho, puede habilitar las métricas de Prometheus para su clúster. Para obtener más información, consulte [Crear un raspador](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-create) en la *Guía del usuario de Amazon Managed Service para Prometheus*.
1. Si tiene previsto implementar cargas de trabajo que utilicen volúmenes de Amazon EBS en su clúster, deberá instalar el [CSI de Amazon EBS](ebs-csi.md) en el clúster antes de implementar las cargas de trabajo.
## Siguientes pasos
+ La [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que creó el clúster es la única entidad principal de IAM que tiene acceso al clúster. [Conceda permisos a otras entidades principales de IAM](grant-k8s-access.md) para que puedan acceder al clúster.
+ Si la entidad principal de IAM que creó el clúster solo tiene los permisos de IAM mínimos a los que se hace referencia en los requisitos previos, es posible que desee agregar permisos de Amazon EKS adicionales para esa entidad principal. Para obtener más información sobre cómo conceder permisos de Amazon EKS a entidades principales de IAM, consulte [Administración de identidades y accesos para Amazon EKS](security-iam.md).
+ Si desea que la entidad principal de IAM que creó el clúster o cualquier otra entidad principal vea los recursos de Kubernetes en la consola de Amazon EKS, conceda los [Permisos necesarios](view-kubernetes-resources.md#view-kubernetes-resources-permissions) a las entidades.
+ Si desea que los nodos y las entidades principales de IAM accedan al clúster desde su VPC, habilite el punto de conexión privado para el clúster. El punto de conexión público está habilitado de forma predeterminada. Si lo desea, puede desactivar el punto de conexión público una vez que haya activado el punto de conexión privado. Para obtener más información, consulte [Punto de conexión del servidor de API del clúster](cluster-endpoint.md).
+ [Habilitación del cifrado de secretos para su clúster](enable-kms.md).
+ [Configure el registro para el clúster](control-plane-logs.md).
+ [Agregue nodos al clúster](eks-compute.md).
# Plano de control aprovisionado de Amazon EKS
## Descripción general
El plano de control aprovisionado de Amazon EKS es una característica que permite a los administradores de clústeres seleccionar entre un conjunto de niveles de escalado y designar el nivel que elijan para obtener un rendimiento muy alto y predecible desde el plano de control del clúster. Esto permite a los administradores de clústeres garantizar que el plano de control siempre esté aprovisionado con la capacidad especificada.
Amazon EKS ofrece dos modos de operación para el plano de control del clúster. De forma predeterminada, los clústeres de Amazon EKS utilizan el **modo estándar**, en el que el plano de control se escala y se reduce verticalmente en función de las exigencias de la carga de trabajo. El modo estándar asigna dinámicamente la capacidad suficiente del plano de control para satisfacer sus necesidades de carga de trabajo y es la solución recomendada para la mayoría de los casos de uso. Sin embargo, para las cargas de trabajo especializadas que no toleran ninguna variabilidad en el rendimiento debido al escalado del plano de control o aquellas que requieren una capacidad muy alta del plano de control, puede utilizar opcionalmente el **modo aprovisionado**. El modo aprovisionado le permite asignar previamente la capacidad del plano de control para que siempre esté lista para gestionar los exigentes requisitos de la carga de trabajo.
**nota**
El modo aprovisionado es un modo de operaciones del plano de control adicional junto con el modo estándar predeterminado. La introducción del modo aprovisionado no cambia el comportamiento del modo estándar.
Con el plano de control aprovisionado de EKS, los administradores de clústeres pueden aprovisionar previamente la capacidad deseada del plano de control con antelación, lo que proporciona un rendimiento alto y predecible desde el plano de control del clúster, que siempre está disponible. El plano de control aprovisionado de EKS también permite a los administradores de clústeres aprovisionar la misma capacidad de plano de control en todos los entornos, desde los sitios de pruebas a los de producción y recuperación ante desastres. Es importante para garantizar que el rendimiento del plano de control obtenido en todos los entornos sea coherente y predecible. Por último, el plano de control aprovisionado de EKS le permite acceder a niveles muy altos de rendimiento del plano de control, lo que le permite ejecutar cargas de trabajo de IA escalables de forma masiva, computación de alto rendimiento y cargas de trabajo de procesamiento de datos a gran escala en Kubernetes.
Todos los clústeres de Amazon EKS nuevos y existentes funcionan en modo estándar de forma predeterminada. Para los clústeres que requieren un rendimiento alto y predecible desde el plano de control, puede optar por utilizar la característica del plano de control aprovisionado de EKS. Se le facturará la tarifa por hora correspondiente al nivel de escalado del plano de control concreto, además de las tarifas por hora de EKS de soporte estándar o ampliado. Para obtener más información acerca de los precios, consulte [Precios de Amazon EKS](https://aws.amazon.com/eks/pricing/).
![\[Modos del plano de control de Amazon EKS\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/control-plane-modes.png)
## Casos de uso
El plano de control aprovisionado de EKS está diseñado para abordar situaciones específicas en las que un rendimiento alto y predecible del plano de control es fundamental para sus operaciones. Comprender estos casos de uso puede ayudarlo a determinar si el plano de control aprovisionado de EKS es la solución adecuada para sus cargas de trabajo.
**Cargas de trabajo críticas para el rendimiento**: para las cargas de trabajo que exigen una latencia mínima y un rendimiento máximo del plano de control de Kubernetes, el plano de control aprovisionado de EKS proporciona una capacidad que elimina la variabilidad del rendimiento al escalar el plano de control.
**Cargas de trabajo con escalabilidad masiva**: si ejecuta cargas de trabajo con alta escalabilidad, como inferencia y entrenamiento de IA, computación de alto rendimiento o procesamiento de datos a gran escala que requieren la ejecución de una gran cantidad de nodos en el clúster, el plano de control aprovisionado proporciona la capacidad de plano de control necesaria para soportar estas cargas de trabajo exigentes.
**Eventos anticipados de alta demanda**: cuando espere un aumento repentino de las solicitudes del plano de control debido a un evento próximo, como rebajas o promociones de comercio electrónico, lanzamientos de productos, temporadas de compras festivas o eventos deportivos o de entretenimiento importantes, el plano de control aprovisionado le permite escalar la capacidad del plano de control por adelantado. Este enfoque proactivo garantiza que el plano de control esté preparado para soportar el aumento de carga sin tener que esperar a que se escale automáticamente para responder a la demanda.
**Coherencia del entorno**: el plano de control aprovisionado le permite igualar la capacidad y el rendimiento del plano de control en los entornos de preparación y producción, lo que lo ayuda a identificar posibles problemas con antelación antes de la implementación en producción. Al mantener el mismo nivel del plano de control en todos los entornos, puede asegurarse de que los resultados de las pruebas reflejen con precisión el comportamiento de la producción, lo que reduce el riesgo de sorpresas relacionadas con el rendimiento durante la implementación.
**Recuperación ante desastres y continuidad empresarial**: para escenarios de recuperación ante desastres, el plano de control aprovisionado le permite aprovisionar entornos de conmutación por error con el mismo nivel de capacidad que el entorno principal. Esto garantiza una interrupción mínima y una recuperación rápida durante los eventos de conmutación por error, ya que el clúster de recuperación ante desastres tendrá características de rendimiento en el plano de control idénticas a las del clúster de producción desde el momento en que se active.
## Niveles de escalado del plano de control
El plano de control aprovisionado de EKS ofrece niveles de escalado con el mismo nombre que las tallas de camisetas (XL, 2XL, 4XL y 8XL). Cada nivel define su capacidad mediante tres atributos clave de Kubernetes que determinan las características de rendimiento del plano de control del clúster. Comprender estos atributos lo ayuda a seleccionar el nivel adecuado para sus requisitos de cargas de trabajo.
La **simultaneidad de solicitudes de API** mide la cantidad de solicitudes que el servidor de API del plano de control de Kubernetes puede procesar simultáneamente, lo cual es fundamental para las cargas de trabajo de alto rendimiento.
La **frecuencia de programación de los pods** indica la rapidez con la que el programador predeterminado de Kubernetes puede programar los pods en los nodos, que se mide en pods por segundo.
El **tamaño de la base de datos del clúster** indica el espacio de almacenamiento asignado a etcd, la base de datos que contiene el estado y los metadatos del clúster.
Al aprovisionar el plano de control del clúster en un nivel de escalado determinado mediante el plano de control aprovisionado, EKS garantiza que el plano de control del clúster mantenga los límites correspondientes a ese nivel. Los límites de los niveles de escalado del plano de control varían en función de la versión de Kubernetes, como se muestra en las siguientes tablas.
### EKS v1.28 y v1.29
| Nivel de escalado del plano de control aprovisionado | Simultaneidad de solicitudes de la API (plazas) | Frecuencia de programación de los pods (pods/seg) | Tamaño de la base de datos del clúster (GB) |
| --- | --- | --- | --- |
| XL | 1700 | 100 | 16 |
| 2XL | 3400 | 100 | 16 |
| 4XL | 6800 | 100 | 16 |
| 8XL | 13600 | 100 | 16 |
### EKS v1.30 y versiones posteriores
| Nivel de escalado del plano de control aprovisionado | Simultaneidad de solicitudes de la API (plazas) | Frecuencia de programación de los pods (pods/seg) | Tamaño de la base de datos del clúster (GB) |
| --- | --- | --- | --- |
| XL | 1700 | 167 | 16 |
| 2XL | 3400 | 283 | 16 |
| 4XL | 6800 | 400 | 16 |
| 8XL | 13600 | 400 | 16 |
### Supervisión del uso de los niveles de escalado del plano de control
Amazon EKS proporciona varias métricas para ayudarlo a supervisar el uso de los niveles del plano de control. Estas métricas se publican como [métricas de Amazon CloudWatch](cloudwatch.md) y se puede acceder a ellas a través de las consolas de CloudWatch y EKS. Además, estas métricas se pueden extraer del punto de conexión de Prometheus del clúster de EKS (consulte [esta página](prometheus.md)).
| | **Métrica de Prometheus** | **Métrica de CloudWatch** |
| --- | --- | --- |
| **Simultaneidad de solicitudes de la API** | apiserver\$1flowcontrol\$1current\$1executing\$1seats | apiserver\$1flowcontrol\$1current\$1executing\$1seats |
| **Frecuencia de programación de pod** | scheduler\$1schedule\$1attempts\$1total | scheduler\$1schedule\$1attempts\$1total, scheduler\$1schedule\$1attempts\$1SCHEDULED, scheduler\$1schedule\$1attempts\$1UNSCHEDULABLE |
| **Tamaño de la base de datos del clúster** | apiserver\$1storage\$1size\$1bytes | apiserver\$1storage\$1size\$1bytes |
Puede ver la utilización del plano de control en la consola de Amazon EKS. En la página de información general del clúster, seleccione **Supervisar clúster** para acceder al panel de observabilidad. Luego, seleccione la pestaña **Supervisión del plano de control** para ver la utilización del plano de control en la sección **Escalado del plano de control**.
![\[Supervisión del clúster de EKS\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/monitor-cluster.png)
![\[Supervisión del plano de control de EKS\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/control-plane-monitoring.png)
### Descripción de la capacidad de los niveles frente al rendimiento real
Cuando selecciona un nivel de escalado del plano de control aprovisionado, los atributos del nivel representan las configuraciones subyacentes que aplica Amazon EKS al plano de control. Sin embargo, el rendimiento real que logre depende de los patrones de carga de trabajo específicos, las configuraciones y el cumplimiento de las prácticas recomendadas de Kubernetes. Por ejemplo, si bien un nivel 4XL configura la prioridad y equidad de la API (APF) con 6800 solicitudes simultáneas, el rendimiento real de las solicitudes que se obtienen desde el plano de control depende del tipo de operaciones que se lleven a cabo. Por ejemplo, Kubernetes penaliza más las solicitudes de lista que las de obtención y, por lo tanto, la cantidad efectiva de solicitudes de lista procesadas simultáneamente por el plano de control es inferior al de las solicitudes de obtención (consulte [esta página](https://docs.aws.amazon.com/eks/latest/best-practices/scale-control-plane.html#_api_priority_and_fairness)). Del mismo modo, aunque el QPS del programador predeterminado se establece en 400 para un nivel 4XL, la tasa real de programación del pod depende de factores como la preparación de los nodos y su estado para la programación. Para lograr un rendimiento óptimo, asegúrese de que las aplicaciones sigan las prácticas recomendadas de Kubernetes (consulte [esta página](https://docs.aws.amazon.com/eks/latest/best-practices/scalability.html)) y de que estén configuradas correctamente según las características de la carga de trabajo.
## Consideraciones
+ **Capacidad del plano de control estándar**: el modo del plano de control estándar de EKS ofrece la mejor relación entre precio y rendimiento y es la opción recomendada para la gran mayoría de los casos de uso. Sin embargo, para las cargas de trabajo especializadas que no toleran ninguna variabilidad en el rendimiento debido al escalado del plano de control o aquellas que requieren una capacidad muy alta del plano de control, puede plantearse opcionalmente el modo aprovisionado.
+ **Suscripción obligatoria**: los clústeres existentes no se escalarán verticalmente de forma automática desde el plano de control estándar a un nivel del plano de control aprovisionado de EKS más [caro](https://aws.amazon.com/eks/pricing/). Debe suscribirse de forma explícita a uno de los nuevos niveles de escalado del plano de control aprovisionado de EKS.
+ **Restricción de salida**: el modo de plano de control estándar admite hasta 8 GB de tamaño de base de datos del clúster (etcd). Si el tamaño de la base de datos del clúster supera los 8 GB mientras utiliza el modo aprovisionado, no podrá volver al modo estándar hasta que reduzca el tamaño de la base de datos a menos de 8 GB. Por ejemplo, si utiliza 14 GB de almacenamiento de base de datos en el modo aprovisionado, debe reducir previamente el uso de la base de datos a menos de 8 GB antes de volver al modo estándar.
+ **Sin escalado automático de niveles**: el plano de control aprovisionado de EKS no escala automáticamente entre niveles. Una vez que selecciona un nivel de escalado, el plano de control del clúster permanece fijo en ese nivel, lo que garantiza un rendimiento coherente y predecible. Sin embargo, tiene la flexibilidad de implementar su propia solución de escalado automático mediante la supervisión de las métricas de uso de los niveles y el uso de las API del plano de control aprovisionado de EKS para reducir o escalar verticalmente cuando estas métricas superen los umbrales definidos, lo que le ofrece un control total sobre su estrategia de escalado y la optimización de costos.
+ **Visualización del nivel actual**: puede utilizar la consola de Amazon EKS, la Amazon Web Services CLI o la API para ver el nivel de escalado del plano de control actual. En la CLI, puede ejecutar el comando `describe-cluster`: `aws eks describe-cluster --name cluster-name`
+ **Tiempo de transición entre niveles**: puede utilizar la consola de Amazon EKS, las API de Amazon EKS o la CLI para salir de los niveles de escalado o moverse entre ellos. Amazon EKS ha introducido un nuevo tipo de actualización de clústeres denominado `ScalingTierConfigUpdate`, que puede inspeccionar para supervisar el progreso de la transición. Después de ejecutar un comando de cambio de nivel, puede enumerar las actualizaciones del clúster para ver una nueva actualización del tipo `ScalingTierConfigUpdate` con el estado `Updating`. El estado cambia a `Successful` al finalizar la actualización o a `Failed` si se produce un error. El campo de error de la actualización indica el motivo del error. No hay restricciones en cuanto a la frecuencia con la que puede cambiar de nivel. El cambio del nivel del plano de control tarda varios minutos en completarse. No hay tiempo de inactividad del servidor de API durante este proceso, ya que EKS abre nuevos servidores API antes de terminar los antiguos.
+ **Selección del nivel óptimo**: para determinar el nivel de escalado del plano de control aprovisionado óptimo para el clúster, puede llevar a cabo pruebas de carga mediante el aprovisionamiento del clúster en el nivel más alto (8XL). A continuación, lleve a cabo una prueba de carga para simular los picos de demanda en el plano de control del clúster. Observe las métricas de uso de los niveles del plano de control en los momentos de máxima carga y utilice estas observaciones como factor guía para seleccionar el nivel adecuado para el modo aprovisionado.
+ **Precios del plano de control aprovisionado**: se le facturará según la tarifa por hora correspondiente al nivel de escalado del plano de control aprovisionado en el que se encuentre el clúster. Esto se suma a los cargos por hora de soporte estándar o ampliado. Consulte la [página](https://aws.amazon.com/eks/pricing/) de precios de EKS para obtener información detallada.
+ **Nivel de escalado más grande**: si tiene previsto ejecutar el clúster en un nivel de escalado superior a 8XL, contacte con el equipo de cuentas de Amazon Web Services para obtener información adicional sobre los precios.
+ **Compatibilidad con la versión y la región de Kubernetes**: el plano de control aprovisionado de EKS se admite en todas las regiones comerciales de Amazon Web Services, GovCloud y China. El plano de control aprovisionado funciona en EKS v1.28 y versiones posteriores.
# Introducción al plano de control aprovisionado de Amazon EKS
En esta guía, se explican los pasos para configurar y usar el plano de control aprovisionado de EKS mediante la AWS CLI y la Consola de administración de AWS.
## Requisitos previos
Antes de comenzar, asegúrese de que dispone de lo siguiente:
+ ** AWS CLI**: una herramienta de línea de comandos para trabajar con servicios de AWS, incluido Amazon EKS. Para obtener más información, consulte [Instalación](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) en la *Guía del usuario de la Interfaz de la línea de comandos de AWS*. Después de instalar la AWS CLI, recomendamos que también la configure. Para obtener más información, consulte [Configuración rápida con aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) en la *Guía del usuario de la Interfaz de la línea de comandos de AWS*. Tenga en cuenta que necesita la v2 de la AWS CLI para utilizar la opción **update-kubeconfig** que se muestra en esta página.
+ **Permisos de IAM necesarios**: la entidad principal de seguridad de IAM que está utilizando debe contar con permisos para trabajar con los roles de IAM de Amazon EKS, los roles vinculados al servicio, AWS CloudFormation, una VPC y recursos relacionados. Para obtener más información, consulte [Acciones](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html) y [Uso de roles vinculados a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) en la *Guía del usuario de IAM*. Debe completar todos los pasos de esta guía como el mismo usuario. Ejecute el siguiente comando para comprobar el usuario actual:
```
aws sts get-caller-identity
```
**nota**
Le recomendamos que siga los pasos de este tema en un intérprete de comandos Bash. Si no está utilizando un intérprete de comandos Bash, algunos comandos de script, como los caracteres de continuación de línea y la forma en que se establecen y utilizan las variables, requieren ajustes para su intérprete de comandos. Además, las reglas de entrecomillado y escape de su intérprete de comandos pueden ser diferentes. Para obtener más información, consulte [Uso de entrecomillado de cadenas en la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-quoting-strings.html) en la *Guía del usuario de la Interfaz de la línea de comandos de AWS*.
## Plano de control aprovisionado de EKS: AWS CLI
### Creación de un clúster con el nivel de escalado del plano de control aprovisionado de EKS
```
aws eks create-cluster --name prod-cluster \
--role-arn arn:aws:iam::012345678910:role/eks-service-role-AWSServiceRoleForAmazonEKS-J7ONKE3BQ4PI \
--resources-vpc-config subnetIds=subnet-6782e71e,subnet-e7e761ac,securityGroupIds=sg-6979fe18 \
--control-plane-scaling-config tier=tier-xl
```
Respuesta:
```
{
"cluster": {
"name": "my-eks-cluster",
"arn": "arn:aws:eks:us-east-2:111122223333:cluster/my-eks-cluster",
"createdAt": "2024-03-14T11:31:44.348000-04:00",
"version": "1.26",
"endpoint": "https://JSA79429HJDASKJDJ8223829MNDNASW.yl4.us-east-2.eks.amazonaws.com",
"roleArn": "arn:aws:iam::111122223333:role/eksctl-my-eks-cluster-cluster-ServiceRole-zMF6CBakwwbW",
"resourcesVpcConfig": {
"subnetIds": [
"subnet-0fb75d2d8401716e7",
"subnet-02184492f67a3d0f9",
"subnet-04098063527aab776",
"subnet-0e2907431c9988b72",
"subnet-04ad87f71c6e5ab4d",
"subnet-09d912bb63ef21b9a"
],
"securityGroupIds": [
"sg-0c1327f6270afbb36"
],
"clusterSecurityGroupId": "sg-01c84d09d70f39a7f",
"vpcId": "vpc-0012b8e1cc0abb17d",
"endpointPublicAccess": true,
"endpointPrivateAccess": true,
"publicAccessCidrs": [
"22.19.18.2/32"
]
},
"controlPlaneScalingConfig": {
"tier": "tier-xl"
},
"kubernetesNetworkConfig": {
"serviceIpv4Cidr": "10.100.0.0/16",
"ipFamily": "ipv4"
},
"logging": {
"clusterLogging": [
{
"types": [
"api",
"audit",
"authenticator",
"controllerManager",
"scheduler"
],
"enabled": true
}
]
},
"identity": {
"oidc": {
"issuer": "https://oidc.eks.us-east-2.amazonaws.com/id/JSA79429HJDASKJDJ8223829MNDNASW"
}
},
"status": "CREATING",
"certificateAuthority": {
"data": "CA_DATA_STRING..."
},
"platformVersion": "eks.14",
"tags": {
"aws:cloudformation:stack-name": "eksctl-my-eks-cluster-cluster",
"alpha.eksctl.io/cluster-name": "my-eks-cluster",
"karpenter.sh/discovery": "my-eks-cluster",
"aws:cloudformation:stack-id": "arn:aws:cloudformation:us-east-2:111122223333:stack/eksctl-my-eks-cluster-cluster/e752ea00-e217-11ee-beae-0a9599c8c7ed",
"auto-delete": "no",
"eksctl.cluster.k8s.io/v1alpha1/cluster-name": "my-eks-cluster",
"EKS-Cluster-Name": "my-eks-cluster",
"alpha.eksctl.io/cluster-oidc-enabled": "true",
"aws:cloudformation:logical-id": "ControlPlane",
"alpha.eksctl.io/eksctl-version": "0.173.0-dev+a7ee89342.2024-03-01T03:40:57Z",
"Name": "eksctl-my-eks-cluster-cluster/ControlPlane"
},
"health": {
"issues": []
},
"accessConfig": {
"authenticationMode": "API_AND_CONFIG_MAP"
}
}
}
```
### Visualización del nivel de escalado del plano de control del clúster
```
aws eks describe-cluster --name prod-cluster
```
Respuesta:
```
{
"cluster": {
"name": "my-eks-cluster",
"arn": "arn:aws:eks:us-east-2:111122223333:cluster/my-eks-cluster",
"createdAt": "2024-03-14T11:31:44.348000-04:00",
"version": "1.26",
"endpoint": "https://JSA79429HJDASKJDJ8223829MNDNASW.yl4.us-east-2.eks.amazonaws.com",
"roleArn": "arn:aws:iam::111122223333:role/eksctl-my-eks-cluster-cluster-ServiceRole-zMF6CBakwwbW",
"resourcesVpcConfig": {
"subnetIds": [
"subnet-0fb75d2d8401716e7",
"subnet-02184492f67a3d0f9",
"subnet-04098063527aab776",
"subnet-0e2907431c9988b72",
"subnet-04ad87f71c6e5ab4d",
"subnet-09d912bb63ef21b9a"
],
"securityGroupIds": [
"sg-0c1327f6270afbb36"
],
"clusterSecurityGroupId": "sg-01c84d09d70f39a7f",
"vpcId": "vpc-0012b8e1cc0abb17d",
"endpointPublicAccess": true,
"endpointPrivateAccess": true,
"publicAccessCidrs": [
"22.19.18.2/32"
]
},
"controlPlaneScalingConfig": {
"tier": "tier-xl"
},
"kubernetesNetworkConfig": {
"serviceIpv4Cidr": "10.100.0.0/16",
"ipFamily": "ipv4"
},
"logging": {
"clusterLogging": [
{
"types": [
"api",
"audit",
"authenticator",
"controllerManager",
"scheduler"
],
"enabled": true
}
]
},
"identity": {
"oidc": {
"issuer": "https://oidc.eks.us-east-2.amazonaws.com/id/JSA79429HJDASKJDJ8223829MNDNASW"
}
},
"status": "ACTIVE",
"certificateAuthority": {
"data": "CA_DATA_STRING..."
},
"platformVersion": "eks.14",
"tags": {
"aws:cloudformation:stack-name": "eksctl-my-eks-cluster-cluster",
"alpha.eksctl.io/cluster-name": "my-eks-cluster",
"karpenter.sh/discovery": "my-eks-cluster",
"aws:cloudformation:stack-id": "arn:aws:cloudformation:us-east-2:111122223333:stack/eksctl-my-eks-cluster-cluster/e752ea00-e217-11ee-beae-0a9599c8c7ed",
"auto-delete": "no",
"eksctl.cluster.k8s.io/v1alpha1/cluster-name": "my-eks-cluster",
"EKS-Cluster-Name": "my-eks-cluster",
"alpha.eksctl.io/cluster-oidc-enabled": "true",
"aws:cloudformation:logical-id": "ControlPlane",
"alpha.eksctl.io/eksctl-version": "0.173.0-dev+a7ee89342.2024-03-01T03:40:57Z",
"Name": "eksctl-my-eks-cluster-cluster/ControlPlane"
},
"health": {
"issues": []
},
"accessConfig": {
"authenticationMode": "API_AND_CONFIG_MAP"
}
}
}
```
### Actualización del clúster para usar el plano de control aprovisionado de EKS
```
aws eks update-cluster-config --name prod-cluster \
--control-plane-scaling-config tier=tier-2xl
```
Respuesta:
```
{
"update": {
"id": "7551c64b-1d27-4b1e-9f8e-c45f056eb6fd",
"status": "InProgress",
"type": "ScalingTierConfigUpdate",
"params": [
{
"type": "UpdatedTier",
"value": "tier-2xl"
},
{
"type": "PreviousTier",
"value": "tier-xl"
}
],
"createdAt": 1565807210.37,
"errors": []
}
}
```
### Visualización de la actualización de escalado del plano de control
```
aws eks list-updates --name example
```
Respuesta:
```
{
"updateIds": [
"7551c64b-1d27-4b1e-9f8e-c45f056eb6fd1"
]
}
```
### Salida del plano de control aprovisionado al plano de control estándar
```
aws eks update-cluster-config --name prod-cluster \
--control-plane-scaling-config tier=standard
```
Respuesta:
```
{
"update": {
"id": "7551c64b-1d27-4b1e-9f8e-c45f056eb6fd",
"status": "InProgress",
"type": "ScalingTierConfigUpdate",
"params": [
{
"type": "UpdatedTier",
"value": "standard"
},
{
"type": "PreviousTier",
"value": "tier-2xl"
}
],
"createdAt": 1565807210.37,
"errors": []
}
}
```
## Plano de control aprovisionado de EKS: Consola de administración de AWS
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Elija **Create cluster**.
1. En *Opciones de configuración*, seleccione **Configuración personalizada**.
1. Desplácese hacia abajo hasta **Nivel de escalado del plano de control**. Seleccione **Usar un nivel de escalado** para activar el plano de control aprovisionado.
1. Seleccione el nivel de escalado del plano de control que desee aprovisionar para el clúster entre varias opciones de niveles de escalado, como XL, 2XL, 4XL y 8XL.
1. Seleccione otras opciones de configuración del clúster según sea necesario. En el último paso, seleccione **Crear clúster**. Tenga en cuenta que la creación del clúster puede tardar varios minutos en completarse.
# Preparación para las actualizaciones de las versiones de Kubernetes y solución de problemas de configuración incorrecta con información sobre clústeres
La información sobre clústeres de Amazon EKS permite detectar problemas y ofrece recomendaciones para resolverlos y ayudarlo a administrar el clúster. Todos los clústeres de Amazon EKS se someten a comprobaciones automáticas y periódicas con una lista de información seleccionada por Amazon EKS. Amazon EKS administra en su totalidad estas *comprobaciones de información* y ofrece recomendaciones sobre cómo abordar cualquier resultado.
## Tipos de información del clúster
+ **Información de configuración**: identifica errores de configuración en la configuración de los nodos híbridos de EKS que podrían afectar a la funcionalidad del clúster o las cargas de trabajo.
+ **Información de actualización**: identifica los problemas que podrían afectar a su capacidad de actualizar a nuevas versiones de Kubernetes.
## Consideraciones
+ **Frecuencia**: Amazon EKS actualiza la información de los clústeres cada 24 horas, pero también puede actualizarla manualmente para ver el estado más reciente. Por ejemplo, puede actualizar manualmente la información del clúster después de solucionar un problema para comprobar si el problema se ha resuelto.
+ **Permisos**: Amazon EKS crea automáticamente una entrada de acceso al clúster para su información en cada clúster de EKS. Esta entrada concede permiso a EKS para ver información sobre su clúster. Amazon EKS usa esta información para generar la información. Para obtener más información, consulte [AmazonEKSClusterInsightsPolicy](access-policy-permissions.md#access-policy-permissions-AmazonEKSClusterInsightsPolicy).
## Casos de uso
La información sobre clústeres de Amazon EKS proporciona comprobaciones automatizadas para ayudar a mantener el buen estado, la fiabilidad y la configuración óptima de los clústeres de Kubernetes. A continuación, se presentan los principales casos de uso para obtener información sobre los clústeres, incluida la preparación para la actualización y la resolución de problemas de configuración.
### Información de actualización
La información de actualización es un tipo específico de comprobación de información dentro de la información de los clústeres. Estas comprobaciones devuelven información relacionada con la preparación para la actualización de la versión de Kubernetes. Amazon EKS lleva a cabo comprobaciones de información de actualización en todos los clústeres de EKS.
**importante**
Amazon EKS ha revertido temporalmente una característica que obligaba a utilizar una marca `--force` para actualizar el clúster cuando se producían determinados problemas de conocimiento del clúster. Para obtener más información, consulte [Temporary rollback of enforcing upgrade insights on update cluster version](https://github.com/aws/containers-roadmap/issues/2570) en GitHub.
Para obtener más información sobre la actualización del clúster, consulte [Paso 3: actualización del plano de control del clúster](update-cluster.md#update-cluster-control-plane).
Antes de actualizar la versión de Kubernetes del clúster, puede usar la pestaña **Información sobre la actualización** en el panel de observabilidad de la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). Si su clúster ha identificado problemas, revíselos y aplique las correcciones adecuadas. Los problemas incluyen enlaces a Amazon EKS y documentación de Kubernetes. Después de solucionar el problema, actualice la información del clúster bajo demanda para obtener la información más reciente. Si se han resuelto todos los problemas, [actualice el clúster.](update-cluster.md)
Amazon EKS devuelve información relacionada con la preparación para la actualización de la versión de Kubernetes. La información sobre las actualizaciones identifica los posibles problemas que podrían afectar a las actualizaciones del clúster de Kubernetes. Esto minimiza el esfuerzo que los administradores dedican a preparar las actualizaciones y aumenta la fiabilidad de las aplicaciones en las versiones más recientes de Kubernetes. Amazon EKS analiza automáticamente los clústeres para compararlos con una lista de posibles problemas que podrían afectar a las actualizaciones de la versión de Kubernetes. Amazon EKS actualiza con frecuencia la lista de comprobaciones de información en función de las revisiones de los cambios hechos en cada lanzamiento de versión de Kubernetes.
La información sobre las actualizaciones de Amazon EKS acelera el proceso de prueba y verificación de las nuevas versiones. También permiten a los administradores de clústeres y a los desarrolladores de aplicaciones aprovechar las capacidades más recientes de Kubernetes, ya que destacan las inquietudes y ofrecen consejos para solucionarlas.
### Información de configuración
La información del clúster de EKS escanea automáticamente los clústeres de Amazon EKS con nodos híbridos para identificar problemas de configuración que afectan a la comunicación entre el plano de control y el webhook de Kubernetes, comandos de kubectl como exec y registros, etc. La información de configuración detecta problemas y ofrece recomendaciones para solucionarlos, lo que acelera el proceso de configuración de los nodos híbridos en pleno funcionamiento.
## Introducción
Para ver la lista de comprobaciones de información hechas y cualquier problema pertinente que Amazon EKS haya identificado, puede usar la operación Consola de administración de AWS, la CLI de AWS, los SDK de AWS y la API `ListInsights` de Amazon EKS. Para empezar, consulte [Consulta de la información del clúster](view-cluster-insights.md).
# Consulta de la información del clúster
Amazon EKS proporciona dos tipos de información: **información de configuración** e **información de actualización**. La **información de configuración** identifica errores de configuración en la configuración de los nodos híbridos de EKS que podrían afectar a la funcionalidad del clúster o las cargas de trabajo. La **información de actualización** identifica los problemas que podrían afectar a su capacidad de actualizar a nuevas versiones de Kubernetes.
Para ver la lista de comprobaciones de información hechas y cualquier problema pertinente que Amazon EKS haya identificado, puede llamar a la operación de búsqueda en la Consola de administración de AWS, la AWS CLI, los AWS SDK y la API `ListInsights` de Amazon EKS.
## Consulta de la información de configuración (consola)
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. En la lista de clústeres, elija el nombre del clúster de Amazon EKS del que desea ver la información.
1. Elija **Supervisar clúster**.
1. Elija la pestaña **Estado del clúster**.
1. En la tabla **Información de configuración**, verá las siguientes columnas:
+ **Nombre**: la comprobación realizada por Amazon EKS en relación con el clúster.
+ **Estado de la información**: una información con un estado de `Error` significa que hay un error de configuración que probablemente esté afectando a la funcionalidad del clúster. Una información con un estado de `Warning` significa que la configuración no coincide con el enfoque documentado, pero que la funcionalidad del clúster podría funcionar si la configuró intencionadamente. Una información con el estado de `Passing` significa que Amazon EKS no encontró ningún problema relacionado con esta comprobación de información en su clúster.
+ **Versión**: la versión aplicable.
+ **Hora de la última actualización**: la hora en que se actualizó por última vez el estado de la información para este clúster.
+ **Descripción**: información de la comprobación de información, que incluye la alerta y las acciones recomendadas para su corrección.
## Consulta de la información de actualización (consola)
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. En la lista de clústeres, elija el nombre del clúster de Amazon EKS del que desea ver la información.
1. Elija **Supervisar clúster**.
1. Seleccione la pestaña **Información sobre actualizaciones**.
1. Para ver los datos más recientes, pulse **Actualizar información** y espere a que finalice la operación de actualización.
1. En la tabla **Información sobre actualizaciones**, verá las siguientes columnas:
+ **Nombre**: la comprobación realizada por Amazon EKS en relación con el clúster.
+ **Estado de la información**: una información con un estado de “Error” normalmente significa que la versión de Kubernetes afectada es N\$11 de la versión actual del clúster, mientras que un estado de “Advertencia” significa que la información se aplica a una versión futura de Kubernetes N\$12 o posterior. Una información con el estado “Aprobado” significa que Amazon EKS no ha encontrado ningún problema relacionado con esta comprobación de información en su clúster. Un estado de información “Desconocido” significa que Amazon EKS no puede determinar si su clúster se ve afectado por esta comprobación de información.
+ **Versión**: la versión de Kubernetes que la información comprobó para detectar posibles problemas.
+ **Hora de la última actualización**: la hora en que se actualizó por última vez el estado de la información para este clúster.
+ **Hora de la última transición**: la hora en que se modificó por última vez el estado de esta información.
+ **Descripción**: información de la comprobación de información, que incluye la alerta y las acciones recomendadas para su corrección.
## Consulta de la información del clúster (AWS CLI)
1. Para ver los datos más recientes, actualice la información de un clúster especificado. Lleve a cabo las siguientes modificaciones en el comando según sea necesario y, a continuación, ejecute el comando modificado.
+ Reemplace *region-code* por el código de la región de AWS.
+ Reemplace *my-cluster* por el nombre de su clúster.
```
aws eks start-insights-refresh --region region-code --cluster-name my-cluster
```
1. Para hacer un seguimiento del estado de una actualización de información, ejecute el siguiente comando. Reemplace *my-cluster* por el nombre de su clúster.
```
aws eks describe-insights-refresh --cluster-name my-cluster
```
Un ejemplo de salida sería el siguiente.
```
{
"message": "Insights refresh is in progress",
"status": "IN_PROGRESS",
"startedAt": "2025-07-30T13:36:09-07:00"
}
```
1. Enumere la información de un clúster especificado. Lleve a cabo las siguientes modificaciones en el comando según sea necesario y, a continuación, ejecute el comando modificado.
+ Reemplace *region-code* por el código de la región de AWS.
+ Reemplace *my-cluster* por el nombre de su clúster.
```
aws eks list-insights --region region-code --cluster-name my-cluster
```
Un ejemplo de salida sería el siguiente.
```
{
"insights":
[
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"name": "Deprecated APIs removed in Kubernetes vX.XX",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557315.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes vX.XX. Upgrading your cluster before migrating to the updated APIs supported by vX.XX could cause application impact.",
"insightStatus":
{
"status": "PASSING",
"reason": "No deprecated API usage detected within the last 30 days.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"name": "Kubelet version skew",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557309.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for kubelet versions of worker nodes in the cluster to see if upgrade would cause non compliance with supported Kubernetes kubelet version skew policy.",
"insightStatus":
{
"status": "UNKNOWN",
"reason": "Unable to determine status of node kubelet versions.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"name": "Deprecated APIs removed in Kubernetes vX.XX",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557315.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes vX.XX. Upgrading your cluster before migrating to the updated APIs supported by vX.XX could cause application impact.",
"insightStatus":
{
"status": "PASSING",
"reason": "No deprecated API usage detected within the last 30 days.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"name": "Cluster health issues",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557314.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for any cluster health issues that prevent successful upgrade to the next Kubernetes version on EKS.",
"insightStatus":
{
"status": "PASSING",
"reason": "No cluster health issues detected.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"name": "EKS add-on version compatibility",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557314.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks version of installed EKS add-ons to ensure they are compatible with the next version of Kubernetes. ",
"insightStatus": { "status": "PASSING", "reason": "All installed EKS add-on versions are compatible with next Kubernetes version."},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEccccc",
"name": "kube-proxy version skew",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557314.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks version of kube-proxy in cluster to see if upgrade would cause non compliance with supported Kubernetes kube-proxy version skew policy.",
"insightStatus":
{
"status": "PASSING",
"reason": "kube-proxy versions match the cluster control plane version.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEddddd",
"name": "Deprecated APIs removed in Kubernetes vX.XX",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557315.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes vX.XX. Upgrading your cluster before migrating to the updated APIs supported by vX.XX could cause application impact.",
"insightStatus":
{
"status": "PASSING",
"reason": "No deprecated API usage detected within the last 30 days.",
},
},
],
"nextToken": null,
}
```
1. Para obtener información descriptiva, ejecuta el siguiente comando. Lleve a cabo las siguientes modificaciones en el comando según sea necesario y, a continuación, ejecute el comando modificado.
+ Reemplace *region-code* por el código de la región de AWS.
+ Sustituya *a1b2c3d4-5678-90ab-cdef-EXAMPLE22222* por un ID de información recuperado de la lista de información del clúster.
+ Reemplace *my-cluster* por el nombre de su clúster.
```
aws eks describe-insight --region region-code --id a1b2c3d4-5678-90ab-cdef-EXAMPLE22222 --cluster-name my-cluster
```
Un ejemplo de salida sería el siguiente.
```
{
"insight":
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"name": "Kubelet version skew",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "1.27",
"lastRefreshTime": 1734557309.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for kubelet versions of worker nodes in the cluster to see if upgrade would cause non compliance with supported Kubernetes kubelet version skew policy.",
"insightStatus":
{
"status": "UNKNOWN",
"reason": "Unable to determine status of node kubelet versions.",
},
"recommendation": "Upgrade your worker nodes to match the Kubernetes version of your cluster control plane.",
"additionalInfo":
{
"Kubelet version skew policy": "https://kubernetes.io/releases/version-skew-policy/#kubelet",
"Updating a managed node group": "https://docs.aws.amazon.com/eks/latest/userguide/update-managed-node-group.html",
},
"resources": [],
"categorySpecificSummary":
{ "deprecationDetails": [], "addonCompatibilityDetails": [] },
},
}
```
# Actualización del clúster existente a la nueva versión de Kubernetes
**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 de Amazon EKS.
Cuando hay una nueva versión de Kubernetes disponible en Amazon EKS, puede actualizar el clúster de Amazon EKS a la versión más reciente.
**importante**
Una vez que actualice un clúster, no podrá cambiarlo a una versión anterior. Antes de actualizar a una nueva versión de Kubernetes, le recomendamos que revise la información en [Descripción del ciclo de vida de las versiones de Kubernetes en EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) y los pasos de actualización de este tema.
Las nuevas versiones de Kubernetes suelen presentar cambios significativos. Por ende, recomendamos que pruebe el comportamiento de las aplicaciones en la nueva versión de Kubernetes antes de realizar la actualización en los clústeres de producción. Para ello, puede crear un flujo de trabajo de integración continua con el fin de probar el comportamiento de la aplicación antes de pasar a una nueva versión de Kubernetes.
El proceso de actualización consiste en que Amazon EKS lance nodos de servidor de API nuevos con la versión actualizada de Kubernetes para sustituir a los existentes. Amazon EKS lleva a cabo una infraestructura estándar y una comprobación de estado de la disponibilidad del tráfico de red en estos nodos nuevos para verificar que funcionan según lo esperado. Sin embargo, una vez que haya iniciado la actualización del clúster, no podrá pausarla ni detenerla. Si cualquiera de estas comprobaciones falla, Amazon EKS revierte la implementación de la infraestructura y su clúster se mantiene en la versión anterior de Kubernetes. Las aplicaciones en ejecución no se ven afectadas y su clúster nunca queda en un estado no determinista o irrecuperable. Si fuese necesario, Amazon EKS realiza copias de seguridad de forma habitual a todos los clústeres administrados y existe un mecanismo de recuperación de clústeres. Evaluamos y mejoramos de forma constante nuestros procesos de administración de la infraestructura de Kubernetes.
Para actualizar el clúster, Amazon EKS requiere hasta cinco direcciones IP disponibles de las subredes que se especificaron cuando creó el clúster. Amazon EKS crea nuevas interfaces de red elástica de clúster (interfaces de red) en cualquiera de las subredes especificadas. Las interfaces de red se pueden crear en subredes diferentes a las que están las interfaces de red existentes, así que asegúrese de que las reglas del grupo de seguridad permitan la [comunicación de clúster necesaria](sec-group-reqs.md) para cualquiera de las subredes que especificó al crear su clúster. Si alguna de las subredes especificadas al crear el clúster no existe, no tiene suficientes direcciones IP disponibles o no tiene reglas de grupo de seguridad que permitan la comunicación del clúster necesaria, la actualización puede tener errores.
Para garantizar que el punto de conexión del servidor de API de su clúster esté siempre accesible, Amazon EKS ofrece un plano de control de Kubernetes y lleva a cabo actualizaciones sucesivas de las instancias del servidor de API durante las operaciones de actualización. Para tener en cuenta los cambios en las direcciones IP de las instancias del servidor de API que admiten su punto de conexión del servidor de API de Kubernetes, debe asegurarse de que los clientes de su servidor de API gestionen las reconexiones de manera eficaz. Versiones recientes de `kubectl` y las [bibliotecas](https://kubernetes.io/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api) del cliente de Kubernetes que cuentan con soporte oficial llevan a cabo este proceso de reconexión de forma transparente.
**nota**
Para obtener más información sobre lo que implica una actualización de clúster, consulte [Best Practices for Cluster Upgrades](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html) en la Guía de prácticas recomendadas de EKS. Este recurso le ayuda a planificar una actualización y a comprender la estrategia de actualización de un clúster.
## Consideraciones para el modo automático de Amazon EKS
+ La capacidad de computación del modo automático de Amazon EKS controla la versión de Kubernetes de los nodos. Después de actualizar el plano de control, el modo automático de EKS comenzará a actualizar de forma incremental los nodos administrados. El modo automático de EKS respeta los presupuestos de interrupción de pods.
+ No es necesario actualizar manualmente las capacidades del modo automático de Amazon EKS, incluidas las capacidades de escalado automático de computación, almacenamiento en bloque y equilibrio de carga.
## Resumen
A continuación, se ofrece un resumen general del proceso de la actualización del clúster de Amazon EKS:
1. Asegúrese de que el clúster tenga un estado que se pueda actualizar. Esto incluye comprobar las API de Kubernetes que utilizan los recursos implementados en el clúster, a fin de garantizar que el clúster no presente ningún problema de estado. Debe utilizar la información sobre actualizaciones de Amazon EKS al evaluar si su clúster está preparado para la actualización.
1. Actualice el plano de control a la siguiente versión secundaria (por ejemplo, de la 1.34 a la 1.35).
1. Actualice los nodos del plano de datos para que coincidan con los del plano de control.
1. Actualice cualquier aplicación adicional que se ejecute en el clúster (por ejemplo, `cluster-autoscaler`).
1. Actualice los complementos proporcionados por Amazon EKS, como los que se incluyen de forma predeterminada:
+ [Versión recomendada de la CNI de Amazon VPC](managing-vpc-cni.md)
+ [Versión recomendada de CoreDNS](managing-coredns.md)
+ [`kube-proxy` Versión recomendada de](managing-kube-proxy.md)
1. Actualice todos los clientes que se comuniquen con el clúster (por ejemplo, `kubectl`).
## Paso 1: preparación para la actualización
Compare la versión de Kubernetes de su plano de control de clúster con la versión de Kubernetes de sus nodos.
+ Obtenga la versión de Kubernetes del plano de control de clúster.
```
kubectl version
```
+ Obtenga la versión de Kubernetes de sus nodos. Este comando devuelve todos los nodos autoadministrados y administrados de Amazon EC2, Fargate e híbridos. Cada pod de Fargate aparece como su propio nodo.
```
kubectl get nodes
```
Antes de actualizar un plano de control a una nueva versión de Kubernetes, asegúrese de que la versión secundaria de Kubernetes de ambos notos administrados y de Fargate en el clúster debe ser la misma que la de la versión actual del plano de control. Por ejemplo, si el plano de control se ejecuta con la versión `1.29` y uno de los nodos con la versión `1.28`, debe actualizar los nodos a la versión `1.29` antes de actualizar el plano de control a la 1.30. Además, recomendamos actualizar los nodos autoadministrados y los nodos híbridos a la misma versión que el plano de control antes de actualizar el plano de control. Para obtener más información, consulte [Actualización de un grupo de nodos administrados para un clúster](update-managed-node-group.md), [Actualización de los nodos autoadministrados para un clúster](update-workers.md) y [Actualización de nodos híbridos para el clúster](hybrid-nodes-upgrade.md). Si tiene nodos de Fargate con una versión secundaria inferior a la versión del plano de control, elimine primero el pod que representa el nodo. Luego, actualice su plano de control. Los pods restantes se actualizarán a la nueva versión después de volver a implementarlos.
## Paso 2: revisión de las consideraciones de actualización
La información proporcionada por el clúster de Amazon EKS analiza automáticamente los clústeres en función de una lista de posibles problemas que afectan a la actualización de la versión de Kubernetes, como el uso obsoleto de la API de Kubernetes. Amazon EKS actualiza periódicamente la lista de comprobaciones de información que se deben realizar en función de las evaluaciones de los cambios en el proyecto de Kubernetes. Amazon EKS también actualiza la lista de verificación de información a medida que se introducen cambios en el servicio Amazon EKS junto con las nuevas versiones. Para obtener más información, consulte [Preparación para las actualizaciones de las versiones de Kubernetes y solución de problemas de configuración incorrecta con información sobre clústeres](cluster-insights.md).
Consulte [Deprecated API Migration Guide](https://kubernetes.io/docs/reference/using-api/deprecation-guide/) en la documentación de Kubernetes.
### Revisión de la información sobre actualizaciones
Utilice la información sobre actualizaciones de Amazon EKS para identificar problemas. Para obtener más información, consulte [Consulta de la información de actualización (consola)](view-cluster-insights.md#view-upgrade-insights-console).
### Consideraciones detalladas
+ Puesto que Amazon EKS ejecuta un plano de control de alta disponibilidad, puede actualizar solo una versión secundaria a la vez. Para obtener más información acerca de este requisito, consulte [Política de compatibilidad de versiones y diferencia de versiones de Kubernetes](https://kubernetes.io/docs/setup/version-skew-policy/#kube-apiserver). Supongamos que la versión del clúster actual es la `1.28` y quiere actualizarla a la `1.30`. Primero debe actualizar su clúster de versión `1.28` a la versión `1.29` y, a continuación, actualizar su clúster de versión `1.29` a la versión `1.30`.
+ Revise la compatibilidad de versiones entre `kube-apiserver` de Kubernetes y el `kubelet` en sus nodos.
+ A partir de la versión de Kubernetes `1.28`, en `kubelet` puede haber hasta tres versiones secundarias anteriores a `kube-apiserver`. Consulte [Política de compatibilidad de escalado entre versiones de Kubernetes](https://kubernetes.io/releases/version-skew-policy/#kubelet).
+ Si el `kubelet` de sus nodos administrados y de Fargate corresponde a la versión de Kubernetes `1.25` o una más reciente, puede actualizar su clúster hasta tres versiones más avanzadas sin necesidad de actualizar la versión de `kubelet`. Por ejemplo, si `kubelet` está en la versión `1.25`, puede actualizar la versión del clúster de Amazon EKS de `1.25` a `1.26` a `1.27` y a `1.28`, mientras que `kubelet` permanezca en la versión `1.25`.
+ Como práctica recomendada antes de iniciar una actualización, asegúrese de que el `kubelet` de sus nodos esté en la misma versión de Kubernetes que la de su plano de control.
+ Si el clúster está configurado con una versión del complemento CNI de Amazon VPC para Kubernetes anterior a la `1.8.0`, le recomendamos actualizar el complemento a la versión más reciente antes de actualizar el clúster. Para actualizar el complemento, consulte [Asignación de direcciones IP a pods con CNI de Amazon VPC](managing-vpc-cni.md).
+ Puede hacer una copia de seguridad del clúster de Amazon EKS para poder restaurar el estado del clúster de Amazon EKS y el almacenamiento persistente en caso de que se produzcan errores durante el proceso de actualización. Consulte [Copia de seguridad de Clústeres de EKS con AWS Backup](integration-backup.md)
## Paso 3: actualización del plano de control del clúster
**importante**
Amazon EKS ha revertido temporalmente una característica que obligaba a utilizar una marca `--force` para actualizar el clúster cuando se producían determinados problemas de conocimiento del clúster. Para obtener más información, consulte [Temporary rollback of enforcing upgrade insights on update cluster version](https://github.com/aws/containers-roadmap/issues/2570) en GitHub.
Amazon EKS actualiza la información de un clúster 24 horas después de la “hora de la última actualización”. Puede comparar la hora en que se ha abordado un problema con la “hora de la última actualización” de la información del clúster.
Además, el estado de la información puede tardar hasta 30 días en actualizarse después de abordar el uso obsoleto de la API. La información sobre actualizaciones siempre busca el uso obsoleto de la API durante un periodo continuo de 30 días.
Puede enviar la solicitud para actualizar la versión de su plano de control de Amazon EKS mediante:
+ [eksctl](#step3-eksctl)
+ [La consola de AWS](#step3-console)
+ [la CLI de AWS](#step3-cli)
### Actualizar clúster: eksctl
En este procedimiento, se requiere la versión `0.215.0` o posterior de `eksctl`. Puede verificar la versión con el siguiente comando:
```
eksctl version
```
Para obtener instrucciones sobre cómo instalar y actualizar `eksctl`, consulte [Instalación](https://eksctl.io/installation) en la documentación de `eksctl`.
Actualice la versión de Kubernetes de su plano de control de Amazon EKS. Reemplace `` por el nombre del clúster. Reemplace `` por el número de versión compatible con Amazon EKS al que desea actualizar el clúster. Para ver una lista de los números de versión compatibles, consulte [Versiones compatibles con Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
```
eksctl upgrade cluster --name --version --approve
```
La actualización puede tardar varios minutos en completarse.
Continuar con [Paso 4: actualización de los componentes del clúster](#step4).
### Actualizar clúster: consola de AWS
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Seleccione **Actualizar ahora** para el clúster que desee actualizar.
1. Seleccione la versión a la que desea actualizar el clúster y elija **Actualizar**.
1. La actualización puede tardar varios minutos en completarse. Continuar con [Paso 4: actualización de los componentes del clúster](#step4).
### Actualizar clúster: AWS CLI
1. Compruebe que la CLI de AWS esté instalada y que haya iniciado sesión. Para obtener más información, consulte [Instalación o actualización de la versión más reciente de la CLI de AWS](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
1. Actualice el clúster de Amazon EKS con el siguiente comando de la AWS CLI. Reemplace `` y `` del clúster que desee actualizar. Reemplace `` por el número de versión compatible con Amazon EKS al que desea actualizar el clúster. Para ver una lista de los números de versión compatibles, consulte [Versiones compatibles con Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
```
aws eks update-cluster-version --name \
--kubernetes-version --region
```
Un ejemplo de salida sería el siguiente.
```
{
"update": {
"id": "",
"status": "InProgress",
"type": "VersionUpdate",
"params": [
{
"type": "Version",
"value": ""
},
{
"type": "PlatformVersion",
"value": "eks.1"
}
],
[...]
"errors": []
}
```
1. La actualización puede tardar varios minutos en completarse. Monitoree el estado de la actualización del clúster con el siguiente comando. Además de usar el mismo `` y ``, use el `` que devolvió el comando anterior.
```
aws eks describe-update --name \
--region --update-id
```
Cuando se muestra el estado `Successful`, la actualización se ha completado.
1. Continuar con [Paso 4: actualización de los componentes del clúster](#step4).
## Paso 4: actualización de los componentes del clúster
1. Una vez que se complete la actualización del clúster, actualice los nodos a la misma versión secundaria de Kubernetes de su clúster actualizado. Para obtener más información, consulte [Actualización de los nodos autoadministrados para un clúster](update-workers.md), [Actualización de un grupo de nodos administrados para un clúster](update-managed-node-group.md) y [Actualización de nodos híbridos para el clúster](hybrid-nodes-upgrade.md). Los pods nuevos que se lancen en Fargate tienen una versión de `kubelet` que coinciden con la versión del clúster. Los pods de Fargate existentes no cambian.
1. (Opcional) Si implementó el Cluster Autoscaler de Kubernetes en el clúster antes de actualizar este último, actualice dicho Cluster Autoscaler a la versión más reciente que coincida con la versión principal y secundaria de Kubernetes a las que actualizó.
1. Abra la página de [versiones](https://github.com/kubernetes/autoscaler/releases) del Escalador automático de clústeres en un navegador web y busque la versión más reciente del Escalador automático de clústeres que coincida con la versión principal y secundaria de Kubernetes de su clúster. Por ejemplo, si la versión de Kubernetes del clúster es `1.30`, busque la última versión del escalador automático del clúster que comience por `1.30`. Registre el número de versión semántica (`1.30.n`, por ejemplo) de esa versión para usarlo en el siguiente paso.
1. Establezca la etiqueta de la imagen del Escalador automático de clústeres en la versión que ha registrado en el paso anterior con el siguiente comando. Si es necesario, reemplace `X.XX.X` por su propio valor.
```
kubectl -n kube-system set image deployment.apps/cluster-autoscaler cluster-autoscaler=registry.k8s.io/autoscaling/cluster-autoscaler:vX.XX.X
```
1. (Solo para clústeres con nodos de GPU) Si el clúster tiene grupos de nodos compatibles con GPU (por ejemplo, `p3.2xlarge`), debe actualizar el DaemonSet del [complemento del dispositivo NVIDIA para Kubernetes](https://github.com/NVIDIA/k8s-device-plugin) de su clúster. Reemplace `` con la versión [Plugin de dispositivo NVidia/K8S](https://github.com/NVIDIA/k8s-device-plugin/releases) deseada antes de ejecutar el siguiente comando.
```
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin//deployments/static/nvidia-device-plugin.yml
```
1. Actualice los complementos CNI de Amazon VPC para Kubernetes, CoreDNS y `kube-proxy`. Recomendamos actualizar los complementos a las versiones mínimas que figuran en los [tokens de las cuentas de servicio](service-accounts.md#boundserviceaccounttoken-validated-add-on-versions).
+ Si está usando complementos de Amazon EKS, seleccione **Clústeres** en la consola de Amazon EKS y, a continuación, seleccione el nombre del clúster que actualizó en el panel de navegación izquierdo. Las notificaciones aparecen en la consola. Le informan que hay una versión nueva disponible para cada complemento que tenga una actualización disponible. Para actualizar un complemento, seleccione la pestaña **Complementos**. En uno de los cuadros de un complemento que tenga una actualización disponible, seleccione **Actualizar ahora**, seleccione una versión disponible y, a continuación, seleccione **Actualizar**.
+ Como alternativa, puede utilizar la AWS CLI o `eksctl` para actualizar los complementos. Para obtener más información, consulte [Actualización de un complemento de Amazon EKS](updating-an-add-on.md).
1. De ser necesario, actualice su versión de `kubectl`. Debe utilizar una versión de `kubectl` con una diferencia de versión de menos de un número que el plano del control del clúster de Amazon EKS.
## Actualización a una versión anterior de Kubernetes en un clúster de Amazon EKS
No puede actualizar a una versión anterior de Kubernetes en un clúster de Amazon EKS. En su lugar, cree un clúster nuevo en una versión anterior de Amazon EKS y migre las cargas de trabajo.
# Eliminar un clúster
Cuando termine de utilizar un clúster de Amazon EKS, debe eliminar los recursos asociados para no incurrir en costos innecesarios.
Puede eliminar un clúster mediante `eksctl`, Consola de administración de AWS o AWS CLI.
## Consideraciones
+ Si recibe un error porque se ha eliminado el creador del clúster, consulte [este artículo](https://aws.amazon.com/premiumsupport/knowledge-center/eks-api-server-unauthorized-error) para resolver el problema.
+ Los recursos de Amazon Managed Service para Prometheus están fuera del ciclo de vida del clúster y deben mantenerse por fuera del clúster. Al eliminar el clúster, asegúrese de eliminar, también, cualquier raspador para reducir los costos aplicables. Para más información, consulte [Búsqueda y eliminación de rapsadores](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-list-delete) en la *Guía de usuario de Amazon Managed Service para Prometheus*.
+ Para eliminar un clúster conectado, consulte . [Anulación del registro de un clúster de Kubernetes desde la consola de Amazon EKS](deregister-connected-cluster.md)
+ Antes de eliminar un clúster, asegúrese de que la protección contra eliminación esté desactivada para el clúster.
### Consideraciones para el modo automático de EKS
+ Se eliminarán todos los nodos de modo automático de EKS, incluidas las instancias administradas por EC2.
+ Se eliminarán todos los equilibradores de carga
Para obtener más información, consulte [Cómo desactivar el modo automático de EKS](auto-disable.md).
## Pasos de requisitos previos
A continuación, se indican los pasos que debe realizar antes de poder eliminar un clúster. Estos pasos se aplican independientemente del método que utilice para eliminar el clúster.
1. Enumere todos los servicios que se ejecutan en el clúster.
```
kubectl get svc --all-namespaces
```
1. Eliminación de los servicios que tengan asociado un valor `EXTERNAL-IP`. Estos servicios se presentan por medio de un balanceador de carga de Elastic Load Balancing y debe eliminarlos en Kubernetes para que el balanceador y los recursos asociados se lancen correctamente. Sustituya *service-name* por el nombre de cada servicio de la lista, tal y como se describe.
```
kubectl delete svc service-name
```
1. Elimine también cualquier recurso de entrada. Si no elimina los recursos de entrada, el equilibrador de carga de aplicación permanecerá incluso si elimina el clúster. Reemplace *ingress-name* por el nombre de los recursos de entrada.
```
kubectl get ingress --all-namespaces
```
```
kubectl delete ing ingress-name
```
## Eliminación del clúster (eksctl)
En este procedimiento, se requiere la versión `0.215.0` o posterior de `eksctl`. Puede verificar la versión con el siguiente comando:
```
eksctl version
```
Para obtener instrucciones sobre cómo instalar o actualizar `eksctl`, consulte [Instalación](https://eksctl.io/installation) en la documentación de `eksctl`.
1. Complete los pasos de [requisitos previos](#prerequisite-steps). Después de hacerlo, elimine el clúster y los nodos asociados con el siguiente comando; reemplace *prod* por el nombre del clúster.
```
eksctl delete cluster --name prod
```
Salida:
```
[ℹ] using region region-code
[ℹ] deleting EKS cluster "prod"
[ℹ] will delete stack "eksctl-prod-nodegroup-standard-nodes"
[ℹ] waiting for stack "eksctl-prod-nodegroup-standard-nodes" to get deleted
[ℹ] will delete stack "eksctl-prod-cluster"
[✔] the following EKS cluster resource(s) for "prod" will be deleted: cluster. If in doubt, check CloudFormation console
```
## Eliminar un clúster (Consola de AWS)
1. Complete los pasos de [requisitos previos](#prerequisite-steps). Después de hacerlo, elimine todos los grupos de nodos y perfiles de Fargate.
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. En el panel de navegación izquierdo, seleccione **Clústeres** de Amazon EKS y, a continuación, en la lista de clústeres con pestañas, seleccione el nombre del clúster que desea eliminar.
1. Elija la pestaña **Compute** (Informática) y elija un grupo de nodos para eliminar. Elija **Delete** (Eliminar), introduzca el nombre del grupo de nodos y, a continuación, elija **Delete** (Eliminar). Eliminación de todos los grupos de nodos del clúster.
**nota**
Los grupos de nodos enumerados solo son los [grupos de nodos administrados](managed-node-groups.md).
1. Seleccione un **Fargate Profile** (Perfil de Fargate) para eliminar, seleccione **Delete** (Eliminar), ingrese el nombre del perfil y, a continuación, seleccione **Delete** (Eliminar). Eliminación de todos los perfiles de Fargate en el clúster.
1. Elimine todas las [pilas de AWS CloudFormation de nodos autoadministrados](https://docs.aws.amazon.com/eks/latest/userguide/worker).
1. Abra la [Consola de AWS CloudFormation](https://console.aws.amazon.com/cloudformation/).
1. Seleccione la pila de nodos que desea eliminar y, luego, elija **Delete** (Eliminar).
1. En el cuadro de diálogo de confirmación **Delete stack** (Eliminar pila), elija **Delete stack** (Eliminar pila). Eliminación de todas las pilas de nodos autoadministradas del clúster.
1. Elimine el clúster.
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Seleccione el clúster que desea eliminar y elija **Delete** (Eliminar).
1. En la pantalla de confirmación de eliminación del clúster, elija **Delete (Eliminar)**.
1. (Opcional) Eliminación de la pila de la VPC de AWS CloudFormation.
1. Abra la [Consola de AWS CloudFormation](https://console.aws.amazon.com/cloudformation/).
1. Seleccione la pila de VPC que desea eliminar y, luego, elija **Delete** (Eliminar).
1. En el cuadro de diálogo de confirmación **Eliminar pila**, elija **Eliminar pila**.
## Eliminación de un clúster (AWS CLI)
1. Complete los pasos de [requisitos previos](#prerequisite-steps). Después de hacerlo, elimine todos los grupos de nodos y perfiles de Fargate.
1. Enumere los grupos de nodos del clúster con el siguiente comando.
```
aws eks list-nodegroups --cluster-name my-cluster
```
**nota**
Los grupos de nodos enumerados son solo los [grupos de nodos administrados](managed-node-groups.md).
1. Eliminación de cada grupo de nodos con el siguiente comando. Eliminación de todos los grupos de nodos del clúster.
```
aws eks delete-nodegroup --nodegroup-name my-nodegroup --cluster-name my-cluster
```
1. Enumere los perfiles de Fargate del clúster con el siguiente comando.
```
aws eks list-fargate-profiles --cluster-name my-cluster
```
1. Eliminación de cada perfil de Fargate con el siguiente comando. Eliminación de todos los perfiles de Fargate en el clúster.
```
aws eks delete-fargate-profile --fargate-profile-name my-fargate-profile --cluster-name my-cluster
```
1. Elimine todas las [pilas de AWS CloudFormation de nodos autoadministrados](https://docs.aws.amazon.com/eks/latest/userguide/worker).
1. Muestre las pilas de AWS CloudFormation disponibles con el siguiente comando. Busque el nombre de la plantilla de nodos en la salida resultante.
```
aws cloudformation list-stacks --query "StackSummaries[].StackName"
```
1. Eliminación de cada pila de nodos con el siguiente comando y reemplace *node-stack* por el nombre de su pila de nodos. Eliminación de todas las pilas de nodos autoadministradas del clúster.
```
aws cloudformation delete-stack --stack-name node-stack
```
1. Eliminación del clúster con el siguiente comando, sustituyendo *my-cluster* por el nombre de su clúster.
```
aws eks delete-cluster --name my-cluster
```
1. (Opcional) Eliminación de la pila de AWS CloudFormation de la VPC.
1. Muestre las pilas de AWS CloudFormation disponibles con el siguiente comando. Busque el nombre de la plantilla de VPC en la salida resultante.
```
aws cloudformation list-stacks --query "StackSummaries[].StackName"
```
1. Elimine la pila de VPC con el siguiente comando, sustituyendo *my-vpc-stack* por el nombre de la pila de VPC.
```
aws cloudformation delete-stack --stack-name my-vpc-stack
```
# Protección de los clústeres de EKS contra la eliminación accidental
La eliminación accidental de un clúster de EKS puede afectar las operaciones del clúster de Kubernetes.
Ahora puede proteger los clústeres de EKS contra la eliminación accidental. Si habilita la protección contra la eliminación en un clúster, primero debe deshabilitar la protección contra eliminación antes de eliminarlo.
El objetivo de la protección contra la eliminación es evitar accidentes. Debe restringir cuidadosamente quién está autorizado a eliminar clústeres.
Si intenta eliminar un clúster activo que tiene activada la protección contra la eliminación, recibirá un`InvalidRequestException`.
**importante**
Si habilita la protección contra la eliminación en un clúster, debe tener los permisos de IAM UpdateClusterConfig **y** DeleteCluster para eliminar primero la protección contra la eliminación y, finalmente, eliminar el clúster.
**nota**
Si el estado del clúster es de creación, error o eliminación, puede eliminarlo aunque la protección contra eliminaciones esté activada.
## Habilitación de la protección contra la eliminación para un clúster existente
Solo puede ejecutar esto en un clúster en estado activo.
```
aws eks update-cluster-config --name --region --deletion-protection
```
## Deshabilitación de la protección contra la eliminación para un clúster existente
```
aws eks update-cluster-config --name --region --no-deletion-protection
```
# Punto de conexión del servidor de API del clúster
Esto lo ayudará a habilitar el acceso privado al punto de conexión del servidor de API de Kubernetes de su clúster de Amazon EKS y a limitar, o a desactivar por completo, el acceso público desde Internet.
Cuando se crea un clúster nuevo, Amazon EKS crea un punto de conexión para el servidor de la API de Kubernetes administrado que utiliza a fin de comunicarse con su clúster (mediante herramientas de administración de Kubernetes como, por ejemplo, `kubectl`). De forma predeterminada, este punto de conexión del servidor de API es público en Internet y el acceso al servidor de API está protegido mediante una combinación de AWS Identity and Access Management (IAM) y el [Control de acceso basado en rol](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) nativo de Kubernetes. Este punto de conexión se conoce como *punto de conexión público del clúster*. También hay un *punto de conexión privado del clúster*. Para obtener más información sobre el punto de conexión privado del clúster, consulte la siguiente sección [Punto de conexión privado del clúster](#cluster-endpoint-private).
## formato de punto de conexión del clúster `IPv6`
EKS crea un punto de conexión único de doble pila con el siguiente formato para los nuevos clústeres `IPv6` que se creen después de octubre de 2024. Un *clúster IPv6* es un clúster en el que selecciona `IPv6` en la configuración de la familia IP (`ipFamily`) del clúster.
**Example**
Punto de conexión público o privado del clúster de EKS: `eks-cluster.region.api.aws`
Punto de conexión público o privado del clúster de EKS: `eks-cluster.region.api.aws`
Punto de conexión público o privado del clúster de EKS: `eks-cluster---region---api.amazonwebservices.com.rproxy.goskope.com.cn`
**nota**
El punto de conexión de clúster de doble pila se introdujo en octubre de 2024. Para obtener más información acerca de los clústeres `IPv6`, consulte [Información sobre la asignación de direcciones IPv6 a clústeres, pods y servicios](cni-ipv6.md). En su lugar, los clústeres creados antes de octubre de 2024 utilizan el siguiente formato de punto de conexión.
## Formato de punto de conexión del clúster `IPv4`
EKS crea un punto de conexión único en el siguiente formato para cada clúster en el que se selecciona `IPv4` en la configuración de familia IP (ipFamily) del clúster:
**Example**
Punto de conexión público o privado del clúster de EKS `eks-cluster.region.eks.amazonaws.com`
Punto de conexión público o privado del clúster de EKS `eks-cluster.region.eks.amazonaws.com`
Punto de conexión público o privado del clúster de EKS `eks-cluster---region.amazonwebservices.com.rproxy.goskope.com.cn`
**nota**
Antes de octubre de 2024, los clústeres `IPv6` también utilizaban este formato de punto de conexión. En el caso de estos clústeres, tanto en el punto de conexión público como en el privado, solo se resuelven direcciones `IPv4` a través de este punto de conexión.
## Punto de conexión privado del clúster
Puede habilitar el acceso privado al servidor de la API de Kubernetes para que toda la comunicación entre los nodos y el servidor de la API permanezcan dentro de su VPC. Puede limitar las direcciones IP que pueden acceder a su servidor de API desde Internet o desactivar por completo el acceso a Internet al servidor de API.
**nota**
Dado que este punto de conexión es para el servidor de la API de Kubernetes y no un punto de conexión de AWS PrivateLink tradicional que sirve para comunicarse con una API de AWS, no aparece como un punto de conexión en la consola de Amazon VPC.
Al habilitar el acceso privado al punto de conexión para el clúster, Amazon EKS crea una zona alojada privada de Route 53 en su nombre y la asocia a la VPC de su clúster. Esta zona alojada privada se administra mediante Amazon EKS y no aparece en los recursos de Route 53 de su cuenta. Para que la zona privada alojada dirija el tráfico adecuadamente a su servidor de API, su VPC debe tener `enableDnsHostnames` y `enableDnsSupport` establecidos en `true` y las opciones de DHCP establecidas para su VPC deben incluir `AmazonProvidedDNS` en su lista de servidores de nombres de dominios. A fin de obtener más información, consulte [Actualización de soporte de DNS para su VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating) en la *guía del usuario de Amazon VPC*.
Puede definir los requisitos de acceso al punto de conexión del servidor de la API al crear un nuevo clúster; puede actualizar el acceso al punto de conexión del servidor de la API para un clúster en cualquier momento.
## Modificar el acceso al punto de conexión del clúster
Utilice los procedimientos de esta sección para modificar el acceso al punto de conexión para un clúster existente. En la siguiente tabla se muestran las combinaciones de acceso al punto de conexión del servidor de la API y sus comportamientos asociados.
| Acceso público al punto de conexión | Acceso privado al punto de conexión | Comportamiento |
| --- | --- | --- |
| Habilitado | Deshabilitado | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/cluster-endpoint.html) |
| Habilitado | Habilitado | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/cluster-endpoint.html) |
| Deshabilitado | Habilitado | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/cluster-endpoint.html) |
**Controles de acceso de puntos de conexión**
Tenga en cuenta que cada uno de los siguientes métodos para controlar el acceso de puntos de conexión solo afecta al punto de conexión correspondiente.
*Grupo de seguridad de clúster*
El grupo de seguridad del clúster controla dos tipos de conexiones: las conexiones a la *API de kubelet* y al punto de conexión privado. Las conexiones a la API `kubelet` se utilizan en los comandos `kubectl attach`, `kubectl cp`, `kubectl exec`, `kubectl logs` y `kubectl port-forward`. El grupo de seguridad del clúster no afecta al punto de conexión público.
*Acceso público: CIDR*
Los *CIDR de acceso público* controlan el acceso al punto de conexión público mediante una lista de bloques de CIDR. Tenga en cuenta que los CIDR de acceso público no afectan al punto de conexión privado. Los CIDR de acceso público se comportan de forma diferente en los clústeres `IPv6` e `IPv4` en función de la fecha en que se crearon, como se describe a continuación:
**Bloques de CIDR en el punto de conexión público (clúster `IPv6`)**
Puede agregar bloques de CIDR `IPv6` y `IPv4` al punto de conexión público de un clúster `IPv6`, ya que el punto de conexión público es de doble pila. Esto solo se aplica a los clústeres nuevos con `ipFamily` configurado como `IPv6` que creó en octubre de 2024 o después. Puede identificar estos clústeres por el nuevo nombre de dominio del punto de conexión `api.aws`.
**Bloques de CIDR en el punto de conexión público (clúster `IPv4`)**
Puede agregar bloques de CIDR `IPv4` al punto de conexión público de un clúster `IPv4`. No puede agregar bloques de CIDR `IPv6` al punto de conexión público de un clúster `IPv4`. Si lo intenta, EKS devuelve el siguiente mensaje de error: `The following CIDRs are invalid in publicAccessCidrs`
**Bloques de CIDR en el punto de conexión público (clúster `IPv6` creado antes de octubre de 2024)**
Puede agregar bloques de CIDR `IPv4` al punto de conexión público de los clústeres `IPv6` antiguos que creó antes de octubre de 2024. Puede identificar estos clústeres por el punto de conexión `eks.amazonaws.com`. No puede agregar bloques de CIDR `IPv6` al punto de conexión público de los clústeres `IPv6` antiguos que creó antes de octubre de 2024. Si lo intenta, EKS devuelve el siguiente mensaje de error: `The following CIDRs are invalid in publicAccessCidrs`
## Acceso a un servidor de API solo privado
Si ha deshabilitado el acceso público al punto de conexión del servidor de API de Kubernetes del clúster, solo puede obtener acceso al servidor de API desde dentro de la VPC o desde una [red conectada](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html). Hay varias formas de obtener acceso al punto de conexión del servidor de API de Kubernetes:
**Red conectada**
Conecte su red a la VPC con una [puerta de enlace de tránsito de AWS](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) u otra opción de [conectividad](https://docs.aws.amazon.com/aws-technical-content/latest/aws-vpc-connectivity-options/introduction.html) y, a continuación, utilice un equipo en la red conectada. Debe asegurarse de que el grupo de seguridad del plano de control de Amazon EKS tiene reglas para permitir el tráfico de entrada en el puerto 443 desde la red conectada.
**Host bastión de Amazon EC2**
Puede lanzar una instancia de Amazon EC2 en una subred pública de la VPC del clúster y, a continuación, iniciar sesión mediante SSH en esa instancia para ejecutar comandos de `kubectl`. Para obtener más información, consulte [Hosts bastión de Linux en AWS](https://aws.amazon.com/quickstart/architecture/linux-bastion/). Debe asegurarse de que el grupo de seguridad del plano de control de Amazon EKS tiene reglas para permitir el tráfico de entrada en el puerto 443 desde su host bastión. Para obtener más información, consulte [Revisión de requisitos de grupos de seguridad de Amazon EKS para clústeres](sec-group-reqs.md).
Cuando configure `kubectl` para el host bastión, asegúrese de utilizar las credenciales de AWS que ya están asignadas a su configuración de RBAC del clúster o agregue la [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que utilizará el bastión a la configuración de RBAC antes de eliminar el acceso público al punto de conexión. Para obtener más información, consulte [Concesión a los usuarios y roles de IAM de acceso a las API de Kubernetes](grant-k8s-access.md) y [Acceso denegado o no autorizado (`kubectl`)](troubleshooting.md#unauthorized).
**IDE de AWS Cloud9**
AWS Cloud9 es un entorno de desarrollo integrado (IDE) basado en la nube que permite escribir, ejecutar y depurar su código con solo un navegador. Puede crear un IDE de AWS Cloud9 en la VPC de su clúster y utilizar el IDE para comunicarse con el clúster. Para obtener más información, consulte [Creación de un entorno en AWS Cloud9](https://docs.aws.amazon.com/cloud9/latest/user-guide/create-environment.html). Debe asegurarse de que el grupo de seguridad del plano de control de Amazon EKS tiene reglas para permitir el tráfico de entrada en el puerto 443 desde el grupo de seguridad de IDE. Para obtener más información, consulte [Revisión de requisitos de grupos de seguridad de Amazon EKS para clústeres](sec-group-reqs.md).
Cuando configure `kubectl` para el IDE de AWS Cloud9, asegúrese de utilizar las credenciales de AWS que ya están asignadas a su configuración de RBAC del clúster o agregue la entidad principal de IAM que utilizará el IDE a la configuración de RBAC antes de eliminar el acceso público al punto de conexión. Para obtener más información, consulte [Concesión a los usuarios y roles de IAM de acceso a las API de Kubernetes](grant-k8s-access.md) y [Acceso denegado o no autorizado (`kubectl`)](troubleshooting.md#unauthorized).
📝 [Edite esta página en GitHub](https://github.com/search?q=repo%3Aawsdocs%2Famazon-eks-user-guide+%5B%23cluster-endpoint%5D&type=code)
# Configuración de acceso de la red al punto de conexión del servidor de API del clúster
Puede modificar el acceso al punto de conexión del servidor de la API del clúster mediante la Consola de administración de AWS o la AWS CLI en las secciones siguientes.
## Configuración del acceso al punto de conexión: consola de AWS
1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Elija el nombre del clúster para mostrar la información del clúster.
1. Elija la pestaña **Redes** y, a continuación, elija **Administrar el acceso a los puntos de conexión**.
1. Para el **acceso privado**, decida si desea habilitar o deshabilitar el acceso privado al punto de conexión del servidor de API de Kubernetes del clúster. Si habilita el acceso privado, las solicitudes de la API de Kubernetes que provengan desde dentro de la VPC del clúster utilizan el punto de conexión de VPC privada. Debe habilitar el acceso privado para deshabilitar el acceso público.
1. Para el **acceso público**, decida si desea habilitar o deshabilitar el acceso público al punto de conexión del servidor de API de Kubernetes del clúster. Si deshabilita el acceso público, el servidor de la API de Kubernetes del clúster solo puede recibir solicitudes que provengan desde dentro de la VPC del clúster.
1. (Opcional) Si ha habilitado el **acceso público**, puede especificar qué direcciones de Internet pueden comunicarse con el punto de conexión público. Seleccione **Advanced Settings (Configuración avanzada)**. Introduzca un bloque de CIDR, como *203.0.113.5/32*. El bloque no puede incluir [direcciones reservadas](https://en.wikipedia.org/wiki/Reserved_IP_addresses). Puede introducir bloques adicionales seleccionando **Add Source (Agregar origen)**. Hay un número máximo de bloques de CIDR que puede especificar. Para obtener más información, consulte [Visualización y administración de Amazon EKS y las Service Quotas de Fargate](service-quotas.md). Si no especifica ningún bloque, el punto de conexión del servidor de API público recibe solicitudes de todas las direcciones IP tanto `IPv4` (`0.0.0.0/0`) como `IPv6` (`::/0`) para el clúster `IPv6` de doble pila. Si restringe el acceso a su punto de conexión público mediante bloques de CIDR, le recomendamos activar también el acceso al punto de conexión privado para que los nodos y los Pods de Fargate (si los utiliza) puedan comunicarse con el clúster. Si el punto de conexión privado no está habilitado, los orígenes de CIDR del punto de conexión de acceso público deben incluir los orígenes de salida de la VPC. Por ejemplo, si tiene un nodo en una subred privada que se comunica con Internet a través de una puerta de enlace NAT, deberá agregar la dirección IP saliente de la puerta de enlace NAT como parte de un bloque de CIDR permitido en su punto de conexión público.
1. Elija **Update (Actualizar)** para finalizar.
## Configuración del acceso al punto de conexión: AWS CLI
Complete los siguientes pasos con la versión `1.27.160` o posterior de la CLI de AWS. Puede comprobar su versión actual con `aws --version`. Para instalar o actualizar la AWS CLI, consulte [Instalación de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html).
1. Actualice el acceso al punto de conexión del servidor de la API del clúster con el siguiente comando de la AWS CLI. Sustituya el nombre de su clúster y los valores de acceso de punto de conexión deseados. Si configura el `endpointPublicAccess=true`, podrá introducir un solo bloque de CIDR o una lista separada por comas de bloques de CIDR para `publicAccessCidrs`. Los bloques no pueden incluir [direcciones reservadas](https://en.wikipedia.org/wiki/Reserved_IP_addresses). Si especifica bloques de CIDR, el punto de conexión del servidor de API público solo recibirá solicitudes de los bloques enumerados. Hay un número máximo de bloques de CIDR que puede especificar. Para obtener más información, consulte [Visualización y administración de Amazon EKS y las Service Quotas de Fargate](service-quotas.md). Si restringe el acceso a su punto de conexión público mediante bloques de CIDR, se recomienda habilitar también el acceso al punto de conexión privado para que los nodos y los Pods de Fargate (si los utiliza) puedan comunicarse con el clúster. Si el punto de conexión privado no está habilitado, los orígenes de CIDR del punto de conexión de acceso público deben incluir los orígenes de salida de la VPC. Por ejemplo, si tiene un nodo en una subred privada que se comunica con Internet a través de una puerta de enlace NAT, deberá agregar la dirección IP saliente de la puerta de enlace NAT como parte de un bloque de CIDR permitido en su punto de conexión público. Si no especifica ningún bloque de CIDR, el punto de conexión del servidor de API público recibe solicitudes de todas las direcciones IP (0.0.0.0/0) y `IPv6` (`::/0`) para el clúster `IPv6` de doble pila.
**nota**
El siguiente comando habilita el acceso privado y público desde una única dirección IP al punto de conexión del servidor de API. Reemplace *203.0.113.5/32* por un único bloque de CIDR o una lista separada por comas de bloques de CIDR a los que desea restringir el acceso a la red.
```
aws eks update-cluster-config \
--region region-code \
--name my-cluster \
--resources-vpc-config endpointPublicAccess=true,publicAccessCidrs="203.0.113.5/32",endpointPrivateAccess=true
```
Un ejemplo de salida sería el siguiente.
```
{
"update": {
"id": "e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000",
"status": "InProgress",
"type": "EndpointAccessUpdate",
"params": [
{
"type": "EndpointPublicAccess",
"value": "true"
},
{
"type": "EndpointPrivateAccess",
"value": "true"
},
{
"type": "publicAccessCidrs",
"value": "[\"203.0.113.5/32\"]"
}
],
"createdAt": 1576874258.137,
"errors": []
}
}
```
1. Monitoree el estado de la actualización del acceso al punto de conexión con el siguiente comando, utilizando el nombre del clúster y el ID de actualización devueltos por el comando anterior. Su actualización se habrá completado cuando el estado mostrado sea `Successful`.
```
aws eks describe-update \
--region region-code \
--name my-cluster \
--update-id e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000
```
Un ejemplo de salida sería el siguiente.
```
{
"update": {
"id": "e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000",
"status": "Successful",
"type": "EndpointAccessUpdate",
"params": [
{
"type": "EndpointPublicAccess",
"value": "true"
},
{
"type": "EndpointPrivateAccess",
"value": "true"
},
{
"type": "publicAccessCidrs",
"value": "[\"203.0.113.5/32\"]"
}
],
"createdAt": 1576874258.137,
"errors": []
}
}
```
📝 [Edite esta página en GitHub](https://github.com/search?q=repo%3Aawsdocs%2Famazon-eks-user-guide+%5B%23config-cluster-endpoint%5D&type=code)
# Implementación de nodos de Windows en clústeres de EKS
Obtenga información sobre cómo habilitar y administrar la compatibilidad con Windows para el clúster de Amazon EKS para ejecutar contenedores de Windows junto con contenedores de Linux.
## Consideraciones
Antes de implementar nodos de Windows, tenga en cuenta lo siguiente.
+ El modo automático de EKS no es compatible con los nodos de Windows
+ Puede utilizar redes de host en nodos de Windows mediante Pods `HostProcess`. Para obtener más información, consulte [Create a Windows HostProcessPod](https://kubernetes.io/docs/tasks/configure-pod-container/create-hostprocess-pod/) en la documentación de Kubernetes.
+ Los clústeres de Amazon EKS deben contener uno o varios nodos de Linux o Fargate para ejecutar pods del sistema principal que solo se ejecutan en Linux, como CoreDNS.
+ Los registros de eventos `kubelet` y `kube-proxy` se redirigen al registro de eventos de `EKS Windows` y se establecen en un límite de 200 MB.
+ No puede usar [Asignación de los grupos de seguridad a pods individuales](security-groups-for-pods.md) con pods que se ejecuten en nodos de Windows.
+ No puede usar [redes personalizadas](cni-custom-network.md) con nodos de Windows.
+ No puede usar `IPv6` con nodos de Windows.
+ Los nodos de Windows admiten una interfaz de red elástica por nodo. De forma predeterminada, la cantidad de pods que puede ejecutar por nodo de Windows es igual a la cantidad de direcciones IP disponibles por interfaz de red elástica para el tipo de instancia del nodo, menos uno. Para obtener más información, consulte [Direcciones IP por interfaz de red por tipo de instancia](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-eni.html#AvailableIpPerENI) en la *Guía del usuario de Amazon EC2*.
+ En un clúster de Amazon EKS, un único servicio con un equilibrador de carga puede admitir hasta 1024 pods de backend. Cada pod tiene su propia dirección IP única. El límite anterior de 64 pods dejará de aplicarse después de [una actualización de Windows Server](https://github.com/microsoft/Windows-Containers/issues/93) a partir de la [compilación del SO 17763.2746](https://support.microsoft.com/en-us/topic/march-22-2022-kb5011551-os-build-17763-2746-preview-690a59cd-059e-40f4-87e8-e9139cc65de4).
+ No se admiten contenedores de Windows para pods de Amazon EKS en Fargate.
+ No puede utilizar Nodos híbridos de Amazon EKS con Windows como sistema operativo del host.
+ No puede recuperar registros del pod de `vpc-resource-controller`. Anteriormente podía hacerlo cuando se implementaba el controlador en el plano de datos.
+ Hay un periodo de enfriamiento antes de que se asigne una dirección `IPv4` a un nuevo pod. Esto evita que el tráfico fluya hacia un pod anterior con la misma dirección `IPv4` debido a reglas caducadas de `kube-proxy`.
+ El origen del controlador se administra en GitHub. Para registrar problemas con el controlador u ofrecer ayuda con estos, visite el [proyecto](https://github.com/aws/amazon-vpc-resource-controller-k8s) en GitHub.
+ Al especificar un ID de AMI personalizado para los grupos de nodos administrados de Windows, agregue `eks:kube-proxy-windows` al mapa de configuración del Autenticador de AWS IAM. Para obtener más información, consulte [Límites y condiciones al especificar un ID de AMI](launch-templates.md#mng-ami-id-conditions).
+ Si conservar las direcciones IPv4 disponibles es fundamental para su subred, consulte la [Guía de prácticas recomendadas de EKS: Administración de direcciones IP de redes de Windows](https://aws.github.io/aws-eks-best-practices/windows/docs/networking/#ip-address-management) para obtener orientación.
+ Consideraciones para las entradas de acceso de EKS
+ Las entradas de acceso para su uso con los nodos de Windows necesitan el tipo de `EC2_WINDOWS`. Para obtener más información, consulte [Creación de entradas de acceso](creating-access-entries.md).
Para crear una entrada de acceso para un nodo de Windows:
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/ --type EC2_Windows
```
## Requisitos previos
+ Un clúster existente.
+ El clúster debe tener al menos un nodo de Linux o pod de Fargate (recomendamos al menos dos) para ejecutar CoreDNS. Si habilita la compatibilidad con Windows heredado, debe utilizar un nodo de Linux (no puede usar un pod de Fargate) para ejecutar CoreDNS.
+ [Un rol de IAM de clúster de Amazon EKS](cluster-iam-role.md) existente.
## Habilitación de la compatibilidad con Windows
1. Si no tiene nodos de Amazon Linux en su clúster y utiliza grupos de seguridad para pods, avance al paso siguiente. De lo contrario, confirme que la política administrada `AmazonEKSVPCResourceController` esté adjunta al [rol del clúster](cluster-iam-role.md). Reemplace *eksClusterRole* por el nombre del rol del clúster.
```
aws iam list-attached-role-policies --role-name eksClusterRole
```
Un ejemplo de salida sería el siguiente.
```
{
"AttachedPolicies": [
{
"PolicyName": "AmazonEKSClusterPolicy",
"PolicyArn": "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy"
},
{
"PolicyName": "AmazonEKSVPCResourceController",
"PolicyArn": "arn:aws:iam::aws:policy/AmazonEKSVPCResourceController"
}
]
}
```
Si la política está adjunta, como en la salida anterior, omita el siguiente paso.
1. Agregue la política de administrada ** [AmazonEKSVPCResourceController](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSVPCResourceController.html) ** al [rol de IAM asociado a su clúster de Amazon EKS](cluster-iam-role.md). Reemplace *eksClusterRole* por el nombre del rol del clúster.
```
aws iam attach-role-policy \
--role-name eksClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController
```
1. Actualice el ConfigMap de la CNI de la VPC para habilitar el IPAM de Windows. Tenga en cuenta que si la CNI de la VPC está instalada en el clúster mediante un gráfico de Helm o como un complemento de Amazon EKS, es posible que no pueda modificar directamente el ConfigMap. Para obtener información sobre la configuración de complementos de Amazon EKS, consulte [Determinación de los campos que se pueden personalizar para los complementos de Amazon EKS](kubernetes-field-management.md).
1. Cree un archivo llamado *vpc-resource-controller-configmap.yaml* con el siguiente contenido.
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-windows-ipam: "true"
```
1. Aplique el `ConfigMap` en su clúster.
```
kubectl apply -f vpc-resource-controller-configmap.yaml
```
1. Si su clúster tiene el modo de autenticación configurado para habilitar el configmap de `aws-auth`:
+ Verifique que el `ConfigMap` de `aws-auth` contenga una asignación para que el rol de instancia del nodo de Windows incluya el grupo de permisos RBAC de `eks:kube-proxy-windows`. Puede verificar ejecutando el siguiente comando:
```
kubectl get configmap aws-auth -n kube-system -o yaml
```
Un ejemplo de salida sería el siguiente.
```
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
- eks:kube-proxy-windows # This group is required for Windows DNS resolution to work
rolearn: arn:aws:iam::111122223333:role/eksNodeRole
username: system:node:{{EC2PrivateDNSName}}
[...]
```
`eks:kube-proxy-windows` debería aparecer en la lista de grupos. Si el grupo no está especificado, debe actualizar `ConfigMap` o crearlo para incluir el grupo requerido. Para obtener más información sobre `ConfigMap` de `aws-auth`, consulte [Aplique el `ConfigMap` de `aws-auth` en su clúster](auth-configmap.md#aws-auth-configmap).
1. Si su clúster tiene el modo de autenticación configurado para deshabilitar el configmap de `aws-auth`, puede usar las entradas de acceso de EKS. Cree un nuevo rol de nodo para usarlo con las instancias de Windows, y EKS creará automáticamente una entrada de acceso de tipo `EC2_WINDOWS`.
## Implementación de pods de Windows
Cuando implementa pods en el clúster, debe especificar el sistema operativo que utilizan si ejecuta una combinación de tipos de nodos.
Para pods de Linux, use el siguiente texto del selector de nodos en sus manifiestos.
```
nodeSelector:
kubernetes.io/os: linux
kubernetes.io/arch: amd64
```
Para pods de Windows, use el siguiente texto del selector de nodos en sus manifiestos.
```
nodeSelector:
kubernetes.io/os: windows
kubernetes.io/arch: amd64
```
Puede implementar una [aplicación de muestra](sample-deployment.md) para ver los selectores de nodos en uso.
## Soporte para una mayor densidad de pods en los nodos de Windows
En Amazon EKS, a cada pod se le asigna una dirección `IPv4` desde su VPC. Debido a esto, la cantidad de pods que puede implementar en un nodo está limitada por las direcciones IP disponibles, incluso si hay recursos suficientes para ejecutar más pods en el nodo. Dado que un nodo de Windows solo admite una interfaz de red elástica, de forma predeterminada, la cantidad máxima de direcciones IP disponibles en un nodo de Windows es igual a:
```
Number of private IPv4 addresses for each interface on the node - 1
```
Se utiliza una dirección IP como dirección IP principal de la interfaz de red, por lo que no se puede asignar a pods.
Puede habilitar una mayor densidad de pods en los nodos de Windows si habilita la delegación de prefijos de IP. Esta característica le permite asignar un prefijo `/28` `IPv4` a la interfaz de red principal, en lugar de asignar direcciones `IPv4` secundarias. La asignación de un prefijo IP aumenta el número máximo de direcciones `IPv4` disponibles en el nodo a:
```
(Number of private IPv4 addresses assigned to the interface attached to the node - 1) * 16
```
Con esta cantidad significativamente mayor de direcciones IP disponibles, las direcciones IP disponibles no deberían limitar su capacidad para escalar la cantidad de pods en sus nodos. Para obtener más información, consulte [Asignación de más direcciones IP a los nodos de Amazon EKS con prefijos](cni-increase-ip-addresses.md).
# Deshabilitar la compatibilidad con Windows
1. Si el clúster contiene nodos de Amazon Linux y utiliza [grupos de seguridad para pods](security-groups-for-pods.md), omita este paso.
Eliminación de política administrada de IAM `AmazonVPCResourceController` de su [rol de clúster](cluster-iam-role.md). Sustituya *eksClusterRole* por el nombre del rol del clúster.
```
aws iam detach-role-policy \
--role-name eksClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController
```
1. Deshabilite IPAM de Windows en el ConfigMap de `amazon-vpc-cni`.
```
kubectl patch configmap/amazon-vpc-cni \
-n kube-system \
--type merge \
-p '{"data":{"enable-windows-ipam":"false"}}'
```
# Implementación de clústeres privados con acceso limitado a Internet
En este tema, se describe cómo implementar un clúster de Amazon EKS que se implementa en la nube de AWS sin acceso a Internet saliente. Si tiene un clúster local en AWS Outposts, consulte [Creación de nodos de Amazon Linux en AWS Outposts](eks-outposts-self-managed-nodes.md) en lugar de este tema.
Si no está familiarizado con las redes de Amazon EKS, consulte [Desmitificación de las redes de clústeres para nodos de trabajo de Amazon EKS](https://aws.amazon.com/blogs/containers/de-mystifying-cluster-networking-for-amazon-eks-worker-nodes). Si su clúster no tiene acceso a Internet saliente, debe cumplir con los siguientes requisitos:
## Requisitos de la arquitectura del clúster
+ El clúster debe extraer imágenes de un registro de contenedores que esté en su VPC. Puede crear un Amazon Elastic Container Registry en su VPC y copiar las imágenes del contenedor para que sus nodos puedan extraerlas. Para obtener más información, consulte [Copiar una imagen de contenedor de un repositorio en otro repositorio](copy-image-to-repository.md).
+ Su clúster debe tener habilitado el acceso privado a los puntos de conexión. Esto es necesario para que los nodos se registren en el punto de conexión del clúster. El acceso público del punto de conexión es opcional. Para obtener más información, consulte [Punto de conexión del servidor de API del clúster](cluster-endpoint.md).
## Requisitos del nodo
+ Los nodos autoadministrados de Linux y Windows deben incluir los siguientes argumentos de arranque antes de lanzarlos. Estos argumentos omiten la introspección de Amazon EKS y no requieren acceso a la API de Amazon EKS desde dentro de la VPC.
1. Determine el valor del punto de conexión del clúster con el siguiente comando. Reemplace *my-cluster* por el nombre de su clúster.
```
aws eks describe-cluster --name my-cluster --query cluster.endpoint --output text
```
Un ejemplo de salida sería el siguiente.
```
https://EXAMPLE108C897D9B2F1B21D5EXAMPLE.sk1.region-code.eks.amazonaws.com
```
1. Determine el valor de la autoridad de certificación del clúster con el siguiente comando. Reemplace *my-cluster* por el nombre de su clúster.
```
aws eks describe-cluster --name my-cluster --query cluster.certificateAuthority --output text
```
El resultado devuelto es una cadena larga.
1. Reemplace los valores de `apiServerEndpoint` y `certificateAuthority` en el objeto NodeConfig por los valores devueltos en la salida de los comandos anteriores. Para obtener más información acerca de cómo especificar argumentos de arranque al lanzar nodos de Amazon Linux 2023 autoadministrados, consulte [Creación de nodos autoadministrados de Amazon Linux](launch-workers.md) y [Creación de nodos autoadministrados de Microsoft Windows](launch-windows-workers.md).
+ En el caso de los nodos Linux:
```
---
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: [.replaceable]https://EXAMPLE108C897D9B2F1B21D5EXAMPLE.sk1.region-code.eks.amazonaws.com
certificateAuthority: [.replaceable]Y2VydGlmaWNhdGVBdXRob3JpdHk=
...
```
Para obtener argumentos adicionales, consulte el [script de arranque](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) en GitHub.
+ Para los usuarios de Windows:
**nota**
Si utiliza un CIDR de servicio personalizado, debe especificarlo con el parámetro `-ServiceCIDR`. De lo contrario, se producirá un error en la resolución de DNS del clúster para pods.
```
-APIServerEndpoint cluster-endpoint -Base64ClusterCA certificate-authority
```
Para obtener argumentos adicionales, consulte [Parámetros de configuración del script de arranque](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
+ El `aws-auth` `ConfigMap` del clúster debe crearse desde su VPC. Para obtener más información sobre cómo crear y añadir entradas al `ConfigMap` de `aws-auth`, ingrese `eksctl create iamidentitymapping --help` en su terminal. Si el `ConfigMap` no existe en su servidor, `eksctl` lo creará cuando utilice el comando para añadir una asignación de identidad.
## Requisitos del pod
+ **Pod Identity**: los pods configurados con Pod Identity de EKS adquieren las credenciales de la API de autenticación de EKS. Si no hay acceso a Internet de salida, debe crear y utilizar un punto de conexión de VPC para la API de autenticación de EKS: `com.amazonaws.region-code.eks-auth`. Para obtener más información sobre los puntos de conexión de VPC de EKS y de autenticación de EKS, consulte [Acceso a Amazon EKS con AWS PrivateLink](vpc-interface-endpoints.md).
+ **IRSA**: los pods configurados con [roles de IAM para cuentas de servicio](iam-roles-for-service-accounts.md) adquieren credenciales de una llamada a la API de AWS Security Token Service (AWS STS). Si no hay acceso a Internet saliente, debe crear y utilizar un punto de conexión de VPC de AWS STS en su VPC. La mayoría de los SDK de AWS `v1` utilizan el punto de conexión global de AWS STS de forma predeterminada (`sts.amazonaws.com`), que no utiliza el punto de conexión de VPC de AWS STS. Para utilizar el punto de conexión de VPC de AWS STS, es posible que tenga que configurar el SDK de modo que utilice el punto de conexión de AWS STS regional (`sts.region-code.amazonaws.com`). Para obtener más información, consulte [Configure el punto de conexión AWS Security Token Service de una cuenta de servicio](configure-sts-endpoint.md).
+ Las subredes de VPC de su clúster deben tener un punto de conexión de interfaz de VPC para todas las subredes de VPC de los servicios de AWS a los que los pods necesiten acceder. Para obtener más información, consulte [Acceso a un servicio de AWS a través de un punto de conexión de VPC de interfaz](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html). Algunos servicios y puntos de conexión de uso común se enumeran en la siguiente tabla. Para obtener la lista completa de los puntos de conexión, consulte [Servicios de AWS que se integran con AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html) en la [Guía de AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/).
Recomendamos que [habilite nombres de DNS privados](https://docs.aws.amazon.com/vpc/latest/privatelink/interface-endpoints.html#enable-private-dns-names) para los puntos de conexión de la VPC, de modo que las cargas de trabajo aún puedan utilizar los puntos de conexión de servicio de AWS públicos sin problemas.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/private-clusters.html)
+ Todos los nodos autoadministrados deben implementarse en subredes que tengan los puntos de conexión de la interfaz de VPC que necesita. Si crea un grupo de nodos administrados, el grupo de seguridad del punto de conexión de la interfaz de VPC debe permitir el CIDR para las subredes. También puede agregar el grupo de seguridad del nodo creado al grupo de seguridad del punto de conexión de la interfaz de VPC.
+ **Almacenamiento de EFS**: si sus pods utilizan volúmenes de Amazon EFS, antes de implementar el [almacenamiento de un sistema de archivos con Amazon EFS](efs-csi.md), se debe cambiar el archivo [kustomization.yaml](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/deploy/kubernetes/overlays/stable/kustomization.yaml) del controlador para establecer las imágenes de contenedor de manera que utilicen la misma región de AWS que el clúster de Amazon EKS.
+ Route 53 no es compatible con AWS PrivateLink. No puede administrar los registros de DNS de Route 53 desde un clúster privado de Amazon EKS. Esto afecta a [external-dns](https://github.com/kubernetes-sigs/external-dns) de Kubernetes.
+ Si usa la AMI optimizada para EKS, debe habilitar el punto de conexión de `ec2` en la tabla anterior. También puede configurar el nombre de DNS del nodo de forma manual. La AMI optimizada utiliza las API de EC2 para establecer el nombre de DNS del nodo automáticamente.
+ Puede utilizar el [controlador de equilibrador de carga de AWS](aws-load-balancer-controller.md) para implementar los Equilibradores de carga de aplicación (ALB) y los equilibradores de carga de red de AWS en su clúster privado. Al implementarlo, debe usar los [indicadores de línea de comandos](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/deploy/configurations/#controller-command-line-flags) para establecer `enable-shield`, `enable-waf` y `enable-wafv2` como falsos. No se admite la [detección de certificados](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/cert_discovery/#discover-via-ingress-rule-host) con nombres de host de los objetos de entrada. Esto se debe a que el controlador necesita llegar a AWS Certificate Manager, el cual no tiene un punto de conexión de la interfaz de VPC.
El controlador es compatible con equilibradores de carga de red con destinos IP, que son necesarios para su uso con Fargate. Para obtener más información, consulte [Redirección de tráfico de aplicaciones y HTTP con los equilibradores de carga de aplicaciones](alb-ingress.md) y [Crear un equilibrador de carga de red](network-load-balancing.md#network-load-balancer).
+ Se admite el [Escalador automático de clústeres](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md). Al implementar pods del Escalador automático de clústeres, asegúrese de que la línea de comandos incluya `--aws-use-static-instance-list=true`. Para obtener más información, consulte [Use Static Instance List](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#use-static-instance-list) en GitHub. La VPC del nodo de trabajo también debe incluir el punto de conexión de VPC de AWS STS y el punto de conexión de VPC de escalado automático.
+ Algunos productos de software de contenedores utilizan llamadas API que acceden al servicio de medición de AWS Marketplace para supervisar el uso. Los clústeres privados no permiten estas llamadas, por lo que estos tipos de contenedores no se pueden utilizar en clústeres privados.
# Escale la computación en clústeres con Karpenter y el Escalador automático de clústeres
El escalado automático es una función que escala y reduce horizontalmente los recursos de manera automática para satisfacer las demandas cambiantes. Esta es una función importante de Kubernetes que, de otro modo, requeriría muchos recursos humanos para funcionar manualmente.
## Modo automático de EKS
El modo automático de Amazon EKS escala automáticamente los recursos de computación del clúster. Si un pod no cabe en los nodos existentes, el modo automático de EKS crea uno nuevo. El modo automático de EKS también consolida cargas de trabajo y elimina nodos. El modo automático de EKS se basa en Karpenter.
Para obtener más información, consulte:
+ [Automatización de la infraestructura de clústeres con el modo automático de EKS](automode.md)
+ [Creación de un grupo de nodos para el modo automático de EKS](create-node-pool.md)
+ [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)
## Soluciones adicionales
Amazon EKS admite dos productos adicionales de escalado automático:
**Karpenter**
Karpenter es un escalador automático de clústeres de Kubernetes flexible y de alto rendimiento que ayuda a mejorar la disponibilidad de las aplicaciones y la eficiencia del clúster. Karpenter lanza recursos de computación del tamaño correcto (por ejemplo, instancias de Amazon EC2) en respuesta a los cambios en la carga de la aplicación en menos de un minuto. Mediante la integración de Kubernetes con AWS, Karpenter puede aprovisionar recursos informáticos justo a tiempo que cumplen con precisión los requisitos de su carga de trabajo. Karpenter aprovisiona automáticamente nuevos recursos informáticos en función de los requisitos específicos de las cargas de trabajo de un clúster. Estos incluyen requisitos de computación, almacenamiento, aceleración y programación. Amazon EKS admite clústeres que utilizan Karpenter, aunque Karpenter funciona con cualquier clúster de Kubernetes conforme. Para obtener más información, consulte la documentación de [Karpenter](https://karpenter.sh/docs/).
Karpenter es un software de código abierto que los clientes de AWS son responsables de instalar, configurar y administrar en sus clústeres de Kubernetes. AWS proporciona soporte técnico cuando Karpenter se ejecuta sin modificaciones utilizando una versión compatible en los clústeres de Amazon EKS. Es fundamental que los clientes aseguren la disponibilidad y seguridad del controlador Karpenter y mantengan procedimientos de prueba adecuados al actualizar tanto el controlador como el clúster de Kubernetes en el que se ejecuta, al igual que con cualquier otro software administrado por el cliente. Karpenter no tiene ningún Acuerdo de nivel de servicio (SLA) de AWS y los clientes son responsables de garantizar que las instancias EC2 lanzadas por Karpenter cumplan con sus requisitos empresariales.
**Escalador automático de clústeres**
El Cluster Autoscaler de Kubernetes ajusta de forma automática el número de nodos del clúster cuando los pods fallan o se reprograman en otros nodos. El Escalador automático de clústeres utiliza grupos de escalado automático. Para obtener más información, consulte [Escalador automático de clústeres en AWS](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md).
# Información sobre el cambio de zona del Controlador de recuperación de aplicaciones de Amazon (ARC) en Amazon EKS
Kubernetes tiene características nativas que le permiten que sus aplicaciones sean más resistentes a eventos como el deterioro del estado o el deterioro de una zona de disponibilidad (AZ). Cuando ejecuta sus cargas de trabajo en un clúster de Amazon EKS, puede mejorar aún más la tolerancia a errores del entorno y la recuperación de aplicaciones mediante el [cambio de zona del Controlador de recuperación de aplicaciones de Amazon (ARC)](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.html) o el [cambio de zona automático](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.html). El cambio de zona de ARC está diseñado como una medida temporal que le permite alejar el tráfico de un recurso de una AZ deteriorada hasta que el cambio de zona caduque o se cancele. Si es necesario, puede ampliar el cambio de zona.
Puede iniciar un cambio de zona para un clúster de EKS o permitir que AWS cambie el tráfico mediante la activación del cambio de zona automático. Este cambio actualiza el flujo del tráfico de red de este a oeste en su clúster para tener en cuenta únicamente los puntos de conexión de red de los pods que se ejecutan en nodos de trabajo en AZ en buen estado. Además, cualquier ALB o NLB que administre la entrada del tráfico de las aplicaciones de su clúster de EKS enrutará de forma automática el tráfico a los destinos de las AZ en buen estado. Para aquellos clientes que buscan los objetivos de disponibilidad más altos, en caso de que una AZ se estropee, puede ser importante poder desviar todo el tráfico de la AZ afectada hasta que se recupere. Para esto, también puede [https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.html](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.html).
## Descripción del flujo de tráfico de red de este a oeste entre pods
El siguiente diagrama ilustra dos ejemplos de cargas de trabajo, Pedidos y Productos. El propósito de este ejemplo es mostrar cómo se comunican las cargas de trabajo y los pods en diferentes AZ.
![\[Ilustración del tráfico de red\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/zs-traffic-flow-before-1.png)
![\[Ilustración del tráfico de red\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/zs-traffic-flow-before-2.png)
1. Para que Pedidos se comunique con Productos, debe resolver antes el nombre de DNS del servicio de destino. Pedidos se comunica con CoreDNS para obtener la dirección IP virtual (IP del clúster) de ese servicio. Después de que Pedidos resuelva el nombre del servicio de Productos, envía el tráfico a esa dirección IP de destino.
1. El kube-proxy se ejecuta en todos los nodos del clúster y supervisa de manera continua los [EndpointSlices](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/) en busca de servicios. Cuando se crea un servicio, el controlador EndpointSlice crea y administra un EndpointSlice en segundo plano. Cada EndpointSlice tiene una lista o tabla de puntos de conexión que contiene un subconjunto de direcciones de pods junto con los nodos en los que se ejecutan. El kube-proxy establece reglas de enrutamiento para cada uno de estos puntos de conexión de los pods mediante el uso de `iptables` en los nodos. El kube-proxy también es responsable de una forma básica de equilibrio de carga, ya que redirige el tráfico destinado a la dirección IP del clúster de un servicio para que, en su lugar, se envía directamente a la dirección IP del pod. Para hacerlo, el kube-proxy reescribe la dirección IP de destino en la conexión saliente.
1. A continuación, los paquetes de red se envían al pod Productos de la AZ 2 mediante los ENI de los nodos respectivos, como se muestra en el diagrama anterior.
### Descripción del cambio de zona de ARC en Amazon EKS
Si hay una alteración de la AZ en su entorno, puede iniciar un cambio de zona para su entorno de clústeres de EKS. Como alternativa, puede permitir que AWS administre el cambio de tráfico con el cambio de zona automático. Con el cambio de zona automático, AWS supervisa el estado general de la AZ y responde a una posible alteración de esta mediante el cambio automático del tráfico de la AZ dañada de su entorno de clústeres.
Cuando se haya activado el cambio de zona del clúster de Amazon EKS con ARC, puede iniciar un cambio de zona o activar un cambio de zona automático mediante la consola de ARC, la AWS CLI o las API de cambio de zona automático y cambio de zona. Durante un cambio de zona de EKS, ocurrirá lo siguiente de forma automática:
+ Se acordonan todos los nodos de la AZ afectada. De este modo, se evita que el programador de Kubernetes programe nuevos pods en los nodos de la AZ en mal estado.
+ Si utiliza [grupos de nodos administrados](managed-node-groups.md), se suspende el [https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage) y se actualiza el grupo de escalado automático para garantizar que los nuevos nodos del plano de datos de Amazon EKS solo se lancen en las zonas de disponibilidad en buen estado.
+ Los nodos de la AZ en mal estado no se terminan y los pods no se expulsan de los nodos. De este modo, se garantizar que, cuando un cambio de zona caduque o se cancele, el tráfico pueda devolverse con seguridad a la AZ para una capacidad plena.
+ El controlador EndpointSlice busca todos los puntos de conexión del pod en la AZ defectuosa y los elimina de los EndpointSlices pertinentes. Esto garantiza que solo los puntos de conexión de pods situados en zonas de disponibilidad en buen estado estén destinados a recibir tráfico de red. Cuando un cambio de zona caduca o se cancela, el controlador EndpointSlice actualiza los EndpointSlices para incluir los puntos de conexión de la AZ restaurada.
Los diagramas siguientes proporcionan información general de alto nivel sobre cómo el cambio de zona de EKS garantiza que solo se usen como objetivo los puntos de conexión de pod en buen estado en el entorno de clústeres.
![\[Ilustración del tráfico de red\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/zs-traffic-flow-after-1.png)
![\[Ilustración del tráfico de red\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/zs-traffic-flow-after-2.png)
## Requisitos del cambio de zona de EKS
Para que el cambio de zona funcione de manera correcta con EKS, debe configurar previamente su entorno de clústeres para que sea resistente a un deterioro de la AZ. A continuación se muestra una lista de opciones de configuración que ayudan a garantizar la resiliencia.
+ Aprovisione los nodos de trabajo de su clúster en varias zonas de disponibilidad.
+ Aprovisione suficiente capacidad de computación para acomodar la eliminación de una sola AZ.
+ Escale previamente sus pods, incluido CoreDNS, en todas las AZ.
+ Distribuya varias réplicas de pods en todas las AZ para asegurarse de que dispondrá de suficiente capacidad si deja de utilizar una sola AZ.
+ Ubique los pods interdependientes o relacionados en la misma AZ.
+ Inicie un cambio de zona de una AZ de forma manual para probar si el entorno de clústeres funciona según lo esperado sin una AZ. Como alternativa, puede activar el cambio de zona automático y depender de las ejecuciones de práctica del cambio automático. Las pruebas con cambios de zona manuales o de práctica no son obligatorias para que el cambio de zona funcione en EKS, pero se recomiendan encarecidamente.
### Aprovisionamiento de los nodos de trabajo de EKS en varias zonas de disponibilidad
Las regiones de AWS tienen varias ubicaciones independientes con centros de datos físicos, conocidas como zonas de disponibilidad (AZ). Las AZ están diseñadas para estar aisladas físicamente unas de otras a fin de evitar un impacto simultáneo que podría afectar a toda una región. Al aprovisionar un clúster de EKS, le recomendamos que implemente los nodos de trabajo en varias AZ de una región. Esto ayudará a que su entorno ende clústeres sea más resistente a los daños de una sola AZ y le permitirá mantener una alta disponibilidad para las aplicaciones que se ejecuten en las demás AZ. Cuando inicie un cambio de zona para alejarse de la AZ afectada, la red integrada en el clúster de su entorno de Amazon EKS se actualizará automáticamente para utilizar solo las AZ en buen estado a fin de ayudar a mantener una alta disponibilidad para el clúster.
Asegurarse de disponer de una configuración multi-AZ para su entorno de Amazon EKS mejora la fiabilidad general de su sistema. Sin embargo, los entornos multi-AZ influyen en cómo se transfieren y procesan los datos de las aplicaciones, lo que, a su vez, repercute en las tarifas de red de su entorno. Concretamente, el tráfico de salida frecuente entre zonas (tráfico distribuido entre las AZ) puede tener un impacto importante en los costos relacionados con la red. Puede aplicar diferentes estrategias para controlar la cantidad de tráfico entre zonas en los pods de su clúster de Amazon EKS y reducir los costos asociados. Para obtener más información sobre cómo optimizar los costos de red cuando se utilizan entornos de Amazon EKS de alta disponibilidad, consulte [https://aws.github.io/aws-eks-best-practices/cost_optimization/cost_opt_networking/](https://aws.github.io/aws-eks-best-practices/cost_optimization/cost_opt_networking/).
En el siguiente diagrama, se ilustra un entorno de EKS de alta disponibilidad con tres AZ en buen estado.
![\[Ejemplo de red\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/zs-ha-before-failure.png)
En el siguiente diagrama, se ilustra cómo un entorno de Amazon EKS con tres AZ es resistente a una AZ dañada y mantiene una alta disponibilidad gracias a dos AZ restantes en buen estado.
![\[Ejemplo de red\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/zs-ha-after-failure.png)
### Aprovisionamiento de suficiente capacidad de computación para soportar la eliminación de una sola zona de disponibilidad
Para optimizar el uso de los recursos y los costos de su infraestructura de computación en el plano de datos de Amazon EKS, una práctica recomendada consiste e alinear la capacidad de computación con los requisitos de la carga de trabajo. Sin embargo, **si todos sus nodos de trabajo están a plena capacidad**, tiene que agregar nuevos nodos de trabajo al plano de datos de EKS antes de poder programar nuevos pods. Cuando ejecuta cargas de trabajo críticas, suele ser una práctica recomendada ejecutar una capacidad redundante en línea para gestionar distintos escenarios como el aumento repentino de la carga o los problemas de estado de los nodos. Si tiene previsto utilizar un cambio de zona, tiene previsto eliminar toda una zona de disponibilidad de capacidad si hubiera daños. Esto significa que debe ajustar la capacidad de computación redundante a fin de que sea suficiente para gestionar la carga incluso con una de las AZ desconectada.
Al escalar los recursos de computación, el proceso de agregar nuevos nodos al plano de datos de EKS lleva algún tiempo. Esto puede repercutir en el rendimiento y la disponibilidad en tiempo real de las aplicaciones, en especial si hay daños en una zona. Su entorno de Amazon EKS debe poder absorber la carga que supone perder una AZ sin que la experiencia de sus usuarios finales o clientes se deteriore. Esto significa minimizar o eliminar cualquier intervalo entre el momento en que se necesita un nuevo pod y el momento real en que se programa en un nodo de trabajo.
Además, si se producen daños en una zona, debe intentar reducir el riesgo de que se produzca una posible limitación de la capacidad de computación que impida agregar nuevos nodos necesarios al plano de datos de Amazon EKS en las AZ en buen estado.
Para lograr reducir el riesgo de estos posibles impactos negativos, le recomendamos aprovisionar en exceso la capacidad de computación en algunos de los nodos de trabajo de cada AZ. De este modo, el programador de Kubernetes dispone de una capacidad preexistente para colocar nuevos pods, lo que es de especial importancia si se pierde una de las AZ del entorno.
### Ejecución y distribución de varias réplicas de pods entre zonas de disponibilidad
Kubernetes le permite escalar previamente sus cargas de trabajo mediante la ejecución de varias instancias (réplicas de pods) de una sola aplicación. Al ejecutar varias réplicas de pods para una aplicación, se eliminan puntos de error y se aumenta su rendimiento general, ya que se reduce la carga de recursos en una sola réplica. Sin embargo, para que sus aplicaciones tengan una alta disponibilidad y una mejor tolerancia a errores, le recomendamos que ejecute y distribuya varias réplicas de su aplicación en distintos dominios de errores, también denominados dominios de topología. Los dominios de errores de este escenario son las zonas de disponibilidad. Al utilizar las [restricciones de distribución topológica](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/), puede configurar sus aplicaciones para que tengan una estabilidad estática preexistente. De este modo, cuando se produzcan daños en una zona de disponibilidad, su entorno dispondrá de suficientes réplicas en AZ en buen estado para gestionar inmediatamente cualquier pico o aumento del tráfico.
En el siguiente diagrama, se ilustra un entorno de Amazon EKS que tiene un flujo de tráfico de este a oeste cuando todas las AZ están en buen estado.
![\[Ejemplo de red\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/zs-spread-constraints.png)
En el siguiente diagrama, se ilustra un entorno de Amazon EKS que tiene un flujo de tráfico de este a oeste en el que se ha producido un error en una sola zona de disponibilidad y ha iniciado un cambio de zona.
![\[Ejemplo de red\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/zs-spread-constraints-2.png)
El siguiente fragmento de código es un ejemplo de cómo configurar la carga de trabajo con varias réplicas en Kubernetes.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: orders
spec:
replicas: 9
selector:
matchLabels:
app:orders
template:
metadata:
labels:
app: orders
tier: backend
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: "topology.kubernetes.io/zone"
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app: orders
```
Lo que es más importante, debe ejecutar varias réplicas del software de servidor de DNS (CoreDNS/kube-dns) y aplicar restricciones de distribución topológica similares si no están configuradas de forma predeterminada. Esto ayuda a garantizar que, si hay daños en una sola AZ, disponga de suficientes pods de DNS en AZ en buen estado para poder continuar con la gestión de las solicitudes de detección de servicios de otros pods que se comunican entre sí en el clúster. El [complemento de EKS de CoreDNS](managing-coredns.md) tiene una configuración predeterminada para los pods de CoreDNS que garantiza que, si hay nodos en varias AZ disponibles, se distribuyan en las zonas de disponibilidad del clúster. Si lo desea, también puede reemplazar esta configuración predeterminada por su propia configuración personalizada.
Al instalar [CoreDNS con Helm](https://github.com/coredns/helm/tree/master), puede actualizar el `replicaCount` en el [archivo values.yaml](https://github.com/coredns/helm/blob/master/charts/coredns/values.yaml) para asegurarse de que disponga de suficientes réplicas en cada AZ. Además, para asegurarse de que estas réplicas estén distribuidas en las distintas AZ del entorno de clústeres, asegúrese de actualizar la propiedad `topologySpreadConstraints` en el mismo archivo `values.yaml`. En el siguiente fragmento de código, se ilustra cómo puede configurar CoreDNS para hacerlo.
**CoredNS Helm values.yaml**
```
replicaCount: 6
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
k8s-app: kube-dns
```
Si hay daños en una AZ, puede absorber el aumento de carga de los pods de CoreDNS mediante un sistema de escalado automático para CoreDNS. La cantidad de instancias de DNS que necesite dependerá de la cantidad de cargas de trabajo que se ejecuten en el clúster. CoreDNS está vinculado a la CPU, lo que le permite escalar en función de la CPU mediante el [Escalador automático de pods horizontales (HPA)](https://aws.github.io/aws-eks-best-practices/reliability/docs/application/#horizontal-pod-autoscaler-hpa). A continuación, se muestra un ejemplo que puede modificar según sus necesidades.
```
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: coredns
namespace: default
spec:
maxReplicas: 20
minReplicas: 2
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: coredns
targetCPUUtilizationPercentage: 50
```
Como alternativa, Amazon EKS puede administrar el escalado automático de la implementación de CoreDNS en la versión del complemento de EKS de CoreDNS. Este escalador automático de CoreDNS monitorea continuamente el estado del clúster, incluida la cantidad de nodos y núcleos de CPU. En función de esa información, el controlador ajusta dinámicamente el número de réplicas de la implementación de CoreDNS en un clúster de Amazon EKS.
Para activar la [configuración de escalado automático en el complemento de EKS de CoreDNS](coredns-autoscaling.md), utilice la configuración siguiente:
```
{
"autoScaling": {
"enabled": true
}
}
```
También puede usar el [NodeLocal DNS](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/) o el [escalador automático proporcional del clúster](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler) para escalar CoredNS. Para obtener más información, consulte [Escalado horizontal de CoreDNS](https://aws.github.io/aws-eks-best-practices/scalability/docs/cluster-services/#scale-coredns-horizontally).
### Colocación de pods interdependientes en la misma zona de disponibilidad
Por lo general, las aplicaciones tienen cargas de trabajo distintas que deben comunicarse entre sí para completar correctamente un proceso integral. Si estas distintas aplicaciones están distribuidas en diferentes AZ y no están ubicadas en la misma AZ, el proceso integral puede verse afectado si hay daños en una sola AZ. Por ejemplo, si la **Aplicación A** tiene varias réplicas en la AZ 1 y la AZ 2, pero la **Aplicación B** tiene todas sus réplicas en la AZ 3, la pérdida de la AZ 3 afectará al proceso integral entre las dos cargas de trabajo, **Aplicación A** y **Aplicación B**. Si combina las restricciones de distribución topológica con la afinidad de pods, puede mejorar la resiliencia de la aplicación mediante la distribución de pods entre todas las AZ. Además, se configura una relación entre determinados pods para garantizar su coubicación.
Con las [reglas de afinidad de los pods](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/), puede definir las relaciones entre las cargas de trabajo para influir en el comportamiento del programador de Kubernetes, de modo que coloque los pods en el mismo nodo de trabajo o en la misma zona de disponibilidad. También puede configurar qué tan estrictas deben ser las restricciones de programación.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: products
namespace: ecommerce
labels:
app.kubernetes.io/version: "0.1.6"
spec:
serviceAccountName: graphql-service-account
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- orders
topologyKey: "kubernetes.io/hostname"
```
En el siguiente diagrama, se muestran varios pods que se han ubicado en el mismo nodo con reglas de afinidad de pods.
![\[Ejemplo de red\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/zs-pod-affinity-rule.png)
### Comprobación de si el entorno de clústeres puede soportar la pérdida de una AZ
Después de cumplir los requisitos descritos en las secciones anteriores, el siguiente paso es comprobar que disponga de la capacidad de computación y cargas de trabajo suficientes para afrontar la pérdida de una AZ. Para ello, puede iniciar un cambio de zona en EKS de forma manual. Como alternativa, puede activar el cambio de zona automático y configurar ejecuciones de práctica, que también comprueban que las aplicaciones funcionen según lo esperado con una AZ menos en el entorno de clústeres.
## Preguntas frecuentes
**Por qué debo utilizar esta característica?**
Al utilizar el cambio de zona o el cambio de zona automático de ARC en su clúster de Amazon EKS es más fácil mantener la disponibilidad de las aplicaciones de Kubernetes al automatizar el proceso de recuperación rápida que consiste en desviar el tráfico de red de una zona de disponibilidad defectuosa dentro del clúster. Con ARC, puede evitar pasos largos y complicados que pueden conllevar un periodo de recuperación prolongado cuando se producen daños en las AZ.
**¿Cómo funciona esta característica con otros servicios de AWS?**
EKS se integra con ARC, que proporciona la interfaz principal en la que puede llevar a cabo las operaciones de recuperación en AWS. Para garantizar que el tráfico interno del clúster se aleje de manera apropiada de una AZ dañada, EKS hace modificaciones en la lista de puntos de conexión de red para los pods que se ejecutan en el plano de datos de Kubernetes. Si utiliza Elastic Load Balancing para dirigir el tráfico externo al clúster, puede registrar los equilibradores de carga con ARC e iniciar un cambio de zona en ellos para evitar que el tráfico fluya hacia la AZ dañada. El cambio de zona también funciona con grupos de Amazon EC2 Auto Scaling creados por los grupos de nodos administrados por EKS. Para evitar que una AZ dañada se utilice para lanzar nuevos nodos o pods de Kubernetes, EKS elimina la AZ dañada de los grupos de escalado automático.
**En qué se diferencia esta característica de las protecciones predeterminadas de Kubernetes?**
Esta característica funciona junto con varias protecciones integradas de Kubernetes que ayudan a la resiliencia de las aplicaciones de los clientes. Puede configurar sondeos de disponibilidad y actividad de un pod que decidan cuándo un pod debe recibir tráfico. Cuando se produce un error en estos sondeos, Kubernetes elimina estos pods como objetivos de un servicio y deja de enviarse el tráfico al pod. Si bien esto es útil, no es sencillo para los clientes configurar estas comprobaciones de estado de forma que se garantice que se produzca un error cuando una AZ se dañe. La característica de cambio de zona de ARC proporciona una red de seguridad adicional que lo ayuda a aislar por completo una AZ dañada cuando las protecciones nativas de Kubernetes no fueron suficientes. El cambio de zona también le proporciona una forma sencilla de evaluar la preparación operativa y la resiliencia de su arquitectura.
**¿AWS puede iniciar un cambio de zona en mi nombre?**
Sí, si desea utilizar el cambio de zona de ARC de forma totalmente automática, puede activar el cambio de zona automático de ARC. Con el cambio de zona automático, puede depender de AWS para supervisar el estado de las AZ del clúster de EKS e iniciar un cambio de zona cuando se detecten daños en la AZ de manera automática.
**Qué ocurre si utilizo esta característica y mis nodos de trabajo y cargas de trabajo no están escaladas previamente?**
Si no ha escalado previamente y depende del aprovisionamiento de nodos o pods adicionales durante un cambio de zona, corre el riesgo de que la recuperación se retrase. El proceso de agregar nuevos nodos al plano de datos de EKS lleva algún tiempo, lo que puede afectar al rendimiento y la disponibilidad en tiempo real de las aplicaciones, especialmente si hay daños en una zona. Además, si se producen daños en una zona, es posible que se encuentre con una limitación de la capacidad de computación que impida agregar nuevos nodos necesarios a las AZ en buen estado.
Si sus cargas de trabajo no se han escalado previamente y no están distribuidas entre todas las AZ del clúster, los daños de una zona podrían afectar a la disponibilidad de una aplicación que solo se ejecuta en los nodos de trabajo de una AZ afectada. Para reducir el riesgo de una interrupción total de la disponibilidad de la aplicación, Amazon EKS dispone de un sistema de seguridad para que el tráfico se envíe a los puntos de conexión de los pods situados en una zona afectada, si esa carga de trabajo tiene todos sus puntos de conexión en una AZ en mal estado. Sin embargo, le recomendamos encarecidamente que escale previamente sus aplicaciones y las distribuya en todas las AZ para mantener la disponibilidad si se produce un problema en un zona.
**¿Cómo funciona si ejecuto una aplicación con estado?**
Si ejecuta una aplicación con estado, debe evaluar su tolerancia a errores en función del caso de uso y la arquitectura. Si tiene una arquitectura o un patrón, ya sea activo o en espera, es posible que haya instancias en las que el elemento activo se encuentre en una AZ dañada. En la aplicación, si el elemento en espera no se activa, es posible que tenga problemas con la aplicación. También es posible que tenga problemas cuando se lancen nuevos pods de Kubernetes en AZ en buen estado, ya que no se podrán conectar a los volúmenes persistentes enlazados a la AZ dañada.
**Funciona esta característica con Karpenter?**
Actualmente, Karpenter no es compatible con el cambio de zona y el cambio de zona automático de ARC en Amazon EKS. Si una AZ está dañada, para ajustar la configuración de NodePool de Karpenter correspondiente, puede eliminar la AZ en mal estado a fin de que los nuevos nodos de trabajo solo se lancen en las AZ en buen estado.
**Funciona esta característica con EKS Fargate?**
Esta característica no es compatible con EKS Fargate. De forma predeterminada, cuando EKS Fargate reconoce un evento de salud en una zona, los pods preferirán ejecutarse en las otras AZ.
**Amazon EKS afectará el plano de control de Kubernetes administrado?**
No, de manera predeterminada Amazon EKS ejecuta y escala el plano de control de Kubernetes en varias AZ para garantizar una alta disponibilidad. El cambio de zona y el cambio de zona automático de ARC solo actúan en el plano de datos de Kubernetes.
**Hay algún costo asociado a esta nueva característica?**
Puede utilizar el cambio de zona y el cambio de zona automático de ARC en su clúster de Amazon EKS sin ningún costo adicional. Sin embargo, continuará pagando por las instancias aprovisionadas y le recomendamos encarecidamente que escale previamente el plano de datos de Kubernetes antes de utilizar esta característica. Debe plantearse que haya un equilibrio entre el costo y la disponibilidad de la aplicación.
## Recursos adicionales
+ [Cómo funciona un cambio de zona](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.how-it-works.html)
+ [Prácticas recomendadas para los cambios de zona en ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/route53-arc-best-practices.zonal-shifts.html#zonalshift.route53-arc-best-practices.zonal-shifts)
+ [Recursos y acontecimientos compatibles con el cambio de zona y el cambio de zona automático](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.html)
+ [Operación de cargas de trabajo resilientes en Amazon EKS](https://aws.amazon.com/blogs/containers/operating-resilient-workloads-on-amazon-eks)
+ [Eliminación del retraso en el escalado de nodos de Kubernetes con la prioridad de los pods y el sobreaprovisionamiento](https://aws.amazon.com/blogs/containers/eliminate-kubernetes-node-scaling-lag-with-pod-priority-and-over-provisioning)
+ [Escalabilidad de los pods de CoredNS para un tráfico de DNS elevado](coredns-autoscaling.md)
# Activación del cambio de zona de EKS para evitar zonas de disponibilidad deterioradas
El Controlador de recuperación de aplicaciones de Amazon (ARC) le ayuda a administrar y coordinar la recuperación de sus aplicaciones en todas las zonas de disponibilidad (AZ) y funciona con muchos servicios, incluido Amazon EKS. Con la compatibilidad de EKS con el cambio de zona de ARC, puede alejar el tráfico de red dentro del clúster de una AZ afectada. También puede autorizar que AWS supervise el estado de sus zonas de disponibilidad y desvíe de forma temporal el tráfico de la red de una zona de disponibilidad en mal estado, en su nombre.
**Cómo se utiliza el cambio de zona de EKS:**
1. Habilite su clúster de EKS con el Controlador de recuperación de aplicaciones de Amazon (ARC). Esto se hace a nivel del clúster, mediante la consola de Amazon EKS, la AWS CLI, CloudFormation o eksctl.
1. Una vez activado, puede administrar los cambios de zona o los cambios de zona automáticos mediante la consola de ARC, la AWS CLI o las API de cambio de zona y cambio de zona automático.
Tenga en cuenta que después de registrar un clúster de EKS con ARC, aún debe configurar ARC. Por ejemplo, puede usar la consola de ARC para configurar el cambio de zona automático.
Para obtener información más detallada sobre cómo funciona el cambio de zona de EKS y cómo diseñar sus cargas de trabajo para administrar las zonas de disponibilidad dañadas, consulte [Información sobre el cambio de zona del Controlador de recuperación de aplicaciones de Amazon (ARC) en Amazon EKS](zone-shift.md).
## Consideraciones
+ El modo automático de EKS no es compatible con el controlador de recuperación de aplicaciones de Amazon, el cambio de zona ni con el cambio automático de zona.
+ Recomendamos esperar al menos 60 segundos entre las operaciones de cambio de zona para garantizar el procesamiento adecuado de cada solicitud.
Cuando intenta realizar cambios de zona en sucesión rápida (dentro de un intervalo de 60 segundos entre ellos), el servicio de Amazon EKS puede no procesar correctamente todas las solicitudes de cambio. Esto se debe al mecanismo de sondeo actual que actualiza el estado de zona del clúster. Si necesita realizar varios cambios de zona, asegúrese de que haya suficiente tiempo entre las operaciones para que el sistema procese cada cambio.
## ¿Qué es el controlador de recuperación de aplicaciones de Amazon?
El controlador de recuperación de aplicaciones de Amazon (ARC) lo ayuda a prepararse y realizar operaciones de recuperación más rápidas para las aplicaciones que se ejecutan en AWS. El cambio de zona permite recuperarse rápidamente de los problemas de la zona de disponibilidad (AZ), ya que desvían temporalmente el tráfico de un recurso compatible de una AZ a otra AZ en buen estado en la región de AWS.
[Obtenga más información sobre el Controlador de recuperación de aplicaciones de Amazon (ARC)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
## ¿Qué es el cambio de zona?
El cambio de zona es una capacidad de ARC que permite mover el tráfico de un recurso, como un clúster de EKS o un equilibrador de carga elástico, fuera de una zona de disponibilidad a una región de AWS para mitigar un problema y recuperar la aplicación de manera rápida. Puede optar por cambiar el tráfico, por ejemplo, si una implementación incorrecta provoca problemas de latencia o porque la zona de disponibilidad está deteriorada. Un cambio de zona no requiere pasos de configuración avanzados.
[Más información sobre el cambio de zona de ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.how-it-works.html)
## ¿Qué es el cambio de zona automático?
El cambio de zona automático es una función de ARC que se puede habilitar para autorizar que AWS traslade el tráfico de una zona de disponibilidad para recursos compatibles a zonas de disponibilidad en buen estado de la región AWS, en su nombre. AWS inicia un cambio automático cuando la telemetría interna indica que hay una alteración en una AZ de una región que podría afectar a los clientes. La telemetría interna incorpora métricas de varios orígenes, incluida la red de AWS y los servicios Amazon EC2 y Elastic Load Balancing.
AWS finaliza los cambios automáticos cuando los indicadores muestran que ya no hay ningún problema o potencial inconveniente.
[Más información sobre el cambio de zona automático de ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.how-it-works.html)
## ¿Qué hace el EKS durante un cambio automático?
EKS actualiza las configuraciones de red para evitar dirigir el tráfico a las zonas de disponibilidad deterioradas. Además, si se utilizan grupos de nodos administrados, EKS solo lanzará nuevos nodos en las AZ en buen estado durante un cambio de zona. Cuando el turno caduque o se cancele, las configuraciones de red se restaurarán para incluir la AZ que anteriormente se había detectado como defectuosa.
[Más información sobre el cambio de zona de Amazon EKS](zone-shift.md).
## Registre un clúster de EKS con el Controlador de recuperación de aplicaciones de Amazon (ARC) (consola de AWS)
1. Busque el nombre y la región del clúster de EKS que desea registrar con el ARC.
1. Navegue hasta la [consola de EKS](https://console.aws.amazon.com/eks) en esa región y seleccione su clúster.
1. Seleccione la pestaña **Información general** en la página **Información del clúster**.
1. En el encabezado **Cambio de zona**, seleccione el botón **Administrar**.
1. Seleccione **activar** o **desactivar** el *cambio de zona de EKS*.
Ahora su clúster EKS está registrado con ARC.
Si desea que AWS detecte y evite las zonas de disponibilidad deterioradas, debe configurar el cambio de zona automático de ARC. Por ejemplo, puede hacer esto en la consola de ARC.
## Siguientes pasos
+ Aprenda cómo [activar el cambio de zona automático](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.start-cancel.html).
+ Obtenga información sobre cómo [iniciar de forma manual un cambio de zona](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.start-cancel.html).