Migrer de dockershim vers containerd - Amazon EKS
Testez la migration vers Amazon Linux 2 depuis Docker à containerd

Aidez à améliorer cette page

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Vous souhaitez contribuer à ce guide de l'utilisateur ? Choisissez le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page. Vos contributions aideront à améliorer notre guide de l'utilisateur pour tout le monde.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Migrer de dockershim vers containerd

Kubernetes ne supporte plusdockershim. Le Kubernetes l'équipe a supprimé le runtime dans Kubernetes version1.24. Pour plus d'informations, consultez Kubernetes is Moving on From Dockershim : Commitments and Next Steps on the Kubernetes Blogue.

Amazon EKS a également mis fin au support pour dockershim démarrer avec le Kubernetes 1.24sortie de version. Les Amazon EKS AMIs publiés officiellement ont 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 le guide Tout ce que vous devez savoir sur la migration vers containerd sur Amazon EKS.

Il existe un kubectl plugin que vous pouvez utiliser pour voir lequel de vos Kubernetes les charges de travail montent le Docker volume du socket. Pour plus d'informations, voir Détecteur de socket Docker (DDS) sur GitHub. Amazon EKS AMIs qui s'exécute Kubernetes 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 de démarrage 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 vers Amazon Linux 2 depuis Docker à containerd.

Nous continuerons à publier AMIs pour les versions existantes Kubernetes versions 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 mettre à niveau 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 Amazon EKS. Fargate et Bottlerocket déjà utilisé containerd uniquement. containerdpermet de minimiser le nombre de versions de l'AMI Amazon EKS 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 devez apporter des modifications aux applications qui installent le Docker prise. Par exemple, les images de conteneurs créées à l'aide d'un conteneur seront affectées. De nombreux outils de surveillance installent également le Docker prise. 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 aux applications qui dépendent de Docker paramètres. 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 le 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, voir Configurer un fournisseur d'informations d'identification d'image Kubelet dans le Kubernetes .

  • Parce qu'Amazon EKS 1.24 ne prend plus en charge Docker, certains indicateurs indiquant que le script de démarrage Amazon EKS était précédemment pris 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à Fluentd configuré pour Container Insights, alors vous devez migrer Fluentd to Fluent Bit avant de passer àcontainerd. Le Fluentd les analyseurs sont configurés pour analyser uniquement les messages du journal au format JSON. Contrairement à celadockerd, le runtime du containerd conteneur contient des messages de journal qui ne sont pas au format JSON. Si vous ne migrez pas vers Fluent Bit, certains des paramètres configurés Fluentd’s les analyseurs génèreront une quantité massive d'erreurs dans le Fluentd contenant. Pour plus d'informations sur la migration, voir Configurer Fluent Bit en tant que DaemonSet pour envoyer des CloudWatch journaux vers 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 obligatoire pourcontainerd. Il est nécessaire pour dépanner Pod-à-Pod, Pod-to-external, ou Pod-à-apiserver connectivité réseau.

    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 EKS AMIs pour Amazon Linux 2 au moment de l'containerdexécution, consultez install-worker.sh GitHub.

Testez la migration vers Amazon Linux 2 depuis Docker à containerd

Dans Kubernetes version1.23, vous pouvez utiliser un indicateur bootstrap facultatif pour activer l'containerdenvironnement d'exécution optimisé AL2 AMIs pour Amazon EKS. 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 à la prise en charge de Docker en commençant par le Kubernetes 1.24lancement de version. Le containerd runtime est largement adopté dans le Kubernetes communautaire et est un projet diplômé de la CNCF. 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 en suivant les instructions de la section Création de nœuds Amazon Linux autogérés. Spécifiez une AMI optimisée pour Amazon EKS et le texte suivant pour le paramètre BootstrapArguments.

--container-runtime containerd
Géré

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 comporter plus de 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 ID d'AMI optimisée pour ami-1234567890abcdef0 , veuillez consulter la rubrique Récupérez l'AMI Amazon Linux recommandée 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écification d'une 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 ID d'AMI optimisée pour Amazon EKS, puis déployez le groupe de nœuds avec 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 bootstrap, consultez le fichier bootstrap.sh sur GitHub.

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