Auf dieser Seite werden bekannte Probleme mit GKE aufgeführt. Diese Seite richtet sich an Administratoren und Architekten, die den Lebenszyklus der zugrunde liegenden technischen Infrastruktur verwalten und auf Benachrichtigungen und Seiten reagieren, wenn Service Level Objectives (SLOs) nicht erfüllt werden oder Anwendungen ausfallen.
Auf dieser Seite sind bekannte Probleme für alle unterstützten Versionen und für die beiden Nebenversionen aufgeführt, die der frühesten Version im erweiterten Support unmittelbar vorausgehen. Nachdem eine Version das Ende des erweiterten Supports erreicht hat, werden alle N-2-Probleme entfernt. Wenn beispielsweise Version 1.30 das Ende des erweiterten Supports erreicht, werden bekannte Probleme, die für Version 1.28 und früher spezifisch sind, entfernt.
Wenn Sie am Google-Entwicklerprogramm teilnehmen, speichern Sie diese Seite, um Benachrichtigungen zu erhalten, wenn eine Versionsanmerkung zu dieser Seite veröffentlicht wird. Weitere Informationen finden Sie unter Gespeicherte Seiten.
Zum Filtern der bekannten Probleme nach einer Produktversion oder -kategorie wählen Sie in den folgenden Drop-down-Menüs die gewünschten Filter aus.
Wählen Sie Ihre GKE-Version aus:
Wählen Sie eine Kategorie für Ihr Problem aus:
Oder suchen Sie nach Ihrem Problem:
| Kategorie | Identifizierte Version(en) | Korrigierte Version(en) | Problem und Problemumgehung |
|---|---|---|---|
| Vorgang | 1.33-Versionen vor 1.33.4-gke.1036000 | 1.33.4-gke.1036000 und höher |
Falsche Leistungsstufe für dynamisch bereitgestellte Lustre-InstanzenWenn Sie eine Lustre-Instanz dynamisch bereitstellen, schlägt die Instanzerstellung mit einem Workaround: Führen Sie ein Upgrade des GKE-Cluster auf Version 1.33.4-gke.1036000 oder höher durch. Wenn Sie den Stable Channel verwenden, ist möglicherweise noch keine neuere Version verfügbar. In diesem Fall können Sie manuell eine Version aus den Kanälen „Regelmäßig“ oder „Schnell“ auswählen, die den Fix enthält. |
| Vorgang |
|
1.33.3-gke.1266000 und höher |
Eingabe-/Ausgabefehler beim Umbenennen oder Verschieben von Dateien mit dem Cloud Storage FUSE-CSI-TreiberWenn Sie eine betroffene Version des Cloud Storage FUSE CSI-Treibers verwenden, kann das Umbenennen oder Verschieben von Dateien in Cloud Storage-Buckets mit einem E/A-Fehler fehlschlagen. Workaround: Fügen Sie Ihrem Pod-Manifest vorübergehend eine bestimmte Sidecar-Bilddefinition hinzu. Fügen Sie im Abschnitt # Add the following block to use the fixed sidecar image - name: gke-gcsfuse-sidecar image: gcr.io/gke-release/gcs-fuse-csi-driver-sidecar-mounter:v1.8.9-gke.2 Weitere Informationen finden Sie im Pod-Manifest unter Privates Image für den Sidecar-Container konfigurieren. Nachdem Sie Ihren Cluster auf eine korrigierte GKE-Version oder höher aktualisiert haben, müssen Sie den gesamten |
| Logging und Monitoring | Alle Versionen | TBD |
Race-Bedingung in
|
| Upgrades | 1.33 | 1.33.2-gke.1043000 |
Niedrigeres Limit für offene Dateien mit containerd 2.0Für Knotenpools mit GKE-Version 1.33, die containerd 2.0 verwenden, wird das standardmäßige Softlimit für offene Dateien ( Dies ist eine Änderung in containerd selbst (siehe containerd PR #8924), bei der Bei Arbeitslasten, die ein höheres Standard-Softlimit erwarten (z. B. solche, die implizit auf dem vorherigen höheren Standardwert basieren), kann es zu Fehlern wie Lösung Führen Sie ein Upgrade von einer früheren 1.33-Patchversion auf 1.33.2-gke.1043000 oder höher durch. Workaround: Sie haben folgende Möglichkeiten, um das Limit für offene Dateien für Ihre Arbeitslasten zu erhöhen:
|
| Upgrades | 1.31.5-gke.1169000, 1.32.1-gke.1376000 | 1.31.7-gke.1164000, 1.32.3-gke.1512000 |
Ungültiger CRD-Status.storedVersions für verwaltete CRDsEinige von GKE verwaltete CRDs haben möglicherweise ein ungültiges Dieses Problem betrifft Cluster, die die folgenden beiden Bedingungen erfüllen:
Workaround: Der empfohlene Workaround besteht darin, Clusterupgrades zu verzögern, bis das Problem behoben ist. Wenn Sie wissen, dass Ihr Cluster nicht unterstützte Versionen von CRD-Objekten enthält, können Sie diese Versionen mit dem Befehl |
| Betrieb, Logging und Monitoring | 1.32.2-gke.1652000, 1.31.6-gke.1221000, 1.30.10-gke.1227000 |
|
Fehlende Messwerte oder Workload Autoscaler wird nicht skaliertNachdem die Clustergröße um mehr als fünf Knoten zugenommen hat, können in den betroffenen Versionen Lücken bei den Messwertdaten auftreten. Dieses Problem kann sich auch auf Autoscaling-Vorgänge auswirken. Dieses Problem betrifft nur Cluster, die auf die betroffenen Versionen aktualisiert wurden. Neu erstellte Cluster sollten wie erwartet funktionieren. Workaround: Wenn Sie betroffen sind, können Sie ein Downgrade auf eine Patchversion oder ein Upgrade auf die neueren korrigierten Versionen durchführen. |
| Vorgang |
Größen- und Anhängelimits für Google Cloud HyperdiskNormalerweise wird die automatische Bereitstellung eines neuen Knotens durch einen Pod ausgelöst, der aufgrund der Volume-Anhangslimits eines Knotens nicht erfolgreich geplant werden kann. Wenn Arbeitslasten, die ein Hyperdisk-Produkt verwenden, auf einem Knoten geplant werden, auf dem eine C3-VM ausgeführt wird, erfolgt keine automatische Knotenbereitstellung und der Pod wird auf dem bereits vollen Knoten geplant. Die Arbeitslast wird auf dem Knoten geplant, obwohl keine verfügbare Festplattenverbindung vorhanden ist. Die Arbeitslast kann auch aufgrund eines Fehlers wie dem folgenden nicht gestartet werden: AttachVolume.Attach failed for volume "[VOLUME NAME]" : rpc error: code = InvalidArgument desc = Failed to Attach: failed when waiting for zonal op: rpc error: code = InvalidArgument desc = operation operation-[OPERATION NUMBERS] failed (UNSUPPORTED_OPERATION): Maximum hyperdisk-balanced disks count should be less than or equal to [16], Requested : [17] Das Problem tritt bei allen Hyperdisk-Produkten auf C3-Maschinen auf. Die Grenzwerte für das Anhängen von Hyperdisk-Volumes variieren je nach Anzahl der vCPUs der VM und dem Hyperdisk-Produkt. Weitere Informationen finden Sie unter Leistungsgrenzen von Hyperdisk. Workaround: Hyperdisk-Produkte lösen die automatische Bereitstellung auf anderen VM-Typen aus. Wir empfehlen eine Form, die nur Hyperdisk unterstützt. |
||
| Vorgang | 1.32.3-gke.1927000, 1.32.3-gke.1785000, 1.32.3-gke.1717000, 1.32.3-gke.1440000, 1.32.3-gke.1170000, 1.32.3-gke.1250000, 1.32.3-gke.1671000, 1.32.3-gke.1596000, 1.32.3-gke.1298000 |
gke-metadata-server wird auf TPU-/GPU-Knoten durch OOMKilled beendetAuf GKE-TPU-Knoten (z. B. Workaround: Wenn Sie |
|
| Vorgang |
|
|
Die Größenänderung von Volumes kann aufgrund des Status „NodePendingResize“ für PVCs hängen bleiben.Bei Clustern mit Version 1.32, die Knoten mit Version 1.31 oder niedriger haben, kann der PersistentVolumeClaim-Status während der Größenänderung nicht aktualisiert werden. Dieser falsche Status verhindert, dass nachfolgende Größenänderungsvorgänge gestartet werden, wodurch weitere Größenänderungen verhindert werden. Ein PVC in diesem Status hat ein Feld Wenn ein PVC erstellt wurde, während Ihr Cluster eine betroffene Version hatte, kann dieses Problem auch nach dem Upgrade Ihres Clusters auf eine bekannte behobene Version weiterhin auftreten. In diesem Fall muss Ihr PVC gepatcht werden, um das Feld Workaround: PVCs, die aufgrund eines nicht zugewiesenen Status hängen bleiben, können gepatcht werden, um diesen Status zu entfernen. Mit einem Patch-Befehl wie dem folgenden können Sie den Status „dangling“ entfernen: kubectl patch pvc $PVC_NAME --subresource='status' --type='merge' -p '{"status":{"allocatedResourceStatuses":null}}'kubectl patch pvc $PVC_NAME --subresource='status' --type='merge' -p '{"status":{"allocatedResources":null}}' |
| Vorgang |
|
|
Der PDCSI-Treiber protokolliert möglicherweise zu viele Informationen.In GKE-Clustern mit bestimmten Versionen von 1.32 werden möglicherweise übermäßig viele Logmeldungen vom PDCSI-Treiber ausgegeben. Diese zusätzlichen Logs würden das Kontingent für die Cloud Logging Write API aufbrauchen. Workaround: Sie können diese übermäßige Protokollierung reduzieren, indem Sie einen Ausschlussfilter hinzufügen. Verwenden Sie die folgende Abfrage, um die Aufnahme der Logmeldungen in Cloud Logging auszuschließen:
resource.type="k8s_container"
resource.labels.container_name="gce-pd-driver"
(sourceLocation.file="cache.go" OR "Cannot process volume group")
|
| Vorgänge |
|
|
Pods, die versuchen, nichtflüchtige NFS-Volumes auf COS-Knoten bereitzustellen, die zuvor eine RO-Bereitstellung (Read-Only, nur lesen) hatten, werden nur im RO-Modus bereitgestellt.In GKE-Version 1.27 und höher können NFS-Volumes, die den Kubernetes-CSI-Treiber im Baum verwenden, nichtflüchtige Volumes nur im RO-Modus einbinden, wenn zuvor eine RO-Einbindung auf demselben Knoten erfolgt ist. Workaround: Downgrade von Knotenpools auf eine Version, die älter als die betroffenen Versionen ist |
| Vorgänge |
|
|
Pods, die versuchen, nichtflüchtige NFS-Volumes auf Ubuntu-Knoten bereitzustellen, können nicht ausgeführt werden.In GKE-Version 1.32 und höher können NFS-Volumes, die den integrierten CSI-Treiber von Kubernetes verwenden, nicht auf Ubuntu-Knoten bereitgestellt werden. In diesem Fall werden möglicherweise die folgenden Fehlermeldungen angezeigt: "MountVolume.SetUp failed for volume 'nfs-storage' : mount failed: exit status 1" Output: Mount failed: mount failed: exit status 127 "Output: chroot: failed to run command 'mount': No such file or directory failed to run command mount on Ubuntu nodes" Workaround: Downgrade von Knotenpools auf Version 1.31 durchführen |
| Vorgang | >= 1.28.15-gke.1436000, < 1.28.15-gke.1668000, >= 1.29.12-gke.1040000, < 1.29.13-gke.1028000, >= 1.30.8-gke.1053000, < 1.30.8-gke.1287000, >= 1.31.4-gke.1057000, < 1.31.6-gke.1020000, >= 1.32.0-gke.1281000, < 1.32.1-gke.1302000 |
|
Pods, die io_uring-bezogene Syscalls verwenden, bleiben möglicherweise im Status „Terminating“ hängen.
Pods, die io_uring-bezogene Systemaufrufe verwenden, können aufgrund eines Fehlers im Linux-Kernel in den Status „D“ (Festplatten-Ruhezustand), auch TASK_UNINTERRUPTIBLE genannt, eintreten. Prozesse im Status D können nicht durch Signale, einschließlich
Wenn ein Pod von diesem bekannten Problem betroffen ist, werden seine Container möglicherweise nicht normal beendet. In den containerd-Logs werden möglicherweise wiederholte Meldungen wie die folgende angezeigt:
oder
Diese Symptome deuten darauf hin, dass Prozesse im Container im unterbrechungsfreien Ruhemodus (D-Status) feststecken, was eine ordnungsgemäße Beendigung des Pods verhindert.
Arbeitslasten, die „io_uring“ direkt oder indirekt über eine Sprachlaufzeitumgebung wie NodeJS verwenden, sind möglicherweise von diesem bekannten Problem betroffen. Betroffene Arbeitslasten haben einen Prozess im Status „D“ (Festplatten-Ruhezustand) in der Datei Workaround: Führen Sie ein Upgrade der Clusternodes auf eine korrigierte Version oder höher durch. |
| Vorgang | 1.28, 1.29, 1.30, 1.31 |
|
Arbeitslasten, die Image-Streaming verwenden, schlagen mit Authentifizierungsfehlern fehlEin Fehler in der Image-Streaming-Funktion kann dazu führen, dass Arbeitslasten fehlschlagen, wenn beim Lesen von Dateien durch den Container bestimmte Bedingungen erfüllt sind. Fehlermeldungen im Zusammenhang mit Authentifizierungsfehlern sind möglicherweise im gcfsd-Log sichtbar.
So prüfen Sie, ob Sie betroffen sind: Suchen Sie in den Logs mit dieser Suchanfrage:
Das Vorhandensein dieser Fehler weist darauf hin, dass die Knoten betroffen sind. Wenn Sie von diesem Problem betroffen sind, können Sie ein Upgrade Ihrer Knotenpools auf eine gepatchte GKE-Version durchführen. |
| Vorgang |
|
|
Erhöhte Pod-Bereinigungsraten in GKE-Versionen 1.30 und 1.31
Einige Versionen von GKE 1.30 und GKE 1.31, die COS 113 bzw. COS 117 verwenden, haben Kernel, die mit der Option
Die Konfigurationsoption Möglicherweise sehen Sie nicht immer eine ungewöhnliche Pod-Entfernungsrate, da dieses Problem vom Speichernutzungsmuster der Arbeitslast abhängt. Bei Arbeitslasten, für die im Feld „resources“ kein Arbeitsspeicherlimit festgelegt wurde, besteht ein höheres Risiko, dass das Kubelet Pods entfernt. Das liegt daran, dass die Arbeitslasten möglicherweise mehr Arbeitsspeicher anfordern, als das Kubelet als verfügbar meldet. Wenn Sie nach dem Upgrade auf die genannten GKE-Versionen ohne weitere Änderungen eine höhere Speicherauslastung einer Anwendung feststellen, sind Sie möglicherweise von der Kerneloption betroffen.
So prüfen Sie, ob es ungewöhnliche Pod-Entfernungsraten gibt: Analysieren Sie die folgenden Messwerte mit dem Metrics Explorer:
Sie können die folgenden PromQL-Abfragen verwenden. Ersetzen Sie die Werte für
max by (pod_name)(max_over_time(kubernetes_io:container_memory_used_bytes{monitored_resource="k8s_container",memory_type="non-evictable",cluster_name="REPLACE_cluster_name",namespace_name="REPLACE_namespace",metadata_system_top_level_controller_type="REPLACE_controller_type",metadata_system_top_level_controller_name="REPLACE_controller_name"}[${__interval}]))
sum by (pod_name)(avg_over_time(kubernetes_io:container_memory_request_bytes{monitored_resource="k8s_container",cluster_name="REPLACE_cluster_name",namespace_name="REPLACE_namespace",metadata_system_top_level_controller_type="REPLACE_controller_type",metadata_system_top_level_controller_name="REPLACE_controller_name"}[${__interval}]))
Wenn Sie ungewöhnliche Spitzen in der Speichernutzung feststellen, die über den angeforderten Speicher hinausgehen, wird die Arbeitslast möglicherweise häufiger entfernt. ProblemumgehungWenn Sie kein Upgrade auf die korrigierten Versionen durchführen können und Ihre Umgebung in GKE ausgeführt wird, wo Sie privilegierte Pods bereitstellen können, können Sie die Option „Multi-Gen LRU“ mit einem DaemonSet deaktivieren.
Sobald das DaemonSet in allen ausgewählten Knotenpools ausgeführt wird, ist die Änderung sofort wirksam und die Berechnung der Kubelet-Speichernutzung erfolgt wieder wie gewohnt. |
| Vorgang | 1.28, 1.29, 1.30, 1.31 |
|
Pods bleiben im Status „Wird beendet“Ein Fehler in der Containerlaufzeit (containerd) kann dazu führen, dass Pods und Container im Status „Terminating“ (Wird beendet) mit Fehlern ähnlich den folgenden hängen bleiben: OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown
Wenn Sie von diesem Problem betroffen sind, können Sie Ihre Knoten auf eine GKE-Version mit einer korrigierten Version von containerd aktualisieren. |
| Vorgang | 1.28,1.29 |
|
Bildstreaming schlägt aufgrund von symbolischen Links fehlEin Fehler im Image-Streaming-Feature kann dazu führen, dass Container nicht gestartet werden. Container, die auf einem Knoten mit aktiviertem Image-Streaming in bestimmten GKE-Versionen ausgeführt werden, können möglicherweise nicht mit dem folgenden Fehler erstellt werden: "CreateContainer in sandbox from runtime service failed" err="rpc error: code = Unknown desc = failed to create containerd container: failed to mount [PATH]: too many levels of symbolic links"
Wenn Sie von diesem Problem betroffen sind, können Sie nach leeren oder doppelten Ebenen suchen. Wenn Sie leere Ebenen oder doppelte Ebenen nicht entfernen können, deaktivieren Sie das Image-Streaming. |
| Vorgang | 1.27,1.28,1.29 |
|
Bildstreaming schlägt aufgrund fehlender Dateien fehlEin Fehler in der Funktion „Image-Streaming“ kann dazu führen, dass Container aufgrund einer fehlenden Datei oder mehrerer fehlender Dateien fehlschlagen. Container, die auf einem Knoten mit aktiviertem Image-Streaming in den folgenden Versionen ausgeführt werden, können möglicherweise nicht gestartet werden oder werden mit Fehlern ausgeführt, die darauf hinweisen, dass bestimmte Dateien nicht vorhanden sind. Hier einige Beispiele für solche Fehler:
Wenn Sie von diesem Problem betroffen sind, können Sie das Image-Streaming deaktivieren. |
| Netzwerk,Upgrades und Updates | 1,28 |
Fehler bei der Gateway-TLS-KonfigurationWir haben ein Problem bei der Konfiguration von TLS für Gateways in Clustern mit GKE-Version 1.28.4-gke.1083000 festgestellt. Dies betrifft TLS-Konfigurationen mit einem SSLCertificate oder einer CertificateMap. Wenn Sie einen Cluster mit vorhandenen Gateways aktualisieren, schlagen Aktualisierungen des Gateways fehl. Bei neuen Gateways werden die Load-Balancer nicht bereitgestellt. Dieses Problem wird in einer zukünftigen GKE 1.28-Patchversion behoben. |
|
| Upgrades und Updates | 1,27 | 1.27.8 oder höher |
Problem mit dem GPU-Geräte-Plug-in
Bei Clustern, auf denen GPUs ausgeführt werden und die von Version 1.26 auf eine Patchversion von Version 1.27 vor Version 1.27.8 aktualisiert wurden, kann es zu Problemen mit den GPU-Geräte-Plug-ins (
|
| Vorgang | 1.27,1.28 |
|
Autoscaling für alle Arbeitslasten wird beendet
HorizontalPodAutoscaler (HPA) und VerticalPodAutoscaler (VPA) skalieren möglicherweise keine Arbeitslasten in einem Cluster mehr automatisch, wenn er falsch konfigurierte Workaround:
Korrigieren Sie falsch konfigurierte
Weitere Informationen zum Konfigurieren von |
| Vorgang | 1.28,1.29 |
|
Container Threat Detection kann nicht bereitgestellt werdenDie Bereitstellung von Container Threat Detection in Autopilot-Clustern mit den folgenden GKE-Versionen kann fehlschlagen:
|
| Netzwerk, Upgrades | 1.27, 1.28, 1.29, 1.30 |
|
Verbindungsprobleme für
|
| Netzwerk | 1.31, 1.32 |
|
Fehlerhafter UDP-Traffic zwischen Pods, die auf demselben Knoten ausgeführt werdenBei Clustern, für die die knoteninterne Sichtbarkeit aktiviert ist, kann es zu Problemen mit dem UDP-Traffic zwischen Pods kommen, die auf demselben Knoten ausgeführt werden. Das Problem tritt auf, wenn der GKE-Clusterknoten auf eine der folgenden GKE-Versionen aktualisiert oder mit einer dieser Versionen erstellt wird:
Der betroffene Pfad ist Pod-zu-Pod-UDP-Traffic auf demselben Knoten über Hostport oder Dienst. Lösung Aktualisieren Sie den Cluster auf eine der folgenden korrigierten Versionen:
|
| Vorgang | 1.29,1.30,1.31 |
|
Inkompatibler Ray-Operator und Cloud KMS-DatenbankverschlüsselungEinige Ray Operator-Versionen sind nicht mit der Cloud KMS-Datenbankverschlüsselung kompatibel. Problemumgehungen: Führen Sie ein Upgrade der Cluster-Steuerungsebene auf eine korrigierte Version oder höher durch. |
| Upgrades und Updates | 1.30, 1.31 |
|
GPU-Wartungshandler-Pod hängt im CrashLoopBackOff-Status festBei diesem Problem bleiben gpu-maintenance-handler-Pods auf den jeweiligen Knoten im Status „CrashLoopBackOff“ hängen. In diesem Status wird verhindert, dass das Label „Anstehende Wartung“ auf GKE-Knoten angewendet wird. Dies kann sich auf die Prozesse zum Leeren von Knoten und zum Entfernen von Pods für Arbeitslasten auswirken.
"Node upcoming maintenance label not applied due to error: Node "gke-yyy-yyy" is invalid: metadata.labels: Invalid value: "-62135596800": a valid label must be an empty string or consist of alphanumeric characters, '-','' or '.', and must start and end with an alphanumeric character (e.g.'MyValue', or 'my_value', or '12345', regex used for validation is '(([A-Za-z0-9][-A-Za-z0-9.]*)?[A-Za-z0-9])?')"
Wenn Sie von diesem Problem betroffen sind, können Sie es beheben, indem Sie Ihre Steuerungsebene auf eine GKE-Version aktualisieren, die den Fix enthält. |
| Vorgang | 1.33.1-gke.1522000 und höher | 1.33.4-gke.1142000 und höher |
Pods können auf Knoten mit aktiviertem Image-Streaming nicht gestartet werden
Auf Knoten, auf denen Image-Streaming aktiviert ist, können Arbeitslasten möglicherweise nicht mit der folgenden Fehlersignatur gestartet werden:
Die Serial-Port-Logs eines betroffenen Knotens enthalten auch die folgende Fehlersignatur:
Das Vorhandensein dieser beiden Fehlersignaturen weist auf einen Deadlock in einer der Komponenten für das Streamen von Bildern hin. Dieser Deadlock verhindert, dass Pods erfolgreich gestartet werden. Möglichkeiten zur Behebung des Problems: Starten Sie den Knoten neu, um das Problem schnell zu beheben. Beachten Sie, dass der neu gestartete Knoten möglicherweise wieder in eine Deadlock-Situation gerät. Für eine robustere Risikominderung deaktivieren Sie das Image-Streaming für den Knotenpool, indem Sie Folgendes ausführen: gcloud container node-pools update NODE_POOL_NAME --cluster CLUSTER_NAME --no-enable-image-streaming |
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:
- Sie können eine Supportanfrage erstellen, indem Sie sich an den Cloud Customer Care wenden.
- Support von der Community erhalten, indem Sie Fragen auf Stack Overflow stellen und mit dem Tag
google-kubernetes-enginenach ähnlichen Problemen suchen. Sie können auch dem#kubernetes-engine-Slack-Kanal beitreten, um weiteren Community-Support zu erhalten. - Sie können Fehler melden oder Funktionsanfragen stellen, indem Sie die öffentliche Problemverfolgung verwenden.