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 so, dass GKE ausgelöst wird, um einen neuen Knoten zu erstellen. Wenn der Knoten bereit ist, wird die Namespace-Löschanfrage 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 zur Verfügung stehen. Ihre Pods verbleiben 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 hat, wie z. B. eine Topologieauswahl, entfernen Sie diese Einschränkung nach Möglichkeit. Anweisungen finden Sie unter GKE-Pods in bestimmten Zonen verwenden.
  • Erstellen Sie einen Cluster in einer anderen Region und wiederholen Sie die Bereitstellung.
  • Versuchen Sie es mit einer anderen Compute-Klasse. Bei Compute-Klassen, die von kleineren Compute Engine-Maschinentypen unterstützt werden, ist es wahrscheinlicher, dass sie verfügbare Ressourcen haben. Der Standardmaschinentyp für Autopilot hat beispielsweise die höchste Verfügbarkeit. Eine Liste mit Rechenklassen und den entsprechenden Maschinentypen finden Sie unter Wann bestimmte Computing-Klassen verwendet werden sollten.
  • 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.

Um Probleme beim Hochskalieren aufgrund der Ressourcenverfügbarkeit in Zukunft zu vermeiden, sollten Sie die folgenden Ansätze in Betracht ziehen:

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 beim Beenden oder Erstellen hängen

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

  • Terminating
  • CreateContainerError

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

  1. Die GKE-Version Ihres Knotens ist 1.29.2-gke.1060000 oder höher
  2. Ihr Pod verwendet eine der folgenden Computing-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 auf Version 1.29.2-gke.1060000 und höher oder nach dem 24. April 2024 erstellt oder aktualisiert wurden, vorübergehend deaktiviert. Für Cluster, die das Bursting vor dem 24. April 2024 aktiviert haben, wird es weiterhin unterstützt.

Wenn Ihre Pods bereits im Status Terminating oder CreateContainerError hängen geblieben sind, 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 erklärt, wie in der folgenden Beispielausgabe zu sehen:

    # 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 in Dauerhaft unzuverlässige Arbeitslastleistung auf einem bestimmten Knoten .

Um eine Ausnahme anzufordern, damit Sie Bursting in der betroffenen GKE verwenden können, oder um Bursting in einem Cluster zu deaktivieren, der weiterhin 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 aus dem Knoten und beendet die Planung von Arbeitslasten für diesen 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, wird GKE heruntergefahren und der Knoten sofort ersetzt und alle konfigurierten PodDisruptionBudgets werden ignoriert.

Die Planung durch Pods bei leeren Clustern dauert länger als erwartet

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 Starten 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 an, dass der Cluster von null auf so viele Knoten wie erforderlich hochskaliert wird, um Ihre bereitgestellte Arbeitslast auszuführen.

Der Zugriff auf zugrunde liegende Knoten ist in einem GKE Autopilot-Cluster nicht zulässig. Daher muss das Dienstprogramm tcpdump in einem Pod ausgeführt und dann mit dem Befehl „kubectl cp“ kopiert werden. Wenn Sie das Dienstprogramm tcpdump im Allgemeinen in einem Pod in einem GKE Autopilot-Cluster ausführen, wird möglicherweise der folgende Fehler angezeigt:

    tcpdump: eth0: You don't have permission to perform this capture on that device
    (socket: Operation not permitted)

Dies liegt daran, dass GKE Autopilot standardmäßig einen Sicherheitskontext auf alle Pods anwendet, in dem die NET_RAW-Funktion entfernt wird, um potenzielle Sicherheitslücken zu mindern. Beispiel:

apiVersion: v1
kind: Pod
metadata:
  labels:
    app: tcpdump
  name: tcpdump
spec:
  containers:
  - image: nginx
    name: nginx
    resources:
      limits:
        cpu: 500m
        ephemeral-storage: 1Gi
        memory: 2Gi
      requests:
        cpu: 500m
        ephemeral-storage: 1Gi
        memory: 2Gi
    securityContext:
      capabilities:
        drop:
        - NET_RAW

Wenn für Ihre Arbeitslast die Funktion NET_RAW erforderlich ist, können Sie diese wieder aktivieren:

  1. Fügen Sie im Abschnitt securityContext der YAML-Spezifikation Ihres Pods die Funktion NET_RAW hinzu:

    securityContext:
  capabilities:
    add:
    - NET_RAW

  2. Führen Sie tcpdump in einem Pod aus:

    tcpdump port 53 -w packetcap.pcap
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

  3. Kopieren Sie ihn mit dem Befehl kubectl cp zur weiteren Analyse auf Ihren lokalen Computer:

    kubectl cp POD_NAME:/PATH_TO_FILE/FILE_NAME/PATH_TO_FILE/FILE_NAME

  4. Verwenden Sie kubectl exec, um den Befehl tcpdump auszuführen, um ein Netzwerkpaket zu erfassen und die Ausgabe weiterzuleiten:

    kubectl exec -it POD_NAME -- bash -c "tcpdump port 53 -w -" > packet-new.pcap

Nächste Schritte

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