**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. # Implementación de Amazon EKS en las instalaciones con AWS Outposts Puede utilizar Amazon EKS para ejecutar aplicaciones de Kubernetes en las instalaciones con AWS Outposts. Puede implementar Amazon EKS en Outposts de las siguientes formas: + **Clústeres extendidos**: ejecute el plano de control de Kubernetes en una región de AWS y los nodos en su Outpost. + **Clústeres locales**: ejecute el plano de control de Kubernetes y nodos en el Outpost. Para ambas opciones de implementación, el plano de control de Kubernetes está completamente administrado por AWS. Puede usar las mismas API, herramientas y consola de Amazon EKS que usa en la nube para crear y ejecutar Amazon EKS en Outposts. En el siguiente diagrama, se muestran estas opciones de implementación. ![\[Opciones de implementación en un Outpost\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/outposts-deployment-options.png) ## Cuándo usar cada opción de implementación Tanto los clústeres locales como los extendidos son opciones de implementación de uso general y se pueden usar para una variedad de aplicaciones. Con los clústeres locales, puede ejecutar todo el clúster de Amazon EKS de forma local en Outposts. Esta opción puede mitigar el riesgo de tiempo de inactividad de las aplicaciones que puede resultar de la desconexión temporal de la red a la nube. Estas desconexiones de red pueden deberse a cortes de fibra o eventos climáticos. Dado que todo el clúster de Amazon EKS se ejecuta de forma local en Outposts, las aplicaciones permanecen disponibles. De esta manera, puede realizar operaciones de clúster durante las desconexiones de red a la nube. Para obtener más información, consulte [Preparación de los clústeres locales de Amazon EKS en AWS Outposts para las desconexiones de la red](eks-outposts-network-disconnects.md). Si le preocupa la calidad de la conexión de red de sus Outposts a la región de AWS principal y requiere una alta disponibilidad durante desconexiones de red, use la opción de implementación de clúster local. Los clústeres extendidos le permiten conservar la capacidad de su Outpost porque el plano de control de Kubernetes se ejecuta en la región de AWS principal. Esta puede ser la opción más adecuada si puede invertir en una conectividad de red confiable y redundante desde su Outpost hasta la región de AWS. La calidad de la conexión de red es fundamental para esta opción. La forma en que Kubernetes administra las desconexiones de red entre el plano de control de Kubernetes y los nodos puede provocar un tiempo de inactividad de la aplicación. Para obtener más información sobre el comportamiento de Kubernetes, consulte [Scheduling, Preemption, and Eviction](https://kubernetes.io/docs/concepts/scheduling-eviction/) en la documentación de Kubernetes. ## Comparación de las opciones de implementación En la siguiente tabla, se comparan las diferencias entre las dos opciones. | Característica | Clúster extendido | Clúster local | | --- | --- | --- | | Ubicación del plano de control de Kubernetes | Región de AWS | Outpost | | Cuenta del plano de control de Kubernetes | Cuenta de AWS | Su cuenta | | Disponibilidad regional | consulte [Service endpoints](https://docs.aws.amazon.com/general/latest/gr/eks.html#eks_region) | Este de EE. UU. (Ohio), Este de EE. UU. (Norte de Virginia), Oeste de EE. UU. (Norte de California), Oeste de EE. UU. (Oregón), Asia-Pacífico (Seúl), Asia-Pacífico (Singapur), Asia-Pacífico (Sídney), Asia-Pacífico (Tokio), Canadá (centro), Europa (Fráncfort), Europa (Irlanda), Europa (Londres), Medio Oriente (Baréin) y América del Sur (São Paulo). | | Versiones secundarias de Kubernetes | eks/latest/userguide/kubernetes-versions.html[Supported Amazon EKS versions,type="documentation"]. | eks/latest/userguide/kubernetes-versions.html[Supported Amazon EKS versions,type="documentation"]. | | Versiones de la plataforma | Consulte [Versiones de la plataforma de EKS](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html). | Consulte [Información sobre las versiones de la plataforma de Amazon EKS y Kubernetes para AWS Outposts](eks-outposts-platform-versions.md) | | Factores de forma de Outpost | Bastidores de Outpost | Bastidores de Outpost | | Interfaces de usuario | Consola de administración de AWS, AWS CLI, API de Amazon EKS, `eksctl`, AWS CloudFormation y Terraform | Consola de administración de AWS, AWS CLI, API de Amazon EKS, `eksctl`, AWS CloudFormation y Terraform | | Políticas administradas | [AmazonEKSClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy) y [Política administrada de AWS: AmazonEKSServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksservicerolepolicy) | [AmazonEKSLocalOutpostClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) y [Política administrada de AWS: AmazonEKSLocalOutpostServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy) | | VPC y subredes del clúster | Consulte [Requisitos de red de Amazon EKS para VPC y subredes](network-reqs.md) | Consulte [Creación de una VPC y subredes para clústeres de Amazon EKS en AWS Outposts](eks-outposts-vpc-subnet-requirements.md) | | Acceso al punto de conexión del clúster | Público o privado o ambos | Solo privada | | Autenticación del servidor de la API de Kubernetes | AWS Identity and Access Management (IAM) y OIDC | IAM y certificados `x.509` | | Tipos de nodos | Solo autoadministrado | Solo autoadministrado | | Tipos de computación de nodos | Amazon EC2 bajo demanda | Amazon EC2 bajo demanda | | Tipos de almacenamiento de nodos | `gp2` de Amazon EBS y SSD de NVMe local | `gp2` de Amazon EBS y SSD de NVMe local | | AMI optimizadas para Amazon EKS | Amazon Linux, Windows y Bottlerocket | Solo Amazon Linux | | Versiones de IP | Sólo `IPv4` | Sólo `IPv4` | | Complementos | Complementos de Amazon EKS o complementos autoadministrados | Solo complementos autoadministrados | | Interfaz de red de contenedores predeterminada | Complemento CNI de Amazon VPC para Kubernetes | Complemento CNI de Amazon VPC para Kubernetes | | Registros del plano de control de Kubernetes | Registros de Amazon CloudWatch | Registros de Amazon CloudWatch | | Equilibrio de carga | Utilice el [Controlador del equilibrador de carga de AWS](aws-load-balancer-controller.md) para aprovisionar solo equilibradores de carga de aplicación (no equilibradores de carga de red) | Utilice el [Controlador del equilibrador de carga de AWS](aws-load-balancer-controller.md) para aprovisionar solo equilibradores de carga de aplicación (no equilibradores de carga de red) | | Cifrado de sobre para secretos | Consulte [Cifrado de los secretos de Kubernetes con KMS en los clústeres existentes](enable-kms.md) | No compatible | | Roles de IAM para cuentas de servicio | Consulte [Roles de IAM para cuentas de servicio](iam-roles-for-service-accounts.md) | No compatible | | Solución de problemas | Consulte [Solución de problemas con los clústeres y nodos de Amazon EKS](troubleshooting.md) | Consulte [Solución de problemas de los clústeres locales de Amazon EKS en AWS Outposts](eks-outposts-troubleshooting.md) | **Topics** # Creación de los clústeres locales de Amazon EKS en AWS Outposts para obtener alta disponibilidad Puede utilizar clústeres locales para ejecutar todo su clúster de Amazon EKS de forma local en AWS Outposts. Esto ayuda a mitigar el riesgo de tiempo de inactividad de las aplicaciones que puede resultar de la desconexión temporal de la red a la nube. Estas desconexiones pueden deberse a cortes de fibra o eventos climáticos. Dado que todo el clúster de Kubernetes se ejecuta de forma local en Outposts, las aplicaciones permanecen disponibles. De esta manera, puede realizar operaciones de clúster durante las desconexiones de red a la nube. Para obtener más información, consulte [Preparación de los clústeres locales de Amazon EKS en AWS Outposts para las desconexiones de la red](eks-outposts-network-disconnects.md). En el siguiente diagrama, se muestra una implementación de clúster local. ![\[Clúster local de Outpost\]](http://docs.aws.amazon.com/es_es/eks/latest/userguide/images/outposts-local-cluster.png) Los clústeres locales suelen estar disponibles para su uso con los bastidores de Outposts. ## Regiones de AWS compatibles Puede crear clústeres locales en las siguientes regiones de AWS: Este de EE. UU. (Ohio), Este de EE. UU. (Norte de Virginia), Oeste de EE. UU. (Norte de California), Oeste de EE. UU. (Oregón), Asia-Pacífico (Seúl), Asia-Pacífico (Singapur), Asia-Pacífico (Sídney), Asia-Pacífico (Tokio), Canadá (centro), Europa (Fráncfort), Europa (Irlanda), Europa (Londres), Medio Oriente (Baréin) y América del Sur (São Paulo). Para obtener información detallada sobre las características admitidas, consulte [Comparación de las opciones de implementación](eks-outposts.md#outposts-overview-comparing-deployment-options). **Topics** # Implementación de un clúster de Amazon EKS en AWS Outposts En este tema, se proporciona información general sobre lo que debe tener en cuenta al ejecutar un clúster local en un Outpost. El tema también contiene instrucciones sobre cómo implementar un clúster local en un Outpost. **importante** Estas consideraciones no se replican en la documentación relacionada de Amazon EKS. Si otros temas de la documentación de Amazon EKS entran en conflicto con las consideraciones que se presentan aquí, siga las consideraciones que se indican a continuación. Estas consideraciones están sujetas a modificaciones y pueden cambiar con frecuencia. Por lo tanto, le recomendamos que revise este tema con regularidad. Muchas de las consideraciones son diferentes a las consideraciones para crear un clúster en la nube de AWS. + Los clústeres locales solo admiten bastidores de Outpost. Un único clúster local puede ejecutarse en varios bastidores de Outpost físicos que comprenden un único Outpost lógico. Un único clúster local no puede ejecutarse en varios Outposts lógicos. Cada Outpost lógico tiene un único ARN de Outpost. + Los clústeres locales ejecutan y administran el plano de control de Kubernetes en su cuenta en Outpost. No se pueden ejecutar cargas de trabajo en las instancias del plano de control de Kubernetes ni modificar los componentes del plano de control de Kubernetes. Estos nodos están administrados por el servicio de Amazon EKS. Los cambios en el plano de control de Kubernetes no persisten a través de las acciones de administración automáticas de Amazon EKS, como la aplicación de parches. + Los clústeres locales admiten complementos autoadministrados y grupos de nodos autoadministrados de Amazon Linux. El [complemento CNI de Amazon VPC para los complementos Kubernetes](managing-vpc-cni.md), [kube-proxy](managing-kube-proxy.md) y [CoreDNS](managing-coredns.md) se instala automáticamente en los clústeres locales. + Los clústeres locales requieren el uso de Amazon EBS en Outposts. Su Outpost debe tener Amazon EBS disponible para el almacenamiento del plano de control de Kubernetes. Los Outposts admiten únicamente volúmenes `gp2` de Amazon EBS. + Los `PersistentVolumes` de Kubernetes basadas en Amazon EBS se admiten mediante el controlador de CSI de Amazon EBS. + Las instancias del plano de control de los clústeres locales se configuran en [topología apilada de alta disponibilidad](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/). Dos de las tres instancias del plano de control deben estar en buen estado en todo momento para mantener el quórum. Si se pierde el quórum, contacte a soporte de AWS, ya que se requerirán algunas acciones del lado del servicio para habilitar las nuevas instancias administradas. **Requisitos previos** + Familiaridad con las [opciones de implementación de Outposts](eks-outposts.md#outposts-overview-comparing-deployment-options). [Seleccione los tipos de instancias y los grupos de ubicación para los clústeres de Amazon EKS en AWS Outposts en función de las consideraciones de capacidad](eks-outposts-capacity-considerations.md) y [los requisitos y las consideraciones de VPC](eks-outposts-vpc-subnet-requirements.md). + Un Outpost existente. Para obtener más información, consulte [¿Qué es AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)? + La herramienta de la línea de comandos de `kubectl` está instalada en su equipo 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 | 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 de usuarios 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 (usuario o rol) 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). Cuando se crea un clúster local de Amazon EKS, la [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que crea el clúster se agrega de manera permanente. La entidad principal de IAM se agrega específicamente a la tabla de autorizaciones RBAC de Kubernetes como administrador. Esta entidad tiene permisos `system:masters`. La identidad de esta entidad no está visible en la configuración del clúster. Por lo tanto, es importante anotar la entidad que creó el clúster y asegurarse de no eliminarlo nunca. Al principio, solo la entidad principal que creó el servidor puede hacer llamadas al servidor de la API de Kubernetes con `kubectl`. Si usa la consola para crear el clúster, debe asegurarse de que las mismas credenciales de IAM se encuentren en la cadena de credenciales del SDK de AWS al ejecutar comandos de `kubectl` en el clúster. Una vez que se crea el clúster, puede conceder acceso a su clúster a otras entidades principales de IAM. ## Creación de un clúster local de Amazon EKS Puede crear un clúster local con las siguientes herramientas que se describen en esta página: + [`eksctl`](#eksctl_create_cluster_outpost) + [Consola de administración de AWS](#console_create_cluster_outpost) También puede utilizar la [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/eks/create-cluster.html), la [API de Amazon EKS](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateCluster.html), los [AWS SDK](https://aws.amazon.com/developer/tools/), [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-eks-cluster-outpostconfig.html) o [Terraform](https://registry.terraform.io/modules/terraform-aws-modules/eks/aws/latest) para crear clústeres en Outposts. ### `eksctl` **Para crear un clúster con `eksctl` ** 1. Instale la versión `0.215.0` o posterior de la herramienta de línea de comandos de `eksctl` instalada en su dispositivo o AWS CloudShell. Para instalar o actualizar `eksctl`, consulte la sección de [Instalación](https://eksctl.io/installation) en la documentación de `eksctl`. 1. Copie los siguientes contenidos en su dispositivo. Reemplace los siguientes valores y, a continuación, ejecute el comando modificado para crear el archivo `outpost-control-plane.yaml`: + Reemplace *region-code* por la región de AWS [admitida](eks-outposts-local-cluster-overview.md#outposts-control-plane-supported-regions) 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. 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. 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 *vpc-ExampleID1* y *subnet-ExampleID1* con los ID de su VPC y subred existentes. La VPC y la subred deben cumplir los requisitos en [Creación de una VPC y subredes para clústeres de Amazon EKS en AWS Outposts](eks-outposts-vpc-subnet-requirements.md). + Reemplace *uniqueid* con el ID de su Outpost. + Reemplace *m5.large* con un tipo de instancia disponible en su Outpost. Antes de elegir un tipo de instancia, consulte [Seleccione los tipos de instancias y los grupos de ubicación para los clústeres de Amazon EKS en AWS en función de las consideraciones de capacidad](eks-outposts-capacity-considerations.md). Se implementan tres instancias del plano de control. No puede cambiar este número. ``` cat >outpost-control-plane.yaml < **Para crear el clúster con la Consola de administración de AWS ** 1. Necesita una VPC y subred existentes que cumplan con los requisitos de Amazon EKS. Para obtener más información, consulte [Creación de una VPC y subredes para clústeres de Amazon EKS en AWS Outposts](eks-outposts-vpc-subnet-requirements.md). 1. Si ya tiene un rol de IAM del clúster local 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": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` 1. Creación del rol de IAM del clúster de Amazon EKS. 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 myAmazonEKSLocalClusterRole --assume-role-policy-document file://"eks-local-cluster-role-trust-policy.json" ``` 1. Adjunte la política administrada de Amazon EKS con el nombre [AmazonEKSLocalOutPostClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostClusterPolicy.html) 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/AmazonEKSLocalOutpostClusterPolicy --role-name myAmazonEKSLocalClusterRole ``` 1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. En la parte superior de la pantalla de la consola, asegúrese de haber seleccionado una región de AWS [admitida](eks-outposts-local-cluster-overview.md#outposts-control-plane-supported-regions). 1. Elija **Agregar clúster** y, a continuación, elija **Crear**. 1. En la página **Configurar clúster**, rellene o seleccione los valores para los siguientes campos: + **Ubicación del plano de control de Kubernetes**: elija AWS Outposts. + **ID de Outpost**: elija el ID del Outpost en el que desea crear su plano de control. + **Tipo de instancia**: seleccione un tipo de instancia. Solo se muestran los tipos de instancias disponibles en su Outpost. En la lista desplegable, cada tipo de instancia describe para cuántos nodos se recomienda el tipo de instancia. Antes de elegir un tipo de instancia, consulte [Seleccione los tipos de instancias y los grupos de ubicación para los clústeres de Amazon EKS en AWS en función de las consideraciones de capacidad](eks-outposts-capacity-considerations.md). Todas las réplicas se implementan con el mismo tipo de instancia. Después de crear el clúster, no se puede cambiar el tipo de instancia. Se implementan tres instancias del plano de control. No puede cambiar este número. + **Nombre**: un nombre único para el clúster. Debe ser único en la cuenta de AWS. 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. 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. + **Versión de Kubernetes**: elija la versión de Kubernetes que desea utilizar para el clúster. Le recomendamos seleccionar la versión más reciente, a menos que necesite usar una versión anterior. + **Rol de servicio de clúster**: elija el rol de IAM del clúster de Amazon EKS que creó en un paso anterior para permitir que el plano de control de Kubernetes administre los recursos de AWS. + **Acceso de administrador del clúster de Kubernetes**: si desea que la entidad principal de IAM (rol o usuario) que está creando el clúster tenga acceso de administrador a los objetos de Kubernetes en el clúster, acepte la opción predeterminada (Permitir). Amazon EKS crea una entrada de acceso para la entidad principal de IAM y concede permisos de administrador de clúster a la entrada de acceso. Para obtener más información acerca de las entradas de acceso, consulte . [Concesión de acceso para los usuarios de IAM a las entradas de acceso de Kubernetes con EKS](access-entries.md). Si desea que una entidad principal de IAM diferente a la entidad principal que creó el clúster tenga acceso de administrador a los objetos del clúster de Kubernetes, seleccione la opción No permitir. Después de crear el clúster, cualquier entidad principal de IAM que tenga permisos de IAM para crear entradas de acceso puede agregar una entrada de acceso para cualquier entidad principal de IAM que necesite acceder a los objetos del clúster de Kubernetes. Para obtener más información sobre los permisos necesarios de IAM, consulte [Acciones definidas por Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) en la Referencia de autorización de servicios. Si elige la opción No permitir y no crea ninguna entrada de acceso, ninguna entidad principal de IAM tendrá acceso a los objetos del clúster de Kubernetes. + **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. La VPC debe tener un número suficiente de direcciones IP disponibles para el clúster, los nodos y otros recursos de Kubernetes que desee crear. La VPC debe cumplir los [Requisitos y consideraciones de la VPC](eks-outposts-vpc-subnet-requirements.md#outposts-vpc-requirements). + **Subredes**: de forma predeterminada, se preseleccionan todas las subredes disponibles de la VPC especificada en el campo anterior. Las subredes que elija deben cumplir los [Requisitos y consideraciones de las subredes](eks-outposts-vpc-subnet-requirements.md#outposts-subnet-requirements). + **Grupos de seguridad**: (opcional) especifique uno o varios grupos de seguridad que desea que Amazon EKS asocie a las interfaces de red que crea. Amazon EKS crea automáticamente un grupo de seguridad que habilita 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 elige agregar sus propios grupos de seguridad, no puede cambiar los que elija tras la creación del clúster. Para que los hosts en las instalaciones se comuniquen con el punto de conexión del clúster, debe permitir el tráfico saliente desde el grupo de seguridad del clúster. Para los clústeres que no tienen una conexión a Internet de entrada y salida (también conocidos como clústeres privados), debe realizar una de las siguientes acciones: + Agregue el grupo de seguridad asociado a los puntos de conexión de VPC requeridos. Para obtener más información acerca de los puntos de conexión requeridos, consulte [Uso de los puntos de conexión de VPC de interfaz](eks-outposts-vpc-subnet-requirements.md#vpc-subnet-requirements-vpc-endpoints) en [Acceso de subred a los servicios de AWS](eks-outposts-vpc-subnet-requirements.md#subnet-access-to-services). + Modifique el grupo de seguridad que creó Amazon EKS para permitir el tráfico del grupo de seguridad asociado a los puntos de conexión de VPC. Cuando haya terminado con esta página, seleccione **Siguiente**. 1. En la página **Configurar observabilidad**, si lo desea, puede elegir qué opciones de **métricas** y **registro de plano 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 **Revisar y crear**, revise la información que introdujo o seleccionó en las páginas anteriores. Si necesita realizar cambios, seleccione **Edit** (Editar). Cuando esté satisfecho, seleccione **Crear**. El campo **Estado** muestra **CREANDO** mientras se aprovisiona el clúster. El aprovisionamiento de clústeres tarda varios minutos. ## Visualización del clúster local de Amazon EKS 1. Una vez creado el clúster, puede ver las instancias del plano de control de Amazon EC2 que se crearon. ``` aws ec2 describe-instances --query 'Reservations[*].Instances[*].{Name:Tags[?Key==`Name`]|[0].Value}' | grep my-cluster-control-plane ``` Un ejemplo de salida sería el siguiente. ``` "Name": "my-cluster-control-plane-id1" "Name": "my-cluster-control-plane-id2" "Name": "my-cluster-control-plane-id3" ``` Cada instancia tiene un taint `node-role.eks-local.amazonaws.com/control-plane` aplicado, de modo que nunca se programen cargas de trabajo en las instancias del plano de control. Para obtener más información sobre las taints, consulte [Taints and Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) en la documentación de Kubernetes. Amazon EKS supervisa continuamente el estado de los clústeres locales. Realizamos acciones de administración automáticas, como la aplicación de parches de seguridad y la reparación de instancias en mal estado. Cuando los clústeres locales se desconectan de la nube, realizamos acciones para garantizar que el clúster vuelva a un buen estado al volver a conectarse. 1. Si ha creado el clúster mediante `eksctl`, puede omitir este paso. `eksctl` completa este paso. Habilite `kubectl` para comunicarse con el clúster agregando un nuevo contexto al archivo `kubectl` `config`. Para obtener instrucciones 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. Para conectarse al servidor de API de Kubernetes de su clúster local, debe tener acceso a la puerta de enlace local de la subred o conectarse desde la VPC. Para obtener más información acerca de la conexión de un bastidor de Outpost a su red en las instalaciones, consulte [Cómo funcionan las puertas de enlace locales para bastidores](https://docs.aws.amazon.com/outposts/latest/userguide/how-racks-work.html) en la Guía del usuario de AWS Outposts. Si usa el enrutamiento directo de VPC y la subred de Outpost tiene una ruta a la puerta de enlace local, las direcciones IP privadas de las instancias del plano de control de Kubernetes se transmiten automáticamente a través de la red local. El punto de conexión del servidor de la API de Kubernetes del clúster local está alojado en Amazon Route 53 (Route 53). Los servidores de DNS públicos pueden resolver el punto de conexión del servicio de API en las direcciones IP privadas de los servidores de la API de Kubernetes. Las instancias del plano de control de Kubernetes de los clústeres locales se configuran con interfaces de red elásticas estáticas con direcciones IP privadas fijas que no cambian a lo largo del ciclo de vida del clúster. Es posible que las máquinas que interactúan con el servidor de la API de Kubernetes no tengan conectividad con Route 53 durante desconexiones de red. Si este es el caso, recomendamos configurar `/etc/hosts` con las direcciones IP privadas estáticas para continuar con las operaciones. También recomendamos configurar servidores de DNS locales y conectarlos a su Outpost. Para obtener más información, consulte la [documentación de AWSOutposts](https://docs.aws.amazon.com/outposts/latest/userguide/how-outposts-works.html#dns). Ejecute el siguiente comando para confirmar que se ha establecido la comunicación con el clúster. ``` 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 ``` 1. (Opcional) Pruebe la autenticación en su clúster local cuando se encuentra desconectado de la nube de AWS. Para obtener instrucciones, consulte [Preparación de los clústeres locales de Amazon EKS en AWS Outposts para las desconexiones de la red](eks-outposts-network-disconnects.md). ### Recursos internos Amazon EKS crea los siguientes recursos en su clúster. Los recursos son para uso interno de Amazon EKS. Para que el clúster funcione correctamente, no edite ni modifique estos recursos. + Los siguientes [pods de reflejo](https://kubernetes.io/docs/reference/glossary/?all=true#term-mirror-pod): + `aws-iam-authenticator-node-hostname ` + `eks-certificates-controller-node-hostname ` + `etcd-node-hostname ` + `kube-apiserver-node-hostname ` + `kube-controller-manager-node-hostname ` + `kube-scheduler-node-hostname ` + Los siguientes complementos autoadministrados: + `kube-system/coredns` + `kube-system/` `kube-proxy` (no se crean hasta que agregue su primer nodo) + `kube-system/aws-node` (no se crea hasta que agregue su primer nodo). Los clústeres locales usan el complemento CNI de Amazon VPC para Kubernetes para redes de clústeres. No cambie la configuración de las instancias del plano de control (pods denominados `aws-node-controlplane-*`). Hay variables de configuración que puede usar para cambiar el valor predeterminado para cuando el complemento crea interfaces de red nuevas. Para obtener más información, consulte la [documentación](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md) en GitHub. + Los siguientes servicios: + `default/kubernetes` + `kube-system/kube-dns` + Una `PodSecurityPolicy` denominada `eks.system` + Una `ClusterRole` denominada `eks:system:podsecuritypolicy` + Una `ClusterRoleBinding` denominada `eks:system` + Además del [grupo de seguridad del clúster](sec-group-reqs.md), Amazon EKS crea un grupo de seguridad en su cuenta de AWS llamado `eks-local-internal-do-not-use-or-edit-cluster-name-uniqueid `. Este grupo de seguridad permite que el tráfico fluya libremente entre los componentes de Kubernetes que se ejecutan en las instancias del plano de control. Siguientes pasos recomendados: + [Conceda a la entidad principal de IAM que creó el clúster los permisos necesarios para ver los recursos de Kubernetes en la Consola de administración de AWS](view-kubernetes-resources.md#view-kubernetes-resources-permissions) + [Conceda acceso a las entidades de IAM al clúster](grant-k8s-access.md). Si desea que las entidades vean los recursos de Kubernetes en la consola de Amazon EKS, conceda los [Permisos requeridos](view-kubernetes-resources.md#view-kubernetes-resources-permissions) a las entidades. + [Configure el registro para el clúster](control-plane-logs.md) + Familiarícese con lo que sucede durante las [desconexiones de red](eks-outposts-network-disconnects.md). + [Agregue nodos al clúster](eks-outposts-self-managed-nodes.md) + Considere la posibilidad de configurar un plan de copia de seguridad para su `etcd`. Amazon EKS no admite la copia de seguridad ni la restauración automatizadas de `etcd` para clústeres locales. Para obtener más información, consulte [Backing up an etcd cluster](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) en la documentación de Kubernetes. Las dos opciones principales son usar `etcdctl` para automatizar la toma de instantáneas o usar la copia de seguridad del volumen de almacenamiento de Amazon EBS. # Información sobre las versiones de la plataforma de Amazon EKS y Kubernetes para AWS Outposts Las versiones de la plataforma de clúster local representan las capacidades del clúster de Amazon EKS en AWS Outposts. Las versiones incluyen los componentes que se ejecutan en el plano de control de Kubernetes, cuyos indicadores del servidor de la API de Kubernetes están habilitados. También incluyen la versión del parche de Kubernetes actual. Cada versión secundaria de Kubernetes tiene una o varias versiones de la plataforma de asociados. Las versiones de la plataforma para las diferentes versiones secundarias de Kubernetes son independientes. Las versiones de plataforma para los clústeres locales y los clústeres de Amazon EKS en la nube son independientes. Cuando está disponible una nueva versión secundaria de Kubernetes para clústeres locales, como `1.31`, la versión inicial de la plataforma para esa versión secundaria de Kubernetes comienza con `eks-local-outposts.1`. Sin embargo, Amazon EKS lanza nuevas versiones de la plataforma de forma periódica para habilitar nuevos ajustes de plano de control de Kubernetes y proporcionar revisiones de seguridad. Cuando están disponibles nuevas versiones de la plataforma de clústeres locales para una versión secundaria: + El número de versión de la plataforma se incrementa (`eks-local-outposts.n+1`). + Amazon EKS actualiza automáticamente todos los clústeres locales existentes a la última versión de la plataforma para su versión secundaria de Kubernetes correspondiente. Las actualizaciones automáticas de las versiones de la plataforma existentes se implementan de forma incremental. El proceso de implementación consiste en reemplazar las instancias administradas del plano de control de Kubernetes que se ejecutan en el Outpost, una a la vez, hasta que las tres instancias se sustituyan por otras nuevas. + El proceso de reemplazo de instancias del plano de control de Kubernetes dejará de avanzar si existe el riesgo de que se interrumpa el servicio. Amazon EKS solo intentará reemplazar una instancia si las otras dos instancias del plano de control de Kubernetes estén en buen estado y cumplen todas las condiciones de preparación como un nodo de clúster. + Por lo general, el lanzamiento de una versión de la plataforma tarda menos de 30 minutos en completarse. Si el estado de un clúster es `UPDATING` durante un periodo prolongado, consulte [Solución de problemas de los clústeres locales de Amazon EKS en AWS Outposts](eks-outposts-troubleshooting.md) y busque ayuda de AWS Support. Nunca cancele manualmente las instancias del plano de control de Kubernetes a menos que AWS Support se lo indique. + Amazon EKS puede publicar una nueva AMI de nodo con la versión de parche correspondiente. Todas las versiones de parche son compatibles entre el plano de control de Kubernetes y las AMI de nodo para una única versión secundaria de Kubernetes. Las nuevas versiones de la plataforma no introducen cambios bruscos ni provocan interrupciones de servicio. Los clústeres locales siempre se crean con la última versión de la plataforma disponible (`eks-local-outposts.n`) para la versión de Kubernetes especificada. Las versiones de la plataforma actuales y recientes se describen en las siguientes tablas. Para recibir notificaciones de todos los cambios en el archivo de origen de esta página de documentación específica, puede suscribirse a la siguiente URL con un lector de RSS: ``` https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/outposts/eks-outposts-platform-versions.adoc.atom ``` ## Versión  de Kubernetes `1.31` Los siguientes controladores de admisión están habilitados para todas las versiones de plataforma `1.31`: `CertificateApproval`, `CertificateSigning`, `CertificateSubjectRestriction`, `ClusterTrustBundleAttest`, `DefaultIngressClass`, `DefaultStorageClass`, `DefaultTolerationSeconds`, `ExtendedResourceToleration`, `LimitRanger`, `MutatingAdmissionWebhook`, `NamespaceLifecycle`, `NodeRestriction`, `PersistentVolumeClaimResize`, `PodSecurity`, `Priority`, `ResourceQuota`, `RuntimeClass`, `ServiceAccount`, `StorageObjectInUseProtection`, `TaintNodesByCondition`, `ValidatingAdmissionPolicy` y `ValidatingAdmissionWebhook`. | Versión de Kubernetes | Versión de la plataforma de Amazon EKS | Notas de la versión | Fecha de lanzamiento de la nueva versión | | --- | --- | --- | --- | | `1.31.14` | `eks-local-outposts.8` | Nueva versión de la plataforma con mejoras y correcciones de seguridad kube-proxy actualizada a `v1.31.14`. AWS Autenticador de IAM actualizado a `v0.7.8`. Se actualizó el complemento CNI de Amazon VPC para Kubernetes a `v1.20.4`. Se actualizó la versión de Bottlerocket a la `v1.52.0`. | 23 de diciembre de 2025 | | `1.31.12` | `eks-local-outposts.5` | Nueva versión de la plataforma con mejoras y correcciones de seguridad kube-proxy actualizada a `v1.31.10`. AWS Autenticador de IAM actualizado a `v0.7.4`. Se actualizó el complemento CNI de Amazon VPC para Kubernetes a `v1.20.2`. Se actualizó la versión de Bottlerocket a la `v1.47.0`. | 3 de octubre de 2025 | | `1.31.9` | `eks-local-outposts.4` | Nueva versión de la plataforma con mejoras y correcciones de seguridad kube-proxy actualizada a `v1.31.9`. AWS Autenticador de IAM actualizado a `v0.7.2`. Se ha actualizado el complemento CNI de Amazon VPC para Kubernetes a la versión `v1.20.0`. Se ha actualizado la versión de Bottlerocket a `v1.43.0`. | 9 de agosto de 2025 | | `1.31.7` | `eks-local-outposts.3` | Nueva versión de la plataforma con mejoras y correcciones de seguridad kube-proxy actualizada a `v1.31.9`. AWS Autenticador de IAM actualizado a `v0.7.1`. Se actualizó el complemento CNI de Amazon VPC para Kubernetes a `v1.19.5`. Se actualizó la versión de Bottlerocket a la `v1.40.0`. | 19 de junio de 2025 | | `1.31.6` | `eks-local-outposts.2` | Nueva versión de la plataforma con mejoras y correcciones de seguridad. Se actualizó la versión de Bottlerocket a la `v1.36.0`. | 24 de abril de 2025 | | `1.31.6` | `eks-local-outposts.1` | Lanzamiento inicial de la versión `v1.31` de Kubernetes para los clústeres locales de Amazon EKS en Outposts. | 9 de abril de 2025 | ## Versión  de Kubernetes `1.30` Los siguientes controladores de admisión están habilitados para todas las versiones de plataforma `1.30`: `CertificateApproval`, `CertificateSigning`, `CertificateSubjectRestriction`, `ClusterTrustBundleAttest`, `DefaultIngressClass`, `DefaultStorageClass`, `DefaultTolerationSeconds`, `ExtendedResourceToleration`, `LimitRanger`, `MutatingAdmissionWebhook`, `NamespaceLifecycle`, `NodeRestriction`, `PersistentVolumeClaimResize`, `PodSecurity`, `Priority`, `ResourceQuota`, `RuntimeClass`, `ServiceAccount`, `StorageObjectInUseProtection`, `TaintNodesByCondition`, `ValidatingAdmissionPolicy` y `ValidatingAdmissionWebhook`. | Versión de Kubernetes | Versión de la plataforma de Amazon EKS | Notas de la versión | Fecha de lanzamiento de la nueva versión | | --- | --- | --- | --- | | `1.30.14` | `eks-local-outposts.10` | Nueva versión de la plataforma con mejoras y correcciones de seguridad. AWS Autenticador de IAM actualizado a `v0.7.8`. Se actualizó el complemento CNI de Amazon VPC para Kubernetes a `v1.20.4`. Se actualizó la versión de Bottlerocket a la `v1.52.0`. | 23 de diciembre de 2025 | | `1.30.14` | `eks-local-outposts.7` | Nueva versión de la plataforma con mejoras y correcciones de seguridad kube-proxy actualizada a `v1.30.14`. AWS Autenticador de IAM actualizado a `v0.7.4`. Se actualizó el complemento CNI de Amazon VPC para Kubernetes a `v1.20.2`. Se actualizó la versión de Bottlerocket a la `v1.47.0`. | 3 de octubre de 2025 | | `1.30.13` | `eks-local-outposts.6` | Nueva versión de la plataforma con mejoras y correcciones de seguridad kube-proxy actualizada a `v1.30.13`. AWS Autenticador de IAM actualizado a `v0.7.2`. Se actualizó el complemento CNI de Amazon VPC para Kubernetes a `v1.20.0`. Se actualizó la versión de Bottlerocket a la `v1.43.0`. | 09 de agosto de 2025 | | `1.30.11` | `eks-local-outposts.5` | Nueva versión de la plataforma con mejoras y correcciones de seguridad kube-proxy actualizada a `v1.30.11`. AWS Autenticador de IAM actualizado a `v0.7.1`. Se ha actualizado el complemento CNI de Amazon VPC para Kubernetes a la versión `v1.19.5`. Se ha actualizado la versión de Bottlerocket a `v1.40.0`. | 19 de junio de 2025 | | `1.30.10` | `eks-local-outposts.4` | Nueva versión de la plataforma con mejoras y correcciones de seguridad. Se actualizó la versión de Bottlerocket a la `v1.36.0`. | 24 de abril de 2025 | | `1.30.10` | `eks-local-outposts.3` | Nueva versión de la plataforma con mejoras y correcciones de seguridad kube-proxy actualizada a `v1.30.10`. AWS Autenticador de IAM actualizado a `v0.6.29`. Se actualizó el complemento CNI de Amazon VPC para Kubernetes a `v1.19.2`. Se actualizó CoreDNS a `v1.11.4`. AWS Se actualizó el administrador de controladores en la nube a `v1.30.8`. Se actualizó la versión de Bottlerocket a la `v1.34.0`. | 27 de marzo de 2025 | | `1.30.7` | `eks-local-outposts.2` | Nueva versión de la plataforma con mejoras y correcciones de seguridad kube-proxy actualizada a `v1.30.7`. AWS Autenticador de IAM actualizado a `v0.6.28`. Se actualizó el complemento CNI de Amazon VPC para Kubernetes a `v1.19.0`. Se actualizó la versión de Bottlerocket a la `v1.29.0`. | 10 de enero de 2025 | | `1.30.5` | `eks-local-outposts.1` | Lanzamiento inicial de la versión `v1.30` de Kubernetes para los clústeres locales de Amazon EKS en Outposts. | 13 de noviembre de 2024 | ## Versión  de Kubernetes `1.29` Los siguientes controladores de admisión están habilitados para todas las versiones de plataforma `1.29`: `CertificateApproval`, `CertificateSigning`, `CertificateSubjectRestriction`, `ClusterTrustBundleAttest`, `DefaultIngressClass`, `DefaultStorageClass`, `DefaultTolerationSeconds`, `ExtendedResourceToleration`, `LimitRanger`, `MutatingAdmissionWebhook`, `NamespaceLifecycle`, `NodeRestriction`, `PersistentVolumeClaimResize`, `PodSecurity`, `Priority`, `ResourceQuota`, `RuntimeClass`, `ServiceAccount`, `StorageObjectInUseProtection`, `TaintNodesByCondition`, `ValidatingAdmissionPolicy` y `ValidatingAdmissionWebhook`. | Versión de Kubernetes | Versión de la plataforma de Amazon EKS | Notas de la versión | Fecha de lanzamiento de la nueva versión | | --- | --- | --- | --- | | `1.29.15` | `eks-local-outposts.13` | Nueva versión de la plataforma con mejoras y correcciones de seguridad. AWS Autenticador de IAM actualizado a `v0.7.8`. Se actualizó el complemento CNI de Amazon VPC para Kubernetes a `v1.20.4`. Se actualizó la versión de Bottlerocket a la `v1.52.0`. | 23 de diciembre de 2025 | | `v1.29.15` | `eks-local-outposts.10` | Nueva versión de la plataforma con mejoras y correcciones de seguridad. AWS Autenticador de IAM actualizado a `v0.7.4`. Se actualizó el complemento CNI de Amazon VPC para Kubernetes a `v1.20.2`. Se actualizó la versión de Bottlerocket a la `v1.47.0`. | 3 de octubre de 2025 | | `v1.29.15` | `eks-local-outposts.9` | Nueva versión de la plataforma con mejoras y correcciones de seguridad. AWS Autenticador de IAM actualizado a `v0.7.2`. Se actualizó el complemento CNI de Amazon VPC para Kubernetes a `v1.20.0`. Se actualizó la versión de Bottlerocket a la `v1.43.0`. | 9 de agosto de 2025 | | `v1.29.15` | `eks-local-outposts.8` | Nueva versión de la plataforma con mejoras y correcciones de seguridad kube-proxy actualizada a `v1.29.15`. AWS Autenticador de IAM actualizado a `v0.7.1`. Se actualizó el complemento CNI de Amazon VPC para Kubernetes a `v1.19.5`. Se actualizó la versión de Bottlerocket a la `v1.40.0`. | 19 de junio de 2025 | | `v1.29.14` | `eks-local-outposts.7` | Nueva versión de la plataforma con mejoras y correcciones de seguridad. Se actualizó la versión de Bottlerocket a la `v1.36.0`. | 24 de marzo de 2025 | | `v1.29.14` | `eks-local-outposts.6` | Nueva versión de la plataforma con mejoras y correcciones de seguridad kube-proxy actualizada a `v1.29.14`. Se actualizó el complemento CNI de Amazon VPC para Kubernetes a `v1.19.2`. Se actualizó CoreDNS a `v1.11.4`. AWS Se actualizó el administrador de controladores en la nube a `v1.29.8`. Se actualizó la versión de Bottlerocket a la `v1.34.0`. | 27 de marzo de 2025 | | `v1.29.11` | `eks-local-outposts.5` | Nueva versión de la plataforma con mejoras y correcciones de seguridad kube-proxy actualizada a `v1.29.11`. Se actualizó el complemento CNI de Amazon VPC para Kubernetes a `v1.19.0`. Se actualizó la imagen de CoreDNS a `v1.11.3`. Se actualizó la versión de Bottlerocket a la `v1.29.0`. | 10 de enero de 2025 | | `1.29.9` | `eks-local-outposts.4` | Nueva versión de la plataforma con mejoras y correcciones de seguridad kube-proxy actualizada a `v1.29.9`. AWS Autenticador de IAM actualizado a `v0.6.26`. Se actualizó la versión de Bottlerocket a la `v1.26.0`. | 8 de noviembre de 2024 | | `1.29.6` | `eks-local-outposts.3` | Nueva versión de la plataforma con mejoras y correcciones de seguridad. Se actualizó la versión de Bottlerocket a la `v1.22.0`. | 22 de octubre de 2024 | | `1.29.6` | `eks-local-outposts.2` | Nueva versión de la plataforma con mejoras y correcciones de seguridad. Se actualizó la versión de Bottlerocket a la `v1.21.0`. | 27 de agosto de 2024 | | `1.29.6` | `eks-local-outposts.1` | Lanzamiento inicial de la versión `v1.29` de Kubernetes para los clústeres locales de Amazon EKS en Outposts. | 20 de agosto de 2024 | # Creación de una VPC y subredes para clústeres de Amazon EKS en AWS Outposts Al crear un clúster local, especifica una VPC y al menos una subred privada que se ejecuta en Outposts. En este tema, se proporciona una descripción general de los requisitos y las consideraciones de la VPC y las subredes para el clúster local. ## Requisitos y consideraciones de la VPC Al crear un clúster local, la VPC que especifique debe cumplir los siguientes requisitos y consideraciones: + Asegúrese de que la VPC tenga suficientes direcciones IP para el clúster local, los nodos y otros recursos de Kubernetes que desee crear. Si la VPC que desea utilizar no tiene suficientes direcciones IP, aumente el número de direcciones IP disponibles. Puede hacerlo [asociando bloques adicionales de enrutamiento entre dominios sin clase (CIDR)](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#add-ipv4-cidr) con su VPC. Puede asociar bloques de CIDR privados (RFC 1918) y públicos (no RFC 1918) a su VPC antes o después de crear el clúster. Un clúster puede tardar hasta cinco horas en reconocer un bloque de CIDR asociado a una VPC. + La VPC no puede tener prefijos IP ni bloques de CIDR IPv6 asignados. Debido a estas restricciones, la información incluida en [Asignación de más direcciones IP a los nodos de Amazon EKS con prefijos](cni-increase-ip-addresses.md) y [Información sobre la asignación de direcciones IPv6 a clústeres, pods y servicios](cni-ipv6.md) no aplica a su VPC. + La VPC tiene un nombre de host de DNS y la resolución de DNS habilitados. Sin estas características, se produce un error en la creación del clúster local y tendrá que habilitarlas y volver a crear el clúster. A fin de obtener más información, consulte [Atributos de DNS para su VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) en la Guía del usuario de Amazon VPC. + Para acceder al clúster local a través de la red local, la VPC debe estar asociada a la tabla de enrutamiento de la puerta de enlace local del Outpost. Para obtener más información, consulte [Asociaciones de la VPC](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-local-gateways.html#vpc-associations) en la Guía del usuario de AWS Outposts. ## Requisitos y consideraciones de la subred Debe especificar al menos una subred privada al crear el clúster. Si especifica más de una subred, las instancias del plano de control de Kubernetes se distribuyen de manera uniforme en las subredes. Si se especifica más de una subred, las subredes deben existir en el mismo Outpost. Además, las subredes también deben tener las rutas y los permisos de grupos de seguridad adecuados para comunicarse entre sí. Las subredes que especifique al crear un clúster local deben cumplir los siguientes requisitos: + Todas las subredes están en el mismo Outpost lógico. + En conjunto, las subredes tienen al menos tres direcciones IP disponibles para las instancias del plano de control de Kubernetes. Si se especifican tres subredes, cada subred debe tener al menos una dirección IP disponible. Si se especifican dos subredes, cada subred debe tener al menos dos direcciones IP disponibles. Si se especifica una subred, la subred debe tener al menos tres direcciones IP disponibles. + Las subredes tienen una ruta a la [puerta de enlace local](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-local-gateways.html) del bastidor del Outpost para acceder al servidor de la API de Kubernetes a través de su red local. Si las subredes no tienen una ruta a la puerta de enlace local del bastidor del Outpost, debe comunicarse con su servidor de la API de Kubernetes desde dentro de la VPC. + Las subredes deben utilizar nombres basados en direcciones IP. La [nomenclatura basada en recursos](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-naming.html#instance-naming-rbn) de Amazon EC2 no es compatible con Amazon EKS. ## Acceso a los servicios de AWS de la subred Las subredes privadas del clúster local en Outposts deben poder comunicarse con los servicios de AWS regionales. Para ello, puede utilizar una [puerta de enlace NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) para el acceso saliente a Internet o, si desea mantener la privacidad de todo el tráfico dentro de su VPC, mediante los [puntos de conexión de la interfaz de la VPC](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html). ### Uso de una puerta de enlace NAT Las subredes privadas del clúster local en Outposts deben tener una tabla de enrutamiento asociada con una ruta a una puerta de enlace NAT en una subred pública en la zona de disponibilidad principal del Outpost. La subred pública debe tener una ruta hacia una [puerta de enlace de Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html). La puerta de enlace NAT permite el acceso a Internet saliente y evita las conexiones entrantes no solicitadas desde Internet hacia las instancias del Outpost. ### Uso de los puntos de conexión de VPC de interfaz Si las subredes privadas del clúster local en Outposts no tienen una conexión a Internet de salida o si desea mantener todo el tráfico privado dentro de su VPC, debe crear los siguientes puntos de conexión de VPC de interfaz y un [punto de conexión de puerta de enlace](https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html) en una subred regional antes de crear el clúster. | Punto de conexión | Tipo de punto de conexión | | --- | --- | | `com.amazonaws.region-code.ssm` | Interfaz | | `com.amazonaws.region-code.ssmmessages` | Interfaz | | `com.amazonaws.region-code.ec2messages` | Interfaz | | `com.amazonaws.region-code.ec2` | Interfaz | | `com.amazonaws.region-code.secretsmanager` | Interfaz | | `com.amazonaws.region-code.logs` | Interfaz | | `com.amazonaws.region-code.sts` | Interfaz | | `com.amazonaws.region-code.ecr.api` | Interfaz | | `com.amazonaws.region-code.ecr.dkr` | Interfaz | | `com.amazonaws.region-code.s3` | Puerta de enlace | Los puntos de conexión debe cumplir los siguientes requisitos: + Deben crearse en una subred privada ubicada en la zona de disponibilidad principal de su Outpost + Deben tener habilitados los nombres de DNS privados + Deben tener un grupo de seguridad adjunto que permita el tráfico HTTPS entrante desde el rango CIDR de la subred de Outpost privada. La creación de puntos de conexión incurre en costos. Para obtener más información, consulte [Precios de AWS PrivateLink](https://aws.amazon.com/privatelink/pricing/). Si sus pods necesitan acceso a otros servicios de AWS, debe crear puntos de conexión adicionales. Para obtener una lista completa de 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). ## Creación de una VPC Puede crear una VPC que cumpla los requisitos anteriores mediante una de las siguientes plantillas de AWS CloudFormation: + **[Plantilla 1](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-09-20/amazon-eks-local-outposts-vpc-subnet.yaml)**: esta plantilla crea una VPC con una subred privada en el Outpost y una subred pública en la región de AWS. La subred privada tiene una ruta a Internet a través de una puerta de enlace NAT que reside en la subred pública de la región de AWS. Esta plantilla se puede usar para crear un clúster local en una subred con acceso a Internet de salida. + **[Plantilla 2](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2023-03-20/amazon-eks-local-outposts-fully-private-vpc-subnet.yaml)**: esta plantilla crea una VPC con una subred privada en el Outpost y el conjunto mínimo de puntos de conexión de VPC necesarios para crear un clúster local en una subred que no tenga acceso a Internet de entrada o salida (también denominada subred privada). # Preparación de los clústeres locales de Amazon EKS en AWS Outposts para las desconexiones de la red Puede seguir usando su clúster local de Amazon EKS en un Outpost si su red local ha perdido la conectividad con la nube de AWS. En este tema, se explica cómo preparar el clúster local para las desconexiones de red y las consideraciones relacionadas. + Los clústeres locales permiten la estabilidad y las operaciones continuas durante las desconexiones de red temporales e imprevistas. AWS Outposts sigue siendo una oferta completamente conectada que funciona como una extensión de la nube de AWS en su centro de datos. En caso de que la red se desconecte entre su Outpost y la nube de AWS, le recomendamos que intente restablecer la conexión. Para obtener instrucciones, consulte [lista de verificación para la solución de problemas de red de los bastidores de AWS](https://docs.aws.amazon.com/outposts/latest/userguide/network-troubleshoot.html) en la * Guía del usuario de AWS Outposts*. Para obtener más información acerca de cómo solucionar problemas de los clústeres locales, consulte [Solución de problemas de los clústeres locales de Amazon EKS en AWS Outposts](eks-outposts-troubleshooting.md). + Los Outposts emiten una métrica `ConnectedStatus` que puede usar para supervisar el estado de conectividad de su Outpost. Para obtener más información, consulte [Métricas de Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-cloudwatch-metrics.html#outposts-metrics) en la *Guía del usuario de AWS Outposts*. + Los clústeres locales utilizan IAM como mecanismo de autenticación predeterminado mediante el [Autenticador de AWS Identity and Access Management para Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator). IAM no está disponible durante las desconexiones de red. Entonces, los clústeres locales admiten un mecanismo de autenticación alternativo mediante certificados `x.509` que puede usar para conectarse a su clúster durante las desconexiones de red. Para obtener información acerca de cómo obtener y usar un certificado `x.509` para su clúster, consulte [Autenticación en el clúster local durante una desconexión de red](#outposts-network-disconnects-authentication). + Si no puede acceder a Route 53 durante las desconexiones de red, considere la posibilidad de utilizar servidores de DNS locales en su entorno en las instalaciones. Las instancias del plano de control de Kubernetes usan direcciones IP estáticas. Puede configurar los hosts que usa para conectarse a su clúster con el nombre de host y las direcciones IP del punto de conexión como alternativa al uso de servidores de DNS locales. Para obtener más información, consulte [DNS](https://docs.aws.amazon.com/outposts/latest/userguide/how-outposts-works.html#dns) en la *Guía del usuario de AWS Outposts*. + Si prevé aumentos en el tráfico de aplicaciones durante las desconexiones de red, puede aprovisionar capacidad de computación sobrante en su clúster cuando se conecte a la nube. Las instancias de Amazon EC2 están incluidas en el precio de AWS Outposts. Por lo tanto, la ejecución de instancias de repuesto no afecta al costo de uso de AWS. + Durante las desconexiones de red, para permitir las operaciones de creación, actualización y escalado de las cargas de trabajo, las imágenes del contenedor de la aplicación deben ser accesibles a través de la red local y el clúster debe tener capacidad suficiente. Los clústeres locales no alojan un registro de contenedores en su nombre. Las imágenes del contenedor se almacenan en caché en los nodos si los pods se ejecutaron anteriormente en esos nodos. Si normalmente extrae las imágenes del contenedor de su aplicación de Amazon ECR en la nube, considere la posibilidad de ejecutar una caché o un registro local. Una caché o un registro local es útil si necesita crear, actualizar y escalar operaciones para los recursos de las cargas de trabajo durante desconexiones de red. + Los clústeres locales usan Amazon EBS como clase de almacenamiento predeterminada para los volúmenes persistentes y el controlador de CSI de Amazon EBS para administrar el ciclo de vida de los volúmenes persistentes de Amazon EBS. Durante las desconexiones de red, los pods basados en Amazon EBS no se pueden crear, actualizar ni escalar. Esto se debe a que estas operaciones requieren llamadas a la API de Amazon EBS en la nube. Si está implementando cargas de trabajo con estado en clústeres locales y necesita crear, actualizar o escalar operaciones durante las desconexiones de red, considere la posibilidad de utilizar un mecanismo de almacenamiento alternativo. + Las instantáneas de Amazon EBS no se pueden crear ni eliminar si AWS Outposts no puede acceder a las API pertinentes en la región de AWS (como las API de Amazon EBS o Amazon S3). + Al integrar ALB (Ingress) con AWS Certificate Manager (ACM), los certificados se cargan y almacenan en la memoria de la instancia ALB Compute de AWS Outposts. La terminación actual de TLS seguirá funcionando en caso de que se desconecte de la región de AWS. Las operaciones de mutación en este contexto fallarán (como las nuevas definiciones de entrada, las nuevas operaciones de API de certificados basadas en ACM, la escala de computación de ALB o la rotación de certificados). Para obtener más información, consulte [Solución de problemas de renovación administrada de certificados](https://docs.aws.amazon.com/acm/latest/userguide/troubleshooting-renewal.html) en la *Guía del usuario de AWS*. + Los registros del plano de control de Amazon EKS se almacenan en caché de forma local en instancias del plano de control de Kubernetes durante las desconexiones de red. Si se conecta nuevamente, los registros se enviarán a Registros de CloudWatch en la región de AWS principal. Puede utilizar [Prometheus](https://prometheus.io/), [Grafana](https://grafana.com/) o las soluciones de socios de Amazon EKS para supervisar el clúster de forma local mediante el punto de conexión de métricas del servidor de la API de Kubernetes o utilizar Fluent Bit para registros. + Si está usando el controlador del equilibrador de carga de AWS en Outposts para el tráfico de aplicaciones, los pods existentes encabezados por el controlador del equilibrador de carga de AWS seguirán recibiendo tráfico durante las desconexiones de red. Los nuevos pods creados durante las desconexiones de red no reciben tráfico hasta que el Outpost se vuelve a conectar a la nube de AWS. Considere la posibilidad de configurar el recuento de réplicas de sus aplicaciones mientras esté conectado a la nube de AWS para satisfacer sus necesidades de escalado durante las desconexiones de red. + El complemento CNI de Amazon VPC para Kubernetes establece el valor predeterminado en el [modo de IP secundario](https://aws.github.io/aws-eks-best-practices/networking/vpc-cni/#overview). Está configurado con `WARM_ENI_TARGET`=`1`, que permite al complemento mantener “una interfaz de red elástica completa” de las direcciones IP disponibles. Considere cambiar los valores `WARM_ENI_TARGET`, `WARM_IP_TARGET` y `MINIMUM_IP_TARGET` de acuerdo con sus necesidades de escalado durante un estado desconectado. Para obtener más información, consulte el archivo [readme](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md) para el complemento en GitHub. Para obtener una lista del número máximo de pods admitidos por cada tipo de instancia, consulte el archivo [eni-max-pods.txt](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/misc/eni-max-pods.txt) en GitHub. ## Autenticación en el clúster local durante una desconexión de red AWS Identity and Access Management (IAM) no está disponible durante las desconexiones de red. No es posible autenticar en su clúster local con las credenciales de IAM mientras esté desconectado. Sin embargo, puede conectarse a su clúster a través de su red local mediante certificados `x509` cuando esté desconectado. Debe descargar y almacenar un certificado cliente `X509` para usar durante las desconexiones. En este tema, aprenderá a crear y utilizar el certificado para autenticarse en su clúster cuando está en estado desconectado. 1. Crear una solicitud de firma de certificado. 1. Genere una solicitud de firma de certificado. ``` openssl req -new -newkey rsa:4096 -nodes -days 365 \ -keyout admin.key -out admin.csr -subj "/CN=admin" ``` 1. Cree una solicitud de firma de certificado en Kubernetes. ``` BASE64_CSR=$(cat admin.csr | base64 -w 0) cat << EOF > admin-csr.yaml apiVersion: certificates.k8s.io/v1 kind: CertificateSigningRequest metadata: name: admin-csr spec: signerName: kubernetes.io/kube-apiserver-client request: ${BASE64_CSR} usages: - client auth EOF ``` 1. Cree una solicitud de firma de certificado con `kubectl`. ``` kubectl create -f admin-csr.yaml ``` 1. Compruebe el estado de la solicitud de firma de certificado. ``` kubectl get csr admin-csr ``` Un ejemplo de salida sería el siguiente. ``` NAME AGE REQUESTOR CONDITION admin-csr 11m kubernetes-admin Pending ``` Kubernetes ha creado la solicitud de firma de certificado. 1. Apruebe la solicitud de firma de certificado. ``` kubectl certificate approve admin-csr ``` 1. Vuelva a comprobar el estado de la solicitud de firma de certificado para aprobarla. ``` kubectl get csr admin-csr ``` Un ejemplo de salida sería el siguiente. ``` NAME AGE REQUESTOR CONDITION admin-csr 11m kubernetes-admin Approved ``` 1. Recupere y verifique el certificado. 1. Recupere el certificado. ``` kubectl get csr admin-csr -o jsonpath='{.status.certificate}' | base64 --decode > admin.crt ``` 1. Verifique el certificado. ``` cat admin.crt ``` 1. Cree un enlace de roles de clúster para un usuario `admin`. ``` kubectl create clusterrolebinding admin --clusterrole=cluster-admin \ --user=admin --group=system:masters ``` 1. Genere un kubeconfig con ámbito de usuario para un estado desconectado. Puede generar un archivo `kubeconfig` con los certificados de `admin` descargados. Reemplace *my-cluster* y *apiserver-endpoint* en los siguientes comandos. ``` aws eks describe-cluster --name my-cluster \ --query "cluster.certificateAuthority" \ --output text | base64 --decode > ca.crt ``` ``` kubectl config --kubeconfig admin.kubeconfig set-cluster my-cluster \ --certificate-authority=ca.crt --server apiserver-endpoint --embed-certs ``` ``` kubectl config --kubeconfig admin.kubeconfig set-credentials admin \ --client-certificate=admin.crt --client-key=admin.key --embed-certs ``` ``` kubectl config --kubeconfig admin.kubeconfig set-context admin@my-cluster \ --cluster my-cluster --user admin ``` ``` kubectl config --kubeconfig admin.kubeconfig use-context admin@my-cluster ``` 1. Visualización del archivo `kubeconfig`. ``` kubectl get nodes --kubeconfig admin.kubeconfig ``` 1. Si ya tiene servicios en producción en su Outpost, omita este paso. Si Amazon EKS es el único servicio que se ejecuta en su Outpost y el Outpost no está en producción actualmente, puede simular una desconexión de red. Antes de iniciar la producción con el clúster local, simule una desconexión para asegurarse de que puede acceder al clúster cuando esté en estado desconectado. 1. Aplique las reglas de firewall en los dispositivos de red que conectan su Outpost a la región de AWS. Esto desconecta el enlace de servicio del Outpost. No puede crear ninguna instancia nueva. Las instancias que se están ejecutando actualmente pierden la conectividad con la región de AWS e Internet. 1. Puede probar la conexión a su clúster local mientras está desconectado mediante el certificado `x509`. Asegúrese de cambiar su `kubeconfig` a la `admin.kubeconfig` que creó en un paso anterior. Reemplace *my-cluster* por el nombre de su clúster local. ``` kubectl config use-context admin@my-cluster --kubeconfig admin.kubeconfig ``` Si observa algún problema con sus clústeres locales mientras están desconectados, le recomendamos que abra un tique de soporte. # Seleccione los tipos de instancias y los grupos de ubicación para los clústeres de Amazon EKS en AWS en función de las consideraciones de capacidad En este tema, se proporciona orientación para seleccionar el tipo de instancia del plano de control de Kubernetes y (opcionalmente) para usar grupos de ubicación para cumplir con los requisitos de alta disponibilidad del clúster local de Amazon EKS en un Outpost. Antes de seleccionar un tipo de instancia (como `m5`, `c5` o `r5`) para usarlo en el plano de control de Kubernetes de su clúster local en Outposts, confirme los tipos de instancias disponibles en su configuración de Outpost. Una vez que haya identificado los tipos de instancias disponibles, seleccione el tamaño de la instancia (como `large`, `xlarge` o `2xlarge`) en función de la cantidad de nodos que requieren sus cargas de trabajo. La siguiente tabla proporciona recomendaciones para elegir el tamaño de una instancia. **nota** Los tamaños de las instancias deben estar establecidos en sus Outposts. Asegúrese de tener capacidad suficiente para tres instancias del tamaño disponible en sus Outposts durante la vida útil de su clúster local. Para obtener una lista de los tipos de instancias de Amazon EC2 disponibles, consulte las secciones de computación y almacenamiento en las [características de los bastidores de AWS Outposts](https://aws.amazon.com/outposts/rack/features/). | Número de nodos | Tamaño de instancia del plano de control de Kubernetes | | --- | --- | | 1–20 | `large` | | 21–100 | `xlarge` | | 101–250 | `2xlarge` | | 251–500 | `4xlarge` | El almacenamiento para el plano de control de Kubernetes requiere 246 GB de almacenamiento de Amazon EBS por cada clúster local para cumplir con la IOPS requerida para `etcd`. Los volúmenes de Amazon EBS se aprovisionan automáticamente cuando se crea el clúster local. ## Ubicación del plano de control Si no especifica un grupo de ubicación en la propiedad `OutpostConfig.ControlPlanePlacement.GroupName`, las instancias de Amazon EC2 aprovisionadas para su plano de control de Kubernetes no reciben ninguna obligación específica de ubicación de hardware en toda la capacidad subyacente disponible en su Outpost. Puede usar grupos de ubicación para cumplir con los requisitos de alta disponibilidad de su clúster local de Amazon EKS en un Outpost. Al especificar un grupo de ubicaciones durante la creación del clúster, se influye en la ubicación de las instancias del plano de control de Kubernetes. Las instancias se distribuyen en un hardware subyacente independiente (bastidores o hosts), lo que minimiza el impacto correlacionado de las instancias en caso de errores de hardware. El tipo de distribución que puede configurar depende de la cantidad de bastidores de Outpost que tenga en su implementación. + **Implementaciones con uno o dos bastidores físicos en un único Outpost lógico**: debe tener al menos tres hosts configurados con el tipo de instancia que elija para las instancias del plano de control de Kubernetes. Un grupo con ubicación *distribuida* que utilice la *distribución por host* garantiza que todas las instancias del plano de control de Kubernetes se ejecuten en distintos hosts dentro de los bastidores subyacentes disponibles en su implementación de Outpost. + **Implementaciones con tres o más bastidores físicos en un único Outpost lógico**: debe tener al menos tres hosts configurados con el tipo de instancia que elija para las instancias del plano de control de Kubernetes. Un grupo con ubicación *distribuida* que utilice la *distribución por bastidor* garantiza que todas las instancias del plano de control de Kubernetes se ejecutan en distintos bastidores en su implementación de Outpost. También puede utilizar el grupo de ubicación de *dispersión a nivel de host* de servidor tal y como se describe en la opción anterior. Usted es responsable de crear el grupo de ubicación deseado. Especifique el grupo de ubicación al llamar a la API de `CreateCluster`. Para más información sobre los grupos de colocación y cómo crearlos, consulte [Grupos de ubicación](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) en la Guía del usuario de Amazon EC2. + Cuando se especifica un grupo de ubicación, debe haber capacidad distribuida disponible en su Outpost para crear correctamente un clúster local de Amazon EKS. La capacidad varía en función de si se utiliza el tipo de distribución de host o de bastidores. Si no hay suficiente capacidad, el clúster permanece en el estado de `Creating`. Puede comprobar el `Insufficient Capacity Error` en el campo de estado de la respuesta de la API de [DescribeCluster](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html). Debe liberar capacidad para que el proceso de creación progrese. + Durante las actualizaciones de la plataforma y la versión del clúster local de Amazon EKS, las instancias del plano de control de Kubernetes del clúster se sustituyen por nuevas instancias mediante una estrategia de actualización continua. Durante este proceso de reemplazo, se termina cada instancia del plano de control, lo que libera su ranura respectiva. Se aprovisiona una nueva instancia actualizada en su lugar. Es posible que la instancia actualizada se coloque en la ranura que se publicó. Si la ranura la consume otra instancia no relacionada y no queda más capacidad que respete el requisito de topología de dispersión requerido, el clúster permanece en el estado de `Updating`. Puede comprobar el `Insufficient Capacity Error` correspondiente en el campo de estado de la respuesta de la API de [DescribeCluster](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html). Debe liberar capacidad para que el proceso de actualización pueda avanzar y restablecer los niveles de alta disponibilidad anteriores. + Puede crear un máximo de 500 grupos de ubicación por cuenta en cada región de AWS. Para obtener más información, consulte [Normas generales y limitaciones](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html#placement-groups-limitations-general) en la Guía del usuario de Amazon EC2. # Solución de problemas de los clústeres locales de Amazon EKS en AWS Outposts En este tema, se tratan algunos errores habituales que pueden aparecer al usar clústeres locales y cómo solucionarlos. Si bien los clústeres locales son similares a los clústeres de Amazon EKS en la nube, existen algunas diferencias en la forma en que Amazon EKS los administra. **importante** Nunca termine ninguna instancia del plano de control de `Kubernetes` del clúster local de EKS administrada que se ejecute en Outpost a menos que AWS Support lo indique explícitamente. La terminación de estas instancias supone un riesgo para la disponibilidad del servicio del clúster local, incluida la pérdida del clúster local en caso de que se terminen varias instancias simultáneamente. Las instancias del plano de control de `Kubernetes` del clúster local de EKS se identifican mediante la etiqueta `eks-local:controlplane-name` de la consola de instancias de EC2. ## Comportamiento de la API Los clústeres locales se crean mediante la API de Amazon EKS, pero se ejecutan de forma asincrónica. Esto significa que las solicitudes a la API de Amazon EKS se devuelven inmediatamente para los clústeres locales. Sin embargo, estas solicitudes pueden tener éxito, responder rápido a los errores debido a errores de validación de entradas o fallar y tener errores de validación descriptivos. Este comportamiento es similar a la API de Kubernetes. Los clústeres locales no pasan a un estado `FAILED`. Amazon EKS intenta conciliar el estado del clúster con el estado deseado solicitado por el usuario de forma continua. Como resultado, un clúster local puede permanecer en el estado `CREATING` durante un periodo prolongado hasta que se resuelva el problema subyacente. ## Describir el campo de estado del clúster Los problemas del clúster local se pueden descubrir utilizando el comando [describe-cluster](https://docs.aws.amazon.com/cli/latest/reference/eks/describe-cluster.html) de la CLI de AWS para Amazon EKS. Los problemas de los clústeres locales aparecen en el campo `cluster.health` de la respuesta del comando `describe-cluster`. El mensaje contenido en este campo incluye un código de error, un mensaje descriptivo y los ID de los recursos relacionados. Esta información se encuentra disponible solo a través de la API y la CLI de AWS para Amazon EKS. En el siguiente ejemplo, reemplace *my-cluster* por el nombre de su clúster local. ``` aws eks describe-cluster --name my-cluster --query 'cluster.health' ``` Un ejemplo de salida sería el siguiente. ``` { "issues": [ { "code": "ConfigurationConflict", "message": "The instance type 'm5.large' is not supported in Outpost 'my-outpost-arn'.", "resourceIds": [ "my-cluster-arn" ] } ] } ``` Si el problema no se puede solucionar, es posible que tenga que eliminar el clúster local y crear uno nuevo. Por ejemplo, intentar aprovisionar un clúster con un tipo de instancia que no está disponible en su Outpost. La siguiente tabla incluye errores comunes relacionados con el estado. | Situación de error | Código | Mensaje | ResourceIds | | --- | --- | --- | --- | | No se encontraron las subredes proporcionadas. | `ResourceNotFound` | `The subnet ID subnet-id does not exist` | Todos los ID de subred proporcionados | | Las subredes proporcionadas no pertenecen a la misma VPC. | `ConfigurationConflict` | `Subnets specified must belong to the same VPC` | Todos los ID de subred proporcionados | | Algunas subredes proporcionadas no pertenecen al Outpost especificado. | `ConfigurationConflict` | `Subnet subnet-id expected to be in outpost-arn, but is in other-outpost-arn ` | ID de subred problemático | | Algunas subredes proporcionadas no pertenecen a ningún Outpost. | `ConfigurationConflict` | `Subnet subnet-id is not part of any Outpost` | ID de subred problemático | | Algunas subredes proporcionadas no tienen suficientes direcciones libres para crear interfaces de red elásticas para instancias del plano de control. | `ResourceLimitExceeded` | `The specified subnet does not have enough free addresses to satisfy the request.` | ID de subred problemático | | El tipo de instancia del plano de control especificado no es compatible con su Outpost. | `ConfigurationConflict` | `The instance type type is not supported in Outpost outpost-arn ` | ARN del clúster | | Terminó una instancia de Amazon EC2 del plano de control o `run-instance` se ejecutó correctamente, pero el estado observó cambios en `Terminated`. Esto puede suceder durante un periodo después de que el Outpost se vuelva a conectar y los errores internos de Amazon EBS provoquen una falla en el flujo de trabajo interno de Amazon EC2. | `InternalFailure` | `EC2 instance state "Terminated" is unexpected` | ARN del clúster | | La capacidad de su Outpost es insuficiente. Esto también puede ocurrir durante la creación del clúster si un Outpost está desconectado de la región de AWS. | `ResourceLimitExceeded` | `There is not enough capacity on the Outpost to launch or start the instance.` | ARN del clúster | | Su cuenta superó la cuota del grupo de seguridad. | `ResourceLimitExceeded` | Mensaje de error devuelto por la API de Amazon EC2 | ID de la VPC de destino | | Su cuenta superó la cuota de la interfaz de red elástica. | `ResourceLimitExceeded` | Mensaje de error devuelto por la API de Amazon EC2 | ID de subred de destino | | No se pudo acceder a las instancias del plano de control a través de AWS Systems Manager. Para obtener una resolución, consulte [No se puede acceder a las instancias del plano de control a través de AWS Systems Manager](#outposts-troubleshooting-control-plane-instances-ssm). | `ClusterUnreachable` | No se puede acceder a las instancias del plano de control de Amazon EKS mediante SSM. Verifique su SSM y la configuración de red y consulte la documentación de solución de problemas de EKS en Outposts. | ID de instancia de Amazon EC2 | | Se produjo un error al obtener detalles de un grupo de seguridad administrado o una interfaz de red elástica. | Basado en el código de error del cliente Amazon EC2. | Mensaje de error devuelto por la API de Amazon EC2 | Todos los ID de grupo de seguridad administrados | | Se produjo un error al autorizar o revocar las reglas de entrada de los grupos de seguridad. Esto se aplica a los grupos de seguridad del clúster y del plano de control. | Basado en el código de error del cliente Amazon EC2. | Mensaje de error devuelto por la API de Amazon EC2 | ID de grupo de seguridad problemático | | Se produjo un error al eliminar una interfaz de red elástica para una instancia del plano de control | Basado en el código de error del cliente Amazon EC2. | Mensaje de error devuelto por la API de Amazon EC2 | ID de interfaz de red elástica problemático | En la siguiente tabla, se enumeran los errores de otros servicios de AWS que se presentan en el campo de estado de la respuesta `describe-cluster`. | Código de error de Amazon EC2 | Código del problema del estado del clúster | Descripción | | --- | --- | --- | | `AuthFailure` | `AccessDenied` | Este error se puede producir por diversas razones. La razón más común es cuando una etiqueta que el servicio usa para determinar el alcance de la política de roles vinculados al servicio se elimina accidentalmente de la instancia del plano de control. Si esto ocurre, Amazon EKS ya no podrá administrar ni supervisar estos recursos de AWS. | | `UnauthorizedOperation` | `AccessDenied` | Este error se puede producir por diversas razones. La razón más común es cuando una etiqueta que el servicio usa para determinar el alcance de la política de roles vinculados al servicio se elimina accidentalmente de la instancia del plano de control. Si esto ocurre, Amazon EKS ya no podrá administrar ni supervisar estos recursos de AWS. | | `InvalidSubnetID.NotFound` | `ResourceNotFound` | Este error se produce cuando no se encuentra el ID de subred de las reglas de entrada de un grupo de seguridad. | | `InvalidPermission.NotFound` | `ResourceNotFound` | Este error se produce cuando los permisos de las reglas de entrada de un grupo de seguridad no son correctos. | | `InvalidGroup.NotFound` | `ResourceNotFound` | Este error se produce cuando no se encuentra el grupo de reglas de entrada de un grupo de seguridad. | | `InvalidNetworkInterfaceID.NotFound` | `ResourceNotFound` | Este error se produce cuando no se encuentra el ID de la interfaz de red para las reglas de entrada de un grupo de seguridad. | | `InsufficientFreeAddressesInSubnet` | `ResourceLimitExceeded` | Este error se produce cuando se supera la cuota de recursos de subred. | | `InsufficientCapacityOnOutpost` | `ResourceLimitExceeded` | Este error se produce cuando se supera la cuota de capacidad del outpost. | | `NetworkInterfaceLimitExceeded` | `ResourceLimitExceeded` | Este error se produce cuando se supera la cuota de la interfaz de red elástica. | | `SecurityGroupLimitExceeded` | `ResourceLimitExceeded` | Este error se produce cuando se supera la cuota del grupo de seguridad. | | `VcpuLimitExceeded` | `ResourceLimitExceeded` | Esto se observa al crear una instancia de Amazon EC2 en una cuenta nueva. El error podría ser similar al siguiente: “: "`You have requested more vCPU capacity than your current vCPU limit of 32 allows for the instance bucket that the specified instance type belongs to. Please visit http://aws.amazon.com/contact-us/ec2-request to request an adjustment to this limit."` | | `InvalidParameterValue` | `ConfigurationConflict` | Amazon EC2 devuelve este código de error si el tipo de instancia especificado no es compatible con Outpost. | | Todas las demás fallas | `InternalFailure` | Ninguno | ## Incapaz de crear o modificar clústeres Los clústeres locales requieren permisos y políticas diferentes a los de los clústeres de Amazon EKS alojados en la nube. Cuando un clúster no se puede crear y produce un error de `InvalidPermissions`, compruebe que el rol de clúster que está utilizando tenga la política administrada [AmazonEKSLocalOutpostClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) adjunta. Todas las demás llamadas a la API requieren el mismo conjunto de permisos que los clústeres de Amazon EKS en la nube. ## El clúster está atascado en el estado `CREATING` La cantidad de tiempo que tarda en crearse un clúster local varía según varios factores. Estos factores incluyen la configuración de la red, la configuración de Outpost y la configuración del clúster. En general, se crea un clúster local y cambia al estado `ACTIVE` en un plazo de 15 a 20 minutos. Si un clúster local permanece en el estado `CREATING`, puede llamar a `describe-cluster` para solicitar información sobre la causa en el campo de resultado `cluster.health`. Los problemas más comunes son los siguientes: + El clúster no puede conectarse a la instancia del plano de control desde la región de AWS en la que se encuentra Systems Manager. Para verificarlo, llame a `aws ssm start-session --target instance-id ` desde un host bastión dentro de la región. Si ese comando no funciona, compruebe si Systems Manager se está ejecutando en la instancia del plano de control. Otra solución alternativa es eliminar el clúster y, a continuación, volver a crearlo. + Las instancias del plano de control no se pueden crear debido a los permisos de claves de KMS para los volúmenes de EBS. Con las claves de KMS administradas por el usuario para los volúmenes de EBS cifrados, las instancias del plano de control se terminarán si no se puede acceder a la clave. Si las instancias se terminan, cambie a una clave de KMS administrada de AWS o asegúrese de que su política de claves administradas por el usuario conceda los permisos necesarios para el rol de clúster. + Es posible que las instancias del plano de control de Systems Manager no tengan acceso a Internet. Compruebe si la subred que proporcionó al crear el clúster tiene una puerta de enlace NAT y una VPC con puerta de enlace de Internet. Use el analizador de accesibilidad de la VPC para verificar que la instancia del plano de control puede llegar a la puerta de enlace de Internet. Para obtener más información, consulte [Introducción al Analizador de accesibilidad de la VPC](https://docs.aws.amazon.com/vpc/latest/reachability/getting-started.html). + Faltan políticas en el ARN de rol que ha proporcionado. Verifique si se eliminó la [política administrada de AWS AmazonEKSLocalOutpostClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) del rol. Esto también puede ocurrir si una pila de AWS CloudFormation está mal configurada. + Todas las subredes proporcionadas deben estar asociadas al mismo Outpost y poder comunicarse entre sí. Cuando se especifican varias subredes al crear un clúster, Amazon EKS intenta distribuir las instancias del plano de control en varias subredes. + Los grupos de seguridad administrados de Amazon EKS se aplican en la interfaz de red elástica. Sin embargo, otros elementos de configuración, como las reglas del firewall NACL, pueden entrar en conflicto con las reglas de la interfaz de red elástica. **Falta o está mal configurada la configuración de DNS de la VPC y de la subred** Revise [Creación de una VPC y subredes para clústeres de Amazon EKS en AWS Outposts](eks-outposts-vpc-subnet-requirements.md). ## El clúster está atascado en el estado `UPDATING` Amazon EKS actualiza automáticamente todos los clústeres locales existentes a las últimas versiones de la plataforma para su versión secundaria de Kubernetes correspondiente. Para obtener más información sobre las versiones de la plataforma, consulte [Información sobre las versiones de la plataforma de Amazon EKS y Kubernetes para AWS Outposts](eks-outposts-platform-versions.md). Durante la implementación de la versión de la plataforma automática, el estado del clúster cambia a `UPDATING`. El proceso de actualización consiste en sustituir todas las instancias del plano de control de Kubernetes por otras nuevas que contengan los últimos parches de seguridad y correcciones de errores publicados para la versión secundaria de Kubernetes correspondiente. En general, el proceso de actualización de la plataforma de un clúster local se completa en menos de 30 minutos y el clúster vuelve al estado `ACTIVE`. Si un clúster local permanece en el estado `UPDATING` durante un periodo de tiempo extenso, puede llamar a `describe-cluster` para consultar información sobre la causa en el campo de resultado `cluster.health`. Amazon EKS garantiza que al menos 2 de cada 3 instancias del plano de control de Kubernetes sean nodos de clúster en buen estado y operativos para mantener la disponibilidad del clúster local y evitar la interrupción del servicio. Si un clúster local se bloquea en el estado `UPDATING`, suele ser porque hay algún problema de infraestructura o configuración que impide garantizar la disponibilidad mínima de las dos instancias en caso de que el proceso continúe. Por lo tanto, el proceso de actualización deja de avanzar para proteger la interrupción del servicio del clúster local. Es importante solucionar los problemas de un clúster local atascado en el estado `UPDATING` y abordar la causa principal para que el proceso de actualización pueda completarse y restaurar el clúster local a `ACTIVE` con la alta disponibilidad de las tres instancias del plano de control de Kubernetes. No termine ninguna instancia de `Kubernetes` del clúster local de EKS administrada que se ejecute en Outposts a menos que AWS Support lo indique explícitamente. Esto es especialmente importante en el caso de los clústeres locales atascados en el estado `UPDATING`, ya que existe una alta probabilidad de que otro nodo del plano de control no esté completamente en buen estado y, si se termina una instancia incorrecta, se podría interrumpir el servicio y correr el riesgo de perder los datos del clúster local. Los problemas más comunes son los siguientes: + Una o más instancias del plano de control no pueden conectarse a Systems Manager debido a un cambio en la configuración de la red desde que se creó el clúster local por primera vez. Para verificarlo, llame a `aws ssm start-session --target instance-id ` desde un host bastión dentro de la región. Si ese comando no funciona, compruebe si Systems Manager se está ejecutando en la instancia del plano de control. + Las instancias del nuevo plano de control no se pueden crear debido a los permisos de claves de KMS para los volúmenes de EBS. Con las claves de KMS administradas por el usuario para los volúmenes de EBS cifrados, las instancias del plano de control se terminarán si no se puede acceder a la clave. Si las instancias se terminan, cambie a una clave de KMS administrada de AWS o asegúrese de que su política de claves administradas por el usuario conceda los permisos necesarios para el rol de clúster. + Es posible que las instancias del plano de control de Systems Manager hayan perdido el acceso a Internet. Compruebe si la subred que se proporcionó al crear el clúster tenga una puerta de enlace de NAT y una VPC con puerta de enlace de Internet. Use el analizador de accesibilidad de la VPC para verificar que la instancia del plano de control puede llegar a la puerta de enlace de Internet. Para obtener más información, consulte [Introducción al Analizador de accesibilidad de la VPC](https://docs.aws.amazon.com/vpc/latest/reachability/getting-started.html). Si sus redes privadas no tienen una conexión a Internet saliente, asegúrese de que todos los puntos de conexión de VPC y de puerta de enlace necesarios sigan presentes en la subred regional de su clúster (consulte [Acceso a los servicios de AWS de la subred](eks-outposts-vpc-subnet-requirements.md#subnet-access-to-services)). + Faltan políticas en el ARN de rol que ha proporcionado. Verifique no se haya eliminado la [política administrada de AWS AmazonEKSLocalOutpostClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) del rol. + Es posible que una de las nuevas instancias del plano de control de Kubernetes haya sufrido un error de arranque inesperado. Envié un ticket con el [Centro de AWS Support](https://console.aws.amazon.com/support/home) para obtener más orientación sobre la solución de problemas y la recopilación de informes en este caso excepcional. ## No puede asociar nodos a un clúster + Problemas con las AMI: + Está utilizando una AMI incompatible. Solo se admiten las AMI de Amazon Linux 2 optimizadas para Amazon EKS (`amazon-linux-2`, `amazon-linux-2-gpu`, `amazon-linux-2-arm64`). Si intenta unir nodos de AL2023 a LocalClusters de EKS en AWS Outposts, los nodos no podrán unirse al clúster. Para obtener más información, consulte [Creación de nodos de Amazon Linux en AWS Outposts](eks-outposts-self-managed-nodes.md). + Si utilizó una plantilla de AWS CloudFormation para crear sus nodos, asegúrese de que no estaba utilizando una AMI no compatible. + Falta el `ConfigMap` del Autenticador de IAM de AWS: si falta, tiene que crearlo. Para obtener más información, consulte  [Aplique el `ConfigMap` de `aws-auth` en su clúster](auth-configmap.md#aws-auth-configmap) . + Se ha usado un grupo de seguridad incorrecto: asegúrese de usar `eks-cluster-sg-cluster-name-uniqueid ` para el grupo de seguridad de sus nodos de trabajo. AWS CloudFormation cambia el grupo de seguridad seleccionado para permitir un nuevo grupo de seguridad cada vez que se utilice la pila. + Siguientes pasos inesperados de VPC de enlace privado: se pasan datos de CA incorrectos (`--b64-cluster-ca`) o del punto de conexión de la API (`--apiserver-endpoint`). ## Recopilación de registros Cuando un Outpost se desconecta del servidor al que está asociado la región de AWS, es probable que el clúster de Kubernetes siga funcionando con normalidad. Sin embargo, si el clúster no funciona correctamente, siga los pasos de solución de problemas que se indican en [Preparación de los clústeres locales de Amazon EKS en AWS Outposts para las desconexiones de la red](eks-outposts-network-disconnects.md). Si encuentra algún problema, póngase en contacto con AWS Support. AWS Support puede guiarlo para descargar y ejecutar una herramienta de recopilación de registros. De esta forma, puede recopilar registros de sus instancias del plano de control del clúster de Kubernetes y enviarlas a AWS Support para una investigación en mayor profundidad. ## No se puede acceder a las instancias del plano de control a través de AWS Systems Manager Cuando no se puede acceder a las instancias del plano de control de Amazon EKS a través de AWS Systems Manager, Amazon EKS muestra el siguiente error para su clúster. ``` Amazon EKS control plane instances are not reachable through SSM. Please verify your SSM and network configuration, and reference the EKS on Outposts troubleshooting documentation. ``` Para resolver este problema, asegúrese de que su VPC y las subredes cumplen con los requisitos que están en [Creación de una VPC y subredes para clústeres de Amazon EKS en AWS Outposts](eks-outposts-vpc-subnet-requirements.md) y que ha completado los pasos de [Configuración del administrador de sesiones](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started.html) en la Guía del usuario de AWS Systems Manager. # Creación de nodos de Amazon Linux en AWS Outposts **importante** Los clústeres locales de Amazon EKS en Outposts solo admiten nodos creados desde las siguientes AMI de Amazon Linux 2023 optimizadas para Amazon EKS: Amazon Linux 2023 estándar (`amazon-linux-2023/x86_64/standard`) Amazon Linux 2023 acelerado por NVIDIA (`amazon-linux-2023/x86_64/nvidia`) Amazon Linux 2023 acelerado por Neuron (`amazon-linux-2023/x86_64/neuron`) AWS finalizó el soporte para las AMI optimizadas para AL2 y aceleradas para AL2 de AKS el 26 de noviembre de 2025. Aunque aún podrá utilizar las AMI EKS AL2 después de la fecha de fin de soporte (EOS) (26 de noviembre de 2025), EKS dejará de publicar nuevas versiones de Kubernetes o actualizaciones de las AMI AL2, incluso versiones secundarias, revisiones y correcciones de errores después de esta fecha. Consulte [esta página](https://docs.aws.amazon.com/eks/latest/userguide/eks-ami-deprecation-faqs.html) para obtener más información sobre la obsolescencia de AL2. En este tema, se describe cómo puede lanzar grupos de escalado automático de nodos de Amazon Linux en un Outpost que se registrarán con el clúster de Amazon EKS. El clúster puede estar en la nube de AWS o en un Outpost. + Un Outpost existente. Para obtener más información, consulte [¿Qué es AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)? + Un clúster existente de Amazon EKS. Para implementar un clúster en la nube de AWS, consulte [Creación de un clúster de Amazon EKS](create-cluster.md). Para implementar un clúster en un Outpost, consulte [Creación de los clústeres locales de Amazon EKS en AWS Outposts para obtener alta disponibilidad](eks-outposts-local-cluster-overview.md). + Supongamos que está creando sus nodos en un clúster en la nube de AWS y tiene subredes en la región de AWS donde tiene habilitados AWS Outposts, AWS Wavelength y las zonas locales de AWS. Esas subredes no deberían haberse transferido al crear el clúster. Si está creando los nodos en un clúster en un Outpost, debe haber proporcionado una subred de Outpost al crear el clúster. + (Recomendado para clústeres en la nube de AWS) El complemento CNI de Amazon VPC para Kubernetes configurado con su propio rol de IAM que tiene asociada la política de IAM necesaria. Para obtener más información, consulte [Configuración del complemento de CNI de Amazon VPC para utilizar IRSA](cni-iam-role.md). Los clústeres locales no admiten roles de IAM para cuentas de servicio. Puede crear un grupo de nodos autoadministrados de Amazon Linux con `eksctl` o la Consola de administración de AWS (con una plantilla de AWS CloudFormation). También puede usar Terraform. Puede crear un grupo de nodos autoadministrado para el clúster local con las siguientes herramientas que se describen en esta página: + [`eksctl`](#eksctl_create_nodes_outpost) + [Consola de administración de AWS](#console_create_nodes_outpost) **importante** Un grupo de nodos autoadministrados incluye instancias de Amazon EC2 en su cuenta. Estas instancias no se actualizan de forma automática cuando usted o Amazon EKS actualizan la versión del plano de control en su nombre. Un grupo de nodos autoadministrados no tiene indicaciones en la consola de que necesita actualizarse. Puede ver la versión de `kubelet` instalada en un nodo al seleccionar el nodo en la lista de **Nodos** en la pestaña **Overview (Información general)** del clúster para determinar qué nodos deben actualizarse. Debe actualizar los nodos de forma manual. Para obtener más información, consulte [Actualización de los nodos autoadministrados para un clúster](update-workers.md). Los certificados que utiliza kubelet en sus nodos autoadministrados se emiten con un año de validez. De forma predeterminada, la rotación de certificados **no** está habilitada (consulte: https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/\$1kubelet-config-k8s-io-v1beta1-KubeletConfiguration); esto significa que, si tiene un nodo autoadministrado en ejecución durante más de un año, ya no podrá autenticarse ante la API de Kubernetes. Como práctica recomendada, recomendamos a los clientes que actualicen periódicamente sus grupos de nodos autoadministrados para recibir los CVE y los parches de seguridad de la última AMI optimizada para Amazon EKS. La actualización de la AMI utilizada en los grupos de nodos autoadministrados también desencadena la recreación de los nodos y garantiza que no se produzcan problemas debido a la caducidad de los certificados de kubelet. Como alternativa, también puede habilitar la rotación de certificados de cliente (consulte: https://kubernetes.io/docs/tasks/tls/certificate-rotation/) al crear los grupos de nodos autoadministrados para asegurarse de que los certificados de kubelet se renueven a medida que el certificado actual se acerca a su fecha de caducidad. ## `eksctl` **Para inicializar nodos de Linux autoadministrados mediante `eksctl` ** 1. Instale la versión `0.215.0` o posterior de la herramienta de línea de comandos de `eksctl` instalada en su dispositivo o AWS CloudShell. Para instalar o actualizar `eksctl`, consulte la sección de [Instalación](https://eksctl.io/installation) en la documentación de `eksctl`. 1. Si su clúster está en la nube de AWS y la política de IAM administrada **AmazonEKS\$1CNI\$1Policy** se adjunta a su [Rol de IAM de nodo de Amazon EKS](create-node-role.md), recomendamos asignarlo a un rol de IAM asociado a la cuenta de servicios de `aws-node` de Kubernetes en su lugar. Para obtener más información, consulte [Configuración del complemento de CNI de Amazon VPC para utilizar IRSA](cni-iam-role.md). Si el clúster está en su Outpost, la política debe estar asociada a su rol de nodo. 1. El siguiente comando crea un grupo de nodos en un clúster existente. El clúster debe haberse creado con `eksctl`. Sustituya *al-nodes* por un nombre para su grupo de nodos. El nombre del grupo de nodos no puede tener más de 63 caracteres. Debe empezar por una letra o un dígito, pero también puede incluir guiones y guiones bajos como caracteres no iniciales. Reemplace *my-cluster* por el nombre de su clúster. El nombre solo puede contener caracteres alfanuméricos (con distinción de mayúsculas y minúsculas) y guiones. Debe comenzar con un carácter alfanumérico y no puede tener más de 100 caracteres. El nombre debe ser único dentro de la región de AWS y la cuenta de AWS en las que va a crear el clúster. Si el clúster existe en un Outpost, reemplace *id* con el ID de una subred de Outpost. Si su clúster existe en la nube de AWS, reemplace *id* con el ID de una subred que no especificó cuando creó el clúster. Reemplace los valores de ejemplo restantes por sus propios valores. Los nodos se crean de forma predeterminada con la misma versión de Kubernetes que el plano de control. Reemplace *instance-type* con un tipo de instancia disponible en su Outpost. Reemplace *my-key* con el nombre de su par de claves de Amazon EC2 o la clave pública. Esta clave se utiliza para SSH en sus nodos después de que se lancen. Si aún no tiene un par de claves de Amazon EC2, puede crear uno en la Consola de administración de AWS. Para obtener más información, consulte [Pares de claves de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) en la *Guía del usuario de Amazon EC2*. Cree el grupo de nodos con el siguiente comando. ``` eksctl create nodegroup --cluster my-cluster --name al-nodes --node-type instance-type \ --nodes 3 --nodes-min 1 --nodes-max 4 --managed=false \ --node-volume-type gp2 --subnet-ids subnet-id \ --node-ami-family AmazonLinux2023 ``` Si su clúster está implementado en la nube de AWS: + El grupo de nodos que implemente puede asignar direcciones `IPv4` a pods de un bloque de CIDR diferente que el de la instancia. Para obtener más información, consulte [Implementación de pods en subredes alternativas con redes personalizadas](cni-custom-network.md). + El grupo de nodos que implemente no requiere acceso a Internet saliente. Para obtener más información, consulte [Implementación de clústeres privados con acceso limitado a Internet](private-clusters.md). Para obtener una lista completa de todas las opciones y valores predeterminados disponibles, consulte [Soporte de AWS Outposts](https://eksctl.io/usage/outposts/) en la documentación de `eksctl`. + Si los nodos no se unen al clúster, consulte [Los nodos no pueden unirse al clúster](troubleshooting.md#worker-node-fail) en [Solución de problemas con los clústeres y nodos de Amazon EKS](troubleshooting.md) y [No puede asociar nodos a un clúster](eks-outposts-troubleshooting.md#outposts-troubleshooting-unable-to-join-nodes-to-a-cluster) en [Solución de problemas de los clústeres locales de Amazon EKS en AWS Outposts](eks-outposts-troubleshooting.md). + Un ejemplo de salida sería el siguiente. Se generan varias líneas mientras se crean los nodos. Una de las últimas líneas de salida es la siguiente línea de ejemplo. ``` [✔] created 1 nodegroup(s) in cluster "my-cluster" ``` 1. (Opcional) Implemente una [aplicación de muestra](sample-deployment.md) para probar el clúster y los nodos de Linux. ## Consola de administración de AWS **Paso 1: lanzamiento de nodos de Linux autoadministrados mediante la Consola de administración de AWS ** 1. Descargue la versión más reciente de la plantilla de AWS CloudFormation. ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2025-11-24/amazon-eks-outpost-nodegroup.yaml ``` 1. Abra la [Consola de AWS CloudFormation](https://console.aws.amazon.com/cloudformation/). 1. Seleccione **Create stack (Crear pila)** y, a continuación, seleccione **With new resources (standard) (Con nuevos recursos [estándar])**. 1. Para **Especificar plantilla**, seleccione **Cargar un archivo de plantilla** y, a continuación, elija **Elegir archivo**. Seleccione el archivo `amazon-eks-nodegroup.yaml` que ha descargado en el paso anterior y, a continuación, seleccione **Siguiente**. 1. En la página **Especificar detalles de la pila**, ingrese los siguientes parámetros según corresponda y luego seleccione **Siguiente**: + **Nombre de pila**: elija un nombre para su pila de AWS CloudFormation. Por ejemplo, puede llamarla *al-nodes*. El nombre solo puede contener caracteres alfanuméricos (con distinción de mayúsculas y minúsculas) y guiones. Debe comenzar con un carácter alfanumérico y no puede tener más de 100 caracteres. El nombre debe ser único dentro de la región de AWS y la cuenta de AWS en las que va a crear el clúster. + **ApiServerEndpoint**: ingrese el punto de conexión del servidor de la API de Kubernetes, visible en la consola de EKS o con la API DescribeCluster. + **ClusterName**: ingrese el nombre del clúster. Si este nombre no coincide con el nombre del clúster, los nodos no pueden unirse al clúster. + **ClusterId**: ingrese el ID que el servicio de EKS asignó al clúster. Visible con la API DescribeCluster. Si este ID no coincide con el ID del clúster, los nodos no pueden unirse al clúster. + **CertificateAuthority**: ingrese la cadena codificada en base64 de la autoridad de certificación de Kubernetes. Visible en la consola de EKS o con la API DescribeCluster. + **ServiceCidr**: ingrese el CIDR de los servicios de Kubernetes. Visible en la consola de EKS o con la API DescribeCluster. + **ClusterControlPlaneSecurityGroup**: elija el valor de **SecurityGroups** en la salida de AWS CloudFormation que generó cuando creó la [VPC](creating-a-vpc.md). En los siguientes pasos, se muestra una operación para recuperar el grupo aplicable. 1. Abra la [consola de Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters). 1. Elija el nombre del clúster. 1. Elija la pestaña **Redes**. 1. Use el valor de **Grupo de seguridad adicional** como referencia al realizar una selección en la lista desplegable **ClusterControlPlaneSecurityGroup**. + **NodeGroupName**: escriba un nombre para el grupo de nodos. Este nombre se puede utilizar más adelante para identificar el grupo de nodos de escalado automático que se crea para los nodos. + **NodeAutoScalingGroupMinSize**: ingrese el número mínimo de nodos al que se puede reducir horizontalmente el grupo de escalado automático de nodos. + **NodeAutoScalingGroupDesiredCapacity**: escriba el número deseado de nodos que desea escalar cuando se crea la pila. + **NodeAutoScalingGroupMaxSize**: ingrese el número máximo de nodos que pueda alcanzar el grupo de Auto Scaling de nodos. + **NodeInstanceType**: elija un tipo de instancia para los nodos. Si su clúster se ejecuta en la nube de AWS y desea obtener más información, consulte [Elección de un tipo de instancia de nodo de Amazon EC2 óptimo](choosing-instance-type.md). Si su clúster se ejecuta en un Outpost, solo puede seleccionar un tipo de instancia disponible en su Outpost. + **NodeImageIdSSMParam**: rellenado previamente con el parámetro de Amazon EC2 Systems Manager de una AMI optimizada recientemente para Amazon EKS para una versión de Kubernetes variable. Para utilizar otra versión secundaria de Kubernetes compatible con Amazon EKS, reemplace *1.XX* por una [versión admitida](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) diferente. Recomendamos especificar la misma versión de Kubernetes que el clúster. Para usar una AMI acelerada optimizada para Amazon EKS, actualice el valor de *NodeImageIdSSMParam* al parámetro de SSM deseado. Consulte cómo recuperar los ID de AMI de EKS desde SSM [aquí](https://docs.aws.amazon.com/eks/latest/userguide/retrieve-ami-id.html). **nota** Las AMI de los nodos de Amazon EKS se basan en Amazon Linux. Puede realizar un seguimiento de los eventos de seguridad o privacidad de Amazon Linux en el [Centro de seguridad de Amazon Linux](https://alas.aws.amazon.com/) seleccionando la pestaña de la versión que desee. También puede suscribirse a la fuente RSS correspondiente. Los eventos de seguridad y privacidad incluyen información general del problema, qué paquetes están afectados y cómo actualizar las instancias para corregir el problema. + **NodeImageId**: (opcional) si utiliza una AMI personalizada propia (en lugar de una AMI optimizada para Amazon EKS), escriba un ID de AMI de nodo para la región de AWS. Si especifica un valor aquí, anula cualquier valor del campo **NodeImageIdSSMParam**. + **NodeVolumeSize**: especifique un tamaño de volumen raíz para los nodos en GiB. + **NodeVolumeType**: especifique un tipo de volumen raíz para sus nodos. + **KeyName**: ingrese el nombre de un par de claves SSH de Amazon EC2 que pueda utilizar para conectar mediante SSH con los nodos después de haberlos lanzado. Si aún no tiene un par de claves de Amazon EC2, puede crear uno en la Consola de administración de AWS. Para obtener más información, consulte [Pares de claves de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) en la *Guía del usuario de Amazon EC2*. **nota** Si no proporciona un par de claves aquí, se produce un error al crear la pila de AWS CloudFormation. + **DisableIMDSv1**: cada nodo admite de forma predeterminada la versión 1 (IMDSv1) e IMDSv2 del servicio de metadatos de la instancia. Puede desactivar IMDSv1. Para evitar que los nodos y pods futuros del grupo de nodos usen IMDSv1, establezca **DisableIMDSv1** en **Verdadero**. Para obtener más información, consulte [Configuración del servicio de metadatos de instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html). Para obtener más información sobre cómo restringir el acceso en sus nodos, consulte [Restringir el acceso al perfil de instancias asignado al nodo de trabajo](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node). + **VpcId**: ingrese el ID de la [VPC](creating-a-vpc.md) que ha creado. Antes de elegir una VPC, revise los [Requisitos y consideraciones de la VPC](eks-outposts-vpc-subnet-requirements.md#outposts-vpc-requirements). + **Subredes**: si su clúster está en un Outpost, elija al menos una subred privada en la VPC. Antes de elegir las subredes, revise [Requisitos y consideraciones de las subredes](eks-outposts-vpc-subnet-requirements.md#outposts-subnet-requirements). Puede ver qué subredes son privadas abriendo cada enlace de subred desde la pestaña **Redes** de su clúster. 1. Seleccione las opciones que desee en la página **Configurar las opciones de pila** y, a continuación, elija **Siguiente**. 1. Seleccione la casilla de verificación a la izquierda de **Reconozco que AWS podría crear recursos de IAM** y, luego, seleccione **Crear pila**. 1. Una vez completada la creación de la pila, selecciónela en la consola y elija **Salidas**. 1. Anote el valor de **NodeInstanceRoles** correspondiente al grupo de nodos creado. Lo necesitará al configurar los nodos de Amazon EKS. **Paso 2: habilitación para que los nodos se unan al clúster** 1. Verifique si ya tiene el `ConfigMap` de `aws-auth`. ``` kubectl describe configmap -n kube-system aws-auth ``` 1. Si se le muestra un `ConfigMap` de `aws-auth`, actualícelo según sea necesario. 1. Abra el icono `ConfigMap` para editar. ``` kubectl edit -n kube-system configmap/aws-auth ``` 1. Añada una nueva entrada de `mapRoles` según sea necesario. Establezca el valor de `rolearn` en el valor de **NodeInstanceRole** que registró en el procedimiento anterior. ``` [...] data: mapRoles: | - rolearn: username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes [...] ``` 1. Guarde el archivo y salga del editor de texto. 1. Si recibe un error que indica “`Error from server (NotFound): configmaps "aws-auth" not found`, aplique el `ConfigMap` bursátil. 1. Descargue el mapa de configuración. ``` curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml ``` 1. En el archivo `aws-auth-cm.yaml`, establezca el `rolearn` al valor de **NodeInstanceRole** que ha registrado en el procedimiento anterior. Puede hacerlo con un editor de texto o puede reemplazar *my-node-instance-role* y ejecutar el siguiente comando: ``` sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml ``` 1. Aplique la configuración. Este comando puede tardar varios minutos en finalizar. ``` kubectl apply -f aws-auth-cm.yaml ``` 1. Observe el estado de los nodos y espere a que aparezca el estado `Ready`. ``` kubectl get nodes --watch ``` Ingrese `Ctrl`\$1`C` para obtener un símbolo del intérprete de comandos. **nota** Si recibe cualquier error de tipo de recurso o autorización, consulte [Acceso denegado o no autorizado (`kubectl`)](troubleshooting.md#unauthorized) en el tema de solución de problemas. Si los nodos no se unen al clúster, consulte [Los nodos no pueden unirse al clúster](troubleshooting.md#worker-node-fail) en [Solución de problemas con los clústeres y nodos de Amazon EKS](troubleshooting.md) y [No puede asociar nodos a un clúster](eks-outposts-troubleshooting.md#outposts-troubleshooting-unable-to-join-nodes-to-a-cluster) en [Solución de problemas de los clústeres locales de Amazon EKS en AWS Outposts](eks-outposts-troubleshooting.md). 1. Instale el controlador de CSI de Amazon EBS. Para obtener más información, consulte [Installation](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/install.md) (Instalación) en GitHub. En la sección **Set up driver permission** (Configurar permiso de controlador), asegúrese de seguir las instrucciones de la opción **Using IAM instance profile** (Uso del perfil de instancia de IAM). Debe usar la clase de almacenamiento `gp2`. No se admite la clase de almacenamiento `gp3`. Para crear una clase de almacenamiento `gp2` en el clúster, realice los siguientes pasos. 1. Ejecute el siguiente comando para crear un archivo `gp2-storage-class.yaml`. ``` cat >gp2-storage-class.yaml <