AMI de Amazon Linux optimizada para Amazon EKS - Amazon EKS
Actualización de AL2 a AL2023AceleradaArmPrueba de la migración de Docker a containerdMás información

AMI de Amazon Linux optimizada para Amazon EKS

La AMI de Amazon Linux optimizada para Amazon EKS, está construida sobre Amazon Linux 2 (AL2) y Amazon Linux 2023 (AL2023). Está configurada de modo que sirva de imagen base para los nodos de Amazon EKS. La AMI está configurada para funcionar con Amazon EKS e incluye los siguientes componentes:

  • kubelet

  • Autenticador de AWS IAM

  • Docker (versión de Amazon EKS 1.23 y anterior)

  • containerd

nota

  • Puede realizar un seguimiento de los eventos de seguridad o privacidad de AL2 en el Centro de seguridad de Amazon Linux o suscribirse a la fuente RSS asociada. 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.

  • Antes de implementar una AMI acelerada o de Arm, revise la información en AMI de Amazon Linux acelerada optimizada para Amazon EKS y AMI de Amazon Linux optimizada para Amazon EKS Arm.

  • Para la versión1.23 de Kubernetes, puede utilizar un indicador de arranque opcional para probar la migración de Docker a containerd. Para obtener más información, consulte Prueba de la migración de Docker a containerd.

  • A partir de la versión 1.25 de Kubernetes, ya no podrá utilizar instancias P2 de Amazon EC2 con las AMI de Amazon Linux aceleradas y optimizadas de Amazon EKS listas para usar. Estas AMI para las versiones 1.25 o posteriores de Kubernetes serán compatibles con controladores de la serie NVIDIA 525 o posteriores, que son incompatibles con las instancias P2. Sin embargo, los controladores de la serie NVIDIA 525 o posteriores son compatibles con las instancias P3, P4 y P5, de modo que puede utilizarlas con las AMI para la versión 1.25 o posterior de Kubernetes. Antes de que sus clústeres de Amazon EKS se actualicen a la versión 1.25, migre todas las instancias P2 a instancias P3, P4 y P5. También debe actualizar sus aplicaciones de manera proactiva para que funcionen con la serie NVIDIA 525 o posterior. Tenemos previsto volver a portar los controladores más recientes de la serie NVIDIA 525 o posteriores a las versiones 1.23 y 1.24 de Kubernetes a finales de enero de 2024.

  • A partir de la versión 1.30 o posterior de Amazon EKS, todos los grupos de nodos administrados recién creados utilizarán automáticamente AL2023 como sistema operativo de nodos de forma predeterminada. Anteriormente, los nuevos grupos de nodos utilizaban AL2 de forma predeterminada. Puede seguir utilizando AL2 si lo elige como tipo de AMI cuando crea un nuevo grupo de nodos.

  • AL2 dejará de ser compatible el 30 de junio de 2025. Para obtener más información, consulte las Preguntas frecuentes de Amazon Linux 2.

Actualización de AL2 a AL2023

La AMI optimizada de Amazon EKS está disponible en dos familias con base en AL2 y AL2023. AL2023 es un nuevo sistema operativo basado en Linux diseñado para proporcionar un entorno seguro, estable y de alto rendimiento para las aplicaciones en la nube. Es la próxima generación de Amazon Linux de Amazon Web Services y está disponible en todas las versiones compatibles de Amazon EKS, incluidas las versiones 1.23 y 1.24 con soporte ampliado. Las AMI aceleradas de Amazon EKS basadas en AL2023 estarán disponibles en una fecha posterior. Si tiene cargas de trabajo aceleradas, debe seguir utilizando la AMI acelerada de AL2 o Bottlerocket.

AL2023 ofrece varias mejoras con respecto al AL2. Para obtener una comparación completa, consulte Comparación de AL2 y Amazon Linux 2023 en la Guía del usuario de Amazon Linux 2023. Se han añadido, actualizado y eliminado varios paquetes de AL2. Se recomienda encarecidamente probar las aplicaciones con AL2023 antes de realizar la actualización. Para ver una lista de todos los cambios de paquetes en AL2023, consulte Cambios de paquetes en Amazon Linux 2023 en las Notas de la versión de Amazon Linux 2023.

Además de estos cambios, debe tener en cuenta lo siguiente:

  • AL2023 presenta un nuevo proceso de inicialización de nodos nodeadm que utiliza un esquema de configuración YAML. Si utiliza grupos de nodos autoadministrados o una AMI con una plantilla de lanzamiento, ahora tendrá que proporcionar metadatos del clúster adicionales de forma explícita cuando cree un nuevo grupo de nodos. A continuación, se muestra un ejemplo de los parámetros mínimos necesarios, en los que ahora se necesitan apiServerEndpoint, certificateAuthority y el servicio de cidr:

    ---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name: my-cluster
    apiServerEndpoint: https://example.com
    certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
    cidr: 10.100.0.0/16

    En AL2, los metadatos de estos parámetros se descubrieron a partir de la llamada a la API DescribeCluster de Amazon EKS. Con AL2023, este comportamiento ha cambiado, ya que la llamada a la API adicional corre el riesgo de limitarse durante los escalados verticales de nodos a gran escala. Este cambio no le afecta si utiliza grupos de nodos administrados sin una plantilla de lanzamiento o si utiliza Karpenter. Para obtener más información sobre certificateAuthority y el servicio de cidr, consulte DescribeCluster en la Referencia de la API de Amazon EKS.

  • Docker no es compatible con AL2023 para todas las versiones compatibles de Amazon EKS. La compatibilidad con Docker finalizó y se eliminó con la versión 1.24 o posterior de Amazon EKS en AL2. Para obtener más información sobre la obsolescencia, consulte Amazon EKS ya no es compatible con Dockershim.

  • Se requiere la versión 1.16.2 o posterior de CNI de Amazon VPC para AL2023.

  • De forma predeterminada, AL2023 requiere IMDSv2. IMDSv2 tiene varios beneficios que ayudan a mejorar la postura de seguridad. Utiliza un método de autenticación orientado a la sesión que requiere la creación de un token secreto en una solicitud sencilla de HTTP PUT para iniciar la sesión. El tiempo de validez de un token de sesión puede oscilar entre 1 segundo y 6 horas. Para obtener más información sobre cómo realizar la transición de IMDSv1 a IMDSv2, consulte Transición a la versión 2 del servicio de metadatos de instancias y Cómo aprovechar todos los beneficios de IMDSv2 e inhabilitar IMDSv1 en toda la infraestructura de AWS. Si desea utilizar IMDSv1, puede hacerlo si anula de manera manual la configuración mediante las propiedades de inicio de la opción de metadatos de la instancia.

    nota

    Para IMDSv2, el recuento de saltos predeterminado para los grupos de nodos administrados se establece en 1. Esto significa que los contenedores no tendrán acceso a las credenciales del nodo mediante IMDS. Si necesita acceso del contenedor a las credenciales del nodo, debe anular HttpPutResponseHopLimit de manera manual en una plantilla de lanzamiento personalizada de Amazon EC2 y aumentarlo a 2. Como alternativa, puede utilizar Pod Identity de Amazon EKS para proporcionar credenciales en lugar de IMDSv2.

  • AL2023 presenta la siguiente generación de jerarquías de grupos de control unificados (cgroupv2). cgroupv2 se utiliza para implementar un tiempo de ejecución de contenedores y por systemd. Si bien AL2023 sigue incluyendo un código que puede hacer que el sistema funcione con cgroupv1, esta configuración no se recomienda ni se admite. Esta configuración se eliminará por completo en una futura versión importante de Amazon Linux.

En el caso de los grupos de nodos administrados que existían con anterioridad, puede realizar una actualización local o una actualización azul/verde, según cómo utilice la plantilla de lanzamiento:

  • Si utiliza una AMI personalizada con un grupo de nodos administrado, puede realizar una actualización local si intercambia el ID de la AMI en la plantilla de lanzamiento. Debe asegurarse de que las aplicaciones y cualquier dato de usuario se transfieran primero a AL2023 antes de llevar a cabo esta estrategia de actualización.

  • Si utiliza grupos de nodos administrados con la plantilla de lanzamiento estándar o con una plantilla de lanzamiento personalizada que no especifica el ID de la AMI, deberá actualizar mediante una estrategia azul/verde. Una actualización azul/verde suele ser más compleja e implica la creación de un grupo de nodos completamente nuevo en el que se especificará AL2023 como tipo de AMI. Luego, será necesario configurar con cuidado el nuevo grupo de nodos para garantizar que todos los datos personalizados del grupo de nodos de AL2 sean compatibles con el nuevo sistema operativo. Una vez que el nuevo grupo de nodos se haya probado y validado con sus aplicaciones, podrá migrar Pods del grupo de nodos anterior al nuevo grupo de nodos. Una vez completada la migración, puede eliminar el grupo de nodos anterior.

Si utiliza Karpenter y quiere utilizar AL2023, deberá modificar el campo EC2NodeClass amiFamily con AL2023. De forma predeterminada, la desviación está habilitada en Karpenter. Esto significa que, una vez que se haya cambiado el campo amiFamily, Karpenter actualizará automáticamente los nodos de trabajo a la AMI más reciente cuando esté disponible.

AMI de Amazon Linux acelerada optimizada para Amazon EKS

nota

Las AMI aceleradas de Amazon EKS basadas en AL2023 estarán disponibles en una fecha posterior. Si tiene cargas de trabajo aceleradas, debe seguir utilizando la AMI acelerada de AL2 o Bottlerocket.

La AMI de Amazon Linux acelerada optimizada para Amazon EKS se basa en la AMI de Amazon Linux optimizada estándar de Amazon EKS. Está configurada de modo que sirva como imagen opcional para los nodos de Amazon EKS a fin de admitir GPU y cargas de trabajo basadas en Inferentia y Trainium.

Además de la configuración de la AMI optimizada para Amazon EKS estándar, la AMI acelerada incluye lo siguiente:

  • Controladores NVIDIA

  • El nvidia-container-runtime (como tiempo de ejecución predeterminado)

  • Tiempo de ejecución del contenedor AWS Neuron

Para obtener una lista de los componentes más recientes incluidos en la AMI acelerada, consulte las versiones amazon-eks-ami en GitHub.

nota

  • La AMI acelerada optimizada para Amazon EKS solo admite tipos de instancias basadas en GPU e Inferentia. Asegúrese de especificar estos tipos de instancia en la plantilla de nodos de AWS CloudFormation. Al utilizar la AMI acelerada optimizada para Amazon EKS, acepta el acuerdo de licencia de usuario (EULA) de NVIDIA.

  • La AMI acelerada optimizada para Amazon EKS se denominaba anteriormente AMI optimizada para Amazon EKS compatible con GPU.

  • Las versiones anteriores de la AMI acelerada optimizada para Amazon EKS instalaron el repositorio nvidia-docker. El repositorio ya no se incluye en la versión v20200529 de la AMI de Amazon EKS y versiones posteriores.

Habilitar cargas de trabajo basadas en GPU

El siguiente procedimiento describe cómo ejecutar una carga de trabajo en una instancia basada en GPU con la AMI acelerada optimizada para Amazon EKS. Para ver otras opciones, consulte las siguientes referencias:

  1. Una vez que los nodos de GPU estén unidos al clúster, debe aplicar el complemento de dispositivos NVIDIA para Kubernetes como un DaemonSet en su clúster. Reemplace vX.X.X con la versión Plugin de dispositivo NVidia/K8Sdeseada antes de ejecutar el siguiente comando.

    kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X.X/nvidia-device-plugin.yml

  2. Puede verificar que los nodos tienen GPU asignables con el siguiente comando.

    kubectl get nodes "-o=custom-columns=NAME:.metadata.name,GPU:.status.allocatable.nvidia\.com/gpu"
Implementar un Pod con el fin de probar que los nodos de la GPU están configurados correctamente

  1. Cree un archivo denominado nvidia-smi.yaml con el siguiente contenido. Reemplace tagcon la etiqueta deseada para nvidia/cuda. Este manifiesto lanza un contenedor de NVIDIA CUDA que ejecuta nvidia-smi en un nodo de trabajo.

    apiVersion: v1
kind: Pod
metadata:
  name: nvidia-smi
spec:
  restartPolicy: OnFailure
  containers:
  - name: nvidia-smi
    image: nvidia/cuda:tag
    args:
    - "nvidia-smi"
    resources:
      limits:
        nvidia.com/gpu: 1

  2. Aplique el manifiesto con el siguiente comando.

    kubectl apply -f nvidia-smi.yaml

  3. Una vez que el Pod termine de ejecutarse, consulte sus registros con el siguiente comando.

    kubectl logs nvidia-smi

    Un ejemplo de salida sería el siguiente.

    Mon Aug  6 20:23:31 20XX
+-----------------------------------------------------------------------------+
| NVIDIA-SMI XXX.XX                 Driver Version: XXX.XX                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  Tesla V100-SXM2...  On   | 00000000:00:1C.0 Off |                    0 |
| N/A   46C    P0    47W / 300W |      0MiB / 16160MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

AMI de Amazon Linux optimizada para Amazon EKS Arm

Las instancias Arm ofrecen un importante ahorro de costos para aplicaciones de escalado horizontal y aplicaciones basadas en Arm, como servidores web, microservicios en contenedores, flotas de almacenamiento en caché y almacenes de datos distribuidos. Al agregar nodos de Arm al clúster, tenga en cuenta las siguientes consideraciones.

Consideraciones

  • Si el clúster se implementó antes del 17 de agosto de 2020, debe realizar una actualización única de los manifiestos complementarios de clúster críticos. Esto es para que Kubernetes pueda extraer la imagen correcta para cada arquitectura de hardware que se utilice en el clúster. Para obtener más información acerca de la actualización de complementos de clúster, consulte Actualice la versión de Kubernetes de un clúster de Amazon EKS. Si implementó el clúster a partir del 17 de agosto de 2020, entonces sus complementos CoreDNS, kube-proxy y Amazon VPC CNI plugin for Kubernetes ya son aptos en múltiples arquitecturas.

  • Las aplicaciones implementadas en los nodos de Arm deben compilarse para Arm.

  • Si tiene algún DaemonSets implementado en un clúster existente o desea implementarlos en un clúster nuevo en el que también quiera implementar nodos de Arm, compruebe que el DaemonSet se pueda ejecutar en todas las arquitecturas de hardware del clúster.

  • Puede ejecutar grupos de nodos de Arm y grupos de nodos x86 en el mismo clúster. Si lo hace, considere la posibilidad de implementar imágenes de contenedor de varias arquitecturas en un repositorio de contenedores como Amazon Elastic Container Registry y, a continuación, agregar selectores de nodo a los manifiestos para que Kubernetes sepa en qué arquitectura de hardware se puede implementar un Pod. Para obtener más información, consulte Introducir una imagen de varias arquitecturas en la Guía del usuario de Amazon ECR y en la publicación del blog Introducing multi-architecture container images for Amazon ECR.

Prueba de la migración de Docker a containerd

Amazon EKS dejó de estar disponible para Docker a partir del lanzamiento de la versión 1.24 de Kubernetes. Para obtener más información, consulte Amazon EKS dejó de ser compatible con Dockershim.

Para la versión 1.23 de Kubernetes, puede utilizar una marca de arranque opcional para habilitar el tiempo de ejecución containerd de las AMI de AL2 optimizadas para Amazon EKS. Esta característica le otorga una ruta clara para migrar a containerd al actualizar a una versión 1.24 o posterior. Amazon EKS dejó de estar disponible para Docker a partir del lanzamiento de la versión 1.24 de Kubernetes. El tiempo de ejecución containerd ha sido ampliamente adoptado en la comunidad de Kubernetes y es un proyecto graduado con la CNCF. Puede probarlo al agregarle un grupo de nodos a un clúster nuevo o existente.

Puede habilitar el indicador del arranque al crear uno de los siguientes tipos de grupos de nodos.

Autoadministrado

Cree el grupo de nodos con las instrucciones en Lanzar nodos autoadministrados de Amazon Linux. Especifique una AMI optimizada para Amazon EKS y el siguiente texto para el parámetro BootstrapArguments.

--container-runtime containerd
Administrado

Si utiliza eksctl, cree un archivo llamado my-nodegroup.yaml con el siguiente contenido. Reemplace cada example value con valores propios. 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. Para recuperar un ID de AMI optimizada para ami-1234567890abcdef0, consulte Recuperación de los ID de la AMI de Amazon Linux optimizada para Amazon EKS.

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: my-cluster
  region: region-code
  version: 1.23
managedNodeGroups:
  - name: my-nodegroup
    ami: ami-1234567890abcdef0
    overrideBootstrapCommand: |
      #!/bin/bash
      /etc/eks/bootstrap.sh my-cluster --container-runtime containerd
nota

Si lanza muchos nodos al mismo tiempo, es posible que desee especificar también valores para los argumentos --apiserver-endpoint, --b64-cluster-ca y --dns-cluster-ip de arranque para evitar errores. Para obtener más información, consulte Especificación de una AMI.

Ejecute el siguiente comando para crear el grupo de nodos.

eksctl create nodegroup -f my-nodegroup.yaml

Si prefiere utilizar una herramienta diferente para crear el grupo de nodos administrado, debe implementar el grupo de nodos mediante una plantilla de lanzamiento. En la plantilla de lanzamiento, especifique un ID de AMI optimizada para Amazon EKS y, a continuación, implemente el grupo de nodos mediante una plantilla de lanzamiento y proporcione los siguientes datos de usuario. Estos datos de usuario pasan los argumentos en el archivo bootstrap.sh. Para obtener más información acerca del archivo del proceso de arranque, consulte bootstrap.sh en GitHub.

/etc/eks/bootstrap.sh my-cluster --container-runtime containerd

Más información

Para obtener más información sobre el uso de las AMI de Amazon Linux optimizadas para Amazon EKS, consulte las siguientes secciones: