Migrer dockershim de containerd

Kubernetes ne prend plus en charge dockershim. L'équipe Kubernetes a supprimé l'environnement d'exécution dans Kubernetes version 1.24. Pour plus d'informations, voir Kubernetes le Kubernetesblog intitulé Moving on Dockershim From : Commitments and Next Steps.

Amazon a EKS également mis fin à la prise en charge dockershim à partir de la 1.24 sortie de la Kubernetes version. Amazon EKS AMIs qui est officiellement publié a containerd pour seul moteur d'exécution commençant par la version1.24. Cette rubrique couvre certains détails, mais de plus amples informations sont disponibles dans la section 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 plus d'informations, voir Detector for Docker Socket (DDS) activéGitHub. Amazon EKS AMIs qui exécute Kubernetes des versions antérieures à celles 1.24 utilisées Docker comme environnement d'exécution par défaut. Cependant, ces Amazon EKS AMIs disposent d'une option d'indicateur bootstrap que vous pouvez utiliser pour tester vos charges de travail sur n'importe quel cluster pris en charge. containerd Pour de plus amples informations, veuillez consulter Testez la migration d'Amazon Linux 2 de Docker vers containerd.

Nous continuerons à publier AMIs les Kubernetes versions existantes jusqu'à la fin de leur date de support. Pour de plus amples informations, veuillez consulter Amazon EKS Kubernetes calendrier des sorties. 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. Toutefois, lorsque vous souhaitez passer à la version officielle d'Amazon EKS AMIs vers une version 1.24 ou une version ultérieure, assurez-vous de valider que vos charges de travail continuent de s'exécuter. containerd

Le containerd moteur d'exécution fournit des performances et une sécurité plus fiables. containerdest le runtime qui est normalisé sur AmazonEKS. Fargate et je l'utilise déjà uniquementBottlerocket. containerd containerdpermet de minimiser le nombre de EKS AMI versions d'Amazon nécessaires pour remédier aux vulnérabilités et aux risques dockershim courants (CVEs). 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'assistant ECR d'identification Amazon pour extraire des images, vous devez passer au fournisseur d'informations d'identification d'kubeletimage. Pour plus d'informations, consultez Configurer un fournisseur d'informations d'identification d'image kubelet dans la documentation Kubernetes.

• Amazon EKS 1.24 n'étant plus pris en chargeDocker, certains indicateurs précédemment pris en charge par le script EKS bootstrap d'Amazon ne le sont plus. Avant de passer à Amazon EKS 1.24 ou à une version ultérieure, vous devez supprimer toute référence aux drapeaux qui ne sont désormais 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 Fluentd analyseurs sont configurés pour analyser uniquement les messages du journal au JSON format. Contrairement à celadockerd, l'environnement d'exécution du containerd conteneur contient des messages de journal qui ne sont pas au JSON format. 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 plus d'informations sur la migration, voir Configurer en Fluent Bit tant que DaemonSet pour envoyer des CloudWatch journaux vers Logs.

• Si vous utilisez une option personnalisée AMI et que vous effectuez une mise à niveau vers Amazon EKS1.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 Amazon pendant EKS AMIs l'containerdexécution, reportez-vous à install-worker.sh la section suivanteGitHub.

Testez la migration d'Amazon Linux 2 de Docker vers containerd

Pour Kubernetes la version1.23, vous pouvez utiliser un indicateur bootstrap facultatif pour activer l'containerdenvironnement d'exécution EKS optimisé AL2 AMIs pour Amazon. Cette fonctionnalité vous offre une voie claire pour migrer vers containerd lors de la mise à jour vers la version 1.24 ou ultérieure. Amazon EKS a mis fin au support pour Docker commencer avec le 1.24 lancement de la Kubernetes version. Le containerd runtime est largement adopté dans la Kubernetes communauté et est un projet progressif avec leCNCF. Vous pouvez le tester en ajoutant un groupe de nœuds à un cluster nouveau ou existant.

Vous pouvez activer l'indicateur d'amorçage en créant l'un des types de groupes de nœuds suivants.

Autogéré

Créez le groupe de nœuds à l'aide des instructions contenues dans Créez des nœuds Amazon Linux autogérés. Spécifiez un paramètre EKS optimisé pour Amazon AMI et le texte suivant pour le BootstrapArguments paramètre.

--container-runtime containerd

Gérées

Si vous utilisez eksctl, créez un fichier nommé my-nodegroup.yaml avec le contenu suivant. Remplacez chaque example value par vos propres valeurs. Le nom du groupe de nœuds ne peut pas dépasser 63 caractères. Il doit commencer par une lettre ou un chiffre, mais peut également inclure des tirets et des traits de soulignement pour les autres caractères. Pour récupérer un AMI identifiant optimisé pourami-1234567890abcdef0, voirRécupérez le système Amazon Linux recommandé AMI IDs.

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

Note

Si vous lancez de nombreux nœuds simultanément, vous pouvez également spécifier des valeurs pour le --apiserver-endpoint, --b64-cluster-ca, et les arguments bootstrap d'amorçage --dns-cluster-ip pour éviter les erreurs. Pour de plus amples informations, veuillez consulter Spécifier un AMI.

Exécutez les commandes suivantes pour créer le groupe de nœuds.

eksctl create nodegroup -f my-nodegroup.yaml

Si vous préférez utiliser un autre outil pour créer votre groupe de nœuds gérés, vous devez déployer le groupe de nœuds à l'aide d'un modèle de lancement. Dans votre modèle de lancement, spécifiez un AMIID EKS optimisé pour Amazon, puis déployez le groupe de nœuds à l'aide d'un modèle de lancement et fournissez les données utilisateur suivantes. Ces données utilisateur transmettent des arguments dans le fichier bootstrap.sh. Pour plus d'informations sur le fichier d'amorçage, consultez bootstrap.sh sur GitHub.

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