Kubernetes supprime Docker

Ce soir, je vais vous parler d’une déclaration de l’équipe de Kubernetes qui date d’hier.

Kubernetes déclare que dans sa dernière version (la version 1.20) ils vont déprécier Docker.

Qu’est ce que ça veut dire ?

Est-ce que vous ne pourrez plus utiliser de conteneurs avec Kubernetes

Est-ce que vous allez devoir reconstruire tous vos conteneurs ?

Rassurez-vous, non.

Alors qu’est ce que c’est docker par rapport à Kubernetes et par rapport aux conteneurs ?

En fait, Docker c’est une appli extrêmement complexe qui certes fait de la conteneurisation mais elle veut aussi faire la gestion de réseau, gestion de volume et caetera… De la construction de conteneurs, les faire tourner et caetera…

Ça se voulait une solution absolument contexte. Ils avaient fait docker swarm par exemple. Ils se voulaient être un concurrent de Kubernetes.

Ou plutôt Kubernetes était un concurrent de Docker Swarm parceque si je me souviens bien, Swarm est sorti avant. Faut peut-être vérifier ça, je suis pas sûr.

Mais la conteneurisation en tant que tel, le fait de faire tourner des conteneurs, c’est pas spécifique à Docker. Ces couches de programmation, Docker, les a en commun avec tout un tas d’autres projets dont Podman (dont vous avez sûrement entendu parler si vous suivez la chaîne)

Et il y en a un autre qui s’appelle CRI-O et Kubernetes, lui, veut tendre tout vers CRI-O.

Alors comment ça se décompose ces couches de programmation ?

Tout d’abord, à la base on a Runc qui est compatible et qui est maintenu par l’Open Container Initiative, une association qui gère ça et Runc, par exemple pour concourse-CI, est le niveau le plus bas sur lequel il peut gérer des conteneurs.

Au dessus de Runc, du coup, on a une couche de programmation qu’on appelle containerd qui a été à la base conçu par les ingénieurs de chez Docker et qu’il a ensuite libéré. Alors je crois qu’ils l’ont envoyé à l’Open Container Initiative mais je suis pas sûr de ça. Mais quoi qu’il en soit, c’est maintenant commun à d’autres systèmes que Docker.

Et au dessus on a Kubernetes et Docker.

Kubernetes, jusqu’à présent, utilisait un outil qui s’appelle Docker-shim. Il était là pour faire la traduction entre Docker et Kubernetes.

Parce que Kubernetes ne gérait pas directement Docker. Il était obligé de passer par ce système parce que l’API de Docker était très touffue et différente de celle de Kubernetes.

Donc l’équipe de Kubernetes a dit :

“bon, on a 2 standards, runc et containerd pour faire tourner les containers. Maintenant, nous on a inventé Container Runtime Interface donc une interface pour pouvoir accéder à containerd et runc qui est beaucoup plus légère qu’on appelait CRI. Et l’implémentation, CRI-O. Alors, pourquoi on continue avec ce truc lourdingue qu’est Docker avec lequel on est obligé de passer par un truc qui s’appelle Docker-Shim qu’est instable et tout ? Pourquoi on passe pas tous directement sur CRI-O ?”

Ils ont pris la décision de tout passer sur CRI-O. Alors, il y a peut-être d’autres supports aussi que CRI-O.

Et donc normalement c’est beaucoup plus léger.

Ça veut dire quoi ?

Vos containers que vous avez construit avec Dockerfile ou avec d’autres systèmes qui prennent en compte Docker sont toujours compatibles.

Il y a peut-être des problèmes à la marge mais normalement ils sont toujours compatibles avec votre Kubernetes.

Donc ça ne va rien changer pour vous si votre coeur de métier c’est de faire des containers.

Ça va changer pour ceux qui veulent mettre en place du Kubernetes. Parce que là ils ne pourront plus utiliser Docker pour gérer les containers de leur infra Kubernetes.

Ils vont devoir passer par CRI-O mais il est beaucoup plus léger que Docker donc normalement ça devrait être beaucoup plus performant.

L’inconvénient, c’est que CRI-O, lui, ne peut pas construire de container. Il peut juste les faire tourner. En plus lui même, je crois, ne gère pas le réseau, tout ça c’est délégué à Kubernetes. Alors que Docker, lui, gérait du réseau.

Donc pour build, il faut toujours soit passer par Docker, soit passer par d’autres solutions comme Podman/Buildah (nous on veut tendre vers ça).

Et ensuite, une fois que le container est construit, on peut toujours le faire tourner sur Kubernetes avec CRI-O.

Donc, ne vous affolez pas, vos containers sont toujours compatibles avec Kubernetes même s’il ne tourneront plus avec Docker dans Kubernetes.

Voilà.