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

📷 "Cloud Computing" by Kevin Krejci is licensed under CC BY 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by/2.0/.

Cilium und eBPF 2026: Wie der Linux-Kernel das Kubernetes-Networking revolutioniert

23. August 2026 · 5 min · Martin Jochum #Kubernetes#Cilium#eBPF#Networking#Service Mesh#Hubble#Tetragon

Im Jahr 2026 hat sich die Netzwerkarchitektur in Kubernetes grundlegend gewandelt. eBPF (extended Berkeley Packet Filter) ist von einer Nischentechnologie zum Fundament moderner Cloud-native-Infrastruktur geworden. Cilium, das eBPF-native Container Network Interface (CNI), hat sich dabei als De-facto-Standard etabliert – sowohl Google Cloud (GKE Dataplane V2) als auch Microsoft Azure (Azure CNI Powered by Cilium) setzen es mittlerweile als empfohlenen Networking-Stack ein. Laut der CNCF Observability TAG Survey 2026 haben 67 % der Teams, die Kubernetes in großem Maßstab betreiben, mindestens ein eBPF-basiertes Observability-Tool in der Produktion im Einsatz.

eBPF: Das Betriebssystem im Kernel

eBPF ist eine virtuelle Maschine im Linux-Kernel, die es erlaubt, kleine, geprüfte Programme an Kernel-Hooks zu hängen – ohne Kernel-Module laden oder Quellcode ändern zu müssen. Die Programme werden in C, Rust oder Go geschrieben, zu eBPF-Bytecode kompiliert, vom Kernel auf Sicherheit geprüft (keine Endlosschleifen, keine Kernel-Abstürze) und dann per JIT in nativen Maschinencode übersetzt.

Diese Programme können an zahlreichen Hook-Punkten andocken: Netzwerk-Packets (ingress/egress), System Calls (vor und nach jedem Syscall), Kernel-Funktionen via kprobes, User-Space-Funktionen via uprobes sowie stabilen Tracepoints. Der entscheidende Vorteil: eBPF-Programme laufen direkt im Kernel und sehen alles – jeden Netzwerk-Packet, jeden Syscall, jede Funktion – ohne dass Anwendungen instrumentiert oder Sidecar-Proxies injiziert werden müssen. Eine einzige eBPF-Implementierung pro Knoten sammelt Telemetrie für alle Pods auf diesem Knoten, unabhängig von der Programmiersprache. Beyla (Grafana Labs) etwa nutzt eBPF-uprobes, um HTTP/2- und gRPC-Handling in Go, Java, Python, Node.js und Rust automatisch zu tracen – ohne eine einzige Codezeile zu ändern.

Cilium: Der eBPF-native Networking-Stack

Cilium nutzt eBPF, um das traditionelle kube-proxy/iptables-Modell abzulösen. Das Problem von iptables: Es arbeitet sequentiell – jedes Packet durchläuft sämtliche Regeln. In einem großen Cluster mit Tausenden Services und Zehntausenden Endpoints wachsen die iptables-Tabellen auf Hunderttausende von Regeln an, und die Latenz steigt proportional. Cilium setzt dagegen auf O(1)-Hash-Lookups über den eBPF-Datapfad.

Benchmarks aus dem Jahr 2026 zeigen, dass Cilium die iptables-Durchsatzleistung um den Faktor 6 übertrifft. Hinzu kommt, dass eBPF-Programme atomar aktualisiert werden können. Cilium kann Routing-Regeln clusterweit in Millisekunden ändern – ohne Paketverlust während der Transition. Das ist ein operativer Quantensprung gegenüber iptables, wo Regel-Flushes kurzzeitige Inkonsistenzen verursachen. Cilium 1.17+ bietet zudem native Gateway-API-Unterstützung (v1.3.0+) mit L7-Load-Balancing über einen integrierten Envoy-Proxy.

Von der CNI zum vollständigen Plattform-Stack

Was Cilium 2026 besonders macht, ist die Kombination mehrerer Funktionen in einem einheitlichen Stack:

  • CNI: Pod-Networking über den eBPF-Datapfad
  • Service Mesh: L7-Routing und mTLS (SPIFFE-basiert) ohne Sidecar-Proxies
  • Network Policy: L3/L4/L7-Sicherheitsregeln, direkt im Kernel durchgesetzt – zum Beispiel, dass nur bestimmte HTTP-Methoden und Pfade erlaubt sind
  • Observability: Hubble bietet Flow-Visibility, Service Maps und Metriken ohne Code-Änderungen
  • Gateway API: Native Unterstützung für das neue Kubernetes-Gateway-API (v1.3.0+) inklusive Traffic-Splitting und Header-basiertem Routing
  • Multi-Cluster: ClusterMesh ermöglicht serviceübergreifende Kommunikation und Discovery zwischen Clustern

Statt CNI + Service Mesh + Ingress Controller + Observability-Tool separat zu betreiben und zu warten, genügt eine Cilium-Installation. Das reduziert die operative Komplexität erheblich.

Hubble und Tetragon: Observability und Security aus dem Kernel

Hubble, die Observability-Komponente von Cilium, erzeugt automatisch eine Service Map des gesamten Cluster-Traffics – ohne Instrumentierung der Anwendungen. HTTP-Requests, gRPC-Calls, DNS-Auflösungen und Datenbankverbindungen werden automatisch erfasst, und das Hubble UI visualisiert sie in Echtzeit. Auf dem KubeCon EU 2026 wurde zudem die OpenTelemetry eBPF Instrumentation (OBI) angekündigt, die Beyla (Grafana Labs) als zero-code-observability-Lösung in das OpenTelemetry-Projekt überführt – ein wichtiger Schritt zur Standardisierung.

Tetragon, ein weiteres Cilium-Subprojekt, geht über reine Beobachtung hinaus: Es kann Security-Policies direkt im Kernel durchsetzen und schädliche Syscalls blockieren, bevor sie ausgeführt werden. Ein TracingPolicy kann etwa den Zugriff auf /etc/shadow oder Privilege-Escalation-Versuche in Containern erkennen und den Prozess per SIGKILL beenden – auf Kernel-Ebene, am Hook security_bprm_check, noch bevor der Syscall ausgeführt wird. Das ist ein entscheidender Sicherheitsgewinn gegenüber user-space-basierten Tools wie herkömmlichen Antivirenlösungen, die ein kompromittiertes System umgehen kann.

Cilium Mesh vs. Istio Ambient: Die Sidecar-Ära endet

Die Service-Mesh-Landschaft hat sich 2026 fundamental verändert. Der Sidecar-Proxy als Standardmodell gilt als überholt – 50–100 MB RAM pro Pod und 15–25 % CPU-Aufschlag sind bei tausenden Pods nicht mehr tragbar. Auf teuren GPU-Inferenz-Knoten ist jeder für einen Sidecar verschwendete Megabyte zu viel.

Sowohl Cilium Mesh (eBPF-basiert, kein User-Space-Proxy) als auch Istio Ambient (ztunnel-DaemonSet + optionale Waypoint-Proxies) bieten sidecar-lose Alternativen. Die Performance-Unterschiede sind messbar: Cilium addiert nur ca. 2 % Latenzaufschlag und ~100 MB pro Knoten, während Istio Ambient bei ~5 % und ~50 MB pro Knoten liegt. Beide sind dem klassischen Sidecar-Modell (15 % Aufschlag) deutlich überlegen. Cilium eignet sich besonders, wenn Performance und ein einheitlicher Stack im Vordergrund stehen; Istio Ambient ist die bessere Wahl, wenn umfangreiches L7-Traffic-Management (Canary-Deployments, Fault-Injection, Circuit-Breaking) benötigt wird.

Fazit

eBPF und Cilium haben sich 2026 als Rückgrat des modernen Kubernetes-Networking etabliert. Die Technologie vereint Networking, Sicherheit und Observability in einem Kernel-nativen Stack, der ohne Sidecars, ohne Code-Instrumentierung und ohne Kompromisse bei der Performance auskommt. Für DevOps-Teams, die neue Kubernetes-Cluster aufsetzen, ist Cilium inzwischen die erste Wahl – und die großen Cloud-Anbieter haben diesen Trend bereits bestätigt. Der nächste Schritt ist bereits in Sicht: KI-gestützte Bedrohungserkennung auf Basis von Hubble-Flow-Daten sowie das neue tetragon-python-SDK, das das Schreiben von eBPF-Sicherheits-Policies in Python ermöglicht. Beides ist für die zweite Jahreshälfte 2026 angekündigt und wird die Zugangshürde zu Kernel-nativer Sicherheit weiter senken.

Quellen

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