Qu’est-ce que containerd et quel est son lien avec Docker et Kubernetes? –

Les conteneurs signifient toujours «Docker» pour de nombreuses personnes. Docker a popularisé l’utilisation moderne des conteneurs dans le développement et le déploiement de logiciels. De nos jours, d’autres technologies existent également. Voici comment Containerd, Docker et Kubernetes sont liés les uns aux autres.

Les débuts

Lors de sa sortie en 2013, Docker était un projet autonome avec tout ce dont vous aviez besoin pour créer et exécuter des conteneurs. Ce qui lui manquait, c’était un moyen simple d’orchestrer les déploiements de conteneurs dans le cloud.

Fin 2013, un groupe de Googleurs abordait déjà ce problème avec un prototype de ce qui allait devenir Kubernetes. Kubernetes est destiné à simplifier le fonctionnement des charges de travail conteneurisées sur de grands parcs de machines.

À l’époque, Kubernetes était inextricablement lié à Docker. Il utilisait Docker directement pour interagir avec les conteneurs, même s’il ne nécessitait qu’un sous-ensemble de fonctionnalités – les parties responsables de l’exécution des conteneurs.

L’interface utilisateur centrée sur les développeurs de Docker a gêné Kubernetes. Il fallait contourner les aspects humains du projet en utilisant un outil dédié, Dockershim. Les problèmes étaient aggravés par les directions différentes dans lesquelles Docker et Kubernetes se dirigeaient. Docker a lancé Swarm, sa propre alternative à Kubernetes, offrant l’orchestration en tant que «mode» Docker intégré.

L’essor de Containerd

Au fur et à mesure que Kubernetes se développait et que de plus en plus d’outils tiers apparaissaient autour de Docker, les limites de son architecture sont devenues claires. Parallèlement, l’Open Container Initiative (OCI) a commencé à standardiser les formats de conteneurs et les temps d’exécution. Cela a abouti à une spécification OCI définissant un conteneur qui pourrait être utilisé par plusieurs runtimes, dont Docker est un exemple.

Docker a ensuite extrait son environnement d’exécution de conteneur dans un nouveau projet, containerd. Cela inclut les fonctionnalités de Docker pour l’exécution de conteneurs, la gestion du stockage de bas niveau et la gestion des transferts d’images. Containerd a été donné à la Cloud Native Computing Foundation (CNCF) afin de fournir à la communauté des conteneurs une base pour la création de nouvelles solutions de conteneurs.

L’émergence de containerd permet aux projets comme Kubernetes d’accéder plus facilement aux éléments «Docker» de bas niveau dont ils ont besoin. Au lieu d’utiliser réellement Docker, ils ont maintenant une interface plus accessible à l’environnement d’exécution du conteneur. La standardisation OCI des technologies de conteneurs signifie que d’autres temps d’exécution peuvent également être utilisés.

Comprendre le rôle de Containerd

Pour bien comprendre containerd, il est nécessaire d’examiner la nature des conteneurs. Les conteneurs sont en fait une abstraction de diverses fonctionnalités du noyau Linux. Pour exécuter un conteneur, vous devez utiliser des appels système pour configurer l’environnement conteneurisé. Les étapes varient selon la plate-forme et la distribution.

Containerd intervient pour faire abstraction de ce câblage de bas niveau. Il est conçu comme une «couche client» sur laquelle le logiciel conteneur se construit ensuite. Il peut s’agir d’un logiciel orienté développeur, comme Docker, ou d’outils de développement orientés cloud tels que Kubernetes.

Auparavant, le développement de Kubernetes se retrouvait avec deux mauvaises options: continuer à écrire des shims autour de la lourde interface Docker ou commencer à interagir directement avec les fonctionnalités du noyau Linux. En supprimant containerd de Docker, une troisième alternative est devenue disponible: utiliser containerd comme couche d’abstraction système, sans impliquer Docker.

Voici un résumé de la combinaison des trois technologies:

• Docker – Un logiciel orienté développeur avec une interface de haut niveau qui vous permet de créer et d’exécuter facilement des conteneurs à partir de votre terminal. Il utilise maintenant containerd comme runtime de conteneur.
• Containerd – Une abstraction des fonctionnalités du noyau qui fournit une interface de conteneur de niveau relativement élevé. D’autres projets logiciels peuvent l’utiliser pour exécuter des conteneurs et gérer des images de conteneurs.
• Kubernetes – Un orchestrateur de conteneurs qui fonctionne avec plusieurs environnements d’exécution de conteneurs, y compris containerd. Kubernetes se concentre sur le déploiement de conteneurs de manière agrégée sur un ou plusieurs «nœuds» physiques. Historiquement, Kubernetes était lié à Docker.

Containerd n’est qu’un seul backend de conteneur. Les autres conteneurs implémentant la spécification Open Containers Runtime incluent runC et CRI-O. Ces environnements d’exécution peuvent également être utilisés avec Docker et Kubernetes; chacun a ses propres distinctions.

L’OCI

L’OCI est l’organe chargé de définir les normes relatives aux conteneurs. Ses travaux ont contribué à faciliter l’interopérabilité entre les différentes technologies de composants.

La spécification d’image de l’OCI définit à quoi doit ressembler un conteneur. La spécification d’exécution définit une interface pour l’exécution de conteneurs. Des projets comme containerd implémentent ensuite ces spécifications.

Surtout, l’une des priorités de l’OCI est de prendre en charge l’expérience d’utilisation des conteneurs popularisée par Docker. Ses images doivent être exécutables sur la plate-forme cible sans aucun argument défini par l’utilisateur (par exemple docker run hello-world:latest). Les images OCI doivent donc contenir suffisamment de métadonnées pour permettre cette configuration automatique.

Vous pouvez également voir des références à Container Runtime Interface (CRI). Il s’agit d’une abstraction spécifique à Kubernetes sur la spécification OCI. Le CRI s’appuie sur les spécifications OCI pour permettre la prise en charge des environnements d’exécution de conteneurs interchangeables dans Kubernetes.

Qu’en est-il de mes images Docker?

Les images que vous créez avec Docker ne sont pas du tout des «images Docker». Comme Docker utilise désormais le runtime containerd, vos images sont construites au format standardisé Open Container Initiative (OCI).

Vous ne devriez pas avoir à vous soucier des incompatibilités entre vos images Docker et l’environnement dans lequel elles sont utilisées. Les images que vous créez avec Docker peuvent toujours être déployées à l’aide de Kubernetes. En effet, Kubernetes prend également en charge les images OCI, grâce à son utilisation de containerd (et d’autres environnements d’exécution conformes aux normes). C’est à la Durée pour gérer l’extraction et l’exécution des images, pas l’interface de haut niveau fournie par des outils tels que Docker et Kubernetes.

Kubernetes et Docker

Kubernetes a abandonné le runtime Docker à la fin de 2020. Il sera supprimé dans une prochaine version, actuellement prévue pour la fin de 2021. Après cela, Kubernetes ne proposera plus Docker. Durée Support. Un runtime alternatif compatible avec les spécifications OCI, tel que containerd, devra être utilisé à la place.

Cette annonce a suscité des inquiétudes quant aux implications pour les développeurs. Le changement ne devrait pas avoir d’incidence sur la plupart des workflows existants. Comme nous l’avons déjà vu, Docker produit des images compatibles OCI que les environnements d’exécution compatibles OCI peuvent exécuter. Toutes les images avec lesquelles vous créez docker build fonctionnera toujours dans Kubernetes, même après la suppression du runtime Docker.

Deux technologies différentes sont envisagées – le Docker interface de ligne de commande utilisé pour créer et exécuter des conteneurs, et le Docker Durée autour duquel l’interface de ligne de commande s’enroule.

C’est trop déroutant!

En quelques années seulement, les conteneurs ont transformé le nombre de développeurs qui travaillent. L’expansion de l’écosystème environnant a été un sous-produit naturel de ce changement. Le Containers === Docker la mentalité s’est avérée trop étouffante car elle empêchait des outils comme Kubernetes de montrer leur plein potentiel.

L’évolution vers la normalisation a abouti à une pléthore de nouveaux termes, outils et technologies. Néanmoins, rien n’a vraiment changé pour les développeurs, que vous interagissiez avec la CLI Docker sur votre machine ou un cluster Kubernetes dans le cloud.

Chaque interface utilisateur de haut niveau (telle que Docker et Kubernetes) bénéficie désormais d’un choix d’exécutions de conteneurs de bas niveau interchangeables (comme containerd et runC). Cela permet une plus grande flexibilité et permet aux nouvelles technologies basées sur les conteneurs de s’établir de manière normalisée.