Probleme mit bereitgestellten Arbeitslasten beheben

Auf dieser Seite wird beschrieben, wie Sie Fehler bei 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 Cloud de Confiance Console oder das 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, versuchen Sie, das Problem mit den Informationen in den folgenden Abschnitten zu beheben.

Fehler: CrashLoopBackOff

Ein Status von CrashLoopBackOff bedeutet nicht, dass ein bestimmter Fehler vorliegt. Stattdessen gibt er 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 bei Image-Pulls.

Fehler: OutOfPods

Ein Status von OutOfPods gibt an, dass ein Pod nicht auf einem Knoten ausgeführt werden kann, weil 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 der kube-scheduler Pods einem neuen Knoten zuweist, bevor der kubelet das Vorhandensein statischer Pods wie kube-proxy gemeldet hat, die eine eigene Pod-Kapazität benötigen.

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 die erhöhten Ressourcenanforderungen zu erfüllen.

• Cluster Autoscaler und automatische Knotenbereitstellung aktivieren Wenn Ihnen häufig die Pod-Kapazität ausgeht, können Sie den Cluster Autoscaler und die automatische Knotenbereitstellung aktivieren, um sicherzustellen, 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 in balanced anstelle von optimize-utilization 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 nicht planbar

Ein Status von 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 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, bei dem Sie die Fehlerbehebung durchführen möchten. Wenn Sie Ihren Cluster nicht finden können, geben Sie den Namen des Clusters in das filter_list 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 können, geben Sie den Namespace in das filter_list Filter Feld ein.

4. Gehen 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 Future Mitigation Tips (Tipps zur zukünftigen Risikominderung) die Option Create an Alert (Benachrichtigung erstellen) aus .

Fehler: Unzureichende Ressourcen

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) gibt an, dass auf zwei Knoten nicht genügend CPU Kapazität verfügbar ist, um die Anforderungen eines Pods zu erfüllen.

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 vertikale Skalierung aus, um einen neuen Knoten hinzuzufügen. Damit GKE den Pod planen kann, müssen Sie entweder weniger Ressourcen für den Pod anfordern oder einen neuen Knotenpool mit ausreichenden Ressourcen erstellen.

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

Die Standard-CPU-Anfrage beträgt 100 MB oder 10 % einer CPU bzw. eines Kerns. Wenn Sie mehr oder weniger Ressourcen anfordern möchten, geben Sie den Wert in der Pod-Spezifikation unter spec: containers: resources: requests an.

Fehler: MatchNodeSelector

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

Sehen Sie sich in der Pod-Spezifikation unter spec: nodeSelector die im Feld nodeSelector angegebenen Labels an, um das zu prüfen.

Führen Sie den folgenden Befehl aus, um sich die Labels von Knoten in Ihrem Cluster anzusehen:

kubectl get nodes --show-labels

Führen Sie den folgenden Befehl aus, um einem Knoten ein Label hinzuzufügen:

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

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

Führen Sie den folgenden Befehl aus, um dies zu ermitteln:

kubectl describe nodes NODE_NAME

Prüfen Sie in der Ausgabe das Feld Taints. Darin sind Schlüssel/Wert-Paare und Planungseffekte aufgeführt.

Lautet der aufgeführte Effekt NoSchedule, können Pods auf diesem Knoten nur geplant werden, wenn sie eine übereinstimmende Toleranz haben.

Eine Möglichkeit zur Behebung dieses Problems ist, die Markierung zu entfernen. 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.

Um das Problem zu beheben, folgen Sie den Kubernetes-Best Practices und verwenden Sie ein NodePort anstelle eines hostPort.

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

Fehler: Keine Mindestverfügbarkeit vorhanden

Wenn für einen Knoten genügend Ressourcen vorhanden sind, die Meldung Does not have minimum availability jedoch immer noch angezeigt wird, prüfen Sie den Status des Pods. Wenn er SchedulingDisabled oder Cordoned lautet, kann der Knoten keine neuen Pods planen. Sie können den Status eines Knotens in der Cloud de Confiance Console oder dem kubectl Befehlszeilentool prüfen.

kubectl get nodes

kubectl uncordon NODE_NAME

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

Wenn das Limit für die maximale Anzahl von Pods pro Knoten für alle Knoten im Cluster erreicht ist, bleiben die Pods im Status „ Nicht planbar“. Auf dem Tab Events des Pods wird eine Meldung mit dem Ausdruck Too many pods angezeigt.

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 weitere Knoten hinzu.

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

Wenn der Knotenpool seine Maximalgröße gemäß der Cluster-Autoscaling-Konfiguration erreicht hat, löst GKE keine vertikale Skalierung für den Pod aus, der andernfalls mit diesem Knotenpool geplant wäre. Wenn der Pod mit diesem Knotenpool geplant werden soll, ändern Sie die Cluster-Autoscaling Konfiguration.

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

Wenn der Knotenpool die maximale Anzahl von Knoten erreicht hat und der Cluster Autoscaler deaktiviert ist, kann GKE den Pod nicht mit dem Knotenpool planen. Erhöhen Sie die Größe Ihres Knotenpools oder aktivieren Sie den Cluster-Autoscaler für GKE, damit GKE die Größe Ihres Clusters automatisch anpassen kann.

Fehler: Ungebundene PersistentVolumeClaims

Der Fehler Unbound PersistentVolumeClaims gibt an, dass der Pod auf einen nicht gebundenen PersistentVolumeClaim verweist. Dieser Fehler kann auftreten, wenn das PersistentVolume nicht bereitgestellt werden konnte. Sie können prüfen, ob die Bereitstellung fehlgeschlagen ist. Dazu rufen Sie die Ereignisse für den PersistentVolumeClaim ab und untersuchen sie auf Fehler.

Führen Sie den folgenden Befehl aus, um Ereignisse abzurufen:

kubectl describe pvc STATEFULSET_NAME-PVC_NAME-0

Dabei gilt:

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

Dies kann auch passieren, wenn während der manuellen Vorabbereitstellung eines PersistentVolume und der Bindung an einen PersistentVolumeClaim ein Konfigurationsfehler aufgetreten ist.

Versuchen Sie, das Volume noch einmal vorab bereitzustellen, um diesen Fehler zu beheben.

Fehler: Unzureichendes Kontingent

Prüfen Sie, ob Ihr Projekt ein ausreichendes Compute Engine-Kontingent hat, damit GKE Ihren Cluster vertikal skalieren kann. Wenn GKE versucht, Ihrem Cluster einen Knoten hinzuzufügen, um den Pod zu planen, und die vertikale Skalierung das verfügbare Kontingent Ihres Projekts überschreiten würde, wird die Fehlermeldung scale.up.error.quota.exceeded angezeigt.

Weitere Informationen finden Sie unter Fehler bei der vertikalen Skalierung.

Problem: Eingestellte APIs

Achten Sie darauf, dass Sie keine eingestellten APIs verwenden, die mit der Nebenversion Ihres Clusters entfernt wurden. Weitere Informationen finden Sie unter Eingestellte Features und APIs Eingestellte Features und APIs.

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

Wenn ein Fehler wie der folgende angezeigt wird, haben Sie wahrscheinlich mehrere Pods auf demselben Knoten, für die im Feld hostPort derselbe Wert definiert ist:

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.

Durch das Binden eines Pods an einen hostPort wird eingeschränkt, wo GKE den Pod planen kann, da jede Kombination aus hostIP, hostPort und protocol eindeutig sein muss.

Um das Problem zu beheben, folgen Sie den Kubernetes-Best Practices und verwenden Sie ein NodePort anstelle eines hostPort.

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

Problem: Anwendungs- und Probe-Fehler in Pods

Das folgende Problem tritt auf, wenn Sie Anwendungen ausführen, die HTTPS für die Kommunikation mit einem Server verwenden. Fehler in diesen Anwendungen ähneln den folgenden:

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

Diese Probleme können auftreten, weil in den Kubernetes-Versionen 1.30 und höher Golang-Versionen verwendet werden, die die folgenden TLS-Verschlüsselungssuites 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

Verwenden Sie unterstützte Verschlüsselungssuites aus TLS 1.2 und höher, um dieses Problem zu beheben.

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 unter anderem Tipps 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 mehr Community-Support zu erhalten.
  • Probleme melden oder Featureanfragen stellen, indem Sie die öffentliche Problemverfolgung verwenden.