GKE Dataplane V2 verwenden

Auf dieser Seite wird erläutert, wie Sie GKE Dataplane V2 für GKE-Cluster (Google Kubernetes Engine) aktivieren.

Neue Autopilot-Cluster haben GKE Dataplane V2 in den Versionen 1.22.7-gke.1500 und höher und den Versionen 1.23.4-gke.1500 und höher aktiviert. Wenn bei der Verwendung von GKE Dataplane V2 Probleme auftreten, fahren Sie mit der Fehlerbehebung fort.

GKE-Cluster mit GKE Dataplane V2 erstellen

Sie können GKE Dataplane V2 aktivieren, wenn Sie neue Cluster mit GKE-Version 1.20.6-gke.700 und höher über die gcloud CLI oder die Kubernetes Engine API erstellen. Sie können GKE Dataplane V2 auch in der Vorschau aktivieren, wenn Sie neue Cluster mit GKE-Version 1.17.9 und höher erstellen.

Console

Führen Sie die folgenden Aufgaben aus, um einen neuen Cluster mit GKE Dataplane V2 zu erstellen:

  1. Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

    Zur Seite „Google Kubernetes Engine“

  2. Klicken Sie auf Erstellen.

  3. Klicken Sie auf Konfigurieren, um einen Standardcluster zu konfigurieren.

  4. Klicken Sie im Abschnitt „Netzwerk“ das Kästchen Dataplane V2 aktivieren an. Die Option „Kubernetes-Netzwerkrichtlinie aktivieren“ ist deaktiviert, wenn Sie „Dataplance V2 aktivieren“ auswählen, da die Durchsetzung von Netzwerkrichtlinien in GKE Dataplane V2 integriert ist.

  5. Klicken Sie auf Erstellen.

gcloud

Erstellen Sie mit dem folgenden Befehl einen neuen Cluster mit GKE Dataplane V2.

gcloud container clusters create CLUSTER_NAME \
    --enable-dataplane-v2 \
    --enable-ip-alias \
    --release-channel CHANNEL_NAME \
    --location COMPUTE_LOCATION

Dabei gilt:

  • CLUSTER_NAME: Der Name des neuen Clusters.
  • CHANNEL_NAME: Eine Release-Version, die die GKE-Version 1.20.6-gke.700 oder höher enthält. Wenn Sie keine Release-Version verwenden möchten, können Sie statt --release-channel auch das Flag --cluster-version verwenden und Version 1.20.6-gke.700 oder höher angeben.
  • COMPUTE_LOCATION: der Compute Engine-Standort für den neuen Cluster.

API

Zum Erstellen eines neuen Clusters mit GKE Dataplane V2 geben Sie das Feld datapathProvider im Objekt networkConfig in der Anfrage create für den Cluster an.

Das folgende JSON-Snippet zeigt die Konfiguration, die zum Aktivieren von GKE Dataplane V2 benötigt wird:

"cluster":{
   "initialClusterVersion":"VERSION",
   "ipAllocationPolicy":{
      "useIpAliases":true
   },
   "networkConfig":{
      "datapathProvider":"ADVANCED_DATAPATH"
   },
   "releaseChannel":{
      "channel":"CHANNEL_NAME"
   }
}

Dabei gilt:

  • VERSION ist Ihre Clusterversion, die die Version GKE 1.20.6-gke.700 oder höher haben muss.
  • CHANNEL_NAME ist eine Release-Version, die die GKE-Version 1.20.6-gke.700 oder höher enthält.

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

Problemumgehungen für GKE-Standardcluster

Sie können dieses Problem beheben, indem Sie die gehackten Pod-IP-Adressen für den Knoten löschen.

Zum Löschen der gehackten Pod-IP-Adressen rufen Sie die Anmeldedaten für die Authentifizierung für den Cluster ab und führen die folgenden Schritte aus, um einen einzelnen Knoten zu bereinigen, wenn Sie seinen Namen kennen.

  1. Speichern Sie das folgende Shell-Script in einer Datei mit dem Namen cleanup.sh:

    for hash in $(sudo find /var/lib/cni/networks/gke-pod-network -iregex '/var/lib/cni/networks/gke-pod-network/[0-9].*' -exec head -n1 {} \;); do hash="${hash%%[[:space:]]}"; if [ -z $(sudo ctr -n k8s.io c ls | grep $hash | awk '{print $1}') ]; then sudo grep -ilr $hash /var/lib/cni/networks/gke-pod-network; fi; done | sudo xargs -r rm

  2. Führen Sie das Script auf einem Clusterknoten aus:

    gcloud compute ssh --zone "ZONE" --project "PROJECT" NODE_NAME --command "$(cat cleanup.sh)"

    Ersetzen Sie NODE_NAME durch den Namen des Knotens.

Sie können auch eine DaemonSet-Version dieses Skripts ausführen, die parallel auf allen Knoten ausgeführt wird:

  1. Speichern Sie folgendes Manifest in einer Datei mit dem Namen cleanup-ips.yaml:

    apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: cleanup-ipam-dir
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: cleanup-ipam
  template:
    metadata:
      labels:
        name: cleanup-ipam
    spec:
      hostNetwork: true
      securityContext:
        runAsUser: 0
        runAsGroup: 0
      containers:
      - name: cleanup-ipam
        image: gcr.io/gke-networking-test-images/ubuntu-test:2022
        command:
          - /bin/bash
          - -c
          - |
            while true; do
            for hash in $(find /hostipam -iregex '/hostipam/[0-9].*' -mmin +10 -exec head -n1 {} \; ); do
            hash="${hash%%[[:space:]]}"
            if [ -z $(ctr -n k8s.io c ls | grep $hash | awk '{print $1}') ]; then
            grep -ilr $hash /hostipam
            fi
            done | xargs -r rm
            echo "Done cleaning up /var/lib/cni/networks/gke-pod-network at $(date)"
            sleep 120s
            done
        volumeMounts:
        - name: host-ipam
          mountPath: /hostipam
        - name: host-ctr
          mountPath: /run/containerd
      volumes:
      - name: host-ipam
        hostPath:
          path: /var/lib/cni/networks/gke-pod-network
      - name: host-ctr
        hostPath:
          path: /run/containerd

  2. Führen Sie das Daemonset auf dem Cluster aus:

    kubectl apply -f cleanup-ips.yaml

    Sie müssen als Administrator des Clusters Zugriff auf kubectl haben, um diesen Befehl auszuführen.

  3. Prüfen Sie die Logs des ausgeführten DaemonSets:

    kubectl -n kube-system logs -l name=cleanup-ipam

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