Comment migrer loin de Dockershim dans Kubernetes v1.24 et versions ultérieures
Kubernetes v1.24 et les versions ultérieures sont livrées sans Dockershim après son obsolescence dans la version v1.20 de décembre 2020. Dockershim n’est plus disponible en tant qu’environnement d’exécution de conteneur intégré. Vous devez utiliser à la place un environnement d’exécution pris en charge différent, tel que containerd, CRI-O ou Docker Engine avec le cri-dockerd adaptateur.
Dans cet article, nous montrerons comment vérifier si vous êtes concerné, puis expliquerons comment vous pouvez migrer vers un runtime différent. Vous devriez suivre ces étapes avant de vous mettez à niveau vers Kubernetes v1.24 ou une version ultérieure afin que les charges de travail de votre cluster ne soient pas affectées.
Sommaire
Qu’est-ce que Dockershim ?
Dockershim a été développé en tant que composant nécessaire pour que Kubernetes puisse prendre en charge davantage d’environnements d’exécution de conteneurs. Au début du projet, Kubernetes ne fonctionnait qu’avec Docker Engine. Cette restriction a été supprimée par l’introduction de la norme CRI. Tout environnement d’exécution compatible CRI peut désormais être utilisé avec Kubernetes, y compris containerd et CRI-O, une implémentation OCI de la norme.
Bien que le CRI ait apporté une nouvelle flexibilité à Kubernetes, il présentait un problème pour les clusters existants. Docker ne prenait pas en charge la norme CRI, Dockershim a donc été conçu pour laisser l’équipe Kubernetes superposer la compatibilité. Dockershim était une intégration directe avec Docker Engine qui a toujours été conçue comme une mesure temporaire.
Le mouvement des conteneurs est maintenant bien plus que Docker, comme le montre la poussée originale de Kubernetes vers CRI. Docker lui-même s’est scindé en composants individuels avec son runtime extrait en tant que containerd, diplômé de la Cloud Native Computing Foundation (CNCF).
containerd est entièrement pris en charge par Kubernetes et plus adapté à une utilisation autonome dans des environnements cloud. Kubernetes n’a pas besoin de l’interface de ligne de commande Docker et de ses nombreuses fonctionnalités pour exécuter vos pods ; tout ce dont il a besoin est la capacité de démarrer et d’exécuter des conteneurs à un niveau relativement bas. Dockershim a été supprimé car il était difficile à maintenir. Son utilisation a créé un code fragile étroitement lié à l’implémentation de Docker Engine.
Vérifier si vous utilisez Dockershim
Il est très peu probable que les clusters récemment créés sur des plates-formes modernes utilisent Dockershim. Cela inclut les clusters gérés par des fournisseurs de cloud populaires tels qu’Amazon EKS, Azure AKS, Google GKE et DigitalOcean DOKS.
Vous devrez probablement prendre des mesures si vous gérez votre propre cluster et que vous l’avez créé pour la première fois il y a plusieurs années. Vous pouvez vérifier si vous utilisez Dockershim comme environnement d’exécution pour l’un de vos nœuds en exécutant cette commande Kubectl :
$ kubectl get nodes -o wide NAME STATUS VERSION CONTAINER-RUNTIME node-1 Ready v1.22.8 docker://19.3.1 node-2 Ready v1.22.8 containerd://1.4.13
Dans cet exemple, l’un des nœuds utilise containerd et peut être laissé tel quel. L’autre nœud est configuré à l’aide de Docker et pourrait être affecté par la suppression de Dockershim. Vous pouvez vérifier en exécutant cette commande sur le nœud :
$ tr ' ' < /proc/"$(pgrep kubelet)"/cmdline | grep "--container-runtime"
Votre nœud utilise Dockershim pour exécuter des conteneurs si aucune sortie n’est affichée. Si vous obtenez une sortie, inspectez le --container-runtime-endpoint flag pour déterminer si Dockershim est actif. Un point de terminaison d’exécution de unix:///run/containerd/containerd.sock signaux containerd est utilisé, aucune migration n’est donc nécessaire.
Modification de l’exécution d’un nœud
Les nœuds qui utilisent Dockershim doivent être mis à jour pour utiliser un environnement d’exécution différent. Videz d’abord les charges de travail du nœud à l’aide de Kubectl, afin que vos pods soient replanifiés vers d’autres nœuds de votre cluster. Vous devez également boucler le nœud pour empêcher la planification de nouveaux pods.
$ kubectl cordon node-1 $ kubectl drain node-1 --ignore-daemonsets
Exécutez ensuite les commandes suivantes sur le nœud lui-même. Commencez par arrêter le démon Docker et le processus de travail Kubelet du nœud :
$ systemctl stop kubelet $ systemctl disable docker.service --now
Vous pouvez maintenant installer votre nouveau runtime.
Utilisation de conteneur
containerd est généralement la solution préférée pour les clusters actuels. Vous devriez pouvoir migrer vers containerd si vous ne comptez pas sur des fonctionnalités spécifiques de Docker Engine. Si tel est le cas, rendez-vous à la section suivante et installez cri-dockerd à la place.
Ajoutez le référentiel de Docker à votre système si vos listes de packages ne l’incluent pas déjà. containerd est distribué dans le référentiel de Docker.
$ sudo apt-get update $ sudo apt-get install ca-certificates curl gnupg lsb-release $ curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg $ echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/debian $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
Installez le conteneur :
$ sudo apt update $ sudo apt install containerd
Maintenant, mettez à jour le fichier de configuration Kubelet du nœud pour utiliser le nouveau runtime. Ouvert /var/lib/kubelet/kubeadm-flags.env. Rechercher ou ajouter le --container-runtime et --container-runtime-endpoint flags avec les valeurs suivantes :
--container-runtime=remote--container-runtime-endpoint=unix:///run/containerd/containerd.sock
Modifiez ensuite l’annotation de socket enregistrée sur l’objet Node dans le plan de contrôle Kubernetes :
$ kubectl edit node node-1
Dans le fichier qui s’ouvre, recherchez le kubeadm.alpha.kubernetes.io/cri-socket annotation et remplacez-la par unix:///run/containerd/containerd.sock. Enregistrez et fermez le fichier pour mettre à jour l’objet du nœud.
Maintenant, redémarrez Kubelet :
$ systemctl start kubelet
Attendez quelques instants que le nœud démarre et se connecte au plan de contrôle Kubernetes. Vous devriez pouvoir répéter le get nodes commande et voyez que containerd est maintenant utilisé.
$ kubectl get nodes -o wide NAME STATUS VERSION CONTAINER-RUNTIME node-1 Ready v1.22.8 containerd://1.4.13 node-2 Ready v1.22.8 containerd://1.4.13
Retirez enfin le cordon que vous avez placé autour du Node afin qu’il puisse commencer à recevoir des Pods :
$ kubectl uncordon node-1
Utilisation de cri-docker
cri-dockerd est un runtime développé conjointement par Docker et Mirantis. Il s’agit en fait d’une version autonome de Dockershim qui est gérée de manière indépendante. Il vous permet de continuer à utiliser des fonctionnalités familières sans encombrer le projet Kubernetes avec les exigences de maintenance de Dockershim.
Assurez-vous que Docker Engine est déjà installé. Installez ensuite cri-dockerd en téléchargeant le dernier fichier binaire à partir des versions de GitHub :
$ wget https://github.com/Mirantis/cri-dockerd/releases/download/v0.2.0/cri-dockerd-v0.2.0-linux-amd64.tar.gz $ tar xvf cri-dockerd-v0.2.0-linux-amd64.tar.gz $ mv cri-dockerd /usr/local/bin/
Ensuite, téléchargez, installez et activez les configurations de service systemd de cri-dockerd :
wget https://raw.githubusercontent.com/Mirantis/cri-dockerd/master/packaging/systemd/cri-docker.service wget https://raw.githubusercontent.com/Mirantis/cri-dockerd/master/packaging/systemd/cri-docker.socket sudo mv cri-docker.socket cri-docker.service /etc/systemd/system/ sudo sed -i -e 's,/usr/bin/cri-dockerd,/usr/local/bin/cri-dockerd,' /etc/systemd/system/cri-docker.service sudo systemctl daemon-reload sudo systemctl enable cri-docker.service sudo systemctl enable --now cri-docker.socket
Vous pouvez maintenant modifier la configuration Kubelet de votre nœud pour utiliser cri-dockerd. Ceci est similaire à la configuration d’un nœud pour utiliser containerd.
Ouvert /var/lib/kubelet/kubeadm-flags.env. Rechercher ou ajouter le --container-runtime et --container-runtime-endpoint flags avec les valeurs suivantes :
--container-runtime=remote--container-runtime-endpoint=unix:///var/run/cri-dockerd.sock
Modifiez ensuite l’annotation socket de l’objet Node :
$ kubectl edit node node-1
Dans le fichier qui s’ouvre, recherchez le kubeadm.alpha.kubernetes.io/cri-socket annotation et remplacez-la par unix:///var/run/cri-dockerd.sock. Enregistrez et fermez le fichier pour mettre à jour l’objet du nœud.
Maintenant, redémarrez Kubelet :
$ systemctl start kubelet
Attendez quelques instants, puis utilisez Kubectl pour vérifier que le nœud est opérationnel. Il affichera toujours le runtime Docker, mais il est désormais basé sur le cri-dockerd autonome, au lieu du Dockershim intégré à Kubernetes.
$ kubectl get nodes -o wide NAME STATUS VERSION CONTAINER-RUNTIME node-1 Ready v1.22.8 docker://19.3.1 node-2 Ready v1.22.8 containerd://1.4.13
Vous pouvez maintenant supprimer le cordon que vous avez placé autour du Node. Il recommencera à accepter les demandes de planification de pod.
$ kubectl uncordon node-1
Conclusion
Kubernetes v1.24 a supprimé le composant Dockershim qui intégrait auparavant la compatibilité CRI pour Docker Engine. Bien que les clusters les plus récents ne soient pas affectés, vous devez vérifier si vous utilisez Dockershim avant de passer à la nouvelle version.
L’environnement d’exécution vers lequel basculer dépend de la manière dont vous utilisez actuellement votre cluster. containerd est généralement un bon choix si vous n’utilisez pas les fonctionnalités de Docker. Vous pouvez utiliser cri-dockerd pour rétablir une intégration de type Dockershim si vous avez besoin de maintenir la compatibilité avec les outils existants qui dépendent de Docker Engine. Cela aide également si vous montez le socket du démon Docker (/var/run/docker.sock) dans vos conteneurs pour alimenter les workflows Docker-in-Docker.
La suppression de Dockershim n’a aucune incidence sur la manière dont vous créez et utilisez les images de conteneur. Kubernetes peut toujours exécuter des images créées avec docker build et ils sont compatibles avec tous les runtimes pris en charge. Les runtimes CRI fonctionnent avec n’importe quelle image au format OCI, telle que sortie par Docker et d’autres générateurs d’images.
