Bekannte Probleme mit GKE

Autopilot Standard

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 unmittelbar vor der frühesten Version im erweiterten Support liegen. 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 nur in Version 1.28 und früheren Versionen auftreten, entfernt.

Wenn Sie am Google Developer-Programm teilnehmen, können Sie diese Seite speichern, 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 Produktionsversion oder -kategorie wählen Sie in den folgenden Drop-down-Menüs die gewünschten Filter aus.

Wählen Sie Ihre GKE-Version aus:

1,35 1,34 1.33 1,32 1,31 1,30 1,29 1,28 1,27

Wählen Sie die Problemkategorie aus:

Konfiguration Installation Upgrades und Updates Vorgang Logging und Monitoring Sicherheit Zurücksetzen/Löschen Leistung

Oder suchen Sie nach Ihrem Problem:

Kategorie	Identifizierte Version(en)	Korrigierte Version(en)	Problem und Problemumgehung
Vorgang	1,35 1,36 1.37	1.35.6-gke.1250001 und höher 1.36.4-gke.1391002 und höher 1.37.1-gke.1187000 und höher	HTTP-POST-Anfragen für Tokens vom Metadatenserver schlagen mit dem Fehler „400 Bad Request“ fehl. Arbeitslasten, die Workload Identity Federation for GKE verwenden, um sich bei Google Cloud APIs zu authentifizieren, indem sie Dienstkonto-Zugriffstokens oder Identitätstokens vom GKE-Metadatenserver anfordern (z. B. /computeMetadata/v1/instance/service-accounts/default/token oder /computeMetadata/v1/instance/service-accounts/default/identity), können mit dem Fehler HTTP 400 Bad Request (INVALID_ARGUMENT) fehlschlagen. Dieses Problem tritt auf, wenn eine Anwendung, eine Clientbibliothek oder ein API-Gateway eine HTTP-POST-Anfrage ohne gültige Zertifikatskette im Anfragetext sendet. In betroffenen GKE-Versionen sind POST-Anfragen an diese Token-Endpunkte ausschließlich für gebundene Zugriffs- und ID-Tokens reserviert. Daher werden Anfragen mit leeren, formcodierten oder ungültigen JSON-Dateien in der Nutzlast abgelehnt. Um das Problem zu beheben, führen Sie ein Upgrade auf die neueste Patchversion innerhalb der Nebenversion eines beliebigen Release-Channels durch. Workaround: Konfigurieren Sie Ihre Anwendung, Clientbibliothek oder Ihr API-Gateway so, dass die GET-Methode anstelle von POST verwendet wird, wenn Sie Zugriffs- oder ID-Tokens vom Metadatenserver anfordern, wie im folgenden Beispiel: curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" Wenn Ihre Arbeitslast ein SDK oder Gateway eines Drittanbieters (z. B. MuleSoft Flex Gateway, IBM App Connect oder benutzerdefinierte HTTP-Skripts) verwendet, das standardmäßig POST-Anfragen an Metadatenserver-Endpunkte sendet, aktualisieren Sie die Konfiguration oder Clientbibliothek, um GET-Anfragen zu senden.
Upgrades und Updates	1.33 und höher	TBD	Nicht geplante Pods und ausgeschöpftes Kontingent während zweistufiger Nebenversionsupgrades für die Steuerungsebene. Bei zweistufigen Upgrades von Nebenversionen für Steuerungsebenen in Autopilot-Clustern, die Pods mit verlängerter Laufzeit verwenden, werden neue Knotenpools möglicherweise mit der früheren Knotenversion bereitgestellt. Cluster Autoscaler vergleicht die neu bereitgestellten Knoten mit der aktualisierten Version der Steuerungsebene, erkennt eine Versionsabweichung und wendet den cloud.google.com/not-target-gke-version:true-Taint an. Cluster Autoscaler blockiert auch das Hochskalieren vorhandener oder neu erstellter Pod-Knotenpools mit verlängerter Dauer, die die frühere Knotenversion verwenden. Dieses Verhalten verhindert, dass Pods geplant werden, und löst eine unendliche Skalierungsschleife aus. Anstatt einen vorhandenen Knotenpool hochzuskalieren, erstellt die automatische Knotenbereitstellung bei jeder Hochskalierungsiteration einen neuen Knotenpool mit einem einzelnen Knoten, um die ausstehenden Arbeitslasten zu bewältigen. Diese Schleife generiert Hunderte von separaten leeren Knotenpools, die schließlich die Kontingente für regionale verwaltete Instanzgruppen erschöpfen können. Workaround: Um die Skalierungsschleife zu beheben, führen Sie das Upgrade der Steuerungsebene manuell aus, indem Sie den folgenden Befehl ausführen: gcloud container clusters complete-control-plane-upgrade [CLUSTER_NAME] --location=[LOCATION] Alternativ können Sie die folgende Toleranz auf die betroffenen Arbeitslasten anwenden, damit sie auf den Knoten der früheren Version geplant werden können: tolerations: - key: "cloud.google.com/not-target-gke-version" operator: "Equal" value: "true" effect: "NoSchedule"
Vorgang	1.37.0-gke.2941000 und höher	1.37.1-gke.1131000	Knoten, die NFS-Volumes bereitstellen, akkumulieren Bereitstellungseinträge und erstellen keine Container mehr Wenn auf Knoten, auf denen betroffene Versionen ausgeführt werden, ein NFS-Volume bereitgestellt wird, verbleiben zusätzliche Einträge in der Bereitstellungstabelle des Knotens. Wenn ein Pod, der ein NFS-Volume verwendet, beendet wird, schlagen außerdem die Versuche fehl, die Bereitstellung aufzuheben. Dadurch versucht der kubelet wiederholt, die Bereitstellung aufzuheben. Bei jedem Wiederholungsversuch werden der Bereitstellungstabelle weitere Einträge hinzugefügt, sodass die Bereitstellungstabelle kontinuierlich wächst, auch wenn keine neuen Arbeitslasten geplant sind. Wenn die Bereitstellungstabelle das Kernel-Limit erreicht, kann die Containerlaufzeit keine Container mehr auf diesem Knoten erstellen. Der Knoten führt keine neuen Pods mehr aus, meldet möglicherweise den Status NotReady und wird möglicherweise wiederholt neu gestartet. Pods, die NFS-Volumes verwenden, bleiben möglicherweise im Status Terminating, da ihre Volumes nicht getrennt werden können. In Pod-Ereignissen und kubelet-Logs melden Knoten in diesem Status Fehler, die in etwa so aussehen: MountVolume.SetUp failed for volume "VOLUME_NAME" : mount failed: exit status 1 mount: /etc: mount(2) system call failed: No space left on device Dieses Problem betrifft Knotenpools, die NFS-Volumes mit dem Kubernetes-In-Tree-NFS-Treiber bereitstellen. Knoten, auf denen NFS-Volumes nicht mit dem integrierten NFS-Treiber bereitgestellt werden, sind nicht betroffen. Workaround: Wenn Sie einen betroffenen Knoten wiederherstellen möchten, starten Sie ihn neu oder erstellen Sie ihn neu. Die zusätzlichen Mount-Einträge sind nur im laufenden Zustand des Knotens vorhanden. Sie werden also gelöscht, wenn der Knoten neu gestartet wird. Pods, die nach dem Neustart im Status Terminating verbleiben, können mit dem folgenden Befehl entfernt werden: kubectl delete pod POD_NAME --namespace NAMESPACE --force --grace-period=0 Damit das Problem in Standard-Clustern nicht mehr auftritt, führen Sie ein Downgrade der Knotenpools, die NFS-Volumes bereitstellen, auf eine 1.36-Version durch. Legen Sie einen Wartungsausschluss fest, damit GKE die Knotenpools nicht automatisch auf eine betroffene Version aktualisiert. Wenn auf einem Autopilot-Cluster eine betroffene Version ausgeführt wird, verwenden Sie stattdessen eine der folgenden Optionen: Wenn Ihre NFS-Volumes von Filestore unterstützt werden, stellen Sie sie mit dem Filestore-CSI-Treiber anstelle des In-Tree-NFS-Treibers bereit. Der CSI-Treiber stellt Volumes aus seinem eigenen Container bereit und verwendet die betroffene Knotenkomponente nicht. Wenn Sie den In-Tree-NFS-Treiber weiterhin verwenden müssen, lassen Sie die betroffenen Knoten durch die automatische Knotenreparatur wiederherstellen. Autopilot-Cluster reparieren Knoten automatisch. Ein Knoten, der etwa 10 Minuten lang den Status NotReady meldet, wird per Drain beendet und neu erstellt, wodurch seine Bereitstellungstabelle gelöscht wird.
Upgrades	1.34.9-gke.1065000 und höher, 1.35.6-gke.1049000 und höher sowie alle 1.36-Patchversionen	1.34.10-gke.1328000 und höher, 1.35.8-gke.1026000 und höher, 1.36.4-gke.1058000 und höher (für 1.37 ist noch kein Fix verfügbar)	Fehler bei A4X Max-GPU-Arbeitslasten (GB300) Das Erstellen oder Aktualisieren von GKE-A4X Max-Knotenpools (a4x-maxgpu-4g-metal) auf oder zu bestimmten Patchversionen (siehe Spalte Identifizierte Version(en)) führt zu GPU-Arbeitslastfehlern mit den angehängten NVIDIA GB300 Grace Blackwell Ultra Superchips. Aufgrund der verlängerten Bootzeiten für High Bandwidth Memory (HBM) auf GB300-Hardware mit diesem Bare-Metal-Maschinentyp kommt es beim Startdienst nvidia-persistenced zu einer Zeitüberschreitung. Durch diese Zeitüberschreitung bleiben die GPUs nicht initialisiert und es wird die Fehlermeldung cudaErrorDeviceUnavailable(46) ausgegeben, wenn Pods versuchen, CUDA-Ressourcen anzufordern. Lösung: Aktualisieren Sie alle betroffenen Cluster und Knotenpools auf eine korrigierte Version. GKE verhindert das Erstellen von A4X Max-Knotenpools mit betroffenen Versionen und führt kein automatisches Upgrade der Knotenpools auf betroffene Versionen durch. GKE verhindert keine manuellen Upgrades auf die betroffenen Versionen. Um die Fehler zu vermeiden, empfehlen wir jedoch, kein Upgrade auf die betroffenen Versionen durchzuführen. Workaround: Wenn Sie kein Upgrade durchführen können, löschen Sie alle A4X Max-Knotenpools, in denen die betroffenen Versionen ausgeführt werden, und erstellen Sie die Knotenpools mit einer früheren, nicht betroffenen Version neu. Da die A4X Max-Kapazität über eine Reservierung abgerufen werden muss, geht durch das Löschen der Knotenpools keine Kapazität verloren.
Vorgang	1.33-Versionen vor 1.33.5-gke.2469000, 1.34-Versionen vor 1.34.1-gke.2037001	1.33.5-gke.2469000 und höher, 1.34.1-gke.2037001 und höher, 1.35 und höher	GPU- oder TPU-Knoten bleiben nach der Hostwartung mit „impending-node-termination“-Markierungen hängen In GKE-Clustern mit Beschleunigerknoten (GPU oder TPU), auf denen betroffene Versionen ausgeführt werden, können Knoten nach Abschluss der Wartung oder Reparatur des Compute Engine-Hosts mit den Markierungen cloud.google.com/impending-node-termination oder cloud.google.com/maintenance-window-started hängen bleiben. Wenn die VM-Instanz neu gestartet wird, kann es sein, dass der GKE-Wartungscontroller diese Markierungen vorzeitig wieder anwendet, wenn für den Knoten ein weiteres Wartungsereignis geplant ist. Dadurch wird verhindert, dass neue Arbeitslasten auf fehlerfreien Knoten geplant werden. Workaround: Um den Status „Hängen geblieben“ zu beheben, müssen Sie die von GKE verwalteten aktiven Wartungslabels und die Taints von den betroffenen Knoten manuell entfernen. Wenn Sie nur die Markierungen entfernen, werden sie vom GKE-Wartungscontroller automatisch wieder angewendet. Führen Sie die folgenden Befehle aus, um die Labels und Taints zu entfernen: kubectl label nodes NODE_NAME cloud.google.com/active-node-maintenance- kubectl label nodes NODE_NAME cloud.google.com/scheduled-maintenance-time- kubectl label nodes NODE_NAME cloud.google.com/scheduled-maintenance-time-latest- kubectl taint nodes NODE_NAME cloud.google.com/impending-node-termination- kubectl taint nodes NODE_NAME cloud.google.com/maintenance-window-started- Ersetzen Sie NODE_NAME durch den Namen des betroffenen Knotens.
Vorgang	1.33 1,34	1.34.1-gke.1829001 und höher	Fehler beim Zulassen von Pods für TPU v7-Arbeitslasten aufgrund einer falschen Anzahl von Chips. Die GKE gibt fälschlicherweise acht zuweisbare TPU-Chips für TPU v7-Beschleuniger (tpu7x) mit einer 2x2x1-Topologie an, die physisch nur vier Chips enthält. Diese Diskrepanz bei der Berichterstellung verhindert die Pod-Planung für TPU v7-Arbeitslasten. Die Dual-Chiplet-Architektur von TPU v7 wird in früheren Versionen nicht korrekt verarbeitet, was zu Fehlern bei der Pod-Zulassung führt. Je nach den angeforderten TPU-Ressourcen treten die folgenden Fehler auf: Wenn Sie vier TPUs (google.com/tpu: 4) anfordern, gibt `kubelet` UnexpectedAdmissionError zurück: "invalid TPU chip count request, you must request all 4 chips on this node together". Wenn Sie acht TPUs (google.com/tpu: 8) anfordern, lehnt der tpu-accelerator-topology-constraints-Aufnahme-Webhook die Anfrage mit dem folgenden Fehler ab: „Invalid resource requests for google.com/tpu. Er muss einem der Werte [4] für den Beschleuniger tpu7x und die Topologie 2x2x1 entsprechen.. Workaround: Aktualisieren Sie den GKE-Cluster auf Version 1.34.1-gke.1829001 oder höher, um dieses Problem zu beheben.
Vorgang	1.35.3-gke.1234000 und höher	TBD	Lustre-Client verwendet keine sekundären NICs auf Knoten mit mehreren NICs Auf GKE-Knoten mit mehreren Netzwerkkarten (NICs) ist der Managed Lustre CSI-Treiber standardmäßig aktiviert, um alle verfügbaren Netzwerkkarten zu verwenden und die Bandbreite zu aggregieren, indem der TCP-Speichertraffic auf die Netzwerkschnittstellen verteilt wird. Aufgrund eines bekannten Problems verwenden Lustre-Clients ab Version 2.14.0_p249 jedoch möglicherweise keine sekundären NICs. Stattdessen wird der gesamte TCP-Speichertraffic zur Managed Lustre-Instanz ausschließlich über die primäre NIC geleitet. Dadurch wird die Bandbreitenaggregation verhindert und der Speicherdurchsatz begrenzt. Workaround: Wenn Ihre Arbeitslasten eine Bandbreitenaggregation mit mehreren NICs für Managed Lustre erfordern, führen Sie ein Downgrade Ihrer Knotenpools auf eine GKE-Version vor 1.35.3-gke.1234000 durch, z. B. 1.35.2-gke.1842000.
Vorgang	1.35 und höher	TBD	Zeitüberschreitung bei der Verbindung oder Verbindung abgelehnt für Abläufe, die an den GKE-Metadatenserver weitergeleitet werden In GKE-Version 1.35 und höher kann es bei Arbeitslasten, die Workload Identity zur Authentifizierung bei Google Cloud APIs verwenden, unmittelbar nach dem Start des Knotens zu vorübergehenden Verbindungszeitüberschreitungen oder abgelehnten Verbindungen zum GKE-Metadatenserver kommen. Workaround: Empfehlungen und Problemumgehungen finden Sie unter Fehlerbehebung bei Zeitüberschreitungsfehlern beim Starten des Pods.
Vorgang	1.33.8-gke.1026000 und höher	1.35.1 oder höher	gVisor-Shim kann nicht bereinigt werden, Fehler "runsc: executable file not found in $PATH" wird protokolliert Bei jedem Beenden eines gVisor-Pods oder bei einem OOM-Kill versucht containerd, die Sandbox zu beenden. Manchmal schlägt der Bereinigungsvorgang jedoch fehl und der Fehler exec: "runsc": executable file not found in $PATH wird protokolliert. Dieser Fehler kann zu Problemen wie Ressourcenerschöpfung, Netzwerkverschlechterung, NodeLocalDNS-Panik, DNS-Zeitüberschreitungen oder hoher Latenz beim Erstellen von Pods führen. Lösung: Aktualisieren Sie die GKE-Knoten auf Version 1.35.1 oder höher. Führen Sie für Standard-Cluster ein Upgrade des Knotenpools mit den betroffenen Knoten durch. Führen Sie für Autopilot-Cluster ein manuelles Upgrade des Autopilot-Clusters auf Version 1.35.1 oder höher durch. GKE aktualisiert Ihre Knoten dann automatisch so schnell wie möglich auf die Version der Steuerungsebene. Workaround: Wenn Sie Ihren Cluster nicht aktualisieren können, haben Sie folgende Möglichkeiten: Prüfen und erhöhen Sie die Arbeitsspeicheranfragen und ‑limits für die gVisor-Pods. Stellen Sie das folgende privilegierte DaemonSet bereit, um die Binärdatei runsc von /home/containerd/usr/local/sbin nach /home/kubernetes/bin zu kopieren: apiVersion: apps/v1 kind: DaemonSet metadata: name: runsc-path namespace: kube-system spec: selector: matchLabels: app: runsc-path updateStrategy: type: RollingUpdate template: metadata: labels: app: runsc-path spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: sandbox.gke.io/runtime operator: In values: - gvisor tolerations: - effect: NoSchedule key: sandbox.gke.io/runtime operator: Equal value: gvisor volumes: - name: host hostPath: path: / initContainers: - name: copy-runsc image: bash command: - /usr/local/bin/bash - -c - | set -euo pipefail cp /host/home/containerd/usr/local/sbin/runsc /host/home/kubernetes/bin chmod a+rx /host/home/kubernetes/bin/runsc volumeMounts: - name: host mountPath: /host resources: requests: memory: 5Mi cpu: 5m securityContext: privileged: true containers: - image: gcr.io/google-containers/pause:3.2 name: pause
Vorgang	1.35.0-gke.2232000 und höher	1.35.3-gke.1.35.3-gke.1290000 und höher	Dynamische Volumes greifen auf den Standardlaufwerkstyp zurück Arbeitslasten, die dynamische Volumes in GKE-Version 1.35.0-gke.2232000 oder höher verwenden, können möglicherweise nicht geplant oder angehängt werden. Dieses Problem kann auch dazu führen, dass Volumes mit dem Fallback-hd-type (z. B. hyperdisk-balanced) anstelle des pd-type bereitgestellt werden, selbst auf Knoten, die Hyperdisk nicht unterstützen. Dies liegt daran, dass der PDCSI-Knotenserver das CSINode-Objekt nicht mit den unterstützten Laufwerkstyp-Topologien füllen kann. Daher fehlen dem Controller die erforderlichen Topologieinformationen, um Volumes mit kompatiblen Knoten abzugleichen. Workaround: Führen Sie ein Upgrade auf 1.35.3-gke.1290000 oder höher durch.
Upgrades und Updates	Alle Patchversionen vor 1.34.3-gke.1208000 für GKE 1.34 Alle Patchversionen vor 1.35.0-gke.2232000 für GKE 1.35	1.34.3-gke.1208000 für GKE 1.34 1.35.0-gke.2232000 für GKE 1.35	Probleme beim Pod-Start während Upgrades auf GKE 1.35 für GKE Dataplane V2-Cluster Cluster, bei denen die Steuerungsebene von Versionen auf GKE-Version 1.35.0-gke.2232000 und höher aktualisiert wird älter als 1.34.3-gke.1208000 für GKE 1.34 vor 1.35.0-gke.2232000 für GKE 1.35 können Probleme beim Starten von Pods für neue Arbeitslasten auftreten, die während des Roll-outs des anetd-DaemonSets erstellt wurden. Neue Arbeitslasten können während des Roll-outs von anetd nicht gestartet werden, wenn sie auf einem Knoten mit veraltetem anetd geplant sind. Während des Roll-outs wird möglicherweise die folgende Fehlermeldung angezeigt: Failed to create pod sandbox: rpc error [...] plugin type="cilium-cni" failed (add): unable to create endpoint: Cilium API client timeout exceeded Das liegt daran, dass GKE den Operator identity-management-mode verwendet, für den alle Agents und der Operator eine synchronisierte Ansicht der identitätsrelevanten Labels benötigen. Ab GKE 1.35.0-gke.2232000 werden topology.kubernetes.io-Labels aus dem identitätsrelevanten Satz ausgeschlossen, um Identitätsduplikate zu vermeiden. Diese Änderung führt während des Roll-outs zu einer vorübergehenden Konfigurationsabweichung zwischen der aktualisierten Steuerungsebene und den veralteten anetd-Agents. Weitere Informationen finden Sie im Cilium-PR. Workaround: Für GKE 1.34 vor 1.34.3-gke.1208000: Führen Sie zuerst ein Upgrade auf 1.34.3-gke.1208000 oder höher und dann auf 1.35.0-gke.2232000 oder höher durch. Für GKE 1.35 vor 1.35.0-gke.2232000: Warten Sie nach dem Upgrade, bis die Einführung von anetd abgeschlossen ist. Wenn Sie den Roll-out manuell beschleunigen möchten, löschen Sie veraltete anetd-Pods. So wird sichergestellt, dass der Operator und die anetd-Knoten-Agents eine synchronisierte Ansicht der identitätsrelevanten Labels haben.
Upgrades und Updates	1,32 1.33 1,34 1,35	1.32.11-gke.1153001 und höher 1.33.5-gke.2326000 und höher 1.34.3-gke.1214000 und höher 1.35.0-gke.2180000 und höher	Verzögerungen bei der Pod-Planung auf neuen Knoten, wenn die Calico-Netzwerkrichtlinie aktiviert ist In GKE-Clustern mit aktivierter Calico-Netzwerkrichtlinie kann eine Regression in den betroffenen Versionen zu erheblichen Verzögerungen bei der Pod-Planung auf neuen oder neu erstellten Knoten führen. Diese Verzögerungen können dazu führen, dass Knoten über einen längeren Zeitraum im Status NotReady verbleiben. Das Problem wird durch das Calico CNI-Startskript verursacht, das die Kubernetes API-Server-URL für IPv4-Adressen falsch formatiert, indem es sie in eckige Klammern ([]) setzt. Dies führt zu einem URL-Parsing-Fehler beim Erstellen neuer Pod-Sandboxes, der in den kubelet-Logs sichtbar ist: Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox ""sandbox-id"": plugin type="calico" failed (add): error creating calico client: host must be a URL or a host:port pair: "https://[IPv4-address]:443" Workaround: Die Version der Calico-Komponente wird durch die Version der Steuerungsebene des Clusters bestimmt. Aktualisieren Sie die Steuerungsebene Ihres Clusters auf eine der korrigierten Versionen, um dieses Problem zu beheben. Nach dem Upgrade der Steuerungsebene müssen Sie die Knoten in Ihren Knotenpools neu erstellen, damit sie das richtige URL-Format für den Kubernetes API-Server verwenden. Sie können dies erreichen, indem Sie ein In-Place-Upgrade Ihres Knotenpools auf dieselbe oder eine neuere Version durchführen oder Ihre Knotenpools manuell neu erstellen.
Leistung	1.32.8-gke.1134000 und höher für GKE 1.32 1.33.3-gke.1392000 und höher für GKE 1.33 Alle Patchversionen für GKE 1.34 und 1.35	1.32.11-gke.1075000 und höher für GKE 1.32 1.33.5-gke.2392000 und höher für GKE 1.33 1.34.3-gke.1318000 und höher für GKE 1.34 1.35.0-gke.2398000 und höher für GKE 1.35	Die Leistung von Netzwerken für allgemeine Zwecke sinkt bei GPU-Maschinentypen der Serien A und G4 GKE-Cluster mit Knoten der A-Serie und G4-GPU-Knoten weisen eine geringere Leistung für das allgemeine Netzwerk in GKE 1.32.8-gke.1134000 und höher für GKE 1.32 sowie in GKE 1.33.3-gke.1392000 und höher auf. Die Leistungseinbußen bei Netzwerken für allgemeine Zwecke wirken sich auf GPU-Maschinentypen aus, darunter die A3-, A4-, A4X- und G4-Maschinenserien. GPUDirect-TCPXO auf A3 Mega und GPUDirect-RDMA auf A3 Ultra, A4 und A4X sind davon nicht betroffen. Dies liegt daran, dass das Script auf Knotenebene (/usr/bin/google_set_multiqueue), das die Interrupt-Affinität festlegt, falsch konfiguriert ist. Workaround: Aktualisieren Sie jeden betroffenen Knotenpool auf eine korrigierte Version.
Leistung	1.32.8-gke.1134000 und höher für GKE 1.32 1.33.3-gke.1392000 und höher für GKE 1.33 und höher	1.32.11-gke.1075000 und höher für GKE 1.32 1.33.5-gke.2392000 und höher für GKE 1.33	Leistung von GPUDirect-TCPX sinkt auf A3 High GKE-Cluster mit A3 High-Knoten (a3-highgpu-8g) weisen eine beeinträchtigte Leistung auf, wenn GPUDirect-TCPX in GKE 1.32.8-gke.1134000 und höher für GKE 1.32 sowie in GKE 1.33.3-gke.1392000 und höher verwendet wird. Dies liegt daran, dass das Script auf Knotenebene (/usr/bin/google_set_multiqueue), das die Interrupt-Affinität festlegt, falsch konfiguriert ist. Workaround: Aktualisieren Sie für GKE 1.32-Knotenpools die GKE-Knotenpoolversionen auf 1.32.11-gke.1075000 oder höher. Aktualisieren Sie für GKE 1.33 und höher die GKE-Knotenpoolversionen auf 1.33.5-gke.2392000 oder höher. Informationen zu GKE 1.34-Knotenpools finden Sie unter GPUDirect-TCPX ist mit A3 High für GKE-Version 1.34 und höher nicht verfügbar.
Upgrades	1,35	1.35.0-gke.2232000 und höher.	Duplizierung von Cilium-Identitäten in GKE Dataplane V2-Clustern Bei GKE-Clustern mit Version 1.35 und aktiviertem GKE Dataplane V2 kann es zu einer Zunahme der Anzahl der benutzerdefinierten ciliumidentities.cilium.io-Ressourcen kommen. Dieses Problem wird dadurch verursacht, dass topology.kubernetes.io-Labels zu Pods in Kubernetes 1.35 hinzugefügt werden. Dadurch werden zusätzliche Cilium-Identitäten für jede Zone erstellt, in der ein Pod aus einer Arbeitslast geplant wird. Sowohl in regionalen als auch in zonenbasierten Clustern kann das Planen einer neuen Arbeitslast zu einer vorübergehenden Duplizierung der Cilium-Identität führen. Diese Duplizierung tritt auf, weil Pods bei der Erstellung anhand der ursprünglichen Labels eine Identität erhalten und eine weitere Identität, nachdem Topologie-Labels hinzugefügt wurden, wenn der Pod für einen Knoten geplant wird. In regionalen Clustern kann sich die Anzahl der Identitäten zusätzlich um einen Faktor erhöhen, der proportional zur Anzahl der Zonen ist, über die sich der Cluster erstreckt. Auswirkungen: Wenn die Gesamtzahl der Identitäten 65.535 überschreitet, können neue Arbeitslasten möglicherweise nicht geplant werden. Workaround: Um die Gesamtzahl der Identitäten zu begrenzen, sollten Sie Ihren Pods keine Labels mit einer großen Anzahl eindeutiger Werte hinzufügen. Weitere Informationen finden Sie in der folgenden Cilium-Dokumentation: Identitätsbasierte Sicherheit Sicherheitsidentitäten Manuelle Upgrades sollten ab Version 1.34.3-gke.1208000 durchgeführt werden. Wenn Sie das Upgrade von einer Version vor 1.34.3-gke.1208000 starten, kann es während des Upgrades zu vorübergehenden Problemen mit der Pod-Planung kommen.
Upgrades	1.34-Patchversionen vor 1.34.5-gke.1153000 1.35-Patchversionen vor 1.35.2-gke.1485000	1.34.5-gke.1153000 und höher 1.35.2-gke.1485000 und höher 1.36 und höher Außerdem müssen Sie die GPUDirect-TCPX-Installer-Version 3.1.9 oder höher und die Sidecar-Version 2.0.12 oder höher verwenden. Die Versionen des Installers und des Sidecars sind 1:1 zugeordnet und müssen übereinstimmen. Die GPUDirect-TCPX-Installationsversion 3.1.12 entspricht beispielsweise der Sidecar-Version 2.0.15. Weitere Informationen zu Installer- und Sidecar-Versionen finden Sie in den Versionshinweisen zu GPUDirect-TCPX.	GPUDirect-TCPX ist für bestimmte GKE-Versionen mit A3 High nicht verfügbar GKE-Cluster mit A3 High-Knoten (a3-highgpu-8g) verwenden GPUDirect-TCPX, um die GPU-Netzwerkbandbreite zu maximieren. Bei Knoten, die TCPX und A3 High verwenden, kann ein Upgrade auf betroffene GKE-Versionen zu Funktions- oder Leistungsproblemen mit TCPX führen. Das liegt daran, dass TCPX nicht mit dem aktualisierten Linux-Kernel 6.12 kompatibel ist, der von Container-Optimized OS-Meilenstein 125 oder höher verwendet wird. Meilenstein 125 wird von GKE-Version 1.34 verwendet. Andere GPU-Maschinentypen vom Typ „A3 High“ (a3-highgpu-1g, a3-highgpu-2g, a3-highgpu-4g) und andere GPU-Maschinenserien sind nicht betroffen, da sie GPUDirect-TCPX nicht unterstützen. Lösung: Führen Sie ein Upgrade auf die korrigierten GKE-Versionspatches durch, um dieses Problem zu beheben. Weitere Informationen zum Konfigurieren und Aktualisieren von Knotenpools mit GPUDirect-TCPX finden Sie unter GPU-Netzwerkbandbreite in Standardclustern maximieren oder GPU-Netzwerkbandbreite in Autopilot-Clustern maximieren. Wenn Sie NCCL-Tests für bestimmte Versionen ausführen, werden möglicherweise die folgenden Warnungen angezeigt, die sich nicht auf die Leistung oder Funktionalität auswirken: NCCL-WARN-Logs für Rx Ctrl Timeouts: Diese Meldung kann angezeigt werden, wenn die Arbeitslast einen Recv-Kommunikationsvorgang auf dem Ziel viel früher als einen Send-Kommunikationsvorgang auf dem Initiator postet. Es sind keine Auswirkungen auf die Leistung zu erwarten. NCCL-WARN-Logs für No free space for recv task: Diese Meldung warnt vor einer geringen Gesamtzahl von Netzwerkaufgaben zur Verarbeitung von Vorgängen, was dazu führt, dass alle Aufgaben vorübergehend belegt sind. Es sind keine Auswirkungen auf die Leistung zu erwarten.
Vorgang	Alle Versionen vor 1.34.0-gke.2285000	1.34.0-gke.2285000 und höher	Aktualisierte Mindestinstanzkapazität Die Mindestkapazität für Managed Lustre-Instanzen wurde auf 9.000 GiB aktualisiert. In Clustern mit Versionen vor 1.34.0-gke.2285000 können mit dem Managed Lustre-CSI-Treiber keine Instanzen mit dieser Mindestkapazität erstellt werden. Workaround: Aktualisieren Sie Ihre Clusterversion auf 1.34.0-gke.2285000 oder höher, um die Erstellung von Managed Lustre-Instanzen mit einer Mindestkapazität von 9.000 GiB zu ermöglichen.
Vorgang	Alle Versionen	TBD	Google Cloud Console-UI kann während der automatischen Knotenreparatur nicht bearbeitet werden Wenn ein GKE-Knoten automatisch repariert wird, kann der Knotenpool aufgrund eines laufenden Vorgangs nicht über die Google Cloud Konsole bearbeitet werden. Workaround: Sie können die Knotenpoolkonfiguration weiterhin mit gcloud CLI-Befehlen bearbeiten.
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-Instanzen Bei der dynamischen Bereitstellung einer Lustre-Instanz schlägt die Instanzerstellung mit dem Fehler InvalidArgument für PerUnitStorageThroughput fehl, unabhängig vom Wert für perUnitStorageThroughput, der in der API-Anfrage angegeben wurde. Workaround: Aktualisieren Sie den GKE-Cluster auf Version 1.33.4-gke.1036000 oder höher. 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 dem Regular oder Rapid Channel auswählen, die die Fehlerbehebung enthält.
Vorgang	1.32.3-gke.1099000 und höher 1.33	1.33.3-gke.1266000 und höher	Eingabe-/Ausgabefehler beim Umbenennen oder Verschieben von Dateien mit dem Cloud Storage FUSE-CSI-Treiber Wenn 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-Image-Definition hinzu. Fügen Sie im Abschnitt spec.containers des Pod-Manifests die folgende Containerdefinition mit dem Image gcr.io/gke-release/gcs-fuse-csi-driver-sidecar-mounter:v1.8.9-gke.2 hinzu. # 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 gke-gcsfuse-sidecar-Block aus Ihrem Manifest entfernen. Nachdem Sie diesen Block entfernt haben, fügt GKE automatisch das richtige Sidecar-Image für Ihre aktualisierte Clusterversion ein und verwaltet es.
Logging und Monitoring	Alle Versionen	TBD	Race-Bedingung in gke-metrics-agent-DaemonSets Wenn Sie einem Knotenpool das Label cloud.google.com/gke-metrics-agent-scaling-level hinzufügen, um die Arbeitsspeicherzuweisung des DaemonSets gke-metrics-agent manuell zu erhöhen, tritt im DaemonSet während der Erstellung eines neuen Knotens eine Race-Bedingung auf. Diese Race-Bedingung führt zu zeitweiligen Neustarts und möglicherweise zu fehlenden Messwerten. Dieses Problem tritt auf, weil es eine Verzögerung gibt, bevor das Label einem neuen Knoten im Knotenpool hinzugefügt wird. Während dieser Verzögerung erstellt das DaemonSet einen Pod mit der ursprünglichen Arbeitsspeicherzuweisung auf diesem Knoten. Nachdem das Label angewendet wurde, erstellt das DaemonSet einen Pod mit der neuen Arbeitsspeicherzuweisung. Der vorhandene Pod wird nicht vollständig gelöscht, wenn der aktualisierte Pod gestartet wird. Beide Pods versuchen, eine Bindung an dieselbe Portnummer herzustellen. Workaround: Nachdem Sie das Label cloud.google.com/gke-metrics-agent-scaling-level zu einem Knotenpool hinzugefügt haben, starten Sie das DaemonSet gke-metrics-agent neu: kubectl -n kube-system rollout restart daemonset gke-metrics-agent
Upgrades	1.33	1.33.2-gke.1043000	Niedrigeres Limit für offene Dateien mit containerd 2.0 Für Knotenpools mit GKE-Version 1.33, die containerd 2.0 verwendet, wird das standardmäßige weiche Limit für geöffnete Dateien (ulimit -n) für Container auf 1024 gesenkt. Dies ist eine Änderung in containerd selbst (siehe containerd PR #8924), bei der LimitNOFILE als Best Practice aus containerd.service entfernt wurde, sodass das standardmäßige weiche Limit des Systems gilt. Bei Arbeitslasten, die ein höheres Standard-Soft-Limit erwarten (z. B. solche, die implizit auf dem vorherigen höheren Standardwert basieren), können Fehler wie Too many open files auftreten. 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: Erhöhen Sie das Limit für geöffnete Dateien für Ihre Arbeitslasten mit einer der folgenden Methoden: Anpassung auf Anwendungsebene: Ändern Sie den Anwendungscode oder die Konfiguration, um ulimit -n oder prlimit --nofile=524288 explizit festzulegen. Containerd NRI Ulimit Adjuster-Plug-in: Verwenden Sie das containerd/nri ulimit-adjuster-Plug-in, um das ulimit anzupassen. Knotenpool downgraden (nur Standard): Bei GKE-Standardclustern können Sie Ihren Knotenpool vorübergehend auf Version 1.32 downgraden, um dieses Problem zu umgehen, bis eine dauerhafte Lösung verfügbar ist. Weitere Informationen zur Migration zu containerd 2 finden Sie unter Knoten zu containerd 2 migrieren.
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 CRDs Einige von GKE verwaltete CRDs haben möglicherweise ein ungültiges status.storedVersions-Feld, was das Risiko birgt, dass der Zugriff auf CRD-Objekte nach einem Upgrade unterbrochen wird. Dieses Problem betrifft Cluster, die beide der folgenden Bedingungen erfüllen: Cluster, die zu einem bestimmten Zeitpunkt eine betroffene GKE-Version verwendet haben. Cluster, die nicht unterstützte (served=false) Versionen von CRD-Objekten in etcd gespeichert hatten. Workaround: Als Problemumgehung wird empfohlen, Clusterupgrades zu verschieben, 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 alternativ mit dem Befehl kubectl patch dem Feld status.storedVersions hinzufügen.
Betrieb, Logging und Monitoring	1.32.2-gke.1652000, 1.31.6-gke.1221000, 1.30.10-gke.1227000	1.32.2-gke.1652003 oder höher 1.31.6-gke.1221001 oder höher 1.30.10-gke.1227001 oder höher	Fehlende Messwerte oder Arbeitslast-Autoscaler skaliert nicht Möglicherweise treten Lücken in den Messwertdaten der betroffenen Versionen auf, nachdem die Clustergröße um mehr als fünf Knoten erhöht wurde. 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 Hyperdisk In der Regel löst ein Pod, der aufgrund der Limits für Volume-Anhänge eines Knotens nicht erfolgreich geplant werden kann, das Auto-Provisioning eines neuen Knotens aus. 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 trotz des Fehlens eines verfügbaren Laufwerksanhangs auf dem Knoten geplant. Die Arbeitslast kann 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 Limits für das Anhängen von Hyperdisks variieren je nach Anzahl der vCPUs der VM und dem Hyperdisk-Produkt. Weitere Informationen finden Sie unter Leistungsgrenzen von Hyperdisk. Workaround: Google Cloud Hyperdisk-Produkte lösen die automatische Bereitstellung auf anderen VM-Formen aus. Wir empfehlen eine Form, die nur Google Cloud 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 mit OOMKilled beendet Auf GKE-TPU-Knoten (z. B. ct4p-hightpu-4t) und GPU-Knoten (z. B. a3-highgpu-8g) kann der Kernel den gke-metadata-server mit einem OOMKilled beenden, wenn die Arbeitsspeichernutzung des Servers 100 MB überschreitet. Workaround: Wenn Sie OOMKilled-Ereignisse für gke-metadata-server auf TPU- oder GPU-Knoten beobachten, wenden Sie sich an das GKE Identity-On-Call-Team (Komponenten-ID: 395450), um Informationen zu möglichen Maßnahmen zu erhalten.
Vorgang	1.32.0-gke.1358000 bis 1.32.4-gke.1106006, 1.32.4-gke.1236007, 1.32.4-gke.1353001, 1.32.4-gke.1415001, 1.32.4-gke.1533000 1.33.0-gke.0 bis 1.33.0-gke.1552000	1.32.4-gke.1353003 und höher 1.33.0-gke.1552000 und höher	Die Größenänderung von Volumes kann aufgrund des Status „NodePendingResize“ bei 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änderungen gestartet werden, und verhindert so effektiv weitere Größenänderungen. Ein PVC in diesem Status hat ein status.allocatedResourceStatuses-Feld, das NodePendingResize oder sowohl das status.allocatedResources-Feld als auch status.conditions.type: FileSystemResizePending enthält. 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 korrigierte Version weiterhin auftreten. In diesem Szenario muss Ihr PVC gepatcht werden, um das Feld status.allocatedResources mit einer einmaligen Problemumgehung zu entfernen. Workaround: PVCs, die aufgrund des Status „Dangling“ 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	1.32.4-gke.1236007, 1.32.4-gke.1353001	1.32.4-gke.1353003 und höher	Der PDCSI-Treiber protokolliert möglicherweise übermäßig viele Daten GKE-Cluster mit bestimmten Versionen von 1.32 können übermäßig viele Logeinträge vom PDCSI-Treiber ausgeben. Dieses übermäßige Logging würde das Kontingent der Cloud Logging Write API verbrauchen. Workaround: Sie können dieses übermäßige Logging reduzieren, indem Sie einen Ausschlussfilter hinzufügen. Verwenden Sie die folgende Abfrage, um die Logeinträge von der Aufnahme 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	1.27.16-gke.2440000 und höher 1.28.15-gke.1673000 und höher 1.29.13-gke.1038000 und höher 1.30.9 und höher 1.31.7 oder höher 1.32.1-gke.1357001 und höher	1.27.16-gke.2691000 und höher 1.28.15-gke.2152000 und höher 1.29.15-gke.1218000 und höher 1.30.11-gke.1190000 und höher 1.31.7-gke.1363000 und höher 1.32.4-gke.1106000 und höher 1.33.0-gke.1552000 und höher	Pods, die versuchen, nichtflüchtige NFS-Volumes auf COS-Knoten zu mounten, die zuvor eine RO-Bereitstellung (Read-Only, schreibgeschützt) 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 bereitstellen, wenn auf demselben Knoten bereits eine RO-Bereitstellung erfolgt ist. Workaround: Führen Sie ein Downgrade der Knotenpools auf eine Version aus, die älter als die betroffenen Versionen ist.
Vorgänge	Versionen 1.32 von 1.32.1-gke.1357001 bis 1.32.4-gke.1106000 (nicht einschließlich) Alle 1.33-Versionen vor 1.33.0-gke.1552000 Version 1.32: 1.32.4-gke.1106000 und höher Version 1.33: 1.33.0-gke.1552000 und höher	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 In-Tree-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" Zusätzlich zu diesen Fehlermeldungen können Pods, die diese Volumes verwenden, nicht gestartet werden. Workaround: Führen Sie ein Downgrade der Knotenpools auf Version 1.31 durch.
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.1369000	1.28.15-gke.1668000 oder höher 1.29.13-gke.1028000 oder höher 1.30.8-gke.1287000 oder höher 1.31.6-gke.1020000 oder höher 1.32.1-gke.1369000 oder höher	Pods, die io_uring-bezogene Syscalls verwenden, bleiben möglicherweise im Status „Terminating“ hängen. Pods, die io_uring-bezogene Syscalls verwenden, können aufgrund eines Fehlers im Linux-Kernel in den Status D (Festplatten-Ruhezustand) wechseln, der auch als TASK_UNINTERRUPTIBLE bezeichnet wird. Prozesse im D-Status können nicht durch Signale geweckt werden, einschließlich SIGKILL. 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: Kill container [container-id]. Das bedeutet, dass das System wiederholt versucht, einen Container zu stoppen. Gleichzeitig werden in den kubelet-Logs Fehlermeldungen wie die folgenden angezeigt: "Kill container failed" err="rpc error: code = DeadlineExceeded desc = context deadline exceeded" oder "Error syncing pod, skipping" err="[failed to \"KillContainer\" for \"container-name\" with KillContainerError: \"rpc error: code = DeadlineExceeded desc = an error occurs during waiting for container \\\"container-id\\\" to be killed: wait container \\\"container-id\\\": context deadline exceeded\", failed to \"KillPodSandbox\" for \"pod-uuid\" with KillPodSandboxError: \"rpc error: code = DeadlineExceeded desc = context deadline exceeded\"]" pod="pod-name" podUID="pod-uuid" Diese Symptome deuten auf Prozesse im Container hin, die in einem nicht unterbrechbaren Ruhezustand (D-Status) hängen, was die ordnungsgemäße Beendigung des Pods verhindert. Arbeitslasten, die io_uring direkt oder indirekt über eine Sprachlaufzeit wie NodeJS verwenden, können von diesem bekannten Problem betroffen sein. Betroffene Arbeitslasten haben einen Prozess im D-Zustand (Festplatten-Ruhemodus) in der Datei /proc/<pid>/state und zeigen den String io_uring als Teil des Inhalts von /proc/<pid>/stack an. Bei NodeJS-Arbeitslasten kann die Verwendung von io_uring möglicherweise über UV_USE_IO_URING=0 deaktiviert werden. Workaround: Aktualisieren Sie die Clusterknoten auf eine korrigierte Version oder höher.
Vorgang	1.28, 1.29, 1.30, 1.31	1.30.8-gke.1261000 und höher 1.31.4-gke.1183000 und höher 1.32.0-gke.1448000 und höher	Arbeitslasten, die Image-Streaming verwenden, schlagen mit Authentifizierungsfehlern fehl Ein Fehler in der Image-Streaming-Funktion kann dazu führen, dass Arbeitslasten fehlschlagen, wenn bestimmte Bedingungen erfüllt sind, während der Container Dateien liest. 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: resource.type="k8s_node" resource.labels.project_id="[project_id]" resource.labels.cluster_name="[cluster_name]" logName="projects/[project_id]/logs/gcfsd" "backend.FileContent failed" "Request is missing required authentication credential." Das Vorhandensein dieser Fehler weist darauf hin, dass die Knoten betroffen sind. Wenn Sie von diesem Problem betroffen sind, können Sie Ihre Knotenpools auf eine gepatchte GKE-Version aktualisieren.
Vorgang	1.30.0 bis 1.30.5-gke.1443001 1.31.0 bis 1.31.1-gke.1678000	1.30.5-gke.1628000 und höher 1.31.1-gke.1846000 und höher	Erhöhte Pod-Entfernungsraten 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 CONFIG_LRU_GEN_ENABLED=y erstellt wurden. Mit dieser Option wird die Kernelfunktion Multi-Gen LRU aktiviert, die dazu führt, dass das Kubelet die Arbeitsspeichernutzung falsch berechnet und möglicherweise Pods entfernt. Die Konfigurationsoption CONFIG_LRU_GEN_ENABLED ist in cos-113-18244-151-96 und cos-117-18613-0-76 deaktiviert. Möglicherweise wird nicht immer eine ungewöhnliche Pod-Entfernungsrate angezeigt, da dieses Problem vom Arbeitsspeichernutzungsmuster 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 Arbeitsspeichernutzung einer Anwendung feststellen, sind Sie möglicherweise von der Kerneloption betroffen. Wenn Sie prüfen möchten, ob ungewöhnliche Pod-Entfernungsraten vorliegen, analysieren Sie die folgenden Messwerte mit dem Metrics Explorer: kubernetes.io/container_memory_used_bytes und kubernetes.io/container_memory_request_bytes. Sie können die folgenden PromQL-Abfragen verwenden. Ersetzen Sie die Werte für cluster_name, namespace_name, metadata_system_top_level_controller_type und metadata_system_top_level_controller_name durch den Namen und Typ der Arbeitslast, die Sie analysieren möchten: 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 Arbeitsspeichernutzung sehen, die über den angeforderten Speicher hinausgehen, wird die Arbeitslast möglicherweise häufiger entfernt. Problemumgehung Wenn Sie kein Upgrade auf die korrigierten Versionen durchführen können und eine GKE-Umgebung verwenden, in der Sie privilegierte Pods bereitstellen können, können Sie die Option „Multi-Gen LRU“ mithilfe eines DaemonSets deaktivieren. Aktualisieren Sie die GKE-Knotenpools, in denen Sie das DaemonSet ausführen möchten, mit einer Annotation, um die Multi-Gen-LRU-Option zu deaktivieren. Beispiel: disable-mglru: "true". Aktualisieren Sie den Parameter nodeSelector im DaemonSet-Manifest mit derselben Annotation, die Sie im vorherigen Schritt verwendet haben. Sehen Sie sich beispielsweise die Datei disable-mglru.yaml im Repository GoogleCloudPlatform/k8s-node-tools an. Stellen Sie das DaemonSet in Ihrem Cluster bereit. Sobald das DaemonSet in allen ausgewählten Knotenpools ausgeführt wird, ist die Änderung sofort wirksam und die Berechnung der Kubelet-Arbeitsspeichernutzung ist wieder normal.
Vorgang	1.28, 1.29, 1.30, 1.31	1.28.14-gke.1175000 und höher 1.29.9-gke.1341000 und höher 1.30.5-gke.1355000 und höher 1.31.1-gke.1621000 und höher	Pods bleiben im Status „Wird beendet“ Ein Fehler in der Containerlaufzeit (containerd) kann dazu führen, dass Pods und Container im Status „Wird beendet“ hängen bleiben. Dabei treten Fehler wie die folgenden auf: 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.34 und früher 1.35-Versionen vor 1.35.6-gke.1005000 1.36-Versionen vor 1.36.0-gke.2459000	1.35.6-gke.1005000 und höher 1.36.0-gke.2459000 und höher	Bildstreaming schlägt aufgrund von symbolischen Links fehl Ein 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 erstellt werden. In diesem Fall wird der folgende Fehler ausgegeben: "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" Workaround: Aktualisieren Sie Ihre Knotenpools auf eine korrigierte Version (1.35.6-gke.1005000 oder höher oder 1.36.0-gke.2459000 oder höher), um dieses Problem zu beheben. Wenn Sie kein Upgrade durchführen können, 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	1.28.9-gke.1103000 und höher 1.29.4-gke.1202000 und höher 1.30: Alle Versionen	Image-Streaming schlägt aufgrund fehlender Dateien fehl Ein Fehler in der Funktion „Image-Streaming“ kann dazu führen, dass Container aufgrund einer 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: No such file or directory Executable file not found in $PATH 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-Konfiguration Wir haben ein Problem mit der Konfiguration von TLS für Gateways in Clustern mit GKE-Version 1.28.4-gke.1083000 festgestellt. Dies betrifft TLS-Konfigurationen, die entweder ein SSLCertificate oder eine CertificateMap verwenden. Wenn Sie ein Upgrade für einen Cluster mit vorhandenen Gateways ausführen, schlagen Aktualisierungen am Gateway fehl. Bei neuen Gateways werden die Load Balancer nicht bereitgestellt. Dieses Problem wird in einer demnächst erscheinenden GKE 1.28-Patchversion behoben.
Upgrades und Updates	1,27	1.27.8 oder höher	Problem mit GPU-Geräte-Plug-in Bei Clustern, auf denen GPUs ausgeführt werden und die von 1.26 auf eine 1.27-Patchversion vor 1.27.8 aktualisiert werden, können Probleme mit den GPU-Geräte-Plug-ins (nvidia-gpu-device-plugin) ihrer Knoten auftreten. Führen Sie je nach Status Ihres Clusters die folgenden Schritte aus: Wenn auf Ihrem Cluster Version 1.26 ausgeführt wird und er GPUs hat, führen Sie kein manuelles Upgrade des Clusters durch, bis Version 1.27.8 in der Release-Version Ihres Clusters verfügbar ist. Wenn auf Ihrem Cluster eine frühere 1.27-Patchversion ausgeführt wird und die Knoten betroffen sind, starten Sie die Knoten neu oder löschen Sie den nvidia-gpu-device-plugin-Pod auf den Knoten manuell. Der Add-on-Manager erstellt dann ein neues funktionierendes Plug-in. Wenn Ihr Cluster automatische Upgrades verwendet, sind Sie davon nicht betroffen, da automatische Upgrades Cluster nur auf Patchversionen mit dem Fix verschieben.
Vorgang	1.27,1.28	1.27.5-gke.1300 und höher 1.28.1-gke.1400 und höher	Autoscaling für alle Arbeitslasten wird beendet HorizontalPodAutoscaler (HPA) und VerticalPodAutoscaler (VPA) beenden möglicherweise das Autoscaling aller Arbeitslasten in einem Cluster, wenn dieser falsch konfigurierte autoscaling/v2-HPA-Objekte enthält. Das Problem betrifft Cluster, auf denen frühere Patchversionen der GKE-Versionen 1.27 und 1.28 ausgeführt werden (z. B. 1.27.3-gke.100). Workaround: Korrigieren Sie falsch konfigurierte autoscaling/v2-HPA-Objekte, indem Sie dafür sorgen, dass die Felder in spec.metrics.resource.target übereinstimmen, z. B.: Wenn spec.metrics.resource.target.type gleich Utilization ist, sollte das Ziel averageUtilization sein. Wenn spec.metrics.resource.target.type den Wert AverageValue hat, sollte das Ziel averageValue sein. Weitere Informationen zum Konfigurieren von autoscaling/v2-HPA-Objekten finden Sie in der Kubernetes-Dokumentation zu HorizontalPodAutoscaler.
Vorgang	1.28,1.29	1.28.7-gke.1026000 1.29.2-gke.1060000	Container Threat Detection kann nicht bereitgestellt werden Container Threat Detection kann möglicherweise nicht in Autopilot-Clustern mit den folgenden GKE-Versionen bereitgestellt werden: 1.28.6-gke.1095000 bis 1.28.7-gke.1025000 1.29.1-gke.1016000 bis 1.29.1-gke.1781000
Netzwerke, Upgrades	1.27, 1.28, 1.29, 1.30	1.30.4-gke.1282000 oder höher 1.29.8-gke.1157000 oder höher 1.28.13-gke.1078000 oder höher 1.27.16-gke.1342000 oder höher	Verbindungsprobleme für hostPort-Pods nach dem Upgrade der Steuerungsebene Bei Clustern mit aktivierter Netzwerkrichtlinie können Verbindungsprobleme mit hostPort-Pods auftreten. Außerdem kann es weitere 30 bis 60 Sekunden dauern, bis neu erstellte Pods bereit sind. Das Problem tritt auf, wenn die GKE-Steuerungsebene eines Clusters auf eine der folgenden GKE-Versionen aktualisiert wird: 1.30 bis 1.30.4-gke.1281999 1.29.1-gke.1545000 bis 1.29.8-gke.1156999 1.28.7-gke.1042000 bis 1.28.13-gke.1077999 1.27.12-gke.1107000 bis 1.27.16-gke.1341999 Workaround: Führen Sie unmittelbar nach dem Upgrade der GKE-Steuerungsebene ein Upgrade der Knoten durch oder erstellen Sie sie neu.
Netzwerk	1.31, 1.32	1.32.1-gke.1729000 oder höher 1.31.6-gke.1020000 oder höher	Fehlerhafter UDP-Traffic zwischen Pods, die auf demselben Knoten ausgeführt werden Bei Clustern mit aktivierter knoteninterner Sichtbarkeit kann es zu fehlerhaftem 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: 1.32.1-gke.1729000 oder höher 1.31.6-gke.1020000 oder höher Der betroffene Pfad ist der Pod-zu-Pod-UDP-Traffic auf demselben Knoten über Hostport oder Dienst. Lösung Aktualisieren Sie den Cluster auf eine der folgenden korrigierten Versionen: 1.32.3-gke.1927000 oder höher 1.31.7-gke.1390000 oder höher
Vorgang	1.29,1.30,1.31	1.29.10-gke.1071000 oder höher 1.30.5-gke.1723000 oder höher 1.31.2-gke.1115000 oder höher	Inkompatibler Ray-Operator und Cloud KMS-Datenbankverschlüsselung Einige Ray Operator-Versionen sind nicht mit der Cloud KMS-Datenbankverschlüsselung kompatibel. Behelfslösungen: Führen Sie ein Upgrade der Cluster-Steuerungsebene auf eine korrigierte Version oder höher durch.
Upgrades und Updates	1.30, 1.31	1.30.8-gke.1051000 oder höher 1.31.1-gke.2008000 und höher	GPU-Wartungshandler-Pod bleibt im CrashLoopBackOff-Status hängen Bei diesem Problem bleiben die gpu-maintenance-handler-Pods auf den jeweiligen Knoten im Status „CrashLoopBackOff“ hängen. In diesem Zustand wird das Label „upcoming maintenance“ nicht auf GKE-Knoten angewendet. Das kann sich sowohl auf das Entleeren von Knoten als auch auf das 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: Failed to create pod sandbox ... context deadline exceeded Die Logs des seriellen Ports eines betroffenen Knotens enthalten außerdem die folgende Fehlersignatur: task gcfsd ... blocked for more than X seconds Das Vorhandensein dieser beiden Fehlersignaturen weist auf einen Deadlock in einer der Image-Streaming-Komponenten hin. Dieser Deadlock verhindert, dass Pods erfolgreich gestartet werden. Aussetzung von Maßnahmen: 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 Hinweis: Wenn Sie Image-Streaming deaktivieren, werden alle Knoten in einem Knotenpool neu erstellt.
Vorgang	1.32.4-gke.1198000 und höher Versionen vor 1.33.5-gke.1862000 1.34-Versionen vor 1.34.1-gke.2541000	1.33.5-gke.1862000 und höher 1.34.1-gke.2541000 und höher	Benutzerdefinierte ComputeClasses mit ImageType, die keine vorhandenen GKE-Knotenpools verwenden. Wenn Sie eine benutzerdefinierte ComputeClass verwenden, in der ein ImageType-Feld definiert ist, erstellt und skaliert Cluster Autoscaler wiederholt neue Knotenpools hoch, anstatt vorhandene Knotenpools hochzuskalieren. Der ComputeClass-Status ist fehlerhaft. Workaround: Aktualisieren Sie den Cluster auf eine der folgenden korrigierten Versionen: 1.33.5-gke.1862000 oder höher 1.34.1-gke.2541000 oder höher Alternativ können Sie dieses Problem beheben, indem Sie bestimmte Felder in der benutzerdefinierten ComputeClass nicht definieren. Wenn Sie keine benutzerdefinierte ComputeClass für Autopilot verwenden, definieren Sie das Feld ImageType nicht. In diesem Fall wird die Standardeinstellung auf Clusterebene verwendet, die standardmäßig cos_containerd ist. Wenn Sie eine benutzerdefinierte ComputeClass für Autopilot verwenden, definieren Sie das Feld nodePoolConfig nicht, das eine Ebene ImageType ist.

Nächste Schritte

• Wenn Sie in der Dokumentation keine Lösung für Ihr Problem finden, finden Sie unter Support erhalten weitere Hilfe, einschließlich Ratschlägen zu den folgenden Themen:

  • Sie können eine Supportanfrage stellen, indem Sie sich an Cloud Customer Care wenden.
  • Support von der Community erhalten, indem Sie Fragen auf StackOverflow stellen und das Tag google-kubernetes-engine verwenden, um nach ähnlichen Problemen zu suchen. Sie können auch dem #kubernetes-engine-Slack-Kanal beitreten, um weiteren Community-Support zu erhalten.
  • Probleme oder Feature Requests über den öffentlichen Issue Tracker melden.