Cette page explique comment migrer vos clusters et pools de nœuds standards Google Kubernetes Engine (GKE) de Docker vers des images de nœuds utilisant l'environnement d'exécution de conteneurs 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. L'environnement d'exécution containerd est un environnement d'exécution de conteneur standard compatible avec GKE.
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. L'environnement d'exécution containerd est considéré comme étant plus économe en ressources et plus sécurisé que l'environnement d'exécution Docker.
Pour migrer l'environnement d'exécution du conteneur, procédez comme suit :
- Identifier les nœuds qui utilisent l'environnement d'exécution Docker
- Vérifier l'impact de la migration
- Modifier l'image de nœud
Avant de commencer
Avant de commencer, effectuez les tâches suivantes :
- Activez l'API Google Kubernetes Engine. Activer l'API Google Kubernetes Engine
- Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande
gcloud components update
.
Identifier les nœuds qui utilisent l'environnement d'exécution Docker
Vous pouvez vérifier les nœuds qui utilisent des images de nœud basées sur Docker à l'aide des méthodes suivantes :
- Utilisez un script pour effectuer une itération sur tous les nœuds de tous les clusters GKE de votre projet Google Cloud.
- Utilisez Google Cloud CLI,
kubectl
ou Google Cloud Console pour identifier les images de nœuds. - Utilisez les insights et recommandations d'obsolescence pour identifier les clusters et les nœuds dans des zones ou des régions spécifiques d'un projet Google Cloud.
Nous vous recommandons d'utiliser un script pour identifier rapidement tous les nœuds que vous devez migrer.
Utiliser un script pour identifier les nœuds Docker
Le script suivant effectue une itération sur tous les nœuds de chaque cluster dans vos projets disponibles et vous fournit des recommandations exploitables, telles que :
- Si le provisionnement automatique des nœuds est configuré pour les images Docker ou non.
- Suggestions d'images de nœuds containerd pour la migration
- Versions d'image de nœud suggérées pour la migration
- Suggestions de commandes à exécuter pour migrer les nœuds et les paramètres identifiés
Le script ignore les clusters GKE Autopilot, qui utilisent par défaut Container-Optimized OS avec l'image de nœud containerd.
Exécutez le script suivant :
Identifier les images de nœuds à l'aide de Google Cloud
Vous pouvez vérifier les images de nœuds des nœuds existants à l'aide de Google Cloud CLI, de kubectl
ou de la console Google Cloud.
gcloud
Exécutez la commande suivante :
gcloud container node-pools list \
--cluster=CLUSTER_NAME \
--format="table(name,version,config.imageType)"
Remplacez CLUSTER_NAME
par le nom de votre cluster.
Le résultat ressemble à ce qui suit :
NAME NODE_VERSION IMAGE_TYPE
default-pool 1.19.6-gke.600 UBUNTU
Console
Accédez à la page Google Kubernetes Engine dans Google Cloud Console.
Dans la liste des clusters, cliquez sur le nom du cluster que vous souhaitez vérifier.
Sélectionnez l'onglet Nœuds.
Dans la section Pools de nœuds, vérifiez la valeur indiquée dans la colonne Type d'image.
kubectl
Exécutez la commande suivante :
kubectl get nodes -o wide
Le résultat ressemble à ce qui suit :
# For Docker runtime
NAME STATUS VERSION OS-IMAGE CONTAINER-RUNTIME
gke-node-1 Ready v1.16.15-gke.6000 Container-Optimized OS from Google docker://19.3.1
gke-node-2 Ready v1.16.15-gke.6000 Container-Optimized OS from Google docker://19.3.1
gke-node-3 Ready v1.16.15-gke.6000 Container-Optimized OS from Google docker://19.3.1
La valeur de la colonne CONTAINER-RUNTIME
indique l'environnement d'exécution et la version.
Identifier les clusters à l'aide des insights et recommandations concernant les abandons
GKE détecte l'utilisation de certaines fonctionnalités et API obsolètes, y compris les images de nœuds basées sur Docker. Pour en savoir plus, consultez la page Abandons de GKE.
Dans le cadre de la détection de l'utilisation des abandons, GKE génère des insights et des recommandations qui identifient l'utilisation des images de nœuds basées sur Docker avec le sous-type d'insights DEPRECATION_K8S_1_24_DOCKERSHIM
.
Une combinaison d'insight et de recommandation identifie un cluster comportant des nœuds qui utilisent des images de nœud basées sur Docker. Chaque insight et recommandation fournit une liste des pools de nœuds spécifiques d'un cluster qui utilisent des images de nœuds basées sur Docker et doivent être migrés vers des images de nœuds containerd.
Pour commencer, suivez les instructions permettant d'afficher les insights et recommandations liés aux abandons. Pour les commandes de gcloud CLI, utilisez l'option suivante pour n'afficher que les insights sur cet abandon :
--filter="insightSubtype:DEPRECATION_K8S_1_24_DOCKERSHIM"
Une fois que vous avez identifié les pools de nœuds du cluster qui utilisent des images de nœuds basées sur Docker, suivez les instructions pour remplacer l'image de nœud par une image de nœud containerd.
Vérifier l'impact de la migration
Avant de migrer vos clusters et pools de nœuds de production vers des images de nœuds utilisant containerd, nous vous recommandons vivement de tester l'impact de la migration dans un environnement de préproduction afin de minimiser le risque de problèmes.
Lorsque vous migrez les nœuds, nous vous recommandons de séparer la migration de la mise à niveau des nœuds, afin de pouvoir isoler les variables au moment de vérifier le bon fonctionnement de la charge de travail avec la nouvelle configuration. En outre, si vous effectuez en même temps la mise à niveau du pool de nœuds vers la version 1.24, tout rollback de ce changement devient impossible, car la version 1.24 n'est pas compatible avec les nœuds Docker et vous ne pouvez pas rétrograder les versions mineures.
Remplacer l'image de nœud par une image containerd
Si vous avez utilisé le script pour identifier vos nœuds Docker, vous pouvez utiliser les commandes suggérées renvoyées par le script pour modifier les paramètres de provisionnement automatique des nœuds et les images de nœud vers les équivalents containerd.
Vous pouvez également migrer des nœuds depuis un type d'image Docker vers un type d'image containerd en mettant à jour le pool de nœuds et en définissant une autre image à l'aide de gcloud CLI ou de la console Google Cloud.
GKE utilise la stratégie et la configuration sélectionnées de mise à niveau de nœuds pour migrer l'image d'un nœud. Pour cette migration, nous vous recommandons d'utiliser la stratégie de mise à niveau bleu-vert : si vos charges de travail rencontrent des problèmes avec la nouvelle image de nœud lors de la mise à niveau, vous pouvez effectuer un rollback vers l'environnement précédent avec la configuration d'origine de l'image de nœud.
gcloud
Exécutez la commande ci-dessous.
gcloud container clusters upgrade CLUSTER_NAME \
--image-type=NODE_IMAGE \
--node-pool=POOL_NAME \
--cluster-version=NODE_VERSION
Remplacez les éléments suivants :
NODE_IMAGE
: image de nœud que les nœuds doivent utiliser.POOL_NAME
: nom du pool de nœuds à migrer.NODE_VERSION
: version existante du pool de nœuds. Il est recommandé d'activer cette option car, dans le cas contraire, GKE tente de mettre à niveau la version du pool de nœuds vers la version du plan de contrôle et de mettre à jour l'image du nœud au cours de la même opération. Si le plan de contrôle exécute la version 1.24, la commande échoue. Si le plan de contrôle exécute la version 1.23, la commande aboutit, ce qui vous empêche de tester les deux modifications (mise à niveau de la version et mise à jour de l'image) de manière isolée.
Le résultat ressemble à ce qui suit :
NAME NODE_VERSION IMAGE_TYPE
default-pool 1.23.6-gke.600 UBUNTU_CONTAINERD
Console
Accédez à la page Google Kubernetes Engine dans Google Cloud Console.
Dans la liste des clusters, cliquez sur le nom du cluster que vous souhaitez vérifier.
Cliquez sur l'onglet Nœuds.
Dans la section Pools de nœuds, cliquez sur le nom du pool de nœuds que vous souhaitez modifier.
Sur la page Détails du pool de nœuds, cliquez sur
Modifier.Dans la section Nœuds, sous Type d'image, cliquez sur Modifier.
Sélectionnez l'un des types d'images containerd.
Cliquez sur Modifier.
Effectuer un rollback vers les images de nœuds Docker
Si vos nœuds ont été migrés automatiquement ou manuellement vers des nœuds containerd et que vous avez constaté un problème avec vos charges de travail, procédez comme suit pour revenir aux images de nœuds Docker :
- Choisissez l'étape suivante en fonction de l'état de l'opération :
- Si l'opération est toujours en cours, vous pouvez annuler et effectuer un rollback.
- Si l'opération est terminée, consultez les étapes de la section précédente et sélectionnez l'image Docker équivalente.
- Configurez une exclusion de maintenance pour empêcher temporairement GKE de relancer la migration.
- Examinez la cause première du problème afin de pouvoir migrer depuis Docker et vous assurer que votre cluster exécute une version compatible de GKE.
- Essayez à nouveau de remplacer l'image de nœud par une image containerd. Si vous supprimez l'exclusion de maintenance, GKE déclenche à nouveau l'opération.
Mettre à jour les configurations des outils IaC (Infrastructure as Code)
Si vous utilisez des outils IaC tels que Terraform, Ansible ou Pulumi pour gérer les clusters GKE, veillez à mettre à jour vos configurations pour qu'elles utilisent des images de nœuds containerd, afin d'empêcher les outils de rapprocher l'état précédemment souhaité avec nouvel état réel. Par exemple, le fournisseur Terraform pour GKE accepte les types d'images configurables.
Mettez à jour les configurations afin que l'outil ne rétablisse pas l'image de nœud vers une image de nœud basée sur Docker après avoir migré vers des images de nœuds containerd.
Modifier l'image de nœud par défaut pour le provisionnement automatique des nœuds
Si vous utilisez le provisionnement automatique des nœuds dans votre cluster, remplacez le type d'image par défaut par une image de nœud containerd. La modification du type d'image par défaut ne s'applique qu'aux nouveaux pools de nœuds provisionnés automatiquement. Vous devez modifier manuellement l'image de nœud pour les pools de nœuds provisionnés automatiquement existants.
Vous pouvez modifier le type d'image de provisionnement automatique des nœuds par défaut à l'aide de gCloud CLI ou d'un fichier de configuration.
gcloud
Exécutez la commande ci-dessous.
gcloud container clusters update CLUSTER_NAME \
--enable-autoprovisioning \
--autoprovisioning-image-type=IMAGE_TYPE
Remplacez les éléments suivants :
CLUSTER_NAME
: nom du cluster à mettre à jour.IMAGE_TYPE
: le type d'image de nœud, qui peut être l'un des éléments suivants :cos_containerd
ubuntu_containerd
Fichier
Vous pouvez utiliser un fichier de configuration YAML pour modifier le type d'image de nœud par défaut pour le provisionnement automatique des nœuds. Lorsque vous utilisez un fichier, vous devez également spécifier des valeurs maximales pour les ressources de processeur et de mémoire.
Enregistrez le fichier YAML suivant :
resourceLimits: - resourceType: 'cpu' minimum: 4 maximum: 10 - resourceType: 'memory' maximum: 64 autoprovisioningNodePoolDefaults: imageType: 'IMAGE_TYPE'
Remplacez
IMAGE_TYPE
par le type d'image containerd.Appliquez la configuration :
gcloud container clusters update CLUSTER_NAME \ --enable-autoprovisioning \ --autoprovisioning-config-file=FILE_NAME
Remplacez
FILE_NAME
par le chemin d'accès au fichier de configuration.
Dépannage
Pour le dépannage et les problèmes connus liés aux solutions de contournement, reportez-vous à la section Dépannage de l'environnement d'exécution des conteneurs.
Étape suivante
- En savoir plus sur le provisionnement automatique des nœuds
- Apprenez-en plus sur les images de nœuds containerd.