Résoudre les problèmes liés aux nœuds dont l'état est "NotReady" dans GKE

Un état NotReady dans Google Kubernetes Engine (GKE) signifie que le kubelet du nœud ne communique pas correctement avec le plan de contrôle. Comme Kubernetes ne planifie pas de nouveaux pods sur un nœud NotReady, ce problème peut réduire la capacité de l'application et entraîner des temps d'arrêt.

Utilisez ce document pour faire la distinction entre les états NotReady attendus et les problèmes réels, diagnostiquer la cause première et trouver des solutions aux problèmes courants tels que l'épuisement des ressources, les problèmes de réseau et les échecs d'exécution du conteneur.

Ces informations s'adressent aux administrateurs et opérateurs de plate-forme responsables de la stabilité des clusters, ainsi qu'aux développeurs d'applications qui souhaitent comprendre le comportement des applications liées à l'infrastructure. 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.

Avant de commencer

  • Pour obtenir les autorisations nécessaires pour effectuer les tâches décrites dans ce document, demandez à votre administrateur de vous accorder les rôles IAM suivants sur votre projet Google Cloud  :

    Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

    Vous pouvez également obtenir les autorisations requises avec des rôles personnalisés ou d'autres rôles prédéfinis.

  • Configurez l'outil de ligne de commande kubectl pour communiquer avec votre cluster GKE :

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location LOCATION \
    --project PROJECT_ID

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster
    • LOCATION : région ou zone Compute Engine (par exemple, us-central1 ou us-central1-a) du cluster.
    • PROJECT_ID : ID de votre projet Google Cloud .

Vérifier l'état et les conditions du nœud

Pour confirmer qu'un nœud a l'état NotReady et vous aider à diagnostiquer la cause première, suivez les étapes ci-dessous pour inspecter les conditions, les événements, les journaux et les métriques de ressources d'un nœud :

  1. Affichez l'état de vos nœuds. Pour obtenir des informations supplémentaires, comme les adresses IP et les versions du noyau, qui sont utiles pour le diagnostic, utilisez l'option -o wide :

    kubectl get nodes -o wide

    Le résultat ressemble à ce qui suit :

    NAME                                STATUS     ROLES    AGE   VERSION               INTERNAL-IP  EXTERNAL-IP  OS-IMAGE                             KERNEL-VERSION   CONTAINER-RUNTIME
gke-cluster-pool-1-node-abc1        Ready      <none>   94d   v1.32.3-gke.1785003   10.128.0.1   1.2.3.4      Container-Optimized OS from Google   6.6.72+          containerd://1.7.24
gke-cluster-pool-1-node-def2        Ready      <none>   94d   v1.32.3-gke.1785003   10.128.0.2   5.6.7.8      Container-Optimized OS from Google   6.6.72+          containerd://1.7.24
gke-cluster-pool-1-node-ghi3        NotReady   <none>   94d   v1.32.3-gke.1785003   10.128.0.3   9.10.11.12   Container-Optimized OS from Google   6.6.72+          containerd://1.7.24

    Dans le résultat, recherchez les nœuds dont la valeur est NotReady dans la colonne STATUS et notez leurs noms.

  2. Affichez plus d'informations sur des nœuds spécifiques avec l'état NotReady, y compris leurs conditions et les événements Kubernetes récents :

    kubectl describe node NODE_NAME

    Remplacez NODE_NAME par le nom d'un nœud dont l'état est NotReady.

    Dans le résultat, concentrez-vous sur la section Conditions pour comprendre l'état du nœud et sur la section Events pour consulter l'historique des problèmes récents. Exemple :

    Name:                   gke-cluster-pool-1-node-ghi3
...
Conditions:
Type                          Status    LastHeartbeatTime                 LastTransitionTime                Reason                   Message
----                          ------    -----------------                 ------------------                ------                   -------
NetworkUnavailable            False     Wed, 01 Oct 2025 10:29:19 +0100   Wed, 01 Oct 2025 10:29:19 +0100   RouteCreated             RouteController created a route
MemoryPressure                Unknown   Wed, 01 Oct 2025 10:31:06 +0100   Wed, 01 Oct 2025 10:31:51 +0100   NodeStatusUnknown        Kubelet stopped posting node status.
DiskPressure                  Unknown   Wed, 01 Oct 2025 10:31:06 +0100   Wed, 01 Oct 2025 10:31:51 +0100   NodeStatusUnknown        Kubelet stopped posting node status.
PIDPressure                   False     Wed, 01 Oct 2025 10:31:06 +0100   Wed, 01 Oct 2025 10:29:00 +0100   KubeletHasSufficientPID  kubelet has sufficient PID available
Ready                         Unknown   Wed, 01 Oct 2025 10:31:06 +0100   Wed, 01 Oct 2025 10:31:51 +0100   NodeStatusUnknown        Kubelet stopped posting node status.
Events:
Type     Reason                   Age                  From                                   Message
----     ------                   ----                 ----                                   -------
Normal   Starting                 32m                  kubelet, gke-cluster-pool-1-node-ghi3  Starting kubelet.
Warning  PLEGIsNotHealthy         5m1s (x15 over 29m)  kubelet, gke-cluster-pool-1-node-ghi3  PLEG is not healthy: pleg was last seen active 5m1.123456789s ago; threshold is 3m0s
Normal   NodeHasSufficientMemory  5m1s (x16 over 31m)  kubelet, gke-cluster-pool-1-node-ghi3  Node gke-cluster-pool-1-node-ghi3 status is now: NodeHasSufficientMemory

    Dans la section Conditions, un état True pour toute condition négative ou Unknown pour la condition Ready indique un problème. Portez une attention particulière aux champs Reason et Message de ces conditions, car ils expliquent la cause du problème.

    Voici la signification de chaque type de condition :

    • KernelDeadlock : True si le noyau du système d'exploitation du nœud a détecté un blocage, qui est une erreur grave pouvant entraîner le blocage du nœud.
    • FrequentUnregisterNetDevice : True si le nœud annule fréquemment l'enregistrement de ses périphériques réseau, ce qui peut être le signe de problèmes de pilote ou matériels.
    • NetworkUnavailable : True si la mise en réseau du nœud n'est pas configurée correctement.
    • OutOfDisk : True si l'espace disque disponible est complètement épuisé. Cette condition est plus grave que DiskPressure.
    • MemoryPressure : True si la mémoire du nœud est faible.
    • DiskPressure : True si l'espace disque du nœud est faible.
    • PIDPressure : True si le nœud est en manque d'ID de processus (PID).
    • Ready : indique si le nœud est opérationnel et prêt à accepter les pods.
      • True si le nœud est opérationnel.
      • False si le nœud n'est pas opérationnel et n'accepte pas les pods.
      • Unknown si le contrôleur de nœud n'a pas reçu de réponse du nœud pendant un délai de grâce (50 secondes par défaut) et que l'état du nœud est inconnu.

    Ensuite, examinez la section Events, qui fournit un journal chronologique des actions et des observations concernant le nœud. Cette chronologie est essentielle pour comprendre ce qui s'est passé immédiatement avant que le nœud ne devienne NotReady. Recherchez des messages spécifiques qui peuvent vous aider à identifier la cause, tels que des avertissements d'éviction (signalant une pression sur les ressources), des vérifications de l'état de santé ayant échoué ou des événements de cycle de vie des nœuds tels que la mise en quarantaine pour une réparation.

  3. Pour comprendre pourquoi les nœuds ont l'état NotReady, consultez les journaux du nœud et de ses composants.

    1. Consultez les journaux kubelet pour connaître l'état de NotReady.

      kubelet est l'agent principal qui signale l'état du nœud au plan de contrôle. Ses journaux sont donc l'endroit le plus susceptible de contenir le message NotReady. Ces journaux sont la source de référence pour diagnostiquer les problèmes liés aux événements du cycle de vie des pods, aux conditions de pression des ressources (comme MemoryPressure ou DiskPressure) et à la connectivité du nœud au plan de contrôle Kubernetes.

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

      Accéder à l'explorateur de journaux

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

      resource.type="k8s_node"
resource.labels.node_name="NODE_NAME"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
log_id("kubelet")
textPayload=~"(?i)NotReady"

      Remplacez les éléments suivants :

      • NODE_NAME : nom du nœud que vous examinez.
      • CLUSTER_NAME : nom du cluster
      • LOCATION : région ou zone Compute Engine (par exemple, us-central1 ou us-central1-a) du cluster.

    4. Cliquez sur Exécuter la requête et examinez les résultats.

    5. Si les journaux kubelet ne révèlent pas la cause première, consultez les journaux container-runtime et node-problem-detector. Il est possible que ces composants n'enregistrent pas directement l'état NotReady, mais ils enregistrent souvent le problème sous-jacent (comme un échec d'exécution ou un kernel panic) qui a causé le problème.

    6. Dans le volet de requête de l'explorateur de journaux, saisissez la requête suivante :

      resource.type="k8s_node"
resource.labels.node_name="NODE_NAME"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
log_id("COMPONENT_NAME")

      Remplacez COMPONENT_NAME par l'une des valeurs suivantes :

      • container-runtime : environnement d'exécution (containerd) responsable du cycle de vie complet du conteneur, y compris de l'extraction des images et de la gestion de l'exécution du conteneur. L'examen des journaux container-runtime est essentiel pour résoudre les échecs liés à l'instanciation des conteneurs, les erreurs de service d'exécution ou les problèmes causés par la configuration de l'exécution.
      • node-problem-detector : utilitaire qui surveille de manière proactive et signale au plan de contrôle divers problèmes au niveau des nœuds. Ses journaux sont essentiels pour identifier les problèmes systémiques sous-jacents qui peuvent entraîner l'instabilité des nœuds, tels que les blocages du noyau, la corruption du système de fichiers ou les défaillances matérielles, qui peuvent ne pas être capturés par d'autres composants Kubernetes.

    7. Cliquez sur Exécuter la requête et examinez les résultats.

  4. Utilisez l'explorateur de métriques pour rechercher l'épuisement des ressources au moment où le nœud est passé à l'état NotReady :

    1. Dans la console Google Cloud , accédez à la page Explorateur de métriques :

      Accéder à l'explorateur de métriques

    2. Dans l'explorateur de métriques, vérifiez si l'instance Compute Engine sous-jacente du nœud est à court de ressources. Concentrez-vous sur les métriques liées au CPU, à la mémoire et aux E/S disque. Exemple :

      • Métriques des nœuds GKE : commencez par les métriques précédées du préfixe kubernetes.io/node/, comme kubernetes.io/node/cpu/allocatable_utilization ou kubernetes.io/node/memory/allocatable_utilization. Ces métriques indiquent la quantité de ressources disponibles du nœud utilisée par vos pods. Le montant disponible n'inclut pas les ressources que Kubernetes réserve pour les frais généraux du système.
      • Métriques de l'OS invité : pour obtenir une vue de l'intérieur du système d'exploitation du nœud, utilisez les métriques préfixées par compute.googleapis.com/guest/, telles que compute.googleapis.com/guest/cpu/usage ou compute.googleapis.com/guest/memory/bytes_used.
      • Métriques de l'hyperviseur : pour afficher les performances de la VM au niveau de l'hyperviseur, utilisez les métriques préfixées par compute.googleapis.com/instance/, telles que compute.googleapis.com/instance/cpu/utilization ou les métriques d'E/S de disque comme compute.googleapis.com/instance/disk/read_bytes_count.

      Pour les métriques de l'OS invité et de l'hyperviseur, vous devez filtrer par nom de l'instance Compute Engine sous-jacente, et non par nom du nœud Kubernetes. Vous pouvez trouver le nom de l'instance d'un nœud en exécutant la commande kubectl describe node NODE_NAME et en recherchant le champ ProviderID dans le résultat. Le nom de l'instance correspond à la dernière partie de cette valeur. Exemple :

      ...
Spec:
ProviderID: gce://my-gcp-project-123/us-central1-a/gke-my-cluster-default-pool-1234abcd-5678
...

      Dans cet exemple, le nom de l'instance est gke-my-cluster-default-pool-1234abcd-5678.

Identifier la cause par symptôme

Si vous avez identifié un symptôme spécifique, tel qu'un message de journal, une condition de nœud ou un événement de cluster, utilisez le tableau suivant pour obtenir des conseils de dépannage :

Catégorie Message de journal ou symptôme Cause possible Procédure de dépannage
Conditions de nœud NetworkUnavailable: True Problème de connectivité entre le nœud et le plan de contrôle, ou échec du plug-in CNI (Container Network Interface). Résolvez les problèmes de connectivité réseau.
MemoryPressure: True Le nœud ne dispose pas de suffisamment de mémoire. Résoudre les problèmes de pénurie de ressources de nœud
DiskPressure: True L'espace disque du nœud est insuffisant. Résoudre les problèmes de pénurie de ressources de nœud
PIDPressure: True Le nœud ne dispose pas de suffisamment d'ID de processus. Résoudre les problèmes de pénurie de ressources de nœud
Événements et messages du journal PLEG is not healthy Le kubelet est surchargé en raison d'une utilisation élevée du processeur/des E/S ou d'un trop grand nombre de pods. Résoudre les problèmes liés au PLEG
Out of memory: Kill process
sys oom event		 La mémoire du nœud est complètement épuisée. Résoudre les événements OOM au niveau du système
leases.coordination.k8s.io...is forbidden L'espace de noms kube-node-lease est bloqué à l'état d'arrêt. Résoudre les problèmes liés à l'espace de noms kube-node-lease
Container runtime not ready
runtime is down
 Erreurs faisant référence à /run/containerd/containerd.sock ou docker.sock		 Le service containerd ou Docker a échoué ou est mal configuré. Résoudre les problèmes liés à l'environnement d'exécution du conteneur
Pods bloqués dans l'état Terminating
Les journaux Kubelet affichent DeadlineExceeded pour le conteneur kill
Les journaux containerd affichent des messages Kill container répétés		 Processus bloqués en veille disque ininterrompue (état D), souvent liés aux E/S. Résoudre les problèmes de processus bloqués dans l'état D
Symptômes au niveau du cluster Plusieurs nœuds échouent après le déploiement d'un DaemonSet. Le DaemonSet interfère avec les opérations de nœud. Résoudre les problèmes causés par les DaemonSets tiers
compute.instances.preempted dans les journaux d'audit. La VM Spot a été préemptée, ce qui est un comportement normal. Confirmer la préemption des nœuds
Les pods kube-system sont bloqués à l'état Pending. Le webhook d'admission bloque des composants essentiels. Résoudre les problèmes causés par les webhooks d'admission
exceeded quota: gcp-critical-pods Un quota mal configuré bloque les pods système. Résoudre les problèmes causés par les quotas de ressources

Vérifier les événements NotReady attendus

Un état NotReady n'indique pas toujours un problème. Il peut s'agir d'un comportement attendu lors d'opérations planifiées, comme la mise à niveau d'un pool de nœuds, ou si vous utilisez certains types de machines virtuelles.

Confirmer les opérations du cycle de vie des nœuds

Symptômes :

Un nœud affiche temporairement l'état NotReady lors de certains événements de cycle de vie.

Cause :

L'état d'un nœud devient temporairement NotReady lors de plusieurs événements courants du cycle de vie. Ce comportement est attendu chaque fois qu'un nœud est créé ou recréé, par exemple dans les scénarios suivants :

  • Mises à niveau des pools de nœuds : lors d'une mise à niveau, chaque nœud est vidé et remplacé. Le nouveau nœud mis à niveau présente l'état NotReady jusqu'à ce qu'il ait terminé de s'initialiser et qu'il rejoigne le cluster.
  • Réparation automatique des nœuds : lorsque GKE remplace un nœud défaillant, le nœud de remplacement reste à l'état NotReady pendant son provisionnement.
  • Augmentation de la taille de l'autoscaler de cluster : lorsque de nouveaux nœuds sont ajoutés, ils commencent avec l'état NotReady et passent à l'état Ready uniquement après avoir été entièrement provisionnés et avoir rejoint le cluster.
  • Modifications manuelles du modèle d'instance : GKE recrée les nœuds lorsque vous appliquez des modifications au modèle. Le nouveau nœud présente l'état NotReady pendant sa phase de démarrage.

Solution :

Les nœuds ne doivent avoir l'état NotReady que brièvement. Si l'état persiste pendant plus de 10 minutes, recherchez d'autres causes.

Confirmer la préemption de nœud

Si votre nœud s'exécute sur une VM Spot ou une VM préemptive, Compute Engine peut l'arrêter brusquement pour récupérer des ressources. Ce comportement est normal pour ces types de machines virtuelles éphémères et ne constitue pas une erreur.

Symptômes :

Si vous constatez les symptômes suivants, il est probable que l'état NotReady du nœud soit dû à une préemption de VM Spot attendue :

  • Un nœud passe de manière inattendue à l'état NotReady avant d'être supprimé et recréé par l'autoscaler de cluster.
  • Cloud Audit Logs affiche un événement compute.instances.preempted pour l'instance de VM sous-jacente.

Cause :

Le nœud s'exécutait sur une instance de VM Spot ou préemptive, et Compute Engine a récupéré ces ressources de calcul pour une autre tâche. Les VM Spot peuvent être interrompues à tout moment, mais elles fournissent généralement un préavis d'arrêt de 30 secondes.

Solution :

N'utilisez les VM Spot ou préemptives que pour les charges de travail tolérantes aux pannes, sans état ou par lot, conçues pour gérer les arrêts fréquents de manière fluide. Pour les charges de travail de production ou avec état qui ne peuvent pas tolérer d'interruptions soudaines, provisionnez vos pools de nœuds à l'aide de VM standards à la demande.

Résoudre les problèmes de pénurie de ressources de nœud

Un nœud devient souvent NotReady parce qu'il manque de ressources essentielles comme le processeur, la mémoire ou l'espace disque. Lorsqu'un nœud ne dispose pas de suffisamment de ces ressources, les composants essentiels ne peuvent pas fonctionner correctement, ce qui entraîne une instabilité de l'application et une absence de réponse du nœud. Les sections suivantes décrivent les différentes façons dont ces pénuries peuvent se manifester, des conditions de pression générales aux événements plus graves à l'échelle du système.

Résoudre la pression exercée sur les ressources de nœud

L'épuisement des ressources se produit lorsqu'un nœud ne dispose pas de suffisamment de processeur, de mémoire, d'espace disque ou d'ID de processus (PID) pour exécuter ses charges de travail. Ce problème peut entraîner l'état NotReady.

Symptômes :

Si vous observez les conditions et les journaux de nœud suivants, l'épuisement des ressources est la cause probable de l'état NotReady du nœud :

  • Dans le résultat de la commande kubectl describe node, vous voyez un état True pour des conditions telles que OutOfDisk, MemoryPressure, DiskPressure ou PIDPressure.
  • Les journaux kubelet peuvent contenir des événements de mémoire insuffisante (OOM), indiquant que le système OOM Killer a été appelé.

Cause :

Les charges de travail sur le nœud demandent collectivement plus de ressources que le nœud ne peut en fournir.

Solution :

Pour les clusters standards, essayez les solutions suivantes :

Pour les clusters Autopilot, vous ne contrôlez pas directement les types de machines des nœuds ni la taille des disque de démarrage. La capacité des nœuds est gérée automatiquement en fonction de vos requêtes de pods. Assurez-vous que les demandes de ressources de votre charge de travail respectent les limites d'Autopilot et reflètent précisément les besoins de votre application. Des problèmes de ressources persistants peuvent indiquer qu'il est nécessaire d'optimiser les requêtes de pod ou, dans de rares cas, qu'il s'agit d'un problème de plate-forme nécessitant l'aide de Cloud Customer Care.

Résoudre les événements OOM au niveau du système

Un événement de mémoire insuffisante (OOM) au niveau du système se produit lorsque la mémoire totale d'un nœud est épuisée, ce qui oblige le noyau Linux à mettre fin aux processus pour libérer des ressources. Cet événement est différent d'un événement OOM au niveau du conteneur, où un seul pod dépasse ses limites de mémoire.

Symptômes :

Si vous remarquez les symptômes suivants, il est probable qu'un événement OOM au niveau du système soit à l'origine de l'instabilité du nœud :

  • Vous remarquez le message Out of memory: Kill process dans les journaux de la console série du nœud.
  • Les journaux kubelet contiennent des événements oom_watcher, qui indiquent que kubelet a détecté un événement OOM au niveau du système.
  • Arrêt inattendu de divers processus, y compris des daemons système ou des pods de charge de travail potentiellement critiques, et pas nécessairement des plus gros consommateurs de mémoire.

Cause :

La mémoire globale du nœud est pleine. Ce problème peut être dû à un bug dans un service système, à une charge de travail mal configurée qui consomme une quantité excessive de mémoire ou à un nœud trop petit pour les besoins collectifs en mémoire de tous ses pods en cours d'exécution.

Solution :

Pour résoudre les événements OOM au niveau du système, diagnostiquez la cause, puis réduisez la demande de mémoire ou augmentez la capacité des nœuds. Pour en savoir plus, consultez Résoudre les problèmes d'événements OOM.

Résoudre les problèmes liés à PLEG

Le générateur d'événements de cycle de vie des pods (PLEG) est un composant de kubelet. Il vérifie régulièrement l'état de tous les conteneurs du nœud et signale toute modification au kubelet.

Lorsque le PLEG rencontre des problèmes de performances, il ne peut pas fournir d'informations à jour au kubelet, ce qui peut entraîner l'instabilité du nœud.

Symptômes :

Si vous observez les symptômes suivants, il est possible que le PLEG ne fonctionne pas correctement :

  • Les journaux kubelet du nœud contiennent un message semblable à PLEG is not healthy.
  • L'état du nœud change fréquemment entre Ready et NotReady.

Cause :

Les problèmes PLEG sont généralement dus à des problèmes de performances qui empêchent le kubelet de recevoir des mises à jour en temps voulu de l'environnement d'exécution du conteneur. Voici quelques causes courantes :

  • Charge CPU élevée : le processeur du nœud est saturé, ce qui empêche le kubelet et le moteur d'exécution du conteneur de disposer de la puissance de traitement dont ils ont besoin.
  • Limitation des E/S : le disque de démarrage du nœud est soumis à de nombreuses opérations d'E/S, ce qui peut ralentir toutes les tâches liées au disque.
  • Nombre excessif de pods : un nombre trop élevé de pods sur un même nœud peut surcharger le kubelet et l'environnement d'exécution du conteneur, ce qui entraîne une contention des ressources.

Solution :

Pour les clusters standards, réduisez la pression sur les ressources du nœud :

Pour les clusters Autopilot, bien que vous ne puissiez pas modifier directement la taille ni le type de disque d'un nœud existant, vous pouvez influencer le matériel sur lequel vos charges de travail s'exécutent en utilisant des ComputeClasses personnalisées. Cette fonctionnalité vous permet de spécifier des exigences dans le fichier manifeste de votre charge de travail, comme une quantité minimale de processeur et de mémoire ou une série de machines spécifique, pour guider la planification de vos pods.

Si vous n'utilisez pas ComputeClasses, ajustez les déploiements de charge de travail (comme le nombre de réplicas et les demandes ou limites de ressources) et assurez-vous qu'ils respectent les contraintes d'Autopilot. Si les problèmes liés à PLEG persistent après l'optimisation de vos charges de travail, contactez l'assistance Cloud Customer Care.

Résoudre les problèmes de processus bloqués dans l'état D

Les processus bloqués dans un état de veille du disque non interruptible (état D) peuvent rendre un nœud non réactif. Ce problème empêche l'arrêt des pods et peut entraîner l'échec de composants critiques tels que containerd, ce qui entraîne un état NotReady.

Symptômes :

  • Les pods, en particulier ceux qui utilisent un stockage réseau tel que NFS, sont bloqués dans l'état Terminating pendant une longue période.
  • Les journaux Kubelet affichent des erreurs DeadlineExceeded lors de la tentative d'arrêt d'un conteneur.
  • Les journaux de la console série du nœud peuvent afficher des messages du noyau concernant hung tasks ou des tâches bloquées pendant plus de 120 secondes.

Cause :

Les processus passent à l'état D lorsqu'ils attendent la fin d'une opération d'E/S et ne peuvent pas être interrompus. Voici quelques causes courantes :

  • Systèmes de fichiers distants lents ou ne répondant pas, tels qu'un partage NFS mal configuré ou surchargé.
  • Dégradation importante des performances du disque ou erreurs d'E/S matérielles sur les disques locaux du nœud.

Solution :

Pour résoudre les problèmes liés aux processus en état D, identifiez la source d'E/S, puis effacez l'état en sélectionnant l'une des options suivantes :

Clusters standards

  1. Recherchez le processus bloqué et déterminez ce qu'il attend :

    1. Connectez-vous au nœud concerné à l'aide de SSH :

      gcloud compute ssh NODE_NAME \
    --zone ZONE \
    --project PROJECT_ID

      Remplacez les éléments suivants :

      • NODE_NAME : nom du nœud auquel se connecter.
      • ZONE : zone Compute Engine du nœud.
      • PROJECT_ID : ID de votre projet.

    2. Recherchez les processus dans un état D :

      ps -eo state,pid,comm,wchan | grep '^D'

      Le résultat ressemble à ce qui suit :

      D  12345  my-app      nfs_wait
D  54321  data-writer io_schedule

      Le résultat ne comportera pas d'en-tête. Les colonnes représentent, dans l'ordre :

      • État
      • ID du processus (PID)
      • Commande
      • Canal d'attente (wchan)

    3. Examinez la colonne wchan pour identifier la source d'E/S :

      • Si la colonne wchan inclut des termes tels que nfs ou rpc, le processus est en attente d'un partage NFS.
      • Si la colonne wchan inclut des termes tels que io_schedule, jbd2 ou ext4, le processus attend le disque de démarrage local du nœud.

    4. Pour en savoir plus sur les fonctions du noyau sur lesquelles le processus est en attente, consultez la pile d'appels du noyau du processus :

      cat /proc/PID/stack

      Remplacez PID par l'ID de processus que vous avez trouvé à l'étape précédente.

  2. Redémarrez le nœud. Le redémarrage est souvent le moyen le plus efficace de supprimer un processus bloqué dans un état D.

    1. Drainez le nœud.
    2. Supprimez l'instance de VM sous-jacente. GKE crée généralement une VM pour la remplacer.

  3. Après avoir résolu le problème immédiat, examinez le système de stockage sous-jacent pour éviter qu'il ne se reproduise.

    • Pour les problèmes de stockage réseau (NFS) : utilisez les outils de surveillance de votre fournisseur de stockage pour vérifier si la latence est élevée, si des erreurs côté serveur se produisent ou si des problèmes réseau existent entre le nœud GKE et le serveur NFS.

    • En cas de problème avec un disque local : vérifiez si la limitation des E/S est activée dans Cloud Monitoring en consultant les métriques compute.googleapis.com/instance/disk/throttled_read_ops_count et compute.googleapis.com/instance/disk/throttled_write_ops_count pour l'instance Compute Engine.

Clusters Autopilot

  1. Essayez d'identifier la source du blocage :

    L'accès SSH direct aux nœuds et l'exécution de commandes telles que ps ou cat /proc ne sont pas disponibles dans les clusters Autopilot. Vous devez vous appuyer sur les journaux et les métriques.

    1. Vérifiez les journaux des nœuds : dans Cloud Logging, analysez les journaux du nœud concerné. Filtrez par nom de nœud et par période du problème. Recherchez les messages du noyau indiquant des erreurs d'E/S, des délais d'attente de stockage (par exemple, sur disque ou NFS) ou des messages provenant des pilotes CSI.
    2. Vérifiez les journaux de charge de travail : examinez les journaux des pods en cours d'exécution sur le nœud concerné. Les journaux d'application peuvent révéler des erreurs liées aux opérations sur les fichiers, aux appels de base de données ou à l'accès au stockage réseau.
    3. Utilisez Cloud Monitoring : même si vous ne pouvez pas obtenir de détails au niveau du processus, vérifiez s'il existe des problèmes d'E/S au niveau du nœud.

  2. Déclenchez le remplacement d'un nœud pour effacer l'état.

    Vous ne pouvez pas supprimer manuellement la VM sous-jacente. Pour déclencher un remplacement, vidangez le nœud. Cette action isole le nœud et évince les pods.

    GKE détecte automatiquement les nœuds défaillants et lance des réparations, généralement en remplaçant la VM sous-jacente.

    Si le nœud reste bloqué après la vidange et n'est pas remplacé automatiquement, contactez Cloud Customer Care.

  3. Après avoir résolu le problème immédiat, examinez le système de stockage sous-jacent pour éviter qu'il ne se reproduise.

    • Pour les problèmes de disque local : vérifiez si la limitation des E/S est activée dans Cloud Monitoring en consultant les métriques compute.googleapis.com/instance/disk/throttled_read_ops_count et compute.googleapis.com/instance/disk/throttled_write_ops_count. Vous pouvez filtrer ces métriques pour le groupe d'instances sous-jacent du pool de nœuds, bien que les instances individuelles soient gérées par Google.
    • Pour les problèmes de stockage réseau (NFS) : utilisez les outils de surveillance de votre fournisseur de stockage pour vérifier si la latence est élevée, si des erreurs côté serveur se produisent ou si des problèmes réseau existent entre le nœud GKE et le serveur NFS. Consultez les journaux de tous les pods de pilotes CSI dans Cloud Logging.

Résoudre les problèmes d'échec des composants principaux

Une fois que vous avez écarté les causes attendues et les pénuries de ressources, le problème peut être lié au logiciel du nœud ou à un mécanisme Kubernetes essentiel. Un état NotReady peut se produire lorsqu'un composant essentiel, tel que le runtime du conteneur, échoue. Cela peut également se produire lorsqu'un mécanisme de vérification de l'état Kubernetes de base, tel que le système de bail de nœud, tombe en panne.

Résoudre les problèmes liés à l'environnement d'exécution du conteneur

Les problèmes liés à l'exécution du conteneur, tels que containerd, peuvent empêcher le kubelet de lancer des pods sur un nœud.

Symptômes :

Si les messages suivants s'affichent dans les journaux kubelet, un problème d'exécution du conteneur est la cause probable de l'état NotReady du nœud :

  • Container runtime not ready
  • Container runtime docker failed!
  • docker daemon exited
  • Erreurs de connexion au socket d'exécution (par exemple, unix:///var/run/docker.sock ou unix:///run/containerd/containerd.sock).

Cause :

L'environnement d'exécution du conteneur ne fonctionne pas correctement, est mal configuré ou est bloqué dans une boucle de redémarrage.

Solution :

Pour résoudre les problèmes liés à l'exécution du conteneur :

  1. Analyser les journaux de l'environnement d'exécution du conteneur :

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

      Accéder à l'explorateur de journaux

    2. Pour afficher tous les journaux d'avertissements et d'erreurs du moteur d'exécution du conteneur sur le nœud concerné, saisissez la requête suivante dans le volet de requête :

      resource.type="k8s_node"
resource.labels.node_name="NODE_NAME"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
log_id("container-runtime")
severity>=WARNING

      Remplacez les éléments suivants :

      • NODE_NAME : nom du nœud que vous examinez.
      • CLUSTER_NAME : nom du cluster
      • LOCATION : région ou zone Compute Engine (par exemple, us-central1 ou us-central1-a) du cluster.

    3. Cliquez sur Exécuter la requête et examinez le résultat pour identifier les messages d'erreur spécifiques qui indiquent pourquoi l'exécution a échoué. Un message tel que failed to load TOML dans les journaux containerd de Cloud Logging indique souvent qu'un fichier est mal formé.

    4. Pour vérifier si le runtime est bloqué dans une boucle de redémarrage, exécutez une requête qui recherche les messages de démarrage. Un grand nombre de ces messages sur une courte période confirme des redémarrages fréquents.

      resource.type="k8s_node"
resource.labels.node_name="NODE_NAME"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
log_id("container-runtime")
("starting containerd" OR "Containerd cri plugin version" OR "serving..."
OR "loading plugin" OR "containerd successfully booted")

      Des redémarrages fréquents indiquent souvent un problème sous-jacent, comme un fichier de configuration corrompu ou une pression sur les ressources, qui provoque des plantages répétés du service.

  2. Vérifiez la configuration containerd pour détecter d'éventuelles modifications : des paramètres incorrects peuvent entraîner l'échec de l'exécution du conteneur. Vous pouvez modifier la configuration à l'aide d'un fichier de configuration du système de nœuds ou en apportant des modifications directes effectuées par des charges de travail disposant de droits d'accès élevés.

    1. Déterminez si le pool de nœuds utilise un fichier de configuration du système de nœuds :

      gcloud container node-pools describe NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location LOCATION \
    --format="yaml(config.containerdConfig)"

      Remplacez les éléments suivants :

      • NODE_POOL_NAME : nom de votre pool de nœuds.
      • CLUSTER_NAME : nom du cluster
      • LOCATION : région ou zone Compute Engine de votre cluster.

      Si le résultat affiche une section containerdConfig, cela signifie que GKE gère ces paramètres personnalisés. Pour modifier ou rétablir les paramètres, suivez les instructions de la section Personnaliser la configuration containerd dans les nœuds GKE.

    2. Si les personnalisations gérées par GKE ne sont pas actives ou si vous suspectez d'autres modifications, recherchez les charges de travail susceptibles de modifier directement le système de fichiers du nœud. Recherchez les DaemonSets avec des autorisations élevées (securityContext.privileged: true) ou les volumes hostPath montant des répertoires sensibles tels que /etc.

      Pour inspecter leur configuration, listez tous les DaemonSets au format YAML :

      kubectl get daemonsets --all-namespaces -o yaml

      Examinez le résultat et inspectez les journaux de tous les DaemonSets suspects.

    3. Pour les clusters standards, inspectez directement le fichier de configuration. L'accès SSH et l'inspection manuelle des fichiers ne sont pas possibles dans les clusters Autopilot, car Google gère la configuration du runtime. Signalez les problèmes d'exécution persistants à l'assistance Google Cloud Customer Care.

      Si vous utilisez un cluster standard, inspectez le fichier :

      1. Connectez-vous au nœud à l'aide de SSH :

        gcloud compute ssh NODE_NAME \
    --zone ZONE \
    --project PROJECT_ID

        Remplacez les éléments suivants :

        • NODE_NAME : nom du nœud auquel se connecter.
        • ZONE : zone Compute Engine du nœud.
        • PROJECT_ID : ID de votre projet.

      2. Affichez le contenu du fichier de configuration containerd :

        sudo cat /etc/containerd/config.toml

      3. Pour vérifier les modifications récentes, listez les détails du fichier :

        ls -l /etc/containerd/config.toml

    4. Comparez le contenu de ce fichier à la sortie containerdConfig de la commande gcloud node-pools describe que vous avez exécutée à l'étape précédente. Tout paramètre de /etc/containerd/config.toml qui ne figure pas dans le résultat gcloud est une modification non gérée.

    5. Pour corriger toute erreur de configuration, supprimez toutes les modifications qui n'ont pas été appliquées via une configuration de système de nœuds.

  3. Résoudre les problèmes d'exécution courants : pour connaître d'autres étapes de dépannage, consultez Résoudre les problèmes liés à l'environnement d'exécution du conteneur.

Résoudre les problèmes liés à l'espace de noms kube-node-lease

Les ressources de l'espace de noms kube-node-lease sont chargées de maintenir l'état des nœuds. Cet espace de noms ne doit pas être supprimé. Toute tentative de suppression de cet espace de noms entraîne son blocage à l'état Terminating. Lorsque l'espace de noms kube-node-lease est bloqué à l'état Terminating, les kubelets ne peuvent pas renouveler leurs baux de vérification de l'état. Ce problème entraîne la considération des nœuds comme non opérationnels par le plan de contrôle, ce qui conduit à un problème à l'échelle du cluster où les nœuds alternent entre les états Ready et NotReady.

Symptômes :

Si vous constatez les symptômes suivants, il est probable qu'un problème lié à l'espace de noms kube-node-lease soit à l'origine de l'instabilité du cluster :

  • Les journaux kubelet de chaque nœud affichent des erreurs persistantes semblables à celles-ci :

    leases.coordination.k8s.io NODE_NAME is forbidden: unable to create new content in namespace kube-node-lease because it is being terminated

  • Les nœuds du cluster alternent à plusieurs reprises entre les états Ready et NotReady.

Cause :

L'espace de noms kube-node-lease, qui gère les battements de cœur des nœuds, est anormalement bloqué à l'état Terminating. Cette erreur empêche le serveur d'API Kubernetes d'autoriser la création ou la modification d'objets dans l'espace de noms. Par conséquent, les kubelets ne peuvent pas renouveler leurs objets Lease, qui sont essentiels pour signaler leur état actif au plan de contrôle. Sans ces mises à jour de l'état, le plan de contrôle ne peut pas confirmer que les nœuds sont opérationnels, ce qui entraîne une alternance de leur état entre Ready et NotReady.

Voici les raisons sous-jacentes pour lesquelles l'espace de noms kube-node-lease lui-même peut rester bloqué à l'état Terminating :

  • Ressources avec des finaliseurs : bien que moins courant pour l'espace de noms système kube-node-lease (qui contient principalement des objets Lease), une ressource peut avoir un finaliseur. Les finaliseurs Kubernetes sont des clés qui indiquent qu'un contrôleur doit effectuer des tâches de nettoyage avant qu'une ressource puisse être supprimée. Si le contrôleur responsable de la suppression du finaliseur ne fonctionne pas correctement, la ressource n'est pas supprimée et le processus de suppression de l'espace de noms est interrompu.
  • Services d'API agrégés non opérationnels ou ne répondant pas : la suppression de l'espace de noms peut être bloquée si un objet APIService, utilisé pour enregistrer un serveur d'API agrégé, est associé à l'espace de noms et devient non opérationnel. Le plan de contrôle peut attendre que le serveur d'API agrégé soit correctement arrêté ou nettoyé, ce qui ne se produira pas si le service ne répond pas.
  • Problèmes liés au plan de contrôle ou au contrôleur : dans de rares cas, des bugs ou des problèmes au sein du plan de contrôle Kubernetes, en particulier le contrôleur d'espace de noms, peuvent empêcher la suppression et la récupération des espaces de noms.

Solution :

Suivez les conseils de Résoudre les problèmes liés à un espace de noms bloqué à l'état "Arrêt en cours".

résoudre les problèmes de connectivité réseau

Les problèmes de réseau peuvent empêcher un nœud de communiquer avec le plan de contrôle ou empêcher le fonctionnement de composants critiques tels que le plug-in CNI, ce qui entraîne un état NotReady.

Symptômes :

Si vous constatez les symptômes suivants, il est possible que des problèmes de réseau soient à l'origine de l'état NotReady de vos nœuds :

  • La condition NetworkNotReady est True.
  • Les journaux kubelet du nœud affichent des erreurs semblables à celles-ci :
    • connection timeout to the control plane IP address
    • network plugin not ready
    • CNI plugin not initialized
    • Messages connection refused ou timeout lorsque vous essayez d'accéder à l'adresse IP du plan de contrôle.
  • Les pods, en particulier dans l'espace de noms kube-system, sont bloqués dans l'état ContainerCreating avec des événements tels que NetworkPluginNotReady.

Cause :

Les symptômes liés au réseau indiquent généralement une défaillance dans l'un des domaines suivants :

  • Problèmes de connectivité : le nœud ne parvient pas à établir une connexion réseau stable avec le plan de contrôle Kubernetes.
  • Échec du plug-in CNI : le plug-in CNI, qui est responsable de la configuration de la mise en réseau des pods, ne s'exécute pas correctement ou n'a pas pu s'initialiser.
  • Problèmes liés aux webhooks : des webhooks d'admission mal configurés peuvent interférer avec les ressources liées au plug-in CNI, ce qui empêche la configuration correcte du réseau.

Solution :

Pour résoudre les problèmes de réseau, procédez comme suit :

  1. Résoudre l'état NetworkNotReady transitoire : il est normal d'observer un bref événement NetworkNotReady sur les nœuds nouvellement créés. Cet état devrait être résolu en une ou deux minutes pendant que le plug-in CNI et d'autres composants s'initialisent. Si l'état persiste, suivez les étapes ci-dessous.

  2. Vérifiez la connectivité entre le nœud et le plan de contrôle, ainsi que les règles de pare-feu : assurez-vous que le chemin réseau entre votre nœud et le plan de contrôle est ouvert et fonctionne correctement :

    1. Vérifiez les règles de pare-feu : assurez-vous que vos règles de pare-feu VPC autorisent le trafic nécessaire entre vos nœuds GKE et le plan de contrôle. Pour en savoir plus sur les règles requises par GKE pour la communication entre les nœuds et le plan de contrôle, consultez Règles de pare-feu créées automatiquement.
    2. Tester la connectivité : utilisez le test de connectivité dans Network Intelligence Center pour vérifier le chemin réseau entre l'adresse IP interne du nœud et l'adresse IP du point de terminaison du plan de contrôle sur le port 443. Un résultat de Not Reachable vous aide souvent à identifier la règle de pare-feu ou le problème de routage qui bloque la communication.

  3. Examiner l'état et les journaux du plug-in CNI : si le réseau du nœud n'est pas prêt, le plug-in CNI peut être en cause.

    1. Vérifiez l'état des pods CNI : identifiez le plug-in CNI utilisé (par exemple, netd ou calico-node), puis vérifiez l'état de ses pods dans l'espace de noms kube-system. Vous pouvez filtrer le nœud spécifique à l'aide de la commande suivante :

      kubectl get pods \
    -n kube-system \
    -o wide \
    --field-selector spec.nodeName=NODE_NAME \
    | grep -E "netd|calico|anetd"

    2. Examinez les journaux des pods CNI : si les pods ne fonctionnent pas correctement, examinez leurs journaux dans Cloud Logging pour obtenir des messages d'erreur détaillés. Utilisez une requête semblable à la suivante pour les pods netd sur un nœud spécifique :

      resource.type="k8s_container"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
resource.labels.namespace_name="kube-system"
labels."k8s-pod/app"="netd"
resource.labels.node_name="NODE_NAME"
severity>=WARNING

    3. Résolvez les erreurs de CNI spécifiques :

      • Si les journaux affichent Failed to allocate IP address, il est possible que vos plages d'adresses IP de pods soient épuisées. Vérifiez l'utilisation des adresses IP de vos pods et examinez les plages CIDR de votre cluster.
      • Si les journaux affichent NetworkPluginNotReady ou cni plugin not initialized, vérifiez que le nœud dispose de suffisamment de ressources processeur et de mémoire. Vous pouvez également essayer de redémarrer le pod CNI en le supprimant, ce qui permet au DaemonSet de le recréer.
      • Si vous utilisez GKE Dataplane V2 et que les journaux affichent Cilium API client timeout exceeded, redémarrez le pod anetd sur le nœud.

    4. Vérifiez la présence éventuelle d'interférences sur le webhook d'admission : des webhooks défectueux peuvent empêcher le démarrage des pods CNI, ce qui laisse le nœud dans un état NetworkNotReady.

    5. Vérifiez les journaux du serveur d'API : examinez les journaux du serveur d'API dans Cloud Logging pour détecter les erreurs liées aux appels de webhook. Pour identifier si un webhook bloque la création de ressources CNI, recherchez des messages tels que failed calling webhook.

      Si un webhook pose problème, vous devrez peut-être identifier le ValidatingWebhookConfiguration ou le MutatingWebhookConfiguration problématique et le désactiver temporairement pour que le nœud devienne prêt. Pour en savoir plus, consultez Résoudre les problèmes causés par les webhooks d'admission.

Résoudre les problèmes de configuration incorrecte des clusters

Les sections suivantes vous aident à auditer certaines configurations à l'échelle du cluster qui pourraient interférer avec le fonctionnement normal des nœuds.

Résoudre les problèmes causés par les webhooks d'admission

Un webhook d'admission mal configuré, indisponible ou trop lent peut bloquer les requêtes API critiques, empêchant ainsi le démarrage des composants essentiels ou l'ajout de nœuds au cluster.

Symptômes :

Si vous observez les symptômes suivants, il est probable qu'un webhook d'admission mal configuré ou indisponible bloque les opérations essentielles du cluster :

  • Les pods, en particulier ceux de l'espace de noms kube-system (comme les pods CNI ou de stockage), sont bloqués à l'état Pending ou Terminating.
  • Les nouveaux nœuds ne parviennent pas à rejoindre le cluster et expirent souvent avec un état NotReady.

Cause :

Des webhooks d'admission mal configurés ou ne répondant pas peuvent bloquer des opérations de cluster essentielles.

Solution :

Vérifiez vos configurations de webhook pour vous assurer qu'elles sont résilientes et correctement définies. Pour éviter les pannes, définissez le champ failurePolicy sur Ignore pour les Webhooks non critiques. Pour les webhooks critiques, assurez-vous que leur service sous-jacent est disponibilité élevée et excluez l'espace de noms kube-system de la supervision des webhooks en utilisant un namespaceSelector pour éviter les blocages du plan de contrôle. Pour en savoir plus, consultez Garantir la stabilité du plan de contrôle lors de l'utilisation de webhooks.

Résoudre les problèmes causés par les quotas de ressources

Une quota de ressources mal calculé dans l'espace de noms kube-system peut empêcher GKE de créer des pods système critiques. Étant donné que des composants tels que la mise en réseau (CNI) et le DNS sont bloqués, ce problème peut empêcher de nouveaux nœuds de rejoindre le cluster.

Symptômes :

  • Les pods critiques de l'espace de noms kube-system (par exemple, netd, konnectivity-agent ou kube-dns) sont bloqués à l'état Pending.
  • Les messages d'erreur dans les journaux du cluster ou la sortie kubectl describe pod indiquent des échecs tels que exceeded quota: gcp-critical-pods.

Cause :

Ce problème se produit lorsque le contrôleur de quota de ressources Kubernetes cesse de mettre à jour avec précision le nombre utilisé dans les objets ResourceQuota. Une cause fréquente est un webhook d'admission tiers défectueux qui bloque les mises à jour du contrôleur, ce qui fait apparaître l'utilisation du quota comme beaucoup plus élevée qu'elle ne l'est en réalité.

Solution :

  1. Étant donné qu'un webhook problématique est la cause racine la plus probable, suivez les instructions de la section Résoudre les problèmes causés par les webhooks d'admission pour identifier et corriger les webhooks qui pourraient bloquer les composants système. La résolution du problème de webhook permet souvent de résoudre automatiquement le problème de quota.

  2. Vérifiez que l'utilisation enregistrée du quota n'est pas synchronisée avec le nombre réel de pods en cours d'exécution. Cette étape permet de vérifier si le nombre d'objets ResourceQuota est incorrect :

    1. Vérifiez l'utilisation du quota signalée :

      kubectl get resourcequota gcp-critical-pods -n kube-system -o yaml

    2. Vérifiez le nombre réel de pods :

      kubectl get pods -n kube-system --no-headers | wc -l

  3. Si le nombre utilisé dans ResourceQuota semble incorrect (par exemple, beaucoup plus élevé que le nombre réel de pods), supprimez l'objet gcp-critical-pods. Le plan de contrôle GKE est conçu pour recréer automatiquement cet objet avec les nombres d'utilisation corrects et réconciliés :

    kubectl delete resourcequota gcp-critical-pods -n kube-system

  4. Surveillez l'espace de noms kube-system pendant quelques minutes pour vous assurer que l'objet est recréé et que la planification des pods en attente commence.

Résoudre les problèmes causés par les DaemonSets tiers

Un DaemonSet tiers nouvellement déployé ou mis à jour, souvent utilisé pour la sécurité, la surveillance ou la journalisation, peut parfois entraîner l'instabilité des nœuds. Ce problème peut se produire si le DaemonSet interfère avec le runtime ou la mise en réseau du conteneur du nœud, consomme des ressources système excessives ou apporte des modifications système inattendues.

Symptômes :

Si vous constatez les symptômes suivants, un DaemonSet tiers récemment déployé ou modifié peut être à l'origine des défaillances de nœuds :

  • Plusieurs nœuds, potentiellement dans l'ensemble du cluster, passent à l'état NotReady peu de temps après le déploiement ou la mise à jour du DaemonSet.
  • Les journaux kubelet des nœuds concernés signalent des erreurs telles que les suivantes :
    • container runtime is down
    • Failed to create pod sandbox
    • Erreurs de connexion au socket de l'environnement d'exécution du conteneur (par exemple, /run/containerd/containerd.sock).
  • Les pods, y compris les pods système ou les propres pods du DaemonSet, sont bloqués dans les états PodInitializing ou ContainerCreating.
  • Les journaux de conteneur des applications affichent des erreurs inhabituelles, comme exec format error.
  • Le détecteur de problèmes de nœuds peut signaler des conditions liées à l'état de l'exécution ou à la pression exercée sur les ressources.

Cause :

Le DaemonSet tiers peut affecter la stabilité des nœuds pour les raisons suivantes :

  • Consommer trop de ressources processeur, de mémoire ou d'E/S disque, ce qui affecte les performances des composants de nœud critiques.
  • Interférer avec le fonctionnement de l'environnement d'exécution du conteneur.
  • Cela peut entraîner des conflits avec la configuration réseau du nœud ou le plug-in CNI (Container Network Interface).
  • Modification involontaire des configurations système ou des règles de sécurité.

Solution :

Pour déterminer si un DaemonSet est à l'origine du problème, isolez-le et testez-le :

  1. Identifier les DaemonSets : listez tous les DaemonSets en cours d'exécution dans votre cluster :

    kubectl get daemonsets --all-namespaces

    Portez une attention particulière aux DaemonSets qui ne font pas partie de l'installation GKE par défaut.

    Vous pouvez souvent identifier ces DaemonSets en examinant les éléments suivants :

    • Espace de noms : les composants GKE par défaut s'exécutent généralement dans l'espace de noms kube-system. Les DaemonSets dans d'autres espaces de noms sont probablement tiers ou personnalisés.
    • Nommage : les DaemonSets par défaut ont souvent des noms tels que gke-metrics-agent, netd ou calico-node. Les agents tiers ont souvent des noms qui reflètent le produit.

  2. Corréler le temps de déploiement : vérifiez si l'apparition des nœuds NotReady coïncide avec le déploiement ou la mise à jour d'un DaemonSet tiers spécifique.

  3. Test sur un seul nœud :

    1. Choisissez un nœud concerné.
    2. Marquez comme non ordonnançable et drainez le nœud.
    3. Empêchez temporairement le DaemonSet de planifier sur ce nœud :
      • Appliquez un libellé de nœud temporaire et configurez l'affinité ou l'anti-affinité de nœuds dans le fichier manifeste du DaemonSet.
      • Supprimez le pod du DaemonSet sur ce nœud spécifique.
    4. Redémarrez l'instance de machine virtuelle du nœud.
    5. Vérifiez si le nœud devient Ready et reste stable lorsque le DaemonSet n'y est pas exécuté. Si les problèmes réapparaissent après la réintroduction du DaemonSet, il est probable qu'il soit en cause.

  4. Consultez le fournisseur : si vous pensez qu'un agent tiers est à l'origine du problème, consultez la documentation du fournisseur pour connaître les problèmes de compatibilité connus ou les bonnes pratiques pour exécuter l'agent sur GKE. Si vous avez besoin d'aide, contactez le fournisseur du logiciel.

Vérifier que le nœud a été récupéré

Après avoir appliqué une solution potentielle, procédez comme suit pour vérifier que le nœud a bien été récupéré et qu'il est stable :

  1. Vérifiez l'état du nœud :

    kubectl get nodes -o wide

    Recherchez le nœud concerné dans le résultat. La colonne Status devrait maintenant afficher la valeur Ready. La mise à jour de l'état peut prendre quelques minutes après l'application de la correction. Si l'état indique toujours NotReady ou s'il alterne entre plusieurs états, cela signifie que le problème n'est pas entièrement résolu.

  2. Inspectez la section Conditions du nœud :

    kubectl describe node NODE_NAME

    Dans la section Conditions, vérifiez les valeurs suivantes :

    • L'état de la condition Ready est True.
    • Les conditions négatives qui étaient auparavant à l'état True (par exemple, MemoryPressure ou NetworkUnavailable) sont désormais à l'état False. Les champs Reason et Message de ces conditions doivent indiquer que le problème est résolu.

  3. Testez la planification des pods. Si le nœud n'était pas en mesure d'exécuter des charges de travail auparavant, vérifiez si de nouveaux pods y sont planifiés et si les pods existants s'exécutent sans problème :

    kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE_NAME

    Les pods du nœud doivent avoir l'état Running ou Completed. Vous ne devriez pas voir de pods bloqués dans l'état Pending ni dans d'autres états d'erreur.

Étapes suivantes