Cilium 2026: eBPF-basiertes Networking als neuer Kubernetes-Standard

📷 "Cool Reflecting Source Code Screen at GGJ Berlin 2015" by qubodup is licensed under CC BY 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by/2.0/.

Cilium hat sich 2026 leise, aber deutlich vom spezialisierten CNI-Plugin zum zentralen Netzwerk-Backbone für Kubernetes entwickelt. Google Cloud setzt Cilium als Standard-CNI in GKE Autopilot ein, Microsoft Azure bietet es als bevorzugte Advanced-Networking-Option in AKS, und auch Amazon EKS empfiehlt Cilium für anspruchsvolle Szenarien. Was steckt hinter diesem Aufstieg – und warum sollten Plattformteams jetzt ein besonderes Auge auf eBPF-basiertes Networking werfen?

eBPF: Die technische Grundlage

Cilium basiert auf eBPF (Extended Berkeley Packet Filter), einer Technologie, die es erlaubt, kleine Programme in den Linux-Kernel zu laden und dort auszuführen. Anders als klassische CNIs, die auf iptables-Ketten setzen – die mit jeder hinzukommenden Service-Regel linear wachsen und bei tausenden von Regeln zu messbaren Latenzspitzen führen – nutzt Cilium eBPF-Maps für konstante Lookup-Zeit (O(1)). Das macht die Netzwerk-Performance unabhängig von der Cluster-Größe. Benchmarks aus dem Jahr 2026 zeigen: Cilium erreicht in Pod-to-Service-Szenarien bis zu 28,5 Gbit/s Durchsatz und eine P99-Latenz von nur 0,8 ms – bei halbem CPU-Verbrauch im Vergleich zu iptables-basierten Alternativen.

Der Haken: Das Kernel-Requirement liegt bei Linux 5.4+, für Produktionsumgebungen wird 5.15+ empfohlen. Wer ältere Knoten betreibt, bleibt vorerst auf Calico oder Flannel angewiesen.

L7-Policies ohne Sidecar

Der entscheidende Mehrwert von Cilium gegenüber Calico oder Flannel liegt in der nativen Layer-7-Inspektion. Wo eine klassische Kubernetes-NetworkPolicy nur „TCP-Port 8080 erlauben" kann, unterscheidet Cilium auf HTTP-Pfad-Ebene: GET /products wird durchgelassen, DELETE /admin blockiert – und zwar kernel-nah, ohne dass ein Envoy-Sidecar pro Pod mitläuft.

Die Konfiguration erfolgt über CiliumNetworkPolicy-Ressourcen im nativen Kubernetes-Manifest-Format:

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

Für Compliance-Anforderungen nach SOC 2 oder ISO 27001 lassen sich diese Regeln als testbare Artefakte direkt in der CI/CD-Pipeline prüfen – ein massiver Fortschritt gegenüber nachträglich geflickten Firewall-Regeln.

Hubble: Observability aus dem Kernel

Hubble, Ciliums integrierte Observability-Schicht, zapft dieselben eBPF-Hooks an, die auch für die Policy-Durchsetzung verwendet werden. Das Ergebnis: vollständige Transparenz über alle Netzwerkflüsse hinweg – ohne Agents, ohne Sidecars, ohne Sampling. Jede Verbindung wird mit Quell- und Ziel-Pod, Protokoll, Verdict und Byte-Zähler protokolliert. Für den Incident-Fall bedeutet das: Statt sich durch inkonsistente Application-Logs von zwanzig Microservices zu wühlen, filtert ein hubble observe --verdict DROPPED direkt die abgewiesenen Verbindungen heraus.

Hubble-Integrationen in Prometheus und Grafana sind über den nativen OpenMetrics-Endpoint abgedeckt, sodass bestehende Monitoring-Stacks erweitert werden können.

Cilium vs. Calico vs. Istio: Die Entscheidungsmatrix 2026

Nach aktuellem Stand 2026 gilt: Wer einen neuen Cluster aufsetzt, sollte Cilium als Default-CNI wählen. Calico bleibt die richtige Wahl für Umgebungen mit älteren Kernels oder BGP-Anforderungen im Bare-Metal-Betrieb. Istio wiederum sollte nur dort zum Einsatz kommen, wo wirklich komplexes Traffic-Management (Canary-Deployments, dynamisches Mirroring) benötigt wird – viele Organisationen laufen heute mit Cilium für die Basis-Netzwerkebene und legen Istio nur dort obendrauf, wo es den Aufwand rechtfertigt.

Fazit

Cilium ist 2026 mehr als ein CNI-Plugin. Es ist eine Plattform für Networking, Sicherheit und Observability aus einem Guss – betrieben auf Kernel-Ebene, ohne Sidecar-Overhead. Die Adoption durch die großen Cloud-Provider (GKE, EKS, AKS) zeigt, dass eBPF-basiertes Networking kein Nischenthema mehr ist, sondern zum neuen Standard wird. Plattformteams, die noch auf Calico oder gar Flannel setzen, sollten eine Migrationsstrategie entwickeln – der Wechsel zu Cilium ist über die offizielle Helm-Chart-Dokumentation gut dokumentiert und über einen Node-by-Node-Prozess ohne Produktionsausfall möglich. Die Lernkurve ist real, aber der Gewinn an Performance, Sicherheit und Transparenz überwiegt deutlich.