GKE Dataplane V2 verwenden

Auf dieser Seite wird beschrieben, wie Sie Fehler bei GKE Dataplane V2 für GKE-Cluster (Google Kubernetes Engine) beheben können.

Fehlerbehebung bei GKE Dataplane V2

In diesem Abschnitt erfahren Sie, wie Sie Probleme mit GKE Dataplane V2 untersuchen und beheben.

  1. Prüfen Sie, ob GKE Dataplane V2 aktiviert ist:

    kubectl -n kube-system get pods -l k8s-app=cilium -o wide

    Wenn GKE Dataplane V2 ausgeführt wird, enthält die Ausgabe Pods mit dem Präfix anetd-. anetd ist der Netzwerkcontroller für GKE Dataplane V2.

  2. Wenn das Problem bei Diensten oder der Durchsetzung von Netzwerkrichtlinien auftritt, prüfen Sie die anetd-Pod-Logs. Verwenden Sie in Cloud Logging die folgende Logauswahl:

    resource.type="k8s_container"
labels."k8s-pod/k8s-app"="cilium"
resource.labels.cluster_name="CLUSTER_NAME"

  3. Wenn die Pod-Erstellung fehlschlägt, suchen Sie in den Kubelet-Logs nach Hinweisen. Verwenden Sie in Cloud Logging die folgende Logauswahl:

    resource.type="k8s_node"
log_name=~".*/logs/kubelet"
resource.labels.cluster_name="CLUSTER_NAME"

    Ersetzen Sie CLUSTER_NAME durch den Namen des Clusters oder entfernen Sie ihn vollständig, um Logs für alle Cluster anzuzeigen.

Bekannte Probleme

Intervallhafte Verbindungsprobleme aufgrund von Konflikten bei NodePort-Bereichen in GKE Dataplane V2-Clustern

In GKE Dataplane V2-Clustern können bei getarntem Traffic oder bei der Verwendung von sitzungsspezifischen Ports sporadische Verbindungsprobleme auftreten. Diese Probleme sind auf mögliche Portkonflikte mit dem reservierten NodePort-Bereich zurückzuführen und treten normalerweise in den folgenden Szenarien auf:

  • Benutzerdefiniert;ip-masq-agent Wenn Sie eine benutzerdefinierte ip-masq-agent (Version 2.10 oder höher) verwenden, für die der Cluster NodePort- oder Load Balancer-Dienste hat, können aufgrund von Konflikten mit dem NodePort-Bereich sporadische Verbindungsprobleme auftreten. Seit Version 2.10 ist in ip-masq-agent das Argument --random-fully standardmäßig intern implementiert. Um dieses Problem zu umgehen, legen Sie explizit --random-fully=false (gilt seit Version 2.11) unter Argumenten in Ihrer ip-masq-agent-Konfiguration fest. Weitere Konfigurationsdetails finden Sie unter IP-Masquerade-Agent in Standardclustern konfigurieren.

  • Sitzungsspezifische Überschneidung im Portbereich: Wenn sich der von net.ipv4.ip_local_port_range auf Ihren GKE-Knoten definierte sitzungsspezifische Portbereich mit dem NodePort-Bereich (30000–32767) überschneidet, kann dies auch Verbindungsprobleme auslösen. Achten Sie darauf, dass sich diese beiden Bereiche nicht überschneiden, um dieses Problem zu vermeiden.

Prüfen Sie Ihre ip-masq-agent-Konfiguration und die Einstellungen für den sitzungsspezifischen Portbereich, um sicherzustellen, dass sie nicht mit dem NodePort-Bereich in Konflikt stehen. Wenn Verbindungsprobleme auftreten, beachten Sie diese möglichen Ursachen und passen Sie Ihre Konfiguration entsprechend an.

Nicht wirksame Portbereiche von Netzwerkrichtlinien

Wenn Sie in einer Netzwerkrichtlinie ein Feld vom Typ endPort in einem Cluster angeben, für den GKE Dataplane V2 aktiviert ist, wird dies nicht wirksam.

Ab GKE 1.22 können Sie mit der Kubernetes Network Policy API einen Portbereich angeben, an dem die Netzwerkrichtlinie erzwungen wird. Diese API wird in Clustern mit Calico Network Policy unterstützt, aber nicht in Clustern mit GKE Dataplane V2.

Sie können das Verhalten Ihrer NetworkPolicy-Objekte prüfen, indem Sie sie zurücklesen, nachdem sie auf den API-Server geschrieben wurden. Wenn das Objekt noch das Feld endPort enthält, wird die Funktion erzwungen. Wenn das Feld endPort fehlt, wird die Funktion nicht erzwungen. In allen Fällen ist das auf dem API-Server gespeicherte Objekt die "Source of Truth" für die Netzwerkrichtlinie.

Weitere Informationen finden Sie unter KEP-2079: Netzwerkrichtlinie zur Unterstützung von Portbereichen.

Pods zeigen failed to allocate for range 0: no IP addresses available in range set-Fehlermeldung an

Betroffene GKE-Versionen: 1.22 bis 1.25

Bei GKE-Clustern, auf denen Knotenpools ausgeführt werden, die containerd verwenden und GKE Dataplane V2 aktiviert ist, kann es zu Problemen bei IP-Adressenlecks kommen. Außerdem können alle Pod-IP-Adressen auf einem Knoten erschöpft sein. Ein Pod, der auf einem betroffenen Knoten geplant ist, zeigt eine Fehlermeldung ähnlich der folgenden an:

failed to allocate for range 0: no IP addresses available in range set: 10.48.131.1-10.48.131.62

Weitere Informationen zu dem Problem finden Sie unter Containerd-Problem 5768.

Feste Versionen

Aktualisieren Sie Ihren Cluster auf eine der folgenden GKE-Versionen, um dieses Problem zu beheben:

  • 1.22.17-gke.3100 oder höher.
  • 1.23.16-gke.200 oder höher.
  • 1.24.9-gke.3200 oder höher.
  • 1.25.6-gke.200 oder höher.

Netzwerkrichtlinie bricht eine Verbindung aufgrund einer falschen Verbindungsverfolgung ab

Wenn 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 Service 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.

Feste Versionen

Aktualisieren Sie Ihren Cluster auf eine der folgenden GKE-Versionen, um dieses Problem zu beheben:

  • 1.28.3-gke.1090000 oder höher

Problemumgehungen

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

Paketdrops für Hairpin-Anschlussflows

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

Feste Versionen

Aktualisieren Sie Ihren Cluster auf eine der folgenden GKE-Versionen, um dieses Problem zu beheben:

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

Problemumgehungen

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

  • Aktivieren Sie die TCP-Wiederverwendung (Keep-Alives) für Anwendungen, die in Pods ausgeführt werden und möglicherweise über einen Service mit sich selbst kommunizieren. 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 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.

Nächste Schritte