New features of containerd 2.1 - Container Service for Kubernetes

Les clusters ACK exécutant Kubernetes 1.33 utilisent containerd 2,1 par défaut, ce qui améliore la sécurité des images, les performances et la stabilité.

Fonctionnalités

Cette section répertorie uniquement les fonctionnalités principales. Consultez les notes de version de containerd .

L'interface Node Resource Interface (NRI) est prise en charge et activée par défaut.
L'interface Container Device Interface (CDI) est prise en charge et activée par défaut.
L'API Sandbox est prise en charge.

Fonctionnalités et API obsolètes

Cette section répertorie uniquement les principales obsolescences. Consultez les notes de version de containerd .

Les paramètres registry.auths, registry.configs et registry.mirrors sont obsolètes. Consultez la rubrique Personnaliser les paramètres containerd d'un pool de nœuds.
Les images Docker Schema 1 ne sont plus prises en charge. Il est impossible de télécharger (pull) les images dont les manifestes sont au format application/vnd.docker.distribution.manifest.v1+json ou application/vnd.docker.distribution.manifest.v1+prettyjws. Pour les identifier, consultez la section Identifier les images Docker Schema 1.
L'appel système io_uring_* a été supprimé du profil seccomp par défaut. Les conteneurs ne peuvent plus effectuer d'appels io_uring_* par défaut.
L'API CRI v1alpha2 a été supprimée. Cette API était obsolète depuis Kubernetes 1.26 et containerd 2,1 la retire entièrement.
Le snapshotter AUFS a été supprimé.
Le paramètre [plugins."io.containerd.internal.v1".tracing] a été supprimé.

Notes sur la mise à niveau

L'API CRI v1alpha2 n'est plus prise en charge dans containerd 2,1. Si vous utilisez cette API, migrez vers CRI v1.
Avant la mise à niveau, identifiez les API obsolètes. Pour exécuter une pré-vérification depuis la console, accédez à la page des détails du cluster, choisissez Operations > Upgrade Cluster, puis exécutez la Precheck.
La mise à niveau vérifie automatiquement la présence d'API obsolètes et suspend le processus si des éléments concernés sont détectés.

Identifier les API obsolètes

Utiliser kubectl

Vérifiez si des répertoires liés à containerd sont montés sur les pods du cluster :

Les outils kubectl et jq doivent être installés. Installez jq avec la commande yum install jq .

kubectl get pods --all-namespaces -o json |
jq -r '.items[] |
  select(.spec.volumes[]?.hostPath.path as $p |
    ["/", "/var", "/var/","/var/run", "/var/run/",
     "/var/run/containerd", "/var/run/containerd/",
     "/var/run/containerd/containerd.sock",
     "/run", "/run/", "/run/containerd", "/run/containerd/",
     "/run/containerd/containerd.sock"] | index($p)) |
  .metadata.namespace + "/" + .metadata.name'

Utiliser ctr

Répertoriez les API obsolètes avec la commande ctr deprecations list :

ctr deprecations list

Identifier les images Docker Schema 1

ctr --namespace k8s.io images list 'labels."io.containerd.image/converted-docker-schema1"'

Méthodes de mise à niveau

Commencez par mettre à niveau manuellement le plan de contrôle du cluster ACK vers Kubernetes 1.33 ou une version ultérieure. Ensuite, mettez à jour un pool de nœuds pour mettre à niveau containerd.

FAQ

La mise à niveau affecte-t-elle mon activité ?

Pour mettre à niveau containerd, mettez à jour un pool de nœuds. Par défaut, les mises à niveau des pools de nœuds s'effectuent sur place (in-place), sans redémarrer les conteneurs.

Puis-je revenir à la version précédente après avoir mis à niveau containerd de la version 1.6 vers la version 2.1 ?

Non. La version 2.1 de containerd introduit l'API shim-v3, qui est incompatible avec shim-v2 de la version 1.6.

La mise à niveau de containerd de la version 1.6 vers la version 2.1 entraîne-t-elle une perte de données ?

Si vous mettez à jour un pool de nœuds pour mettre à niveau containerd, une mise à niveau sur place s'exécute par défaut et utilise les répertoires de données d'origine. Aucune perte de données ne se produit.

Container Service for Kubernetes:Containerd 2.1