La version bĂȘta de KIOWY Platform 🚀
est disponible ! En savoir +

← Retour

Pourquoi Kubernetes abandonne Docker ? 💔 18.06.2021

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