Résoudre les problèmes de mise à niveau des clusters

Si la mise à niveau de votre plan de contrôle ou de votre pool de nœuds Google Kubernetes Engine (GKE) échoue, se bloque ou entraîne un comportement inattendu de la charge de travail, vous devrez peut-être résoudre le problème. Il est essentiel de maintenir à jour votre plan de contrôle et vos pools de nœuds pour la sécurité et les performances. La résolution des problèmes permet de garantir la stabilité de votre environnement.

Pour résoudre les problèmes de mise à niveau courants, la première étape consiste à surveiller le processus de mise à niveau du cluster. Vous trouverez ensuite des conseils pour résoudre votre problème :

Ces informations sont importantes pour les administrateurs et opérateurs de plate-forme qui souhaitent diagnostiquer les causes profondes des mises à niveau bloquées ou ayant échoué, gérer les règles de maintenance et résoudre les problèmes d'incompatibilité de version. Les développeurs d'applications peuvent trouver des conseils pour résoudre les problèmes de charge de travail après la mise à niveau et comprendre comment les configurations de charge de travail, telles que PodDisruptionBudgets, peuvent affecter la durée de la mise à niveau. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez Rôles utilisateur et tâches courantes de GKE.

Surveiller le processus de mise à niveau du cluster

Pour résoudre plus efficacement les problèmes de mise à niveau, commencez par comprendre ce qui s'est passé pendant le processus de mise à niveau. GKE fournit plusieurs outils qui vous permettent de suivre ce processus.

Dans la console Google Cloud , le tableau de bord des mises à niveau offre une vue à l'échelle du projet de toutes les mises à niveau de cluster en cours, une chronologie des événements récents et des avertissements concernant les blocages potentiels tels que les exclusions de maintenance actives ou les futures obsolescences de version. Pour les vérifications en ligne de commande ou automatisées, vous pouvez utiliser la commande gcloud container operations list pour obtenir l'état d'opérations de mise à niveau spécifiques. Pour en savoir plus, consultez Obtenir de la visibilité sur les mises à niveau des clusters.

Pour une analyse plus détaillée, Cloud Logging est votre principale source d'informations. GKE enregistre des informations détaillées sur les processus de mise à niveau du plan de contrôle et du pool de nœuds dans Cloud Logging. Cela inclut les journaux d'audit de haut niveau qui suivent les principales opérations de mise à niveau, ainsi que les journaux plus précis tels que les événements Kubernetes et les journaux des composants de nœud, qui peuvent vous fournir plus d'informations sur des erreurs spécifiques.

Les sections suivantes expliquent comment interroger ces journaux à l'aide de l'explorateur de journaux ou de la gcloud CLI. Pour en savoir plus, consultez Vérifier les journaux de mise à niveau.

Identifier l'opération de mise à niveau à l'aide des journaux d'audit

Si vous ne savez pas quelle opération de mise à niveau a échoué, vous pouvez utiliser les journaux d'audit GKE. Les journaux d'audit suivent les actions administratives et fournissent un enregistrement faisant autorité de la date à laquelle une mise à niveau a été lancée et de son état final. Utilisez les requêtes suivantes dans l'explorateur de journaux pour trouver l'opération concernée.

Type d'événement Requête de journal
Mise à niveau automatique du plan de contrôle 
resource.type="gke_cluster"
protoPayload.methodName="google.container.internal.ClusterManagerInternal.UpdateClusterInternal"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.metadata.operationType="UPGRADE_MASTER"
resource.labels.cluster_name="CLUSTER_NAME"

Remplacez CLUSTER_NAME par le nom du cluster que vous souhaitez examiner.

Cette requête affiche la version cible du plan de contrôle et la version précédente du plan de contrôle.
Mise à niveau manuelle du plan de contrôle 
resource.type="gke_cluster"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.response.operationType="UPGRADE_MASTER"
resource.labels.cluster_name="CLUSTER_NAME"

 
Mise à niveau automatique du pool de nœuds (version cible uniquement) 
resource.type="gke_nodepool"
protoPayload.methodName="google.container.internal.ClusterManagerInternal.UpdateClusterInternal"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.metadata.operationType="UPGRADE_NODES"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.nodepool_name="NODEPOOL_NAME"

Remplacez NODEPOOL_NAME par le nom du pool de nœuds appartenant au cluster.
Mise à niveau manuelle du pool de nœuds 
resource.type="gke_nodepool"
protoPayload.methodName="google.container.v1.ClusterManager.UpdateNodePool"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.response.operationType="UPGRADE_NODES"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.nodepool_name="NODEPOOL_NAME"

Pour trouver la version précédente du pool de nœuds, consultez les journaux de l'API Kubernetes :

resource.type="k8s_cluster"
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.methodName="nodes.patch"

Trouver des messages d'erreur détaillés dans les journaux GKE

Une fois que le journal d'audit vous a indiqué l'opération qui a échoué et le moment où elle s'est produite, vous pouvez rechercher des messages d'erreur plus détaillés provenant des composants GKE à peu près au même moment. Ces journaux peuvent contenir les raisons spécifiques d'un échec de mise à niveau, comme un objet PodDisruptionBudget mal configuré.

Par exemple, après avoir trouvé une opération UPGRADE_NODES ayant échoué dans les journaux d'audit, vous pouvez utiliser son code temporel pour affiner votre recherche. Dans l'explorateur de journaux, saisissez la requête suivante, puis utilisez le sélecteur de période pour vous concentrer sur le moment où l'échec s'est produit :

resource.type="k8s_node"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.node_name="NODE_NAME"
severity=ERROR

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster
  • NODE_NAME : nom du nœud du cluster pour lequel vous souhaitez rechercher des erreurs.

Utiliser la gcloud CLI pour afficher les événements de mise à niveau

En plus de l'explorateur de journaux, vous pouvez utiliser les commandes de la gcloud CLI pour examiner les événements de mise à niveau.

Pour rechercher les mises à niveau du plan de contrôle, exécutez la commande suivante :

gcloud container operations list --filter="TYPE=UPGRADE_MASTER"

Le résultat ressemble à ce qui suit :

NAME: operation-1748588803271-cfd407a2-bfe7-4b9d-8686-9f1ff33a2a96
TYPE: UPGRADE_MASTER
LOCATION: LOCATION
TARGET: CLUSTER_NAME
STATUS_MESSAGE:
STATUS: DONE
START_TIME: 2025-05-30T07:06:43.271089972Z
END_TIME: 2025-05-30T07:18:02.639579287Z

Ce résultat inclut les valeurs suivantes :

  • LOCATION : région ou zone Compute Engine (par exemple, us-central1 ou us-central1-a) du cluster.
  • CLUSTER_NAME : nom du cluster

Pour rechercher les mises à niveau de pool de nœuds, exécutez la commande suivante :

gcloud container operations list --filter="TYPE=UPGRADE_NODES"

Le résultat ressemble à ce qui suit :

NAME: operation-1748588803271-cfd407a2-bfe7-4b9d-8686-9f1ff33a2a96
TYPE: UPGRADE_NODES
LOCATION: LOCATION
TARGET: CLUSTER_NAME
STATUS_MESSAGE:
STATUS: DONE
START_TIME: 2025-05-30T07:06:43.271089972Z
END_TIME: 2025-05-30T07:18:02.639579287Z

Exemple : Utiliser les journaux pour résoudre les problèmes de mise à niveau du plan de contrôle

L'exemple suivant montre comment utiliser les journaux pour résoudre les problèmes liés à une mise à niveau du plan de contrôle qui a échoué :

  1. Dans la console Google Cloud , accédez à la page Explorateur de journaux.

    Accéder à l'explorateur de journaux

  2. Dans le volet de requête, filtrez les journaux de mise à niveau du plan de contrôle en saisissant la requête suivante :

    resource.type="gke_cluster"
protoPayload.metadata.operationType=~"(UPDATE_CLUSTER|UPGRADE_MASTER)"
resource.labels.cluster_name="CLUSTER_NAME"

    Remplacez CLUSTER_NAME par le nom du cluster que vous souhaitez examiner.

  3. Cliquez sur Exécuter la requête.

  4. Examinez la sortie du journal pour obtenir les informations suivantes :

  5. Vérifiez que la mise à niveau a commencé : recherchez les événements UPGRADE_MASTER récents qui se sont produits au moment où vous avez lancé la mise à niveau. La présence de ces événements confirme que vous ou GKE avez déclenché le processus de mise à niveau.

    • Vérifiez les versions : vérifiez les champs suivants pour confirmer les versions précédente et cible :

      • protoPayload.metadata.previousMasterVersion : affiche la version du plan de contrôle avant la mise à niveau.

      • protoPayload.metadata.currentMasterVersion : affiche la version vers laquelle GKE a tenté de mettre à niveau le plan de contrôle.

        Par exemple, si vous souhaitiez passer à la version 1.30.1-gke.1234, mais que vous avez accidentellement spécifié la version 1.30.2-gke.4321 (une version plus récente, potentiellement incompatible avec vos charges de travail), l'examen de ces deux champs mettrait en évidence cette différence. Si le champ currentMasterVersion affiche toujours l'ancienne version après une longue période, cela indique que la mise à niveau n'a pas réussi à appliquer la nouvelle version.

    • Recherchez les erreurs : vérifiez si des événements UPGRADE_MASTER se répètent ou si d'autres messages d'erreur s'affichent. Si le journal des opérations s'arrête sans indiquer la fin ou l'échec de l'opération, cela indique un problème.

Une fois que vous avez identifié une erreur ou un comportement spécifique dans les journaux, vous pouvez utiliser ces informations pour trouver la solution appropriée dans ce guide.

Résoudre les problèmes liés aux mises à niveau de pools de nœuds qui prennent plus de temps que d'habitude

Si la mise à niveau de votre pool de nœuds prend plus de temps que prévu, essayez les solutions suivantes :

  1. Vérifiez la valeur de terminationGracePeriodSeconds dans le fichier manifeste de vos pods. Cette valeur définit la durée maximale pendant laquelle Kubernetes attend qu'un pod s'arrête correctement. Une valeur élevée (par exemple, quelques minutes) peut prolonger considérablement la durée des mises à niveau, car Kubernetes attend la période complète pour chaque pod. Si ce délai pose problème, envisagez de réduire la valeur.

  2. Vérifiez vos objets PodDisruptionBudget. Lorsqu'un nœud est en cours de vidange, GKE attend au maximum une heure par nœud pour évincer correctement ses charges de travail. Si votre objet PodDisruptionBudget est trop restrictif, il peut empêcher une éviction progressive de réussir. Dans ce scénario, GKE utilise l'intégralité du délai de grâce d'une heure pour tenter de vider le nœud avant qu'il n'expire et ne force la mise à niveau à se poursuivre. Ce délai, lorsqu'il se répète sur plusieurs nœuds, est une cause fréquente de lenteur de la mise à niveau globale du cluster. Pour vérifier si un objet PodDisruptionBudget restrictif est à l'origine de la lenteur de vos mises à niveau, utilisez l'explorateur de journaux :

    1. Dans la console Google Cloud , accédez à la page Explorateur de journaux.

      Accéder à l'explorateur de journaux

    2. Dans le volet Requête, saisissez la requête suivante :

      resource.type=("gke_cluster" OR "k8s_cluster")
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.response.message="Cannot evict pod as it would violate the pod's disruption budget."
log_id("cloudaudit.googleapis.com/activity")

    3. Cliquez sur Exécuter la requête.

    4. Examinez la sortie du journal. Si l'objet PodDisruptionBudget est à l'origine de votre problème, le résultat ressemble à ce qui suit :

      resourceName: "core/v1/namespaces/istio-system/pods/POD_NAME/eviction"

response: {
  @type: "core.k8s.io/v1.Status"
  apiVersion: "v1"
  code: 429
  details: {
  causes: [
    0: {
    message: "The disruption budget istio-egressgateway needs 1 healthy pods and has 1 currently"
    reason: "DisruptionBudget"
    }
  ]
  }
  kind: "Status"
  message: "Cannot evict pod as it would violate the pod's disruption budget."
  metadata: {
  }
  reason: "TooManyRequests"
  status: "Failure"
}

    5. Après avoir confirmé qu'un objet PodDisruptionBudget est à l'origine du problème, listez tous les objets PodDisruptionBudget et assurez-vous que les paramètres sont appropriés :

      kubectl get pdb --all-namespaces

      Le résultat ressemble à ce qui suit :

      NAMESPACE        NAME          MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
example-app-one  one_pdb       3               0                 1                     12d

      Dans cet exemple, le PodDisruptionBudget nommé one_pdb nécessite au moins trois pods disponibles. Étant donné que l'éviction d'un pod pendant la mise à niveau ne laisserait que deux pods disponibles, l'action enfreint le budget et bloque la mise à niveau.

      Si votre objet PodDisruptionBudget fonctionne comme vous le souhaitez, aucune action n'est requise de votre part. Si ce n'est pas le cas, envisagez de relâcher les paramètres PodDisruptionBudget pendant la période de mise à niveau.

  3. Vérifiez vos affinités de nœud. Les règles restrictives peuvent ralentir les mises à niveau en empêchant la reprogrammation des pods sur les nœuds disponibles si ces nœuds ne correspondent pas aux libellés requis. Ce problème est particulièrement problématique lors des mises à niveau par pics, car les affinités de nœuds peuvent limiter le nombre de nœuds pouvant être mis à niveau simultanément si les nœuds portant les libellés appropriés ne disposent pas d'une capacité de cluster suffisante pour héberger les nouveaux pods.

  4. Vérifiez si vous utilisez la stratégie de mise à niveau à durée limitée. GKE utilise la stratégie de mise à niveau de courte durée pour les nœuds à démarrage flexible et pour les nœuds qui utilisent uniquement le provisionnement en file d'attente sur les clusters exécutant la version 1.32.2-gke.1652000 de GKE ou une version ultérieure. Si vous utilisez cette stratégie de mise à niveau, l'opération peut prendre jusqu'à sept jours.

  5. Vérifiez si vous utilisez des pods à durée prolongée (disponibles pour les clusters Autopilot). Lors d'une mise à niveau, GKE doit vider tous les pods d'un nœud avant que le processus puisse se terminer. Toutefois, lors d'une mise à niveau lancée par GKE, GKE n'évince pas les pods à durée prolongée pendant sept jours maximum. Cette protection empêche le nœud de se vider. GKE arrête de force le pod uniquement après la fin de cette période. Ce délai important de plusieurs jours pour un seul nœud peut retarder la mise à niveau d'autres nœuds dans le cluster Autopilot.

  6. Les volumes persistants associés peuvent entraîner un allongement de la procédure de mise à niveau, en raison du temps nécessaire à la gestion du cycle de vie de ces volumes.

  7. Vérifiez l'état de la mise à niveau automatique du cluster. Si la raison est SYSTEM_CONFIG, les mises à niveau automatiques sont temporairement suspendues pour des raisons techniques ou commerciales. Si cette raison s'affiche, nous vous recommandons de ne pas effectuer de mise à niveau manuelle, sauf si cela est nécessaire.

Résoudre les problèmes de mise à niveau incomplète des pools de nœuds

Il arrive que GKE ne puisse pas terminer la mise à niveau d'un pool de nœuds, ce qui laisse le pool de nœuds partiellement mis à niveau. Plusieurs raisons peuvent expliquer pourquoi la mise à niveau est incomplète :

  • La mise à niveau a été annulée manuellement.
  • La mise à niveau a échoué en raison d'un problème tel que l'échec de l'enregistrement de nouveaux nœuds, l'épuisement des adresses IP ou des quotas de ressources insuffisants.
  • GKE a suspendu la mise à niveau. Cette suspension peut se produire, par exemple, pour éviter une mise à niveau vers une version présentant des problèmes connus ou pendant certaines périodes de maintenance initiées par Google.
  • Si vous utilisez les mises à niveau automatiques, un intervalle de maintenance s'est terminé avant que la mise à niveau puisse être effectuée. Il est également possible qu'une période d'exclusion de maintenance ait commencé avant la fin de la mise à niveau. Pour en savoir plus, consultez Intervalle de maintenance empêchant la mise à jour des nœuds de se terminer.

Lorsqu'un pool de nœuds est partiellement mis à niveau, les nœuds s'exécutent sur différentes versions. Pour résoudre ce problème et vérifier que tous les nœuds du pool de nœuds s'exécutent sur la même version, reprenez la mise à niveau ou effectuez un rollback de la mise à niveau.

Toutefois, la stratégie de mise à niveau de la surutilisation et la stratégie de mise à niveau bleu-vert interagissent différemment avec les périodes de maintenance :

  • Mises à niveau de la surutilisation : l'opération de mise à niveau est suspendue si elle dépasse l'intervalle de maintenance. La mise à niveau reprend automatiquement lors du prochain intervalle de maintenance planifié.
  • Mises à niveau bleu-vert : l'opération de mise à niveau se poursuit jusqu'à son achèvement, même si elle dépasse l'intervalle de maintenance. Les mises à niveau bleu-vert offrent un contrôle précis du rythme de mise à niveau grâce à des fonctionnalités telles que les temps d'imprégnation des lots et des pools de nœuds. Le pool de nœuds supplémentaire permet de s'assurer que les charges de travail restent opérationnelles.

Résoudre les problèmes liés à la mise à niveau automatique inattendue

Il arrive parfois que les mises à niveau automatiques des clusters ne se déroulent pas comme prévu. Les sections suivantes vous aident à résoudre les problèmes suivants :

Échec de la mise à niveau des clusters lorsque la mise à niveau automatique des nœuds est activée

Si vous n'avez pas désactivé la mise à niveau automatique des nœuds, mais qu'aucune mise à niveau n'a lieu, essayez les solutions suivantes :

  1. Si vous utilisez une version disponible, vérifiez que les mises à niveau automatiques des nœuds ne sont pas bloquées. Pour les clusters enregistrés dans un canal de publication, votre maintenancePolicy est le principal moyen de contrôler les mises à niveau automatiques. Cela peut empêcher une mise à niveau de démarrer ou interrompre celle qui est déjà en cours. Une exclusion de maintenance active peut bloquer complètement une mise à niveau, et le calendrier d'un intervalle de maintenance peut entraîner une interruption. Consultez vos maintenancePolicy pour déterminer si l'un de ces paramètres est à l'origine du problème :

    gcloud container clusters describe CLUSTER_NAME \
    --project PROJECT_ID  \
    --location LOCATION

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster du pool de nœuds à décrire.
    • PROJECT_ID : ID de projet du cluster.
    • LOCATION : région ou zone Compute Engine (par exemple, us-central1 ou us-central1-a) du cluster.

    Le résultat ressemble à ce qui suit :

    …
maintenancePolicy:
  maintenanceExclusions:
  - exclusionName: critical-event-q4-2025
    startTime: '2025-12-20T00:00:00Z'
    endTime: '2026-01-05T00:00:00Z'
    scope:
      noUpgrades: true # This exclusion blocks all upgrades
  window:
    dailyMaintenanceWindow:
      startTime: 03:00 # Daily window at 03:00 UTC
…

    Dans le résultat, examinez la section maintenancePolicy pour les deux conditions suivantes :

    • Pour savoir si une mise à niveau est bloquée, recherchez un maintenanceExclusion actif avec un champ d'application NO_MINOR_OR_NODE_UPGRADES. Ce paramètre empêche généralement GKE de lancer une nouvelle mise à niveau.
    • Pour savoir si une mise à niveau a été interrompue, consultez le calendrier de votre dailyMaintenanceWindow ou maintenanceExclusions. Si une mise à niveau dépasse la période planifiée, GKE la suspend, ce qui entraîne une mise à niveau partielle. Pour en savoir plus sur les mises à niveau partielles, consultez la section Résoudre les problèmes de mises à niveau incomplètes.

    Pour résoudre ces problèmes, vous pouvez attendre la fin d'une exclusion, la supprimer ou ajuster vos périodes de maintenance pour laisser plus de temps aux mises à niveau.

  2. Si vous n'utilisez pas de canal de publication, vérifiez que la mise à niveau automatique est toujours activée pour le pool de nœuds :

    gcloud container node-pools describe NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location LOCATION

    Remplacez NODE_POOL_NAME par le nom du pool de nœuds à décrire.

    Si les mises à niveau automatiques du pool de nœuds sont activées pour ce pool de nœuds, la sortie dans le champ autoUpgrade est la suivante :

    management:
  autoUpgrade: true

    Si autoUpgrade est défini sur false ou si le champ n'est pas présent, activez les mises à niveau automatiques.

  3. Il est possible que la mise à niveau n'ait pas été déployée dans la région ou la zone où se trouve votre cluster, même si elle est mentionnée dans les notes de version. Les mises à niveau de GKE sont déployées progressivement sur plusieurs jours (généralement quatre ou plus). Une fois la mise à niveau disponible dans votre région ou zone, elle ne démarre que pendant les intervalles de maintenance approuvés. Par exemple, un déploiement peut atteindre la zone de votre cluster le premier jour du déploiement, mais le prochain intervalle de maintenance du cluster n'aura lieu que le septième jour. Dans ce scénario, GKE ne mettra pas à niveau le cluster avant le septième jour. Pour en savoir plus, consultez le calendrier des versions de GKE.

Mise à niveau automatique des clusters lorsque la mise à niveau automatique n'est pas activée

Pour vous aider à maintenir la fiabilité, la disponibilité, la sécurité et les performances de votre environnement GKE, GKE peut mettre à niveau automatiquement vos clusters, même si vous n'utilisez pas les mises à niveau automatiques.

GKE peut contourner vos intervalles de maintenance, vos exclusions ou la mise à niveau automatique désactivée des pools de nœuds pour effectuer les mises à niveau nécessaires pour plusieurs raisons critiques, par exemple :

  • Clusters dont les plans de contrôle exécutent une version de GKE qui a atteint sa date de fin de compatibilité. Pour vérifier que la date de fin de l'assistance pour votre cluster approche, consultez Calendrier estimé pour les canaux de publication.
  • Nœuds d'un cluster qui exécutent une version de GKE ayant atteint sa date de fin de compatibilité.
  • Clusters en cours d'exécution, mais sans activité pendant une période prolongée. Par exemple, GKE peut considérer qu'un cluster sans appels d'API, sans trafic réseau et sans utilisation active de sous-réseaux est abandonné.
  • Clusters présentant une instabilité persistante qui passe régulièrement par des états opérationnels. Par exemple, les états qui basculent en boucle entre exécution, état dégradé, réparation, suspension, puis exécution à nouveau sans résolution.

Si vous constatez une mise à niveau automatique inattendue et que vous craignez l'effet qu'elle pourrait avoir sur votre cluster, contactez l'équipe Cloud Customer Care pour obtenir de l'aide.

Résoudre les problèmes de mise à niveau

En cas d'échec de la mise à niveau, GKE génère des messages d'erreur. Les sections suivantes décrivent les causes et les solutions des erreurs suivantes :

Erreur : kube-apiserver n'est pas opérationnel

Il arrive que le message d'erreur suivant s'affiche lorsque vous lancez une mise à niveau manuelle du plan de contrôle de la version GKE de votre cluster :

FAILED: All cluster resources were brought up, but: component
"KubeApiserverReady" from endpoint "readyz of kube apiserver is not successful"
is unhealthy.

Ce message s'affiche dans la CLI gcloud et dans les entrées de journal de type de ressource gke_cluster et gke_nodepool.

Ce problème se produit lorsque certains webhooks d'admission déployés par l'utilisateur empêchent les composants système de créer les rôles RBAC permissifs qui sont requis pour un fonctionnement correct.

Lors d'une mise à niveau du plan de contrôle, GKE recrée le composant de serveur d'API Kubernetes (kube-apiserver). Si un webhook bloque le rôle RBAC pour le composant de serveur d'API, le serveur d'API ne démarre pas et la mise à niveau du cluster ne se termine pas. Même si un webhook fonctionne correctement, il peut entraîner l'échec de la mise à niveau du cluster, car le plan de contrôle nouvellement créé peut ne pas être en mesure d'accéder au webhook.

Kubernetes rapproche automatiquement les rôles RBAC système par défaut avec les stratégies par défaut de la dernière version mineure. Les stratégies par défaut des rôles système changent parfois dans les nouvelles versions de Kubernetes.

Pour effectuer ce rapprochement, GKE crée ou met à jour les ClusterRoles et les ClusterRoleBindings dans le cluster. Si vous disposez d'un webhook qui intercepte et refuse les requêtes de création ou de mise à jour en raison du champ d'application des autorisations utilisées par les stratégies RBAC par défaut, le serveur d'API ne peut pas fonctionner sur la nouvelle version mineure.

Pour identifier le webhook défaillant, consultez vos journaux d'audit GKE pour les appels RBAC avec les informations suivantes :

protoPayload.resourceName="RBAC_RULE"
protoPayload.authenticationInfo.principalEmail="system:apiserver"

Dans ce résultat, RBAC_RULE est le nom complet du rôle RBAC, tel que rbac.authorization.k8s.io/v1/clusterroles/system:controller:horizontal-pod-autoscaler.

Le nom du webhook défaillant est affiché dans le journal au format suivant :

admission webhook WEBHOOK_NAME denied the request

Pour résoudre ce problème, procédez comme suit :

  1. Examinez vos ClusterRoles pour vous assurer qu'ils ne sont pas trop restrictifs. Vos règles ne doivent pas bloquer les requêtes de GKE visant à créer ou à mettre à jour les ClusterRoles avec le préfixe system: par défaut.
  2. Ajustez le webhook pour ne pas intercepter les requêtes de création et de mise à jour des rôles RBAC système.
  3. Désactivez le webhook.

Erreur : Échec de DeployPatch

Parfois, l'opération de mise à niveau du cluster échoue avec l'erreur suivante :

DeployPatch failed

Cette erreur peut se produire si le plan de contrôle Kubernetes reste non opérationnel pendant plus de 20 minutes.

Cette erreur est souvent temporaire, car le plan de contrôle réessaie l'opération jusqu'à ce qu'elle réussisse. Si la mise à niveau continue d'échouer avec cette erreur, contactez le Cloud Customer Care.

Résoudre les problèmes après une mise à niveau

Si vous constatez un comportement inattendu après la mise à niveau, les sections suivantes vous aideront à résoudre les problèmes courants suivants :

Comportement inattendu en raison de modifications destructives

Si la mise à niveau s'est déroulée correctement, mais que vous constatez un comportement inattendu après la mise à niveau, consultez les notes de version de GKE pour obtenir des informations sur les bugs et les modifications majeures liés à la version vers laquelle le cluster a été mis à niveau.

Éviction des charges de travail après la mise à niveau d'un cluster standard

Vos charges de travail peuvent être exposées à une éviction après la mise à niveau d'un cluster si toutes les conditions suivantes sont remplies :

  • Les charges de travail système nécessitent davantage d'espace lorsque le plan de contrôle du cluster exécute la nouvelle version de GKE.
  • Vos nœuds existants ne disposent pas de suffisamment de ressources pour exécuter les nouvelles charges de travail système et vos charges de travail existantes.
  • L'autoscaler de cluster est désactivé pour le cluster.

Pour résoudre ce problème, procédez comme suit :

  1. Activer l'autoscaling pour un pool de nœuds existant
  2. Activez le provisionnement automatique des nœuds.
  3. Créez un pool de nœuds.
  4. Effectuer le scaling à la hausse d'un pool de nœuds existant

Pods bloqués à l'état Pending après la configuration des ressources pouvant être allouées aux nœuds

Si vous avez configuré des ressources pouvant être allouées aux nœuds, une mise à niveau de la version d'un nœud peut parfois entraîner le blocage des pods qui étaient à l'état Running à l'état Pending. Ce changement se produit généralement parce que le nœud mis à niveau consomme des ressources système légèrement différentes ou parce que les pods qui ont été reprogrammés doivent désormais s'adapter aux limites de ressources allouables des nœuds nouveaux ou modifiés, potentiellement dans des conditions plus strictes.

Si vos pods sont associés à l'état Pending après une mise à niveau, essayez les solutions suivantes :

  1. Vérifiez que les demandes de ressources de mémoire et de processeur pour vos pods ne dépassent pas leur pic d'utilisation. Étant donné que GKE réserve le processeur et la mémoire pour les frais généraux, les pods ne peuvent pas demander ces ressources. Les pods qui demandent plus de ressources mémoire et de processeur qu'ils n'en utilisent empêchent les autres pods de demander ces ressources et peuvent laisser le cluster sous-exploité. Pour en savoir plus, consultez la section Programmation des pods avec des demandes de ressources dans la documentation Kubernetes.
  2. Envisagez d'augmenter la taille de votre cluster.
  3. Pour vérifier si la mise à niveau est à l'origine de ce problème, annulez-la en rétrogradant vos pools de nœuds.
  4. Configurez votre cluster pour envoyer les métriques du programmeur Kubernetes à Cloud Monitoring et afficher les métriques du programmeur. En surveillant ces métriques, vous pouvez déterminer si les ressources sont suffisantes pour l'exécution des pods.

Résoudre les problèmes de version et de compatibilité

Il est essentiel de maintenir des versions compatibles et acceptées pour tous les composants de votre cluster afin de garantir la stabilité et les performances. Les sections suivantes vous expliquent comment identifier et résoudre les problèmes de gestion des versions et de compatibilité qui peuvent affecter le processus de mise à niveau.

Vérifier l'incompatibilité entre la version du plan de contrôle et celle du nœud

Un décalage entre les versions de votre plan de contrôle et de vos nœuds peut entraîner une instabilité du cluster. La règle de décalage entre les versions GKE stipule qu'un plan de contrôle n'est compatible qu'avec les nœuds jusqu'à deux versions mineures antérieures. Par exemple, un plan de contrôle 1.19 fonctionne avec les nœuds 1.19, 1.18 et 1.17.

Si vos nœuds ne se trouvent pas dans cette fenêtre compatible, vous risquez de rencontrer des problèmes de compatibilité critiques. Ces problèmes sont souvent liés aux API. Par exemple, une charge de travail sur un ancien nœud peut utiliser une version d'API qui a été abandonnée ou supprimée dans le nouveau plan de contrôle. Cette incompatibilité peut également entraîner des échecs plus graves, comme un chemin réseau rompu qui empêche les nœuds de s'enregistrer auprès du cluster si une charge de travail incompatible perturbe la communication.

L'équipe GKE effectue régulièrement des mises à niveau du plan de contrôle du cluster en votre nom. Les plans de contrôle sont mis à niveau vers les versions stables les plus récentes de Kubernetes. Pour que vos nœuds restent compatibles avec le plan de contrôle mis à niveau, ils doivent également être tenus à jour. Par défaut, GKE gère cette mise à niveau, car la mise à niveau automatique est activée sur les nœuds d'un cluster. Nous vous recommandons de ne pas la désactiver. Si la mise à niveau automatique est désactivée pour les nœuds d'un cluster et que vous ne les mettez pas à niveau manuellement, votre plan de contrôle finira par être incompatible avec vos nœuds.

Pour vérifier si les versions de votre plan de contrôle et de vos nœuds sont incompatibles, vérifiez la version de Kubernetes exécutée par le plan de contrôle et les pools de nœuds de votre cluster :

gcloud container clusters describe CLUSTER_NAME \
    --project PROJECT_ID  \
    --location LOCATION

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster du pool de nœuds à décrire.
  • PROJECT_ID : ID de projet du cluster.
  • LOCATION : région ou zone Compute Engine (par exemple, us-central1 ou us-central1-a) du cluster.

Le résultat ressemble à ce qui suit :

…
currentMasterVersion: 1.32.3-gke.1785003
…
currentNodeVersion: 1.26.15-gke.1090000
…

Dans cet exemple, la version du plan de contrôle et celle du pool de nœuds sont incompatibles.

Pour résoudre ce problème, mettez à niveau manuellement le pool de nœuds vers une version compatible avec le plan de contrôle.

Si vous craignez que le processus de mise à niveau entraîne des perturbations pour les charges de travail s'exécutant sur les nœuds concernés, procédez comme suit pour migrer vos charges de travail vers un nouveau pool de nœuds :

  1. Créez un pool de nœuds avec une version compatible.
  2. Marquez les nœuds du pool existant comme non programmables.
  3. Facultatif : Mettez à jour vos charges de travail exécutées sur le pool de nœuds existant pour ajouter un sélecteur de nœuds pour le libellé cloud.google.com/gke-nodepool:NEW_NODE_POOL_NAME. Remplacez NEW_NODE_POOL_NAME par le nom du nouveau pool de nœuds. Cette action garantit que GKE place ces charges de travail sur les nœuds du nouveau pool de nœuds.
  4. Drainez le pool de nœuds existant.
  5. Vérifiez que les charges de travail s'exécutent correctement dans le nouveau pool de nœuds. Si tel est le cas, vous pouvez supprimer l'ancien pool de nœuds. Si vous remarquez des interruptions de charge de travail, reprogrammez les charges de travail sur les nœuds existants en marquant les nœuds du pool de nœuds existant comme non programmables et en drainant les nouveaux nœuds.

L'utilisation du processeur par le nœud 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.

Ce problème peut se produire si vous utilisez des mises à niveau manuelles et que vos clusters ou nœuds n'ont pas été mis à niveau pour exécuter une version compatible. Consultez les notes de version pour vous assurer que les versions que vous utilisez sont disponibles et compatibles.

Étapes suivantes