Fehlerbehebung bei Autopilot-Clustern

Auf dieser Seite wird beschrieben, wie Sie Probleme mit GKE-Autopilot-Clustern (Google Kubernetes Engine) beheben können.

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

Clusterprobleme

Cluster kann nicht erstellt werden: 0 Knoten registriert

Das folgende Problem tritt auf, wenn Sie versuchen, einen Autopilot-Cluster mit einem IAM-Dienstkonto zu erstellen, das deaktiviert ist oder nicht die erforderlichen Berechtigungen hat. Die Clustererstellung schlägt mit der folgenden Fehlermeldung fehl:

All cluster resources were brought up, but: only 0 nodes out of 2 have registered.

So beheben Sie das Problem:

  1. Prüfen Sie, ob das Compute Engine-Standarddienstkonto oder das benutzerdefinierte IAM-Dienstkonto, das Sie verwenden möchten, deaktiviert ist:

    gcloud iam service-accounts describe SERVICE_ACCOUNT

    Ersetzen Sie SERVICE_ACCOUNT durch die E-Mail-Adresse des Dienstkontos, z. B. my-iam-account@my-first-project.iam.gserviceaccount.com.

    Wenn das Dienstkonto deaktiviert ist, sieht die Ausgabe in etwa so aus:

    disabled: true
displayName: my-service-account
email: my-service-account@my-project.iam.gserviceaccount.com
...

  2. Wenn das Dienstkonto deaktiviert ist, aktivieren Sie es:

    gcloud iam service-accounts enable SERVICE_ACCOUNT

Wenn das Dienstkonto aktiviert ist und der Fehler weiterhin besteht, gewähren Sie dem Dienstkonto die für GKE erforderlichen Mindestberechtigungen:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SERVICE_ACCOUNT" \
    --role roles/container.nodeServiceAccount

Namespace bleibt im Abbruchstatus, wenn der Cluster 0 Knoten hat

Das folgende Problem tritt auf, wenn Sie einen Namespace in einem Cluster löschen, nachdem der Cluster auf null Knoten herunterskaliert wurde. Die Komponente metrics-server kann die Anfrage zum Löschen des Namespace nicht akzeptieren, da die Komponente null Replikate hat.

Führen Sie den folgenden Befehl aus, um dieses Problem zu diagnostizieren:

kubectl describe ns/NAMESPACE_NAME

Ersetzen Sie NAMESPACE_NAME durch den Namen des Namespace.

Die Ausgabe sieht so aus:

Discovery failed for some groups, 1 failing: unable to retrieve the complete
list of server APIs: metrics.k8s.io/v1beta1: the server is currently unable to
handle the request

Zum Beheben dieses Problems skalieren Sie jede Arbeitslast vertikal, damit GKE einen neuen Knoten erstellt. Wenn der Knoten bereit ist, wird die Anfrage zum Löschen des Namespace automatisch abgeschlossen. Nachdem GKE den Namespace gelöscht hat, skalieren Sie die Arbeitslast wieder herunter.

Skalierungsprobleme

Knoten konnte nicht hochskaliert werden, da der Pod möglicherweise nicht geplant wird

Das folgende Problem tritt auf, wenn das Logging des seriellen Ports in Ihrem Google Cloud-Projekt deaktiviert ist. GKE Autopilot-Cluster erfordern ein serielles Port-Logging, um Knotenprobleme effektiv zu beheben. Wenn das Logging des seriellen Ports deaktiviert ist, kann Autopilot keine Knoten zum Ausführen Ihrer Arbeitslasten bereitstellen.

Die Fehlermeldung in Ihrem Kubernetes-Ereignislog sieht in etwa so aus:

LAST SEEN   TYPE      REASON          OBJECT                          MESSAGE
12s         Warning   FailedScaleUp   pod/pod-test-5b97f7c978-h9lvl   Node scale up in zones associated with this pod failed: Internal error. Pod is at risk of not being scheduled

Das Logging des seriellen Ports kann auf Organisationsebene über eine Organisationsrichtlinie deaktiviert werden, die die Einschränkung compute.disableSerialPortLogging erzwingt. Das Logging des seriellen Ports kann auch auf Instanz- oder VM-Instanzebene deaktiviert werden.

So beheben Sie das Problem:

  1. Bitten Sie den Administrator der Google Cloud-Organisationsrichtlinien, die Einschränkung compute.disableSerialPortLogging im Projekt mit Ihrem Autopilot-Cluster zu entfernen.
  2. Wenn Sie keine Organisationsrichtlinie haben, die diese Einschränkung erzwingt, sollten Sie das Logging des seriellen Ports in den Projektmetadaten aktivieren. Für diese Aktion ist die IAM-Berechtigung compute.projects.setCommonInstanceMetadata erforderlich.

Knoten konnte nicht hochskaliert werden: Ressourcen für GCE erschöpft

Das folgende Problem tritt auf, wenn Ihre Arbeitslasten mehr Ressourcen anfordern, als in dieser Compute Engine-Region oder -Zone verfügbar sind. Ihre Pods bleiben möglicherweise im Status Pending.

  • Prüfen Sie die Pod-Ereignisse:

    kubectl get events --for='POD_NAME' --types=Warning

    Ersetzen Sie RESOURCE_NAME durch den Namen der ausstehenden Kubernetes-Ressource. Beispiel: pod/example-pod.

    Die Ausgabe sieht in etwa so aus:

    LAST SEEN         TYPE            REASON                  OBJECT                   Message
19m               Warning         FailedScheduling        pod/example-pod          gke.io/optimize-utilization-scheduler  0/2 nodes are available: 2 node(s) didn't match Pod's node affinity/selector. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling.
14m               Warning         FailedScheduling        pod/example-pod          gke.io/optimize-utilization-scheduler  0/2 nodes are available: 2 node(s) didn't match Pod's node affinity/selector. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling.
12m (x2 over 18m) Warning         FailedScaleUp           cluster-autoscaler       Node scale up in zones us-central1-f associated with this pod failed: GCE out of resources. Pod is at risk of not being scheduled.
34s (x3 over 17m) Warning         FailedScaleUp           cluster-autoscaler       Node scale up in zones us-central1-b associated with this pod failed: GCE out of resources. Pod is at risk of not being scheduled.

Versuchen Sie Folgendes, um dieses Problem zu beheben:

  • Stellen Sie den Pod in einer anderen Region oder Zone bereit. Wenn Ihr Pod eine zonale Einschränkung wie einen Topologieselektor hat, entfernen Sie die Einschränkung nach Möglichkeit. Eine Anleitung finden Sie unter GKE-Pods in bestimmten Zonen platzieren.
  • Erstellen Sie einen Cluster in einer anderen Region und wiederholen Sie die Bereitstellung.
  • Versuchen Sie es mit einer anderen Compute-Klasse. Compute-Klassen, die von kleineren Compute Engine-Maschinentypen unterstützt werden, haben mit größerer Wahrscheinlichkeit verfügbare Ressourcen. Der Standardmaschinentyp für Autopilot hat beispielsweise die höchste Verfügbarkeit. Eine Liste der Compute-Klassen und der entsprechenden Maschinentypen finden Sie unter Wann werden bestimmte Compute-Klassen verwendet?.
  • Wenn Sie GPU-Arbeitslasten ausführen, ist die angeforderte GPU möglicherweise nicht an Ihrem Knotenstandort verfügbar. Stellen Sie Ihre Arbeitslast an einem anderen Standort bereit oder fordern Sie einen anderen GPU-Typ an.

Ziehen Sie die folgenden Ansätze in Betracht, um Probleme bei der vertikalen Skalierung zu vermeiden, die durch die Ressourcenverfügbarkeit in Zukunft verursacht werden:

Knoten können nicht hochskaliert werden: Zonale Pod-Ressourcen überschritten

Das folgende Problem tritt auf, wenn Autopilot keine neuen Knoten für einen Pod in einer bestimmten Zone bereitstellt, da ein neuer Knoten gegen Ressourcenlimits verstoßen würde.

Die Fehlermeldung in Ihren Logs sieht in etwa so aus:

    "napFailureReasons": [
            {
              "messageId": "no.scale.up.nap.pod.zonal.resources.exceeded",
              ...

Dieser Fehler bezieht sich auf ein noScaleUp-Ereignis, bei dem die automatische Knotenbereitstellung keine Knotengruppe für den Pod in der Zone bereitgestellt hat.

Wenn dieser Fehler auftritt, prüfen Sie Folgendes:

Probleme mit Arbeitslasten

Pods bleiben im Status "Ausstehend"

Ein Pod bleibt möglicherweise im Status Pending hängen, wenn Sie einen bestimmten Knoten für Ihren Pod auswählen, aber die Summe der Ressourcenanfragen im Pod und in DaemonSets, die auf dem Knoten ausgeführt werden müssen, den maximal zuweisbare Kapazität des Knotens überschreitet. Dies kann dazu führen, dass Ihr Pod den Status Pending erhält und ungeplant bleibt.

Um dieses Problem zu vermeiden, sollten Sie die Größe Ihrer bereitgestellten Arbeitslasten prüfen, damit sie innerhalb des unterstützten Maximalwerts für Ressourcenanfragen für Autopilot liegen.

Sie können auch versuchen, Ihre DaemonSets zu planen, bevor Sie die regulären Arbeitslast-Pods planen.

Pods bleiben bei der Beendigung oder der Erstellung hängen

Ein bekanntes Problem führt dazu, dass Pods gelegentlich in einem der folgenden Status hängen bleiben:

  • Terminating
  • CreateContainerError

Dieses Problem tritt leicht auf, wenn Sie Burst-Pods in GKE-Umgebungen verwenden, die alle der folgenden Bedingungen erfüllen:

  1. Die GKE-Version des Knotens ist 1.29.2-gke.1060000 oder höher.
  2. Ihr Pod verwendet eine der folgenden Compute-Klassen:
    • Standard-Compute-Klasse für allgemeine Zwecke
    • Die Compute-Klasse Balanced
    • Die Compute-Klasse Scale-Out

Zur Behebung dieses Problems haben wir das Bursting in GKE Autopilot-Clustern, die am oder nach dem 24. April 2024 erstellt oder auf Version 1.29.2-gke.1060000 und später erstellt oder aktualisiert wurden, vorübergehend deaktiviert. Cluster, die Bursting vor dem 24. April 2024 aktiviert haben, unterstützen weiterhin Bursting.

Wenn Ihre Pods bereits im Status Terminating oder CreateContainerError hängen bleiben, führen Sie die folgenden Schritte aus:

  1. Beschreiben Sie den hängen gebliebenen Pod:

    kubectl describe pod POD_NAME

    Ersetzen Sie POD_NAME durch den Namen des hängen gebliebenen Pods.

    Wenn der Pod aufgrund dieses Problems hängen bleibt, zeigt das Feld Events in der Ausgabe kein Ereignis an, das den Status Terminating oder CreateContainerError erläutert, wie im folgenden Beispiel gezeigt. Ausgabe:

    # Fields omitted for readability
Containers:
  startup-script:
    State:          Waiting
      Reason:       CreateContainerError
    Last State:     Terminated
      Reason:       Unknown
      Exit Code:    255
      Started:      Sun, 14 Apr 2024 20:04:08 +0000
      Finished:     Sun, 14 Apr 2024 20:04:17 +0000
    Ready:          False
# Fields omitted for readability
Events:
  Type    Reason   Age                      From     Message
  ----    ------   ----                     ----     -------
  Normal  Pulling  2m49s (x12236 over 46h)  kubelet  Pulling image "gcr.io/google-containers/startup-script:v1"

  2. Leeren Sie die betroffenen Knoten mithilfe der Schritte im Abschnitt Konsistente unzuverlässige Arbeitslastleistung auf einem bestimmten Knoten.

Wenn Sie eine Ausnahme anfordern möchten, damit Sie das Bursting in den betroffenen GKE-Versionen verwenden oder es in einem Cluster deaktivieren können, der noch Bursting unterstützt, wenden Sie sich an Cloud Customer Care.

Konsistent unzuverlässige Arbeitslastleistung auf einem bestimmten Knoten

Wenn in GKE-Version 1.24 und höher Ihre Arbeitslasten auf einem bestimmten Knoten konsistent Unterbrechungen, Abstürze oder ein ähnliches unzuverlässiges Verhalten aufweisen, können Sie GKE über den problematischen Knoten informieren, indem Sie ihn mit folgendem Befehl sperren:

kubectl drain NODE_NAME --ignore-daemonsets

Ersetzen Sie NODE_NAME durch den Namen des problematischen Knotens. Sie ermitteln den Namen des Knotens durch Ausführen von kubectl get nodes.

GKE führt Folgendes aus:

  • Entfernt vorhandene Arbeitslasten vom Knoten und beendet die Planung von Arbeitslasten auf diesem Knoten.
  • Entfernt automatisch entfernte Arbeitslasten, die von einem Controller, z. B. einem Deployment oder einem StatefulSet, auf anderen Knoten verwaltet werden.
  • Beendet alle Arbeitslasten, die auf dem Knoten verbleiben, und repariert oder erstellt den Knoten im Laufe der Zeit neu.
  • Wenn Sie Autopilot verwenden, fährt GKE herunter und ersetzt den Knoten sofort und ignoriert alle konfigurierten PodDisruptionBudgets.

Pods brauchen länger als erwartet, um auf leeren Clustern zu planen

Dieses Ereignis tritt auf, wenn Sie eine Arbeitslast in einem Autopilot-Cluster bereitstellen, der keine anderen Arbeitslasten hat. Autopilot-Cluster beginnen mit null verwendbaren Knoten und skalieren auf null Knoten, wenn der Cluster leer ist, um nicht ausgelastete Rechenressourcen im Cluster zu vermeiden. Durch das Bereitstellen einer Arbeitslast in einem Cluster mit null Knoten wird ein Hochskalierungsereignis ausgelöst.

In diesem Fall funktioniert Autopilot wie vorgesehen und es sind keine Maßnahmen erforderlich. Ihre Arbeitslast wird nach dem Start der neuen Knoten wie erwartet bereitgestellt.

Prüfen Sie, ob Ihre Pods auf neue Knoten warten:

  1. Beschreiben Sie den ausstehenden Pod:

    kubectl describe pod POD_NAME

    Ersetzen Sie POD_NAME durch den Namen des ausstehenden Pods.

  2. Prüfen Sie den Abschnitt Events der Ausgabe. Wenn der Pod auf neue Knoten wartet, sieht die Ausgabe in etwa so aus:

    Events:
  Type     Reason            Age   From                                   Message
  ----     ------            ----  ----                                   -------
  Warning  FailedScheduling  11s   gke.io/optimize-utilization-scheduler  no nodes available to schedule pods
  Normal   TriggeredScaleUp  4s    cluster-autoscaler                     pod triggered scale-up: [{https://www.googleapis.com/compute/v1/projects/example-project/zones/example-zone/instanceGroups/gk3-example-cluster-pool-2-9293c6db-grp 0->1 (max: 1000)} {https://www.googleapis.com/compute/v1/projects/example-project/zones/example-zone/instanceGroups/gk3-example-cluster-pool-2-d99371e7-grp 0->1 (max: 1000)}]

    Das Ereignis TriggeredScaleUp zeigt, dass Ihr Cluster von null Knoten auf so viele Knoten hochskaliert wird, wie zum Ausführen der bereitgestellten Arbeitslast erforderlich sind.

Nächste Schritte

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