Fehlerbehebung bei Knoten mit dem Status „NotReady“ in GKE

Der Status NotReady in Google Kubernetes Engine (GKE) bedeutet, dass das Kubelet des Knotens nicht korrekt an die Steuerungsebene meldet. Da Kubernetes keine neuen Pods auf einem NotReady-Knoten plant, kann dieses Problem die Anwendungskapazität verringern und zu Ausfallzeiten führen.

In diesem Dokument erfahren Sie, wie Sie zwischen erwarteten NotReady-Status und tatsächlichen Problemen unterscheiden, die Ursache diagnostizieren und Lösungen für häufige Probleme wie Ressourcenerschöpfung, Netzwerkprobleme und Containerlaufzeitfehler finden.

Diese Informationen richten sich an Plattformadministratoren und ‑betreiber, die für die Clusterstabilität verantwortlich sind, sowie an Anwendungsentwickler, die das infrastrukturbezogene Anwendungsverhalten nachvollziehen möchten. Weitere Informationen zu den gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Hinweise

  • Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für das Google Cloud -Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Ausführen der Aufgaben in diesem Dokument benötigen:

    Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

    Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

  • Konfigurieren Sie das kubectl-Befehlszeilentool für die Kommunikation mit Ihrem GKE-Cluster:

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

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name Ihres Clusters.
    • LOCATION: die Compute Engine-Region oder -Zone (z. B. us-central1 oder us-central1-a) für den Cluster.
    • PROJECT_ID: Projekt-ID in Google Cloud .

Status und Bedingungen des Knotens prüfen

So prüfen Sie, ob ein Knoten den Status NotReady hat, und ermitteln die Ursache:

  1. Status Ihrer Knoten ansehen Verwenden Sie das Flag -o wide, um zusätzliche Details wie IP-Adressen und Kernel-Versionen zu erhalten, die für die Diagnose hilfreich sind:

    kubectl get nodes -o wide

    Die Ausgabe sieht etwa so aus:

    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

    Suchen Sie in der Ausgabe nach Knoten mit dem Wert NotReady in der Spalte STATUS und notieren Sie sich ihre Namen.

  2. Weitere Informationen zu bestimmten Knoten mit dem Status NotReady, einschließlich ihrer Bedingungen und aller aktuellen Kubernetes-Ereignisse, finden Sie hier:

    kubectl describe node NODE_NAME

    Ersetzen Sie NODE_NAME durch den Namen eines Knotens mit dem Status NotReady.

    Konzentrieren Sie sich in der Ausgabe auf den Abschnitt Conditions, um den Zustand des Knotens zu ermitteln, und auf den Abschnitt Events, um den Verlauf der letzten Probleme zu sehen. Beispiel:

    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

    Im Abschnitt Conditions weist ein Status von True für eine negative Bedingung oder Unknown für die Bedingung Ready auf ein Problem hin. Achten Sie bei diesen Bedingungen genau auf die Felder Reason und Message, da sie die Ursache des Problems erläutern.

    Bedeutung der einzelnen Bedingungstypen:

    • KernelDeadlock: True, wenn der Betriebssystemkernel des Knotens einen Deadlock erkannt hat. Dies ist ein schwerwiegender Fehler, der dazu führen kann, dass der Knoten nicht mehr reagiert.
    • FrequentUnregisterNetDevice: True, wenn die Registrierung der Netzwerkgeräte des Knotens häufig aufgehoben wird. Dies kann ein Zeichen für Treiber- oder Hardwareprobleme sein.
    • NetworkUnavailable: True, wenn die Netzwerkeinstellungen für den Knoten nicht richtig konfiguriert sind.
    • OutOfDisk: True, wenn der verfügbare Speicherplatz vollständig erschöpft ist. Dieser Zustand ist schwerwiegender als DiskPressure.
    • MemoryPressure: True, wenn der Knotenspeicherplatz gering ist.
    • DiskPressure: True, wenn der Speicherplatz auf dem Knoten gering ist.
    • PIDPressure: True, wenn auf dem Knoten die Prozess-ID (PID) erschöpft ist.
    • Ready: Gibt an, ob der Knoten fehlerfrei und bereit ist, Pods zu akzeptieren.
      • True, wenn der Knoten fehlerfrei ist.
      • False, wenn der Knoten fehlerhaft ist und keine Pods akzeptiert.
      • Unknown, wenn der Knotencontroller innerhalb eines Kulanzzeitraums (standardmäßig 50 Sekunden) keine Antwort vom Knoten erhalten hat und der Knotenstatus unbekannt ist.

    Sehen Sie sich als Nächstes den Bereich Events an. Dort finden Sie ein chronologisches Log mit Aktionen und Beobachtungen zum Knoten. Diese Zeitachse ist wichtig, um zu verstehen, was unmittelbar vor dem NotReady-Status des Knotens passiert ist. Suchen Sie nach bestimmten Meldungen, die Ihnen helfen können, die Ursache zu finden, z. B. Warnungen vor dem Entfernen von Pods (die auf Ressourcenengpässe hinweisen), fehlgeschlagene Health Checks oder Ereignisse im Knotenlebenszyklus wie das Sperren von Knoten für eine Reparatur.

  3. Weitere Informationen dazu, warum Knoten den Status NotReady haben, finden Sie in den Logs des Knotens und seiner Komponenten.

    1. Prüfen Sie die kubelet-Logs auf den Status NotReady.

      Der kubelet ist der primäre Agent, der den Status des Knotens an die Steuerungsebene meldet. In seinen Logs finden Sie daher am ehesten die Meldung NotReady. Diese Logs sind die maßgebliche Quelle für die Diagnose von Problemen mit Pod-Lebenszyklusereignissen, Bedingungen für Ressourcenengpässe (z. B. MemoryPressure oder DiskPressure) und der Verbindung des Knotens zur Kubernetes-Steuerungsebene.

    2. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf:

      Zum Log-Explorer

    3. Geben Sie im Bereich „Abfrage“ die folgende Abfrage ein:

      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"

      Ersetzen Sie Folgendes:

      • NODE_NAME: der Name des Knotens, den Sie untersuchen.
      • CLUSTER_NAME: Der Name Ihres Clusters.
      • LOCATION: die Compute Engine-Region oder -Zone (z. B. us-central1 oder us-central1-a) für den Cluster.

    4. Klicken Sie auf Abfrage ausführen und sehen Sie sich die Ergebnisse an.

    5. Wenn die kubelet-Logs die Ursache nicht erkennen lassen, prüfen Sie die container-runtime- und node-problem-detector-Logs. Diese Komponenten protokollieren den NotReady-Status möglicherweise nicht direkt, aber oft das zugrunde liegende Problem (z. B. einen Laufzeitfehler oder eine Kernel-Panik), das das Problem verursacht hat.

    6. Geben Sie im Abfragebereich des Log-Explorers die folgende Abfrage ein:

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

      Ersetzen Sie COMPONENT_NAME durch einen der folgenden Werte:

      • container-runtime: Die Laufzeit (containerd), die für den gesamten Containerlebenszyklus verantwortlich ist, einschließlich des Abrufens von Images und der Verwaltung der Containerausführung. Die Überprüfung der container-runtime-Logs ist unerlässlich, um Fehler im Zusammenhang mit der Containerinstanziierung, Laufzeitdienstfehler oder Probleme zu beheben, die durch die Konfiguration der Laufzeit verursacht werden.
      • node-problem-detector: Ein Dienstprogramm, das proaktiv eine Vielzahl von Problemen auf Knotenebene überwacht und an die Steuerungsebene meldet. Die zugehörigen Logs sind wichtig, um zugrunde liegende Systemprobleme zu identifizieren, die zu Knoteninstabilität führen können, z. B. Kernel-Deadlocks, Beschädigungen des Dateisystems oder Hardwarefehler. Diese werden möglicherweise nicht von anderen Kubernetes-Komponenten erfasst.

    7. Klicken Sie auf Abfrage ausführen und sehen Sie sich die Ergebnisse an.

  4. Suchen Sie mit dem Metrics Explorer nach einer Ressourcenerschöpfung um den Zeitpunkt, zu dem der Knoten NotReady wurde:

    1. Rufen Sie in der Google Cloud Console die Seite Metrics Explorer auf:

      Zum Metrics Explorer

    2. Prüfen Sie im Metrics Explorer, ob die zugrunde liegende Compute Engine-Instanz des Knotens Ressourcen erschöpft hat. Konzentrieren Sie sich auf Messwerte für CPU, Arbeitsspeicher und Festplatten-E/A. Beispiel:

      • GKE-Knotenmesswerte: Beginnen Sie mit Messwerten, denen das Präfix kubernetes.io/node/ vorangestellt ist, z. B. kubernetes.io/node/cpu/allocatable_utilization oder kubernetes.io/node/memory/allocatable_utilization. Diese Messwerte zeigen, wie viele der verfügbaren Ressourcen des Knotens von Ihren Pods verwendet werden. Der verfügbare Betrag enthält nicht die Ressourcen, die Kubernetes für den System-Overhead reserviert.
      • Messwerte des Gastbetriebssystems: Wenn Sie eine Ansicht aus dem Betriebssystem des Knotens benötigen, verwenden Sie Messwerte mit dem Präfix compute.googleapis.com/guest/, z. B. compute.googleapis.com/guest/cpu/usage oder compute.googleapis.com/guest/memory/bytes_used.
      • Hypervisor-Messwerte: Wenn Sie die Leistung der VM auf Hypervisor-Ebene sehen möchten, verwenden Sie Messwerte mit dem Präfix compute.googleapis.com/instance/, z. B. compute.googleapis.com/instance/cpu/utilization oder Messwerte für Laufwerk-E/A wie compute.googleapis.com/instance/disk/read_bytes_count.

      Für die Gastbetriebssystem- und Hypervisor-Messwerte müssen Sie nach dem Namen der zugrunde liegenden Compute Engine-Instanz filtern, nicht nach dem Kubernetes-Knotennamen. Sie können den Instanznamen für einen Knoten ermitteln, indem Sie den Befehl kubectl describe node NODE_NAME ausführen und in der Ausgabe nach dem Feld ProviderID suchen. Der Instanzname ist der letzte Teil dieses Werts. Beispiel:

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

      In diesem Beispiel lautet der Instanzname gke-my-cluster-default-pool-1234abcd-5678.

Ursache anhand des Symptoms ermitteln

Wenn Sie ein bestimmtes Symptom wie eine Log-Nachricht, einen Knotenstatus oder ein Clusterereignis identifiziert haben, finden Sie in der folgenden Tabelle Tipps zur Fehlerbehebung:

Kategorie Symptom oder Log-Meldung Mögliche Ursache Schritte zur Fehlerbehebung
Knotenbedingungen NetworkUnavailable: True Problem mit der Verbindung vom Knoten zur Steuerungsebene oder Fehler beim CNI-Plug-in (Container Network Interface). Fehlerbehebung bei Netzwerkverbindungen
MemoryPressure: True Auf dem Knoten ist nicht genügend Arbeitsspeicher verfügbar. Fehlerbehebung bei Ressourcenmangel auf Knoten
DiskPressure: True Auf dem Knoten ist nicht genügend Speicherplatz vorhanden. Fehlerbehebung bei Ressourcenmangel auf Knoten
PIDPressure: True Auf dem Knoten sind nicht genügend Prozess-IDs verfügbar. Fehlerbehebung bei Ressourcenmangel auf Knoten
Ereignisse und Protokollnachrichten PLEG is not healthy Kubelet ist aufgrund einer hohen CPU-/E/A-Auslastung oder zu vieler Pods überlastet. Probleme mit PLEG beheben
Out of memory: Kill process
sys oom event		 Der Knotenspeicher ist vollständig belegt. OOM-Ereignisse auf Systemebene beheben
leases.coordination.k8s.io...is forbidden Der Namespace kube-node-lease hängt in der Beendigungsphase fest. Probleme mit dem Namespace kube-node-lease beheben
Container runtime not ready
runtime is down
Fehler mit Verweis auf /run/containerd/containerd.sock oder docker.sock		 Der containerd- oder Docker-Dienst ist fehlgeschlagen oder falsch konfiguriert. Probleme mit der Containerlaufzeit beheben
Pods bleiben im Status Terminating
Kubelet-Logs zeigen DeadlineExceeded für „kill container“
containerd-Logs zeigen wiederholte Kill container-Meldungen		 Prozesse, die im unterbrechungsfreien Laufwerk-Ruhezustand (D-Status) hängen bleiben, was häufig mit E/A zusammenhängt. Im D-Status hängende Prozesse beheben
Symptome auf Clusterebene Mehrere Knoten fallen nach einem DaemonSet-Roll-out aus. Das DaemonSet beeinträchtigt den Knotenbetrieb. Probleme beheben, die durch DaemonSets von Drittanbietern verursacht werden
compute.instances.preempted in Audit-Logs. Die Spot-VM wurde vorzeitig beendet. Das ist das erwartete Verhalten. Knoten-Preemption bestätigen
kube-system Pods bleiben in Pending hängen. Der Zugangs-Webhook blockiert kritische Komponenten. Probleme beheben, die durch Zulassungs-Webhooks verursacht werden
exceeded quota: gcp-critical-pods Ein falsch konfiguriertes Kontingent blockiert System-Pods. Probleme aufgrund von Ressourcenkontingenten beheben

Nach erwarteten NotReady-Ereignissen suchen

Ein NotReady-Status weist nicht immer auf ein Problem hin. Das kann bei geplanten Vorgängen wie einem Knotenpool-Upgrade oder bei Verwendung bestimmter Arten von virtuellen Maschinen zu erwarten sein.

Knotenlebenszyklusvorgänge bestätigen

Symptome:

Ein Knoten hat während bestimmter Lebenszyklusereignisse vorübergehend den Status NotReady.

Ursache:

Der Status eines Knotens wird vorübergehend zu NotReady, wenn bestimmte Lebenszyklusereignisse eintreten. Dieses Verhalten ist zu erwarten, wenn ein Knoten erstellt oder neu erstellt wird, z. B. in den folgenden Szenarien:

  • Knotenpool-Upgrades: Während eines Upgrades wird jeder Knoten geleert und ersetzt. Der neue, aktualisierte Knoten hat den Status NotReady, bis die Initialisierung abgeschlossen ist und er dem Cluster beitritt.
  • Automatische Reparatur von Knoten: Wenn GKE einen fehlerhaften Knoten ersetzt, bleibt der Ersatzknoten während der Bereitstellung NotReady.
  • Hochskalierung durch Cluster Autoscaler: Wenn neue Knoten hinzugefügt werden, haben sie zuerst den Status NotReady und werden erst dann zu Ready, wenn sie vollständig bereitgestellt wurden und dem Cluster beigetreten sind.
  • Manuelle Änderungen an Instanzvorlagen: GKE erstellt die Knoten neu, wenn Sie Änderungen an der Vorlage vornehmen. Der neue Knoten hat während der Startphase den Status NotReady.

Lösung:

Knoten sollten den Status NotReady nur kurz haben. Wenn der Status länger als 10 Minuten andauert, sollten Sie andere Ursachen in Betracht ziehen.

Knoten-Preemption bestätigen

Wenn Ihr Knoten auf einer Spot-VM oder einer VM auf Abruf ausgeführt wird, kann Compute Engine ihn abrupt beenden, um Ressourcen zurückzugewinnen. Dies ist das erwartete Verhalten für diese Arten von kurzlebigen virtuellen Maschinen und kein Fehler.

Symptome:

Wenn Sie die folgenden Symptome beobachten, wird der Status NotReady des Knotens wahrscheinlich durch eine erwartete vorzeitige Beendigung der Spot-VM verursacht:

  • Ein Knoten wechselt unerwartet in den Status NotReady, bevor er vom Cluster Autoscaler gelöscht und neu erstellt wird.
  • In Cloud-Audit-Logs wird ein compute.instances.preempted-Ereignis für die zugrunde liegende VM-Instanz angezeigt.

Ursache:

Der Knoten wurde auf einer Spot-VM- oder VM-Instanz auf Abruf ausgeführt und Compute Engine hat diese Rechenressourcen für eine andere Aufgabe zurückgefordert. Spot-VMs können jederzeit unterbrochen werden. In der Regel erhalten Sie jedoch einen 30-sekündigen Beendigungshinweis.

Lösung:

Verwenden Sie Spot-VMs oder VMs auf Abruf nur für fehlertolerante, zustandslose oder Batch-Arbeitslasten, die so konzipiert sind, dass sie häufige Beendigungen problemlos verarbeiten können. Für Produktions- oder zustandsorientierte Arbeitslasten, die keine plötzlichen Unterbrechungen tolerieren können, stellen Sie Ihre Knotenpools mit Standard-On-Demand-VMs bereit.

Probleme mit Ressourcenmangel bei Knoten beheben

Ein Knoten wird oft NotReady, weil ihm wichtige Ressourcen wie CPU, Arbeitsspeicher oder Speicherplatz fehlen. Wenn einem Knoten nicht genügend dieser Ressourcen zur Verfügung stehen, können kritische Komponenten nicht richtig funktionieren, was zu Anwendungsinstabilität und Reaktionslosigkeit des Knotens führt. In den folgenden Abschnitten wird beschrieben, wie sich diese Engpässe äußern können – von allgemeinen Druckbedingungen bis hin zu schwerwiegenderen systemweiten Ereignissen.

Knotenressourcenbelastung beheben

Ressourcenerschöpfung tritt auf, wenn einem Knoten nicht genügend CPU, Arbeitsspeicher, Speicherplatz oder Prozess-IDs (PIDs) zum Ausführen seiner Arbeitslasten zur Verfügung stehen. Dieses Problem kann zum Status NotReady führen.

Symptome:

Wenn Sie die folgenden Knotenbedingungen und Logs beobachten, ist die wahrscheinliche Ursache für den NotReady-Status des Knotens eine Ressourcenerschöpfung:

  • In der Ausgabe des Befehls kubectl describe node wird für Bedingungen wie OutOfDisk, MemoryPressure, DiskPressure oder PIDPressure der Status True angezeigt.
  • Die kubelet-Logs enthalten möglicherweise OOM-Ereignisse (Out of Memory), die darauf hinweisen, dass der OOM Killer des Systems aufgerufen wurde.

Ursache:

Arbeitslasten auf dem Knoten fordern gemeinsam mehr Ressourcen an, als der Knoten bereitstellen kann.

Lösung:

Versuchen Sie für Standardcluster die folgenden Lösungen:

  • Arbeitslastanforderungen reduzieren:
    • Reduzieren Sie die Anzahl der Pods, die auf dem betroffenen Knoten ausgeführt werden, indem Sie die Anzahl der Replikate Ihrer Deployments verringern. Weitere Informationen finden Sie unter Anwendung skalieren.
    • Prüfen und optimieren Sie Ihre Anwendungen, damit sie weniger Ressourcen verbrauchen.
  • Knotenkapazität erhöhen:

Bei Autopilot-Clustern haben Sie keine direkte Kontrolle über die Maschinentypen der Knoten oder die Größen der Startlaufwerke. Die Knotenkapazität wird automatisch basierend auf Ihren Pod-Anforderungen verwaltet. Achten Sie darauf, dass die Ressourcenanforderungen Ihrer Arbeitslast innerhalb der Autopilot-Limits liegen und die Anforderungen Ihrer Anwendung genau widerspiegeln. Anhaltende Ressourcenprobleme können darauf hindeuten, dass Pod-Anfragen optimiert werden müssen. In seltenen Fällen kann es sich auch um ein Plattformproblem handeln, bei dem Unterstützung durch Cloud Customer Care erforderlich ist.

OOM-Ereignisse auf Systemebene beheben

Ein OOM-Ereignis (Out of Memory) auf Systemebene tritt auf, wenn der Gesamtspeicher eines Knotens erschöpft ist. Der Linux-Kernel muss dann Prozesse beenden, um Ressourcen freizugeben. Dieses Ereignis unterscheidet sich von einem OOM-Ereignis auf Containerebene, bei dem ein einzelner Pod seine Arbeitsspeicherlimits überschreitet.

Symptome:

Wenn Sie die folgenden Symptome bemerken, ist ein OOM-Ereignis auf Systemebene wahrscheinlich die Ursache für die Instabilität des Knotens:

  • In den seriellen Konsolenlogs des Knotens wird die Meldung Out of memory: Kill process angezeigt.
  • Die kubelet-Logs enthalten oom_watcher-Ereignisse, die darauf hinweisen, dass das kubelet ein OOM-Ereignis auf Systemebene erkannt hat.
  • Unerwartetes Beenden verschiedener Prozesse, einschließlich potenziell kritischer System-Daemons oder Arbeitslast-Pods, die nicht unbedingt die größten Arbeitsspeicherverbraucher sind.

Ursache:

Der Gesamtspeicher des Knotens ist erschöpft. Dieses Problem kann durch einen Fehler in einem Systemdienst, eine falsch konfigurierte Arbeitslast, die übermäßig viel Arbeitsspeicher verbraucht, oder einen Knoten verursacht werden, der für die kollektiven Arbeitsspeicheranforderungen aller darauf ausgeführten Pods zu klein ist.

Lösung:

Um OOM-Ereignisse auf Systemebene zu beheben, müssen Sie die Ursache ermitteln und dann entweder den Speicherbedarf verringern oder die Knotenkapazität erhöhen. Weitere Informationen finden Sie unter OOM-Ereignisse beheben.

Probleme mit PLEG beheben

Der Pod-Lebenszyklus-Ereignisgenerator (PLEG) ist eine Komponente in kubelet. Es prüft regelmäßig den Status aller Container auf dem Knoten und meldet alle Änderungen an das Kubelet zurück.

Wenn beim PLEG Leistungsprobleme auftreten, kann es dem Kubelet keine rechtzeitigen Updates bereitstellen, was dazu führen kann, dass der Knoten instabil wird.

Symptome:

Wenn Sie die folgenden Symptome bemerken, funktioniert der PLEG möglicherweise nicht richtig:

  • Die Kubelet-Logs für den Knoten enthalten eine Meldung ähnlich der folgenden: PLEG is not healthy.
  • Der Status des Knotens ändert sich häufig zwischen Ready und NotReady.

Ursache:

PLEG-Probleme werden in der Regel durch Leistungsprobleme verursacht, die verhindern, dass das Kubelet rechtzeitig Updates von der Containerlaufzeit erhält. Häufige Ursachen sind:

  • Hohe CPU-Auslastung: Die CPU des Knotens ist ausgelastet, sodass das Kubelet und die Containerlaufzeit nicht die benötigte Rechenleistung haben.
  • E/A-Drosselung: Auf dem Bootlaufwerk des Knotens werden viele E/A-Vorgänge ausgeführt, was alle laufwerkbezogenen Aufgaben verlangsamen kann.
  • Zu viele Pods: Zu viele Pods auf einem einzelnen Knoten können das Kubelet und die Containerlaufzeit überlasten und zu Ressourcenkonflikten führen.

Lösung:

Bei Standardclustern können Sie die Belastung der Knotenressourcen verringern:

Bei Autopilot-Clustern können Sie die Größe oder den Festplattentyp eines vorhandenen Knotens zwar nicht direkt ändern, aber die Hardware, auf der Ihre Arbeitslasten ausgeführt werden, mithilfe von benutzerdefinierten Compute-Klassen beeinflussen. Mit dieser Funktion können Sie Anforderungen in Ihrem Arbeitslastmanifest angeben, z. B. eine Mindestmenge an CPU und Arbeitsspeicher oder eine bestimmte Maschinenserie, um zu steuern, wo Ihre Pods geplant werden.

Wenn Sie keine Compute-Klassen verwenden, passen Sie die Bereitstellungen von Arbeitslasten (z. B. die Anzahl der Replikate und Ressourcenanforderungen oder ‑limits) an und achten Sie darauf, dass sie den Autopilot-Einschränkungen entsprechen. Wenn PLEG-Probleme nach der Optimierung Ihrer Arbeitslasten weiterhin bestehen, wenden Sie sich an den Cloud Customer Care.

Prozesse beheben, die im D-Status hängen geblieben sind

Prozesse, die in einem nicht unterbrechbaren Festplatten-Ruhezustand (D-Status) feststecken, können dazu führen, dass ein Knoten nicht mehr reagiert. Dieses Problem verhindert, dass Pods beendet werden, und kann dazu führen, dass kritische Komponenten wie containerd fehlschlagen, was zu einem NotReady-Status führt.

Symptome:

  • Pods, insbesondere solche, die Netzwerkspeicher wie NFS verwenden, bleiben lange im Status Terminating hängen.
  • In den Kubelet-Logs werden DeadlineExceeded-Fehler angezeigt, wenn versucht wird, einen Container zu stoppen.
  • In den seriellen Konsolenlogs des Knotens werden möglicherweise Kernelmeldungen zu hung tasks oder zu Aufgaben angezeigt, die länger als 120 Sekunden blockiert sind.

Ursache:

Prozesse wechseln in den D-Status, wenn sie auf den Abschluss eines E/A-Vorgangs warten und nicht unterbrochen werden können. Häufige Ursachen sind:

  • Langsame oder nicht reagierende Remote-Dateisysteme, z. B. eine falsch konfigurierte oder überlastete NFS-Freigabe.
  • Erhebliche Beeinträchtigung der Festplattenleistung oder Hardware-E/A-Fehler auf den lokalen Festplatten des Knotens.

Lösung:

Um Probleme mit Prozessen im D-Status zu beheben, müssen Sie die E/A-Quelle ermitteln und den Status dann mit einer der folgenden Optionen löschen:

Standardcluster

  1. Hängenden Prozess suchen und ermitteln, worauf er wartet:

    1. Stellen Sie über SSH eine Verbindung zum betroffenen Knoten her:

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

      Ersetzen Sie Folgendes:

      • NODE_NAME: der Name des Knotens, zu dem eine Verbindung hergestellt werden soll.
      • ZONE: die Compute Engine-Zone des Knotens.
      • PROJECT_ID: Ihre Projekt-ID.

    2. Prozesse im Status „D“ finden:

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

      Die Ausgabe sieht etwa so aus:

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

      Die Ausgabe hat keinen Header. Die Spalten stehen in der Reihenfolge für Folgendes:

      • Bundesland
      • Prozess-ID (PID)
      • Befehl
      • Wartekanal (wchan)

    3. Sehen Sie sich die Spalte wchan an, um die E/A-Quelle zu ermitteln:

      • Wenn die Spalte wchan Begriffe wie nfs oder rpc enthält, wartet der Prozess auf eine NFS-Freigabe.
      • Wenn die Spalte wchan Begriffe wie io_schedule, jbd2 oder ext4 enthält, wartet der Prozess auf das lokale Bootlaufwerk des Knotens.

    4. Weitere Informationen dazu, auf welche Kernelfunktionen der Prozess wartet, finden Sie im Kernel-Callstack des Prozesses:

      cat /proc/PID/stack

      Ersetzen Sie PID durch die Prozess-ID, die Sie im vorherigen Schritt gefunden haben.

  2. Starten Sie den Knoten neu. Ein Neustart ist oft die effektivste Methode, um einen Prozess zu beenden, der im D-Status feststeckt.

    1. Leeren Sie den Knoten.
    2. Löschen Sie die zugrunde liegende VM-Instanz. In der Regel wird von GKE eine neue VM erstellt, um sie zu ersetzen.

  3. Nachdem Sie das unmittelbare Problem behoben haben, untersuchen Sie das zugrunde liegende Speichersystem, um ein erneutes Auftreten zu verhindern.

    • Bei Problemen mit dem Netzwerkspeicher (NFS): Verwenden Sie die Monitoring-Tools Ihres Speicheranbieters, um nach hoher Latenz, serverseitigen Fehlern oder Netzwerkproblemen zwischen dem GKE-Knoten und dem NFS-Server zu suchen.

    • Probleme mit lokalen Festplatten: Prüfen Sie in Cloud Monitoring, ob die E/A-Vorgänge gedrosselt werden. Sehen Sie sich dazu die Messwerte compute.googleapis.com/instance/disk/throttled_read_ops_count und compute.googleapis.com/instance/disk/throttled_write_ops_count für die Compute Engine-Instanz an.

Autopilot-Cluster

  1. Versuchen Sie, die Ursache der Blockierung zu ermitteln:

    Der direkte SSH-Zugriff auf Knoten und das Ausführen von Befehlen wie ps oder cat /proc sind in Autopilot-Clustern nicht verfügbar. Sie müssen sich auf Logs und Messwerte verlassen.

    1. Knotenlogs prüfen: Analysieren Sie in Cloud Logging die Logs des betroffenen Knotens. Nach dem Knotennamen und dem Zeitraum des Problems filtern. Suchen Sie nach Kernel-Meldungen, die auf E/A-Fehler, Speicher-Timeouts (z. B. auf Festplatte oder NFS) oder Meldungen von CSI-Treibern hinweisen.
    2. Arbeitslastlogs prüfen: Untersuchen Sie die Logs der Pods, die auf dem betroffenen Knoten ausgeführt werden. Anwendungsprotokolle können Fehler im Zusammenhang mit Dateivorgängen, Datenbankaufrufen oder dem Zugriff auf Netzwerkspeicher aufdecken.
    3. Cloud Monitoring verwenden: Obwohl Sie keine Details auf Prozessebene erhalten, können Sie nach I/O-Problemen auf Knotenebene suchen.

  2. Lösen Sie einen Knotenaustausch aus, um den Status zu löschen.

    Sie können die zugrunde liegende VM nicht manuell löschen. Um einen Ersatz auszulösen, müssen Sie den Knoten entleeren. Dadurch wird der Knoten isoliert und die Pods werden entfernt.

    GKE erkennt automatisch fehlerhafte Knoten und leitet Reparaturen ein, in der Regel durch Ersetzen der zugrunde liegenden VM.

    Wenn der Knoten nach dem Entleeren weiterhin hängt und nicht automatisch ersetzt wird, wenden Sie sich an den Cloud Customer Care.

  3. Nachdem Sie das unmittelbare Problem behoben haben, untersuchen Sie das zugrunde liegende Speichersystem, um ein erneutes Auftreten zu verhindern.

    • Probleme mit lokalen Festplatten: Prüfen Sie in Cloud Monitoring anhand der Messwerte compute.googleapis.com/instance/disk/throttled_read_ops_count und compute.googleapis.com/instance/disk/throttled_write_ops_count, ob die E/A-Vorgänge gedrosselt werden. Sie können diese Messwerte nach der zugrunde liegenden Instanzgruppe des Knotenpools filtern, obwohl einzelne Instanzen von Google verwaltet werden.
    • Bei Problemen mit dem Netzwerkspeicher (NFS): Verwenden Sie die Monitoring-Tools Ihres Speicheranbieters, um nach hoher Latenz, serverseitigen Fehlern oder Netzwerkproblemen zwischen dem GKE-Knoten und dem NFS-Server zu suchen. Prüfen Sie die Logs von CSI-Treiber-Pods in Cloud Logging.

Fehler bei Kernkomponenten beheben

Wenn Sie erwartete Ursachen und Ressourcenmangel ausgeschlossen haben, ist möglicherweise die Software des Knotens oder ein wichtiger Kubernetes-Mechanismus die Ursache des Problems. Der Status NotReady kann auftreten, wenn eine kritische Komponente wie die Container-Laufzeit ausfällt. Das kann auch passieren, wenn ein wichtiger Kubernetes-Mechanismus für die Systemdiagnose, z. B. das Knotenleasesystem, ausfällt.

Probleme mit der Containerlaufzeit beheben

Probleme mit der Containerlaufzeit, z. B. containerd, können verhindern, dass das kubelet Pods auf einem Knoten startet.

Symptome:

Wenn Sie die folgenden Meldungen in den Kubelet-Logs sehen, ist wahrscheinlich ein Problem mit der Containerlaufzeit die Ursache für den Status NotReady des Knotens:

  • Container runtime not ready
  • Container runtime docker failed!
  • docker daemon exited
  • Fehler beim Herstellen einer Verbindung zum Laufzeitsocket (z. B. unix:///var/run/docker.sock oder unix:///run/containerd/containerd.sock).

Ursache:

Die Containerlaufzeit funktioniert nicht richtig, ist falsch konfiguriert oder befindet sich in einer Neustartschleife.

Lösung:

So beheben Sie Probleme mit der Containerlaufzeit:

  1. Containerlaufzeitprotokolle analysieren:

    1. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.

      Zum Log-Explorer

    2. Wenn Sie alle Warn- und Fehlerlogs der Containerlaufzeit auf dem betroffenen Knoten aufrufen möchten, geben Sie im Abfragebereich Folgendes ein:

      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

      Ersetzen Sie Folgendes:

      • NODE_NAME: der Name des Knotens, den Sie untersuchen.
      • CLUSTER_NAME: Der Name Ihres Clusters.
      • LOCATION: die Compute Engine-Region oder -Zone (z. B. us-central1 oder us-central1-a) für den Cluster.

    3. Klicken Sie auf Abfrage ausführen und prüfen Sie die Ausgabe auf spezifische Fehlermeldungen, die angeben, warum die Laufzeit fehlgeschlagen ist. Eine Meldung wie failed to load TOML in den containerd-Logs in Cloud Logging weist häufig auf eine fehlerhafte Datei hin.

    4. Um zu prüfen, ob die Laufzeit in einer Neustartschleife hängen geblieben ist, führen Sie eine Abfrage aus, die nach Startmeldungen sucht. Eine hohe Anzahl dieser Nachrichten in kurzer Zeit bestätigt häufige Neustarts.

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

      Häufige Neustarts deuten oft auf ein zugrunde liegendes Problem hin, z. B. eine beschädigte Konfigurationsdatei oder Ressourcenengpässe, die dazu führen, dass der Dienst wiederholt abstürzt.

  2. containerd-Konfiguration auf Änderungen prüfen: Falsche Einstellungen können dazu führen, dass die Container-Laufzeit fehlschlägt. Sie können Konfigurationsänderungen über eine Konfigurationsdatei für das Knotensystem oder durch direkte Änderungen vornehmen, die von Arbeitslasten mit erhöhten Berechtigungen vorgenommen werden.

    1. Ermitteln Sie, ob der Knotenpool eine Knotensystemkonfigurationsdatei verwendet:

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

      Ersetzen Sie Folgendes:

      • NODE_POOL_NAME: Der Name des Knotenpools.
      • CLUSTER_NAME: Der Name Ihres Clusters.
      • LOCATION: Die Compute Engine-Region oder -Zone des Clusters.

      Wenn in der Ausgabe ein Abschnitt containerdConfig angezeigt wird, werden diese benutzerdefinierten Einstellungen von GKE verwaltet. Wenn Sie die Einstellungen ändern oder zurücksetzen möchten, folgen Sie der Anleitung unter containerd-Konfiguration in GKE-Knoten anpassen.

    2. Wenn von GKE verwaltete Anpassungen nicht aktiv sind oder Sie andere Änderungen vermuten, suchen Sie nach Arbeitslasten, die das Dateisystem des Knotens möglicherweise direkt ändern. Suchen Sie nach DaemonSets mit erhöhten Berechtigungen (securityContext.privileged: true) oder hostPath-Volumes, die vertrauliche Verzeichnisse wie /etc einbinden.

      Wenn Sie die Konfiguration prüfen möchten, listen Sie alle DaemonSets im YAML-Format auf:

      kubectl get daemonsets --all-namespaces -o yaml

      Prüfen Sie die Ausgabe und untersuchen Sie die Logs verdächtiger DaemonSets.

    3. Prüfen Sie für Standardcluster die Konfigurationsdatei direkt. SSH-Zugriff und manuelle Dateiüberprüfung sind in Autopilot-Clustern nicht möglich, da Google die Laufzeitkonfiguration verwaltet. Melden Sie anhaltende Laufzeitprobleme an den Google Cloud Customer Care.

      Wenn Sie einen Standardcluster verwenden, prüfen Sie die Datei:

      1. Stellen Sie über SSH eine Verbindung zum Knoten her:

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

        Ersetzen Sie Folgendes:

        • NODE_NAME: der Name des Knotens, zu dem eine Verbindung hergestellt werden soll.
        • ZONE: die Compute Engine-Zone des Knotens.
        • PROJECT_ID: Ihre Projekt-ID.

      2. Rufen Sie den Inhalt der containerd-Konfigurationsdatei auf:

        sudo cat /etc/containerd/config.toml

      3. So prüfen Sie, ob es in letzter Zeit Änderungen gab:

        ls -l /etc/containerd/config.toml

    4. Vergleichen Sie den Inhalt dieser Datei mit der containerdConfig-Ausgabe des Befehls gcloud node-pools describe, den Sie im vorherigen Schritt ausgeführt haben. Jede Einstellung in /etc/containerd/config.toml, die nicht in der gcloud-Ausgabe enthalten ist, ist eine nicht verwaltete Änderung.

    5. Entfernen Sie alle Änderungen, die nicht über eine Knotensystemkonfiguration angewendet wurden, um eine Fehlkonfiguration zu beheben.

  3. Häufige Laufzeitprobleme beheben: Weitere Schritte zur Fehlerbehebung finden Sie unter Fehlerbehebung bei der Containerlaufzeit.

Probleme mit dem Namespace kube-node-lease beheben

Ressourcen im Namespace kube-node-lease sind für die Aufrechterhaltung des Knotenstatus verantwortlich. Dieser Namespace sollte nicht gelöscht werden. Versuche, diesen Namespace zu löschen, führen dazu, dass der Namespace im Status Terminating verbleibt. Wenn der Namespace kube-node-lease im Status Terminating hängen bleibt, können Kubelets ihre Systemdiagnose-Leases nicht erneuern. Dieses Problem führt dazu, dass die Steuerungsebene die Knoten als fehlerhaft betrachtet. Das führt zu einem clusterweiten Problem, bei dem die Knoten zwischen den Status Ready und NotReady wechseln.

Symptome:

Wenn Sie die folgenden Symptome beobachten, ist ein Problem mit dem kube-node-lease-Namespace wahrscheinlich die Ursache für die clusterweite Instabilität:

  • Die Kubelet-Logs auf jedem Knoten enthalten dauerhafte Fehler wie die folgenden:

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

  • Knoten im Cluster wechseln wiederholt zwischen den Status Ready und NotReady.

Ursache:

Der Namespace kube-node-lease, in dem Node-Heartbeats verwaltet werden, befindet sich ungewöhnlich lange im Status Terminating. Dieser Fehler verhindert, dass der Kubernetes API-Server das Erstellen oder Ändern von Objekten im Namespace zulässt. Daher können Kubelets ihre Lease-Objekte nicht erneuern, die für die Signalisierung ihres Liveness-Status an die Steuerungsebene unerlässlich sind. Ohne diese Statusaktualisierungen kann die Steuerungsebene nicht bestätigen, dass die Knoten fehlerfrei sind. Daher wechselt der Status der Knoten zwischen Ready und NotReady.

Mögliche Gründe dafür, dass der kube-node-lease-Namespace selbst im Status Terminating hängen bleibt:

  • Ressourcen mit Finalizern: Obwohl dies für den System-Namespace kube-node-lease (der hauptsächlich Lease-Objekte enthält) weniger häufig vorkommt, kann eine Ressource darin einen Finalizer haben. Kubernetes-Finalizer sind Schlüssel, die signalisieren, dass ein Controller Bereinigungsaufgaben ausführen muss, bevor eine Ressource gelöscht werden kann. Wenn der Controller, der für das Entfernen des Finalizers verantwortlich ist, nicht richtig funktioniert, wird die Ressource nicht gelöscht und der Namespace-Löschvorgang wird angehalten.
  • Nicht fehlerfreie oder nicht reagierende aggregierte API-Dienste: Die Namespace-Beendigung kann blockiert werden, wenn ein APIService-Objekt, das zum Registrieren eines aggregierten API-Servers verwendet wird, mit dem Namespace verknüpft ist und nicht fehlerfrei wird. Die Steuerungsebene wartet möglicherweise darauf, dass der aggregierte API-Server ordnungsgemäß heruntergefahren oder bereinigt wird. Dies geschieht jedoch nicht, wenn der Dienst nicht reagiert.
  • Probleme mit der Steuerungsebene oder dem Controller: In seltenen Fällen können Fehler oder Probleme in der Kubernetes-Steuerungsebene, insbesondere im Namespace-Controller, die erfolgreiche Garbage Collection und das Löschen des Namespace verhindern.

Lösung:

Folgen Sie der Anleitung unter Fehlerbehebung bei Namespaces, die im Status „Wird beendet“ hängen bleiben.

Fehlerbehebung bei Netzwerkverbindungen

Netzwerkprobleme können verhindern, dass ein Knoten mit der Steuerungsebene kommuniziert oder dass wichtige Komponenten wie das CNI-Plug-in funktionieren. Dies führt zu einem NotReady-Status.

Symptome:

Wenn Sie die folgenden Symptome beobachten, sind möglicherweise Netzwerkprobleme die Ursache für den Status NotReady Ihrer Knoten:

  • Die Bedingung NetworkNotReady ist True.
  • Die Kubelet-Logs auf dem Knoten enthalten Fehler, die den folgenden ähneln:
    • connection timeout to the control plane IP address
    • network plugin not ready
    • CNI plugin not initialized
    • connection refused- oder timeout-Meldungen beim Versuch, die IP-Adresse der Steuerungsebene zu erreichen.
  • Pods, insbesondere im Namespace kube-system, bleiben im Status ContainerCreating mit Ereignissen wie NetworkPluginNotReady hängen.

Ursache:

Netzwerkbezogene Symptome deuten in der Regel auf einen Fehler in einem der folgenden Bereiche hin:

  • Verbindungsprobleme: Der Knoten kann keine stabile Netzwerkverbindung zur Kubernetes-Steuerungsebene herstellen.
  • Fehler beim CNI-Plug-in: Das CNI-Plug-in, das für die Konfiguration des Pod-Netzwerks zuständig ist, wird nicht richtig ausgeführt oder konnte nicht initialisiert werden.
  • Webhook-Probleme: Falsch konfigurierte Zulassungs-Webhooks können Ressourcen im Zusammenhang mit dem CNI-Plug-in beeinträchtigen und verhindern, dass das Netzwerk richtig konfiguriert wird.

Lösung:

So beheben Sie Netzwerkprobleme:

  1. Vorübergehenden NetworkNotReady-Status beheben: Bei neu erstellten Knoten ist ein kurzes NetworkNotReady-Ereignis normal. Dieser Status sollte innerhalb von ein bis zwei Minuten behoben werden, während das CNI-Plug-in und andere Komponenten initialisiert werden. Wenn der Status weiterhin angezeigt wird, fahre mit den folgenden Schritten fort.

  2. Konnektivität zwischen Knoten und Steuerungsebene sowie Firewallregeln prüfen: Achten Sie darauf, dass der Netzwerkpfad zwischen Ihrem Knoten und der Steuerungsebene offen ist und ordnungsgemäß funktioniert:

    1. Firewallregeln prüfen: Achten Sie darauf, dass Ihre VPC-Firewallregeln den erforderlichen Traffic zwischen Ihren GKE-Knoten und der Steuerungsebene zulassen. Informationen zu den Regeln, die für die Kommunikation zwischen Knoten und Steuerungsebene in GKE erforderlich sind, finden Sie unter Automatisch erstellte Firewallregeln.
    2. Verbindung testen: Verwenden Sie den Konnektivitätstest im Network Intelligence Center, um den Netzwerkpfad zwischen der internen IP-Adresse des Knotens und der Endpunkt-IP-Adresse der Steuerungsebene auf Port 443 zu prüfen. Ein Ergebnis von Not Reachable kann Ihnen helfen, die Firewallregel oder das Routingproblem zu identifizieren, das die Kommunikation blockiert.

  3. CNI-Plug-in-Status und ‑Logs untersuchen: Wenn das Netzwerk des Knotens nicht bereit ist, liegt möglicherweise ein Problem mit dem CNI-Plug-in vor.

    1. CNI-Pod-Status prüfen: Ermitteln Sie das verwendete CNI-Plug-in (z. B. netd oder calico-node) und prüfen Sie den Status der zugehörigen Pods im Namespace kube-system. Mit dem folgenden Befehl können Sie nach dem jeweiligen Knoten filtern:

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

    2. CNI-Pod-Logs prüfen: Wenn die Pods nicht richtig funktionieren, prüfen Sie ihre Logs in Cloud Logging auf detaillierte Fehlermeldungen. Verwenden Sie für netd-Pods auf einem bestimmten Knoten eine Abfrage, die der folgenden ähnelt:

      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. Bestimmte CNI-Fehler beheben:

      • Wenn in den Logs Failed to allocate IP address angezeigt wird, sind Ihre Pod-IP-Adressbereiche möglicherweise erschöpft. Prüfen Sie die Auslastung der Pod-IP-Adressen und die CIDR-Bereiche Ihres Clusters.
      • Wenn in den Logs NetworkPluginNotReady oder cni plugin not initialized angezeigt wird, prüfen Sie, ob der Knoten über genügend CPU- und Arbeitsspeicherressourcen verfügt. Sie können auch versuchen, den CNI-Pod neu zu starten, indem Sie ihn löschen. Das DaemonSet erstellt ihn dann neu.
      • Wenn Sie GKE Dataplane V2 verwenden und in den Logs Cilium API client timeout exceeded angezeigt wird, starten Sie den anetd-Pod auf dem Knoten neu.

    4. Auf Störungen durch Zulassungs-Webhooks prüfen: Fehlerhafte Webhooks können verhindern, dass CNI-Pods gestartet werden, wodurch der Knoten den Status NetworkNotReady erhält.

    5. API-Server-Logs prüfen: Sehen Sie sich die API-Server-Logs in Cloud Logging an, um Fehler im Zusammenhang mit Webhook-Aufrufen zu finden. Um festzustellen, ob ein Webhook die Erstellung von CNI-Ressourcen blockiert, suchen Sie nach Meldungen wie failed calling webhook.

      Wenn ein Webhook Probleme verursacht, müssen Sie möglicherweise den problematischen ValidatingWebhookConfiguration oder MutatingWebhookConfiguration identifizieren und vorübergehend deaktivieren, damit der Knoten bereit wird. Weitere Informationen finden Sie unter Probleme beheben, die durch Admission-Webhooks verursacht werden.

Fehlkonfigurationen von Clustern beheben

In den folgenden Abschnitten erfahren Sie, wie Sie einige clusterweite Konfigurationen prüfen, die möglicherweise die normalen Knotenoperationen beeinträchtigen.

Probleme beheben, die durch Zulassungs-Webhooks verursacht werden

Ein Zulassungs-Webhook, der falsch konfiguriert, nicht verfügbar oder zu langsam ist, kann kritische API-Anfragen blockieren und verhindern, dass wichtige Komponenten gestartet werden oder Knoten dem Cluster beitreten.

Symptome:

Wenn Sie die folgenden Symptome beobachten, blockiert ein falsch konfigurierter oder nicht verfügbarer Admission-Webhook wahrscheinlich wichtige Clusteroperationen:

  • Pods, insbesondere im Namespace kube-system (z. B. CNI- oder Speicher-Pods), hängen im Status Pending oder Terminating fest.
  • Neue Knoten können dem Cluster nicht beitreten und es kommt häufig zu einem Zeitüberschreitungsfehler mit dem Status NotReady.

Ursache:

Falsch konfigurierte oder nicht reagierende Zulassungs-Webhooks blockieren möglicherweise wichtige Cluster-Vorgänge.

Lösung:

Prüfen Sie Ihre Webhook-Konfigurationen, um sicherzustellen, dass sie stabil und richtig festgelegt sind. Um Ausfälle zu vermeiden, legen Sie das Feld failurePolicy für nicht kritische Webhooks auf Ignore fest. Bei kritischen Webhooks muss der zugrunde liegende Dienst hochverfügbar sein. Schließen Sie den kube-system-Namespace aus der Webhook-Überwachung aus, indem Sie ein namespaceSelector verwenden, um Deadlocks auf der Steuerungsebene zu vermeiden. Weitere Informationen finden Sie unter Bei Verwendung von Webhooks für die Stabilität der Steuerungsebene sorgen.

Durch Ressourcenkontingente verursachte Probleme beheben

Ein falsch berechnetes Ressourcenkontingent im Namespace kube-system kann verhindern, dass GKE kritische System-Pods erstellt. Da Komponenten wie das Netzwerk (CNI) und DNS blockiert sind, kann dieses Problem verhindern, dass neue Knoten dem Cluster erfolgreich beitreten.

Symptome:

  • Kritische Pods im Namespace kube-system (z. B. netd, konnectivity-agent oder kube-dns) verbleiben im Status Pending.
  • Fehlermeldungen in den Clusterlogs oder der kubectl describe pod-Ausgabe weisen auf Fehler wie exceeded quota: gcp-critical-pods hin.

Ursache:

Dieses Problem tritt auf, wenn der Kubernetes-Controller für Ressourcenkontingente die Anzahl der verwendeten Ressourcen in ResourceQuota-Objekten nicht mehr korrekt aktualisiert. Eine häufige Ursache ist ein fehlerhafter Zulassungs-Webhook eines Drittanbieters, der die Aktualisierungen des Controllers blockiert. Dadurch wird die Kontingentnutzung viel höher angezeigt, als sie tatsächlich ist.

Lösung:

  1. Da ein problematischer Webhook die wahrscheinlichste Ursache ist, folgen Sie der Anleitung im Abschnitt Probleme beheben, die durch Admission-Webhooks verursacht werden, um alle Webhooks zu identifizieren und zu beheben, die Systemkomponenten blockieren könnten. Wenn Sie den Webhook korrigieren, wird das Kontingentproblem oft automatisch behoben.

  2. Prüfen Sie, ob die aufgezeichnete Nutzung des Kontingents nicht mit der tatsächlichen Anzahl der ausgeführten Pods übereinstimmt. In diesem Schritt wird geprüft, ob die Anzahl des ResourceQuota-Objekts falsch ist:

    1. Prüfen Sie die gemeldete Nutzung des Kontingents:

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

    2. Prüfen Sie die tatsächliche Anzahl der Pods:

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

  3. Wenn die verwendete Anzahl in ResourceQuota falsch erscheint (z. B. viel höher als die tatsächliche Anzahl der Pods), löschen Sie das gcp-critical-pods-Objekt. Die GKE-Steuerungsebene ist so konzipiert, dass dieses Objekt automatisch mit den korrekten, abgeglichenen Nutzungszahlen neu erstellt wird:

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

  4. Beobachten Sie den Namespace kube-system einige Minuten lang, um sicherzustellen, dass das Objekt neu erstellt wird und die ausstehenden Pods mit der Planung beginnen.

Probleme beheben, die durch DaemonSets von Drittanbietern verursacht werden

Ein neu bereitgestelltes oder aktualisiertes DaemonSet eines Drittanbieters, das häufig für Sicherheit, Monitoring oder Logging verwendet wird, kann manchmal zu Knoteninstabilität führen. Dieses Problem kann auftreten, wenn das DaemonSet die Containerlaufzeit oder das Netzwerk des Knotens beeinträchtigt, übermäßig viele Systemressourcen verbraucht oder unerwartete Systemänderungen vornimmt.

Symptome:

Wenn Sie die folgenden Symptome beobachten, ist ein kürzlich bereitgestelltes oder geändertes Drittanbieter-DaemonSet eine mögliche Ursache für Knotenausfälle:

  • Mehrere Knoten, möglicherweise im gesamten Cluster, wechseln kurz nach der Bereitstellung oder Aktualisierung des DaemonSets in den Status NotReady.
  • In den Kubelet-Logs für betroffene Knoten werden Fehler wie die folgenden gemeldet:
    • container runtime is down
    • Failed to create pod sandbox
    • Fehler beim Herstellen einer Verbindung zum Socket der Containerlaufzeit (z. B. /run/containerd/containerd.sock).
  • Pods, einschließlich System-Pods oder der eigenen Pods des DaemonSets, verbleiben im Status PodInitializing oder ContainerCreating.
  • Containerlogs für Anwendungen enthalten ungewöhnliche Fehler wie exec format error.
  • Node Problem Detector meldet möglicherweise Bedingungen, die sich auf den Laufzeitstatus oder den Ressourcendruck beziehen.

Ursache:

Das Drittanbieter-DaemonSet kann die Knotenstabilität aus folgenden Gründen beeinträchtigen:

  • Übermäßiger Verbrauch von CPU, Arbeitsspeicher oder Laufwerk-E/A, was sich auf die Leistung kritischer Knotenkomponenten auswirkt.
  • Beeinträchtigung des Betriebs der Containerlaufzeit.
  • Dies führt zu Konflikten mit der Netzwerkkonfiguration des Knotens oder dem CNI-Plug-in (Container Network Interface).
  • Systemkonfigurationen oder Sicherheitsrichtlinien werden unbeabsichtigt geändert.

Lösung:

So stellen Sie fest, ob ein DaemonSet die Ursache ist:

  1. DaemonSets identifizieren: Listen Sie alle DaemonSets auf, die in Ihrem Cluster ausgeführt werden:

    kubectl get daemonsets --all-namespaces

    Achten Sie genau auf DaemonSets, die nicht Teil der Standard-GKE-Installation sind.

    Sie können diese DaemonSets oft anhand der folgenden Informationen identifizieren:

    • Namespace: Standard-GKE-Komponenten werden normalerweise im Namespace kube-system ausgeführt. DaemonSets in anderen Namespaces sind wahrscheinlich Drittanbieter- oder benutzerdefinierte DaemonSets.
    • Benennung: Standard-DaemonSets haben oft Namen wie gke-metrics-agent, netd oder calico-node. Drittanbieter-Agents haben oft Namen, die das Produkt widerspiegeln.

  2. Bereitstellungszeit korrelieren: Prüfen Sie, ob das Auftreten von NotReady-Knoten mit der Bereitstellung oder Aktualisierung eines bestimmten Drittanbieter-DaemonSets zusammenfällt.

  3. Auf einem einzelnen Knoten testen:

    1. Wählen Sie einen betroffenen Knoten aus.
    2. Sperren und leeren Sie den Knoten.
    3. Verhindern Sie vorübergehend, dass das DaemonSet auf diesem Knoten geplant wird:
      • Wenden Sie ein temporäres Knotenlabel an und konfigurieren Sie die Knotenaffinität oder ‑antiaffinität im Manifest des DaemonSets.
      • Löschen Sie den Pod des DaemonSets auf diesem bestimmten Knoten.
    4. Starten Sie die VM-Instanz des Knotens neu.
    5. Prüfen Sie, ob der Knoten Ready wird und stabil bleibt, während das DaemonSet nicht darauf ausgeführt wird. Wenn die Probleme nach der Wiedereinführung des DaemonSets wieder auftreten, ist es wahrscheinlich ein Faktor.

  4. Anbieter kontaktieren: Wenn Sie vermuten, dass ein Drittanbieter-Agent die Ursache ist, lesen Sie die Dokumentation des Anbieters, um Informationen zu bekannten Kompatibilitätsproblemen oder Best Practices für die Ausführung des Agents in GKE zu erhalten. Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Softwareanbieter.

Prüfen, ob der Knoten wiederhergestellt wurde

Nachdem Sie eine mögliche Lösung angewendet haben, gehen Sie so vor, um zu prüfen, ob der Knoten wieder stabil ist:

  1. Prüfen Sie den Status des Knotens:

    kubectl get nodes -o wide

    Suchen Sie in der Ausgabe nach dem betroffenen Knoten. In der Spalte Status sollte jetzt der Wert Ready angezeigt werden. Es kann einige Minuten dauern, bis der Status aktualisiert wird, nachdem die Korrektur angewendet wurde. Wenn der Status weiterhin NotReady anzeigt oder zwischen verschiedenen Status wechselt, ist das Problem noch nicht vollständig behoben.

  2. Sehen Sie sich den Abschnitt Conditions des Knotens an:

    kubectl describe node NODE_NAME

    Prüfen Sie im Abschnitt Conditions die folgenden Werte:

    • Die Bedingung Ready hat den Status True.
    • Die negativen Bedingungen, die zuvor den Status True hatten (z. B. MemoryPressure oder NetworkUnavailable), haben jetzt den Status False. In den Feldern Reason und Message für diese Bedingungen sollte angegeben werden, dass das Problem behoben wurde.

  3. Pod-Planung testen. Wenn auf dem Knoten zuvor keine Arbeitslasten ausgeführt werden konnten, prüfen Sie, ob neue Pods darauf geplant werden und ob vorhandene Pods ohne Probleme ausgeführt werden:

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

    Pods auf dem Knoten sollten den Status Running oder Completed haben. Es sollten keine Pods im Status Pending oder in anderen Fehlerstatus hängen bleiben.

Nächste Schritte

  • Wenn Sie in der Dokumentation keine Lösung für Ihr Problem finden, lesen Sie den Abschnitt Support erhalten. Dort finden Sie weitere Hilfe, z. B. zu den folgenden Themen: