Blog Agaetis

Les runtime Kubernetes CRI, deux alternatives à Docker

13/04/2021| François Travais read_time 3 min.
Retour au blog

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

Source : CNCF

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

Source : 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

Source : CNCF

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

Source : CNCF

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.

Pour lire les précédents articles de notre série sur les containers : 

Un sujet vous intéresse ? Une question ? Contactez-nous

Nos adresses

Clermont-Ferrand
9, allée Evariste Galois
63170 Aubière
Tél. 04 73 35 47 51
Paris
21, rue de la banque
75002 Paris
Tél. 01 44 63 53 13
Lyon
52, Quai Rambaud
69002 Lyon