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 events --for='pod/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

Arbeitslasten, die mit flüchtigem Speicherfehler hängen bleiben

GKE erstellt keine Pods, wenn Ihre sitzungsspezifischen Pod-Speicheranfragen das Autopilot-Maximal von 10 GiB in GKE-Version 1.28.6-gke.1317000 und höher überschreiten.

Um dieses Problem zu diagnostizieren, beschreiben Sie den Arbeitslast-Controller, z. B. die Bereitstellung oder den Job:

kubectl describe CONTROLLER_TYPE/CONTROLLER_NAME

Ersetzen Sie Folgendes:

  • CONTROLLER_TYPE: der Typ des Arbeitslast-Controllers, z. B. replicaset oder daemonset. Eine Liste der Controller-Typen finden Sie unter Arbeitslastverwaltung.
  • CONTROLLER_NAME: der Name der hängen gebliebenen Arbeitslast.

Wenn der Pod nicht erstellt wird, weil die Anfrage für sitzungsspezifischen Speicher das Maximum überschreitet, sieht die Ausgabe in etwa so aus:

# lines omitted for clarity

Events:

{"[denied by autogke-pod-limit-constraints]":["Max ephemeral-storage requested by init containers for workload '' is higher than the Autopilot maximum of '10Gi'.","Total ephemeral-storage requested by containers for workload '' is higher than the Autopilot maximum of '10Gi'."]}

Aktualisieren Sie Ihre Anfragen für den sitzungsspezifischen Speicher, damit die Gesamtmenge des sitzungsspezifischen Speichers, die von Arbeitslastcontainern und Containern angefordert wird, in die Webhooks eingefügt werden, unter dem zulässigen Maximum liegt. Weitere Informationen zum Maximum finden Sie unter Ressourcenanfragen in Autopilot. für die Arbeitslastkonfiguration.

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. Auf Ihren Knoten werden GKE-Versionen ab 1.29.2-gke.1060000 bis, aber nicht einschließlich 1.30.2-gke.1394000 ausgeführt.
  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

Aktualisieren Sie Ihre Steuerungsebene auf die GKE-Version 1.30.2-gke.1394000 oder höher, um dieses Problem zu beheben. Pods, die bereits im Status Terminating oder CreateContainerError verbleiben, werden korrekt bereitgestellt, nachdem GKE die Pods auf Knoten, auf denen eine korrigierte Version ausgeführt wird, neu erstellt.

Wenn Sie einen Autopilot-Cluster aktualisieren, aktualisiert GKE die Worker-Knoten so, dass sie der Version der Steuerungsebene im Laufe der Zeit entsprechen. Ein Neustart der Steuerungsebene ist erforderlich, um das Bursting zu aktivieren, und muss erfolgen, nachdem alle Knoten eine unterstützte Version ausgeführt haben. Die Steuerungsebene wird bei Vorgängen wie Skalierung, Upgrades oder Wartungen automatisch etwa einmal pro Woche neu gestartet.

So lösen Sie einen Neustart der Steuerungsebene manuell aus:

  1. Prüfen Sie, ob auf allen Knoten die Version 1.30.2-gke.1349000 oder höher ausgeführt wird:

    kubectl get nodes

    Die Ausgabe sieht in etwa so aus:

    NAME                                          STATUS   ROLES    AGE     VERSION
gk3-ap-cluster-1-default-pool-18092e49-mllk   Ready    <none>   4m26s   v1.30.2-gke.1349000

    Alle Knoten in der Ausgabe müssen die erforderliche Version oder höher anzeigen.

  2. Starten Sie manuell ein Upgrade der Steuerungsebene auf dieselbe Version, die der Cluster bereits verwendet. Eine Anleitung finden Sie unter Manuelles Upgrade der Steuerungsebene.

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. Beispiele:

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.