Résumé

  • containerd est un démon open source diplômé de la CNCF qui gère le contenu des images, les instantanés, les métadonnées des conteneurs et les tâches en cours d’exécution pour des plateformes de niveau supérieur sous Linux et Windows.
  • Le projet est issu de la refonte du runtime de Docker, a rejoint la Cloud Native Computing Foundation en 2017 et est devenu une couche d’infrastructure partagée plutôt qu’une plateforme de conteneurs complète.
  • Kubernetes accède à containerd par l’intermédiaire de la Container Runtime Interface, tandis que le réseau, l’isolation de bas niveau, la confiance accordée aux images et la planification du cluster restent des responsabilités distinctes qui déterminent toujours le résultat.
  • containerd 2.3 est devenue la branche LTS actuelle le 30 avril 2026; les correctifs ultérieurs de sécurité et de cycle de vie montrent que le nettoyage, la réconciliation et la livraison des correctifs font partie de la justesse du runtime.

Une fuite de montage constitue une défaillance du runtime, même si le processus a démarré

Le 10 juillet 2026, containerd a publié la version 2.3.3. Parmi les correctifs figuraient des modifications concernant la validation de l’état des bacs à sable, la gestion des sorties NRI et un chemin d’échec de hook susceptible de provoquer des fuites de montages. Rien de cela ne paraît aussi spectaculaire qu’une évasion de conteneur.

Pour un opérateur, cependant, un montage qui aurait dû disparaître mais persiste constitue une véritable défaillance du runtime: répétées sur un parc de nœuds, de petites fuites peuvent consommer les ressources des hôtes, compliquer le nettoyage et transformer une machine autrement saine en un système qu’il faut évacuer ou reconstruire.

Cette version illustre pourquoi containerd est important. La plupart des utilisateurs n’interagissent pas directement avec le démon. Ils demandent à Kubernetes de démarrer un pod, à Docker d’exécuter un conteneur ou à un service cloud géré de fournir un nœud. containerd se trouve sous ces requêtes et les transforme en transitions d’état portant sur le contenu des images, les instantanés de systèmes de fichiers, les enregistrements de conteneurs, les shims du runtime et les processus actifs.

La plateforme visible peut se rétablir en replanifiant les charges, mais le runtime doit malgré tout laisser le nœud dans un état compréhensible et réutilisable.

Le lancement d’un processus n’est donc qu’un aspect de la justesse. La création, l’observation, la suppression et la récupération comptent toutes. Une tâche qui démarre rapidement mais laisse derrière elle un montage, un état réseau obsolète, un shim orphelin ou des métadonnées non réconciliées n’est pas correcte sur le plan opérationnel. La défaillance peut apparaître lentement, après des centaines ou des milliers d’opérations qui semblaient pourtant réussies.

C’est la tension centrale qui entoure containerd. Le projet a réussi en devenant une couche intermédiaire commune sous de nombreux produits. Cette même ubiquité rend ses décisions ordinaires de cycle de vie lourdes de conséquences pour de vastes parcs qui peuvent ne jamais révéler son nom aux équipes applicatives.

containerd est devenu utile en s’arrêtant avant de devenir une plateforme

containerd est un démon d’exécution intégré, et non un produit de conteneurs complet. Il ne planifie pas les charges de travail à l’échelle d’un cluster, ne fournit pas de modèle de service applicatif et ne décide pas de la manière dont une entreprise doit construire et déployer ses logiciels. Ses services gRPC stables exposent des capacités plus limitées: transférer et stocker le contenu des images, maintenir les métadonnées, préparer les instantanés de systèmes de fichiers, créer les enregistrements de conteneurs et gérer les tâches en cours d’exécution.

Cette limite est délibérée. Docker Engine peut construire au-dessus une offre destinée aux utilisateurs. Kubernetes peut l’utiliser comme runtime de nœud par l’intermédiaire de la Container Runtime Interface. Les fournisseurs cloud peuvent l’intégrer à leurs images de nœuds. Les distributions Linux peuvent le livrer avec leurs propres valeurs par défaut et rétroportages. Chaque système supérieur peut présenter un modèle opérationnel différent sans réimplémenter les mêmes mécanismes fondamentaux de cycle de vie des images et des processus.

Cette distinction explique aussi pourquoictr, la commande fournie avec containerd, est facile à employer à mauvais escient. Le projet la considère comme une interface instable de débogage et de développement, et non comme un contrat destiné aux utilisateurs et pris en charge. Un processus de production qui dépend discrètement des mécanismes internes dectrpeut fonctionner pendant des années, puis découvrir qu’il s’est construit sur la partie du projet qui avait précisément été laissée libre d’évoluer.

La frontière stable dépasse donc une simple décision d’API. C’est un choix de gouvernance. Le projet promet une compatibilité autour des services documentés tout en conservant la possibilité de remplacer les implémentations qui se trouvent derrière eux. containerd ne constitue une couche partagée utile que si les produits en aval respectent la même frontière.

Docker a extrait un cœur d’exécution commun et créé une infrastructure réutilisable par d’autres produits

containerd est né au sein de Docker. Les premières versions de Docker réunissaient dans un même produit la distribution des images, la construction, les API, le réseau et le cycle de vie des processus. À mesure que la plateforme s’est développée, le travail d’exécution a été séparé afin que les mécanismes durables de préparation et de supervision des conteneurs puissent évoluer indépendamment du reste de l’offre Docker.

L’historique public des versions commence par une branche 0.0 datée du 4 décembre 2015. En mars 2017, Docker a fait don de containerd à la Cloud Native Computing Foundation. La version 1.0 a suivi le 5 décembre 2017, établissant des API gRPC stables et un contrat d’intégration orienté vers la production. La CNCF a annoncé la graduation du projet le 28 février 2019.

Cette évolution institutionnelle était importante parce que Docker était à la fois l’initiateur du projet et une entreprise exploitant une plateforme commerciale. Il est plus facile pour des fournisseurs cloud concurrents, des distributeurs Linux et des fournisseurs Kubernetes de dépendre d’un runtime lorsque sa gouvernance en amont n’appartient pas exclusivement à un seul fournisseur de produit. La licence Apache 2.0 permet également une large utilisation commerciale et open source sans imposer à chaque adoptant de partager le même modèle économique.

L’hébergement par une fondation n’a effacé ni l’histoire de Docker ni l’influence des entreprises qui emploient des mainteneurs. Il a modifié la voie formelle par laquelle le code partagé pouvait être gouverné. containerd est devenu une infrastructure que Docker continuait d’utiliser, plutôt qu’un composant interne que les autres devaient accepter aux conditions de Docker.

Le résultat technique a été tout aussi important. Les plateformes supérieures ont obtenu une couche durable entre l’orchestration et les runtimes de bas niveau tels que runc. Au lieu que chaque produit invente son propre magasin d’images, son propre cycle de vie des instantanés et son propre modèle de supervision des processus, plusieurs produits ont pu converger vers les mêmes mécanismes et se différencier ailleurs.

Images, conteneurs et tâches désignent délibérément des choses différentes

Le vocabulaire des conteneurs prête à confusion parce que les outils destinés aux utilisateurs regroupent souvent plusieurs entités sous un même mot. containerd ne le fait pas. Une image désigne du contenu et des métadonnées. Un enregistrement de conteneur conserve la configuration d’exécution prévue et les libellés. Une tâche représente l’ensemble des processus actifs créés à partir de cette définition. Chacun peut suivre un calendrier différent.

Un enregistrement de conteneur peut subsister après l’arrêt d’une tâche. Une image peut rester présente après la suppression de tous les conteneurs qui l’utilisaient. Une tâche peut s’interrompre alors que les métadonnées décrivant son conteneur existent encore. Cette séparation facilite le redémarrage, l’inspection et la récupération, car le démon n’a pas à considérer la durée de vie d’un processus comme celle de chaque entité qui lui est associée.

Elle crée également une obligation opérationnelle. La suppression d’une entité ne prouve pas automatiquement que tous les systèmes de fichiers, blobs, shims ou ressources réseau associés ont été récupérés. Une supervision qui compte les conteneurs sans comprendre les tâches peut signaler un état trompeur. Un code de nettoyage qui suppose qu’une suppression entraîne toutes les autres peut laisser des ressources derrière lui.

Le modèle d’entités n’est donc pas un détail d’implémentation. Il constitue la réponse du runtime à un problème fondamental: la configuration souhaitée, le contenu stocké et l’exécution active sont des formes d’état différentes. Un système qui vise une récupération fiable doit pouvoir déterminer laquelle a échoué.

Cette distinction devient particulièrement importante après une défaillance partielle. Si un redémarrage du démon, un épisode de pression sur le nœud ou une erreur de hook interrompt une opération à mi-chemin, le processus de récupération doit disposer de suffisamment d’informations durables pour déterminer ce qui a déjà eu lieu et ce qui doit encore être supprimé ou recréé.

L’adressage par contenu prouve quels octets sont arrivés, pas s’il faut leur faire confiance

Les images de conteneurs sont des graphes de contenu immuable. containerd stocke les blobs selon leur condensat cryptographique, ce qui permet de réutiliser un contenu identique et de vérifier son identité octet par octet. Les enregistrements d’images relient les noms et les manifestes à ce contenu, tandis que les services de transfert résolvent les références de registres et déplacent les blobs nécessaires vers le stockage local.

Ce modèle réduit les doublons et fournit un moyen stable de préciser quels octets un nœud a reçus. Il n’établit pas qui les a publiés, si l’éditeur mérite confiance, si une signature est acceptable ou si le logiciel contient une vulnérabilité connue. Une image malveillante peut avoir un condensat parfaitement valide. Une balise mutable peut pointer vers différents contenus au fil du temps, alors même que chaque blob individuel reste correctement adressé.

Cette distinction compte parce que containerd s’inscrit souvent dans un système plus large de chaîne d’approvisionnement. L’authentification auprès des registres, les politiques de signature, les nomenclatures logicielles, les attestations, l’analyse des vulnérabilités et les politiques d’admission sont gérées par d’autres composants ou par les produits en aval. Le runtime peut préserver l’intégrité du contenu sans devenir un cadre de confiance complet.

Pour les opérateurs, la règle pratique est simple: l’identité d’une image et la confiance accordée à cette image sont deux contrôles différents. L’analyse d’un incident doit consigner à la fois le condensat exécuté et la politique qui a autorisé son exécution. Qualifier un stockage adressé par condensat de système de sécurité revient à confondre deux questions distinctes.

Cette séparation facilite également la portabilité. Un modèle de contenu stable permet à différentes plateformes supérieures d’utiliser les mêmes données locales, mais des différences de coordonnées de registre, de politique de confiance et de sélection de plateforme peuvent toujours rendre une image utilisable sur un parc et bloquée sur un autre.

Les snapshotters transforment les images immuables en systèmes de fichiers opérationnels

Une image peut être stockée sans être prête à être exécutée. Un conteneur actif a besoin d’une vue du système de fichiers qui associe les couches de l’image à un état modifiable. containerd délègue ce travail aux plugins snapshotters.

L’interface des snapshotters sépare la distribution du contenu de l’implémentation du système de fichiers. Un snapshotter peut préparer des instantanés actifs, en lecture seule ou validés, les monter pour le dépaquetage ou l’exécution, puis les supprimer. Les implémentations courantes comprennent des approches fondées sur overlay et des approches natives, tandis que les snapshotters spécialisés ou distants peuvent modifier la quantité de données récupérée avant le démarrage d’une charge.

L’avantage réside dans la modularité. Le démon central n’a pas à être réécrit pour chaque stratégie de système de fichiers. Les fournisseurs cloud, les fournisseurs de stockage et les plateformes de périphérie peuvent optimiser le démarrage, l’utilisation du disque ou l’accès distant derrière une frontière de service commune.

Le coût est que le comportement des instantanés n’est pas uniforme. Le ramasse-miettes, la sémantique des montages, le comportement des quotas, la latence de démarrage et la récupération dépendent de l’implémentation. Une étude comparative qui attribue un démarrage à froid rapide à « containerd » sans préciser le chemin de l’image, le registre, le disque et le snapshotter est donc incomplète.

Le correctif de la fuite de montage dans la version 2.3.3 rappelle le même principe sous l’angle de la défaillance. L’état du stockage doit être annulé proprement lorsque des hooks ou des étapes du cycle de vie échouent. Si un instantané ou un montage reste référencé à tort, du contenu peut demeurer sur le disque après que la plateforme supérieure considère la charge comme supprimée. À l’échelle d’un parc, le comportement du nettoyage devient une question de capacité.

Les snapshotters distants et à récupération différée renforcent ce compromis. Ils peuvent réduire le délai de démarrage ou l’utilisation du disque local en rendant une plus grande partie du chemin d’image disponible à la demande. Ils font aussi de la disponibilité du registre ou du stockage distant une condition de l’exécution, contrairement à une image entièrement locale. L’abstraction reste stable alors que le modèle de défaillance évolue sous celle-ci.

Les shims runtime v2 permettent à une tâche de survivre au démon qui l’a créée

containerd n’exécute normalement pas lui-même un processus de conteneur Linux. Il utilise un shim de runtime pour communiquer avec un runtime de bas niveau tel que runc, qui effectue les opérations finales de création et d’exécution au moyen des primitives du système d’exploitation hôte.

Le modèle runtime v2 attribue à chaque tâche ou bac à sable un intermédiaire qui peut rester actif indépendamment du démon containerd de longue durée. Si le démon redémarre, les charges en cours n’ont pas nécessairement à s’arrêter avec lui. containerd peut se reconnecter aux shims et reconstituer la supervision à partir de l’état préservé.

Il s’agit d’une propriété de résilience significative. Un démon d’exécution peut être corrigé ou redémarré sans que chaque charge d’un nœud devienne automatiquement indisponible. Elle permet aussi à plusieurs runtimes de bas niveau de coexister derrière une même API supérieure, y compris des runtimes en bac à sable qui modifient la frontière d’isolation.

Cette garantie a des limites. Un shim mort ou orphelin, un état local corrompu, un défaut du runtime de bas niveau ou une défaillance du noyau de l’hôte peuvent encore entraîner la perte de la supervision ou de la charge elle-même. Le redémarrage d’un nœud diffère de celui d’un démon. Une corruption du disque diffère du redémarrage propre d’un processus. L’architecture assure une continuité face à une catégorie de défaillances; elle ne rend pas l’exécution indépendante de la machine.

Ce modèle d’exécution en couches explique pourquoi l’expression « runtime de conteneurs » peut être ambiguë. containerd est un service durable de cycle de vie et d’état. runc et les autres runtimes de bas niveau créent les processus. Kata Containers ou gVisor peuvent modifier le modèle d’isolation inférieur, tandis que containerd reste le courtier placé au-dessus. Une attribution précise des incidents commence par l’identification de la couche qui a réellement échoué.

Kubernetes dépend de containerd sans lui confier le cluster

Kubernetes accède à containerd par l’intermédiaire de la Container Runtime Interface. Le plugin CRI intégré implémente les services d’exécution et d’image attendus par kubelet, associe les bacs à sable des pods et les conteneurs aux entités containerd et assure la coordination avec le runtime et le chemin réseau configurés.

containerd est ainsi devenu une dépendance directe sur de nombreux nœuds Kubernetes sans pour autant devenir Kubernetes. Le planificateur continue de choisir où un pod doit s’exécuter. Les contrôleurs continuent de réconcilier l’état applicatif souhaité. kubelet continue de gérer l’intention au niveau du nœud. Le réseau et les politiques du cluster reposent sur des implémentations CNI et d’autres composants. Le noyau de l’hôte et le runtime de bas niveau fournissent toujours les primitives qui isolent les processus.

Cette frontière importe en cas de défaillance. Un pod qui ne démarre pas peut être bloqué par la configuration de kubelet, la compatibilité CRI, une image manquante, une erreur du snapshotter, la configuration CNI, un shim, runc ou le noyau. Présenter l’événement comme une simple « défaillance de containerd » peut masquer le transfert précis qui a échoué. Attribuer chaque problème de runtime à « Kubernetes » est tout aussi imprécis.

La compatibilité comporte aussi une dimension de version. Les distributions Kubernetes valident des combinaisons précises de containerd, de CRI et de configuration. Les services gérés peuvent intégrer des correctifs en aval ou des versions retardées. Une version en amont peut être correcte alors qu’une image de nœud cloud reste fondée sur une ancienne compilation, et un fournisseur cloud peut rétroporter un correctif de sécurité sans modifier la version de la manière attendue par un utilisateur de la version en amont.

Pour cette raison, l’entité opérationnelle pertinente est la nomenclature du nœud plutôt que le seul nom du projet: containerd, runtime de bas niveau, binaires CNI, snapshotter, noyau, configuration et correctifs en aval. C’est cette pile qui démarre et supprime réellement un pod.

CNI et NRI maintiennent le périmètre étroit de containerd en transférant davantage de responsabilités à la pile du nœud

L’architecture de containerd repose largement sur la composition. Le chemin CRI peut invoquer des plugins externes Container Network Interface pour créer et supprimer le réseau des bacs à sable. Les plugins Node Resource Interface peuvent observer les événements du cycle de vie et ajuster les paramètres de ressources ou d’exécution autorisés. Les snapshotters et les plugins de runtime remplacent les composants de stockage et d’exécution sans réécrire l’API centrale.

C’est ainsi que le démon reste suffisamment petit pour être réutilisable. Les spécialistes du réseau peuvent faire évoluer les implémentations CNI. Les fournisseurs de matériel peuvent utiliser NRI ou des mécanismes connexes au lieu de maintenir une bifurcation privée. Les développeurs de stockage peuvent ajouter des snapshotters distants. Les projets de bac à sable peuvent intégrer d’autres runtimes.

Chaque extension ajoute aussi une dépendance en matière de défaillance et de confiance. Un échec CNI ADD ou DEL peut laisser subsister des adresses, des interfaces ou des espaces de noms. Un plugin NRI défectueux peut bloquer le cycle de vie ou modifier les allocations sur un nœud. Un snapshotter tiers peut provoquer des fuites de montages ou mal gérer le ramasse-miettes. Un plugin de runtime peut fonctionner correctement avec un noyau et échouer avec un autre.

La maturité du projet central ne se transmet pas automatiquement au graphe d’extensions. Une version prise en charge de containerd ne certifie pas chaque plugin, runtime ou configuration qui lui est associé. Les opérateurs doivent connaître l’origine, la version, la signature, le circuit d’assistance et le plan de retour en arrière de chaque extension privilégiée admise dans le cycle de vie du nœud.

Le graphe de plugins constitue donc à la fois le principal mécanisme de portabilité de containerd et l’une de ses principales sources de risque de composition. Le projet réduit le besoin de bifurcations en créant des points d’extension. En contrepartie, la fiabilité en production doit être évaluée sur l’ensemble de ces extensions plutôt que déduite de la réputation du démon central.

Les espaces de noms organisent les clients au sein d’un démon; ils ne créent pas une nouvelle frontière d’hôte

Les espaces de noms de containerd permettent à différents clients de regrouper et d’adresser des ressources au sein d’un même démon. Docker, CRI et d’autres systèmes intégrateurs peuvent séparer logiquement leurs images, conteneurs, instantanés et tâches au lieu de les faire entrer en collision dans un espace d’entités unique.

Cette organisation est utile lorsque plusieurs clients partagent le système. Elle n’équivaut pas à isoler deux locataires sur des machines distinctes. Le démon reste un processus privilégié, le socket d’administration reste une interface à fort impact et les charges de conteneurs ordinaires dépendent toujours de l’isolation offerte par le noyau de l’hôte, sauf recours à un bac à sable plus robuste.

Un client disposant d’un accès suffisant au démon peut être en mesure d’énumérer les espaces de noms ou d’agir sur plusieurs d’entre eux, selon ses autorisations et le comportement des plugins. La frontière est donc un mécanisme de cadrage de l’API, et non un substitut aux autorisations Unix, à la protection du socket, aux espaces de noms du noyau, aux cgroups, aux contrôles d’accès obligatoires ou à une isolation fondée sur des machines virtuelles.

Cette distinction compte sur le plan commercial autant que technique. Une plateforme peut promouvoir une séparation logique tout en plaçant plusieurs clients sur un runtime privilégié et un noyau hôte partagés. L’argumentaire de sécurité doit être établi au niveau de l’hôte et du bac à sable, et non déduit de la présence d’une chaîne d’espace de noms containerd.

Le projet gagne à maintenir cette frontière explicite. Il peut fournir un modèle d’organisation clair sans prétendre résoudre l’isolation des locataires, qui relève d’une couche inférieure de la pile.

Le socket du démon doit relever du même modèle de menace que l’administration de l’hôte

containerd a le pouvoir de créer des processus, des montages et des espaces de noms, ainsi que de transmettre aux couches inférieures des spécifications d’exécution à fort impact. Sur de nombreux systèmes, contrôler le démon ou son socket peut revenir à contrôler l’hôte.

L’accès au socket, son éventuelle exposition distante, l’authentification, l’audit et les privilèges des plugins constituent donc des contrôles de sécurité primaires. Considérer le démon comme un détail d’implémentation invisible peut conduire les équipes à protéger l’API Kubernetes tout en accordant moins d’attention à l’interface locale du nœud qui crée effectivement les processus privilégiés.

La même prudence s’applique à la configuration du runtime. Un conteneur peut demander des capacités, des périphériques, des espaces de noms et des montages qui modifient sa relation avec l’hôte. containerd transmet ces spécifications à un runtime de bas niveau et aux mécanismes du noyau. La couche d’exécution peut appliquer les restrictions configurées; elle ne peut pas éliminer une vulnérabilité du noyau ni rendre sûre une spécification privilégiée dangereuse au seul motif qu’elle utilise une API standard.

L’attribution en matière de sécurité nécessite donc plusieurs niveaux. Une vulnérabilité dans le traitement de l’API de containerd diffère d’une évasion runc, d’un défaut du noyau, d’un plugin CNI dangereux ou d’une charge Kubernetes dotée de privilèges excessifs. Un correctif containerd en amont ne prouve pas que chaque nœud en aval est protégé, et une version sûre de containerd ne sécurise pas un noyau vulnérable.

La version 2.3.2, publiée le 18 juin 2026, comprenait des correctifs pour cinq CVE containerd répertoriées ainsi que d’autres corrections du runtime. La bonne question opérationnelle n’est pas de savoir si la dernière version est « sûre ». Il faut déterminer quel avis concerne la configuration déployée, quelle compilation contient le correctif et quand cette compilation a effectivement atteint les nœuds en service.

Les événements et le ramasse-miettes font de la réconciliation une tâche permanente

Un runtime de longue durée doit mémoriser suffisamment d’état pour se remettre d’opérations interrompues tout en récupérant les ressources devenues inutiles. Les mécanismes de métadonnées, d’événements et de ramasse-miettes de containerd soutiennent ce travail.

Les événements permettent aux orchestrateurs et aux outils de supervision de réagir aux changements du cycle de vie et du contenu sans interroger en permanence chaque entité. Ils sont utiles pour la réconciliation et l’observabilité, mais les consommateurs ne doivent pas considérer un flux d’événements comme une base de données parfaitement ordonnée et durable à jamais. La logique de reconnexion doit toujours interroger l’état actuel et se remettre d’observations manquées ou reçues dans un ordre différent.

Les baux, les libellés et les références de métadonnées contribuent à protéger le contenu et les instantanés encore utilisés tout en permettant la collecte des ressources inaccessibles. Ce mécanisme maîtrise la croissance de l’espace disque dans les parcs qui utilisent beaucoup d’images. Il peut aussi échouer dans les deux sens: des références qui fuient conservent indéfiniment les données, tandis que des références erronées peuvent exposer du contenu à un nettoyage prématuré.

La pression sur le disque constitue donc un problème de runtime même lorsque la mémoire et le processeur des applications semblent normaux. Les téléchargements d’images, les couches dépaquetées, les instantanés modifiables et les états obsolètes se disputent tous le stockage de l’hôte. Un nœud incapable de récupérer, dépaqueter ou nettoyer des images peut devenir indisponible pour le planificateur bien avant que l’hôte lui-même ne tombe en panne.

C’est une autre raison d’exploiter containerd au moyen d’objectifs de service au niveau du nœud qui incluent la suppression et la récupération. La plateforme doit connaître non seulement la vitesse de démarrage d’un pod, mais aussi si les opérations échouées laissent la machine dans un état qui reste sûr à réutiliser.

La branche LTS 2.3 transforme l’ingénierie des versions en contrat opérationnel

La politique de publication de containerd est devenue plus explicite avec le passage du projet à l’ère 2.x. La branche 1.6 a commencé le 15 février 2022. La branche LTS 1.7 a suivi le 10 mars 2023. La version 2.0 est arrivée le 5 novembre 2024, puis les versions 2.1 et 2.2 ont poursuivi la transition en 2025.

Le 30 avril 2026, le projet a publié containerd 2.3 et l’a désignée comme la branche actuelle de support à long terme, avec une prise en charge prévue jusqu’au 30 avril 2028. Le projet a également adopté un cycle de versions mineures de quatre mois et publié des niveaux de plateformes, des attentes de stabilité des API et des chemins de mise à niveau pris en charge.

Il s’agit d’une politique d’infrastructure, et non d’un simple entretien du dépôt. Les fournisseurs cloud et les distributions Kubernetes doivent savoir combien de temps une branche recevra des correctifs, quelles séquences de mise à niveau sont censées fonctionner et quelles plateformes le projet peut tester en continu. Le statut LTS permet à un opérateur de planifier la maintenance des images de nœuds par rapport à un horizon déclaré, plutôt que de déduire la prise en charge de l’activité des commits.

Le contrat est volontairement limité. Les garanties de stabilité s’appliquent aux API documentées et aux plateformes prises en charge.ctrne fait pas partie de cette promesse. Les plugins tiers ne sont pas automatiquement couverts. Les distributions en aval peuvent rétroporter, retarder ou modifier les versions. L’horizon de prise en charge du projet n’indique pas à une entreprise quand son fournisseur cloud géré remplacera une image de nœud vulnérable.

À la date limite de recherche de l’article, le 6 août 2026, la version 2.3.3 était la dernière version stable vérifiée, après le correctif 2.3.2 de juin comportant des éléments de sécurité. La version 2.4 était provisoirement prévue pour le 26 août 2026. Cette date constituait un projet, et non une publication achevée, et devra être actualisée avant publication si l’article dépasse cette date limite.

Le modèle de publication facilite la gouvernance d’une dépendance cachée. Sa réussite se mesurera à la qualité des rétroportages, à la santé de la branche 2.3 jusqu’en 2028 et au temps nécessaire aux parcs en aval pour absorber les correctifs importants.

Les niveaux de plateformes montrent où la portabilité dépend d’une capacité de test durable

containerd prend en charge plusieurs environnements d’exploitation, mais cette prise en charge ne signifie pas abstraitement que chaque architecture se comporte de manière identique. À la date limite de recherche, les plateformes de niveau 1 comprenaientlinux/amd64,linux/arm64etwindows/amd64.

Un niveau de plateforme reflète la maintenance de tests fonctionnels et la capacité du projet. Les conteneurs Windows utilisent des primitives d’hôte et des chemins d’exécution différents de ceux de Linux. La sémantique des systèmes de fichiers, l’isolation des processus et la couverture d’intégration continue diffèrent. Une fonctionnalité présente dans l’API commune peut donc présenter une maturité ou un comportement en cas de défaillance différent selon les familles de plateformes.

La politique de niveaux est à la fois un document technique et un document relatif aux ressources. Une plateforme ne peut rester de premier plan que si les mainteneurs disposent d’exécuteurs fiables, de matériel, de tests et de personnes capables d’intervenir lorsque ces tests échouent. La portabilité dépend de l’infrastructure durable qui sous-tend l’affirmation de compatibilité.

Cela entraîne deux conséquences pour les acheteurs. Premièrement, une fonctionnalité du projet doit être évaluée par rapport à la combinaison exacte de plateforme et de runtime prise en charge. Deuxièmement, la promotion ou la rétrogradation d’un niveau de plateforme est importante, car elle signale une évolution de la capacité du projet à garantir la branche, et non une simple modification documentaire.

Le même principe s’applique aux intégrations matérielles spécialisées. Un démon peut exposer un point d’extension général alors que la qualité en production d’un chemin particulier pour GPU, stockage ou réseau dépend d’un code et de tests maintenus ailleurs.

La CNCF a créé un amont neutre, mais containerd déployé compte encore de nombreux responsables

containerd est gouverné comme un projet CNCF par l’intermédiaire de mainteneurs, de committers, de responsables de versions, de documents de gouvernance et d’un processus de sécurité. Le projet ne possède ni conseil d’administration conventionnel, ni actionnaires, ni équipe dirigeante. L’autorité découle des rôles au sein du projet et des processus de contribution, plutôt que d’une participation au capital.

Ce modèle permet à des entreprises concurrentes d’utiliser le runtime. Un fournisseur cloud n’a pas besoin d’acheter containerd à un autre fournisseur cloud. Une distribution Linux peut l’intégrer. Docker peut l’embarquer. Les fournisseurs Kubernetes peuvent le valider. Des mainteneurs employés par différentes organisations peuvent travailler sur le même code en amont.

Une gouvernance neutre ne signifie pas que l’influence des employeurs disparaît. La capacité d’ingénierie provient en grande partie de personnes rémunérées par des fournisseurs ou contribuant par l’intermédiaire d’institutions qui bénéficient du runtime. L’intégration continue, la responsabilité des versions et le travail de sécurité nécessitent du temps et des infrastructures. Les documents publics de gouvernance présentent les rôles formels, mais ne permettent pas de mesurer pleinement l’influence informelle sur la feuille de route ou les priorités commerciales privées.

Le contrôle du déploiement est encore plus distribué. Les mainteneurs en amont décident de ce qui entre dans une version officielle. Les distributions Linux choisissent ce qu’elles intègrent et rétroportent. Les fournisseurs cloud déterminent quelle compilation entre dans une image de nœud et quand cette image atteint les clients. Les opérateurs de clusters décident quand évacuer et remplacer les nœuds actifs. Le même projet peut donc exister simultanément sous la forme de plusieurs compilations de production sensiblement différentes.

Ce contrôle en couches est essentiel pour rendre compte des incidents. La date d’une version en amont n’est pas la date d’achèvement du déploiement d’un correctif sur le marché. Un avis cloud peut décrire un parc corrigé même lorsque le numéro de version public diffère de celui de l’amont. La seule réponse fiable consiste à retracer la compilation exacte et son parcours de déploiement.

containerd crée de la valeur économique sans disposer d’une ligne de revenus traditionnelle

containerd n’est pas une entreprise de produit autonome publiant un compte de résultat. Les preuves fournies ne comportent aucun chiffre d’affaires de containerd, aucune valorisation d’entreprise ni aucun décompte audité des déploiements. La CNCF héberge le projet, les employeurs financent une grande partie de l’ingénierie par le temps de travail de leur personnel, et les entreprises en aval tirent leurs revenus de produits et de services qui intègrent le runtime.

Sa valeur économique prend principalement la forme d’une duplication évitée. Docker, les fournisseurs Kubernetes, les clouds et les distributions peuvent partager les mécanismes d’images et de cycle de vie au lieu de financer chacun un démon entièrement distinct. Un correctif peut se propager à plusieurs produits. Une API stable peut réduire le coût de maintenance des intégrations sur plusieurs années.

Cette structure de bien commun pose aussi une question de durabilité. De nombreuses entreprises peuvent dépendre de containerd sans contribuer à son ingénierie à proportion de cette dépendance. Les branches LTS ont besoin de responsables de versions, d’intégration continue, de rétroportages et de réponse de sécurité longtemps après que l’intérêt pour une nouvelle version s’est déplacé ailleurs. Les tests propres aux plateformes nécessitent du matériel et des mainteneurs. L’intégration rend le projet précieux tout en rendant son budget direct difficile à voir.

L’engagement LTS 2.3 présente donc une dimension financière, même sans budget publié. Une branche de deux ans exige un travail soutenu. La santé de cet engagement doit être évaluée à partir de la responsabilité des versions, du rythme des correctifs, de la couverture des tests et de la diversité des contributeurs, plutôt qu’au moyen d’une estimation inventée des revenus du projet.

Il n’existe pas non plus de recensement complet des déploiements. L’utilisation étendue de containerd dans Docker, Kubernetes et les offres cloud ressort clairement du rôle du projet, mais cela ne permet pas d’affirmer une part de marché précise. La description la plus défendable est que containerd est largement intégré et important, et non qu’il exécute un pourcentage connu des conteneurs dans le monde.

Les solutions de remplacement ne concurrencent containerd qu’une fois la frontière définie

Les comparaisons de runtimes de conteneurs mélangent souvent des produits intervenant à des couches différentes. CRI-O est une solution de remplacement directe dans les déploiements CRI orientés Kubernetes. Docker Engine est une plateforme plus large destinée aux utilisateurs qui intègre containerd, plutôt qu’un remplacement de même portée pour chaque couche. Podman et la pile libpod utilisent un autre modèle d’utilisateur et de démon. runc est un runtime OCI de bas niveau qui se trouve couramment sous containerd au lieu de lui faire concurrence.

Kata Containers et gVisor modifient le modèle d’isolation sous le courtier du cycle de vie. Ils peuvent fonctionner par l’intermédiaire d’intégrations de runtime tandis que containerd continue de gérer les services supérieurs d’images et de tâches. Kubernetes est lui-même un orchestrateur placé au-dessus du runtime de nœud. L’Open Container Initiative définit des spécifications utilisées par la pile plutôt que d’exploiter des conteneurs.

Ces distinctions comptent parce que remplacer un composant ne supprime pas toutes les dépendances. Passer de containerd à un autre runtime CRI affecte les images de nœuds, les tests de compatibilité, le stockage des instantanés, la configuration du runtime et les outils opérationnels. Passer de runc à un bac à sable fondé sur des machines virtuelles modifie une autre frontière. Le remplacement de Docker Engine peut encore laisser containerd dans l’architecture résultante.

La comparaison la plus utile est donc fonctionnelle. Quelle couche est remplacée? Quel état doit être déplacé? Quels outils opérationnels supposent l’ancienne API ou l’ancien modèle d’entités? Quels modes de défaillance changent? Un « marché des runtimes » générique masque davantage qu’il n’explique.

L’avantage de containerd ne tient pas à l’absence de solutions de remplacement. Il réside dans le fait que de nombreux produits ont accumulé du code d’intégration, des connaissances opérationnelles et des tests autour de sa couche intermédiaire stable. Ces connaissances installées créent un coût de changement, même si la licence logicielle ne produit aucun verrouillage juridique.

Le véritable test de portabilité commence lorsqu’une opération s’arrête à mi-chemin

La conception de containerd repose sur une séparation utile des responsabilités. Le démon gère l’état et les services durables du runtime. Les snapshotters préparent les systèmes de fichiers. Les shims servent d’intermédiaires pour les tâches actives. Les runtimes de bas niveau créent les processus. CNI configure le réseau. Kubernetes ou un autre système supérieur décide ce qui doit s’exécuter. Le noyau fournit les primitives d’isolation proprement dites.

Cette répartition permet au projet de rester suffisamment petit pour être réutilisé. Elle signifie aussi qu’aucun composant ne peut garantir à lui seul l’ensemble du résultat. Un conteneur peut échouer parce que l’image n’a pas pu être résolue, que le snapshotter n’a pas pu effectuer le montage, que CNI n’a pas pu nettoyer, que le shim a disparu, que le runtime a rejeté la spécification ou que le noyau a refusé l’opération.

Un runtime de nœud mature doit donc rendre les défaillances intelligibles. Les opérateurs doivent savoir quel état a changé avant l’arrêt de l’opération, quelles ressources subsistent, si une nouvelle tentative est sûre et si le nœud peut être remis en service sans reconstruction. La gestion des erreurs, l’état des tâches, les événements, le nettoyage et la récupération sont aussi importants que le lancement nominal.

C’est la meilleure manière de comprendre la réussite à long terme de containerd. Le projet a rendu possible une couche intermédiaire commune sans la transformer en plateforme de conteneurs complète. Il conservera sa valeur si ces mécanismes partagés restent suffisamment stables pour être intégrés, suffisamment transparents pour être diagnostiqués et suffisamment remplaçables pour que leur ubiquité ne devienne pas une raison d’accepter une dette opérationnelle cachée.