containerd 2.0 est sorti fin 2024, et à l’époque le conseil du projet lui-même était de ne pas se précipiter : les branches 1.x resteraient supportées encore longtemps. Cette fenêtre est désormais fermée. Le support étendu de containerd 1.7 prend fin en septembre 2026, et Kubernetes 1.35 est la dernière version de Kubernetes à prendre en charge containerd 1.x : tout ce qui vient après exige la 2.x. Si un cluster tourne encore sur containerd 1.x, ce n’est plus une mise à niveau optionnelle. Ce guide présente ce qui a réellement changé et comment évaluer votre exposition avant de migrer.

containerd a versionné son API séparément du daemon

Depuis la 2.0, la version du daemon et la version de l’API gRPC ne sont plus le même numéro : containerd est passé à la 2.0, mais l’API elle-même n’a connu aucune rupture et est restée sur une ligne 1.x (passée à 1.8). La bibliothèque cliente Go a aussi migré vers son propre chemin de package. En pratique, cela signifie que la plupart des intégrations directes avec l’API ou le client Go n’ont besoin que de chemins d’import mis à jour, pas d’une réécriture : les mainteneurs de containerd ont rapporté que la migration d’au moins un outil en aval se résumait exactement à cela, un rechercher-remplacer sur les chemins d’import.

Ce qui a réellement été supprimé dans la 2.0

• La prise en charge des images Docker schema 1, désactivée par défaut. Le schema 1 a été remplacé par le schema 2 en 2014, puis par le format d’image OCI en 2017 ; si une image a plus de quelques années et n’a pas été reconstruite, c’est un candidat schema 1. containerd convertit les images schema 1 lors du pull plutôt que de les stocker telles quelles, donc la solution pratique pour une image dont vous avez encore besoin est de la récupérer une fois puis de la repousser vers votre registre, ce qui effectue la conversion à votre place.
• La prise en charge de l’API CRI v1alpha2. Kubernetes lui-même est passé à l’API CRI v1 stable dès la version 1.23 ; tout kubelet moderne utilise déjà la v1. Ce qui est réellement à risque, ce sont les outils tiers (agents de supervision, scanners de sécurité, tout ce qui dialogue directement avec le socket CRI) qui n’auraient pas été mis à jour. Tout ce qui monte le socket containerd en bind-mount ou qui s’exécute en mode privilégié mérite d’être vérifié en premier.
• Les deux plus anciennes implémentations de shim (io.containerd.runtime.v1.linux et io.containerd.runc.v1), ne laissant que io.containerd.runc.v2. C’était déjà la valeur par défaut depuis des années, donc la plupart des clusters ne voient aucun changement de comportement, simplement la suppression de chemins de code que plus rien n’utilisait.
• Le snapshotter aufs, qui dépendait d’un système de fichiers du noyau hors arbre amont. overlayfs, le défaut de longue date, est son remplaçant et ne demande aucune action si vous n’aviez pas délibérément configuré aufs.
• Les appels système basés sur io_uring, refusés par défaut à la suite de CVE du noyau qui leur sont associées. Les workloads concernés devraient se rabattre sur d’anciens chemins d’appels système pour la même fonctionnalité plutôt que d’échouer net, bien que containerd ne puisse pas le détecter à l’avance comme il le fait pour les autres changements listés ici.

Par ailleurs, l’ancien mécanisme de plugins Go de type dlopen et les anciennes options CRI de miroirs de registre/configuration ont été dépréciés dans la 2.0 puis supprimés dans les versions 2.x suivantes, pour une raison similaire : faible usage réel, avec un remplaçant clair disponible (la configuration de registre de style hosts.toml pour ce dernier).

Savoir à quoi vous êtes réellement exposé

containerd inclut un service de dépréciation qui journalise un avertissement, horodaté, la première fois que quelque chose sur un nœud utilise réellement une fonctionnalité vouée à disparaître. Il ne se déclenche que sur un usage réel, pas de façon spéculative, donc un rapport vide signifie une mise à niveau sans surprise :

ctr deprecations list
ctr deprecations list --format json   # pour alimenter d'autres outils

C’est une fonctionnalité de la 1.x (rétroportée dans les versions correctives 1.6 et 1.7), et non de la 2.0, ce qui la rend justement utile : vérifiez-la sur votre cluster actuel, sur le runtime que vous vous apprêtez à quitter, avant de mettre quoi que ce soit à niveau. containerd efface cet état au redémarrage du daemon ; si vous avez récemment redémarré containerd ou reconstruit des nœuds, laissez d’abord tourner les workloads un certain temps pour que les schémas d’usage réels refassent surface.

Une séquence de mise à niveau pratique

1. Passez d’abord à la dernière version corrective 1.7.x, pour que le service de dépréciation soit fiable et que vous ne mélangiez pas une mise à niveau avec des correctifs de bugs sans rapport.
2. Faites tourner du trafic de production assez longtemps pour que les schémas d’usage réels apparaissent, puis vérifiez ctr deprecations list sur l’ensemble de votre parc.
3. Corrigez tout ce qui ressort : convertissez ou remplacez les images schema 1, mettez à jour les outils qui appellent encore CRI v1alpha2, vérifiez la configuration pour la syntaxe de registre dépréciée (la plupart migre automatiquement ; l’ancienne syntaxe continue de fonctionner sous un daemon 2.x pendant la transition).
4. Relancez la vérification et confirmez que la liste des dépréciations est vide.
5. Mettez d’abord à niveau vers la 2.x un cluster de test ou un sous-ensemble de nœuds, et seulement ensuite déployez plus largement.

Si vous utilisez un fournisseur Kubernetes managé, vérifiez s’il fait remonter lui-même ces avertissements de dépréciation : certains les propagent dans les conditions des nœuds ou dans leur propre console, et les intègrent au contrôle automatisé des mises à niveau, ce qui évite de devoir se connecter en SSH à chaque nœud.

Où chercher quand quelque chose ne correspond pas ici

Le projet containerd publie un tableau complet de chaque changement de la 2.0 et de son remplaçant, ainsi que des notes de version détaillées, sur containerd.io et dans le dépôt GitHub du projet. Pour tout ce que ce guide ne couvre pas, c’est la source de référence, avec le canal #containerd du Slack de la CNCF pour obtenir de l’aide directement.