Depuis quelques années, Docker et Kubernetes ont dominé ensemble le domaine des conteneurs. Le premier étant l’outil qui vient naturellement en tête lorsqu’il s’agit de créer et d’exécuter des conteneurs et le second lorsqu’il s’agit de les gérer et de les orchestrer. Pourtant, depuis sa version 1.20 lancée en décembre 2020, Kubernetes a déprécié la prise en charge de Docker en tant que container runtime. Un choix qui a généré un tremblement de terre chez les professionnels du développement. Aujourd’hui, les professionnels se tournent davantage vers Containerd.

Pourquoi Kubernetes a déprécié Docker ?

Au début, Docker a été le container runtime privilégié des utilisateurs de Kubernetes. Pourtant, Docker n’est pas un container runtime à proprement parler. Il a fallu ajouter le composant dockershim dans le code de la kubelet pour que les conteneurs puissent être gérés directement avec Docker. À vrai dire, Docker est un ensemble d’outils qui crée une interface plus pratique pour l’utilisateur. Docker a évolué depuis son lancement et il utilise désormais Containerd, un composant compatible avec le CRI. Lorsqu’on utilise Docker comme runtime de conteneur, il fait office d’intermédiaire entre Kubernetes et Docker.

Par ailleurs, Kubernetes est capable de fonctionner avec tous les runtime de conteneur qui implémentent le standard CRI (Container Runtime Interface) et de nos jours, il existe de nombreux runtimes qui le font. Or, Docker n’implémente par l’interface d’exécution de conteneur. Il devient alors évident qu’il existe des alternatives plus intéressantes à Docker et la concrétisation de sa dépréciation n’était qu’une question de temps. Cela étant, Docker peut toujours avoir un rôle à jouer dans l’écosystème Kubernetes et le flux de travail.

Docker et Containerd : quelles relations et quelles différences ?

Compatible avec le container runtime interface ou CRI, Containerd est un container engine utilisé par Docker. Cette relation rend naturel le remplacement de Docker par Containerd pour les professionnels évoluant dans un environnement k8s. On peut même affirmer qu’il s’agit d’une amélioration puisqu’on fait l’impasse sur un daemon et un composant du nœud.

Depuis que Docker a révolutionné l’univers des conteneurs en 2013, Containerd a toujours fait partie de cette technologie. C’est notamment l’environnement utilisé par Docker pour la création de conteneurs, l’extraction des images, la gestion du stockage, la gestion de la mise en réseau et l’interaction avec les conteneurs. Ce n’est qu’en 2016 que Docker et Containerd ont été séparés et c’est justement pour les écosystèmes de conteneurs comme Kubernetes que cette séparation a eu lieu.

Aujourd’hui, Containerd fait également partie de la Cloud Native Computing Foundation (CNCF).

Ce que Containerd peut apporter en tant que container runtime

Containerd est devenu interopérable avec k8s puisqu’il est désormais capable d’implémenter le CRI. En tant qu’environnement d’exécution de container, il permet alors de :

Limiter la mémoire totale et les partages CPU alloués aux conteneurs
Isoler les processus dans un conteneur pour les écarter des processus hôtes
Extraire l’image du conteneur dans les parties isolées du système hôte en garantissant que le conteneur ne peut accéder aux fichiers d’autres conteneurs ou fichiers hôtes
Configurer des variables d’environnement dans le conteneur
Ajouter et supprimer des fonctionnalités Linux lors du démarrage d’un conteneur
Créer votre propre espace de noms réseau pour l’attacher à un conteneur au démarrage