Récemment Kubernetes a annoncé  déprécier Docker comme runtime CRI  (Container Runtime Interface). S’en est suivi un mouvement de panique dans mon entourage sur la disparition de Docker. Au fil des articles de cette série, vous avez pu vous familiariser un petit peu plus avec les technologies de conteneurs, et constater que d’une part Docker a de multiples usages et que d’autre part il existe des alternatives convaincantes quelque soit l’usage qu’on en fait.

Dans cet article, nous allons parler des runtimes CRI, ces outils que Kubernetes (k8s pour les intimes) va utiliser pour créer les pods et lancer les conteneurs. Nous commencerons par un aperçu de ce qu’est le CRI de Kubernetes, nous verrons ensuite comment Docker s’intègre à Kubernetes avant de faire un rapide tour d’horizon des runtimes OCI qui existent aujourd’hui.

Le Container Runtime Interface de Kubernetes

Kubernetes est un orchestrateur de conteneurs que l’on ne présente plus aujourd’hui. Qui dit orchestrateur de conteneurs, dit que celui-ci doit démarrer des conteneurs à un moment donné. Cette tâche ainsi que l’implémentation concrète des  pods  est dévolue au runtime CRI.

Sur chacun des nœuds d’un cluster k8s se trouve la kubelet. Il s’agit grosso modo de “l’agent k8s”, il est chargé de la gestion des conteneurs sur son nœud. C’est donc à lui d’appeler le runtime CRI. En plus de gérer le cycle de vie des conteneurs, le runtime CRI gère également la gestion des images depuis une registry.

L’interface CRI utilise le protocole  gRPC  et les messages sont au format  protocol buffer , un format binaire de Google.

Maintenant que nous en savons un petit peu plus sur le CRI, faisons un tour des runtimes CRI, en commençant par Docker.

Docker

Docker permet de faire toutes les opérations attendues par un runtime CRI, sauf qu’il n’implémente pas l’interface CRI. Un composant a été ajouté dans le code de la kubelet pour explicitement gérer les conteneurs avec Docker : c’est le  dockershim . C’est ce composant qui a été déprécié par Kubernetes.

Il faut rester vigilant au fait de ne plus utiliser Docker avec k8s : cela signifie aussi qu’il ne sera plus possible de faire du “Docker in Docker”, puisque les nœuds n’auront plus de socket Docker.

Il est donc maintenant évident que Docker n’est plus l’outil idéal pour s’interfacer avec Kubernetes. Mais docker n’est plus le monolithe qu’il était, il utilise containerd, qui lui est compatible avec le CRI.

Containerd

Containerd  est un container engine utilisé par Docker qui est compatible avec le CRI. Il est le remplaçant le plus naturel à Docker dans un environnement k8s. C’est même une amélioration par rapport à Docker puisque l’on supprime un daemon et un composant du nœud.

Pour en savoir plus sur containerd, je vous invite à consulter l’épisode 2 de cette série sur les conteneurs.

Passons maintenant à l’autre runtime CRI bien connu : CRI-O.

CRI-O

CRI-O  est un runtime CRI qui a la particularité d’être dédié à cette tâche, ce n’est pas un outil aux multiples usages comme Docker ou containerd. Il se veut léger et minimal.



Les principaux contributeurs de CRI-O sont Red Hat, Intel, Suse, Hyper et IBM. Il est le runtime par défaut d’ Openshift  (Red Hat),  SUSE CaaS platform  et  openSUSE Kubic  entre autres.

Conclusion

Docker ne sera bientôt plus utilisable par Kubernetes, mais comme nous l’avons vu, containers et CRI-O permettent tous les deux d’assurer le même service. Ils sont tous les deux déjà utilisés en production.

• Un article court et bien fait sur les différents runtime : container engine, runtime OCI et runtime CRI
• The differences between Docker, containerd, CRI-O and runc

• Série par Ian Lewis sur les runtimes avec des explications sur les mécanismes bas-niveaux
• Container Runtimes Part 1: An Introduction to Container Runtimes  
• Container Runtimes Part 2: Anatomy of a Low-Level Container Runtime
• Container Runtimes Part 3: High-Level Runtimes
• Container Runtimes Part 4: Kubernetes Container Runtimes & CRI