▸ saaro:~/blog ▊ Notizen & Artikel EN
← zurück

📷 "Cloud Computing - Abstract 2" by perspec_photo88 is licensed under CC BY-SA 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by-sa/2.0/.

eBPF in Kubernetes 2026: Vom Kernel-Feature zur Standard-Infrastruktur

14. September 2026 · 4 min · Martin Jochum #Kubernetes#DevOps#eBPF#Cilium#Observability#Security#Cloud Native

eBPF hat sich in den letzten Jahren von einem exotischen Kernel-Feature zur zentralen Infrastruktur-Technologie für Cloud-Native-Umgebungen entwickelt. Laut der CNCF Annual Cloud Native Survey 2026 setzen bereits 67 Prozent der Kubernetes-Teams im Produktionseinsatz mindestens ein eBPF-basiertes Tool ein. Gleichzeitig wurde Cilium – der bekannteste eBPF-basierte Container Network Interface (CNI) – zum Standard-Netzwerk-Plugin für die drei großen Managed-Kubernetes-Dienste GKE, EKS und AKS. Doch was steckt hinter dieser Entwicklung, und warum sollten DevOps-Teams jetzt auf eBPF setzen?

Was eBPF eigentlich ist

eBPF (Extended Berkeley Packet Filter) ist eine virtuelle Maschine im Linux-Kernel, die es erlaubt, sandboxed Programme direkt im Kernel auszuführen – ohne Kernel-Module schreiben oder den Kernel-Quellcode ändern zu müssen. Die Besonderheit: Ein Kernel-Verifier prüft jedes eBPF-Programm vor der Ausführung auf Sicherheit und Korrektheit. Nur Programme, die garantiert nicht abstürzen oder in Endlosschleifen laufen, werden per JIT-Compiler in nativen Maschinencode übersetzt und ausgeführt.

Die Kommunikation zwischen eBPF-Programmen im Kernel und Userspace-Tools erfolgt über sogenannte BPF-Maps – Shared-Memory-Strukturen, die beide Seiten gleichzeitig lesen und beschreiben können. Dieses Architekturmuster ermöglicht Beobachtbarkeit und Steuerung des Kernels mit nahezu null Overhead.

Cilium: Der erfolgreichste eBPF-Use-Case

Das bekannteste eBPF-Projekt ist Cilium, das als CNI für Kubernetes fungiert und mittlerweile in GKE, EKS und AKS als Standard-Option oder sogar als Default ausgeliefert wird. Cilium ersetzt kube-proxy durch eBPF-basierte Paketverarbeitung und erreicht damit bei tausenden Services eine bis zu 100-fach höhere Performance als iptables – weil BPF-Maps auf Hash-Tabellen (O(1)) setzen, während iptables lineare Regel-Durchläufe verwendet.

Doch Cilium kann weit mehr als reine Paketvermittlung:

Hubble ist die integrierte Netzwerk-Observability-Schicht von Cilium. Sie zeigt in Echtzeit, welcher Traffic zwischen welchen Pods fließt – ohne dass Anwendungen instrumentiert werden müssen. Ein hubble observe --namespace production genügt, um Verbindungen, Latenzen und verworfene Pakete (Policy-Verstöße) zu sehen.

CiliumNetworkPolicy erweitert die standardmäßigen Kubernetes NetworkPolicies um Layer-7-Regeln. Statt nur IP/Port-basierter Zugriffskontrolle lassen sich HTTP-Methoden, Pfade und sogar Header in YAML spezifizieren:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-http-policy
spec:
  endpointSelector:
    matchLabels:
      app: backend-api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: GET
          path: "/api/.*"

Sidecar-loses Service Mesh mit Cilium 1.19

Auf der KubeCon EU 2026 in Amsterdam präsentierte das Cilium-Team Version 1.19 mit nativer mTLS-Unterstützung – ohne Sidecar-Container. Die Architektur ist revolutionär: Statt pro Pod einen Envoy-Proxy (~50–100 MB RAM) zu injecten, läuft ein eBPF-Programm pro Node, das Routing, mTLS und Observability für alle Pods auf diesem Node übernimmt. Für Layer-7-Features kommt ein einziger Envoy pro Node zum Einsatz – nicht einer pro Pod.

Die Einsparung ist enorm: Bei 1.000 Pods bedeuten 100 MB Sidecar-Overhead pro Pod insgesamt 100 GB RAM, die ausschließlich für Proxy-Infrastruktur reserviert sind – ohne einen Beitrag zur Anwendungsfunktionalität zu leisten. Ciliums eBPF-natives mTLS eliminiert diesen Overhead komplett.

Zero-Instrumentation Observability mit OpenTelemetry eBPF

Ein weiterer Meilenstein der KubeCon EU 2026 war die Beta-Veröffentlichung von OpenTelemetry eBPF Instrumentation (OBI) durch Splunk. OBI erfasst Telemetriedaten direkt aus dem Linux-Kernel – ohne Code-Änderungen, ohne Service-Neustarts, ohne Sidecar-Agenten. Das ist besonders wertvoll für Legacy-Anwendungen, Go-Binaries, Rust-Services oder C+±Codebasen, bei denen Source-Code-Modifikationen langwierig oder unmöglich sind.

OBI integriert sich mit bestehenden OpenTelemetry-SDKs und füllt Beobachtbarkeitslücken, ohne Daten von bereits instrumentierten Diensten zu duplizieren. In der Evaluationsphase decken Teams typischerweise 15 bis 40 Prozent des Cluster-Traffics auf, der zuvor für verteiltes Tracing unsichtbar war.

Runtime Security mit Tetragon

Tetragon – ebenfalls aus dem Cilium-Ökosystem – geht einen Schritt weiter: Es kann Sicherheitsrichtlinien nicht nur erkennen, sondern direkt im Kernel durchsetzen. Ein TracingPolicy kann beispielsweise die Ausführung von /bin/bash oder /bin/sh in Pods ohne CAP_SYS_ADMIN erkennen und den Prozess per Sigkill beenden – in Echtzeit, auf Kernel-Ebene.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: detect-privilege-escalation
spec:
  kprobes:
  - call: "security_bprm_check"
    args:
    - index: 0
      type: "linux_binprm"
    selectors:
    - matchBinaries:
      - operator: "In"
        values:
        - "/usr/bin/sudo"
        - "/bin/su"
      matchActions:
      - action: Sigkill
      - action: Post
        rateLimit: "1m"

Der eBPF-Stack 2026

Für einen Produktions-Cluster im Jahr 2026 sieht der empfohlene eBPF-Stack wie folgt aus:

Ebene Tool
CNI + Service Mesh Cilium
Netzwerk-Observability Hubble
App-Observability (automatisch) Pixie oder Grafana Beyla
Runtime Security Tetragon
Custom Traces OpenTelemetry (via OBI)

Fazit

eBPF hat den Weg vom Nischen-Kernel-Thema zur essenziellen Infrastruktur-Technologie geschafft. Wer heute Kubernetes betreibt, kommt an eBPF nicht mehr vorbei. Die Vorteile liegen auf der Hand: geringere Latenz als iptables, keine Sidecar-Overheads, Beobachtbarkeit ohne Code-Änderungen und Sicherheitsdurchsetzung auf Kernel-Ebene.

Die KubeCon EU 2026 hat gezeigt, dass die Technologie den Enterprise-Tipping-Point erreicht hat. Cilium ist bei allen großen Cloud-Anbietern als CNI verfügbar, OpenTelemetry eBPF Instrumentation befindet sich in der Beta-Phase und Unternehmen wie Splunk bieten kommerziellen Support. Für DevOps-Teams bedeutet das: Jetzt ist der Zeitpunkt, den eBPF-Stack zu evaluieren und in die eigene Kubernetes-Strategie zu integrieren.

Quellen

🤖 Dieser Beitrag wurde KI-gestützt erstellt und redaktionell geprüft.