CRI-O, qu’est-ce que c’est ?

CRI-O est une implémentation de l’interface d’environnement d’exécution de conteneurs (Container Runtime Interface, CRI) pour Kubernetes, qui utilise les images et les environnements d’exécution (runtimes) de « l’Open Container Initiative » (OCI). Le projet a été lancé en 2016 par l’entreprise « Red Hat » et transféré en 2019 à la « Cloud Native Computing Foundation » (CNCF).

Pour comprendre le fonctionnement de CRI-O et son interaction avec les technologies utilisées, il faut revenir sur l’historique du développement de la virtualisation basée sur les conteneurs. Le logiciel Docker, qui a popularisé la virtualisation d’applications individuelles grâce à des conteneurs légers, a servi de base à la création du logiciel. Avant Docker, la virtualisation se faisait principalement à l’aide de machines virtuelles. Une machine virtuelle contient un système d’exploitation complet, tandis que plusieurs conteneurs accèdent à un noyau de système d’exploitation partagé.

Un conteneur contient en général une application qui met, la plupart du temps, un microservice à disposition. Dans la pratique, un grand nombre de conteneurs doivent, en général, être contrôlés ensemble pour réaliser une application complète. La gestion coordonnée de grands groupes de conteneurs est appelée orchestration.

Même s’il est possible d’effectuer l’orchestration avec Docker et des outils comme Docker Swarm, Kubernetes a réussi à s’imposer comme une alternative à Docker. Kubernetes regroupe plusieurs conteneurs dans un pod. Ces pods fonctionnent sur des machines appelées nœuds qui peuvent être aussi bien des machines virtuelles que physiques.

L’un des principaux problèmes de Docker résidait dans l’architecture monolithique du logiciel. Le daemon docker fonctionnait avec des privilèges administrateurs et était responsable d’un grand nombre de tâches : du téléchargement des images des conteneurs à la création de nouvelles images en passant par l’exécution de l’environnement d’exécution. Cet amalgame de tâches normalement indépendantes va à l’encontre du principe de développement de logiciel : la « séparation des préoccupations » (Separation of concerns) et provoque notamment des problèmes de sécurité. Des efforts ont donc été faits pour découpler les différentes composantes.

Lors de la création de Kubernetes, le daemon Kubernetes kubelet a été doté d’un environnement d’exécution codé en dur. Mais la nécessité de prendre en charge d’autres environnements d’exécution s’est rapidement fait sentir. Une modularisation des aspects individuels promettait un développement simplifié et plus de sécurité. Afin de rendre différents environnements d’exécution compatibles avec Kubernetes, une interface a été définie : Container Runtime Interface (CRI). CRI-O est une implémentation spécifique de cette interface.

Les processus suivants s’effectuent lors de l’utilisation de CRI-O :

1. Téléchargement d’une image conteneur OCI
2. Décompression de l’image dans un paquet du système de fichier de l’environnement d’exécution OCI.
3. Exécution du conteneur via un environnement d’exécution OCI

À l’heure actuelle CRI-O est surtout utilisé comme élément de la série de produits OpenShift de Red Hat. Il existe des implémentations OpenShift pour toutes les grandes plateformes Cloud. En outre, le logiciel peut être utilisé dans des centres de données publics ou privés comme composant de la plateforme de conteneurs OpenShift. Voici un aperçu des différents produits OpenShift :

CRI-O est un développement relativement récent dans le domaine de la virtualisation de conteneurs. Historiquement, il existe un certain nombre d’autres environnements d’exécution des conteneurs. Le principal argument de vente de CRI-O est probablement sa focalisation sur Kubernetes en tant qu’environnement. Avec CRI-O, Kubernetes sera en mesure d’exécuter directement les conteneurs sans avoir recours à des outils ou à une modification spéciale du code. CRI-O lui-même prend en charge les environnements d’exécution compatibles OCI existants. Voici un aperçu des environnements d’exécution activement développés et fréquemment utilisés :