Das prägende Merkmal von Cilium ist nicht eine einzelne Funktion, sondern dass Netzwerk, Sicherheit und Observability als Programme direkt im Linux-Kernel über eBPF implementiert sind, statt über iptables-Regeln oder einen Sidecar-Proxy aufgesetzt zu werden. Diese Anleitung behandelt, was das in der Praxis bedeutet: was passiert, wenn ein Pod startet, wie eine Policy-Entscheidung zustande kommt und warum Ciliums Netzwerkpfad schneller ist als die Alternativen, die er ersetzt.

eBPF in einem Absatz

eBPF erlaubt es, kleine, zweckgebundene Programme zur Laufzeit in den Linux-Kernel zu laden, ohne ein Kernel-Modul zu schreiben oder den Kernel selbst zu patchen. Bevor ein solches Programm geladen werden darf, analysiert ein Verifier im Kernel es statisch: Er bestätigt, dass es terminiert (keine unbegrenzten Schleifen), innerhalb sicherer Speichergrenzen bleibt und den Kernel nicht zum Absturz oder Hängen bringen kann. Besteht ein Programm diese Prüfung nicht, wird es rundheraus abgelehnt. Genau das macht es sicher, Userspace-Werkzeuge beliebige Logik in den Kernel-Space laden zu lassen. Jedes eBPF-Programm wird frisch kompiliert und geladen und nicht als vorkompiliertes Kernel-Binary ausgeliefert.

Was passiert, wenn ein Pod startet

Der kubelet von Kubernetes bittet das konfigurierte CNI-Plugin, das Netzwerk für einen neuen Pod einzurichten. Mit Cilium als diesem CNI:

1. Cilium weist dem Pod einen Network Namespace und die übliche IP-Konfiguration zu – dieselbe Basisaufgabe, die jedes CNI erfüllt.
2. Cilium weist dem Pod eine Sicherheitsidentität zu, die sich aus seinen Kubernetes-Labels ableitet, nicht aus seiner IP-Adresse. Jeder Pod mit denselben relevanten Labels (typischerweise etwa den Selector-Labels seines Deployments) teilt dieselbe Identität. Das ist wichtig, weil Pod-IPs kurzlebig sind und ständig neu vergeben werden. Eine an Labels gebundene Identität bleibt über Neustarts und Umplanung hinweg stabil, wie es eine IP-Adresse nie könnte.
3. Cilium hängt ein eBPF-Programm an den Network Namespace des Pods. Ab diesem Moment sieht dieses Programm jedes Netzwerkereignis, das diesen Pod betrifft, und kann darauf reagieren: eine sich öffnende Verbindung, ein ankommendes Paket, eine Anfrage, die zu einem anderen Service oder in die Außenwelt geht.

Policy-Entscheidungen fallen pro Paket, nicht pro Sitzung

Traditionelle Firewalls implementieren häufig „allow established“: Sobald eine Verbindung erlaubt ist, passiert jedes weitere Paket darauf ohne erneute Prüfung, nur neue Verbindungen werden gegen die Policy geprüft. Ciliums eBPF-basierte Durchsetzung bewertet jedes einzelne Paket gegen die aktuelle Policy, nicht nur den Verbindungsaufbau.

Die praktische Folge: Wenn du eine Network Policy änderst, gilt die Änderung sofort für den gesamten Traffic, auch auf bereits offenen Verbindungen. Es gibt kein Zeitfenster, in dem eine bereits etablierte Sitzung unter veralteten Regeln weiterläuft, bis sie zufällig geschlossen und neu geöffnet wird.

Observability kommt kostenlos aus demselben Event-Strom

Dieselbe eBPF-Instrumentierung, die Policy-Entscheidungen trifft, erzeugt auch ein Event für jede beobachtete Netzwerkinteraktion: Verbindungsversuche, erlaubten und verweigerten Traffic, Anfragen an externe Ziele. So kann Cilium Traffic auch dem tatsächlichen Prozess zuordnen, der ihn erzeugt hat – nicht nur „dieser Pod hat mit jenem Pod gesprochen“, sondern welcher konkrete Prozess im Pod die Verbindung geöffnet hat. Dieses Detailniveau können Ansätze wie Deep Packet Inspection am Rand eines Sidecars im Nachhinein typischerweise nicht rekonstruieren. Dieser Event-Strom ist die Grundlage von Ciliums eigenem Observability-Werkzeug Hubble, das bei den Kernkonzepten auf der Landingpage dieser Technologie behandelt wird.

Load Balancing auf Socket-Ebene: das Umschreiben der Pakete überspringen

Einen Kubernetes-Service zu erreichen bedeutet traditionell, dass ein an die virtuelle IP des Services adressiertes Paket per NAT auf die IP eines tatsächlichen Backend-Pods umgeschrieben wird – ein Schritt, der historisch mit iptables- oder IPVS-Regeln umgesetzt wurde, die jedes Paket durchlaufen muss. Cilium führt diese Übersetzung stattdessen auf der Socket-Ebene zum Verbindungszeitpunkt durch, mit eBPF-Hooks an der Stelle, an der ein Prozess connect() aufruft oder Daten sendet. Die Verbindung der Anwendung wird von Anfang an direkt auf ein ausgewähltes Backend aufgebaut, statt dass jedes folgende Paket einzeln im Flug umgeschrieben wird. Das entfernt spürbar Overhead pro Paket, besonders bei durchsatzstarkem oder latenzempfindlichem Service-zu-Service-Traffic.

kube-proxy vollständig ersetzen

kube-proxy, in den Standard-Kubernetes-Binaries enthalten, implementiert standardmäßig mit iptables- oder IPVS-Regeln das Service-Routing (ClusterIP, NodePort und so weiter). Cilium kann kube-proxy komplett ersetzen und dieselbe Service-Routing-Logik stattdessen in eBPF umsetzen. Neben der reinen Performance ändert das eine betriebliche Eigenschaft, die man kennen sollte: Ein großes iptables-Regelwerk ist eine einzige, voneinander abhängige Struktur, und die Änderung einer Regel kann bedeuten, das gesamte Regelwerk neu zu laden. Ciliums eBPF-basierte Regeln sind eher unabhängige, atomare Einträge, sodass die Änderung eines Eintrags nicht erfordert, den Rest anzufassen.

Warum das über „es ist schnell“ hinaus zählt

Performance ist die Schlagzeile, aber der tiefere Punkt ist architektonisch: Weil Cilium auf Kernel-Ebene arbeitet und nicht über einen Stapel von iptables-Regeln oder einen Sidecar pro Pod, speisen sich Netzwerk, Sicherheits-Policy, Load Balancing und Observability aus demselben zugrunde liegenden Event-Strom und demselben Durchsetzungspunkt im Kernel, statt vier getrennter Systeme zu sein, die jeweils konfiguriert, synchron gehalten und darauf vertraut werden müssen, miteinander übereinzustimmen. Der Rest dieser Reihe baut darauf auf: Cluster-Einrichtung, Gateway API, das Schreiben von Network Policies und BGP-Route-Ankündigung.