Probleme mit bereitgestellten Arbeitslasten beheben

Auf dieser Seite wird beschrieben, wie Sie Fehler bei Ihren bereitgestellten Arbeitslasten in der 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 prüfen, indem Sie den Status eines Pods in der Google Cloud -Konsole oder mit dem 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

Potenzielle Fehler sind in der Spalte Status aufgeführt.

Führen Sie den folgenden Befehl aus, um weitere Details 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 Container-Logs:

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, können Sie in den folgenden Abschnitten versuchen, das Problem 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. Wenn ein Container kurz nach dem Start abstürzt oder beendet wird (CrashLoop), versucht Kubernetes, den Container neu zu starten. Mit jedem fehlgeschlagenen Neustart erhöht sich die Verzögerung (BackOff) vor dem nächsten Versuch exponentiell (10 Sekunden, 20 Sekunden, 40 Sekunden usw.) bis zu einem Maximum von fünf Minuten.

In den folgenden Abschnitten erfahren Sie, warum Ihr Container möglicherweise abstürzt.

Interaktives Playbook für Pods in Absturzschleifen verwenden

Beginnen Sie mit der Fehlerbehebung, um die Ursache für den Status CrashLoopBackOff zu ermitteln. Verwenden Sie dazu das interaktive Playbook in der Google Cloud Console:

  1. Rufen Sie das Interaktive Playbook für Pods in Absturzschleifen auf:

    Playbook aufrufen

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

  3. Wählen Sie in der Drop-down-Liste Namespace den Namespace aus, für den Sie Fehler beheben möchten. Wenn Sie Ihren Namespace nicht finden, geben Sie ihn in das Feld Filter ein.

  4. Gehen Sie die einzelnen Abschnitte durch, um die Ursache zu ermitteln:

    1. Anwendungsfehler ermitteln
    2. Probleme durch unzureichenden Arbeitsspeicher untersuchen
    3. Knotenstörungen untersuchen
    4. Fehlgeschlagene Aktivitätsprüfungen untersuchen
    5. Änderungsereignisse korrelieren

  5. Optional: Wenn Sie über zukünftige CrashLoopBackOff-Fehler benachrichtigt werden möchten, wählen Sie im Abschnitt Tipps zur zukünftigen Behebung die Option Benachrichtigung erstellen aus.

Logs prüfen

Ein Container kann aus verschiedenen Gründen abstürzen. Hier kann ein Blick in die Logs eines Pods helfen, die Ursache zu beheben.

Sie können die Protokolle in der Google Cloud -Konsole oder mit dem kubectl-Befehlszeilentool prüfen.

Console

Führen Sie diese Schritte aus:

  1. Rufen Sie in der Google Cloud -Konsole 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 den problematischen Pod.

  4. Klicken Sie im Menü des Pods auf den Tab Logs.

kubectl

  1. So rufen Sie alle in Ihrem Cluster ausgeführten Pods auf:

    kubectl get pods

  2. Suchen Sie in der Ausgabe des vorherigen Befehls in der Spalte Status nach einem Pod mit dem Fehler CrashLoopBackOff.

  3. Rufen Sie die Logs des Pods ab:

    kubectl logs POD_NAME

    Ersetzen Sie POD_NAME durch den Namen des problematischen Pods.

    Wenn Sie das Flag -p übergeben, können Sie außerdem die Logs der vorherigen Instanz des Containers eines Pods abrufen, falls vorhanden.

Exit-Code des abgestürzten Containers überprüfen

Um besser nachvollziehen zu können, warum Ihr Container abgestürzt ist, ermitteln Sie den Exit-Code:

  1. Beschreiben Sie den Pod:

    kubectl describe pod POD_NAME

    Ersetzen Sie POD_NAME durch den Namen des problematischen Pods.

  2. Prüfen Sie den Wert im Feld containers: CONTAINER_NAME: last state: exit code:

    • Lautet der Exit-Code 1, ist ein Absturz der Anwendung der Grund dafür, dass der Container abgestürzt ist.
    • Wenn der Exit-Code 0 ist, prüfen Sie, wie lange die Anwendung ausgeführt wurde. Container werden beendet, wenn der Hauptprozess der Anwendung beendet wird. Wird die Ausführung einer Anwendung sehr schnell beendet, ist es möglich, dass der Container weiter neu gestartet wird. Wenn dieser Fehler auftritt, können Sie das Feld restartPolicy auf OnFailure festlegen. Nach dieser Änderung wird die App nur dann neu gestartet, wenn der Beendigungscode nicht 0 ist.

Verbindung zu einem ausgeführten Container herstellen

Wenn Sie Bash-Befehle aus dem Container ausführen möchten, um das Netzwerk zu testen oder zu prüfen, ob Sie Zugriff auf Dateien oder Datenbanken haben, die von Ihrer Anwendung verwendet werden, öffnen Sie eine Shell für den Pod:

kubectl exec -it POD_NAME -- /bin/bash

Wenn sich in Ihrem Pod mehrere Container befinden, fügen Sie -c CONTAINER_NAME hinzu.

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.

Sie können dieses Problem mithilfe der Google Cloud -Konsole oder des kubectl-Befehlszeilentools 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 den problematischen Pod.

  4. Klicken Sie im Menü des Pods auf den Tab Ereignisse.

kubectl

Führen Sie den folgenden Befehl aus, um weitere Informationen zum Container-Image eines Pods zu erhalten:

kubectl describe pod POD_NAME

Problem: Das Image wird nicht gefunden

Wenn Ihr Image nicht gefunden wird, führen Sie die folgenden Schritte aus:

  1. Prüfen Sie, ob der Name des Image korrekt ist.
  2. Prüfen Sie, ob das Tag für das Image korrekt ist. Versuchen Sie es mit :latest oder keinem Tag, um das neueste Image per Pull abzurufen.
  3. Wenn das Image einen vollständigen Registry-Pfad hat, schauen Sie nach, ob es in der von Ihnen verwendeten Docker-Registry vorhanden ist. Falls Sie nur den Image-Namen angegeben haben, prüfen Sie die Docker Hub-Registry.

  4. Versuchen Sie, das Docker-Image in GKE Standard-Clustern manuell herunterzuladen:

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

      Wenn Sie beispielsweise eine SSH-Verbindung zu einer VM herstellen möchten, führen Sie den folgenden Befehl aus:

      gcloud compute ssh VM_NAME --zone=ZONE_NAME

      Ersetzen Sie Folgendes:

    2. Generieren Sie eine Konfigurationsdatei unter /home/[USER]/.docker/config.json:

      docker-credential-gcr configure-docker

      Die Konfigurationsdatei unter /home/[USER]/.docker/config.json muss die Registry des Images im Feld credHelpers enthalten. Die folgende Datei enthält beispielsweise Authentifizierungsinformationen für Images, die unter asia.gcr.io, eu.gcr.io, gcr.io, marketplace.gcr.io und us.gcr.io gehostet werden:

      {
"auths": {},
"credHelpers": {
  "asia.gcr.io": "gcr",
  "eu.gcr.io": "gcr",
  "gcr.io": "gcr",
  "marketplace.gcr.io": "gcr",
  "us.gcr.io": "gcr"
}
}

    3. Versuchen Sie, das Image herunterzuladen:

      docker pull IMAGE_NAME

    Wenn das Abrufen des Bilds manuell funktioniert, müssen Sie wahrscheinlich ImagePullSecrets für einen Pod angeben. Pods können nur auf Image-Pull-Secrets in ihrem eigenen Namespace verweisen. Daher muss dieser Prozess pro Namespace einmal ausgeführt werden.

Fehler: Berechtigung verweigert

Wenn ein Fehler des Typs "Berechtigung verweigert" oder "Kein Pull-Zugriff" auftritt, überprüfen Sie, ob Sie angemeldet sind und/oder Zugriff auf das Image haben. Probieren Sie je nach Registry, in der Sie Ihre Images hosten, eine der folgenden Methoden aus.

Artifact Registry

Wenn sich Ihr Image in Artifact Registry befindet, benötigt das Dienstkonto Ihres Knotenpools Lesezugriff auf das Repository, das das Image enthält.

Weisen Sie dem Dienstkonto die Rolle artifactregistry.reader zu.

gcloud artifacts repositories add-iam-policy-binding REPOSITORY_NAME \
    --location=REPOSITORY_LOCATION \
    --member=serviceAccount:SERVICE_ACCOUNT_EMAIL \
    --role="roles/artifactregistry.reader"

Ersetzen Sie Folgendes:

  • REPOSITORY_NAME: der Name Ihres Artifact Registry-Repositorys
  • REPOSITORY_LOCATION: die Region Ihres Artifact Registry-Repositorys
  • SERVICE_ACCOUNT_EMAIL: die E-Mail-Adresse des IAM-Dienstkontos, das Ihrem Knotenpool zugeordnet ist.

Container Registry

Wenn sich Ihr Image in Container Registry befindet, benötigt das Dienstkonto Ihres Knotenpools Lesezugriff auf den Cloud Storage-Bucket, der das Image enthält.

Weisen Sie dem Dienstkonto die Rolle roles/storage.objectViewer zu, damit es aus dem Bucket lesen kann:

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
    --member=serviceAccount:SERVICE_ACCOUNT_EMAIL \
    --role=roles/storage.objectViewer

Ersetzen Sie Folgendes:

  • SERVICE_ACCOUNT_EMAIL: die E-Mail-Adresse des Dienstkontos, das Ihrem Knotenpool zugeordnet ist. Mit gcloud iam service-accounts list können Sie alle Dienstkonten in Ihrem Projekt auflisten.
  • BUCKET_NAME: Der Name des Cloud Storage-Buckets, der Ihre Images enthält. Mit gcloud storage ls können Sie alle Buckets in Ihrem Projekt auflisten.

Wenn Ihr Registry-Administrator gcr.io-Repositories in Artifact Registry eingerichtet hat, um Images für die Domain gcr.io anstelle von Container Registry zu speichern, müssen Sie Artifact Registry anstelle von Container Registry Lesezugriff gewähren.

Private Registry

Wenn sich Ihr Image in einer Private Registry befindet, benötigen Sie möglicherweise Schlüssel für den Zugriff auf die Images. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Private Repositories verwenden.

Fehler 401 Unauthorized: Images können nicht aus dem Repository der privaten Container Registry abgerufen werden

Wenn Sie ein Image aus einem privaten Container Registry-Repository abrufen, kann ein Fehler ähnlich dem folgenden auftreten:

gcr.io/PROJECT_ID/IMAGE:TAG: rpc error: code = Unknown desc = failed to pull and
unpack image gcr.io/PROJECT_ID/IMAGE:TAG: failed to resolve reference
gcr.io/PROJECT_ID/IMAGE]:TAG: unexpected status code [manifests 1.0]: 401 Unauthorized

Warning  Failed     3m39s (x4 over 5m12s)  kubelet            Error: ErrImagePull
Warning  Failed     3m9s (x6 over 5m12s)   kubelet            Error: ImagePullBackOff
Normal   BackOff    2s (x18 over 5m12s)    kubelet            Back-off pulling image

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

  1. Identifizieren Sie den Knoten, auf dem der Pod ausgeführt wird:

    kubectl describe pod POD_NAME | grep "Node:"

  2. Prüfen Sie, ob der im vorherigen Schritt identifizierte Knoten den Speicherbereich hat:

    gcloud compute instances describe NODE_NAME \
    --zone=COMPUTE_ZONE --format="flattened(serviceAccounts[].scopes)"

    Der Zugriffsbereich des Knotens muss mindestens einen der folgenden Bereiche enthalten:

    serviceAccounts[0].scopes[0]: https://www.googleapis.com/auth/devstorage.read_only
serviceAccounts[0].scopes[0]: https://www.googleapis.com/auth/cloud-platform

    Wenn der Knoten keinen dieser Bereiche enthält, erstellen Sie den Knotenpool neu.

  3. Erstellen Sie den Knotenpool, zu dem der Knoten gehört, mit ausreichendem Umfang neu. Vorhandene Knoten können nicht geändert werden. Sie müssen den Knoten mit dem richtigen Umfang neu erstellen.

    • Empfohlen: Erstellen Sie einen neuen Knotenpool mit dem Bereich gke-default:

      gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --zone=COMPUTE_ZONE \
    --scopes="gke-default"

    • Neuen Knotenpool mit nur Speicherbereich erstellen:

      gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --zone=COMPUTE_ZONE \
    --scopes="https://www.googleapis.com/auth/devstorage.read_only"

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 Google Cloud -Konsole beheben:

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

    Playbook aufrufen

  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 seinen Namen in das Feld Filter ein.

  3. Wählen Sie in der Drop-down-Liste Namespace den Namespace aus, für den Sie Fehler beheben möchten. Wenn Sie Ihren Namespace nicht finden, geben Sie ihn in das Feld Filter 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 über zukünftige PodUnschedulable-Fehler benachrichtigt werden möchten, wählen Sie im Abschnitt Tipps zur zukünftigen Behebung die Option 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). Dies weist darauf hin, dass auf zwei Knoten nicht genügend CPU-Kapazität verfügbar ist, um die Anfragen eines Pods zu erfüllen.

Wenn die Ressourcenanfragen Ihres Pods die eines einzelnen Knotens aus allen infrage kommenden Knotenpools überschreiten, wird der Pod von GKE nicht geplant und es wird auch kein vertikales Skalieren ausgelöst, 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

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.

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 gibt an, dass ein Knoten versucht, einen Port zu verwenden, der bereits belegt ist.

Um das Problem zu beheben, können Sie die Best Practices für Kubernetes befolgen und statt eines hostPort ein NodePort verwenden.

Wenn Sie eine 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 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 Google Cloud -Konsole oder dem kubectl-Befehlszeilentool prüfen.

Console

Führen Sie diese Schritte aus:

  1. Rufen Sie in der Google Cloud -Konsole die Seite Google Kubernetes Engine auf.

    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 untersuchen möchten.

  2. Klicken Sie im Bereich 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: Maximale Anzahl von Pods pro Knoten erreicht

Wenn das Limit für die maximale Anzahl von Pods pro Knoten von allen Knoten im Cluster erreicht wird, befinden sich die Pods im Status „Nicht planbar“. Auf dem Tab Ereignisse des Pods sehen Sie eine Nachricht mit dem Begriff Too many pods.

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

  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 oder dem vorhandenen Knotenpool zusätzliche Knoten hinzu.

Problem: Maximale Knotenpoolgröße erreicht, wenn Cluster Autoscaler aktiviert ist

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 erreicht, Cluster Autoscaler deaktiviert

Wenn der Knotenpool seine 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, damit GKE die Größe Ihres Clusters automatisch anpasst.

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 für GKE hat, um Ihren Cluster zu skalieren. Wenn GKE versucht, Ihrem Cluster einen Knoten hinzuzufügen, um den Pod zu planen, und die Skalierung das verfügbare Kontingent Ihres Projekts überschreiten würde, erhalten Sie die Fehlermeldung scale.up.error.quota.exceeded.

Weitere Informationen finden Sie unter ScaleUp-Fehler.

Problem: Eingestellte APIs

Achten Sie darauf, dass Sie keine veralteten APIs verwenden, die mit der Nebenversion Ihres Clusters entfernt werden. Weitere Informationen finden Sie unter Verworfene Komponenten von GKE.

Fehler: Es sind keine freien Ports für die angeforderten Pod-Ports verfügbar.

Wenn Sie einen ähnlichen Fehler wie den folgenden sehen, haben Sie wahrscheinlich mehrere Pods auf demselben Knoten mit demselben Wert im Feld hostPort definiert:

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.

Wenn Sie einen Pod an eine hostPort binden, schränkt das ein, wo GKE den Pod planen kann, da jede Kombination aus hostIP, hostPort und protocol eindeutig sein muss.

Um das Problem zu beheben, können Sie die Best Practices für Kubernetes befolgen und statt eines hostPort ein NodePort verwenden.

Wenn Sie eine 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 hostPort definiert sind.

Nächste Schritte

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.