Bekannte Probleme mit GKE

• 1.36.3-gke.1767000 und höher

Agent-Sandbox-Arbeitslasten schlagen nach Cluster-Upgrade fehl

Das Agent Sandbox-Add-on (agentsandbox) hat seine benutzerdefinierten Ressourcendefinitionen und die API ab GKE-Version 1.36.3-gke.1767000 von v1alpha1 auf v1beta1 hochgestuft. Wenn Sie ein Upgrade für einen Cluster durchführen, auf dem die Agent-Sandbox mit einer Version vor 1.36.3-gke.1767000 ausgeführt wird, ohne Ihre benutzerdefinierten Ressourcen zu migrieren, funktionieren vorhandene v1alpha1-Arbeitslasten nicht ordnungsgemäß.

Workaround:

Bevor Sie die Steuerungsebene Ihres Clusters auf 1.36.3-gke.1767000 oder höher aktualisieren, migrieren Sie Ihre Agent Sandbox-Manifeste und -Arbeitslasten von v1alpha1 zu v1beta1. Folgen Sie dazu der Migrationsanleitung für Agent Sandbox v1alpha1 zu v1beta1.

• 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 Cloud de Confiance -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. Anfragen mit leeren, formatierten oder ungültigen JSON-Nutzlasten werden daher abgelehnt.

Führen Sie ein Upgrade auf die neueste Patchversion innerhalb der Nebenversion einer beliebigen Release-Version durch, um das Problem zu beheben.

Workaround:

Konfigurieren Sie Ihre Anwendung, Clientbibliothek oder Ihr API-Gateway so, dass die Methode GET 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.

• 1.33 und höher

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 die Markierung cloud.google.com/not-target-gke-version:true an. Cluster Autoscaler blockiert auch das Hochskalieren vorhandener oder neu erstellter Knotenpools für Pods 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 aufzunehmen. Diese Schleife generiert Hunderte von separaten leeren Knotenpools, die schließlich die Kontingente für regionale verwaltete Instanzgruppen erschöpfen können.

Workaround:

Führen Sie den folgenden Befehl aus, um die Skalierungsschleife zu beenden und das Upgrade der Steuerungsebene manuell abzuschließen:

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"

Knoten, die NFS-Volumes bereitstellen, akkumulieren Bereitstellungseinträge und erstellen keine Container mehr

Auf Knoten, auf denen betroffene Versionen ausgeführt werden, werden beim Bereitstellen eines NFS-Volumes zusätzliche Einträge in der Bereitstellungstabelle des Knotens hinterlassen. Wenn ein Pod, der ein NFS-Volume verwendet, beendet wird, schlagen außerdem 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, die nicht den integrierten NFS-Treiber zum Bereitstellen von NFS-Volumes verwenden, sind nicht betroffen.

Workaround:

Wenn Sie einen betroffenen Knoten wiederherstellen möchten, starten Sie ihn neu oder erstellen Sie ihn neu. Die zusätzlichen Bereitstellungseinträge sind nur im laufenden Zustand des Knotens vorhanden und werden daher beim Neustart des Knotens gelöscht. 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 die GKE die Knotenpools nicht automatisch wieder 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 Knotekomponente 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.

Fehler bei A4X Max (GB300)-GPU-Arbeitslasten

Wenn Sie GKE-A4X Max-Knotenpools (a4x-maxgpu-4g-metal) mit bestimmten Patchversionen erstellen oder auf diese aktualisieren (siehe Spalte Identifizierte Version(en)), führt dies zu Fehlern bei GPU-Arbeitslasten 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. Die 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, auf denen betroffene Versionen ausgeführt werden, und erstellen Sie die Knotenpools mit einer früheren, nicht betroffenen Version neu. Da die maximale Kapazität von A4X über eine Reservierung erworben werden muss, geht durch das Löschen der Knotenpools keine Kapazität verloren.

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 Hostwartung oder -reparatur in Compute Engine 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 hängenden Zustand zu beheben, müssen Sie sowohl die von GKE verwalteten aktiven Wartungs-Labels als auch die Markierungen manuell von den betroffenen Knoten 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 Markierungen zu löschen:

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.

• 1.33
• 1,34

Fehler bei der Pod-Zulassung für TPU v7-Arbeitslasten aufgrund einer falschen Chipanzahl.

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 Abweichung 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 das `kubelet` einen UnexpectedAdmissionError zurück: „Ungültige Anfrage für die Anzahl der TPU-Chips. Sie müssen alle 4 Chips auf diesem Knoten zusammen anfordern.“.
• Wenn Sie acht TPUs (google.com/tpu: 8) anfordern, lehnt der Zulassungs-Webhook tpu-accelerator-topology-constraints die Anfrage mit dem folgenden Fehler ab: "Ungültige Ressourcenanfragen für 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.

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

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 für die Authentifizierung bei Google Cloud APIs verwenden, unmittelbar nach dem Starten des Knotens zu vorübergehenden Zeitüberschreitungen bei der Verbindung oder zu abgelehnten Verbindungen zum GKE-Metadatenserver kommen.

Workaround:

Empfehlungen und Problemumgehungen finden Sie unter Zeitüberschreitungsfehler beim Starten des Pods beheben.

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 bei Standard-Clustern 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
    

Dynamische Volumes werden auf den Standardlaufwerkstyp zurückgesetzt

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.

Das liegt daran, dass der PDCSI-Knotenserver das CSINode-Objekt nicht mit den unterstützten Laufwerkstyp-Topologien füllt. 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.

• 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, die die Steuerungsebene auf die GKE-Version 1.35.0-gke.2232000 und höher aktualisieren, von Versionen

• älter als 1.34.3-gke.1208000 für GKE 1.34
• älter als 1.35.0-gke.2232000 für GKE 1.35

Neue Arbeitslasten können während des anetd-Roll-outs 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

Dies liegt daran, dass GKE den Operator-identity-management-mode verwendet, bei dem alle Agents und der Operator eine synchronisierte Ansicht der identitätsrelevanten Labels haben müssen. 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 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 das anetd-Rollout 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.

• 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 mit aktivierter Calico-Netzwerkrichtlinie

In GKE-Clustern mit aktivierter Calico-Netzwerkrichtlinie kann eine Regression in 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. Dazu können Sie ein direktes Upgrade Ihres Knotenpools auf dieselbe oder eine neuere Version durchführen oder Ihre Knotenpools manuell neu erstellen.

• 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

Leistungseinbußen bei Netzwerken für allgemeine Zwecke auf GPU-Maschinentypen der A-Serie und G4

GKE-Cluster mit GPU-Knoten der Serien A und G4 weisen bei GKE 1.32.8-gke.1134000 und höher für GKE 1.32 sowie bei GKE 1.33.3-gke.1392000 und höher eine beeinträchtigte Leistung für allgemeine Netzwerke auf. Die Leistungsminderung bei Netzwerken für allgemeine Zwecke betrifft GPU-Maschinentypen, einschließlich der Maschinenserien A3, A4, A4X und G4. 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:

Führen Sie ein Upgrade aller betroffenen Knotenpools auf eine korrigierte Version durch.

• 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 für GKE-Version 1.34 und höher nicht mit A3 High verfügbar.

1.35.0-gke.2232000 und höher.

Cilium-Identitätsduplizierung 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 in Kubernetes 1.35 Pods mit „topology.kubernetes.io“-Labels versehen 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 zonalen Clustern kann das Planen einer neuen Arbeitslast zu einer vorübergehenden Duplizierung der Cilium-Identität führen. Diese Duplizierung tritt auf, weil Pods beim Erstellen eine Identität basierend auf den ursprünglichen Labels erhalten und eine weitere Identität, nachdem Topologielabels hinzugefügt wurden, wenn der Pod einem Knoten zugewiesen 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:

Wenn Sie die Gesamtzahl der Identitäten begrenzen möchten, 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.

• 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

Sie müssen außerdem 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 den Installations- und Sidecar-Versionen finden Sie in den Versionshinweisen zu GPUDirect-TCPX.

GPUDirect-TCPX ist für bestimmte GKE-Versionen nicht mit A3 High 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-Milestone 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 korrigierte 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 feste Versionen ausführen, werden möglicherweise die folgenden Warnungen angezeigt, die keine Auswirkungen auf die Leistung oder Funktionalität haben:

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

Aktualisierte Mindestinstanzkapazität

Die Mindestkapazität für Managed Lustre-Instanzen wurde auf 9.000 GiB aktualisiert. Auf Clustern mit Versionen vor 1.34.0-gke.2285000 können keine Instanzen mit dieser Mindestkapazität über den Managed Lustre-CSI-Treiber 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.

Cloud de Confiance 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 Cloud de Confiance Console bearbeitet werden.

Workaround:

Sie können die Knotenpoolkonfiguration weiterhin mit gcloud CLI-Befehlen bearbeiten.

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

• 1.32.3-gke.1099000 und höher
• 1.33

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.

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 unregelmäßigen Neustarts und kann zu verlorenen Messwerten führen.

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

Niedrigeres Limit für geöffnete 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 den Knotenpool vorübergehend auf Version 1.32 downgraden, um dieses Problem zu vermeiden, bis eine dauerhafte Lösung verfügbar ist.

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.

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

Größen- und Anhangslimits für Google Cloud Hyperdisk

In der Regel löst ein Pod, der aufgrund der Limits für das Anhängen von Volumes 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 Hyperdisk-Leistungsgrenzen.

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.

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 Optionen zur Problembehebung zu erhalten.

• 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“ auf PVCs hängen bleiben.

Bei Clustern mit Version 1.32, die Knoten mit Version 1.31 oder niedriger haben, schlägt die Aktualisierung des PersistentVolumeClaim-Status während der Größenänderung fehl. 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. Sie können einen Patch-Befehl wie den folgenden verwenden, um den Status „Verwaist“ zu 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}}'

• 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äßige 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")
    

• 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 oder 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 bereitzustellen, die zuvor eine schreibgeschützte Bereitstellung hatten, werden nur im schreibgeschützten Modus bereitgestellt.

In GKE-Version 1.27 und höher können NFS-Volumes, die den Kubernetes-In-Tree-CSI-Treiber verwenden, nichtflüchtige Volumes nur im RO-Modus bereitstellen, nachdem sie zuvor auf demselben Knoten bereitgestellt wurden.

Workaround:

Führen Sie ein Downgrade der Knotenpools auf eine Version aus, die älter als die betroffenen Versionen ist.

• 1.32-Versionen von 1.32.1-gke.1357001 bis, aber nicht einschließlich, 1.32.4-gke.1106000
• 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.

Ab GKE-Version 1.32 können NFS-Volumes, die den Kubernetes-In-Tree-CSI-Treiber verwenden, keine nichtflüchtigen Volumes auf Ubuntu-Knoten bereitstellen. 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.

• 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 Systemaufrufe verwenden, bleiben möglicherweise im Status „Wird beendet“ hängen

Pods, die io_uring-bezogene Systemaufrufe verwenden, können aufgrund eines Fehlers im Linux-Kernel in den Status „D“ (Disk Sleep) 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, können seine Container möglicherweise nicht normal beendet werden. In den containerd-Logs werden möglicherweise wiederholt Meldungen wie die folgende angezeigt: Kill container [container-id]. Das bedeutet, dass das System wiederholt versucht, einen Container zu beenden.
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.

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

Wenn Sie prüfen möchten, 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.

• 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-Bereinigungsraten in den 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, was dazu führt, dass das Kubelet die Arbeitsspeichernutzung falsch berechnet und Pods entfernt.

Die Konfigurationsoption CONFIG_LRU_GEN_ENABLED ist in cos-113-18244-151-96 und cos-117-18613-0-76 deaktiviert.

Möglicherweise sehen Sie nicht immer eine ungewöhnliche Pod-Entfernungsrate, 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 Kernel-Option 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 den Typ der Arbeitslast, die Sie analysieren möchten:

Wenn Sie ungewöhnliche Spitzen bei der Arbeitsspeichernutzung feststellen, die den angeforderten Arbeitsspeicher überschreiten, 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.

1. Aktualisieren Sie die GKE-Knotenpools, in denen Sie das DaemonSet ausführen möchten, mit einer Annotation, um die Option „Multi-Gen LRU“ zu deaktivieren. Beispiel: disable-mglru: "true".
2. 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.
3. Stellen Sie das DaemonSet in Ihrem Cluster bereit.

Nachdem das DaemonSet in allen ausgewählten Knotenpools ausgeführt wird, ist die Änderung sofort wirksam und die Berechnung der Kubelet-Arbeitsspeichernutzung ist wieder normal.

• 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, mit Fehlern wie den folgenden:

Wenn Sie von diesem Problem betroffen sind, können Sie ein Upgrade Ihrer Knoten auf eine GKE-Version mit einer korrigierten Version von containerd durchführen.

• 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

Image-Streaming schlägt aufgrund symbolischer 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:

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 ausführen können, können Sie nach leeren oder doppelten Ebenen suchen. Wenn Sie leere oder doppelte Ebenen nicht entfernen können, deaktivieren Sie das Image-Streaming.

• 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 Image-Streaming-Funktion 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.

Gateway-TLS-Konfigurationsfehler

Wir haben ein Problem mit der Konfiguration von TLS für Gateways in Clustern mit der 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. Für neue Gateways werden die Load Balancer nicht bereitgestellt. Dieses Problem wird in einer zukünftigen GKE 1.28-Patchversion behoben.

Problem mit GPU-Geräte-Plug-in

Bei Clustern, die GPUs ausführen und 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.

• 1.27.5-gke.1300 und höher
• 1.28.1-gke.1400 und höher

Das 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 den Wert Utilization hat, sollte das Ziel averageUtilization sein.
• Wenn spec.metrics.resource.target.type AverageValue ist, sollte das Ziel averageValue sein

Weitere Informationen zum Konfigurieren von autoscaling/v2-HPA-Objekten finden Sie in der Kubernetes-Dokumentation zu HorizontalPodAutoscaler.

• 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

• 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 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 wird ausgelöst, 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.

• 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 wird ausgelöst, 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

• 1.29.10-gke.1071000 oder höher
• 1.30.5-gke.1723000 oder höher
• 1.31.2-gke.1115000 oder höher

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

• 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 „gpu-maintenance-handler“-Pods auf ihren jeweiligen Knoten im Status „CrashLoopBackOff“ hängen. In diesem Status 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.

Wenn Sie von diesem Problem betroffen sind, können Sie es beheben, indem Sie Ihre Steuerungsebene auf eine GKE-Version aktualisieren, die die Korrektur enthält.

Pods können auf Knoten mit aktiviertem Image-Streaming nicht gestartet werden

Auf Knoten mit aktiviertem Image-Streaming 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 einen Deadlock aufweist. Wenn Sie eine robustere Lösung wünschen, 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

• 1.32.4-gke.1198000 und höher
• 1.33-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, die ein ImageType-Feld definiert, erstellt und skaliert Cluster Autoscaler wiederholt neue Knotenpools, anstatt vorhandene Knotenpools hochzuskalieren. Der ComputeClass-Status ist nicht fehlerfrei.

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 von Autopilot verwenden, definieren Sie das Feld ImageType nicht. In diesem Fall wird der Standardwert auf Clusterebene verwendet, der standardmäßig cos_containerd ist.
• Wenn Sie eine benutzerdefinierte ComputeClass von Autopilot verwenden, definieren Sie nicht das Feld nodePoolConfig, das sich eine Ebene ImageType befindet.