Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

GKE Dataplane V2 verwenden

Autopilot Standard

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

GKE Dataplane V2 ist in neuen Autopilot-Clustern immer aktiviert. Wenn bei der Verwendung von GKE Dataplane V2 Probleme auftreten, fahren Sie mit der Fehlerbehebung fort.

Hinweis

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

Aktivieren Sie die Google Kubernetes Engine API.

Google Kubernetes Engine API aktivieren

Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl gcloud components update ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.
Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI das compute/region-Attribut fest. Wenn Sie hauptsächlich zonale Cluster verwenden, legen Sie stattdessen compute/zone fest. Wenn Sie einen standardmäßigen Speicherort festlegen, können Sie in der gcloud CLI Fehler wie diesen vermeiden: One of [--zone, --region] must be supplied: Please specify location. Bei bestimmten Befehlen müssen Sie möglicherweise den Speicherort angeben, wenn er sich von dem von Ihnen festgelegten Standard unterscheidet.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle „Administrator für Kubernetes Engine-Cluster“ (container.clusterAdmin) für das Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Erstellen eines GKE-Cluster benötigen. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

GKE-Cluster mit GKE Dataplane V2 erstellen

Sie können GKE Dataplane V2 nur aktivieren, wenn Sie einen neuen GKE-Cluster erstellen. Diese Einstellung kann für einen vorhandenen Cluster nicht geändert werden.

Wenn Sie einen Standardcluster erstellen möchten, der GKE Dataplane V2 verwendet, wählen Sie eine der folgenden Optionen aus:

Console

Rufen Sie in der Google Cloud Console die Seite Kubernetes-Cluster erstellen auf.
Zur Seite „Kubernetes-Cluster erstellen“
Klicken Sie im Navigationsmenü auf Netzwerk.
Maximieren Sie den Abschnitt Container Network Interface (CNI).
Klicken Sie das Kästchen Dataplane V2 an.
Klicken Sie auf Erstellen.

gcloud

Führen Sie dazu diesen Befehl aus:

gcloud container clusters create CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-dataplane-v2

Ersetzen Sie Folgendes:

CLUSTER_NAME: ein Name für den neuen Cluster.
CONTROL_PLANE_LOCATION: ein Standort für die Steuerungsebene des Clusters.

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":{
    "networkConfig":{
      "datapathProvider":"ADVANCED_DATAPATH"
    }
}

Fehlerbehebung bei GKE Dataplane V2

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

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.
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"
```
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.
Wenn die anetd-Pods nicht ausgeführt werden, prüfen Sie die ConfigMap „cilium-config“ auf Änderungen. Vermeiden Sie es, vorhandene Felder in dieser ConfigMap zu ändern, da solche Änderungen den Cluster destabilisieren und anetd stören können. Die ConfigMap wird nur dann wieder in den Standardzustand versetzt, wenn neue Felder hinzugefügt werden. Änderungen an vorhandenen Feldern werden nicht zurückgepatcht. Wir empfehlen, den ConfigMap nicht zu ändern oder anzupassen.

Bekannte Probleme

Wenn Sie GKE Dataplane V2 verwenden, können die folgenden bekannten Probleme auftreten.

Zeitüberschreitungen bei Verbindungen für nicht bereite Pods

Wenn ein Pod nicht bereit ist, können Verbindungen zum zugehörigen Dienst Zeitüberschreitungen verursachen. Dies ist das erwartete Verhalten für GKE Dataplane V2 und unterscheidet sich von kube-proxy, das einen schnelleren connection refused-Fehler zurückgeben kann.

Die Filterung von identitätsrelevanten Labels für Cilium Identity wird nicht wirksam und Pods bleiben im Status „ContainerCreating“ hängen

Betroffene Versionen: 1.34, 1.35

In GKE Dataplane V2-Clustern wird die Notfallverwendung der Filterung von identitätsbezogenen Labels über die kube-system/cilium-config-emergency-override-ConfigMap in den betroffenen Versionen nicht korrekt angewendet.

Bei diesem Ansatz wird eingeschränkt, welche Pod-Labels für die Generierung von Cilium-Identitäten verwendet werden.

Wenn andere Mechanismen zum Verhindern/Entfernen von Label-Schlüssel/-Werten mit hoher Kardinalität aus Pods nicht verfügbar sind (z. B. wenn Labels von einem Tool oder Framework angewendet werden), kann die Filterung von identitätsrelevanten Labels verwendet werden, um die Label-Schlüssel aus der Cilium-Identitätsberechnung auszuschließen. Weitere Informationen zum Konfigurieren dieser Regeln finden Sie in der Cilium-Dokumentation unter Identity-Relevant Labels.

Bei den betroffenen GKE-Versionen enthalten die vom Operator erstellten Cilium-Identitäten weiterhin die ausgeschlossenen Labels.

Symptome

Pods mit Labels, die für die Cilium-Identitätsgenerierung gefiltert werden sollen, können möglicherweise nicht gestartet werden und bleiben im Status ContainerCreating hängen. In Pod-Ereignissen werden möglicherweise Zeitüberschreitungsfehler angezeigt:

  {"level":"warning", "msg":"Error changing endpoint identity", "error":"unable to resolve identity: timed out waiting for cilium-operator to allocate CiliumIdentity for key ...;, error: exponential backoff cancelled via context: context canceled", "k8sPodName":"...", "subsys":"endpoint"}

Anstatt Identitäten basierend auf gefilterten Labels freizugeben, generieren Pods mit eindeutigen Labelwerten weiterhin eindeutige Cilium-Identitäten. Dies kann zu einem starken Anstieg der Identitäten führen, wodurch die verfügbaren Cilium-Identitäten (bis zu einem Limit von 65.536) möglicherweise erschöpft werden und Skalierbarkeitsprobleme auftreten.

Korrigierte Versionen

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

1.34.6-gke.1307000 oder höher
1.35.2-gke.1962000 oder höher

Problemumgehung

Als Workaround können Sie die Label-Filterregeln auf das Feld data.labels in der Haupt-ConfigMap cilium-config anwenden und sie aus cilium-config-emergency-override entfernen. Diese Situation bleibt auch bei Steuerungsebenenvorgängen wie Upgrades bestehen, da GKE Nutzermodifikationen an Feldern beibehält, die nicht in der cilium-config-ConfigMap verwaltet werden.

Entfernen Sie den Schlüssel labels aus dem Abschnitt data der ConfigMap cilium-config-emergency-override, falls er vorhanden ist.
Bearbeiten Sie die ConfigMap cilium-config, indem Sie den Schlüssel labels im Abschnitt data hinzufügen oder ändern. Wenn Sie beispielsweise verhindern möchten, dass Labels mit dem Namen uuid für die Identitätsgenerierung verwendet werden:
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: cilium-config
  namespace: kube-system
data:
  # ... other existing keys
  labels: "!uuid"
  # ... other existing keys
```

Starten Sie anet-operator auf der Steuerungsebene neu, indem Sie die Steuerungsebene auf die gleiche Version aktualisieren, die darauf ausgeführt wird. Dadurch wird der Operator gezwungen, seine Konfiguration neu zu starten und neu zu laden:

gcloud container clusters upgrade CLUSTER_NAME \
    --location CLUSTER_LOCATION \
    --project PROJECT_ID \
    --cluster-version $(gcloud container clusters describe CLUSTER_NAME --location CLUSTER_LOCATION --project PROJECT_ID --format="value(currentMasterVersion)") \
    --master

Starten Sie nach dem Neustart der Steuerungsebene das anetd-DaemonSet neu, damit auch die Knoten-Agents alle erforderlichen Änderungen übernehmen:
```
kubectl rollout restart daemonset anetd -n kube-system
```

Intermittierende Verbindungsprobleme im Zusammenhang mit `NodePort`-Bereichskonflikten in GKE Dataplane V2-Clustern

In GKE Dataplane V2-Clustern können intermittierende Verbindungsprobleme bei maskiertem Traffic oder bei der Verwendung von ephemeren Ports auftreten. Diese Probleme sind auf potenzielle Portkonflikte mit dem reservierten Bereich NodePort zurückzuführen und treten in der Regel 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 Informationen zur Konfiguration 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 die Konfiguration von ip-masq-agent und die Einstellungen für den Bereich der temporären Ports, um sicherzustellen, dass sie nicht mit dem Bereich von NodePort in Konflikt stehen. Wenn Sie zeitweise Verbindungsprobleme haben, sollten Sie diese möglichen Ursachen in Betracht ziehen und Ihre Konfiguration entsprechend anpassen.

Verbindungsprobleme mit `hostPort` in GKE Dataplane V2-Clustern

Betroffene GKE-Versionen:Alle verfügbaren Versionen

In Clustern, die GKE Dataplane V2 verwenden, können Verbindungsfehler auftreten, wenn der Traffic auf die IP-Adresse:Port eines Knotens gerichtet ist, wobei „Port“ der im Pod definierte hostPort ist. Diese Probleme treten in zwei Hauptszenarien auf:

Knoten mit hostPort hinter einem Passthrough-Network-Load-Balancer:

hostPort bindet einen Pod an den Port eines bestimmten Knotens und ein Passthrough Network Load Balancer verteilt den Traffic auf alle Knoten. Wenn Sie Pods über hostPort und einen Passthrough-Network-Load-Balancer im Internet verfügbar machen, sendet der Load-Balancer möglicherweise Traffic an einen Knoten, auf dem der Pod nicht ausgeführt wird, was zu Verbindungsfehlern führt. Dies ist auf eine bekannte Einschränkung in GKE Dataplane V2 zurückzuführen, bei der der Traffic von Passthrough-Network Load Balancern nicht konsistent an hostPort-Pods weitergeleitet wird.

Problemumgehung:Wenn Sie hostPort eines Pods auf dem Knoten mit einem Passthrough-Network Load Balancer bereitstellen, geben Sie die interne oder externe IP-Adresse des Network Load Balancers im Feld hostIP des Pods an.
```
ports:
- containerPort: 62000
  hostPort: 62000
  protocol: TCP
  hostIP: 35.232.62.64
- containerPort: 60000
  hostPort: 60000
  protocol: TCP
  hostIP: 35.232.62.64
  # Assuming 35.232.62.64 is the external IP address of a passthrough Network Load Balancer.
```
hostPort-Konflikt mit reserviertem NodePort-Bereich:

Wenn der hostPort eines Pods mit dem reservierten NodePort-Bereich (30000–32767) in Konflikt steht, kann Cilium den Traffic möglicherweise nicht an den Pod weiterleiten. Dieses Verhalten tritt auf, weil Cilium hostPort-Funktionen verwaltet und die vorherige Portmap-Methode ersetzt. Dies ist ein erwartetes Verhalten für Cilium und wird in der öffentlichen Dokumentation erwähnt.

Wir planen nicht, diese Einschränkungen in späteren Versionen zu beheben. Die Ursache dieser Probleme hängt mit dem Verhalten von Cilium zusammen und liegt außerhalb des direkten Einflussbereichs von GKE.

Empfehlung:Wir empfehlen, für eine höhere Zuverlässigkeit zu NodePort-Diensten anstelle von hostPort zu migrieren. NodePort Die Dienste bieten ähnliche Funktionen.

Portbereiche für Netzwerkrichtlinien werden nicht wirksam

Betroffene GKE-Versionen:vor 1.32

Wenn Sie das Feld endPort in einem NetworkPolicy-Objekt in einem Cluster angeben, für den GKE Dataplane V2 aktiviert ist und der eine GKE-Version vor 1.32 ausführt, ignoriert Kubernetes das Feld.

Mit der Kubernetes-NetworkPolicy-API können Sie einen Portbereich angeben, in dem Kubernetes die Netzwerkrichtlinie erzwingt. Diese API wird in Clustern mit Calico Network Policy und in Clustern mit GKE Dataplane V2 unterstützt, auf denen GKE-Version 1.32 oder höher ausgeführt wird. Die API wird in GKE Dataplane V2-Clustern, auf denen Versionen vor 1.32 ausgeführt werden, nicht unterstützt.

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 von Kubernetes erzwungen. Wenn das Feld endPort fehlt, wird die Funktion von Kubernetes nicht erzwungen. Das auf dem API-Server gespeicherte Objekt ist die „Source of Truth“ für die Netzwerkrichtlinie.

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

Feste Versionen

Aktualisieren Sie Ihren Cluster auf GKE-Version 1.32 oder höher, um dieses Problem zu beheben.

Knoten im Status `NodeNotReady` aufgrund des fehlenden `containerID`-Fehlers

Wenn Cluster auf GKE-Version 1.35.1-gke.1616000 und höher aktualisiert werden, können Knoten sofort in den Status NodeNotReady wechseln, wenn sowohl GKE Dataplane V2 als auch Cloud Service Mesh aktiviert sind.

Ursache

Ab der GKE-Version 1.35.1-gke.1616000 verwenden GKE Dataplane V2-Cluster die CNI-Version 1.1.0 in ihren CNI-Konfigurationsdateien. Diese Änderung erfordert, dass nachgelagerte CNI-Plug-ins wie Google Managed Istio auch CNI-Version 1.1.0 unterstützen. Aufgrund einer Verzögerung bei der Einführung von Managed Istio haben einige Cluster noch nicht die kompatible Version (1.23) erhalten, was zum Initialisierungsfehler führt.

Symptome

Betroffene Knoten werden sofort als NodeNotReady angezeigt. Die folgende Fehlermeldung wird in den containerd-Logs angezeigt:

NetworkPluginNotReady message:Network plugin returns error: missing containerID

Problemumgehung

Um das Problem zu beheben, führen Sie ein Downgrade des betroffenen Clusters auf eine GKE-Version vor 1.35.1-gke.1616000 durch.

Beeinträchtigung durch benutzerdefinierte eBPF-Programme

GKE verwendet eBPF-Programme, um das Netzwerk für GKE Dataplane V2 zu verwalten. Wenn Sie benutzerdefinierte eBPF-Programme auf von GKE verwalteten Netzwerkschnittstellen von Knoten bereitstellen, können diese Programme die von GKE verwalteten eBPF-Programme beeinträchtigen und Netzwerkprobleme verursachen.

GKE unterstützt keine benutzerdefinierten eBPF-Programme, die an die folgenden Netzwerkschnittstellen angehängt sind:

eth*
ens4
lo
cilium*
gke*
veth*

Das Vorhandensein benutzerdefinierter eBPF-Programme auf diesen Schnittstellen kann die vom anetd-Agent installierten Programme von GKE Dataplane V2 beeinträchtigen, was zu Störungen im Clusternetzwerk führen kann. Wir empfehlen, alle benutzerdefinierten eBPF-Programme oder Arbeitslasten, die solche Programme einfügen, aus Ihrem Cluster zu entfernen.

Benutzerdefinierte eBPF-Programme entdecken

Wenn Sie benutzerdefinierte eBPF-Programme ermitteln möchten, die auf Clusternknoten ausgeführt werden, können Sie ein DaemonSet erstellen, das mit der Einstellung hostNetwork: true konfiguriert ist und bpftool verwendet, um solche eBPF-Programme abzufragen:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: bpftool-logger
  labels:
    app: bpftool-logger
spec:
  selector:
    matchLabels:
      app: bpftool-logger
  template:
    metadata:
      labels:
        app: bpftool-logger
    spec:
      hostPID: true
      hostNetwork: true
      containers:
      - name: bpftool
        image: ubuntu:22.04
        securityContext:
          privileged: true
        env:
        - name: NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        command:
        - /bin/bash
        - -c
        - |
          echo "Installing dependencies..."
          apt-get update -y > /dev/null 2>&1
          apt-get install -y curl tar > /dev/null 2>&1

          echo "Downloading and setting up bpftool..."
          curl -sL https://github.com/libbpf/bpftool/releases/download/v7.7.0/bpftool-v7.7.0-amd64.tar.gz | tar xz
          chmod +x bpftool
          mv bpftool /usr/local/bin/

          echo "========== $(date) | Node: ${NODE_NAME} =========="
          bpftool net | grep -E '^(eth|ens4|lo|cilium|gke|veth)' | grep -v ' cil_'
          sleep infinity

Speichern Sie das Manifest als ebpf-discovery.yaml und wenden Sie das DaemonSet an:
```
kubectl apply -f ebpf-discovery.yaml
```

Warten Sie, bis die Pods ausgeführt werden:

kubectl rollout status ds/bpftool-logger

Prüfen Sie die Logs der Pods, um eBPF-Programme zu finden:
```
kubectl logs -l app=bpftool-logger
```
Wenn Sie fertig sind, löschen Sie das DaemonSet:
```
kubectl delete -f ebpf-discovery.yaml
```