Probleme mit bereitgestellten Arbeitslasten beheben

Autopilot Standard

Auf dieser Seite wird beschrieben, wie Sie Fehler bei Ihren bereitgestellten Arbeitslasten in Google Kubernetes Engine (GKE) beheben.

Allgemeinere Tipps zur Fehlerbehebung bei Anwendungen finden Sie in der Kubernetes-Dokumentation unter Fehlerbehebung bei Anwendungen.

Alle Fehler: Pod-Status prüfen

Bei Problemen mit den Pods einer Arbeitslast aktualisiert Kubernetes den Pod-Status mit einer Fehlermeldung. Sie können diese Fehler ansehen, indem Sie den Status eines Pods über die Google Cloud Console oder das kubectl Befehlszeilentool prüfen.

Console

Führen Sie diese Schritte aus:

1. Rufen Sie in der Google Cloud Console die Seite Arbeitslasten auf.

   Zu Arbeitslasten

2. Wählen Sie die Arbeitslast aus, die Sie prüfen möchten. Auf dem Tab Übersicht wird der Status der Arbeitslast angezeigt.

3. Klicken Sie im Abschnitt Verwaltete Pods auf eine Fehlerstatusmeldung.

kubectl

Führen Sie den folgenden Befehl aus, um alle in Ihrem Cluster ausgeführten Pods anzusehen:

kubectl get pods

Die Ausgabe sieht in etwa so aus:

NAME       READY  STATUS             RESTARTS  AGE
POD_NAME   0/1    CrashLoopBackOff   23        8d

Mögliche Fehler sind in der Spalte Status aufgeführt.

Führen Sie den folgenden Befehl aus, um weitere Informationen zu einem bestimmten Pod abzurufen:

kubectl describe pod POD_NAME

Ersetzen Sie POD_NAME durch den Namen des Pods, den Sie sich prüfen möchten.

In der Ausgabe enthält das Feld Events weitere Informationen zu Fehlern.

Weitere Informationen finden Sie in den Containerlogs:

kubectl logs POD_NAME

Anhand dieser Logs können Sie feststellen, ob ein Befehl oder Code im Container den Absturz des Pods verursacht hat.

Nachdem Sie den Fehler identifiziert haben, versuchen Sie, das Problem anhand der folgenden Abschnitte zu beheben.

Fehler: CrashLoopBackOff

Der Status CrashLoopBackOff bedeutet nicht, dass ein bestimmter Fehler vorliegt. Er gibt an, dass ein Container nach dem Neustart wiederholt abstürzt.

Weitere Informationen finden Sie unter Fehlerbehebung bei CrashLoopBackOff-Ereignissen.

Fehler: ImagePullBackOff und ErrImagePull

Der Status ImagePullBackOff oder ErrImagePull gibt an, dass das von einem Container verwendete Image nicht aus der Image-Registry geladen werden kann.

Eine Anleitung zur Fehlerbehebung bei diesen Status finden Sie unter Fehlerbehebung bei Image-Pulls.

Fehler: OutOfPods

Der Status OutOfPods gibt an, dass ein Pod nicht auf einem Knoten ausgeführt werden kann, da die maximale Pod-Kapazität des Knotens erreicht wurde.

Symptome

In den Ereignissen des Pods wird möglicherweise eine Meldung wie die folgende angezeigt:

Node didn't have enough resource: pods, requested: 1, used: 32, capacity: 32

Ursache

Dieser Fehler tritt auf, wenn ein Pod auf einem Knoten geplant werden soll, der bereits voll ausgelastet ist. Diese Situation kann häufig beim Starten von Knoten auftreten, z. B. wenn die Komponente kube-scheduler Pods einem neuen Knoten zuweist, bevor der kubelet-Agent die Anwesenheit statischer Pods wie der Komponente kube-proxy gemeldet hat, die eine eigene Pod-Kapazität erfordern.

Lösung

Versuchen Sie eine der folgenden Lösungen, um dieses Problem zu beheben:

• Maximale Anzahl von Pods pro Knoten erhöhen Wenn Ihre Knoten regelmäßig ihr Pod-Limit erreichen, erhöhen Sie die Einstellung --max-pods-per-node für Ihre Knotenpools. Wenn Sie die Anzahl der Pods erhöhen, sind möglicherweise größere Knoten erforderlich, um den erhöhten Ressourcenbedarf zu decken.

• Cluster-Autoscaling und automatische Knotenbereitstellung aktivieren Wenn Ihnen häufig die Pod-Kapazität ausgeht, können Sie mit dem Cluster Autoscaler und der automatischen Knotenbereitstellung dafür sorgen, dass Ihr Cluster genügend Knoten hat, um den Bedarf Ihrer Arbeitslasten zu decken.

• Autoscaling-Profil ändern Wenn Sie bereits den Cluster Autoscaler verwenden, versuchen Sie, das Autoscaling-Profil in das balanced Profil anstelle des optimize-utilization Profils zu ändern. Das Profil optimize-utilization kann die Wahrscheinlichkeit von OutOfPods-Fehlern erhöhen, da es versucht, Pods auf den am stärksten ausgelasteten Knoten zu platzieren.

Fehler: Pod kann nicht geplant werden

Der Status PodUnschedulable gibt an, dass Ihr Pod aufgrund unzureichender Ressourcen oder eines Konfigurationsfehlers nicht geplant werden kann.

Wenn Sie Messwerte der Steuerungsebene konfiguriert haben, finden Sie weitere Informationen zu diesen Fehlern unter Planermesswerte und API-Server Messwerte.

Interaktives Playbook für nicht planbare Pods verwenden

Sie können PodUnschedulable Fehler mit dem interaktiven Playbook in der Google Cloud Console beheben:

1. Rufen Sie das interaktive Playbook für nicht planbare Pods auf:

   Zum Playbook

2. Wählen Sie in der Drop-down-Liste Cluster den Cluster aus, bei dem Sie die Fehlerbehebung durchführen möchten. Wenn Sie Ihren Cluster nicht finden, geben Sie den Namen des Clusters in das Filter Feld ein.

3. Wählen Sie in der Drop-down-Liste Namespace den Namespace aus, bei dem Sie die Fehlerbehebung durchführen möchten. Wenn Sie Ihren Namespace nicht finden, geben Sie den Namespace in das Filter Feld ein.

4. Arbeiten Sie die einzelnen Abschnitte im Playbook durch, um die Ursache zu ermitteln:

   1. CPU und Arbeitsspeicher untersuchen
   2. Maximale Anzahl von Pods pro Knoten untersuchen
   3. Autoscaling-Verhalten untersuchen
   4. Andere Fehlermodi untersuchen
   5. Änderungsereignisse korrelieren

5. Optional: Wenn Sie Benachrichtigungen über zukünftige PodUnschedulable-Fehler erhalten möchten, wählen Sie im Abschnitt Tipps zur zukünftigen Fehlerbehebung die Option Benachrichtigung erstellen aus.

Fehler: Unzureichende Ressourcen

Der Status PodUnschedulable kann auftreten, wenn nicht genügend CPU, Arbeitsspeicher oder andere Ressourcen vorhanden sind, um die Anforderungen des Pods zu erfüllen.

Symptome

Hierbei tritt möglicherweise ein Fehler auf, der auf zu wenig CPU-Kapazität, Arbeitsspeicher oder andere Ressourcen hinweist. Beispiel: No nodes are available that match all of the predicates: Insufficient cpu (2). Diese Meldung weist darauf hin, dass auf zwei Knoten nicht genügend CPU-Kapazität verfügbar ist, um die Anfragen eines Pods zu erfüllen.

Ursache

Wenn die Ressourcenanforderungen Ihres Pods die eines einzelnen Knotens aus einem der infrage kommenden Knotenpools übersteigen, plant GKE den Pod nicht und löst auch keine Aufskalierung aus, um einen neuen Knoten hinzuzufügen.

Der Cluster führt Systemcontainer im Namespace kube-system aus. Diese Container verwenden auch Clusterressourcen.

Lösung

Probieren Sie die folgenden Lösungen aus:

• Passen Sie die Ressourcenanforderung des Pods an, indem Sie im Feld spec: containers: resources: requests einen niedrigeren Wert angeben. Die Standard-CPU-Anfrage beträgt 100 m oder 10% einer CPU (bzw. eines Kerns).

• Erstellen Sie einen neuen Knotenpool mit Knoten, die über genügend Ressourcen verfügen, um die Anforderungen des Pods zu erfüllen.

• Aktivieren Sie die automatische Knotenbereitstellung , damit GKE automatisch Knotenpools mit Knoten erstellen kann, auf denen die nicht geplanten Pods ausgeführt werden können.

Fehler: MatchNodeSelector

Der Fehler MatchNodeSelector gibt an, dass keine Knoten vorhanden sind, die mit der Labelauswahl des Pods übereinstimmen.

Symptome

Der Pod-Status oder die Ereignisse zeigen den Fehler MatchNodeSelector an.

Ursache

Die im Feld nodeSelector des Pod-Manifests angegebenen Labels sind auf keinem Knoten im Cluster vorhanden.

Lösung

Achten Sie darauf, dass die im Feld nodeSelector des Pods angegebenen Labels mit den Labels auf mindestens einem Knoten im Cluster übereinstimmen, um diesen Fehler zu beheben:

1. Ermitteln Sie die Labelanforderungen, die der Pod benötigt, indem Sie das Feld spec: nodeSelector prüfen.

2. Prüfen Sie, ob Labels den Anforderungen des Pods entsprechen, indem Sie die tatsächlichen Labels ansehen, die den Knoten im Cluster zugewiesen sind:

   kubectl get nodes --show-labels
   

3. Wenn ein Knoten diesen Pod ausführen soll, fügen Sie das erforderliche Label hinzu:

   kubectl label nodes NODE_NAME LABEL_KEY=LABEL_VALUE
   

   Ersetzen Sie Folgendes:

   • NODE_NAME: der Knoten, dem Sie ein Label hinzufügen möchten.
   • LABEL_KEY: der Schlüssel des Labels
   • LABEL_VALUE: der Wert des Labels

Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Pods zu Knoten zuweisen.

Fehler: PodToleratesNodeTaints

Ein PodToleratesNodeTaints Fehler gibt an, dass der Pod für keinen Knoten geplant werden kann, da der Pod keine Toleranzen hat, die den vorhandenen Knotenmarkierungen entsprechen.

Symptome

Der Pod-Status oder die Ereignisse zeigen den Fehler PodToleratesNodeTaints an.

Ursache

Der Pod kann nicht auf einem Knoten geplant werden, da er keine Toleranzen hat, die den vorhandenen Knotenmarkierungen entsprechen.

Lösung

1. Prüfen Sie die Markierungen auf dem Knoten:

   kubectl describe nodes NODE_NAME
   

   Prüfen Sie in der Ausgabe das Feld Taints. Darin sind Schlüssel/Wert-Paare und Planungseffekte aufgeführt. Wenn der aufgeführte Effekt NoSchedule ist, kann auf diesem Knoten kein Pod geplant werden, es sei denn, er hat eine passende Toleranz.

2. Entfernen Sie die Markierung vom Knoten. Führen Sie beispielsweise den folgenden Befehl aus, um eine NoSchedule-Markierung zu entfernen:

   kubectl taint nodes NODE_NAME key:NoSchedule-
   

Fehler: PodFitsHostPorts

Der Fehler PodFitsHostPorts bedeutet, dass ein Knoten versucht, einen Port zu verwenden, der bereits belegt ist.

Symptome

Der Pod-Status zeigt den Fehler PodFitsHostPorts an.

Ursache

Ein Pod fordert einen Hostport an, der bereits von einem anderen Pod oder Prozess auf dem Zielknoten verwendet wird.

Lösung

Um das Problem zu beheben, sollten Sie die Kubernetes-Best Practices befolgen und einen NodePort-Dienst anstelle der Einstellung hostPort verwenden.

Wenn Sie einen Hostport verwenden müssen, prüfen Sie die Manifeste der Pods und achten Sie darauf, dass für alle Pods auf demselben Knoten eindeutige Werte für die Einstellung hostPort definiert sind.

Fehler: Keine Mindestverfügbarkeit vorhanden

Dieser Fehler kann auftreten, wenn ein Knoten über ausreichende Ressourcen verfügt, aber nicht für die Planung verfügbar ist.

Symptome

• Der Fehler Does not have minimum availability wird angezeigt.

• Der Status des Knotens ist SchedulingDisabled oder Cordoned.

Ursache

Der gesperrte Status des Knotens verhindert, dass neue Pods darauf geplant werden.

Lösung

Entsperren Sie den Knoten, damit er wieder für die Planung von Pods verfügbar ist:

Console

Führen Sie diese Schritte aus:

1. Öffnen Sie in der Google Cloud Console die Seite Google Kubernetes Engine.

   Zur Seite "Google Kubernetes Engine"

2. Wählen Sie den gewünschten zu prüfenden Cluster aus. Auf dem Tab Knoten werden die Knoten und ihr Status angezeigt.

Führen Sie die folgenden Schritte aus, um die Planung auf dem Knoten zu aktivieren:

1. Klicken Sie in der Liste auf den Knoten, den Sie prüfen möchten.

2. Klicken Sie im Abschnitt Knotendetails auf Entsperren.

kubectl

Führen Sie den folgenden Befehl aus, um die Status der Knoten abzurufen:

kubectl get nodes

Die Planung auf dem Knoten aktivieren Sie mit folgendem Befehl:

kubectl uncordon NODE_NAME

Fehler: Limit für maximale Anzahl von Pods pro Knoten erreicht

Der Fehler Too many pods gibt an, dass ein Pod nicht geplant werden kann, da der Zielknoten seine maximal konfigurierte Pod-Kapazität erreicht hat.

Symptome

• Die Pods befinden sich im Status Unschedulable.
• Sie sehen eine Meldung mit dem Ausdruck Too many pods.

Ursache

Das Limit für die maximale Anzahl von Pods pro Knoten wurde von allen Knoten im Cluster erreicht.

Lösung

Führen Sie folgende Schritte aus, um diesen Fehler zu beheben:

1. Prüfen Sie die Maximum pods per node Konfiguration auf dem Tab „Knoten“ in den GKE-Clusterdetails in der Google Cloud Console.

2. Rufen Sie eine Liste der Knoten ab:

   kubectl get nodes
   

3. Prüfen Sie für jeden Knoten die Anzahl der Pods, die auf dem Knoten ausgeführt werden:

   kubectl get pods -o wide | grep NODE_NAME | wc -l
   

4. Wenn das Limit erreicht ist, fügen Sie einen neuen Knotenpool hinzu oder fügen Sie dem vorhandenen Knotenpool weitere Knoten hinzu.

Problem: Maximale Knotenpoolgröße mit aktiviertem Cluster Autoscaler erreicht

Dieses Problem tritt auf, wenn ein Knotenpool seine maximal konfigurierte Größe unter dem Cluster Autoscaler erreicht hat.

Symptome

GKE löst keine Aufskalierung für einen Pod aus, der andernfalls mit diesem Knotenpool geplant wäre. Stattdessen bleibt der Pod im Status Pending.

Ursache

Der Knotenpool hat seine Maximal größe gemäß der Cluster-Autoscaling-Konfiguration erreicht.

Lösung

Erhöhen Sie die maximale Größe des Knotenpools, indem Sie die Cluster-Autoscaling Konfiguration ändern.

Problem: Maximale Knotenpoolgröße mit deaktiviertem Cluster Autoscaler erreicht

Dieses Problem tritt auf, wenn ein Knotenpool seine maximale Größe erreicht hat und der Cluster Autoscaler deaktiviert ist.

Symptome

GKE kann den Pod nicht mit dem Knotenpool planen.

Ursache

Der Knotenpool hat die maximale Anzahl von Knoten erreicht und der Cluster Autoscaler ist deaktiviert.

Lösung

Versuchen Sie eine der folgenden Lösungen, um dieses Problem zu beheben:

• Erhöhen Sie die Größe des Knoten pools.
• Aktivieren Sie den Cluster Autoscaler , um die Größe des Clusters automatisch anzupassen.

Fehler: Ungebundene PersistentVolumeClaims

Der Fehler Unbound PersistentVolumeClaims gibt an, dass der Pod auf einen nicht gebundenen PersistentVolumeClaim verweist.

Symptome

Der Pod-Status oder die Ereignisse zeigen den Fehler Unbound PersistentVolumeClaims an.

Ursache

Dieser Fehler kann aus einem der folgenden Gründe auftreten:

• Das PersistentVolume konnte nicht bereitgestellt werden.
• Bei der manuellen Vorabbereitstellung eines PersistentVolume und der Bindung an einen PersistentVolumeClaim ist ein Konfigurationsfehler aufgetreten.

Lösung

1. Prüfen Sie, ob die Bereitstellung fehlgeschlagen ist, indem Sie die Ereignisse für Ihren PersistentVolumeClaim abrufen:

   kubectl describe pvc STATEFULSET_NAME-PVC_NAME-0
   

   Ersetzen Sie Folgendes:

   • STATEFULSET_NAME: der Name des StatefulSet-Objekts.
   • PVC_NAME: der Name des PersistentVolumeClaim-Objekts.

2. Versuchen Sie, das Volume noch einmal vorab bereitzustellen.

Fehler: Unzureichendes Kontingent

Wenn GKE versucht, den Cluster aufzuskalieren, um einen Pod zu planen, aber auf Kontingentbeschränkungen stößt, schlägt die Aufskalierung fehl.

Symptome

In den Ereignissen des Pods wird die Fehlermeldung scale.up.error.quota.exceeded angezeigt.

Ursache

Durch die Aufskalierung des Clusters würde das verfügbare Kontingent Ihres Projekts überschritten.

Lösung

Prüfen Sie, ob Ihr Projekt ein ausreichendes Compute Engine-Kontingent hat, damit GKE den Cluster aufskalieren kann. Weitere Informationen finden Sie unter Fehler bei der Aufskalierung.

Problem: Veraltete APIs

Wenn Sie in Ihren Manifesten APIs verwenden, die nicht mehr unterstützt werden, kann die Bereitstellung von Arbeitslasten verhindert werden.

Symptome

Arbeitslasten können aufgrund der Verwendung veralteter APIs nicht bereitgestellt oder ausgeführt werden.

Ursache

Ihre Manifeste verwenden veraltete APIs, die in der Nebenversion Ihres Clusters entfernt wurden.

Lösung

Achten Sie darauf, dass Sie keine veralteten APIs verwenden. Aktualisieren Sie Ihre Manifeste, um unterstützte APIs zu verwenden. Weitere Informationen finden Sie unter Verworfene Features und APIs.

Fehler: Keine kostenlosen Ports für die angeforderten Pod-Ports

Wenn Sie einen Pod an einen Hostport binden, wird eingeschränkt, wo GKE den Pod planen kann, da jede Kombination aus hostIP-Adresse, hostPort-Einstellung und protocol-Wert eindeutig sein muss.

Symptome

Es wird ein Fehler ähnlich dem folgenden angezeigt:

0/1 nodes are available: 1 node(s) didn't have free ports for the requested pod ports. preemption: 0/1 nodes are available: 1 No preemption victims found for incoming pod.

Ursache

Mehrere Pods auf demselben Knoten geben denselben Wert an, der im Feld hostPort definiert ist.

Lösung

Versuchen Sie eine der folgenden Lösungen, um dieses Problem zu beheben:

• Befolgen Sie die Kubernetes-Best Practices und verwenden Sie einen NodePort-Dienst anstelle eines Hostports.
• Wenn Sie einen Hostport verwenden müssen, prüfen Sie die Manifeste der Pods und achten Sie darauf, dass für alle Pods auf demselben Knoten eindeutige Werte für das Feld hostPort definiert sind.

Problem: Anwendungs- und Probe-Fehler in Pods

Dieses Problem tritt auf, wenn Sie Anwendungen ausführen, die HTTPS verwenden, um mit einem Server zu kommunizieren.

Symptome

Fehler in diesen Anwendungen sehen in etwa so aus:

• Pods werden nicht gestartet und Container stürzen mit dem Exit-Code 137 ab.

• Liveness- oder Readiness-Probes schlagen mit einer Fehlermeldung ähnlich der folgenden fehl:

  probeResult="failure" output="Get "https://example.com/healthy": EOF"
  

• Pods werden wie erwartet ausgeführt, aber in den Anwendungsprotokollen werden Verbindungsfehler angezeigt.

Ursache

In Kubernetes-Versionen 1.30 und höher werden Golang-Versionen verwendet, die die folgenden TLS-Cipher-Suites deaktivieren:

• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA

Lösung

Verwenden Sie unterstützte Cipher-Suites aus TLS 1.2 und höher.

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 Informationen zu folgenden Themen:

  • Supportanfrage erstellen, indem Sie sich an Cloud Customer Care wenden.
  • Support von der Community erhalten, indem Sie Fragen auf Stack Overflow stellen und mit dem google-kubernetes-engine Tag nach ähnlichen Problemen suchen. Sie können auch dem #kubernetes-engine Slack-Kanal beitreten, um weitere Unterstützung von der Community zu erhalten.
  • Probleme melden oder Featureanfragen stellen, indem Sie die öffentliche Problemverfolgung verwenden.