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:
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 ...
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:
- Bitten Sie den Administrator der Google Cloud-Organisationsrichtlinien, die Einschränkung
compute.disableSerialPortLogging
im Projekt mit Ihrem Autopilot-Cluster zu entfernen. - 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:
- Mit Kubernetes PriorityClasses können Sie zusätzliche Rechenkapazität in Ihrem Cluster bereitstellen. Weitere Informationen finden Sie unter Zusätzliche Rechenkapazität für eine schnelle Pod-Skalierung bereitstellen.
- Verwenden Sie Compute Engine-Kapazitätsreservierungen mit den Compute-Klassen "Leistung" oder "Accelerator". Weitere Informationen finden Sie unter Reservierte zonale Ressourcen nutzen.
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:
- Ihre Pods haben ausreichend Arbeitsspeicher und CPU.
- Der CIDR-Bereich der Pod-IP-Adresse ist groß genug, um die erwartete maximale Clustergröße zu unterstützen.
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:
- Die GKE-Version des Knotens ist 1.29.2-gke.1060000 oder höher.
- 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:
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 StatusTerminating
oderCreateContainerError
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"
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:
Beschreiben Sie den ausstehenden Pod:
kubectl describe pod POD_NAME
Ersetzen Sie
POD_NAME
durch den Namen des ausstehenden Pods.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.