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

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, die dasselbe Verbindung-Tupel verwenden, 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, geben Sie den Pod über einen Proxy-Load-Balancer wie Gateway frei, 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