À propos de l'abandon des images de nœuds Docker

Standard

Cette page fournit des informations sur l'environnement d'exécution du conteneur containerd, la compatibilité avec Docker dans Google Kubernetes Engine (GKE) et une présentation des raisons pour lesquelles vous devez migrer vers des images de nœud qui utilisent containerd. Pour obtenir des instructions sur la migration vers une image de nœud containerd, consultez la page Migrer depuis Docker vers des images de nœuds containerd.

Présentation

Les nœuds Kubernetes utilisent l'environnement d'exécution de conteneurs pour lancer, gérer et arrêter les conteneurs s'exécutant dans les pods. Le projet Kubernetes supprime la compatibilité intégrée avec l'environnement d'exécution Docker dans Kubernetes 1.24 et versions ultérieures. Pour ce faire, Kubernetes supprime un composant appelé dockershim, qui permet à Docker de communiquer avec des composants Kubernetes tels que le kubelet.

Containerd, le nouvel environnement d'exécution par défaut, est un environnement d'exécution de conteneur standard, compatible avec Kubernetes et utilisé par de nombreux autres projets. L'environnement d'exécution containerd fournit l'abstraction de couche qui permet la mise en œuvre d'un ensemble complet de fonctionnalités telles que gVisor et le streaming d'images pour étendre les fonctionnalités de GKE. Il est également considéré comme étant plus économe en ressources et plus sécurisé que l'environnement d'exécution Docker.

En raison de cette modification, GKE ne prend plus en charge les images de nœuds qui utilisent Docker comme environnement d'exécution dans GKE 1.24 et versions ultérieures. Un cluster est affecté si l'un de ses pools de nœuds utilise des images de nœud basées sur Docker ou utilise le provisionnement automatique des nœuds avec un type d'image de nœud par défaut basé sur Docker.

D'ici le 31 juillet 2023, qui est la date de fin de vie de GKE version 1.23, GKE suspend les mises à niveau automatiques et empêche les mises à niveau manuelles vers la version 1.24. Pour mettre à niveau le plan de contrôle de votre cluster vers GKE 1.24 ou une version ultérieure avant cette date, vous devez mettre à jour la configuration du provisionnement automatique des nœuds et tous les nœuds vers l'environnement d'exécution containerd. Pour mettre à niveau un pool de nœuds, vous devez migrer vers une image de nœud utilisant l'environnement d'exécution containerd.

Après la fin de vie de la version 1.23, GKE débloquera les mises à niveau manuelles du plan de contrôle vers la version 1.24 pour les clusters qui n'ont pas encore effectué leur migration, et commencera progressivement la mise à niveau des clusters à des fins de sécurité et de compatibilité. Pour en savoir plus sur la manière dont GKE met à niveau vos clusters vers la version 1.24 et connaître nos recommandations pour la migration de vos clusters à partir d'images de nœuds Docker, consultez la section Migration automatique quand la version 1.23 arrive en fin de vie.

Images de nœuds Docker et containerd

Containerd est l'environnement d'exécution par défaut pour tous les nouveaux nœuds GKE depuis la version 1.19 sous Linux et 1.21 sous Windows. Toutefois, les clusters standards GKE ont également continué à accepter les images de nœuds utilisant Docker comme environnement d'exécution. Le tableau suivant décrit les images de nœuds basées sur Docker qui ne seront pas compatibles avec GKE version 1.24 ou ultérieure, ainsi que les équivalents containerd :

Environnement d'exécution Docker	Environnement d'exécution containerd
Container-Optimized OS avec Docker (`cos`)	Container-optimized OS avec containerd (`cos_containerd`)
Ubuntu avec Docker (`ubuntu`)	Ubuntu avec containerd (`ubuntu_containerd`)
`windows_ltsc` : Option LTSC Windows Server avec Docker	`windows_ltsc_containerd` : Option LTSC Windows Server avec Containerd
`windows_sac` : Option SAC Windows Server avec Docker	`windows_sac_containerd` : Option SAC Windows Server avec Containerd

Chronologie et jalons

Dans GKE version 1.23, vous ne pouvez plus effectuer les opérations suivantes:

Créez des clusters qui utilisent des images de nœuds basées sur Docker.
Ajouter des pools de nœuds avec des images de nœuds basées sur Docker à un cluster existant.
Activez le provisionnement automatique des nœuds en spécifiant l'option --autoprovisioning-image-type sur les images de nœuds basées sur Docker.

Si vous passez à la version 1.23 de GKE, vous pouvez continuer d'utiliser les éléments suivants:

Des pools de nœuds existants avec des images de nœuds basées sur Docker créées avant la mise à niveau
Autoscaler de cluster sur des pools de nœuds avec des images de nœuds Docker.
Provisionnement automatique des nœuds avec l'option --autoprovisioning-image-type définie sur les images de nœuds basées sur Docker, si cette option est activée avant la mise à niveau.

Dans GKE version 1.24, vous ne pouvez plus effectuer les opérations suivantes :

Si le plan de contrôle exécute la version 1.24, vous ne pouvez pas utiliser le provisionnement automatique des nœuds en spécifiant l'option --autoprovisioning-image-type sur les images de nœuds basées sur Docker.
Si le pool de nœuds exécute la version 1.24, les nœuds ne peuvent pas utiliser d'images de nœuds basées sur Docker.

Le tableau suivant récapitule les modifications à attendre lorsque vous interagissez avec les versions GKE à venir:

Action	Version 1.23 de GKE	Version 1.24 de GKE
Créer des clusters avec Docker	Non	Non
Créer des pools de nœuds avec Docker	Non	Non
Activer le provisionnement automatique des nœuds avec Docker	Non	Non
Effectuer une mise à niveau à partir de la version précédente avec la configuration de provisionnement automatique des nœuds Docker existante	Oui	Non
Utiliser des images de nœuds basées sur Docker	Oui	Non

Migration automatique quand la version 1.23 entre en fin de vie

Si vous ne passez pas à la version 1.24 et que vous ne migrez pas vers des images de nœuds containerd avant que la version 1.23 n'arrive en fin de vie le 31 juillet 2023, GKE effectuera les opérations suivantes :

Si votre cluster utilise le provisionnement automatique des nœuds avec un type d'image de nœud par défaut basé sur Docker, GKE met à jour la configuration pour employer l'image de nœud équivalente qui utilise l'environnement d'exécution containerd. Vous ne pouvez pas bloquer cette opération avec une exclusion de maintenance. Pour vérifier qu'il n'y a aucun effet négatif sur vos charges de travail, nous vous recommandons de mettre à jour manuellement votre type d'image par défaut pour le provisionnement automatique des nœuds vers une image basée sur containerd avant que GKE ne mette à jour automatiquement la configuration.
GKE met à niveau le plan de contrôle de votre cluster vers la version 1.24.
GKE migre tous les pools de nœuds qui utilisent toujours Docker vers des images de nœuds containerd à compter du 1er septembre 2023. Nous vous recommandons de migrer manuellement vos images de nœuds avant cette date. Sinon, vous pouvez demander à GKE de lancer une opération de migration de votre cluster pour utiliser des images containerd. Pour effectuer cette demande, contactez l'assistance Cloud Customer Care.

Pour bloquer temporairement la migration automatique, mettez à niveau votre cluster vers la version 1.24 ou une version ultérieure, puis configurez une exclusion de maintenance. Pour plus d'informations sur cette exclusion de maintenance, consultez la section Retarder temporairement la migration automatique vers les images de nœuds containerd.
GKE met à niveau les pools de nœuds en version 1.23 vers la version 1.24, comme c'est le cas avec toute version non compatible pour garantir l'alignement de l'état du cluster avec la règle d'asymétrie de la version Open Source. Pour en savoir plus, consultez le cycle de vie d'une version mineure GKE. Vous pouvez bloquer temporairement cette mise à niveau avec une exclusion de maintenance.

Retarder temporairement la migration automatique vers les images de nœuds containerd

Une fois que le plan de contrôle de votre cluster a été mis à niveau vers la version 1.24 ou ultérieure, vous pouvez configurer une exclusion de maintenance pour empêcher temporairement la migration des nœuds jusqu'au 29 février 2024, lorsque la version 1.25 est en fin de vie. Pour pouvoir bénéficier de cette exclusion de maintenance, votre cluster doit être enregistré dans un canal de publication. Configurez l'exclusion de maintenance avec le champ d'application "Aucune mise à niveau mineure ni mise à niveau des nœuds", et définissez l'option --add-maintenance-exclusion-end sur 2024-02-29T00:00:00Z ou une valeur antérieure. Nous vous recommandons de débloquer votre migration dès que possible et d'autoriser la mise à niveau des nœuds vers la version 1.24. Les versions mineures qui ne sont plus compatibles ne reçoivent plus de correctifs de sécurité ni de corrections de bugs.

Migrer depuis Docker vers des images de nœuds containerd

Consultez la page Migrer depuis Docker vers des images de nœuds containerd pour identifier les clusters et les pools de nœuds utilisant des images de nœuds basées sur Docker et migrer ces pools de nœuds vers des images de nœuds containerd.

Dans le cadre du modèle de responsabilité partagée de GKE, il relève des responsabilités du client de maintenir l'état des charges de travail, et des responsabilités de Google de garantir que le cluster reste fonctionnel, ce qui inclut l'exécution d'une version compatible. Nous vous recommandons vivement de tester vos charges de travail et de migrer votre cluster avant que GKE ne s'en charge automatiquement.

Avant la fin de compatibilité de la version 1.23, GKE empêche les mises à niveau automatiques ou manuelles vers la version 1.24 pour les clusters qui comportent des pools de nœuds utilisant des images de nœuds Docker. Une fois que vous avez migré votre cluster pour n'utiliser que des images containerd, les mises à niveau automatiques peuvent reprendre dans un délai d'un jour (selon le calendrier des versions GKE) ou vous pouvez mettre à niveau votre cluster manuellement.

Après la fin de compatibilité de la version 1.23, GKE débloque les mises à niveau automatiques ou manuelles vers la version 1.24, puis suit le processus de migration automatique.

Impact de la migration

Le principal changement lorsque vous migrez vers des images de nœuds containerd est que Docker ne gère plus le cycle de vie de vos conteneurs (par exemple, leur démarrage et leur arrêt). Vous ne pouvez donc pas utiliser les commandes Docker ou l'API Docker pour afficher ou interagir avec les conteneurs GKE s'exécutant sur des nœuds qui utilisent des images containerd.

La plupart des charges de travail des utilisateurs n'ont pas de dépendance à l'exécution de conteneur. L'environnement d'exécution Docker met également en œuvre containerd, de sorte que vos charges de travail se comportent de la même manière sur les images de nœuds containerd.

Vous pouvez être affecté dans les cas suivants:

Vous exécutez des pods privilégiés qui exécutent des commandes Docker.
Vous exécutez des scripts sur des nœuds extérieurs à l'infrastructure Kubernetes (par exemple, pour résoudre les problèmes à l'aide de SSH.)
Vous exécutez des outils tiers qui effectuent des opérations avec des privilèges similaires.
Certains de vos outils répondent aux journaux spécifiques à Docker dans votre système de surveillance.
Vous déployez des outils de journalisation, de surveillance, de sécurité ou d'intégration continue fournis par des fournisseurs externes dans votre cluster GKE. Contactez ces fournisseurs pour confirmer l'impact.

Vous n'êtes pas affecté dans les situations suivantes:

Vous disposez d'un pipeline de compilation en dehors du cluster GKE qui utilise Docker pour compiler et transférer des images de conteneurs.
Vous utilisez les commandes docker build et docker push dans votre cluster GKE. Les images de nœuds Linux avec containerd incluent le binaire Docker et sont compatibles avec ces commandes.

Utiliser des pods privilégiés pour accéder à Docker

Si vos utilisateurs accèdent à Docker Engine sur un nœud à l'aide d'un pod privilégié, vous devez mettre à jour ces charges de travail pour qu'elles ne dépendent pas directement de Docker. Par exemple, envisagez de migrer votre processus d'extraction de journalisation et de surveillance de Docker Engine vers les modules complémentaires du système GKE.

Créer des images de conteneurs avec containerd

Vous ne pouvez pas utiliser containerd pour créer des images de conteneurs. Les images Linux avec containerd incluent le binaire Docker afin que vous puissiez utiliser Docker pour créer et transférer des images. Toutefois, nous vous déconseillons d'utiliser des conteneurs individuels et des nœuds locaux pour exécuter des commandes permettant de créer des images.

Kubernetes ne connaît pas les ressources système utilisées par les processus locaux en dehors de son champ d'application, et le plan de contrôle de Kubernetes ne peut pas prendre en compte ces processus lors de l'allocation de ressources. Cela peut priver vos charges de travail GKE de ressources ou provoquer une instabilité sur le nœud.

Nous vous conseillons plutôt d'effectuer ces tâches à l'aide d'autres services extérieurs au champ d'application du conteneur individuel, comme Cloud Build, ou d'utiliser un outil tel que kaniko pour compiler des images en tant que charge de travail Kubernetes.

Si aucune de ces suggestions ne vous convient et que vous comprenez les risques, vous pouvez continuer à utiliser Docker sur le nœud local pour créer des images. Vous devez envoyer les images à un registre avant de pouvoir les utiliser dans un cluster GKE. Kubernetes avec containerd ne connaît pas les images compilées localement à l'aide de Docker.

Déboguer des conteneurs sur des nœuds containerd

Pour déboguer les nœuds Linux ou résoudre les problèmes associés, vous pouvez interagir avec containerd à l'aide de l'outil de ligne de commande portable crictl conçu pour les environnements d'exécution de conteneurs Kubernetes. crictl offre des fonctionnalités courantes telles que l'affichage des conteneurs et des images, la consultation des journaux et l'exécution de commandes dans les conteneurs. Reportez-vous au guide de l'utilisateur de crictl pour accéder à la liste complète des fonctionnalités compatibles et aux informations d'utilisation.

Pour les nœuds Windows Server, le daemon containerd s'exécute en tant que service Windows nommé containerd.

Les journaux sont disponibles comme suit:

Windows : C:\etc\kubernetes\logs\containerd.log
Linux: exécuter journalctl -u containerd

Vous pouvez également consulter les journaux pour les nœuds Windows et Linux dans l'explorateur de journaux sous LOG NAME: "container-runtime".

Dépannage

Pour résoudre les problèmes, consultez la section Résoudre les problèmes liés à l'environnement d'exécution containerd.