Mettre à jour manuellement un cluster ou un pool de nœuds

Ce document explique comment demander manuellement une mise à niveau ou un retour à une version antérieure pour le plan de contrôle ou les nœuds d'un cluster Google Kubernetes Engine (GKE). GKE met automatiquement à niveau la version du plan de contrôle et des nœuds pour s'assurer que le cluster bénéficie de nouvelles fonctionnalités, de corrections de bugs et de correctifs de sécurité. Toutefois, comme expliqué dans ce document, vous pouvez également effectuer ces mises à niveau manuellement.

Pour en savoir plus sur le fonctionnement des mises à niveau automatiques et manuelles des clusters, consultez À propos des mises à niveau des clusters GKE. Vous pouvez également contrôler le moment où les mises à niveau automatiques peuvent avoir lieu ou non en configurant des intervalles et des exclusions de maintenance.

Vous pouvez mettre à jour la version manuellement comme suit :

• Clusters Autopilot : mettez à niveau la version du plan de contrôle.
• Clusters standards : mettez à niveau la version du plan de contrôle et la version du pool de nœuds.

Pour mettre à niveau un cluster, GKE met à jour la version exécutée par le plan de contrôle et les nœuds, dans des opérations distinctes. Les clusters sont mis à niveau vers une version mineure plus récente (par exemple, 1.33 vers 1.34) ou une version du correctif plus récente (par exemple, 1.33.4-gke.1350000 vers 1.33.5-gke.1080000). Le plan de contrôle et les nœuds d'un cluster n'exécutent pas nécessairement la même version à tout moment. Pour en savoir plus sur les versions, consultez Gestion des versions et assistance GKE.

Pour en savoir plus sur le fonctionnement des mises à niveau de cluster, y compris les mises à niveau automatiques et manuelles, consultez À propos des mises à niveau de cluster GKE.

De nouvelles versions de GKE sont régulièrement publiées. Vous pouvez recevoir des notifications sur les nouvelles versions disponibles pour chaque cluster spécifique grâce aux notifications de cluster. Pour trouver des cibles de mise à niveau automatique spécifiques pour les clusters, obtenez des informations sur les mises à niveau d'un cluster.

Pour en savoir plus sur les versions disponibles, consultez la page Gestion des versions. Pour en savoir plus sur les clusters, consultez la page Architecture d'un cluster. Pour obtenir des conseils sur la mise à niveau des clusters, consultez Bonnes pratiques de mise à niveau des clusters.

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 la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la commande gcloud components update. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.

• Assurez-vous de disposer d'un cluster Autopilot ou Standard existant. Pour créer un cluster, consultez Créer un cluster Autopilot.

À propos des mises à niveau

Le plan de contrôle et les nœuds d'un cluster sont mis à niveau séparément. Le plan de contrôle et les nœuds du cluster n'exécutent pas nécessairement la même version à chaque fois.

Les plans de contrôle et les nœuds de cluster sont mis à niveau régulièrement, que votre cluster soit enregistré dans un canal de publication ou non.

Limites

Les clusters alpha ne peuvent pas être mis à jour.

Versions compatibles

Les notes de version vous informent lorsque de nouvelles versions sont disponibles et lorsque d'anciennes versions ne le sont plus. Vous pouvez à tout moment répertorier l'ensemble des versions des clusters et des nœuds compatibles à l'aide de la commande suivante :

gcloud container get-server-config \
    --location=CONTROL_PLANE_LOCATION

Remplacez CONTROL_PLANE_LOCATION par l'emplacement (région ou zone) du plan de contrôle, par exemple us-central1 ou us-central1-a.

Si votre cluster est enregistré dans une version disponible, vous pouvez passer à une version de correctif dans une version disponible différente avec la même version mineure que votre plan de contrôle. Par exemple, vous pouvez passer de la version 1.33.4-gke.1350000 du canal standard à la version 1.33.5-gke.1162000 du canal rapide dans votre cluster. Pour en savoir plus, consultez Exécuter des versions de correctif à partir d'un canal plus récent. Tous les clusters Autopilot sont enregistrés dans des versions disponibles.

À propos du retour à l'édition standard

Dans certains cas, vous pouvez rétrograder la version de votre cluster :

• Rétrogradation de correctif du plan de contrôle : pour limiter l'échec de la mise à niveau d'un plan de contrôle de cluster, vous pouvez revenir à une version de correctif antérieure de votre plan de contrôle si la version est une version de correctif antérieure dans la même version mineure. Par exemple, si le plan de contrôle de votre cluster exécute GKE 1.33.5-gke.1080000, vous pouvez revenir au plan de contrôle 1.33.4-gke.1350000 si cette version est toujours disponible.
• Restauration lors de la mise à niveau mineure en deux étapes du plan de contrôle (aperçu) : vous ne pouvez rétrograder le plan de contrôle d'un cluster Kubernetes vers une version mineure antérieure qu'après la mise à niveau du binaire d'une mise à niveau mineure en deux étapes du plan de contrôle avec sécurité de restauration. Si GKE a déjà effectué la deuxième étape de la mise à niveau en deux étapes (la mise à niveau de la version émulée), vous ne pouvez pas revenir à la version mineure précédente.
• Rétrogradation d'un pool de nœuds : pour remédier à une mise à niveau du pool de nœuds qui a échoué, vous pouvez revenir à une version antérieure du pool de nœuds (version de correctif ou version mineure). Assurez-vous de ne pas rétrograder les nœuds vers une version qui est antérieure de plus de deux versions mineures à la version du plan de contrôle du cluster.

En dehors des scénarios décrits dans les points précédents, vous ne pouvez pas rétrograder un cluster. Vous ne pouvez pas revenir à une version mineure antérieure d'un plan de contrôle de cluster, y compris après une mise à niveau mineure en une étape du plan de contrôle. Par exemple, si votre plan de contrôle exécute la version 1.34 de GKE, vous ne pouvez pas revenir à la version 1.33. Si vous tentez de le faire, le message d'erreur suivant s'affiche :

ERROR: (gcloud.container.clusters.upgrade) ResponseError: code=400,
message=Master cannot be upgraded to "1.33.4-gke.1350000": specified version is
not newer than the current version.

Nous vous recommandons de tester et qualifier les mises à niveau de versions mineures avec des clusters dans un environnement de test lorsqu'une nouvelle version mineure devient disponible, mais avant que la version ne devienne la version cible de mise à niveau automatique pour votre cluster. Nous vous le recommandons tout particulièrement si votre cluster risque d'être affecté par des modifications importantes dans la prochaine version mineure, comme la suppression d'API ou de fonctionnalités obsolètes. Pour en savoir plus sur la disponibilité des versions, consultez Quelles sont les versions disponibles dans un canal ?.

Mettre à niveau le plan de contrôle du cluster

GKE met automatiquement à niveau les plans de contrôle et les nœuds des clusters. Pour gérer la façon dont GKE met à niveau vos clusters, consultez Contrôler les mises à niveau des clusters.

Avec les clusters Autopilot et les clusters standards régionaux, le plan de contrôle reste disponible lors des mises à niveau du plan de contrôle. Toutefois, lorsque vous lancez une mise à niveau du plan de contrôle pour les clusters zonaux, vous ne pouvez pas modifier la configuration du cluster tant que le plan de contrôle n'est pas à nouveau accessible (dans quelques minutes). Les mises à niveau du plan de contrôle n'affectent pas la disponibilité des nœuds de calcul sur lesquels vos charges de travail s'exécutent, car ils restent disponibles pendant les mises à niveau du plan de contrôle.

Pour gérer les versions de votre cluster, vous pouvez lancer une mise à niveau manuelle à tout moment lorsqu'une nouvelle version est disponible, en utilisant l'une des méthodes suivantes :

• Mise à niveau en une étape : mettez à niveau votre plan de contrôle directement vers une version mineure ou de correctif ultérieure le plus rapidement possible. Vous pouvez utiliser cette approche si vous avez déjà validé les performances de votre cluster et de votre charge de travail sur la nouvelle version mineure.
• Mise à niveau mineure du plan de contrôle en deux étapes avec sécurité de restauration (Aperçu) : mettez à niveau votre plan de contrôle vers une version mineure ultérieure en deux étapes. Vous pouvez valider la nouvelle version mineure pendant une période de stabilisation et la restaurer si nécessaire. Cette méthode de mise à niveau n'est disponible que pour les mises à niveau vers la version 1.33 ou ultérieure, pour les mises à niveau mineures manuelles du plan de contrôle.

Mettre à niveau manuellement le plan de contrôle en une seule étape

Vous pouvez mettre à niveau manuellement votre plan de contrôle Autopilot ou Standard à l'aide de la console Cloud de Confiance ou de Google Cloud CLI.

gcloud container get-server-config \
    --location=CONTROL_PLANE_LOCATION

gcloud container clusters upgrade CLUSTER_NAME \
    --master \
    --location=CONTROL_PLANE_LOCATION

gcloud container clusters upgrade CLUSTER_NAME \
    --master \
    --location=CONTROL_PLANE_LOCATION \
    --cluster-version=VERSION

Après la mise à niveau d'un plan de contrôle standard, vous pouvez mettre à jour ses nœuds. Par défaut, la mise à niveau automatique est activée sur les nœuds standards créés à l'aide de la console Cloud de Confiance . Vous n'avez donc pas besoin de le faire manuellement. Autopilot met toujours à niveau les nœuds automatiquement.

Mise à niveau mineure du plan de contrôle en deux étapes avec sécurité de restauration

Vous pouvez mettre à niveau manuellement le plan de contrôle de votre cluster GKE Autopilot ou Standard vers la version mineure suivante en deux étapes. Ce processus en deux étapes vous permet de tester les performances de votre cluster avec la nouvelle version mineure, appelée version binaire, tout en utilisant les fonctionnalités et les API de la version mineure précédente, appelée version émulée. Pendant cette période de stabilisation, où le plan de contrôle s'exécute en mode émulation, vous pouvez revenir à la version mineure précédente si nécessaire. Pour en savoir plus sur la façon dont Kubernetes permet ce type de mise à niveau, consultez Version de compatibilité pour les composants du plan de contrôle Kubernetes.

Les mises à niveau en deux étapes fonctionnent de la manière suivante :

1. Mise à niveau binaire : GKE met à niveau le binaire du plan de contrôle vers la nouvelle version mineure, mais émule la version mineure précédente :

   • Émulation de la version précédente : le cluster exécute le nouveau binaire, mais continue d'émuler le comportement de l'API de la version mineure précédente. Par exemple, vous pouvez appeler des API qui ont été supprimées dans la nouvelle version mineure, mais qui sont toujours disponibles dans la version mineure précédente.
   • Tester le nouveau binaire : vous pouvez tester les nouveaux binaires pour détecter les régressions, les correctifs et les modifications de performances avant de rendre accessibles les fonctionnalités Kubernetes disponibles avec la nouvelle version mineure. Surveillez les métriques d'application, les journaux, les états des pods, les taux d'erreur et la latence.
   • Laissez les modifications s'imprégner : attendez entre six heures et sept jours pour vous donner le temps de tester et de surveiller. Passé ce délai, GKE effectue la mise à niveau de la version émulée.
   • Effectuer un rollback ou finaliser la mise à niveau : vous pouvez effectuer un rollback si nécessaire. Vous pouvez également passer à l'étape suivante si vous êtes sûr de la nouvelle version mineure, si vous ne voulez pas attendre la fin de la période de test et si vous êtes prêt à commencer à utiliser les nouvelles fonctionnalités et les modifications de l'API.

2. Mise à niveau de la version émulée : GKE met à jour la version émulée pour qu'elle corresponde à la nouvelle version binaire.

   • Active les nouvelles fonctionnalités : toutes les nouvelles fonctionnalités et les modifications de l'API de la nouvelle version mineure sont activées.
   • Aucun rollback : une fois cette étape effectuée, vous ne pouvez pas revenir à la version mineure d'origine. La mise à niveau est terminée.

Les limites suivantes s'appliquent pendant cette opération :

• Vous ne pouvez pas lancer de mise à niveau mineure en une étape du plan de contrôle.
• Vous ne pouvez pas créer ni mettre à niveau les nœuds vers une version ultérieure à la version émulée.
• GKE n'effectue aucun type de mise à niveau automatique du plan de contrôle ni des nœuds.

Lancer une mise à niveau en deux étapes

Démarrez une mise à niveau en deux étapes en exécutant la commande suivante :

gcloud beta container clusters upgrade CLUSTER_NAME \
  --location=CONTROL_PLANE_LOCATION \
  --cluster-version VERSION \
  --control-plane-soak-duration SOAK_DURATION \
  --master

Remplacez les éléments suivants :

• CLUSTER_NAME : nom du cluster.
• CONTROL_PLANE_LOCATION : emplacement (région ou zone) du plan de contrôle, tel que us-central1 ou us-central1-a.
• VERSION : correctif spécifique de la prochaine version mineure. Par exemple, si votre cluster exécute la version 1.33, 1.34.1-gke.1829001.
• SOAK_DURATION : délai d'attente dans la phase de sécurité de restauration. Vous pouvez définir cette valeur sur une durée minimale de six heures et maximale de sept jours à l'aide des formats de durée absolue, comme expliqué dans la référence pour gcloud topic datetimes. Par exemple, utilisez 2d1h pour une durée d'imprégnation de deux jours et une heure.

Tester le nouveau binaire lors d'une mise à niveau en deux étapes

Pendant le temps de stabilisation, vérifiez que votre cluster (avec le plan de contrôle exécutant le nouveau binaire) et les charges de travail fonctionnent comme prévu. Vous pouvez effectuer l'une des étapes suivantes, selon que vous êtes en mesure de vérifier ou non que les charges de travail sont compatibles avec le nouveau binaire :

• Effectuer un rollback : si vous constatez un problème avec vos charges de travail exécutées sur le nouveau binaire, vous pouvez effectuer un rollback vers la version mineure précédente.
• Finalisez la mise à niveau : si vous avez vérifié que vos charges de travail s'exécutent sans problème sur le nouveau binaire, vous pouvez finaliser la mise à niveau si vous souhaitez commencer à utiliser les fonctionnalités et les API de la nouvelle version.
• Attendre : vous pouvez également attendre que le temps de trempage soit écoulé. Ensuite, GKE effectue la mise à niveau de la version émulée, où il passe à l'utilisation des fonctionnalités et des API de la nouvelle version mineure.

Observer la mise à niveau en cours

Pour obtenir des informations sur une mise à niveau en cours, utilisez l'une des ressources suivantes :

• Pour afficher des informations détaillées sur la mise à niveau, suivez les instructions pour obtenir des informations sur les mises à niveau au niveau du cluster.
• Utilisez les notifications de cluster. GKE envoie une notification UpgradeEvent lorsque la mise à niveau du binaire commence, et un UpgradeInfoEvent de type L'opération de mise à niveau est terminée lorsque la mise à niveau du binaire est terminée et que la période de stabilisation commence.
• Pour afficher des informations sur votre cluster, y compris sur la mise à niveau en cours, exécutez la commande gcloud container clusters describe.
• Consultez les journaux pertinents dans Cloud Logging.

Effectuer un rollback d'une mise à niveau en deux étapes après la mise à niveau de la version binaire

Lors d'une mise à niveau en deux étapes, la période de stabilisation suit la mise à niveau de la version binaire. Pendant cette période, vous pouvez revenir à la version mineure précédente si nécessaire. Vous ne pouvez pas effectuer de rollback une fois que GKE a effectué la mise à niveau de la version émulée.

Une fois l'opération de rollback terminée, votre plan de contrôle exécute la version mineure précédente, comme avant le lancement de la mise à niveau en deux étapes.

Si possible, procédez comme suit pour effectuer un rollback :

1. Vérifiez que vous pouvez toujours rétablir la version mineure précédente du plan de contrôle en exécutant la commande gcloud CLI décrite dans Obtenir des informations sur les mises à niveau au niveau du cluster. Déterminez si vous pouvez ou non effectuer une restauration en fonction du résultat de la commande :

   • Vous pouvez revenir à la version précédente si une section rollbackSafeUpgradeStatus figure dans le résultat. Dans cette section, enregistrez le previousVersion pour la variable VERSION à l'étape suivante. Passez à l'étape suivante.
   • Vous ne pouvez pas revenir à une version antérieure si la section rollbackSafeUpgradeStatus n'existe pas. Cela indique que GKE a déjà effectué la mise à niveau de la version émulée. Vous ne pouvez pas passer à l'étape suivante.

2. Si l'étape précédente a déterminé qu'un rollback est possible, revenez à la version précédente :

   gcloud container clusters upgrade CLUSTER_NAME \
     --location=CONTROL_PLANE_LOCATION \
     --cluster-version VERSION
     --master
   

   Le VERSION doit correspondre exactement à la version du correctif utilisée précédemment. Vous avez enregistré cette version à l'étape précédente.

Après avoir exécuté cette commande et être revenu à la version précédente, vous pouvez déterminer pourquoi votre charge de travail ne s'est pas exécutée correctement sur le nouveau binaire. Si nécessaire, vous pouvez contacter le service Cloud Customer Care en fournissant les journaux, les messages d'erreur et les informations pertinentes sur l'échec de la validation que vous avez rencontré. Pour en savoir plus, consultez Obtenir de l'aide.

Une fois le problème résolu, vous pouvez à nouveau effectuer manuellement la mise à niveau vers la nouvelle version mineure.

Effectuer la mise à niveau en deux étapes

Pendant la période de stabilisation, si vous avez vérifié que les charges de travail s'exécutent correctement avec le nouveau binaire, vous pouvez ignorer le reste de la période de stabilisation :

gcloud beta container clusters clusters complete-control-plane-upgrade CLUSTER_NAME  \
  --location=CONTROL_PLANE_LOCATION

Une fois cette commande exécutée, vous ne pourrez plus revenir à la version mineure précédente.

Revenir à une version de correctif antérieure du plan de contrôle

1. Définissez une exclusion de maintenance avant de revenir à une version antérieure pour empêcher GKE de mettre à niveau automatiquement le plan de contrôle après la rétrogradation.

2. Revenez à une version de correctif antérieure du plan de contrôle du cluster :

    gcloud container clusters upgrade CLUSTER_NAME \
        --master \
        --location=CONTROL_PLANE_LOCATION \
        --cluster-version=VERSION
   

Désactiver les mises à niveau automatiques du cluster

La sécurité de l'infrastructure est une priorité élevée pour GKE. Ces plans de contrôle sont mis à niveau régulièrement et ne peuvent pas être désactivés. Toutefois, vous pouvez appliquer des intervalles et des exclusions de maintenance afin de suspendre temporairement les mises à niveau pour les plans de contrôle et les nœuds.

Bien que cette pratique ne soit pas recommandée, vous pouvez désactiver la mise à niveau automatique des nœuds pour les pools de nœuds standards.

Vérifier l'historique récent des mises à niveau du plan de contrôle

Pour obtenir un aperçu de l'historique récent des mises à niveau automatiques d'un cluster, consultez les informations sur les mises à niveau d'un cluster.

Vous pouvez également lister les opérations récentes pour voir quand le plan de contrôle a été mis à niveau :

gcloud container operations list --filter="TYPE:UPGRADE_MASTER AND TARGET:CLUSTER_NAME" \
    --location=CONTROL_PLANE_LOCATION

Mettre à niveau les pools de nœuds

Par défaut, la mise à niveau automatique est activée pour les pools de nœuds Standard, et elle l'est toujours pour tous les pools de nœuds gérés par Autopilot dans les clusters Standard. Les mises à niveau automatiques des nœuds garantissent que le plan de contrôle et la version des nœuds de votre cluster restent synchronisés et conformes aux règles d'asymétrie de version Kubernetes, ce qui garantit que les plans de contrôle sont compatibles avec les nœuds jusqu'à deux versions mineures antérieures au plan de contrôle. Par exemple, les plans de contrôle Kubernetes 1.34 sont compatibles avec les nœuds Kubernetes 1.32.

Avec les mises à niveau de pool de nœuds GKE Standard, vous pouvez choisir entre trois stratégies de mise à niveau configurables, y compris les mises à niveau de la surutilisation, les mises à niveau bleu-vert et les mises à niveau bleu-vert avec autoscaling (aperçu). Les pools de nœuds gérés par Autopilot dans les clusters standards utilisent toujours les mises à niveau de la surutilisation.

Pour les pools de nœuds standards, choisissez une stratégie et utilisez les paramètres pour ajuster la stratégie afin de répondre au mieux aux besoins de votre environnement de cluster.

Fonctionnement des mises à niveau de nœuds

Lorsqu'un nœud est mis à jour, GKE interrompt la programmation de nouveaux pods et tente de programmer les pods en cours d'exécution sur d'autres nœuds. Cette opération est semblable à d'autres événements permettant de recréer le nœud, tels que l'activation ou la désactivation d'une fonctionnalité dans le pool de nœuds.

Pendant les mises à jour automatiques ou manuelles des nœuds, les PodDisruptionBudgets (PDB) et le délai de grâce pour l'arrêt des pods sont respectés pendant une heure au maximum. Si les pods exécutés sur le nœud ne peuvent pas être programmés sur de nouveaux nœuds au bout d'une heure, GKE lance quand même la mise à niveau. Ce comportement s'applique même si vous configurez vos PDB pour que toutes vos instances répliquées soient toujours disponibles en définissant le champ maxUnavailable sur 0 ou 0%, ou en définissant le champ minAvailable sur 100% ou sur le nombre d'instances répliquées. Dans tous ces scénarios, GKE supprime les pods au bout d'une heure afin que le nœud puisse être supprimé.

La mise à niveau n'est terminée que lorsque tous les nœuds ont été recréés et que le cluster est dans le nouvel état. Lorsqu'un nœud qui vient d'être mis à niveau s'enregistre auprès du plan de contrôle, GKE le marque comme programmable.

Les nouvelles instances de nœud exécutent la nouvelle version de Kubernetes, ainsi que les composants suivants :

• L'Image du nœud
• kubelet
• kube-proxy

Pour qu'une mise à niveau d'un pool de nœuds soit considérée comme terminée, tous les nœuds du pool doivent être recréés. Si une mise à niveau a commencé, mais ne s'est pas terminée et est dans un état partiellement mis à niveau, il est possible que la version du pool de nœuds ne reflète pas la version de tous les nœuds. Pour en savoir plus, consultez Certaines versions de nœuds ne correspondent pas à la version du pool de nœuds après une mise à niveau incomplète du pool de nœuds. Pour déterminer si la mise à niveau du pool de nœuds est terminée, vérifiez son état. Si l'opération de mise à niveau dépasse la période de conservation, vérifiez que la version de chaque nœud correspond à la version du pool de nœuds.

Sauvegarder vos données sur des disques persistants avant la mise à niveau

Avant de mettre à niveau un pool de nœuds, vous devez vous assurer que toutes les données que vous souhaitez conserver sont stockées dans un pod à l'aide de volumes persistants, qui utilisent des disques persistants. Les disques persistants sont désinstallés au lieu d'être effacés lors des mises à jour, ce qui permet leur transmission d'un pod à un autre.

Les disques persistants sont soumis aux restrictions suivantes :

• Les nœuds sur lesquels les pods sont exécutés doivent être des VM Compute Engine.
• Ces VM doivent appartenir au même projet et à la même zone Compute Engine que le disque persistant.

Pour savoir comment ajouter un disque persistant à une instance de nœud existante, consultez la page Ajouter ou redimensionner des disques persistants zonaux dans la documentation Compute Engine.

Mettre à niveau manuellement un pool de nœuds

Vous pouvez mettre à niveau manuellement la version d'un pool de nœuds standard ou d'un pool de nœuds géré par Autopilot dans un cluster Standard. Vous pouvez utiliser la même version que celle du plan de contrôle ou une version antérieure qui est toujours disponible et compatible avec le plan de contrôle. Vous pouvez mettre à niveau manuellement plusieurs pools de nœuds en parallèle, tandis que GKE ne met à niveau automatiquement qu'un seul pool de nœuds à la fois.

Lorsque vous mettez à niveau manuellement un pool de nœuds, GKE supprime les libellés que vous avez ajoutés à des nœuds individuels à l'aide de kubectl. Pour éviter cela, essayez plutôt d'appliquer des libellés aux pools de nœuds.

Avant de mettre à niveau manuellement votre pool de nœuds, tenez compte des conditions suivantes :

• La mise à niveau d'un pool de nœuds peut perturber les charges de travail s'exécutant dans celui-ci. Pour éviter cela, vous pouvez créer un pool de nœuds de la version requise, puis migrer la charge de travail vers celui-ci. Une fois la migration terminée, vous pouvez supprimer l'ancien pool de nœuds.
• Si vous mettez à niveau un pool de nœuds avec un Ingress dans un état erroné, le groupe d'instances ne se synchronise pas. Afin d'éviter ce problème, commencez par vérifier l'état à l'aide de la commande kubectl get ing. Si le groupe d'instances n'est pas synchronisé, vous pouvez réappliquer le fichier manifeste utilisé pour créer l'entrée.

Vous pouvez mettre à niveau manuellement vos pools de nœuds vers une version compatible avec le plan de contrôle :

• Pour les pools de nœuds standards, vous pouvez utiliser la console Cloud de Confiance ou la Google Cloud CLI.

• Pour les pools de nœuds gérés par Autopilot, vous ne pouvez utiliser que la Google Cloud CLI.

gcloud container clusters upgrade CLUSTER_NAME \
  --node-pool=NODE_POOL_NAME \
  --location=CONTROL_PLANE_LOCATION

gcloud container clusters upgrade CLUSTER_NAME \
  --node-pool=NODE_POOL_NAME \
  --location=CONTROL_PLANE_LOCATION \
  --cluster-version VERSION

Revenir à une version antérieure des pools de nœuds

Vous pouvez revenir à une version antérieure d'un pool de nœuds, par exemple pour récupérer de l'échec d'une mise à niveau du pool de nœuds. Consultez les limites avant de revenir à une version antérieure d'un pool de nœuds.

1. Définissez une exclusion de maintenance pour le cluster afin d'empêcher la mise à niveau automatique du pool de nœuds par GKE après son retour à une version antérieure.
2. Pour revenir à une version antérieure d'un pool de nœuds, spécifiez une version antérieure en suivant les instructions de la section Mettre à jour manuellement un pool de nœuds.

Modifier les paramètres de mise à niveau de la surutilisation

Pour en savoir plus sur la modification des paramètres de mise à niveau de la surutilisation, consultez Configurer les mises à niveau de la surutilisation.

Vérifier l'état de la mise à niveau du pool de nœuds

Vous pouvez vérifier l'état d'une mise à niveau à l'aide de gcloud container operations.

Affichez la liste de toutes les opérations en cours ou terminées dans le cluster au cours des 12 derniers jours (si le nombre d'opérations est inférieur à 5 000) ou des 5 000 dernières opérations :

gcloud container operations list \
    --location=CONTROL_PLANE_LOCATION

Chaque opération se voit attribuer un ID d'opération et un type d'opération, ainsi que des heures de début et de fin, un cluster cible et un état. Cette liste se présente comme dans l'exemple suivant :

NAME                              TYPE                ZONE           TARGET              STATUS_MESSAGE  STATUS  START_TIME                      END_TIME
operation-1505407677851-8039e369  CREATE_CLUSTER      us-west1-a     my-cluster                          DONE    20xx-xx-xxT16:47:57.851933021Z  20xx-xx-xxT16:50:52.898305883Z
operation-1505500805136-e7c64af4  UPGRADE_CLUSTER     us-west1-a     my-cluster                          DONE    20xx-xx-xxT18:40:05.136739989Z  20xx-xx-xxT18:41:09.321483832Z
operation-1505500913918-5802c989  DELETE_CLUSTER      us-west1-a     my-cluster                          DONE    20xx-xx-xxT18:41:53.918825764Z  20xx-xx-xxT18:43:48.639506814Z

Pour obtenir plus d'informations sur une opération déterminée, spécifiez l'ID de cette opération, comme indiqué dans la commande suivante :

gcloud container operations describe OPERATION_ID \
    --location=CONTROL_PLANE_LOCATION

Exemple :

gcloud container operations describe operation-1507325726639-981f0ed6
endTime: '20xx-xx-xxT21:40:05.324124385Z'
name: operation-1507325726639-981f0ed6
operationType: UPGRADE_CLUSTER
selfLink: https://container.googleapis.com/v1/projects/.../kubernetes-engine/docs/zones/us-central1-a/operations/operation-1507325726639-981f0ed6
startTime: '20xx-xx-xxT21:35:26.639453776Z'
status: DONE
targetLink: https://container.googleapis.com/v1/projects/.../kubernetes-engine/docs/zones/us-central1-a/clusters/...
zone: us-central1-a

Si la mise à niveau a été annulée ou a échoué et qu'elle est partiellement terminée, vous pouvez la reprendre ou effectuer un rollback.

Vérifier les paramètres de mise à niveau du pool de nœuds

Vous pouvez afficher les détails de la stratégie de mise à niveau du pool de nœuds utilisée pour vos pools de nœuds à l'aide de la commande gcloud container node-pools describe. Pour les mises à niveau bleu-vert, la commande renvoie également la phase actuelle de la mise à niveau.

Exécutez la commande ci-dessous.

gcloud container node-pools describe NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

Remplacez les éléments suivants :

• NODE_POOL_NAME : nom du pool de nœuds à décrire.
• CLUSTER_NAME : nom du cluster du pool de nœuds à décrire.
• CONTROL_PLANE_LOCATION : emplacement (région ou zone) du plan de contrôle, tel que us-central1 ou us-central1-a.

Cette commande génère les paramètres de mise à niveau actuels. L'exemple suivant montre le résultat si vous utilisez la stratégie de mise à niveau bleu-vert.

upgradeSettings:
  blueGreenSettings:
    nodePoolSoakDuration: 1800s
    standardRolloutPolicy:
      batchNodeCount: 1
      batchSoakDuration: 10s
  strategy: BLUE_GREEN

Si vous utilisez la stratégie de mise à niveau bleu-vert, le résultat inclut également des détails sur les paramètres de mise à niveau bleu-vert et sa phase intermédiaire actuelle. L'exemple suivant montre comment cela se présente :

updateInfo:
  blueGreenInfo:
    blueInstanceGroupUrls:
    - https://www.googleapis.com/compute/v1/projects/{PROJECT_ID}/zones/{LOCATION}/instanceGroupManagers/{BLUE_INSTANCE_GROUP_NAME}
    bluePoolDeletionStartTime: {BLUE_POOL_DELETION_TIME}
    greenInstanceGroupUrls:
    - https://www.googleapis.com/compute/v1/projects/{PROJECT_ID}/zones/{LOCATION}/instanceGroupManagers/{GREEN_INSTANCE_GROUP_NAME} 
    greenPoolVersion: {GREEN_POOL_VERSION}
    phase: DRAINING_BLUE_POOL

Annuler la mise à niveau d'un pool de nœuds

Vous pouvez annuler une mise à jour à tout moment. Pour en savoir plus sur ce qui se passe lorsque vous annulez une mise à niveau de la surutilisation, consultez la page Annuler une mise à niveau de la surutilisation. Pour en savoir plus sur ce qui se passe lorsque vous annulez une mise à niveau bleu-vert, consultez la page Annuler une mise à niveau bleu-vert.

1. Obtenez l'ID d'opération de la mise à niveau :

   gcloud container operations list \
         --location=CONTROL_PLANE_LOCATION
   

2. Annulez la mise à niveau :

   gcloud container operations cancel OPERATION_ID \
         --location=CONTROL_PLANE_LOCATION
   

Consultez la documentation sur gcloud container operations cancel.

Reprendre la mise à niveau d'un pool de nœuds

Vous pouvez reprendre une mise à niveau en lançant manuellement la mise à niveau, en spécifiant la version cible de la mise à niveau d'origine.

Par exemple, si une mise à niveau a échoué ou si vous avez suspendu une mise à niveau en cours, vous pouvez la reprendre en relançant la même mise à niveau sur le pool de nœuds, en spécifiant la version cible de l'opération de mise à niveau initiale.

Pour en savoir plus sur ce qui se passe lorsque vous réactivez une mise à niveau, consultez les pages Reprendre une mise à niveau de la surutilisation et Mise à niveau bleu-vert.

Pour reprendre une mise à niveau, utilisez la commande suivante :

gcloud container clusters upgrade CLUSTER_NAME \
  --node-pool=NODE_POOL_NAME \
  --location=CONTROL_PLANE_LOCATION \
  --cluster-version VERSION

Remplacez les éléments suivants :

• NODE_POOL_NAME : nom du pool de nœuds pour lequel vous souhaitez reprendre la mise à niveau du pool de nœuds.
• CLUSTER_NAME : nom du cluster du pool de nœuds pour lequel vous souhaitez reprendre la mise à niveau.
• CONTROL_PLANE_LOCATION : emplacement (région ou zone) du plan de contrôle, tel que us-central1 ou us-central1-a.
• VERSION : version cible de la mise à niveau du pool de nœuds annulé.

Pour en savoir plus, consultez la documentation sur gcloud container clusters upgrade.

Effectuer un rollback pour mettre à niveau un pool de nœuds

Vous pouvez effectuer un rollback d'un pool de nœuds pour revenir à l'état d'origine des nœuds mis à niveau avant le début de la mise à niveau du pool de nœuds.

Utilisez la commande rollback si une mise à niveau en cours a été annulée, si la mise à niveau a échoué ou si la mise à niveau est incomplète en raison d'un intervalle de maintenance dont le délai a expiré. Si vous souhaitez spécifier la version, suivez les instructions pour revenir à une version antérieure du pool de nœuds.

Pour en savoir plus sur ce qui se passe lorsque vous effectuez un rollback de la mise à niveau d'un pool de nœuds, consultez la page Restaurer une mise à niveau de la surutilisation ou Effectuer un rollback vers une mise à niveau bleu-vert.

Pour effectuer le rollback d'une mise à jour, exécutez la commande suivante :

gcloud container node-pools rollback NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

Remplacez les éléments suivants :

• NODE_POOL_NAME : nom du pool de nœuds pour lequel vous souhaitez effectuer un rollback de la mise à niveau du pool de nœuds.
• CLUSTER_NAME : nom du cluster du pool de nœuds pour lequel vous souhaitez effectuer un rollback de la mise à niveau.
• CONTROL_PLANE_LOCATION : emplacement (région ou zone) du plan de contrôle, tel que us-central1 ou us-central1-a.

Consultez la documentation sur gcloud container node-pools rollback.

Effectuer la mise à niveau d'un pool de nœuds

Si vous utilisez la stratégie de mise à niveau bleu-vert, vous pouvez effectuer une mise à niveau du pool de nœuds pendant la phase de stabilisation, en ignorant le reste du temps de stabilisation.

Pour savoir comment effectuer une mise à niveau du pool de nœuds, consultez la page Effectuer une mise à niveau du pool de nœuds.

Pour effectuer une mise à niveau lors de l'utilisation de la stratégie de mise à niveau bleu-vert, exécutez la commande suivante :

gcloud container node-pools complete-upgrade NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

Remplacez les éléments suivants :

• NODE_POOL_NAME : nom du pool de nœuds pour lequel vous souhaitez effectuer la mise à niveau.
• CLUSTER_NAME : nom du cluster du pool de nœuds pour lequel vous souhaitez effectuer la mise à niveau.
• CONTROL_PLANE_LOCATION : emplacement (région ou zone) du plan de contrôle, tel que us-central1 ou us-central1-a.

Consultez la documentation sur gcloud container node-pools complete-upgrade.

Problèmes connus

Si des objets PodDisruptionBudget sont configurés pour ne pas autoriser d'autres interruptions, les mises à niveau de nœuds peuvent échouer à passer à la version du plan de contrôle après plusieurs tentatives. Pour éviter cet échec, nous vous recommandons d'effectuer un scaling à la hausse de Deployment ou HorizontalPodAutoscaler afin de permettre au nœud de se drainer tout en respectant la configuration PodDisruptionBudget.

Pour afficher tous les objets PodDisruptionBudget qui n'autorisent aucune interruption, procédez comme suit :

kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'

Bien que les mises à niveau automatiques puissent rencontrer ce problème, le processus de mise à niveau automatique oblige les nœuds à se mettre à niveau. Cependant, la mise à niveau prend une heure supplémentaire pour chaque nœud de l'espace de noms istio-system qui ne respecte pas le PodDisruptionBudget.

Dépannage

Pour en savoir plus sur le dépannage, consultez Résoudre les problèmes de mise à niveau de cluster.

Étapes suivantes

• En savoir plus sur les stratégies de mise à niveau des nœuds
• En savoir plus sur les mises à niveau des clusters
• En savoir plus sur les mises à niveau automatiques des nœuds
• En savoir plus sur les intervalles et les exclusions de maintenance