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

Autopilot Standard

---

Par défaut, les mises à niveau automatiques sont activées pour les clusters Google Kubernetes Engine (GKE) et pour les pools de nœuds GKE Standard.

Cette page 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 GKE. Vous pouvez mettre à jour la version manuellement comme suit :

• Autopilot : mettez à niveau la version du plan de contrôle.
• Standard : 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 du plan de contrôle et des nœuds. Les clusters sont mis à niveau vers une version mineure plus récente (par exemple, 1.24 à 1.25) ou une version du correctif plus récente (par exemple, 1.24.2-gke.100 vers 1.24.5-gke.200). Pour en savoir plus, consultez la page Gestion des versions et compatibilité GKE.

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

Remarque terminologique : Le plan de contrôle et les nœuds d'un cluster n'exécutent pas nécessairement la même version à tout moment. Dans cet article, les termes mise à niveau du cluster et mise à niveau du plan de contrôle sont interchangeables et se distinguent des mises à niveau de nœuds.

De nouvelles versions de GKE sont régulièrement publiées et vous pouvez recevoir des notifications sur les nouvelles versions vers lesquelles un cluster spécifique peut être mis à niveau grâce aux notifications de 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 la page 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 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.
  Remarque : Pour les installations de gcloud CLI existantes, veillez à définir les propriétés compute/region et compute/zone. En définissant des emplacements par défaut, vous pouvez éviter les erreurs gcloud CLI telles que celle-ci : One of [--zone, --region] must be supplied: Please specify location.

Sauvegarder vos données sur des disques persistants

Avant de mettre à jour un pool de nœuds, vous devez vous assurer que toutes les données que vous souhaitez conserver sont stockées dans un pod utilisant des volumes persistants, qui eux-mêmes 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 machines virtuelles Compute Engine.
• Ces machines virtuelles 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.

À propos des mises à niveau

Le plan de contrôle et les nœuds d'un cluster sont mis à jour séparément.

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

Pour recevoir les notifications de mise à niveau de manière proactive, consultez la page Recevoir des notifications de cluster.

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

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.21.12-gke.1700 du canal standard à la version 1.21.13-gke.900 du canal rapide dans votre cluster. Pour plus d'informations, consultez la section Exécuter des versions de correctif à partir d'un canal plus récent. Tous les clusters Autopilot sont enregistrés dans une version disponible.

Limites applicables au retour à une version antérieure

Dans certains scénarios, vous pouvez revenir à une version antérieure du cluster.

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.25.3-gke.400, vous pouvez revenir au plan de contrôle 1.25.2-gke.100 si cette version est toujours disponible.

Vous ne pouvez pas revenir à une version mineure antérieure d'un plan de contrôle de cluster Kubernetes. Par exemple, si votre plan de contrôle exécute la version 1.25 de GKE, vous ne pouvez pas revenir à la version 1.24. 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.24.3-gke.100": specified version is not
newer than the current version.

Vous ne pouvez pas revenir à une version antérieure du plan de contrôle d'un cluster. Nous vous recommandons donc 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 par défaut. Cela est particulièrement recommandé si votre cluster peut être affecté par des modifications importantes dans la prochaine version mineure, telles que la suppression d'API ou fonctionnalités obsolètes.

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. Assurez-vous de ne pas rétrograder les nœuds vers une version qui diffère de plus de deux versions mineures par rapport à la version du plan de contrôle du cluster.

Mise à niveau du cluster

Google met automatiquement à jour les clusters et les nœuds. Si vous souhaitez avoir davantage de contrôle sur les mises à niveau automatiques que votre cluster et ses nœuds reçoivent, vous pouvez enregistrer ce cluster dans une version disponible. Tous les clusters Autopilot sont enregistrés automatiquement dans une version disponible.

Pour en savoir plus sur la gestion de la version GKE de votre cluster, consultez la page Mises à niveau.

Vous pouvez lancer une mise à jour manuelle à tout moment lorsqu'une nouvelle version est disponible.

Mettre à jour manuellement le plan de contrôle

Remarque : Vous ne pouvez mettre à jour votre cluster que d'une version mineure à la fois. Par exemple, vous pouvez passer d'une version 1.25 à une version 1.26, mais pas directement d'une version 1.25 à une version 1.27. Pour en savoir plus, consultez la section Puis-je sauter des versions lors de la mise à niveau d'un cluster ?.

Lors du lancement de la mise à jour d'un cluster, vous ne pouvez pas modifier la configuration du cluster pendant plusieurs minutes, jusqu'à ce que le plan de contrôle soit à nouveau accessible. Si vous devez éviter les temps d'arrêt pendant les mises à niveau du plan de contrôle, envisagez d'utiliser un cluster Autopilot ou un cluster Standard régional. Cette opération n'affecte pas la disponibilité des nœuds de calcul sur lesquels vos charges de travail s'exécutent, car ils restent disponibles lors des mises à niveau du plan de contrôle.

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

gcloud

Pour afficher les versions disponibles du plan de contrôle de votre cluster, exécutez la commande suivante :

gcloud container get-server-config

Pour passer à la version de cluster par défaut, exécutez la commande suivante :

gcloud container clusters upgrade CLUSTER_NAME --master

Pour effectuer une mise à niveau vers une version spécifique autre que celle par défaut, spécifiez l'option --cluster-version comme dans la commande suivante :

gcloud container clusters upgrade CLUSTER_NAME --master \
    --cluster-version VERSION

Remplacez VERSION par la version vers laquelle vous souhaitez mettre à niveau votre cluster. Vous pouvez utiliser une version spécifique, telle que 1.18.17-gke.100, ou un alias de version, tel que latest. Pour en savoir plus, consultez la section Spécifier la version du cluster.

Remarque : Si votre cluster est enregistré dans une version disponible, VERSION doit être une version mineure valide pour la version disponible ou une version de correctif valide dans la version disponible la plus récente. Tous les clusters Autopilot sont enregistrés dans une version disponible.

Console

Pour mettre à niveau manuellement le plan de contrôle du cluster, procédez comme suit :

1. Accédez à la page Google Kubernetes Engine dans la console Google Cloud.

   Accéder à Google Kubernetes Engine

2. Cliquez sur le nom de cluster souhaité.

3. Sous Paramètres de base du cluster, cliquez sur Mise à niveau disponible à côté de Version.

4. Sélectionnez la version souhaitée, puis cliquez sur Enregistrer les modifications.

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 créés à l'aide de la console Google Cloud. Vous n'avez donc pas besoin de le faire manuellement. Autopilot met toujours à niveau les nœuds automatiquement.

Revenir à une version antérieure des clusters

Remarque : Assurez-vous de bien comprendre les limites avant d'essayer de revenir à une version antérieure du cluster.

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 son retour à une version antérieure.

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

    gcloud container clusters upgrade CLUSTER_NAME \
        --master --cluster-version VERSION
   

Remarque : Si votre cluster est abonné à une version disponible, le VERSION doit être une version de correctif disponible pour le canal de distribution. Tous les clusters Autopilot sont enregistrés dans un canal de distribution.

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.

Mettre à niveau les pools de nœuds

Par défaut, la mise à niveau automatique est activée sur les nœuds d'un cluster. Nous vous recommandons de ne pas la désactiver. 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.29 sont compatibles avec les nœuds Kubernetes 1.27.

Avec les mises à niveau du pool de nœuds GKE, vous pouvez choisir entre deux stratégies de mise à niveau configurables, à savoir les mises à niveau de la surutilisation et les mises à niveau bleu-vert.

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.

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.

Remarque : 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 un nœud ne peuvent pas être programmés sur de nouveaux nœuds dans un délai d'une heure, la mise à niveau est lancée, quoi qu'il en soit. Si une charge de travail nécessite plus de flexibilité avec une résiliation concertée, nous vous recommandons d'utiliser des mises à niveau bleu-vert, qui fournissent des paramètres de délai d'attente supplémentaire pour étendre les vérifications PDB au-delà de la valeur par défaut de 1 heure. Pour savoir à quoi vous attendre lors de l'arrêt de nœuds en général, consultez la page sur les pods.

La mise à jour n'est terminée que lorsque tous les nœuds ont été recréés et que le cluster est dans l'état souhaité. 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 version souhaitée de Kubernetes, ainsi que les composants suivants :

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

Mettre à niveau manuellement un pool de nœuds

Vous pouvez mettre à niveau manuellement une version du pool de nœuds vers celle du plan de contrôle ou vers 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.

Remarque : La mise à jour 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 souhaitée, puis migrer la charge de travail vers celui-ci. Une fois la migration terminée, vous pouvez supprimer l'ancien pool de nœuds.

Remarque : Si vous mettez à niveau un pool de nœuds avec un objet 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 à jour manuellement vos pools de nœuds vers une version compatible avec le plan de contrôle à l'aide de la console Google Cloud ou de la Google Cloud CLI.

gcloud

Les variables suivantes sont utilisées dans les commandes de cette section :

• CLUSTER_NAME : nom du cluster du pool de nœuds à mettre à jour.
• NODE_POOL_NAME : nom du pool de nœuds à mettre à jour.
• VERSION : version de Kubernetes vers laquelle les nœuds sont mis à niveau. Par exemple, --cluster-version=1.7.2 ou cluster-version=latest.

Mettre à niveau un pool de nœuds :

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

Pour spécifier une autre version de GKE sur les nœuds, utilisez l'indicateur --cluster-version facultatif :

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

Pour en savoir plus sur la spécification des versions, consultez la page Gestion des versions.

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

Console

Pour mettre à niveau un pool de nœuds à l'aide de la console Google Cloud, procédez comme suit :

1. Accédez à la page Google Kubernetes Engine dans la console Google Cloud.

   Accéder à Google Kubernetes Engine

2. À côté du cluster que vous souhaitez modifier, cliquez sur Actions, puis sur Modifier.

3. Sur la page Détails du cluster, cliquez sur l'onglet Nœuds.

4. Dans la section Pools de nœuds, cliquez sur le nom du pool de nœuds que vous souhaitez mettre à niveau.

5. Cliquez sur Modifier.

6. Cliquez sur Modifier sous Version du nœud.

7. Sélectionnez la version souhaitée dans la liste déroulante Version du nœud, puis cliquez sur Modifier.

Remarque : Le changement de version du nœud peut prendre plusieurs minutes.

Rétablir une version antérieure d'un pool 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.

Remarque : Nous vous recommandons la stratégie de mise à niveau des nœuds bleu-vert si vous devez optimiser les mesures de réduction des risques pour les mises à niveau du pool de nœuds affectant vos charges de travail. Avec cette stratégie, vous pouvez effectuer le rollback d'une mise à niveau en cours vers les nœuds d'origine si la mise à niveau échoue.

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 la page 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 :

gcloud container operations list

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

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

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 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

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.

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 une mise à niveau du 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
   

2. Annulez la mise à niveau :

   gcloud container operations cancel OPERATION_ID
   

Consultez la documentation sur gcloud container operations cancel.

Reprendre une 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 vous avez suspendu une mise à niveau en cours vers la version 1.23.1-gke.100, vous pouvez la reprendre en relançant la même mise à niveau sur le pool de nœuds, en ciblant la version 1.23.1-gke.100.

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 \
      --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.
• 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 rétablir la version du 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.

Remarque : En revanche, le rollback n'est plus possible pour les pools de nœuds dont la mise à jour a abouti. Vous devez rétrograder le pool de nœuds si vous souhaitez que les nœuds soient dans la version précédente.

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

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.

Consultez la documentation sur gcloud container node-pools rollback.

Terminer une mise à niveau du pool de nœuds

Avertissement : L'utilisation de la commande complete-upgrade n'est possible qu'avec les mises à niveau bleu-vert.

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

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.

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

L'utilisation du processeur par les nœuds est plus élevée que prévu

Vous pouvez rencontrer un problème lorsque certains nœuds utilisent plus de processeur que prévu par les pods en cours d'exécution.

Cela peut se produire si votre cluster ou vos nœuds n'exécutent pas de version compatible. Consultez les notes de version pour vous assurer que les versions que vous utilisez sont disponibles et compatibles. Vous pouvez également exécuter la commande suivante pour répertorier toutes les versions de cluster et de nœud compatibles :

gcloud container get-server-config

Étape suivante

• Apprenez-en plus sur l'architecture d'un cluster.
• Apprenez-en plus sur les versions disponibles.