Cilium: eBPF-Netzwerk, Sicherheit und Observability für Kubernetes
eBPF-basiertes Netzwerk, Sicherheit und Beobachtbarkeit
Auf einen Blick
- Was ist das?
- Wie das CNCF-Projekt Cilium den Netzwerkpfad in eBPF verlagert, kube-proxy ersetzt und Richtlinien über Identitäten statt IP-Adressen durchsetzt, inklusive Release-Strategie und realer Grenzen.
- Für wen ist es gedacht?
- Cilium eignet sich für Teams, die Kubernetes-Netzwerk, Lastverteilung und Sicherheitsrichtlinien in einem eBPF-Dataplane zusammenführen wollen und Linux-Kernel-Voraussetzungen prüfen können. Weniger geeignet ist es, wenn ein Cluster auf alten Kernels läuft oder man eine CNI ohne Kernel-Abhängigkeit sucht.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Go, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Ciliums eBPF-Dataplane als Ersatz für kube-proxy
Cilium beschreibt sich als Networking-, Observability- und Security-Lösung mit einem eBPF-basierten Dataplane. Der Kern ist eine flache Layer-3-Netzwerkschicht, die mehrere Cluster überspannen kann, und zwar entweder im Native-Routing oder im Overlay-Modus. Das Projekt ist in Go geschrieben, steht unter Apache-2.0 und ist ein CNCF-Graduated-Projekt; das Repository verzeichnet rund 25.000 Sterne und knapp 4.000 Forks.
Die auffälligste Funktion ist laut README der vollständige Ersatz von kube-proxy: Cilium implementiert verteiltes Lastbalancieren für Pod-Verkehr und Verkehr zu externen Diensten mithilfe effizienter Hash-Tabellen im Linux-Kernel. Weil eBPF-Programme dynamisch an Integrationspunkten wie Netzwerk-IO, Applikations-Sockets und Tracepoints eingehängt werden, entfällt der klassische iptables-Pfad. Dazu kommen integrierte Ingress- und Egress-Gateways, Bandbreitenmanagement und ein Service-Mesh, das nicht auf Sidecar-Injection angewiesen ist.
Identitätsbasierte Richtlinien auf Layer 3 bis Layer 7
Das Sicherheitsmodell von Cilium koppelt Netzwerkrichtlinien von Adressierung ab. Statt Regeln an IP-Bereiche zu hängen, ordnet der Dataplane Workloads Identitäten zu und setzt Richtlinien auf den Layern 3 bis 7 durch. Ein Policy-Regelwerk kann also beispielsweise sprechenden HTTP-Pfad und Methode unterscheiden, ohne dass die dahinterliegenden Pod-IPs beim Neustart die Regelmeaning verschieben.
Für den Betrieb bedeutet das zwei Dinge. Erstens wandern Sicherheitsentscheidungen in den Kernel, was die Durchsetzung dort passiert, wo Pakete ohnehin verarbeitet werden. Zweitens ist L7-Awareness kein Nebenprodukt: Der Dataplane muss Protokollinformationen parsen, was zu mehr Rechenarbeit an heißen Pfaden führt. Das README nennt die Protokollerkennung als Bestandteil der Funktionalität, ohne Performance-Kennzahlen zu versprechen; konkrete Messungen zur eigenen Workload bleiben Betreibern nicht erspart.
Overlay mit VXLAN und Geneve oder natives Routing
Beim Netzwerkdesign lässt Cilium laut README zwei Hauptwege zu. Overlay-Netzwerk kapselt Pods-Verkehr in VXLAN oder Geneve ein und funktioniert auf fast jeder Infrastruktur, weil nur IP-Konnektivität zwischen den Hosts nötig ist. Der Native-Routing-Modus nutzt dagegen die reguläre Routing-Tabelle des Linux-Hosts; das Netz muss die Container-IPs routen können, zahlt dafür mit weniger Overhead.
Dazwischen stehen flexible Routing-Optionen: In gemeinsamen Layer-2-Domains kann Cilium die Nachbarerkennung automatisieren, über Layer-3-Grenzen hinweg kommt BGP zum Zug, und IPv6-native Infrastruktur wird direkt unterstützt. Wer in einer Cloud mit restriktiven Routern arbeitet, landet meist beim Overlay, wer eigene Router oder BGP-Sessions kontrolliert, kann den nativen Weg wählen. Diese Entscheidung beeinflusst MTU, Fehlerdiagnose und spätere Cluster-Erweiterungen und lässt sich nachträglich nur mit Migrationsaufwand ändern.
Release-Politik: Drei Minor-Versionen, danach EOL
Die Community pflegt laut README Minor-Stable-Releases nur für die letzten drei Minor-Versionen; ältere Zweige gelten als EOL. Zum Zeitpunkt der Datenlage sind das v1.20 mit dem Patch v1.20.1 vom 18. August 2026, v1.19 mit v1.19.7 und v1.18 mit v1.18.13. Die zugehörigen Images liegen unter quay.io/cilium/cilium, etwa das Tag v1.20.0 aus dem freigegebenen Zweig v1.20.
Für Upgrade-Planung heißt das: Ein Sprung über mehr als zwei Minor-Versionen führt durch offiziell nicht mehr unterstützte Zwischenstände. Das README verweist dafür auf den Cilium Upgrade Guide, der für neue Minor-Releases konsultiert werden soll. Wer auf bleeding-edge testet, findet tägliche CI-Images unter dem Tag quay.io/cilium/cilium-ci:latest sowie den Vorabstand v1.21.0-pre.0 vom 3. August 2026; beide Quellen sind laut README ausdrücklich nicht für Produktion gedacht.
SBOM-Pflicht seit 1.13.0 und Images für AMD64 und AArch64
Seit Version 1.13.0 enthalten laut README alle Cilium-Images eine Software Bill of Materials im SPDX-Format, dokumentiert unter docs.cilium.io im Abschnitt zur SBOM. Für Teams mit Compliance-Anforderungen ist das ein handfestes Unterscheidungsmerkmal gegenüber CNI-Anbietern ohne herstellbare Herkunftsnachweise, weil Komponentenlisten automatisiert ausgewertet werden können.
Die Architekturabdeckung beschränkt sich auf AMD64 und AArch64. Beide Plattformen decken die gängigen Cloud- und ARM-Server-Setups ab, aber exotischere Architekturen wie 32-Bit-ARM oder PowerPC bleiben außen vor. Wer Edge-Cluster auf solcher Hardware betreibt, muss über einen anderen CNI-Pfad nachdenken oder selbst bauen, was angesichts der Kernel-Abhängigkeiten von eBPF ohnehin eine gründliche Prüfung der Zielkernels erfordert.
Grenzen von Cilium v1.20.1 im Alltag
Das README nennt keine Kompatibilitätsmatrix zu Kernel-Versionen auf der Seite des Benutzers, obwohl eBPF-Funktionen streng von der Kernel-Version abhängen. Wer einen älteren LTS-Kernel betreibt, kann also nicht davon ausgehen, dass alle beschriebenen Features funktionieren; die Dokumentation muss diese Frage für die konkrete Version beantworten. Mit 1.085 offenen Issues bei 25.019 Sternen zeigt sich zudem ein Projekt in starker Bewegung, dessen Funktionsumfang sich zwischen Minor-Releases spürbar verschiebt.
Ein zweiter Punkt ist die Betriebskomplexität: Der Ersatz von kube-proxy greift tief in die Host-Netzwerkstacks ein, und die Diagnose verschiebt sich von iptables-Regeln auf eBPF-Maps und -Programme. Teams ohne Erfahrung mit bpftool oder den Cilium-CLI-Werkzeugen verlieren bei Problemen Zeit. Wer nur ein kleines Cluster mit simplen Policies betreibt, kann mit einer einfacheren CNI plus regulärem kube-proxy vermutlich schneller ans Ziel kommen; der Vorteil von Cilium wächst mit Clustergröße, Sicherheitstiefe und Observability-Bedarf.
Redaktionelles Fazit
Cilium eignet sich für Teams, die Kubernetes-Netzwerk, Lastverteilung und Sicherheitsrichtlinien in einem eBPF-Dataplane zusammenführen wollen und Linux-Kernel-Voraussetzungen prüfen können. Weniger geeignet ist es, wenn ein Cluster auf alten Kernels läuft oder man eine CNI ohne Kernel-Abhängigkeit sucht. Vor dem Produktivbetrieb sollte man die Kernel-Version, den gewählten Routing-Modus und die Release-Unterstützung der eingesetzten Minor-Version gegen die Cilium-Dokumentation verifizieren.
Community-Notizen