**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.
# Cómo preparar el sistema operativo para los nodos híbridos
Bottlerocket, Amazon Linux 2023 (AL2023), Ubuntu y RHEL se validan de forma continua para su uso como sistema operativo de nodo para los nodos híbridos. Bottlerocket es compatible únicamente con AWS en los entornos VMware vSphere. Los planes de AWS Support no cubren AL2023 cuando se ejecuta fuera de Amazon EC2. AL2023 solo se puede utilizar en entornos virtualizados en las instalaciones. Consulte la [Guía del usuario de Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/outside-ec2.html) para obtener más información. AWS admite la integración de nodos híbridos con los sistemas operativos Ubuntu y RHEL, pero no proporciona soporte para los sistemas operativos en sí.
Usted es responsable del aprovisionamiento y la administración del sistema operativo. Al probar nodos híbridos por primera vez, lo más sencillo es ejecutar la CLI de Nodos híbridos de Amazon EKS (`nodeadm`) en un host ya aprovisionado. En el caso de implementaciones en producción, se recomienda incluir `nodeadm` en las imágenes del sistema operativo, configurado para ejecutarse como un servicio de systemd, de modo que los hosts se unan automáticamente a los clústeres de Amazon EKS al iniciar. Si usa Bottlerocket como sistema operativo de nodo en vSphere, no es necesario utilizar `nodeadm`, ya que Bottlerocket incluye las dependencias necesarias para nodos híbridos y se conectará automáticamente al clúster configurado al iniciar el host.
## Compatibilidad de versiones
La tabla que aparece a continuación representa las versiones del sistema operativo compatibles y validadas para su uso como sistema operativo de nodo para nodos híbridos. Si utiliza otras variantes o versiones del sistema operativo que no aparecen en esta tabla, la compatibilidad de los nodos híbridos con la variante o versión del sistema operativo no está cubierta por AWS Support. Los nodos híbridos son independientes de la infraestructura subyacente y admiten arquitecturas x86 y ARM.
| Sistema operativo | Versiones |
| --- | --- |
| Amazon Linux | Amazon Linux 2023 (AL2023) |
| Bottlerocket | Variantes de VMware desde la v1.37.0 en adelante que ejecutan Kubernetes v1.28 o superior |
| Ubuntu | Ubuntu 20.04, Ubuntu 22.04, Ubuntu 24.04 |
| Red Hat Enterprise Linux | RHEL 8, RHEL 9 |
## Consideraciones de los sistemas operativos
### General
+ La CLI (`nodeadm`) de los Nodos híbridos de Amazon EKS se puede utilizar para simplificar la instalación y configuración de los componentes y dependencias de los nodos híbridos. Puede ejecutar el proceso `nodeadm install` durante las canalizaciones de creación de imágenes del sistema operativo o en tiempo de ejecución en cada host en las instalaciones. Para más información sobre los componentes que `nodeadm` instala, consulte el [Referencia de `nodeadm` de nodos híbridos](hybrid-nodes-nodeadm.md).
+ Si utiliza un proxy en el entorno en las instalaciones para acceder a Internet, se requiere una configuración adicional del sistema operativo para que los procesos de instalación y actualización configuren el administrador de paquetes para utilizar el proxy. Para obtener instrucciones, consulte [Configuración del proxy para nodos híbridos](hybrid-nodes-proxy.md).
### Bottlerocket
+ Los pasos y herramientas para conectar un nodo de Bottlerocket son diferentes de los requeridos para otros sistemas operativos y se abordan por separado en [Conexión de nodos híbridos con Bottlerocket](hybrid-nodes-bottlerocket.md), en lugar de los pasos indicados en [Cómo conectar nodos híbridos](hybrid-nodes-join.md).
+ Los pasos para Bottlerocket no requieren el uso de la herramienta de interfaz de la línea de comandos (CLI) para nodos híbridos, `nodeadm`.
+ Solo se admiten las variantes de VMware de Bottlerocket a partir de la versión v1.37.0 con los Nodos híbridos de EKS. Las variantes de VMware de Bottlerocket están disponibles para las versiones v1.28 y posteriores de Kubernetes. [Otras variantes de Bottlerocket](https://bottlerocket.dev/en/os/1.36.x/concepts/variants) no son compatibles como sistema operativo de nodos híbridos. NOTA: Las variantes de VMware de Bottlerocket solo se encuentran disponibles para la arquitectura x86\$164.
### Containerd
+ Containerd es el tiempo de ejecución de contenedores estándar de Kubernetes y es una dependencia para los nodos híbridos, así como para todos los tipos de computación de nodos de Amazon EKS. La CLI (`nodeadm`) de los Nodos Híbridos de Amazon EKS intenta instalar containerd durante el proceso `nodeadm install`. Puede configurar la instalación de containerd en tiempo de ejecución de `nodeadm install` con la opción de línea de comandos `--containerd-source`. Las opciones válidas son `none`, `distro` y `docker`. Si utiliza RHEL, `distro` no es una opción válida y puede, o bien configurar `nodeadm` para instalar la compilación containerd desde los repositorios de Docker, o instalar containerd manualmente. Cuando se usa AL2023 o Ubuntu, `nodeadm` instala containerd desde la distribución del sistema operativo de forma predeterminada. Si no quiere que nodeadm instale containerd, use la opción `--containerd-source none`.
### Ubuntu
+ Si usa Ubuntu 24.04, es posible que tenga que actualizar la versión de containerd o cambiar la configuración de AppArmor para adoptar una corrección que permita que los pods se terminen correctamente. Consulte [Ubuntu \$12065423](https://bugs.launchpad.net/ubuntu/+source/containerd-app/\+bug/2065423). Se requiere un reinicio para aplicar los cambios al perfil de AppArmor. La versión más reciente de Ubuntu 24.04 tiene una versión actualizada de containerd en su administrador de paquetes con la corrección (versión 1.7.19\$1 de containerd).
### ARM
+ Si utiliza hardware de ARM, se requiere un procesador compatible con ARMv8.2 con la extensión de criptografía (ARMv8.2\$1crypto) para ejecutar la versión 1.31 o posterior del complemento kube-proxy de EKS. Todos los sistemas Raspberry Pi anteriores a Raspberry Pi 5, así como los procesadores basados en Cortex-A72, no cumplen este requisito. Como solución alternativa, puede seguir utilizando la versión 1.30 del complemento kube-proxy de EKS hasta que finalice el soporte extendido en julio de 2026 (consulte el [calendario de lanzamiento de Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) o utilice una imagen de kube-proxy personalizada ascendente).
+ El siguiente mensaje de error del registro de kube-proxy indica esta incompatibilidad:
```
Fatal glibc error: This version of Amazon Linux requires a newer ARM64 processor compliant with at least ARM architecture 8.2-a with Cryptographic extensions. On EC2 this is Graviton 2 or later.
```
## Creación de imágenes del sistema operativo
Amazon EKS proporciona [plantillas Packer de ejemplo](https://github.com/aws/eks-hybrid/tree/main/example/packer) que se pueden utilizar para crear imágenes del sistema operativo que incluyan `nodeadm` y lo configuren de modo que se ejecute al iniciar el host. Este proceso se recomienda para no tener que extraer las dependencias de los nodos híbridos individualmente en cada host y para automatizar el proceso de arranque de los nodos híbridos. Puede utilizar las plantillas Packer de ejemplo con una imagen ISO de Ubuntu 22.04, Ubuntu 24.04, RHEL 8 o RHEL 9 y puede obtener imágenes con estos formatos: OVA, Qcow2 o sin procesar.
### Requisitos previos
Antes de utilizar las plantillas Packer de ejemplo, debe tener instalado lo siguiente en la máquina desde la que ejecuta Packer.
+ Versión 1.11.0 o superior de Packer. Para obtener instrucciones sobre cómo instalar Packer, consulte [Instalación de Packer](https://developer.hashicorp.com/packer/tutorials/docker-get-started/get-started-install-cli) en la documentación de Packer.
+ Si se crean OVA, la versión 1.4.0 o superior del complemento VMware vSphere.
+ Si crea imágenes `Qcow2` o sin procesar, utilice la versión 1.x del complemento QEMU
### Configuración de las variables de entorno
Antes de ejecutar la compilación de Packer, establezca las siguientes variables de entorno en la máquina desde la que ejecuta Packer.
**General**
Se deben establecer las siguientes variables de entorno para crear imágenes con todos los sistemas operativos y formatos de salida.
| Variable de entorno | Tipo | Descripción |
| --- | --- | --- |
| PKR\$1SSH\$1PASSWORD | Cadena | Durante el aprovisionamiento, Packer utiliza las variables `ssh_username` y `ssh_password` para acceder mediante SSH a la máquina creada. Esto debe coincidir con las contraseñas utilizadas para crear el usuario inicial dentro de los archivos kickstart o user-data del SO respectivo. El valor predeterminado se establece como “builder” o “ubuntu” según el sistema operativo. Al configurar la contraseña, asegúrese de cambiarla dentro del archivo `ks.cfg` o `user-data` correspondiente de modo que coincida. |
| ISO\$1URL | Cadena | URL de la ISO que se va a utilizar. Puede ser un enlace web para descargar de un servidor, o una ruta absoluta a un archivo local |
| ISO\$1CHECKSUM | Cadena | Suma de comprobación asociada para la ISO suministrada. |
| CREDENTIAL\$1PROVIDER | Cadena | Proveedor de credenciales para nodos híbridos. Los valores válidos son `ssm` (predeterminados) para las activaciones híbridas de SSM y `iam` para IAM Roles Anywhere |
| K8S\$1VERSION | Cadena | Versión de Kubernetes para nodos híbridos (por ejemplo, `1.31`). Para ver las versiones de Kubernetes compatibles, consulte las [versiones compatibles de Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html). |
| NODEADM\$1ARCH | Cadena | Arquitecturas para `nodeadm install`. Seleccione `amd` o `arm`. |
**RHEL**
Si utiliza RHEL, se deben configurar las siguientes variables de entorno.
| Variable de entorno | Tipo | Descripción |
| --- | --- | --- |
| RH\$1USERNAME | Cadena | Nombre de usuario del administrador de suscripciones de RHEL |
| RH\$1PASSWORD | Cadena | Contraseña del administrador de suscripciones de RHEL |
| RHEL\$1VERSION | Cadena | La versión iso de Rhel que se utiliza. Los valores válidos son `8` o `9`. |
**Ubuntu**
No se requieren variables de entorno específicas de Ubuntu.
**vSphere**
Si va a crear un OVA de VMware vSphere, deberá configurar las siguientes variables de entorno.
| Variable de entorno | Tipo | Descripción |
| --- | --- | --- |
| VSPHERE\$1SERVER | Cadena | Dirección del servidor vSphere |
| VSPHERE\$1USER | Cadena | Nombre de usuario de vSphere |
| VSPHERE\$1PASSWORD | Cadena | Contraseña de vSphere |
| VSPHERE\$1DATACENTER | Cadena | Nombre del centro de datos de vSphere |
| VSPHERE\$1CLUSTER | Cadena | Nombre del clúster de vSphere |
| VSPHERE\$1DATASTORE | Cadena | Nombre del almacén de datos de vSphere |
| VSPHERE\$1NETWORK | Cadena | Nombre de la red de vSphere |
| VSPHERE\$1OUTPUT\$1FOLDER | Cadena | Carpeta de salida de vSphere para las plantillas |
**QEMU**
| Variable de entorno | Tipo | Descripción |
| --- | --- | --- |
| PACKER\$1OUTPUT\$1FORMAT | Cadena | Formato de salida para el generador QEMU. Los valores válidos son `qcow2` y `raw`. |
**Validación de la plantilla**
Antes de ejecutar la compilación, valide la plantilla con el siguiente comando después de configurar las variables de entorno. Sustituya `template.pkr.hcl` si utiliza un nombre diferente para la plantilla.
```
packer validate template.pkr.hcl
```
### Generación de imágenes
Genere las imágenes con los siguientes comandos y utilice la marca `-only` para especificar el destino y el sistema operativo de las imágenes. Sustituya `template.pkr.hcl` si utiliza un nombre diferente para la plantilla.
**OVA de vSphere**
**nota**
Si utiliza RHEL con vSphere necesita convertir los archivos kickstart a una imagen OEMDRV y transmitirla como una ISO desde la que arrancar. Para obtener más información, consulte [Readme de Packer](https://github.com/aws/eks-hybrid/tree/main/example/packer#utilizing-rhel-with-vsphere) en el repositorio de GitHub de los Nodos híbridos de EKS.
**OVA de Ubuntu**
```
packer build -only=general-build.vsphere-iso.ubuntu22 template.pkr.hcl
```
**OVA de Ubuntu**
```
packer build -only=general-build.vsphere-iso.ubuntu24 template.pkr.hcl
```
**OVA de RHEL**
```
packer build -only=general-build.vsphere-iso.rhel8 template.pkr.hcl
```
**OVA de RHEL**
```
packer build -only=general-build.vsphere-iso.rhel9 template.pkr.hcl
```
**QEMU**
**nota**
Si va a generar una imagen para una CPU de host específica que no coincide con el host del generador, consulte la documentación de [QEMU](https://www.qemu.org/docs/master/system/qemu-cpu-models.html) para obtener el nombre que coincida con la CPU de host y utilice la marca `-cpu` con el nombre de la CPU de host cuando ejecute los siguientes comandos.
**Ubuntu 22.04 Qcow2/sin procesar**
```
packer build -only=general-build.qemu.ubuntu22 template.pkr.hcl
```
**Ubuntu 24.04 Qcow2/sin procesar**
```
packer build -only=general-build.qemu.ubuntu24 template.pkr.hcl
```
**RHEL 8 Qcow2/sin procesar**
```
packer build -only=general-build.qemu.rhel8 template.pkr.hcl
```
**RHEL 9 Qcow2/sin procesar**
```
packer build -only=general-build.qemu.rhel9 template.pkr.hcl
```
### Cómo transmitir la configuración de nodeadm a través de user-data
Puede transmitir la configuración de `nodeadm` en los user-data a través de cloud-init para configurar y conectar automáticamente los nodos híbridos al clúster de EKS al iniciar el host. A continuación, encontrará un ejemplo de cómo lograrlo al utilizar VMware vSphere como infraestructura para los nodos híbridos.
1. Instale la CLI de `govc` según las instrucciones del archivo [govc readme](https://github.com/vmware/govmomi/blob/main/govc/README.md) en GitHub.
1. Después de ejecutar la compilación de Packer en la sección anterior y aprovisionar la plantilla, podrá clonar la plantilla para crear varios nodos diferentes de la siguiente manera. Debe clonar la plantilla para cada nueva máquina virtual que cree y que vaya a utilizar para nodos híbridos. Sustituya las variables del comando que aparece a continuación por los valores correspondientes al entorno. El `VM_NAME` en el comando que aparece a continuación se utiliza como `NODE_NAME` cuando se introducen los nombres de las máquinas virtuales a través del archivo `metadata.yaml`.
```
govc vm.clone -vm "/PATH/TO/TEMPLATE" -ds="YOUR_DATASTORE" \
-on=false -template=false -folder=/FOLDER/TO/SAVE/VM "VM_NAME"
```
1. Después de clonar la plantilla para cada una de sus nuevas máquinas virtuales, cree un `userdata.yaml` y `metadata.yaml` para las máquinas virtuales. Las máquinas virtuales pueden compartir los mismos `userdata.yaml` y `metadata.yaml`, que deberá completar según cada máquina virtual y a través de los pasos que se indican a continuación. La configuración `nodeadm` se crea y define en la sección `write_files` del `userdata.yaml`. En el siguiente ejemplo, se utilizan las activaciones híbridas de AWS SSM como proveedor de credenciales en las instalaciones para los nodos híbridos. Para obtener más información sobre la configuración de `nodeadm`, consulte [Referencia de `nodeadm` de nodos híbridos](hybrid-nodes-nodeadm.md).
**userdata.yaml:**
```
#cloud-config
users:
- name: # username for login. Use 'builder' for RHEL or 'ubuntu' for Ubuntu.
passwd: # password to login. Default is 'builder' for RHEL.
groups: [adm, cdrom, dip, plugdev, lxd, sudo]
lock-passwd: false
sudo: ALL=(ALL) NOPASSWD:ALL
shell: /bin/bash
write_files:
- path: /usr/local/bin/nodeConfig.yaml
permissions: '0644'
content: |
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: # Cluster Name
region: # AWS region
hybrid:
ssm:
activationCode: # Your ssm activation code
activationId: # Your ssm activation id
runcmd:
- /usr/local/bin/nodeadm init -c file:///usr/local/bin/nodeConfig.yaml >> /var/log/nodeadm-init.log 2>&1
```
**metadata.yaml:**
Cree un `metadata.yaml` para el entorno. Mantenga el formato de la variable `"$NODE_NAME"` en el archivo, ya que este se completará con valores en un paso posterior.
```
instance-id: "$NODE_NAME"
local-hostname: "$NODE_NAME"
network:
version: 2
ethernets:
nics:
match:
name: ens*
dhcp4: yes
```
1. Agregue los archivos `userdata.yaml` y `metadata.yaml` como cadenas `gzip+base64` con los siguientes comandos. Se deben ejecutar los siguientes comandos para cada una de las máquinas virtuales que se van a crear. Sustituya `VM_NAME` por el nombre de la máquina virtual que va a actualizar.
```
export NODE_NAME="VM_NAME"
export USER_DATA=$(gzip -c9 metadata.yaml.tmp
export METADATA=$(gzip -c9