Bekannte Probleme mit GKE-Netzwerken

Auf dieser Seite werden bekannte Probleme mit der GKE-Netzwerkfunktion 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.

Zum Filtern der bekannten Probleme nach einer Produktversion wählen Sie in den folgenden Drop-down-Menüs die gewünschten Filter aus.

Wählen Sie Ihre GKE-Version aus:

Oder suchen Sie nach Ihrem Problem:

Ermittelte Version(en) Korrigierte Version(en) Problem und Problemumgehung
1.31, 1.32, 1.33
  • 1.33.1-gke.1107000 und höher

Ausfälle von Ingress- und Service-Load-Balancern in Clustern mit einem Legacy-Netzwerk

Eine Inkompatibilität mit Legacy-Netzwerken führt dazu, dass die Backends eines GKE-verwalteten Load Balancers, der mit Ingress oder Service bereitgestellt wird, getrennt werden. Dadurch hat der Load Balancer keine aktiven Back-Ends mehr, was wiederum dazu führt, dass alle eingehenden Anfragen an diese Load Balancer verworfen werden.

Das Problem betrifft GKE-Cluster, die ein Legacy-Netzwerk verwenden und die Version 1.31 oder höher haben.

Führen Sie den folgenden Befehl aus, um GKE-Cluster mit einem Legacy-Netzwerk zu identifizieren: 

    gcloud container clusters describe CLUSTER_NAME --location=LOCATION --format="value(subnetwork)"

Bei einem Cluster mit einem Legacy-Netzwerk ist die Ausgabe für diesen Befehl leer.

Workaround:

Da Legacy-Netzwerke schon seit einiger Zeit eingestellt wurden, ist die bevorzugte Lösung, Ihr Legacy-Netzwerk zu einem VPC-Netzwerk zu migrieren. Dazu können Sie ein Legacy-Netzwerk umwandeln, das GKE-Cluster enthält. Wenn Sie diese Migration derzeit nicht durchführen können, wenden Sie sich an den Cloud Customer Care.

1.30, 1.31, 1.32
  • 1.30.10-gke.1070000 und höher
  • 1.31.5-gke.1068000 und höher
  • 1.32.1-gke.1002000 und höher

Neu erstellte Knoten werden nicht den internen Layer-4-Load-Balancern hinzugefügt.

Bei Google Cloud -Load-Balancern, die für interne LoadBalancer-Dienste erstellt werden, fehlen möglicherweise neu erstellte Knoten in der Backend-Instanzgruppe.

Das Problem ist am deutlichsten in einem Cluster zu sehen, der auf null Knoten skaliert und dann wieder auf einen oder mehrere Knoten skaliert wurde.

Problemumgehungen:

  • Aktivieren Sie die GKE-Teileinstellung und erstellen Sie den Dienst neu.

    Hinweis: Die GKE-Teilmengeneinstellung kann nicht deaktiviert werden, nachdem sie aktiviert wurde.

  • Erstellen Sie einen weiteren internen Load-Balancing-Dienst. Wenn die Synchronisierung erfolgt, wird die Instanzgruppe auch für den betroffenen Dienst korrigiert. Der neue Dienst kann nach der Synchronisierung entfernt werden.
  • Fügen Sie einem der Knoten das Label node.kubernetes.io/exclude-from-external-load-balancers hinzu und entfernen Sie es dann wieder.
  • Fügen Sie dem Cluster einen Knoten hinzu. Sie können den Knoten entfernen, nachdem der Dienst funktioniert.
1.27,1.28,1.29,1.30,1.31

NEG-Controller verwaltet Endpunkte nicht mehr, wenn Port aus Dienst entfernt wird

Wenn der NEG-Controller so konfiguriert ist, dass er eine eigenständige NEG für einen Dienst erstellt, und einer der konfigurierten Ports später aus dem Dienst entfernt wird, verwaltet der NEG-Controller schließlich keine Endpunkte mehr für die NEG. Neben Diensten, für die der Nutzer eine eigenständige NEG-Annotation erstellt, betrifft dies auch Dienste, auf die von GKE Gateway, MCI und GKE Multi-Cluster-Gateway verwiesen wird.

Workaround:

Wenn Sie einen Port aus einem Dienst mit einer eigenständigen NEG-Annotation entfernen, muss die Annotation auch aktualisiert werden, um den betreffenden Port zu entfernen.

1,28

Gateway-TLS-Konfigurationsfehler

Wir haben ein Problem bei der Konfiguration von TLS für Gateways in Clustern mit GKE-Version 1.28.4-gke.1083000 festgestellt. Dies betrifft TLS-Konfigurationen mit einem SSLCertificate oder einer CertificateMap. Wenn Sie einen Cluster mit vorhandenen Gateways aktualisieren, schlagen Aktualisierungen des Gateways fehl. Bei neuen Gateways werden die Load-Balancer nicht bereitgestellt. Dieses Problem wird in einer zukünftigen GKE 1.28-Patchversion behoben.

1.27,1.28,1.29
  • 1.26.13-gke.1052000 und höher
  • 1.27.10-gke.1055000 und höher
  • 1.28.6-gke.1095000 und höher
  • 1.29.1-gke.1016000 und höher

Zeitweise fehlgeschlagene Verbindungsaufbauten

Bei Clustern mit Steuerungsebenenversionen ab 1.26.6-gke.1900 kann es zu zeitweiligen Fehlern beim Herstellen von Verbindungen kommen.

Die Wahrscheinlichkeit von Fehlern ist gering und sie betreffen nicht alle Cluster. Die Ausfälle sollten nach einigen Tagen nach dem Auftreten der Symptome vollständig aufhören.

1.27,1.28,1.29
  • 1.27.11-gke.1118000 oder höher
  • 1.28.7-gke.1100000 oder höher
  • 1.29.2-gke.1217000 oder höher

Probleme mit der DNS-Auflösung bei Container-Optimized OS

Bei Arbeitslasten, die auf GKE-Clustern mit Knoten auf Basis von Container-Optimized OS ausgeführt werden, kann es zu Problemen bei der DNS-Auflösung kommen.

1,28 1.28.3-gke.1090000 oder höher

Netzwerkrichtlinie bricht eine Verbindung aufgrund einer falschen Verbindungsverfolgung ab

Wenn in Clustern mit aktivierter GKE Dataplane V2 ein Client-Pod über einen Dienst oder die virtuelle IP-Adresse eines internen Passthrough-Network Load Balancer eine Verbindung zu sich selbst herstellt, wird das Antwortpaket aufgrund eines falschen Conntrack-Lookups in der Datenebene nicht als Teil einer vorhandenen Verbindung identifiziert. Das bedeutet, dass eine Netzwerkrichtlinie, die eingehenden Traffic für den Pod einschränkt, für das Paket falsch erzwungen wird.

Die Auswirkungen dieses Problems hängen von der Anzahl der konfigurierten Pods für den Dienst ab. Wenn der Dienst beispielsweise einen Backend-Pod hat, schlägt die Verbindung immer fehl. Wenn der Dienst zwei Backend-Pods hat, schlägt die Verbindung in 50% der Fälle fehl.

Workaround:

Sie können dieses Problem mindern, indem Sie port und containerPort im Service-Manifest auf denselben Wert festlegen.

1.27,1.28
  • 1.28.3-gke.1090000 oder höher
  • 1.27.11-gke.1097000 oder höher

Paketdrops für Hairpin-Anschlussflows

Wenn in Clustern mit aktiviertem GKE Dataplane V2 ein Pod mithilfe eines Service eine TCP-Verbindung zu sich selbst erstellt, sodass der Pod sowohl Quelle als auch Ziel der Verbindung ist, überwacht die GKE Dataplane V2 eBPF-Verbindungsüberwachung den Verbindungsstatus nicht korrekt, was zu verlorenen conntrack-Einträgen führt.

Wenn ein Verbindungstupel (Protokoll, Quell-/Ziel-IP und Quell-/Zielport) offengelegt wurde, kann es bei neuen Verbindungen mit demselben Verbindungstupel dazu kommen, dass Rückgabepakete verworfen werden.

Workaround:

Versuchen Sie einen der folgenden Schritte, um das Problem zu umgehen:

  • Aktivieren Sie die TCP-Wiederverwendung (Keep-Alives) für eine Anwendung, die in einem Pod ausgeführt wird und möglicherweise über einen Service mit sich selbst kommuniziert. Dadurch wird verhindert, dass das TCP FIN-Flag ausgegeben wird und dass der Conntrack-Eintrag ausgegeben wird.
  • Wenn Sie kurzlebige Verbindungen verwenden, machen Sie den Pod über einen Proxy-Load-Balancer wie Gateway verfügbar, um den Dienst verfügbar zu machen. Dies führt dazu, dass das Ziel der Verbindungsanfrage auf die IP-Adresse des Load-Balancers festgelegt wird. Dadurch wird verhindert, dass GKE Dataplane V2 SNAT zum Loopback der IP-Adresse ausführt.
Älter als 1.31.0-gke.1506000 1.31.0-gke.1506000 und höher

Gerätetypisiertes Netzwerk in GKE-Multi-Netzwerk schlägt bei langen Netzwerknamen fehl

Die Clustererstellung schlägt mit dem folgenden Fehler fehl:

error starting very-long-string-that-exceeds-character-limit-gpu-nic0 device plugin endpoint: listen unix /var/lib/kubelet/plugins_registry/networking.gke.io.networks_very-long-string-that-exceeds-character-limit-gpu-nic0.sock: bind: invalid argument

Workaround:

Beschränken Sie die Länge von Namen von Netzwerkobjekten mit Gerätetyp auf maximal 41 Zeichen. Der vollständige Pfad jedes UNIX-Domain-Sockets wird zusammengesetzt, einschließlich des entsprechenden Netzwerknamens. Unter Linux gilt eine Beschränkung für die Länge von Socket-Pfaden (unter 107 Byte). Nach Berücksichtigung des Verzeichnisses, des Dateinamenpräfixes und der Erweiterung .sock ist der Netzwerkname auf maximal 41 Zeichen begrenzt.
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 Upgrade der Steuerungsebene

Bei Clustern mit aktivierter Netzwerkrichtlinie können Verbindungsprobleme mit hostPort-Pods auftreten. Außerdem kann es bei neu erstellten Pods zusätzlich 30 bis 60 Sekunden dauern, bis sie 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:

Aktualisieren oder erstellen Sie Knoten unmittelbar nach dem Upgrade der GKE-Steuerungsebene neu.
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, für die die knoteninterne Sichtbarkeit aktiviert ist, kann es zu Problemen mit dem UDP-Traffic zwischen Pods kommen, die auf demselben Knoten ausgeführt werden.

Das Problem tritt auf, wenn der GKE-Clusterknoten auf eine der folgenden GKE-Versionen aktualisiert oder mit einer dieser Versionen erstellt wird:

  • 1.32.1-gke.1729000 oder höher
  • 1.31.6-gke.1020000 oder höher

Der betroffene Pfad ist Pod-zu-Pod-UDP-Traffic auf demselben Knoten über Hostport oder Dienst.

Lösung

Aktualisieren Sie den Cluster auf eine der folgenden korrigierten Versionen:

  • 1.32.3-gke.1927000 oder höher
  • 1.31.7-gke.1390000 oder höher
1.28, 1.29, 1.30, 1.31

Calico-Pods sind in Clustern mit weniger als 3 Knoten und unzureichender vCPU nicht fehlerfrei

Die Pods „calico-typha“ und „calico-node“ können nicht in Clustern geplant werden, die alle folgenden Bedingungen erfüllen: weniger als 3 Knoten insgesamt, jeder Knoten mit maximal 1 zuweisbaren vCPU und Netzwerkrichtlinie aktiviert aktiviert. Das liegt an unzureichenden CPU-Ressourcen.

Problemumgehungen:

  • Skalieren Sie auf mindestens 3 Knotenpools mit 1 Knoten mit 1 zuweisbaren vCPU.
  • Ändern Sie die Größe eines einzelnen Knotenpools auf mindestens 3 Knoten mit 1 zuweisbaren vCPU.
  • Verwenden Sie einen Maschinentyp mit mindestens zwei zuweisbaren vCPUs in einem Knotenpool mit einem einzelnen Knoten.