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).

Managed Kubernetes de IONOS

Le moyen le plus simple de gérer les charges de travail en conteneur. Configuration automatisée des clusters Kubernetes ainsi que visibilité et contrôle maximum des clusters K8s.

Stockage persistant
Assistance 24/7
Configuration automatisée des clusters

Comment fonctionne CRI-O ?

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é.

De Docker à CRI-O en passant par Kubernetes

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.

Note

Utilisez Kubernetes dès maintenant avec Managed Kubernetes de IONOS.

Architecture et fonctionnement de CRI-O

CRI-O est composé des éléments suivants :

  • La bibliothèque de logiciel conteneurs/image pour le téléchargement des images conteneurs des différentes sources en ligne.
  • La bibliothèque de logiciel conteneurs/stockage pour gérer les couches de conteneurs et créer le système de fichiers des conteneurs d’un pod.
  • Un espace d’exécution compatible OCI pour exécuter les conteneurs. runC est un espace d’exécution standard, mais il est également possible d’utiliser d’autres espaces d’exécution compatibles comme Kata Containers.
  • L’interface de réseau de conteneurs (« container networking interface », CNI) pour la création d’un réseau, utilisation de plug-ins pour Flannel, Weave et OpenShift-SDN.
  • L’outil de surveillance des conteneurs conmon pour une surveillance continue des conteneurs.

CRI-O est également souvent utilisé en synergie avec l’outil de gestion des pods Podman. Cela fonctionne, car Podman utilise les mêmes bibliothèques de téléchargement d’images et de gestion de couches de conteneurs que CRI-O.

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

Quand utilise-t-on CRI-O ?

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

Produit Infrastructure Géré par Pris en charge par
Red Hat OpenShift Dedicated AWS, Google Cloud Red Hat Red Hat
Microsoft Azure Red Hat OpenShift Microsoft Azure Red Hat et Microsoft Red Hat et Microsoft
Amazon Red Hat OpenShift AWS Red Hat et AWS Red Hat et AWS
Red Hat OpenShift on IBM Cloud IBM Cloud IBM Red Hat et IBM
Red Hat OpenShift Online Red Hat Red Hat Red Hat
Red Hat OpenShift Container Platform Cloud privé, cloud public, machines physiques, machines virtuelles, Edge Clients Red Hat, autres
Red Hat OpenShift Kubernetes Engine Cloud privé, cloud public, machines physiques, machines virtuelles, Edge Clients Red Hat, autres

Qu’est-ce qui différencie CRI-O des autres environnements d’exécution ?

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 :

Environnement d’exécution Type Description
runC Environnement d'exécution OCI de bas niveau Runtime standard de facto dérivé de Docker et écrit en Go.
crun Environnement d'exécution OCI de bas niveau Runtime performant ; implémenté en C au lieu de Go
Kata Containers Environnement d’exécution OCI virtualisé Utilise une machine virtuelle légère (MV)
containerd Environnement d'exécution CRI de haut niveau Utilise runC par défaut
CRI-O Environnement d’exécution CRI léger Peut utiliser notamment runC, crun, Kata Containers