Pourquoi Kubernetes abandonne Docker ? 💔

kubernetesops

Publié le Invalid date

Dans le changelog de la version 1.20 de Kubernetes, un changement qui a laissé beaucoup de monde perplexe est apparu : Kubernetes va arrêter de supporter Docker comme container runtime. Un vent de panique a parcouru la communauté, mais voyons pourquoi il n’y a pas (vraiment) besoin de s’inquiéter de ce changement.

Tout d’abord, pour comprendre ce changement, rappelons ce qu’est un runtime de conteneur et à quoi il sert au sein de Kubernetes. Le but de l'orchestrateur est de faire fonctionner une application conteneurisée. Kubernetes doit donc réaliser deux opérations avec vos conteneurs : récupérer les images (pull) et exécuter des conteneurs (start, stop).

Afin de ne pas re-développer des fonctionnalités existantes, Kubernetes délègue ces deux fonctions à un outil spécialisé : le container runtime. Quand vous déployez un pod, le composant de Kubernetes appelé Kubelet (un kubelet sur chaque noeud) va voir que vous voulez exécuter un conteneur, il va alors envoyer l’information au container runtime du noeud qui se chargera de récupérer l’image puis de démarrer le conteneur.

Mais alors, si Kubernetes nous laisse choisir le runtime de conteneur, ils doivent tous pouvoir se parler ?

Et bien oui, si Kubernetes a été initialement développé avec Docker, la multiplication des runtimes a conduit la communauté à créer deux standards : Container Runtime Interface (CRI) et Open Container Initiative (OCI). Le CRI est un standard pour l'exécution de conteneurs par le Kubelet, et l’OCI permet l'interopérabilité des images de conteneurs.

Mais le problème avec Docker, c’est qu’il ne respecte pas (entièrement) le CRI. C’est pourquoi le Kubelet était compilé avec un composant appelé Dockershim, qui servait d’interface. Et c’est bien le maintien de cette interface, en dehors des standards, qui pose problèmes aujourd’hui. Les développeurs de Kubernetes souhaitent se reposer uniquement sur les standards, sans traitement de faveur pour Docker.

Donc mon cluster ne fonctionnera plus à partir de la 1.20 ?

Rassurez-vous, il y a de grandes chances que tout marche comme avant. Il faut pour cela que les nœuds de votre cluster utilisent un runtime compatible CRI comme containerd ou CRI-O. Hors il se trouve que depuis la version 18.09 de Docker, il est nécessaire d’installer containerd (qui est en fait anciennement un composant de Docker qui a été détaché du reste du projet). Vous pouvez donc vérifier sur vos nœuds la présence de containerd. Dans ce cas, vos conteneurs continueront à s'exécuter comme avant.

Et pour nos images créées à partir d’un Dockerfile ?

Aucun problème, les images produites par Docker (via la commande docker build) sont compatibles OCI. Elles peuvent donc êtres utilisées par n’importe quel autre runtime de conteneur compatible OCI. Les développeurs pourront donc continuer d’utiliser Docker pour produire vos images.

En résumé ?

Pour le développement, rien ne change. Pour votre cluster, il faut s’assurer d’utiliser un runtime compatible CRI comme containerd (ce qui est le cas à partir de Docker 18.09) ou CRI-O. Enfin, si vous utilisez des fonctionnalités de Docker-in-Docker dans votre cluster (pour votre CI sur Kubernetes par exemple), vous pouvez utiliser des solutions alternatives telles que kaniko ou buildha. À retenir également que le retrait définitif du support sera effectif dans la version 1.22 (prévue fin 2021).

Si vous avez besoin d'aide pour mesurer l'impact de ce changement sur votre infrastructure, notre équipe peut vous accompagner ! Et si vous ne voulez plus avoir à penser à la changelog Kubernetes, simplifiez vous la vie avec KIOWY Platform.

Références :

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation