Kubernetes procède à la dépréciation et à la suppression de dockershim dans la prochaine version 1.24. Les worflows et les systèmes qui utilisent Docker Engine comme environnement d'exécution de conteneur pour leur cluster Kubernetes devront migrer avant de passer à la version 1.24. La version 1.23 conservera dockershim et sera prise en charge pendant encore une année.
Docker a été le premier runtime de conteneur utilisé par Kubernetes. À l'origine, la prise en charge de Docker était codée en dur dans Kubernetes, mais au fur et à mesure de l'évolution du projet, Kubernetes a commencé à ajouter la prise en charge de plusieurs runtimes. La communauté Kubernetes a décidé de passer à des interfaces plus structurées et standardisées au lieu d'intégrer directement des solutions tierces dans le code principal. Cela a conduit à la création de la Container Runtime Interface (CRI), la Container Network Interface (CNI) et la Container Storage Interface (CSI).
Comme Adam Parco, CTO chez Mirantis, déclare :
Pour la plupart des gens, l'abandon de dockershim n'est pas un problème, car même s'ils n'en sont pas conscients, ils n'utilisent pas réellement Docker en tant que tel ; ils utilisent containerd, qui est conforme au CRI. Pour ces personnes, rien ne changera.
Comme Docker n'est pas conforme au CRI, dockershim agit comme une couche de traduction entre kubelet et Docker. Docker s'interface ensuite avec containerd pour exécuter les conteneurs. Containerd a été extrait de Docker en tant qu'environnement d'exécution de conteneur autonome et est devenu le premier environnement d'exécution conforme au CRI. Le changement pour déprécier dockershim verra kubelet communiquer directement avec le runtime du conteneur tel que containerd.
Comme indiqué dans un article récent sur le blog de Kubernetes, l'abandon de dockershim est de mieux aligner la base de code Kubernetes sur le nouveau modèle d'interfaces. Certaines nouvelles fonctionnalités, telles que cgroups v2 et l'espace de noms d'utilisateurs, sont largement incompatibles avec dockershim. Comme le notent les auteurs de ce récent article de blog : " Les dépendances à Docker et à dockershim se sont glissées dans divers outils et projets de l'écosystème de la CNCF, entraînant un code fragile."
Si Docker est actuellement utilisé pour créer les conteneurs d'application, ces conteneurs peuvent toujours être exécutés sur n'importe quel environnement d'exécution de conteneur. Lorsqu'un environnement d'exécution de conteneur alternatif est utilisé, les commandes Docker peuvent ne pas fonctionner ou produire des résultats différents. Par exemple, docker ps ou docker inspect ne seront plus utilisables pour obtenir des informations sur le conteneur, et docker exec ne fonctionnera plus.
Autres éléments à surveiller pour déterminer une dépendance sur dockershim inclut de s'assurer qu'aucun pod privilégié n'exécute des commandes Docker telles que docker ps, redémarre le service Docker ou modifie des fichiers spécifiques à Docker. Le fichier de configuration Docker doit être examiné pour les registres privés ou les paramètres de miroir d'images. S'ils existent, ils doivent souvent être reconfigurés pour une autre runtime.
Un examen doit être effectué sur les scripts qui s'exécutent en dehors de l'infrastructure Kubernetes pour identifier les commandes Docker. Cela peut inclure SSH vers les nœuds pour le dépannage, les scripts de démarrage des nœuds ou des agents de surveillance et de sécurité qui sont installés directement sur les nœuds.
Mirantis et Docker ont convenu de s'associer pour maintenir le code dockershim en tant qu'interface CRI autonome, open-source et conforme pour Kubernetes. Cela signifie que le Mirantis Container Runtime (MCR) sera conforme au CRI. Leur cri-dockerd pourrait être utilisé comme un remplacement externe pour dockershim dans les cas où la désactivation de dockershim n'est pas souhaitable ou faisable.
L'équipe de publication de Kubernetes 1.24 et la CNCF se sont engagées à fournir la documentation à temps pour la publication, actuellement prévue pour avril. Cela comprend des articles de blog, des exemples de code de mise à jour, des didacticiels et un guide de migration.
L'équipe pense qu'il n'y a plus d'obstacles majeurs à la poursuite de la migration. Ils notent que des discussions sur le report ont eu lieu lors de la récente discussion sur le nœud SIG le 11 novembre et la réunion du Kubernetes Steering Committee le 6 décembre. A l'heure actuelle, ils ont accepté de poursuivre la suppression de dockershim dans la prochaine version 1.24.