Bekannte Probleme mit GKE-Netzwerken

Auf dieser Seite sind bekannte Probleme mit GKE-Netzwerken 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:

Sie können auch nach Ihrem Problem suchen:

Erkannte Version(en) Korrigierte Version(en) Problem und Problemumgehung
1.30, 1.31, 1.32

Neu erstellte Knoten werden den internen Layer-4-Load Balancern nicht 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 bei 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. Bei der Synchronisierung wird auch die Instanzgruppe für den betroffenen Dienst korrigiert. Der neue Dienst kann nach der Synchronisierung entfernt werden.
  • Fügen Sie das Label node.kubernetes.io/exclude-from-external-load-balancers einem der Knoten hinzu und entfernen Sie es dann wieder.
  • Fügen Sie dem Cluster einen Knoten hinzu. Sie können den Knoten entfernen, nachdem der Dienst gestartet wurde.
1.27,1.28,1.29,1.30,1.31

NEG-Controller beendet die Verwaltung von Endpunkten, wenn Port aus Dienst entfernt wird

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

Workaround:

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

1,28

Fehler bei der TLS-Konfiguration des Gateways

Wir haben ein Problem bei der Konfiguration von TLS für Gateways in Clustern mit der GKE-Version 1.28.4-gke.1083000 festgestellt. Das betrifft TLS-Konfigurationen, bei denen entweder ein SSLCertificate oder eine CertificateMap verwendet wird. 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 Verbindungsaufbauversuche

Bei Clustern mit Steuerungsebenen-Versionen ab 1.26.6-gke.1900 kann es zu zeitweiligen Verbindungsaufbaufehlern kommen.

Die Wahrscheinlichkeit von Ausfällen ist gering und sie betreffen nicht alle Cluster. Die Ausfälle sollten nach einigen Tagen nach Beginn 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 in GKE-Clustern mit Container-Optimized OS-basierten Knoten ausgeführt werden, kann es zu DNS-Auflösungsproblemen 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 Balancers 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 Service 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 bei 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 Verbindungs-Tupel (Protokoll, Quell-/Ziel-IP und Quell-/Zielport) gehackt wurde, können neue Verbindungen mit demselben Verbindungs-Tupel dazu führen, 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 Dienst 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, stellen Sie den Pod mit einem Proxy-Load Balancer wie Gateway bereit, um den Dienst zu veröffentlichen. 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ätetypisches Netzwerk in GKE-Multi-Netzwerk funktioniert bei langen Netzwerknamen nicht

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:

Begrenzen Sie die Länge von von Geräten eingegebenen Netzwerkobjektnamen auf maximal 41 Zeichen. Der vollständige Pfad jedes UNIX-Domain-Sockets wird zusammengesetzt, einschließlich des entsprechenden Netzwerknamens. Unter Linux ist die Länge von Socket-Pfaden auf unter 107 Byte beschränkt. Abzüglich des Verzeichnisses, des Dateinamenspräfixes und der .sock-Erweiterung darf der Netzwerkname maximal 41 Zeichen lang sein.
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 bei neu erstellten Pods weitere 30 bis 60 Sekunden dauern, bis sie einsatzbereit 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.
1.28, 1.29, 1.30, 1.31

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

Calico-typha- und calico-node-Pods können nicht in Clustern geplant werden, die alle folgenden Bedingungen erfüllen: weniger als 3 Knoten insgesamt, jeder Knoten hat eine oder weniger zuweisbare vCPUs und Netzwerkrichtlinie aktiviert. Das liegt an unzureichenden CPU-Ressourcen.

Problemumgehungen:

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