**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. # Ejecución de cargas de trabajo en las instalaciones en nodos híbridos En un clúster de EKS con nodos híbridos habilitados, es posible ejecutar aplicaciones en las instalaciones y periféricas en una infraestructura propia con los mismos clústeres, características y herramientas de Amazon EKS que se utilizan en la nube de AWS. En las siguientes secciones se ofrecen instrucciones paso a paso sobre cómo se utilizan los nodos híbridos. **Topics** + [Cómo conectar nodos híbridos](hybrid-nodes-join.md) + [Conexión de nodos híbridos con Bottlerocket](hybrid-nodes-bottlerocket.md) + [Actualización de nodos híbridos](hybrid-nodes-upgrade.md) + [Aplicación de revisiones a nodos híbridos](hybrid-nodes-security.md) + [Cómo eliminar nodos híbridos](hybrid-nodes-remove.md) # Cómo conectar nodos híbridos **nota** Los siguientes pasos se aplican a nodos híbridos que ejecutan sistemas operativos compatibles, con excepción de Bottlerocket. Para conocer los pasos para conectar un nodo híbrido que ejecute Bottlerocket, consulte [Conexión de nodos híbridos con Bottlerocket](hybrid-nodes-bottlerocket.md). En este tema se explica cómo conectar nodos híbridos a un clúster de Amazon EKS. Una vez que los nodos híbridos se unan al clúster, aparecerán con el estado No listos en la consola de Amazon EKS y en las herramientas compatibles con Kubernetes, como kubectl. Tras completar los pasos que se indican en esta página, proceda a [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md) para preparar los nodos híbridos para ejecutar aplicaciones. ## Requisitos previos Antes de conectar los nodos híbridos al clúster de Amazon EKS, compruebe que se cumplen los requisitos previos indicados. + Dispone de conectividad de red entre el entorno en las instalaciones con la región de AWS que aloja el clúster de Amazon EKS. Para obtener más información, consulte [Cómo preparar las redes para los nodos híbridos](hybrid-nodes-networking.md). + Dispone de un sistema operativo compatible con los nodos híbridos instalado en los hosts en las instalaciones. Para obtener más información, consulte [Cómo preparar el sistema operativo para los nodos híbridos](hybrid-nodes-os.md). + Ha creado el rol de IAM de los nodos híbridos y ha configurado el proveedor de credenciales en las instalaciones (activaciones híbridas de AWS Systems Manager o AWS IAM Roles Anywhere). Para obtener más información, consulte [Cómo preparar las credenciales para los nodos híbridos](hybrid-nodes-creds.md). + Ha creado el clúster de Amazon EKS habilitado para nodos híbridos. Para obtener más información, consulte [Cómo crear un clúster de Amazon EKS con nodos híbridos](hybrid-nodes-cluster-create.md). + Ha asociado el rol de IAM de nodos híbridos a los permisos de control de acceso basado en roles (RBAC) de Kubernetes. Para obtener más información, consulte [Cómo preparar el acceso al clúster para los nodos híbridos](hybrid-nodes-cluster-prep.md). ## Paso 1: Instalación de la CLI (`nodeadm`) de nodos híbridos en cada host en las instalaciones Si incluye la CLI (`nodeadm`) de los Nodos híbridos de Amazon EKS en las imágenes prediseñadas del sistema operativo, puede omitir este paso. Para obtener más información acerca de la versión de los nodos híbridos de `nodeadm`, consulte [Referencia de `nodeadm` de nodos híbridos](hybrid-nodes-nodeadm.md). La versión de nodos híbridos de `nodeadm` está alojada en Amazon S3, con Amazon CloudFront como frontend. Para instalar `nodeadm` en cada host en las instalaciones, puede ejecutar el siguiente comando desde los hosts en las instalaciones. **Para los hosts x86\$164:** ``` curl -OL 'https://hybrid-assets.eks.amazonaws.com/releases/latest/bin/linux/amd64/nodeadm' ``` **Para los hosts ARM** ``` curl -OL 'https://hybrid-assets.eks.amazonaws.com/releases/latest/bin/linux/arm64/nodeadm' ``` Agregue permiso de archivo ejecutable al binario descargado en cada host. ``` chmod +x nodeadm ``` ## Paso 2: Instalación de las dependencias de los nodos híbridos con `nodeadm` Si va a instalar las dependencias de los nodos híbridos en las imágenes prediseñadas del sistema operativo, puede omitir este paso. El comando `nodeadm install` se puede usar para instalar todas las dependencias necesarias para los nodos híbridos. Las dependencias de los nodos híbridos incluyen containerd, kubelet, kubectl y los componentes de AWS SSM o AWS IAM Roles Anywhere. Consulte [Referencia de `nodeadm` de nodos híbridos](hybrid-nodes-nodeadm.md) para obtener más información sobre los componentes y las ubicaciones de los archivos instalados por `nodeadm install`. Consulte [Cómo preparar las redes para los nodos híbridos](hybrid-nodes-networking.md) para nodos híbridos para obtener más información sobre los dominios que se deben permitir en el firewall en las instalaciones durante el proceso de `nodeadm install`. Ejecute el siguiente comando para instalar las dependencias de los nodos híbridos en el host en las instalaciones. El comando que aparece a continuación se debe ejecutar con un usuario que tenga privilegios de raíz/sudo en el host. **importante** La CLI (`nodeadm`) de nodos híbridos se debe ejecutar con un usuario que tenga acceso sudo/raíz en el host. + Sustituya `K8S_VERSION` por la versión secundaria de Kubernetes del clúster de Amazon EKS, por ejemplo `1.31`. Consulte las [versiones compatibles de Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) para obtener una lista de las versiones de Kubernetes compatibles. + Sustituya `CREDS_PROVIDER` por el proveedor de credenciales en las instalaciones que utiliza. Los valores válidos son `ssm` para AWS SSM y `iam-ra` para AWS IAM Roles Anywhere. ``` nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER ``` ## Paso 3: Conexión de los nodos híbridos al clúster Antes de conectar los nodos híbridos al clúster, asegúrese de haber permitido el acceso necesario en el firewall en las instalaciones y en el grupo de seguridad del clúster para la comunicación entre el plano de control de Amazon EKS y el nodo híbrido. La mayoría de los problemas de este paso están relacionados con la configuración del firewall, la configuración del grupo de seguridad o la configuración de los roles de IAM de los nodos híbridos. **importante** La CLI (`nodeadm`) de nodos híbridos se debe ejecutar con un usuario que tenga acceso sudo/raíz en el host. 1. Cree un archivo `nodeConfig.yaml` en cada host con los valores de la implementación. Para obtener una descripción completa de los ajustes de configuración disponibles, consulte [Referencia de `nodeadm` de nodos híbridos](hybrid-nodes-nodeadm.md). Si el rol de IAM de los nodos híbridos no tiene permiso para la acción `eks:DescribeCluster`, debe proporcionar el punto de conexión de la API de Kubernetes, el paquete CA del clúster y el CIDR IPv4 del servicio de Kubernetes en la sección del clúster del `nodeConfig.yaml`. 1. Utilice el `nodeConfig.yaml` de ejemplo que aparece a continuación si utiliza activaciones híbridas de AWS SSM para el proveedor de credenciales en las instalaciones. 1. Reemplace `CLUSTER_NAME` por el nombre del clúster. 1. Sustituya `AWS_REGION` por la región de AWS en la que se aloja el clúster. Por ejemplo, `us-west-2`. 1. Sustituya `ACTIVATION_CODE` por el código de activación que recibió al crear la activación híbrida de AWS SSM. Para obtener más información, consulte [Cómo preparar las credenciales para los nodos híbridos](hybrid-nodes-creds.md). 1. Sustituya `ACTIVATION_ID` por el ID de activación que recibió al crear la activación híbrida de AWS SSM. Puede recuperar esta información desde la consola de AWS Systems Manager o desde el comando `aws ssm describe-activations` de AWS CLI. ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: CLUSTER_NAME region: AWS_REGION hybrid: ssm: activationCode: ACTIVATION_CODE activationId: ACTIVATION_ID ``` 1. Utilice el `nodeConfig.yaml` de ejemplo que aparece a continuación si utiliza AWS IAM Roles Anywhere para el proveedor de credenciales en las instalaciones. 1. Reemplace `CLUSTER_NAME` por el nombre del clúster. 1. Sustituya `AWS_REGION` por la región de AWS en la que se aloja el clúster. Por ejemplo, `us-west-2`. 1. Sustituya `NODE_NAME` por el nombre del nodo. El nombre del nodo debe coincidir con el CN del certificado del host si configuró la política de confianza del rol de IAM de nodos híbridos con la condición de recurso `"sts:RoleSessionName": "${aws:PrincipalTag/x509Subject/CN}"`. El `nodeName` que utilice no puede tener más de 64 caracteres. 1. Sustituya `TRUST_ANCHOR_ARN` por el ARN del anclaje de veracidad que configuró en los pasos que se indican en Cómo preparar credenciales para nodos híbridos. 1. Sustituya `PROFILE_ARN` por el ARN del anclaje de veracidad que configuró en los pasos de [Cómo preparar las credenciales para los nodos híbridos](hybrid-nodes-creds.md). 1. Sustituya `ROLE_ARN` por el ARN del rol de IAM de nodos híbridos. 1. Sustituya `CERTIFICATE_PATH` por la ruta en disco al certificado del nodo. Si no se especifica, el valor predeterminado es `/etc/iam/pki/server.pem`. 1. Sustituya `KEY_PATH` por la ruta en disco a la clave privada del certificado. Si no se especifica, el valor predeterminado es `/etc/iam/pki/server.key`. ``` apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: CLUSTER_NAME region: AWS_REGION hybrid: iamRolesAnywhere: nodeName: NODE_NAME trustAnchorArn: TRUST_ANCHOR_ARN profileArn: PROFILE_ARN roleArn: ROLE_ARN certificatePath: CERTIFICATE_PATH privateKeyPath: KEY_PATH ``` 1. Ejecute el comando `nodeadm init` con el `nodeConfig.yaml` para conectar los nodos híbridos al clúster de Amazon EKS. ``` nodeadm init -c file://nodeConfig.yaml ``` Si el comando anterior se ejecuta correctamente, el nodo híbrido se habrá unido a su clúster de Amazon EKS. Puede verificar esto en la consola de Amazon EKS. Para ello, vaya a la pestaña Computación del clúster ([asegúrese de que la entidad principal de IAM tenga permisos de visualización](view-kubernetes-resources.md#view-kubernetes-resources-permissions)) o con `kubectl get nodes`. **importante** Los nodos tendrán el estado `Not Ready`, que es el esperado, y se debe a la falta de una CNI que se ejecute en los nodos híbridos. Si los nodos no se unieron al clúster, consulte [Solución de problemas relacionados con los nodos híbridos](hybrid-nodes-troubleshooting.md). ## Paso 4: Configuración de una CNI para los nodos híbridos Para que los nodos híbridos estén preparados para ejecutar aplicaciones, continúe con los pasos que se indican en [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md). # Conexión de nodos híbridos con Bottlerocket Este tema describe cómo conectar nodos híbridos que ejecutan Bottlerocket a un clúster de Amazon EKS. [Bottlerocket](https://aws.amazon.com/bottlerocket/) es una distribución de Linux de código abierto patrocinada y respaldada por AWS. Bottlerocket está diseñado específicamente para alojar cargas de trabajo de contenedores. Con Bottlerocket, puede mejorar la disponibilidad de las implementaciones en contenedores y reducir los costos operativos mediante la automatización de las actualizaciones de la infraestructura de contenedores. Bottlerocket incluye solo el software esencial para ejecutar los contenedores, lo que mejora el uso de los recursos, reduce las amenazas a la seguridad y reduce los gastos de administración. Solo se admiten las variantes de VMware de Bottlerocket a partir de la versión v1.37.0 con los Nodos híbridos de EKS. Las variantes de VMware de Bottlerocket están disponibles para las versiones v1.28 y posteriores de Kubernetes. Las imágenes del sistema operativo para estas variantes incluyen kubelet, containerd, aws-iam-authenticator y otros requisitos previos de software para los Nodos híbridos de EKS. Puede configurar estos componentes mediante un archivo de [configuración](https://github.com/bottlerocket-os/bottlerocket#settings) de Bottlerocket que incluya datos de usuario codificados en base64 para los contenedores de arranque y administración de Bottlerocket. Configurar estos ajustes permite que Bottlerocket utilice el proveedor de credenciales de los nodos híbridos para autenticarlos en el clúster. Después de que los nodos híbridos se unan al clúster, aparecerán con el estado `Not Ready` en la consola de Amazon EKS y en herramientas compatibles con Kubernetes, como `kubectl`. Tras completar los pasos que se indican en esta página, proceda a [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md) para preparar los nodos híbridos para ejecutar aplicaciones. ## Requisitos previos Antes de conectar los nodos híbridos al clúster de Amazon EKS, compruebe que se cumplen los requisitos previos indicados. + Dispone de conectividad de red entre el entorno en las instalaciones con la región de AWS que aloja el clúster de Amazon EKS. Para obtener más información, consulte [Cómo preparar las redes para los nodos híbridos](hybrid-nodes-networking.md). + Ha creado el rol de IAM de los nodos híbridos y ha configurado el proveedor de credenciales en las instalaciones (activaciones híbridas de AWS Systems Manager o AWS IAM Roles Anywhere). Para obtener más información, consulte [Cómo preparar las credenciales para los nodos híbridos](hybrid-nodes-creds.md). + Ha creado el clúster de Amazon EKS habilitado para nodos híbridos. Para obtener más información, consulte [Cómo crear un clúster de Amazon EKS con nodos híbridos](hybrid-nodes-cluster-create.md). + Ha asociado el rol de IAM de nodos híbridos a los permisos de control de acceso basado en roles (RBAC) de Kubernetes. Para obtener más información, consulte [Cómo preparar el acceso al clúster para los nodos híbridos](hybrid-nodes-cluster-prep.md). ## Paso 1: creación del archivo TOML de configuración de Bottlerocket Para configurar Bottlerocket para nodos híbridos, debe crear un archivo `settings.toml` con la configuración necesaria. El contenido del archivo TOML variará según el proveedor de credenciales que utilice (SSM o IAM Roles Anywhere). Este archivo se transferirá como datos de usuario al aprovisionar la instancia de Bottlerocket. **nota** Los archivos TOML que se proporcionan a continuación solo representan la configuración mínima necesaria para inicializar una máquina VMWare de Bottlerocket como un nodo en un clúster de EKS. Bottlerocket ofrece una amplia gama de opciones de configuración para abordar varios casos de uso diferentes, por lo que, para obtener más opciones de configuración además de la inicialización del nodo híbrido, consulte la [documentación de Bottlerocket](https://bottlerocket.dev/en) a fin de obtener una lista completa de todas las configuraciones documentadas para la versión de Bottlerocket que esté utilizando (por ejemplo, [aquí](https://bottlerocket.dev/en/os/1.51.x/api/settings-index) están todas las configuraciones disponibles para Bottlerocket 1.51.x). ### SSM Si utiliza AWS Systems Manager como proveedor de credenciales, cree un archivo `settings.toml` con el siguiente contenido: ``` [settings.kubernetes] cluster-name = "" api-server = "" cluster-certificate = "" hostname-override = "" provider-id = "eks-hybrid://///" authentication-mode = "aws" cloud-provider = "" server-tls-bootstrap = true [settings.network] hostname = "" [settings.aws] region = "" [settings.kubernetes.credential-providers.ecr-credential-provider] enabled = true cache-duration = "12h" image-patterns = [ "*.dkr.ecr.*.amazonaws.com", "*.dkr.ecr.*.amazonaws.com.rproxy.govskope.ca.cn", "*.dkr.ecr.*.amazonaws.eu", "*.dkr.ecr-fips.*.amazonaws.com", "*.dkr.ecr-fips.*.amazonaws.eu", "public.ecr.aws" ] [settings.kubernetes.node-labels] "eks.amazonaws.com/compute-type" = "hybrid" "eks.amazonaws.com/hybrid-credential-provider" = "ssm" [settings.host-containers.admin] enabled = true user-data = "" [settings.bootstrap-containers.eks-hybrid-setup] mode = "always" user-data = "" [settings.host-containers.control] enabled = true ``` Reemplace los marcadores de posición con los siguientes valores: + ``: el nombre del clúster de Amazon EKS. + ``: el punto de conexión del servidor API del clúster. + ``: el paquete CA codificado en base64 del clúster. + ``: la región de AWS donde se aloja el clúster, por ejemplo, “us-east-1”. + ``: el nombre de host de la instancia de Bottlerocket, que se utilizará también como nombre del nodo. Puede ser cualquier valor único de su elección, pero debe cumplir con las [convenciones de nomenclatura de objetos de Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names). Además, el nombre de host que utilice no puede tener más de 64 caracteres. NOTA: Al utilizar el proveedor SSM, este nombre de host y nombre de nodo serán reemplazados por el ID de instancia administrada (por ejemplo, ID `mi-*`) después de que la instancia se registre en SSM. + ``: el contenido codificado en base64 de la configuración del contenedor de administración de Bottlerocket. Al habilitar el contenedor de administración, se puede conectar a la instancia de Bottlerocket mediante SSH para explorar y depurar el sistema. Aunque esta configuración no es obligatoria, recomendamos habilitarla para facilitar la resolución de problemas. Consulte la [documentación del contenedor de administración de Bottlerocket](https://github.com/bottlerocket-os/bottlerocket-admin-container#authenticating-with-the-admin-container) para obtener más información sobre cómo autenticarse con el contenedor de administración. El contenedor de administración acepta entradas de usuario y clave SSH en formato JSON, por ejemplo, ``` { "user": "", "ssh": { "authorized-keys": [ "" ] } } ``` + ``: el contenido codificado en base64 de la configuración del contenedor de arranque Bottlerocket. Consulte la [documentación del contenedor de arranque de Bottlerocket](https://github.com/bottlerocket-os/bottlerocket-bootstrap-container) para obtener más información sobre su configuración. El contenedor de arranque se encarga de registrar la instancia como una instancia administrada de AWS SSM y de unirla como nodo de Kubernetes en el clúster de Amazon EKS. Los datos de usuario que se transmiten al contenedor de arranque adoptan la forma de una invocación de comando que acepta como entrada el código de activación híbrida SSM y el ID que creó previamente: ``` eks-hybrid-ssm-setup --activation-id= --activation-code= --region= ``` ### IAM Roles Anywhere Si utiliza AWS IAM Roles Anywhere como proveedor de credenciales, cree un archivo `settings.toml` con el siguiente contenido: ``` [settings.kubernetes] cluster-name = "" api-server = "" cluster-certificate = "" hostname-override = "" provider-id = "eks-hybrid://///" authentication-mode = "aws" cloud-provider = "" server-tls-bootstrap = true [settings.network] hostname = "" [settings.aws] region = "" config = "" [settings.kubernetes.credential-providers.ecr-credential-provider] enabled = true cache-duration = "12h" image-patterns = [ "*.dkr.ecr.*.amazonaws.com", "*.dkr.ecr.*.amazonaws.com.rproxy.govskope.ca.cn", "*.dkr.ecr.*.amazonaws.eu", "*.dkr.ecr-fips.*.amazonaws.com", "*.dkr.ecr-fips.*.amazonaws.eu", "public.ecr.aws" ] [settings.kubernetes.node-labels] "eks.amazonaws.com/compute-type" = "hybrid" "eks.amazonaws.com/hybrid-credential-provider" = "iam-ra" [settings.host-containers.admin] enabled = true user-data = "" [settings.bootstrap-containers.eks-hybrid-setup] mode = "always" user-data = "" ``` Reemplace los marcadores de posición con los siguientes valores: + ``: el nombre del clúster de Amazon EKS. + ``: el punto de conexión del servidor API del clúster. + ``: el paquete CA codificado en base64 del clúster. + ``: la región de AWS que aloja el clúster (por ejemplo, “us-east-1”) + ``: el nombre de host de la instancia de Bottlerocket, que se utilizará también como nombre del nodo. Puede ser cualquier valor único de su elección, pero debe cumplir con las [convenciones de nomenclatura de objetos de Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names). Además, el nombre de host que utilice no puede tener más de 64 caracteres. NOTA: Cuando se utiliza el proveedor IAM-RA, el nombre del nodo debe coincidir con el CN del certificado en el host si ha configurado la política de confianza del rol de IAM de Nodos híbridos con la condición de recurso `"sts:RoleSessionName": "${aws:PrincipalTag/x509Subject/CN}"`. + AWS: el contenido codificado en base64 del archivo de configuración de ``. El contenido del archivo debe ser el siguiente: ``` [default] credential_process = aws_signing_helper credential-process --certificate /root/.aws/node.crt --private-key /root/.aws/node.key --profile-arn --role-arn --trust-anchor-arn --role-session-name ``` + ``: el contenido codificado en base64 de la configuración del contenedor de administración de Bottlerocket. Al habilitar el contenedor de administración, se puede conectar a la instancia de Bottlerocket mediante SSH para explorar y depurar el sistema. Aunque esta configuración no es obligatoria, recomendamos habilitarla para facilitar la resolución de problemas. Consulte la [documentación del contenedor de administración de Bottlerocket](https://github.com/bottlerocket-os/bottlerocket-admin-container#authenticating-with-the-admin-container) para obtener más información sobre cómo autenticarse con el contenedor de administración. El contenedor de administración acepta entradas de usuario y clave SSH en formato JSON, por ejemplo, ``` { "user": "", "ssh": { "authorized-keys": [ "" ] } } ``` + ``: el contenido codificado en base64 de la configuración del contenedor de arranque Bottlerocket. Consulte la [documentación del contenedor de arranque de Bottlerocket](https://github.com/bottlerocket-os/bottlerocket-bootstrap-container) para obtener más información sobre su configuración. El contenedor de arranque se encarga de crear el certificado de host de IAM Roles Anywhere y los archivos de clave privada del certificado en la instancia. Estas serán consumidas por el `aws_signing_helper` para obtener credenciales temporales para autenticarse con el clúster de Amazon EKS. Los datos de usuario que se transmiten al contenedor de arranque adoptan la forma de una invocación de comando que acepta como entrada el contenido del certificado y la clave privada que creó previamente: ``` eks-hybrid-iam-ra-setup --certificate= --key= ``` ## Paso 2: aprovisionamiento de la máquina virtual Bottlerocket vSphere con datos de usuario Una vez que haya creado el archivo TOML, transmítalo como datos de usuario durante la creación de la máquina virtual en vSphere. Tenga en cuenta que los datos de usuario se deben configurar antes de que la máquina virtual se encienda por primera vez. Por lo tanto, deberá proporcionarlos al crear la instancia o, si desea crear la máquina virtual con anticipación, esta debe permanecer en estado apagado (poweredOff) hasta que configure los datos de usuario. Por ejemplo, si utiliza la CLI de `govc`: ### Cómo crear la máquina virtual por primera vez ``` govc vm.create \ -on=true \ -c=2 \ -m=4096 \ -net.adapter= \ -net= \ -e guestinfo.userdata.encoding="base64" \ -e guestinfo.userdata="$(base64 -w0 settings.toml)" \ -template= \ ``` ### Cómo actualizar los datos de usuario de una máquina virtual existente ``` govc vm.create \ -on=false \ -c=2 \ -m=4096 \ -net.adapter= \ -net= \ -template= \ govc vm.change -vm \ -e guestinfo.userdata="$(base64 -w0 settings.toml)" \ -e guestinfo.userdata.encoding="base64" govc vm.power -on ``` En las secciones anteriores, la opción `-e guestinfo.userdata.encoding="base64"` especifica que los datos de usuario están codificados en base64. La opción `-e guestinfo.userdata` transmite el contenido codificado en base64 del archivo `settings.toml` como datos de usuario a la instancia de Bottlerocket. Reemplace los marcadores de posición con los valores específicos, como la plantilla OVA de Bottlerocket y los detalles de la red. ## Paso 3: verificación de la conexión del nodo híbrido Después de que la instancia de Bottlerocket inicie, intentará unirse al clúster de Amazon EKS. Para verificar la conexión, ingrese a la consola de Amazon EKS y diríjase a la pestaña Computación del clúster o ejecute el siguiente comando: ``` kubectl get nodes ``` **importante** Los nodos tendrán el estado `Not Ready`, que es el esperado, y se debe a la falta de una CNI que se ejecute en los nodos híbridos. Si los nodos no se unieron al clúster, consulte [Solución de problemas relacionados con los nodos híbridos](hybrid-nodes-troubleshooting.md). ## Paso 4: Configuración de una CNI para los nodos híbridos Para que los nodos híbridos estén preparados para ejecutar aplicaciones, continúe con los pasos que se indican en [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md). # Actualización de nodos híbridos para el clúster Las instrucciones para actualizar los nodos híbridos son similares a aquellas de los nodos autoadministrados de Amazon EKS que se ejecutan en Amazon EC2. Le recomendamos crear nuevos nodos híbridos en la versión de Kubernetes de destino, migrar correctamente las aplicaciones existentes a los nodos híbridos de la nueva versión de Kubernetes y eliminar los nodos híbridos de la versión antigua de Kubernetes del clúster. Asegúrese de revisar las [Prácticas recomendadas de Amazon EKS](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html) para actualizaciones antes de iniciar una actualización. Los Nodos híbridos de Amazon EKS cuentan con el mismo [soporte para versiones de Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) que los clústeres de Amazon EKS con nodos en la nube, incluidos el soporte estándar y ampliado. Los Nodos híbridos de Amazon EKS siguen la misma [política de discrepancia de versiones](https://kubernetes.io/releases/version-skew-policy/#supported-version-skew) para los nodos que el proyecto fuente de Kubernetes. Los Nodos híbridos de Amazon EKS no pueden estar en una versión más reciente que el plano de control de Amazon EKS, y los nodos híbridos pueden tener hasta tres versiones menores de Kubernetes más antiguas que la versión menor del plano de control de Amazon EKS. Si no dispone de capacidad de sobra para crear nuevos nodos híbridos en la versión de Kubernetes de destino para una estrategia de actualización de migración de transición, también puede utilizar la CLI de Nodos híbridos de Amazon EKS (`nodeadm`) para actualizar la versión de Kubernetes de los nodos híbridos in situ. **importante** Si actualiza los nodos híbridos in situ con `nodeadm`, se produce un tiempo de inactividad del nodo durante el proceso en el que se apaga la versión anterior de los componentes de Kubernetes y se instalan e inician los componentes de la nueva versión de Kubernetes. ## Requisitos previos Antes de efectuar la actualización, asegúrese de que cumple los siguientes requisitos previos. + La versión de Kubernetes de destino para la actualización de los nodos híbridos debe ser igual o inferior a la versión del plano de control de Amazon EKS. + Si sigue una estrategia de actualización de migración de transición, los nuevos nodos híbridos que instale en la versión de Kubernetes de destino deben cumplir los requisitos [Configuración previa requerida para los nodos híbridos](hybrid-nodes-prereqs.md). Esto implica contar con direcciones IP dentro del CIDR de red de nodos remotos que transmitió durante la creación del clúster de Amazon EKS. + Tanto para la migración de transición como para las actualizaciones en las instalaciones, los nodos híbridos deben tener acceso a los [dominios necesarios](hybrid-nodes-networking.md#hybrid-nodes-networking-on-prem) para obtener las nuevas versiones de las dependencias de los nodos híbridos. + Debe tener kubectl instalado en la máquina local o en la instancia que utilice para interactuar con el punto de conexión de la API de Kubernetes de Amazon EKS. + La versión de la CNI debe ser compatible con la versión de Kubernetes a la que se actualiza. En caso contrario, actualice la versión de la CNI antes de actualizar los nodos híbridos. Para obtener más información, consulte [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md). ## Actualizaciones de migración por transición (azul/verde) Las *actualizaciones de migración por transición* se refieren al proceso de crear nuevos nodos híbridos en hosts nuevos con la versión de destino de Kubernetes, migrar de forma controlada las aplicaciones existentes a los nuevos nodos híbridos con la versión de destino de Kubernetes y eliminar del clúster los nodos híbridos con la versión anterior de Kubernetes. Esta estrategia también se conoce como una migración azul/verde. 1. Siga los siguientes pasos [Cómo conectar nodos híbridos](hybrid-nodes-join.md) para conectar los nuevos hosts como nodos híbridos. Al ejecutar el comando `nodeadm install`, utilice la versión de Kubernetes de destino. 1. Habilite la comunicación entre los nuevos nodos híbridos en la versión de Kubernetes de destino y los nodos híbridos en la versión antigua de Kubernetes. Esta configuración permite que los pods se comuniquen entre sí mientras la carga de trabajo se migra a los nodos híbridos de la versión de Kubernetes de destino. 1. Confirme que los nodos híbridos de la versión de Kubernetes de destino se han unido correctamente al clúster y que se encuentran en estado Preparado. 1. Utilice el siguiente comando para marcar como no programables cada uno de los nodos que desea eliminar. Esto es para que los nuevos pods no se programen ni se vuelvan a programar en los nodos que se van a reemplazar. Para obtener más información, consulte [kubectl cordon](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_cordon/) en la documentación de Kubernetes. Sustituya `NODE_NAME` por el nombre de los nodos híbridos en la versión anterior de Kubernetes. ``` kubectl cordon NODE_NAME ``` Puede identificar y marcar como no programables todos los nodos de una versión específica de Kubernetes (en este caso, la `1.28`) con el siguiente fragmento de código. ``` K8S_VERSION=1.28 for node in $(kubectl get nodes -o json | jq --arg K8S_VERSION "$K8S_VERSION" -r '.items[] | select(.status.nodeInfo.kubeletVersion | match("\($K8S_VERSION)")).metadata.name') do echo "Cordoning $node" kubectl cordon $node done ``` 1. Si la implementación actual ejecuta menos de dos réplicas de CoreDNS en los nodos híbridos, escale horizontalmente la implementación a al menos dos réplicas. Le recomendamos ejecutar al menos dos réplicas de CoreDNS en nodos híbridos para garantizar la resistencia durante las operaciones normales. ``` kubectl scale deployments/coredns --replicas=2 -n kube-system ``` 1. Vacíe cada uno de los nodos híbridos de la versión antigua de Kubernetes que desee eliminar del clúster con el siguiente comando. Para obtener más información sobre el vaciado de nodos, consulte [Vaciado seguro de nodos](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) en la documentación de Kubernetes. Sustituya `NODE_NAME` por el nombre de los nodos híbridos en la versión anterior de Kubernetes. ``` kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data ``` Puede identificar todos los nodos de una versión concreta de Kubernetes (en este caso, `1.28`) y vaciarlos con el siguiente fragmento de código. ``` K8S_VERSION=1.28 for node in $(kubectl get nodes -o json | jq --arg K8S_VERSION "$K8S_VERSION" -r '.items[] | select(.status.nodeInfo.kubeletVersion | match("\($K8S_VERSION)")).metadata.name') do echo "Draining $node" kubectl drain $node --ignore-daemonsets --delete-emptydir-data done ``` 1. Puede usar `nodeadm` para detener y eliminar los artefactos de los nodos híbridos del host. Debe ejecutar `nodeadm` con un usuario que tenga privilegios raíz/sudo. De forma predeterminada, `nodeadm uninstall` no procederá si quedan pods en el nodo. Para obtener más información, consulte [Referencia de `nodeadm` de nodos híbridos](hybrid-nodes-nodeadm.md). ``` nodeadm uninstall ``` 1. Una vez que los artefactos de los nodos híbridos estén detenidos y desinstalados, elimine el recurso de nodo del clúster. ``` kubectl delete node node-name ``` Puede identificar todos los nodos de una versión concreta de Kubernetes (en este caso, `1.28`) y eliminarlos con el siguiente fragmento de código. ``` K8S_VERSION=1.28 for node in $(kubectl get nodes -o json | jq --arg K8S_VERSION "$K8S_VERSION" -r '.items[] | select(.status.nodeInfo.kubeletVersion | match("\($K8S_VERSION)")).metadata.name') do echo "Deleting $node" kubectl delete node $node done ``` 1. Según la CNI que elija, es posible que, aún después de ejecutar los pasos anteriores, queden artefactos en los nodos híbridos. Para obtener más información, consulte [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md). ## Actualizaciones locales El proceso de actualización in situ consiste en utilizar `nodeadm upgrade` para actualizar la versión de Kubernetes para nodos híbridos sin utilizar nuevos hosts físicos o virtuales ni una estrategia de migración de transición. El proceso `nodeadm upgrade` apaga los componentes de Kubernetes antiguos existentes que se ejecutan en el nodo híbrido, desinstala los componentes de Kubernetes antiguos existentes, instala los nuevos componentes de Kubernetes de destino e inicia los nuevos componentes de Kubernetes de destino. Se recomienda enfáticamente actualizar un nodo a la vez para minimizar el impacto en las aplicaciones que se ejecutan en los nodos híbridos. La duración de este proceso depende del ancho de banda y la latencia de la red. 1. Utilice el siguiente comando para marcar como no programable el nodo que está en proceso de actualizar. Esto es para que los nuevos pods no se programen o reprogramen en el nodo que se actualiza. Para obtener más información, consulte [kubectl cordon](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_cordon/) en la documentación de Kubernetes. Sustituya `NODE_NAME` por el nombre del nodo híbrido que se actualiza ``` kubectl cordon NODE_NAME ``` 1. Vacíe el nodo que se actualiza con el siguiente comando. Para obtener más información sobre el vaciado de nodos, consulte [Vaciado seguro de nodos](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) en la documentación de Kubernetes. Sustituya `NODE_NAME` por el nombre del nodo híbrido que se actualiza. ``` kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data ``` 1. Ejecute `nodeadm upgrade` en el nodo híbrido que se actualiza. Debe ejecutar `nodeadm` con un usuario que tenga privilegios raíz/sudo. El nombre del nodo se conserva durante la actualización para los proveedores de credenciales de AWS SSM y AWS IAM Roles Anywhere. No es posible cambiar de proveedor de credenciales durante el proceso de actualización. Consulte [Referencia de `nodeadm` de nodos híbridos](hybrid-nodes-nodeadm.md) para conocer los valores de configuración de `nodeConfig.yaml`. Sustituya `K8S_VERSION` por la versión de Kubernetes de destino a la que se actualiza. ``` nodeadm upgrade K8S_VERSION -c file://nodeConfig.yaml ``` 1. Para permitir que los pods se programen en el nodo después de la actualización, escriba lo siguiente. Sustituya `NODE_NAME` por el nombre del nodo. ``` kubectl uncordon NODE_NAME ``` 1. Observe el estado de los nodos híbridos y espere a que se apaguen y reinicien en la nueva versión de Kubernetes con el estado Preparado. ``` kubectl get nodes -o wide -w ``` # Aplicación de revisiones de actualizaciones de seguridad para nodos híbridos Este tema describe el procedimiento para aplicar revisiones de actualizaciones de seguridad en el lugar para paquetes y dependencias específicos que se ejecutan en los nodos híbridos. Como buena práctica, recomendamos actualizar periódicamente los nodos híbridos para recibir actualizaciones relacionadas con vulnerabilidades (CVE) y revisiones de seguridad. Para conocer los pasos para actualizar la versión de Kubernetes, consulte [Actualización de nodos híbridos para el clúster](hybrid-nodes-upgrade.md). Un ejemplo de software que podría requerir revisiones de seguridad es `containerd`. ## `Containerd` `containerd` es el tiempo de ejecución de contenedores estándar de Kubernetes y una dependencia fundamental para los nodos híbridos de EKS. Se encarga de administrar el ciclo de vida de los contenedores, incluida la extracción de imágenes y la ejecución de los contenedores. En un nodo híbrido, puede instalar `containerd` mediante la [CLI de nodeadm](https://docs.aws.amazon.com/eks/latest/userguide/hybrid-nodes-nodeadm.html) o de forma manual. Según el sistema operativo del nodo, `nodeadm` instalará `containerd` desde el paquete distribuido por el sistema operativo o desde el paquete de Docker. Si se publica un CVE en `containerd`, tendrá las siguientes opciones para actualizar a la versión revisada de `containerd` en los nodos híbridos. ## Paso 1: Cómo comprobar si la revisión se ha publicado en los administradores de paquetes Para verificar si la revisión de la CVE de `containerd` ha sido publicada en el administrador de paquetes de cada sistema operativo, puede consultar los boletines de seguridad correspondientes: + [Amazon Linux 2023](https://alas.aws.amazon.com/alas2023.html) + [RHEL](https://access.redhat.com/security/security-updates/security-advisories) + [Ubuntu 20.04](https://ubuntu.com/security/notices?order=newest&release=focal) + [Ubuntu 22.04](https://ubuntu.com/security/notices?order=newest&release=jammy) + [Ubuntu 24.04](https://ubuntu.com/security/notices?order=newest&release=noble) Si utiliza el repositorio de Docker como origen de `containerd`, puede consultar los [Anuncios de seguridad de Docker](https://docs.docker.com/security/security-announcements/) para verificar la disponibilidad de la versión revisada en el repositorio de Docker. ## Paso 2: Cómo elegir el método para instalar la revisión Existen tres métodos para aplicar revisiones e instalar actualizaciones de seguridad en el lugar en los nodos. El método que puede utilizar depende de si la revisión está disponible en el administrador de paquetes del sistema operativo. 1. Instale revisiones con las `nodeadm upgrade` publicadas en los administradores de paquetes. Consulte el [Paso 2.a](#hybrid-nodes-security-nodeadm). 1. Instale revisiones directamente con los administradores de paquetes. Consulte el [Paso 2.b](#hybrid-nodes-security-package). 1. Instale revisiones personalizadas que no estén publicadas en los administradores de paquetes. Tenga en cuenta que existen consideraciones especiales para las revisiones personalizadas de `containerd`. Consulte el [Paso 2.c](#hybrid-nodes-security-manual). ## Paso 2.a: Aplicación de revisiones con `nodeadm upgrade` Una vez que haya confirmado que la revisión de la CVE de `containerd` ha sido publicada en los repositorios del sistema operativo o de Docker (ya sea Apt o RPM), puede utilizar el comando `nodeadm upgrade` para actualizar a la última versión de `containerd`. Como no se trata de una actualización de versión de Kubernetes, debe proporcionar la versión actual de Kubernetes al comando de actualización `nodeadm`. ``` nodeadm upgrade K8S_VERSION --config-source file:///root/nodeConfig.yaml ``` ## Paso 2.b: Aplicación de revisiones con los administradores de paquetes del sistema operativo Como alternativa, también puede actualizar a través del administrador de paquetes correspondiente y usarlo para actualizar el paquete de `containerd` de la siguiente manera. **Amazon Linux 2023** ``` sudo yum update -y sudo yum install -y containerd ``` **RHEL** ``` sudo yum install -y yum-utils sudo yum-config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo sudo yum update -y sudo yum install -y containerd ``` **Ubuntu** ``` sudo mkdir -p /etc/apt/keyrings sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt update -y sudo apt install -y --only-upgrade containerd.io ``` ## Paso 2.c: Revisión de CVE de `Containerd` no publicada en los administradores de paquetes Si la versión revisada de `containerd` solo está disponible por otros medios, en lugar de en el administrador de paquetes; por ejemplo, en las publicaciones de GitHub, puede instalar `containerd` desde el sitio oficial de GitHub. 1. Si la máquina ya se ha unido al clúster como un nodo híbrido, entonces debe ejecutar el comando `nodeadm uninstall`. 1. Instale los binarios oficiales de `containerd`. Puede seguir los [pasos de instalación oficiales](https://github.com/containerd/containerd/blob/main/docs/getting-started.md#option-1-from-the-official-binaries) disponibles en GitHub. 1. Ejecute el comando `nodeadm install` con el argumento `--containerd-source` establecido en `none`, lo que omitirá la instalación de `containerd` a través de `nodeadm`. Puede usar el valor de `none` en el origen de `containerd` para cualquier sistema operativo que el nodo ejecute. ``` nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER --containerd-source none ``` # Cómo eliminar nodos híbridos En este tema se explica cómo eliminar nodos híbridos del clúster de Amazon EKS. Debe eliminar los nodos híbridos con las herramientas compatibles con Kubernetes que elija, como [kubectl](https://kubernetes.io/docs/reference/kubectl/). El cobro por los nodos híbridos se detiene cuando el objeto del nodo se elimina del clúster de Amazon EKS. Para obtener más información sobre los precios de los nodos híbridos, consulte los [Precios de Amazon EKS](https://aws.amazon.com/eks/pricing/). **importante** La eliminación de nodos interrumpe las cargas de trabajo en ejecución en el nodo. Antes de eliminar los nodos híbridos, le recomendamos vaciar primero el nodo para trasladar los pods a otro nodo activo. Para obtener más información sobre el vaciado de nodos, consulte [Vaciado seguro de nodos](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) en la documentación de Kubernetes. Ejecute los pasos de kubectl que se indican a continuación desde la máquina o instancia local que utilice para interactuar con el punto de conexión de la API de Kubernetes del clúster de Amazon EKS. Si utiliza un archivo `kubeconfig` específico, utilice la marca `--kubeconfig`. ## Paso 1: Enumeración de los nodos ``` kubectl get nodes ``` ## Paso 2: Vaciado del nodo Consulte [Vaciado de kubectl](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_drain/) en la documentación de Kubernetes para obtener más información sobre el comando `kubectl drain`. ``` kubectl drain --ignore-daemonsets ``` ## Paso 3: Detención y desinstalación de artefactos de nodos híbridos Puede usar la CLI (`nodeadm`) de los Nodos híbridos de Amazon EKS para detener y eliminar los artefactos de nodos híbridos del host. Debe ejecutar `nodeadm` con un usuario que tenga privilegios raíz/sudo. De forma predeterminada, `nodeadm uninstall` no procederá si quedan pods en el nodo. Si utiliza AWS Systems Manager (SSM) como proveedor de credenciales, el comando `nodeadm uninstall` anula el registro del host como instancia administrada por AWS SSM. Para obtener más información, consulte [Referencia de `nodeadm` de nodos híbridos](hybrid-nodes-nodeadm.md). ``` nodeadm uninstall ``` ## Paso 4: Cómo eliminar el nodo del clúster Una vez que los artefactos de los nodos híbridos estén detenidos y desinstalados, elimine el recurso de nodo del clúster. ``` kubectl delete node ``` ## Paso 5: Cómo comprobar si hay artefactos restantes Según la CNI que elija, es posible que, aún después de ejecutar los pasos anteriores, queden artefactos en los nodos híbridos. Para obtener más información, consulte [Configuración de una CNI para nodos híbridos](hybrid-nodes-cni.md).