GKE Dataplane V2 verwenden

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

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 GKE 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 Kubernetes-Cluster erstellen auf.

    Kubernetes-Cluster erstellen

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

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

  4. Wenn die anetd-Pods nicht ausgeführt werden, prüfen Sie die ConfigMap „cilium-config“ auf Änderungen. Ändern Sie keine vorhandenen Felder in dieser ConfigMap, da solche Änderungen den Cluster destabilisieren und anetd stören können. Die ConfigMap wird nur dann auf den Standardzustand zurückgesetzt, wenn neue Felder hinzugefügt werden. Änderungen an vorhandenen Feldern werden nicht zurückgesetzt. Wir empfehlen, die ConfigMap nicht zu ändern oder anzupassen.

Bekannte Probleme

Bei der Verwendung von GKE Dataplane V2 können die folgenden bekannten Probleme auftreten.

Zeitüberschreitungen bei Verbindungen für nicht bereite Pods

Wenn ein Pod nicht bereit ist, kann es bei Verbindungen zum zugehörigen Dienst zu Zeitüberschreitungen kommen. Dies ist das erwartete Verhalten für GKE Dataplane V2. Es unterscheidet sich von kube-proxy, das schneller einen Fehler vom Typ connection refused zurückgeben kann.

Die Filterung von identitätsrelevanten Labels für die Cilium-Identität wird nicht angewendet und Pods bleiben im Status „ContainerCreating“

Betroffene Versionen: 1.34, 1.35

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

Dieser Ansatz beschränkt, welche Pod-Labels für die Cilium-Identitätsgenerierung verwendet werden.

Wenn andere Mechanismen zum Verhindern/Entfernen von Label-Schlüssel/Wert-Paaren 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 Identity-Relevant Labels in der Cilium-Dokumentation.

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 sollten, können möglicherweise nicht gestartet werden und bleiben im Status ContainerCreating. In den 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 Label-Werten weiterhin eindeutige Cilium-Identitäten. Dies kann zu einem starken Anstieg der Identitäten führen, wodurch die verfügbaren Cilium-Identitäten möglicherweise erschöpft werden (bis zu einem Limit von 65.536) und Skalierbarkeitsprobleme entstehen.

Problemumgehung

Als Problemumgehung können Sie die Regeln für die Label-Filterung auf das data.labels Feld in der Haupt cilium-config ConfigMap anwenden und sie aus cilium-config-emergency-override entfernen. Diese Situation bleibt bei Vorgängen auf der Steuerungsebene wie Upgrades bestehen, da GKE Nutzermodifikationen an Feldern beibehält, die nicht in der ConfigMap cilium-config verwaltet werden.

  1. Entfernen Sie den Schlüssel labels aus dem Abschnitt data der ConfigMap cilium-config-emergency-override, falls er vorhanden ist.

  2. Bearbeiten Sie die ConfigMap cilium-config, indem Sie den Schlüssel labels im Abschnitt data hinzufügen oder ändern. So verhindern Sie beispielsweise, 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

  3. Starten Sie den anet-operator auf der Steuerungsebene neu, indem Sie die Steuerungsebene auf dieselbe Version aktualisieren, auf der sie ausgeführt wird. Dadurch wird der Operator neu gestartet und seine Konfiguration neu geladen:

    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

  4. Starten Sie nach dem Neustart der Steuerungsebene das DaemonSet anetd 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 für maskierten Traffic oder bei der Verwendung von sitzungsspezifischen Ports auftreten. Diese Probleme sind auf potenzielle Portkonflikte mit dem reservierten NodePort-Bereich zurückzuführen und treten in der Regel in den folgenden Szenarien auf:

  • Benutzerdefinierter ip-masq-agent: Wenn Sie einen benutzerdefinierten ip-masq-agent (Version 2.10 oder höher) verwenden, für den 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 Standard Clustern 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. Um dieses Problem zu vermeiden, müssen Sie darauf achten, dass sich diese beiden Bereiche nicht überschneiden.

Prüfen Sie die 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 intermittierende Verbindungsprobleme auftreten, berücksichtigen Sie diese möglichen Ursachen und passen Sie die Konfiguration entsprechend an.

Verbindungsprobleme mit hostPort in GKE Dataplane V2-Clustern

Betroffene GKE-Versionen: 1.29 und höher

In Clustern, die GKE Dataplane V2 verwenden, können Verbindungsfehler auftreten, wenn Traffic auf die IP-Adresse eines Knotens mit dem Port ausgerichtet ist, wobei der Port der für den 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 einen bestimmten Knotenport und ein Passthrough-Network Load Balancer verteilt den Traffic auf alle Knoten. Wenn Sie Pods mit hostPort und einem Passthrough-Network Load Balancer im Internet bereitstellen, 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 Traffic von Passthrough-Network Load Balancern nicht konsistent an hostPort-Pods weitergeleitet wird.

    Problemumgehung:Wenn Sie hostPorts 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 dem reserviertenNodePort-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 wurde in Clusterversionen ab 1.29 beobachtet, da Cilium jetzt die 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 der direkten Kontrolle von GKE.

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

Portbereiche für Netzwerkrichtlinien werden nicht wirksam

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.

Mit der Kubernetes Network Policy API können Sie 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.

Feste Versionen

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

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 Verbindungstupel (Protokoll, Quell-/Ziel-IP und Quell-/Zielport) verloren gegangen ist, kann es bei neuen Verbindungen mit demselben Verbindungstupel zu Paketdrops bei den Rückgabepaketen kommen.

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 über einen Proxy-Load Balancer, wie Gateway, bereit, um den Dienst bereitzustellen. 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.

Upgrade der GKE-Steuerungsebene verursacht anetd-Pod-Deadlock

Wenn Sie ein Upgrade eines GKE-Cluster mit aktivierter GKE Dataplane V2 (erweiterter Datenpfad) von Version 1.27 auf 1.28 durchführen, kann es zu einem Deadlock kommen. Bei Arbeitslasten kann es zu Unterbrechungen kommen, da alte Pods nicht beendet oder erforderliche Komponenten wie anetd nicht geplant werden können.

Ursache

Beim Cluster-Upgrade steigen die Ressourcenanforderungen für die GKE Dataplane V2-Komponenten. Dieser Anstieg kann zu Ressourcenkonflikten führen, die die Kommunikation zwischen dem Cilium Container Network Interface (CNI)-Plug-in und dem Cilium-Daemon stören.

Symptome

Möglicherweise treten die folgenden Symptome auf:

  • anetd-Pods bleiben im Status Pending.
  • Arbeitslast-Pods bleiben im Status Terminating.
  • Fehler, die auf Kommunikationsfehler bei Cilium hinweisen, z. B. failed to connect to Cilium daemon.

  • Fehler bei der Bereinigung von Netzwerkressourcen für Pod-Sandboxes, z. B.:

    1rpc error: code = Unknown desc = failed to destroy network for sandbox "[sandbox_id]": plugin type="cilium-cni" failed (delete): unable to connect to Cilium daemon... connection refused

Problemumgehung

Standard-Cluster: Um das Problem zu beheben und den anetd Pod zu planen, erhöhen Sie vorübergehend die zuweisbaren Ressourcen auf dem betroffenen Knoten.

  1. Führen Sie den folgenden Befehl aus, um den betroffenen Knoten zu identifizieren und die zuweisbare CPU und den zuweisbaren Arbeitsspeicher zu prüfen:

    kubectl get nodes $NODE_NAME -o json | jq '.status.allocatable | {cpu, memory}'

  2. Führen Sie den folgenden Befehl aus, um die zuweisbare CPU und den zuweisbaren Arbeitsspeicher vorübergehend zu erhöhen:

    kubectl patch node $NODE_NAME -p '{"status":{"allocatable":{"cpu":CPU_VALUE, "memory":MEMORY_VALUE}}}'

Autopilot-Cluster: Um das Deadlock-Problem in Autopilot -Clustern zu beheben, geben Sie Ressourcen kostenlos, indem Sie den betroffenen Pod zwangsweise löschen:

kubectl delete pod POD_NAME -n NAMESPACE --grace-period=0 --force

Dabei gilt:

  • POD_NAME: der Name des Pods
  • NAMESPACE: der Namespace des Pods

Nachdem Sie die zuweisbaren Ressourcen auf dem Knoten erhöht haben und das Upgrade von GKE-Version 1.27 auf 1.28 abgeschlossen ist, wird der anetd-Pod in der neueren Version ausgeführt.

Knoten im Status NodeNotReady aufgrund des Fehlers „containerID fehlt“

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 GKE-Version 1.35.1-gke.1616000 verwenden GKE Dataplane V2-Cluster in ihren CNI-Konfigurationsdateien CNI-Version 1.1.0. Diese Änderung erfordert, dass auch nachgelagerte CNI-Plug-ins wie Google Managed Istio CNI-Version 1.1.0 unterstützen. Aufgrund einer Verzögerung bei der Einführung von Managed Istio haben einige Cluster die kompatible Version (1.23) noch nicht erhalten, was zu einem Fehler bei der Initialisierung 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 umgehen, führen Sie ein Downgrade des betroffenen Clusters auf eine GKE-Version vor 1.35.1-gke.1616000 durch.

Interferenz 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 Knotennetzwerkschnittstellen bereitstellen, können diese Programme mit von GKE verwalteten eBPF-Programmen in Konflikt geraten 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 von GKE Dataplane V2 anetd-Agent installierten Programme stören, was zu Problemen im Clusternetzwerk führen kann. Wir empfehlen, alle benutzerdefinierten eBPF-Programme oder Arbeitslasten zu entfernen, die solche Programme in Ihren Cluster einfügen.

Benutzerdefinierte eBPF-Programme ermitteln

Um benutzerdefinierte eBPF-Programme zu ermitteln, die auf Clusterknoten ausgeführt werden, können Sie ein DaemonSet mit der Einstellung hostNetwork: true erstellen, das 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

  1. Speichern Sie das Manifest als ebpf-discovery.yaml und wenden Sie das DaemonSet an:

    kubectl apply -f ebpf-discovery.yaml

  2. Warten Sie, bis die Pods ausgeführt werden:

    kubectl rollout status ds/bpftool-logger

  3. Prüfen Sie die Logs der Pods, um eBPF-Programme zu ermitteln:

    kubectl logs -l app=bpftool-logger

  4. Wenn Sie fertig sind, löschen Sie das DaemonSet:

    kubectl delete -f ebpf-discovery.yaml

Nächste Schritte