Les conteneurs signifient encore "Docker" pour beaucoup de gens. Docker a popularisé l'utilisation moderne des conteneurs dans le développement et le déploiement de logiciels. De nos jours, d'autres technologies sont également présentes. Voici comment Containerd, Docker et Kubernetes sont liés.
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 vise à simplifier le fonctionnement des charges de travail conteneurisées sur de grandes flottes de machines.
À ces débuts, Kubernetes était inextricablement lié à Docker. Il a utilisé Docker directement pour interagir avec les conteneurs, même s'il n'avait besoin que d'un sous-ensemble de fonctionnalités :les parties responsables de l'exécution des conteneurs.
L'interface utilisateur centrée sur le développeur de Docker a gêné Kubernetes. Il fallait contourner les aspects humains du projet en utilisant un outil dédié, Dockershim. Les problèmes ont été 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'ascension 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 devenaient claires. Dans le même temps, l'Open Container Initiative (OCI) a commencé à normaliser les formats et les durées d'exécution des conteneurs. Cela a abouti à une spécification OCI définissant un conteneur pouvant être utilisé par plusieurs runtimes, dont Docker est un exemple.
Docker a ensuite extrait son runtime de conteneur dans un nouveau projet, containerd. Cela inclut la fonctionnalité 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 créer de nouvelles solutions de conteneurs.
L'émergence de containerd permet à des 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 disposent désormais d'une interface plus accessible pour l'exécution du conteneur. La standardisation OCI des technologies de conteneur signifie que d'autres environnements d'exécution peuvent également être utilisés.
Comprendre le rôle de Containerd
Pour bien comprendre le conteneur, il est nécessaire d'examiner la nature des conteneurs. Les conteneurs sont vraiment 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 résumer ce câblage de bas niveau. Il est conçu comme une «couche client» sur laquelle le logiciel de conteneur se construit ensuite. Il peut s'agir de logiciels destinés aux développeurs, tels que 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 sortant 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 façon dont les trois technologies se combinent :
- 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 désormais containerd comme runtime de conteneur.
- Conteneur – 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 agrégés sur un ou plusieurs « nœuds » physiques. Historiquement, Kubernetes était lié à Docker.
Containerd n'est qu'un backend de conteneur. Les autres conteneurs implémentant la spécification Open Containers Runtime incluent runC et CRI-O. Ces runtimes peuvent également être utilisés avec Docker et Kubernetes ; chacun a ses propres distinctions.
L'OCI
L'OCI est l'organisme chargé de définir les normes de conteneurs. Son travail a contribué à faciliter l'interopérabilité entre les différentes technologies de composants.
La spécification d'image de l'OCI définit à quoi un conteneur doit ressembler. La spécification d'exécution définit une interface pour l'exécution des conteneurs. Des projets comme containerd implémentent ensuite ces spécifications.
Il est important de noter que l'une des priorités de l'OCI est de soutenir 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 à l'interface d'exécution du conteneur (CRI). Il s'agit d'une abstraction spécifique à Kubernetes par rapport à 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 dans le 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 à l'exécution pour gérer l'extraction et l'exécution des images, et non l'interface de haut niveau fournie par des outils tels que Docker et Kubernetes.
Kubernetes et Docker
Kubernetes a rendu obsolète le runtime Docker fin 2020. Il sera supprimé dans une future version, actuellement prévue pour fin 2021. Après cela, Kubernetes n'offrira plus Docker runtime Support. Un environnement d'exécution 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 affecter 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 que vous créez avec docker build fonctionnera toujours dans Kubernetes, même après la suppression de l'environnement d'exécution Docker.
Deux technologies différentes sont envisagées :l'interface de ligne de commande de Docker utilisé pour créer et exécuter des conteneurs, et le Docker runtime autour de laquelle l'interface de ligne de commande s'enroule.
C'est trop déroutant !
En quelques années seulement, les conteneurs ont transformé le travail de nombreux développeurs. 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 tout leur potentiel.
L'évolution vers la normalisation a entraîné 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'environnements d'exécution de conteneur de bas niveau interchangeables (comme containerd et runC). Cela permet un plus grand degré de flexibilité et permet aux nouvelles technologies basées sur les conteneurs de s'établir d'une manière alignée sur les normes.