Probleme mit bereitgestellten Arbeitslasten beheben

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

Allgemeinere Informationen 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 wird der Pod-Status von Kubernetes mit einer Fehlermeldung aktualisiert. Sie können diese Fehler einsehen, indem Sie den Status eines Pods mit der Cloud de Confiance -Konsole oder dem kubectl-Befehlszeilentool prüfen.

kubectl get pods

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

kubectl describe pod POD_NAME

kubectl logs POD_NAME

Nachdem Sie den Fehler identifiziert haben, können Sie versuchen, das Problem mithilfe 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

Ein Status von 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 beim Pullen von Images.

Fehler: OutOfPods

Der Status OutOfPods gibt an, dass auf einem Knoten kein Pod ausgeführt werden kann, weil die maximale Pod-Kapazität des Knotens erreicht ist.

Symptome

Möglicherweise wird in den Ereignissen des Pods 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 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 Agent kubelet das Vorhandensein statischer Pods wie der Komponente kube-proxy gemeldet hat, die ihre eigene Pod-Kapazität benötigen.

Lösung

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

• Erhöhen Sie die maximale Anzahl von Pods pro Knoten. 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 die höheren Ressourcenanforderungen zu erfüllen.

• Cluster-Autoscaling und automatische Knotenbereitstellung aktivieren. Wenn Sie häufig nicht genügend Pod-Kapazität haben, kann die Aktivierung des Cluster-Autoscalers und der automatischen Knotenbereitstellung dazu beitragen, dass Ihr Cluster genügend Knoten hat, um die Anforderungen Ihrer Arbeitslasten zu erfüllen.

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

Fehler: Pod nicht planbar

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

Interaktives Playbook für nicht planbare Pods verwenden

Sie können PodUnschedulable-Fehler mithilfe des interaktiven Playbooks in der Cloud de Confiance 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, für den Sie die Fehlerbehebung durchführen möchten. Wenn Sie Ihren Cluster nicht finden, geben Sie den Namen des Clusters in das Feld filter_list Filter ein.

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

4. Um die Ursache zu ermitteln, gehen Sie die einzelnen Abschnitte im Playbook durch:

   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 zu zukünftigen PodUnschedulable-Fehlern 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

Möglicherweise stoßen Sie auf einen Fehler, 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 Ressourcenanfragen Ihres Pods die eines einzelnen Knotens aus einem der infrage kommenden Knotenpools überschreiten, plant GKE den Pod nicht und löst auch keine Aufskalierung aus, um einen neuen Knoten hinzuzufügen.

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

Lösung

Versuchen Sie Folgendes:

• Passen Sie die Ressourcenanfrage des Pods an, indem Sie im Feld spec: containers: resources: requests einen niedrigeren Wert angeben. Die Standard-CPU-Anfrage beträgt 100 MB 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 einen MatchNodeSelector-Fehler an.

Ursache

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

Lösung

Um diesen Fehler zu beheben, müssen die im Feld nodeSelector des Pods angegebenen Labels mit den Labels auf mindestens einem Knoten in Ihrem Cluster übereinstimmen:

1. Sehen Sie sich das Feld spec: nodeSelector des Pods an, um die Labelanforderungen zu ermitteln, nach denen der Pod sucht.

2. So sehen Sie, ob Labels den Anforderungen des Pods entsprechen:

   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

Der Fehler PodToleratesNodeTaints 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 einen PodToleratesNodeTaints-Fehler an.

Ursache

Der Pod kann für keinen 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 kein Pod auf diesem Knoten geplant werden, es sei denn, er hat eine übereinstimmende 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 einen PodFitsHostPorts-Fehler 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 anstelle der Einstellung hostPort einen NodePort-Dienst 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 Sperrstatus des Knotens verhindert, dass neue Pods darauf geplant werden.

Lösung

Um den Knoten wieder für die Planung von Pods verfügbar zu machen, heben Sie die Sperrung auf:

kubectl get nodes

kubectl uncordon NODE_NAME

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

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

Symptome

• Die Pods bleiben im Status Unschedulable hängen.
• Es wird eine Meldung mit dem Begriff Too many pods angezeigt.

Ursache

Das Limit für die maximale Anzahl von Pods pro Knoten wird 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 Cloud de Confiance 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 zusätzliche Knoten hinzu.

Problem: Maximale Knotenpoolgröße bei aktiviertem Cluster-Autoscaling erreicht

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

Symptome

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

Ursache

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

Lösung

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

Problem: Maximale Knotenpoolgröße bei deaktiviertem Cluster-Autoscaling 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 das Cluster-Autoscaling ist deaktiviert.

Lösung

Versuchen Sie Folgendes, um dieses Problem zu beheben:

• Größe des Knotenpools erhöhen.
• Aktivieren Sie Cluster Autoscaler, um die Größe Ihres 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 einen Unbound PersistentVolumeClaims-Fehler 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: Name des PersistentVolumeClaim-Objekts.

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

Fehler: Unzureichendes Kontingent

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

Symptome

Sie erhalten die Fehlermeldung scale.up.error.quota.exceeded in den Ereignissen Ihres Pods.

Ursache

Durch das Hochskalieren des Clusters würde das verfügbare Kontingent Ihres Projekts überschritten werden.

Lösung

Prüfen Sie, ob Ihr Projekt ein ausreichendes Compute Engine-Kontingent hat, damit GKE Ihren Cluster hochskalieren kann. Weitere Informationen finden Sie unter ScaleUp-Fehler.

Problem: Eingestellte APIs

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

Symptome

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

Ursache

Ihre Manifeste verwenden verworfene APIs, die in der Nebenversion Ihres Clusters entfernt werden.

Lösung

Achten Sie darauf, dass Sie keine verworfenen APIs verwenden. Aktualisieren Sie Ihre Manifeste, damit unterstützte APIs verwendet werden. Weitere Informationen finden Sie unter Einstellung von Funktionen und APIs.

Fehler: Keine verfügbaren Ports für die angeforderten Pod-Ports vorhanden

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

Möglicherweise wird ein ähnlicher Fehler wie dieser 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 Folgendes, um dieses Problem zu beheben:

• Folgen Sie den Best Practices für Kubernetes 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 für die Kommunikation mit einem Server verwenden.

Symptome

Fehler in diesen Anwendungen sehen in etwa so aus:

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

• Aktivitäts- oder Bereitschaftsprüfungen schlagen mit einer Fehlermeldung wie 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 ab 1.30 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 ab TLS 1.2.

Nächste Schritte

• Wenn Sie in der Dokumentation keine Lösung für Ihr Problem finden, können Sie Support anfordern. Dort erhalten Sie unter anderem Hilfe zu den folgenden Themen:

  • Sie können eine Supportanfrage stellen, indem Sie sich an Cloud Customer Care wenden.
  • Support von der Community erhalten, indem Sie Fragen auf StackOverflow stellen und das Tag google-kubernetes-engine verwenden, um nach ähnlichen Problemen zu suchen. Sie können auch dem #kubernetes-engine-Slack-Kanal beitreten, um weiteren Community-Support zu erhalten.
  • Sie können Probleme oder Feature Requests über die öffentliche Problemverfolgung melden.