Amazon EKS a mis fin à la prise en charge de Dockershim - Amazon EKS

Amazon EKS a mis fin à la prise en charge de Dockershim

Kubernetes ne prend plus en charge Dockershim. L'équipe Kubernetes a supprimé l'environnement d'exécution dans Kubernetes version 1.24. Pour de plus amples informations, veuillez consulter Kubernetes is Moving on From Dockershim: Commitments and Next Steps sur le Blog Kubernetes.

Amazon EKS a également mis fin à la prise en charge de Dockershim à partir de la version 1.24 de Kubernetes. Les AMI Amazon EKS officiellement publiées incluent containerd comme seul environnement d'exécution à partir de la version 1.24. Cette rubrique couvre certains détails, mais de plus amples informations sont disponibles dans le guide Tout ce que vous devez savoir sur la migration vers containerd sur Amazon EKS.

Vous pouvez utiliser un plug-in kubectl pour identifier les charges de travail Kubernetes qui montent le volume du socket Docker. Pour de plus amples informations, veuillez consulter Détecteur pour Docker Socket (DDS) sur GitHub. Les AMI Amazon EKS qui exécutent des versions de Kubernetes antérieures à la version 1.24 utilisent Docker comme environnement d'exécution par défaut. Toutefois, ces AMI Amazon EKS disposent d'une option d'indicateur d'amorçage que vous pouvez utiliser pour tester vos charges de travail sur n'importe quel cluster pris en charge à l'aide de containerd. Pour de plus amples informations, veuillez consulter Activez l'indicateur d'amorçage d'exécution containerd.

Nous continuerons à publier des AMI pour les versions existantes de Kubernetes jusqu'à la date de fin de support. Pour de plus amples informations, veuillez consulter Calendrier de sortie de la version Kubernetes Amazon EKS. Si vous avez besoin de plus de temps pour tester vos charges de travail sur containerd, utilisez une version prise en charge antérieure à la version 1.24. Mais si vous souhaitez mettre à niveau les AMI Amazon EKS officielles vers la version 1.24 ou ultérieure, vérifiez que vos charges de travail s'exécutent sur containerd.

L'environnement d'exécution containerd est plus fiables en termes de performances et de sécurité. containerd correspond à l'environnement d'exécution normalisé sur Amazon EKS. Fargate et Bottlerocket n'utilisent déjà que containerd. containerd réduit le nombre de versions d'AMI Amazon EKS nécessaires pour corriger les CVE (Vulnérabilités et expositions courantes) Dockershim. Comme Dockershim utilise déjà containerd en interne, vous n'aurez peut-être pas besoin d'apporter de modifications. Toutefois, dans certaines situations, des changements peuvent s'avérer nécessaires :

  • Vous devrez apporter des modifications aux applications qui montent le socket Docker. Par exemple, les images de conteneurs créées à l'aide d'un conteneur seront affectées. De nombreux outils de surveillance montent également le socket Docker. Vous devrez peut-être attendre des mises à jour ou redéployer les charges de travail pour la surveillance de l'exécution.

  • Vous devrez peut-être apporter des modifications pour les applications qui dépendent de paramètres Docker spécifiques. Par exemple, le protocole HTTPS_PROXY n'est plus pris en charge. Vous devez mettre à jour les applications qui utilisent ce protocole. Pour plus d'informations, consultez dockerd dans la documentation Docker.

  • Si vous utilisez l'assistance des informations d'identification Amazon ECR pour extraire des images, vous devez basculer vers le fournisseur d'informations d'identification d'images kubelet. Pour plus d'informations, consultez Configurer un fournisseur d'informations d'identification d'image kubelet dans la documentation Kubernetes.

  • Comme Amazon EKS 1.24 ne prend plus en charge Docker, certains indicateurs que le script d'amorçage Amazon EKS prenait auparavant en charge ne le sont plus. Avant de passer à Amazon EKS 1.24 ou version ultérieure, vous devez supprimer toute référence aux indicateurs qui ne sont plus pris en charge :

    • --container-runtime dockerd (containerd est la seule valeur prise en charge)

    • --enable-docker-bridge

    • --docker-config-json

  • Si vous avez déjà configuré Fluentd pour Container Insights, vous devez effectuer la migration de Fluentd vers Fluent Bit avant de passer à containerd. Les analyseurs Fluentd sont configurés pour analyser uniquement les messages du journal au format JSON. Contrairement à dockerd, l’exécution du conteneur containerd a des messages de journal qui ne sont pas au format JSON. Si vous ne migrez pas vers Fluent Bit, certains des analyseurs Fluentd's configurés généreront un grand nombre d'erreurs à l'intérieur du conteneur Fluentd. Pour en savoir plus sur la migration, voir Configurer Fluent Bit en tant que DaemonSet pour l'envoi de journaux à CloudWatch Logs.

  • Si vous utilisez une AMI personnalisée et que vous effectuez une mise à niveau vers Amazon EKS 1.24, vous devez vous assurer que le transfert IP est activé pour vos nœuds de travail. Ce paramètre n'était pas nécessaire avec Docker mais est requis pour containerd. Il est nécessaire pour résoudre les problèmes de connectivité des réseaux de Pod-à-Pod, de Pod-à-externe, ou de Pod-à-apiserver.

    Pour vérifier ce paramètre sur un nœud de travail, exécutez l'une des commandes suivantes :

    • sysctl net.ipv4.ip_forward

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

    Si le résultat est 0, exécutez l'une des commandes suivantes pour activer la variable du noyau net.ipv4.ip_forward :

    • sysctl -w net.ipv4.ip_forward=1

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

    Pour l'activation du paramètre sur les AMI Amazon EKS au cours de l'exécution containerd, consultez install-worker.sh sur GitHub.