Migración de dockershim a containerd - Amazon EKS
Prueba de la migración

Ayude a mejorar esta página

¿Quiere contribuir a esta guía del usuario? Desplácese hasta el final de esta página y seleccione Editar esta página en GitHub. Sus contribuciones ayudarán a que nuestra guía del usuario sea mejor para todos.

Migración de dockershim a containerd

Kubernetes ya no es compatible con dockershim. El equipo de Kubernetes eliminó el tiempo de ejecución en la versión 1.24 de Kubernetes. Para obtener más información, consulte Kubernetes is Moving on From Dockershim: Commitments and Next Steps en el blog de Kubernetes.

Amazon EKS también dejará de ser compatible con dockershim a partir del lanzamiento de la versión 1.24 de Kubernetes. Las AMI de Amazon EKS publicadas oficialmente incluyen containerd como único tiempo de ejecución a partir de la versión 1.24. En este tema se describen algunos detalles, pero hay más información disponible en Todo lo que necesita saber sobre la migración a containerd en Amazon EKS.

Hay un complemento kubectl que puede usar para ver cuál de sus cargas de trabajo de Kubernetes están montando el volumen del socket de Docker. Para obtener más información, consulte Detector para socket Docker (DDS) en GitHub. Las AMI de Amazon EKS que ejecutan versiones de Kubernetes que son anteriores a la 1.24 utilizadas por Docker como tiempo de ejecución predeterminado. Sin embargo, estas AMI de Amazon EKS tienen una opción de marca de arranque que puede utilizar para probar sus cargas de trabajo en cualquier clúster compatible con containerd. Para obtener más información, consulte Prueba de la migración de Amazon Linux 2 de Docker a containerd.

Seguiremos publicando AMI para las versiones de Kubernetes existentes hasta su fecha de cese de la compatibilidad. Para obtener más información, consulte Calendario de lanzamientos de Amazon EKS de Kubernetes. Si necesita más tiempo para probar sus cargas de trabajo en containerd, use una versión compatible anterior a la 1.24. Pero, cuando desee actualizar las AMI oficiales de Amazon EKS a la versión 1.24 o superior, asegúrese de validar que sus cargas de trabajo se ejecutan en containerd.

El tiempo de ejecución de containerd proporciona un rendimiento y una seguridad más fiables. containerd es el tiempo de ejecución que se está estandarizando en Amazon EKS. Fargate y Bottlerocket ya usan solo containerd. containerd ayuda a minimizar el número de versiones de AMI de Amazon EKS necesarias para abordar las vulnerabilidades y exposiciones comunes (CVE) de dockershim. Como dockershim ya usa containerd internamente, es posible que no tenga que hacer ningún cambio. Sin embargo, hay algunas situaciones en las que es posible que se requieran cambios:

  • Deberá realizar cambios en cualquier aplicación que monte el socket de Docker. Por ejemplo, se verá afectada la creación de imágenes de contenedor creadas a partir de un contenedor. Muchas herramientas de supervisión también montan el socket de Docker. Es posible que tenga que esperar las actualizaciones o volver a implementar las cargas de trabajo para la supervisión del tiempo de ejecución.

  • Es posible que tenga que realizar cambios en las aplicaciones que dependan de una configuración específica de Docker. Por ejemplo, el protocolo HTTPS_PROXY ya no es compatible. Debe actualizar las aplicaciones que utilicen este protocolo. Para obtener más información, consulte dockerd en la documentación de Docker.

  • Si utiliza el asistente de credenciales de Amazon ECR para extraer imágenes, tendrá que cambiar al proveedor de credenciales de imágenes de kubelet. Para obtener más información, consulte Configurar un proveedor de credenciales de imagen de kubelet en la documentación de Kubernetes.

  • Dado que Amazon EKS 1.24 ya no es compatible con Docker, ya no se admiten algunos indicadores que el script de arranque de Amazon EKS admitía anteriormente. Antes de pasar a Amazon EKS 1.24 o a una versión posterior, debe eliminar cualquier referencia a los indicadores que ahora no son compatibles:

    • --container-runtime dockerd (containerd es el único valor admitido)

    • --enable-docker-bridge

    • --docker-config-json

  • Si ya ha configurado Fluentd para Container Insights, debe migrar Fluentd a Fluent Bit antes de cambiar a containerd. Los analizadores de Fluentd están configurados para analizar únicamente los mensajes de registro en formato JSON. A diferencia de dockerd, el tiempo de ejecución del contenedor containerdcontiene mensajes de registro que no están en formato JSON. Si no migra a Fluent Bit, algunos de los analizadores de Fluentd's configurados generarán una enorme cantidad de errores dentro del contenedor de Fluentd. por el número de versión compatible con Amazon EKS al que desea actualizar su clústerPara enviar registros a CloudWatch Logs, consulte Configurar Fluent Bit como DaemonSet para enviar registros a CloudWatch Logs.

  • Si utiliza una AMI personalizada y va a actualizar a Amazon EKS 1.24, debe asegurarse de que el reenvío de IP esté habilitado para sus nodos de trabajo. Esta configuración no era necesaria con Docker, pero es obligatoria para containerd. Es necesario para solucionar problemas de conectividad de red de Pod a Pod, Pod a externa o Pod a apiserver.

    Para comprobar esta configuración en un nodo de trabajo, ejecute uno de los siguientes comandos:

    • sysctl net.ipv4.ip_forward

    • cat /proc/sys/net/ipv4/ip_forward

    Si el resultado es 0, ejecute uno de los siguientes comandos para activar la variable net.ipv4.ip_forward del kernel:

    • sysctl -w net.ipv4.ip_forward=1

    • echo 1 > /proc/sys/net/ipv4/ip_forward

    Para obtener información sobre la activación de la configuración en las AMI de Amazon EKS en tiempo de ejecución containerd, consulte install-worker.sh en GitHub.

Prueba de la migración de Amazon Linux 2 de Docker a containerd

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 Creación de 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 Obtención de los ID de AMI de Amazon Linux recomendados.

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