De la même façon que le Java Runtime Environment (JRE) est le logiciel nécessaire pour exécuter des programmes Java sur une machine1, un container runtime est le composant logiciel indispensable pour faire fonctionner des conteneurs sur un hôte.
Le container runtime s’exécute sur tous les nœuds d’un cluster Kubernetes et prend en charge :
- Le téléchargement (“pull”) des images de conteneurs depuis les registres (Docker Hub, Quay.io, etc.).
- Le démarrage, l’arrêt et la suppression des conteneurs.
- L’allocation, l’isolation et la gestion des ressources (CPU, mémoire, réseaux, stockage) pour chaque conteneur.
- La supervision du cycle de vie complet du conteneur sur chaque hôte.
Deux concepts fondamentaux
| Concept | Explication enrichie |
|---|---|
| Container Runtime Interface (CRI) | Spécification d’APIs standardisées qui permet à Kubernetes de communiquer et piloter diverses solutions de container runtime (Docker, containerd, CRI-O…). Grâce au CRI, Kubernetes devient agnostique du runtime de conteneurs, permettant d’échanger/mettre à jour le runtime sans casser l’intégration. Le CRI définit toutes les opérations : création, démarrage, arrêt et suppression de conteneurs, gestion des images et des réseaux, etc. |
| Open Container Initiative (OCI) | Initiative open source pour standardiser les formats d’images de conteneurs et les spécifications de runtime : garantit que des conteneurs créés sur un environnement sont exécutables sur n’importe quel runtime conforme. L’OCI définit la structure des images, des métadonnées et la manière dont elles doivent être lancées (runc est le runtime de référence pour OCI). |
image.png
Runtimes courants compatibles Kubernetes
Kubernetes supporte plusieurs runtimes compatibles CRI : CRI-O, Docker Engine (legacy), containerd, etc. Tous exposent des APIs gRPC définies par le CRI pour interagir avec le cluster.
Tableau synthétique
| Runtime | Points clefs |
|---|---|
| containerd | Léger, rapide, moderne, maintenu indépendamment de Docker. |
| CRI-O | Spécifique à Kubernetes, 100% compatible CRI, utilise runc pour lancer les conteneurs. |
| Docker Engine | Historiquement utilisé, remplacé peu à peu par containerd/CRI-O dans Kubernetes récent. |
| runc | Runtime bas-niveau conforme OCI (utilisé par CRI-O, containerd…) |
Exemple de cycle « pod → conteneur » avec CRI-O
- L’utilisateur ou un controller soumet une requête de création de pod via l’API server.
- kubelet (agent par nœud) reçoit cette requête, puis appelle le runtime via les APIs CRI (gRPC).
- CRI-O :
- Vérifie si l’image demandée est dispo localement, sinon la télécharge depuis un registre via la bibliothèque containers/image.
- Génère une spécification de conteneur conforme OCI (JSON).
- Lance
runcpour créer le process conteneur selon la spec.
- kubelet surveille ensuite la santé du conteneur, remonte les états/status à l’API server et gère les redémarrages selon la stratégie du pod.
Schéma simplifié du flux (explication)
textUtilisateur → API server → kubelet → CRI-O → container registry → image → runc → conteneur lancé
Points à retenir
- C’est le container runtime qui s’occupe de toute la partie opérationnelle des conteneurs : récupération d’images, isolement, démarrage/arrêt/surveillance, gestion bas-niveau.
- Le kubelet discute exclusivement avec ce runtime via le CRI.
- Grâce à l’OCI et au CRI, Kubernetes reste compatible avec de nombreux runtimes, offrant flexibilité et évolutivité au cluster.
- Des alternatives comme gVisor ou Kata Containers peuvent également être utilisées pour une isolation renforcée.
Résumé :
Dans Kubernetes, le container runtime est la “couche d’exécution” basse qui garantit la portabilité, la flexibilité et l’automatisation du cycle de vie des conteneurs, orchestrés depuis les niveaux supérieurs du cluster (API Server et kubelet)1.