Fehlerbehebung bei Autopilot-Clustern

Probleme mit Ihren Autopilot-Clustern in Google Kubernetes Engine (GKE) können sich auf die Verfügbarkeit und Betriebseffizienz Ihrer Anwendung auswirken. Diese Probleme können den gesamten Lebenszyklus Ihrer Anwendungen beeinträchtigen, von der ersten Bereitstellung bis zur Skalierung unter Last.

Auf dieser Seite können Sie häufige Probleme mit Autopilot-Clustern diagnostizieren und beheben. Hier finden Sie Informationen zur Fehlerbehebung bei Problemen beim Erstellen von Clustern, die die Bereitstellung Ihres Clusters verhindern, bei Skalierungsproblemen wie out of resources-Fehlern und bei arbeitslastspezifischen Problemen wie Fehlern beim flüchtigen Speicher oder Pods, die im Status Pending hängen bleiben.

Diese Informationen sind wichtig für Anwendungsentwickler, die dafür sorgen müssen, dass ihre Anwendungen reibungslos bereitgestellt und ausgeführt werden, sowie für Plattformadministratoren und ‑betreiber, die für die allgemeine Integrität und Ressourcenverwaltung von Autopilot-Clustern verantwortlich sind. Weitere Informationen zu den gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud -Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und ‑Aufgaben.

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

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 annehmen, da sie keine 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

Um dieses Problem zu beheben, skalieren Sie eine beliebige Arbeitslast hoch, damit GKE einen neuen Knoten erstellt. 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 IhremGoogle 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 Organisationsrichtlinie Google Cloud , 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.

  • Pod-Ereignisse prüfen:

    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 versuchen Sie es noch einmal.
  • 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 am Standort Ihres Knotens verfügbar. Versuchen Sie, Ihre Arbeitslast an einem anderen Ort bereitzustellen oder eine andere GPU anzufordern.

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 Anfragen für den sitzungsspezifischen Speicher von Pods das Autopilot-Maximum von 10 GiB in GKE-Version 1.28.6-gke.1317000 und höher überschreiten.

So diagnostizieren Sie dieses Problem:

kubectl describe CONTROLLER_TYPE/CONTROLLER_NAME

Ersetzen Sie Folgendes:

  • CONTROLLER_TYPE: der Typ des Arbeitslastcontrollers, z. B. replicaset oder daemonset. Eine Liste der Controllertypen finden Sie unter Arbeitslastverwaltung.
  • CONTROLLER_NAME: Der Name der Arbeitslast, die nicht abgeschlossen werden kann.

Wenn der Pod nicht erstellt wird, weil die Anfrage für flüchtigen 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 die Anfragen für flüchtigen Speicher, sodass der von Arbeitslastcontainern und von Containern, die von Webhooks eingefügt werden, angeforderte flüchtige Speicher insgesamt kleiner oder gleich dem zulässigen Maximum ist. Weitere Informationen zum Maximum finden Sie unter Ressourcenanfragen in Autopilot.

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.

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 nutzbaren Knoten und werden auf null Knoten skaliert, wenn der Cluster leer ist. So werden nicht genutzte Rechenressourcen im Cluster vermieden. 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. Sehen Sie sich den Abschnitt Events der Ausgabe an. 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.

System-Pods können nicht auf leeren Clustern geplant werden

Dieses Ereignis tritt auf, wenn keine Ihrer eigenen Arbeitslasten in einem Cluster ausgeführt werden, was dazu führt, dass der Cluster auf null Knoten herunterskaliert wird. Autopilot-Cluster beginnen mit null nutzbaren Knoten und werden auf null Knoten herunterskaliert, wenn Sie keine Ihrer Arbeitslasten im Cluster ausführen. Dadurch werden verschwendete Rechenressourcen im Cluster minimiert.

Wenn ein Cluster auf null Knoten herunterskaliert wird, werden GKE-Systemarbeitslasten nicht geplant und bleiben im Status Pending. Das ist ein erwartetes Verhalten und Sie müssen nichts unternehmen. Wenn Sie das nächste Mal eine Arbeitslast im Cluster bereitstellen, skaliert GKE den Cluster hoch und die ausstehenden System-Pods werden auf diesen Knoten ausgeführt.

So prüfen Sie, ob System-Pods aufgrund eines leeren Clusters ausstehend sind:

  1. Prüfen Sie, ob Ihr Cluster Knoten enthält:

    kubectl get nodes

    Die Ausgabe sieht so aus, was darauf hinweist, dass der Cluster keine Knoten hat:

    No resources found

  2. Prüfen Sie den Status der System-Pods:

    kubectl get pods --namespace=kube-system

    Die Ausgabe sieht etwa so aus:

    NAME                                                       READY   STATUS    RESTARTS   AGE
antrea-controller-horizontal-autoscaler-6d97f7cf7c-ngfd2   0/1     Pending   0          9d
egress-nat-controller-84bc985778-6jcwl                     0/1     Pending   0          9d
event-exporter-gke-5c5b457d58-7njv7                        0/2     Pending   0          3d5h
event-exporter-gke-6cd5c599c6-bn665                        0/2     Pending   0          9d
konnectivity-agent-694b68fb7f-gws8j                        0/2     Pending   0          3d5h
konnectivity-agent-7d659bf64d-lp4kt                        0/2     Pending   0          9d
konnectivity-agent-7d659bf64d-rkrw2                        0/2     Pending   0          9d
konnectivity-agent-autoscaler-5b6ff64fcd-wn7fw             0/1     Pending   0          9d
konnectivity-agent-autoscaler-cc5bd5684-tgtwp              0/1     Pending   0          3d5h
kube-dns-65ccc769cc-5q5q7                                  0/5     Pending   0          3d5h
kube-dns-7f7cdb9b75-qkq4l                                  0/5     Pending   0          9d
kube-dns-7f7cdb9b75-skrx4                                  0/5     Pending   0          9d
kube-dns-autoscaler-6ffdbff798-vhvkg                       0/1     Pending   0          9d
kube-dns-autoscaler-8b7698c76-mgcx8                        0/1     Pending   0          3d5h
l7-default-backend-87b58b54c-x5q7f                         0/1     Pending   0          9d
metrics-server-v1.31.0-769c5b4896-t5jjr                    0/1     Pending   0          9d

  3. Prüfen Sie den Grund dafür, warum die System-Pods den Status Pending haben:

    kubectl describe pod --namespace=kube-system SYSTEM_POD_NAME

    Ersetzen Sie SYSTEM_POD_NAME durch den Namen eines beliebigen System-Pods aus der Ausgabe des vorherigen Befehls.

    Die Ausgabe sieht etwa so aus:

    ...
Events:
Type     Reason            Age                       From               Message
----     ------            ----                      ----               -------
Warning  FailedScheduling  4m35s (x27935 over 3d5h)  default-scheduler  no nodes available to schedule pods
...

    In der Ausgabe gibt der Wert no nodes available to schedule pods im Feld Message für das Ereignis FailedScheduling an, dass der System-Pod nicht geplant wurde, weil der Cluster leer ist.

Der Zugriff auf die zugrunde liegenden Knoten ist in einem GKE Autopilot-Cluster nicht zulässig. Daher muss das tcpdump-Dienstprogramm in einem Pod ausgeführt und dann mit dem Befehl „kubectl cp“ kopiert werden. Wenn Sie das tcpdump-Dienstprogramm normalerweise 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)

Das liegt daran, dass GKE Autopilot standardmäßig einen Sicherheitskontext auf alle Pods anwendet, der die NET_RAW-Funktion entfernt, um potenzielle Sicherheitslücken zu minimieren. 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:
        # This section drops NET_RAW to mitigate security vulnerabilities
        drop:
        - NET_RAW

Wenn Ihre Arbeitslast die Funktion NET_RAW erfordert, können Sie sie so wieder aktivieren:

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

    securityContext:
  capabilities:
    add:
    - NET_RAW

  2. tcpdump in einem Pod ausführen:

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

  3. Verwenden Sie den Befehl kubectl cp, um die Datei zur weiteren Analyse auf Ihren lokalen Computer zu kopieren:

    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 Netzwerkpakete zu erfassen und die Ausgabe umzuleiten:

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

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 weitere Hilfe, z. B. zu den folgenden Themen: