Zustellung mit Durchblick

von Dr. Matthias Wübbeling

Dank vielfältiger Orchestrierungstools steht ein Kubernetes-Cluster heute in kürzester Zeit. Für den sicheren und kontrollierten Betrieb braucht es jedoch mehr als das reine Aufsetzen. Cilium richtet auf Basis der eBPF-Schnittstellen im Linux-Kernel das Netzwerk Ihres Clusters dynamisch anhand konkreter Policys und Service-Tags aus – statt es starr an Pod-IPs festzumachen. Dieser Artikel stellt Ihnen eBPF und Cilium vor und zeigt erste Schritte bei Konfiguration und Trafficmonitoring mit Hubble.

Für den Betrieb eines eigenen Kubernetes-Clusters gibt es viele gute Gründe. Häufig startet dieser Betrieb mit einer kleinen Instanz, die kontinuierlich wächst. Spätestens jedoch, wenn Kollegen den Vorteil eines lokalen Betriebs erkennen. Auch die begleitende Konfiguration des Clusters ist anfangs oft auf "klein" ausgelegt: Ein einfaches Netzwerk-Overlay wie Flannel oder Weave Net lässt sich schnell aufsetzen und leicht administrieren – zumindest solange der Cluster überschaubar bleibt.

Wer schon einmal versucht hat, einen Netzwerkfehler in einem stetig wachsenden Kubernetes-Cluster nachzuvollziehen, kennt die Reise durch iptables, Conntrack und Servicer-Regeln bereits und damit auch das beschriebene Problem. Irgendwo zwischen Pod, Service, Node- Port, NAT-Regel und Loadbalancer verliert sich ein Paket, eine Regel schreibt es um, oder es erreicht schlicht nicht das erwartete Ziel. Auf dem Papier lässt sich der Ablauf noch erklären. Im Alltag wächst die Komplexität jedoch schneller als die Übersicht.

Kubernetes ist ein hochdynamisches System: Pods entstehen und verschwinden mitunter im Sekundentakt, Deployments skalieren automatisch, Services zeigen auf wechselnde Endpoints, und IP-Adressen liefern eher Momentaufnahmen als belastbare Identitäten. Genau hier stoßen klassische Netzwerk- und Sicherheitsmodelle an ihre Grenzen. Zwar liegt es nahe, Policys, Weiterleitungen und Fehleranalysen vor allem an IP-Adressen und langen Regelketten festzumachen – wer ehrlich ist, verwaltet damit im Zweifel jedoch nicht den gewünschten Zustand, sondern dessen sich ständig ändernde technische Ableitung.

iptables hat sich für Docker und Kubernetes über Jahre bewährt und ist vielen Admins vertraut. In großen Clustern wird die Regelbasis jedoch schnell unübersichtlich, schwer prüfbar und mühsam zu debuggen. Jede neue Anwendung, jeder zusätzliche Service und jede Skalierungsbewegung erzeugt weitere Einträge, Sprünge und Zustände. Im Fehlerfall müssen Sie dann nicht nur nachvollziehen, was Kubernetes eigentlich beabsichtigt hat, sondern auch, wie der jeweilige Node diese Absicht gerade in Paketfilterregeln, NAT-Tabellen und Verbindungszustände übersetzt.

Mit Cilium [1] existiert bereits seit einiger Zeit ein Network-Overlay, das genau an dieser Stelle ansetzt. Es verspricht nicht einfach nur mehr Performance durch eBPF (extended Berkeley Packet Filter) [2], sondern ein völlig anderes Betriebsmodell für Kubernetes-Netzwerke: einen programmierbaren Kernel-Datapath, identitätsbasierte Sicherheitsrichtlinien und eingebaute Observability. Statt Netzwerkentscheidungen ausschließlich über die flüchtige IP-Logik der Container und verschachtelte Regelketten zu treffen, behandelt Cilium Workloads anhand ihrer Identität, ihrer Labels und ihrer Kommunikationsbeziehungen.

Für Sie als Admin bedeutet das einen schnelleren Paketpfad auf der einen und eine bessere Grundlage für Kontrolle, Fehlersuche und die Durchsetzung von Sicherheitsrichtlinien auf der anderen Seite. Dabei geht es nicht um die Frage, ob iptables schlecht ist – das ist es nämlich nicht –, sondern vor allem darum, ob iptables in modernen, hochdynamischen Kubernetes-Umgebungen noch das beste Werkzeug ist, um den Netzwerkverkehr transparent, sicher und nachvollziehbar zu steuern.

Vom einfachen Paketfilter zur Kernelplattform

Um den Vorteil zu verstehen, den eBPF in Form von Cilium für Ihr Kubernetes-Netzwerk bringen kann, lohnt sich zunächst ein Blick auf BPF und eBPF selbst. BPF gehört bereits seit den 1990er-Jahren zum Linux-Kernel und erlaubt es, kleine, geprüfte Programme an definierten Stellen im Kernel auszuführen.

Die klassische Variante von BPF diente vor allem dazu, Netzwerkpakete effizient zu filtern, etwa bei Werkzeugen wie tcpdump. Statt jedes Paket vollständig in den Userspace zu kopieren und erst dort über dessen Relevanz zu entscheiden, traf der Kernel diese Entscheidung bereits früh anhand eines kleinen Filterprogramms und leitete das Paket weiter oder verwarf es. Der Vorteil lag auf der Hand: weniger Kopieraufwand, weniger Kontextwechsel, weniger Last für das System.

eBPF erweitert diese Idee deutlich. Aus dem einfachen Paketfilter entwickelte sich eine allgemeine Ausführungsumgebung im Linux-Kernel. eBPF-Programme können heute nicht nur Pakete filtern, sondern auch Netzwerkverkehr steuern, Systemaufrufe beobachten, Performancedaten sammeln, Sicherheitsentscheidungen unterstützen oder Events an Userspace-Werkzeuge weitergeben. Für das Netzwerk eines Kubernetes-Clusters ist vor allem relevant, dass eBPF an definierten Stellen im Netzwerkpfad läuft und dort sehr früh, sehr schnell und mit Kernelkontext über Pakete entscheiden kann.

Natürlich ist eBPF keine freie und unkontrollierte Spielwiese für beliebigen Kernelcode. Ein Entwickler erstellt ein eBPF-Programm im Userspace, kompiliert es beispielsweise aus C-Code mit LLVM/Clang und lädt es anschließend als eBPF-Bytecode in den Kernel. Der Kernel nimmt dieses Programm jedoch nicht blind entgegen: Zuerst prüft der eBPF-Verifier, ob es sich sicher ausführen lässt. Er kontrolliert unter anderem Speicherzugriffe, Sprünge, das Laufzeitverhalten und die Frage, ob das Programm garantiert terminiert. Erst nach erfolgreicher Prüfung darf der Kernel das Programm laden.

Danach hängt der Kernel das Programm an einen sogenannten Hook, einen festgelegten Einstiegspunkt im Kernel. Im Netzwerkbereich kommen dafür etwa XDP-Hooks infrage, die sehr früh am Netzwerktreiber ansetzen, Traffic-Control-Hooks für die Wahl des Interfaces sowie für Um- und Weiterleitung des Datenverkehrs, oder Socket-bezogene Hooks auf dem Weg über ein konkretes Interface. Der Hook bestimmt zugleich, wann der Kernel das Programm ausführt: Ein XDP-Programm ("eXpress Data Path") sieht Pakete bereits sehr früh, noch bevor der reguläre Netzwerkstack sie vollständig verarbeitet, während ein TC-Programm etwas später im Pfad greift, etwa beim Routing zu einem Interface.

Zur Architektur gehören darüber hinaus sogenannte Maps, der zweite zentrale Baustein neben den Programmen selbst. Ein eBPF-Programm legt seinen veränderlichen Zustand nicht einfach in beliebigem Kernelspeicher ab, sondern in solchen Maps. Der Kernel verwaltet diese Maps als eigene Datenstrukturen, etwa als Hashmaps, Arrays, LPM-Tries, LRU-Maps, Per-CPU-Maps oder Program-Arrays. Über sie tauschen die eBPF-Programme Daten mit Userspace-Prozessen aus: Das Programm liefert die Logik, die Map hält den aktuellen Zustand.

Neben den Netzwerk-Hooks bietet der Linux-Kernel noch viele weitere Möglichkeiten, Daten direkt an den Userspace zu leiten. Der auf Performanceoptimierung spezialisierte Entwickler und Autor Brendan Gregg [3] hat diese Möglichkeiten in seinem Buch "BPF Performance Tools" übersichtlich dargestellt, die Übersicht sehen Sie in Bild 1. Gregg arbeitet derzeit an der Kosten- und Performanceoptimierung von ChatGPT bei OpenAI.

Blick unter die Haube: eBPF im Kernel

Um sich ein Bild davon zu machen, wie eBPF in Ihrem Linux-Kernel arbeitet, werfen Sie am besten selbst einen Blick auf die Liste der aktuell laufenden Programme. Führen Sie dazu als root folgendes Kommando aus:

Sie erhalten daraufhin eine Übersicht der geladenen Programme, wie Bild 2 zeigt. Der Ausschnitt liefert die Daten eines geladenen Programms, in diesem Fall eines Traffic-Control-Programms. Mit

rufen Sie weitere Informationen zu diesem Programm ab.

Diese Einträge zeigen zunächst nur, dass auf diesem Node ein Cilium-eBPF-Programm im Traffic-Control-Pfad des Kernels läuft. Der Name "cil_from_netdev" deutet darauf hin, dass es Traffic verarbeitet, der direkt von einem Netzwerkgerät in den Cilium-Datapath gelangt. Der Typ "sched_cls" zeigt, dass das Programm an einem TC-Hook hängt, und der Wert "jited: true" verrät, dass der Kernel den geprüften eBPF-Bytecode mit dem Just-in-Time-Compiler in nativen Maschinencode übersetzt hat. Die map_ids verraten, welche Kernel-Datenstrukturen das Programm für seine Entscheidungen heranzieht. Weitere Details zu den einzelnen Maps liefert in diesem Fall:

Gegebenenfalls müssen Sie das bpftool zunächst passend für Ihre Linux-Distribution installieren.

Zurück zum praktischen Einsatz von eBPF mit Cilium: Der Cilium-Agent läuft im Userspace auf jedem Node des Kubernetes-Clusters und beobachtet dort die relevanten Objekte wie Pods, Services, Endpoints und Policys. Aus diesen Informationen lädt oder aktualisiert er die eBPF-Programme und schreibt die entsprechenden Zustände in eBPF-Maps. Der Kernel muss bei einem Paket also nicht erst bei Kubernetes nachfragen, sondern führt direkt das geladene eBPF-Programm aus, das wiederum in den passenden Maps nachschaut. Dort findet er neben vielen weiteren Informationen, welche Service-IP das Paket adressiert, welche Backends dazugehören und ob eine passende Policy existiert. Auch die Identität der Quell-IP eines Datenpakets hält diese Struktur bereit.

Identitäten statt IP-Adressen

In klassischen Netzwerkumgebungen denken viele Sicherheitskonzepte in IP-Adressen, vor allem entlang der Frage, welche Adresse mit welcher anderen Adresse oder auf welchem Port kommunizieren darf und welche nicht. Selbst in statischen Netzen wird diese Betrachtung mitunter unübersichtlich, bleibt aber grundsätzlich nachvollziehbar. In Kubernetes überholt die Dynamik dieses Modell jedoch schnell: Pods sind kurzlebig, starten neu, wandern zwischen Nodes oder skalieren automatisch. Eine Pod-IP beschreibt deshalb selten eine stabile Sicherheitsidentität. Sie zeigt eigentlich nur noch, wo ein Workload in diesem Moment erreichbar ist.

Statt Sicherheitsregeln primär an flüchtige IP-Adressen zu binden, nutzt Cilium gezielt Kubernetes-Labels und die daraus abgeleiteten Workload-Identitäten. Ein Pod verdient Ihr Vertrauen nicht deshalb, weil er zufällig die IP 10.42.3.17 trägt, sondern weil er etwa die Labels "app=frontend", "team=shop" oder "role=backend" führt. Cilium übersetzt diese Label-Sets in sogenannte Security Identities und zieht sie im Datapath direkt für Policyentscheidungen heran.

Für Sie als Admin verändert das die Denkweise erheblich: Sie formulieren nicht mehr die Regel "IP x darf zu IP y", sondern "Frontend darf zu Backend auf Port 443" oder "Nur Pods mit der Identität app=payment dürfen den Datenbankdienst erreichen". Die Policy beschreibt damit die fachliche Kommunikationsbeziehung und nicht den zufälligen Netzwerkzustand eines bestimmten Moments in Form einer IP-Adresse.

Der Bezug zur Architektur bleibt dabei entscheidend, denn die genannten Identitäten sind keine abstrakte Kubernetes-Idee. Der Cilium-Agent beobachtet auf jedem Host die Kubernetes-Objekte, erkennt deren Labels, Endpoints und Policys und aktualisiert entsprechend die passenden eBPF-Datenstrukturen. Durchläuft ein Paket den Datapath, prüft Cilium die Quelle, das Ziel und ob die konfigurierte Policy diese Kommunikation erlaubt. Die Entscheidung fällt damit nah am Paketpfad, stützt sich aber auf den vollen Kubernetes-Kontext.

Policys auf mehreren Ebenen

Die Policys in Cilium greifen auf mehreren Ebenen. Auf Netzwerkebene 3 oder 4 legen Sie fest, welche Workloads grundsätzlich miteinander sprechen dürfen und welche Ports oder Protokolle erlaubt sind. Das deckt im Kern die klassische Netzwerksegmentierung ab, allerdings mit stabileren Bezugspunkten als IP-Adressen. Entstehen durch Autoscaling neue Backend-Pods, passen Sie die Regel nicht an, solange diese Pods die passenden Labels tragen.

Cilium bildet darüber hinaus auch Policys auf Anwendungsebene ab. Damit verlassen Sie die reine Port-Sicht und rücken den Anwendungskontext in den Fokus. Bei HTTP etwa schränken Sie ein, welche Methoden und Pfade zulässig sind: Ein Workload spricht dann nicht einfach irgendwie mit dem API-Service, sondern nutzt vielleicht ausschließlich "GET /health" oder "POST /orders". Für Admins und Security-Teams bedeutet diese Granularität einen großen Schritt nach vorn, denn sie sichern damit nicht nur den Zugang zu einem Port, sondern grenzen konkrete Kommunikationsmuster ein.

Auch DNS-basierte Policys erweisen sich in dynamischen Umgebungen als hilfreich. Viele Anwendungen sprechen externe Dienste nicht über feste IPs an, sondern über Namen wie "api.it-administrator.de". Pflegen Sie dafür statische IP-Regeln, laufen Sie externen Änderungen ständig hinterher. Mit DNS-basierten Regeln legen Sie stattdessen fest, welche FQDNs ein Workload erreichen darf, und Cilium bezieht diese Namensauflösung direkt in die Policybewertung ein.

In der Praxis profitieren Sie besonders bei Rollouts, Autoscaling und Blue/Green-Deployments. Ein Blue/Green-Deployment bezeichnet das parallele Aufsetzen einer neueren Softwareversion in Vorbereitung eines Updates und den anschließenden Wechsel, sobald diese einsatzbereit ist. So bereiten Sie Kommunikationspfade über Labels sauber vor, testen sie und schalten schrittweise um.

Das klingt zunächst komfortabel und leicht durchschaubar, entbindet Sie aber nicht von einer sauberen Vorbereitung. Labels werden dadurch unmittelbar sicherheitsrelevant: Vergeben Teams sie uneinheitlich oder zu großzügig, verlieren auch die Policys in Cilium ihre Schärfe. Definieren Sie deshalb verbindliche Label-Konventionen, legen Sie Verantwortlichkeiten fest und versionieren Sie Ihre Policys. Idealerweise behandeln Sie Ihre Netzwerkregeln wie Code, reviewbar, testbar und nachvollziehbar. Dann wird aus Cilium nicht nur ein schnellerer Datapath, sondern ein belastbares Sicherheitsmodell für dynamische Kubernetes-Umgebungen.

Fehlersuche mit Hubble

Angenommen, ein Workload in Ihrem Kubernetes-Cluster ist nicht erreichbar: Die klassische Fehlersuche setzt oft an mehreren Stellen gleichzeitig an. Sie prüfen die Logs der Pods, die Service-Definition, konfigurierte Endpoints, DNS-Einträge, die Node-Firewall und werfen mit Conntrack, iptables und tcpdump einen Blick in den Traffic. Das kostet Zeit, und häufig erhalten Sie nur einzelne Ausschnitte oder ertrinken geradezu im Netzwerktraffic. Am Ende wissen Sie vielleicht, dass ein Paket irgendwo angekommen ist oder eben nicht, erkennen aber nicht sofort, welche Workloads beteiligt waren, welche Identitäten dahinterstanden und ob eine Policy die Verbindung blockiert hat.

An dieser Stelle kommt Hubble ins Spiel. Hubble bildet im Kern die Observability-Schicht von Cilium und nutzt die Sichtbarkeit, die Cilium ohnehin über den eBPF-Datapath gewinnt. Statt nur rohe Pakete oder einzelne Logzeilen zu betrachten, sehen Sie Kommunikationsflüsse zwischen Pods, Services, Namespaces und Identitäten. Für Sie als Admin wird aus der wenig spezifischen Frage, wo Ihr Paket geblieben ist, damit die präzisere Frage, welche Verbindung zustande kam, mit welcher Policy Cilium diese bewertete und an welcher Stelle der Flow die Freigabe erhielt oder scheiterte.

Besonders hilfreich zeigt sich das bei der Service-zu-Service-Kommunikation. Hubble liefert Ihnen Flows mit sämtlichen relevanten Informationen: Quelle, Ziel, Port, Protokoll, Namespace, Pod, Service und Cilium-Identity. Sie sehen also nicht nur, dass 10.42.1.23 mit 10.42.2.19 spricht, sondern übersetzen diese IP-Adressen direkt zurück in Ihren Kubernetes-Kontext. Genau das macht die Fehlersuche praxistauglich: Sie debuggen nicht gegen zufällige Pod-Adressen, sondern gegen Ihre konkreten Workloads.

Bevor Sie Hubble einsetzen, prüfen Sie zunächst mit dem Cilium-CLI-Tool, ob es in Ihrem Cilium bereits aktiv ist. Bild 3 zeigt die Ausgabe ohne aktiviertes Hubble.

Aktivieren Sie Hubble direkt bei der Helm-Installation wie in Listing 1, oder greifen Sie zu folgendem Kommando:

Warten Sie anschließend einen kurzen Moment, bis die Container starten. Eine erneute Abfrage mitcilium statuszeigt Ihnen dann das Hubble Relay mit dem Status OK an.

Einmal gestartet, sammelt Hubble bereits Informationen über den Cluster und den Netzwerkverkehr. Um diese Daten einzusehen, installieren Sie entweder das Commandline-Tool oder greifen zum Hubble-UI. Letzteres starten Sie mit dem Kommando:

Die Ausgabe bestätigt Ihnen daraufhin, dass Cilium Ihren lokalen Browser startet und die URL "https://localhost:12000" öffnet. Betreiben Sie Ihren Kubernetes-Cluster nicht auf dem lokalen Rechner mit Browser, legen Sie stattdessen ein entsprechendes Port-Forwarding an und übertragen die URL manuell.

Die Startseite begrüßt Sie direkt mit der Auswahl der vorhandenen Namespaces. Wählen Sie den problematischen Namespace aus oder einfach den, in den Sie gerade hineinschauen möchten. Nach der Auswahl präsentiert Ihnen das UI einen abgeleiteten Service-Graphen: Hubble visualisiert hier die Abhängigkeiten zwischen den Anwendungen dieses Name-space, wie Bild 4 zeigt, und darunter finden Sie die letzten Verbindungsdaten übersichtlich in einer Tabelle.

Gerade in Clustern, die über Monate gewachsen sind, erweist sich die automatische Erkennung als äußerst wertvoll. Sie erkennen sofort, welche Dienste tatsächlich miteinander kommunizieren, welche Verbindungen eventuell überraschen und welche Komponenten möglicherweise noch an alten Abhängigkeiten hängen. Für Admins und Plattformteams dient das nicht nur der Fehlersuche, sondern auch der Dokumentation des Ist-Zustands.

Einen entscheidenden Vorteil bietet die bereits erwähnte Sichtbarkeit auf Anwendungsschicht in Hubble. Bei HTTP-Verkehr erkennt Hubble nicht nur, dass zwei Workloads über TCP kommunizieren, sondern macht auch Informationen wie HTTP-Methode, Pfad oder Statuscode sichtbar, sofern Sie die L7-Metriken aktiviert haben.

Gegenüber einer klassischen Proxylösung punktet Hubble damit, dass Sie für grundlegende Flow-Sichtbarkeit kein komplettes Service-Mesh ausrollen müssen: Hubble baut direkt auf Ciliums Datapath-Sicht auf. Alle anderen Werkzeuge zur Fehlersuche macht Hubble damit jedoch nicht überflüssig, tcpdump, Logs und Metriken behalten weiterhin ihren Platz im Werkzeugkasten. Hubble ergänzt sie um eine zentrale Perspektive, die sich direkt in Kubernetes und den jeweiligen Anwendungskontext integriert. Genau diese Kombination macht Ihre Fehlersuche schneller und nachvollziehbarer.

Migration und CNI-Chaining

Cilium entfaltet seinen größten Nutzen, wenn Sie es bewusst in Ihr bestehendes Betriebsmodell integrieren. In Ihrem laufenden Cluster arbeiten bereits ein CNI-Plugin, bestehende Services, Network Policys, Firewallregeln, Monitoring, etablierte Betriebsprozesse und möglicherweise eine cloudspezifische Netzwerkintegration. Ein unbedachter Ad-hoc-Tausch verbietet sich hier von selbst, denn die Migration entscheidet am Ende über Erfolg oder Misserfolg des Projekts.

CNI-Chaining bietet sich dabei als pragmatischer Zwischenschritt an. Cilium ersetzt so nicht sofort das komplette bestehende CNI-Setup, sondern kombiniert sich mit einem vorhandenen CNI. Das etablierte Plugin übernimmt weiterhin bestimmte Basisaufgaben der Pod-Netzwerkanbindung, während Cilium zusätzliche Funktionen wie Policy-Enforcement, eBPF-basierte Sichtbarkeit oder Security-Features beisteuert.

Vor der Migration sollten Sie Ihren aktuellen Zustand sauber dokumentieren. Notieren Sie, welches CNI aktuell im Einsatz ist, ob kube-proxy im iptables- oder IPVS-Modus arbeitet und ob auf einzelnen Nodes eigene iptables-Regeln existieren. Prüfen Sie außerdem die MTU im Cluster, denn diese entpuppt sich gerade bei komplexen Setups immer wieder als Fehlerursache. Berücksichtigen Sie zudem bereits existierende Network Policys und das Verhalten, das Ihre Anwendungen vom Netzwerk erwarten. Diese Fragen wirken zunächst banal, doch am Ende steckt der Teufel einer Migration im Detail.

Für die eigentliche Migration arbeiten Sie am besten mit einem Testcluster oder zumindest einem isolierten Node-Pool. Dort prüfen Sie Cilium zunächst mit denselben übergeordneten Workloads, die später produktiv relevant werden, etwa Webservices, Datenbanken, DNS oder Monitoringkomponenten. Diese sollten zuverlässig laufen. Starten Sie dabei nicht mit dem kompliziertesten Sonderfall. Um den kümmern Sie sich erst, wenn die Basis funktioniert.

Auch nach einer erfolgreichen Migration bleibt Betriebsdisziplin gefragt. Überwachen Sie Map-Größen, Connection-Tracking-Auslastung, Policyanzahl, Drop-Raten und den Zustand des Cilium-Agenten. Planen Sie weitere Upgrades wie Infrastrukturänderungen und nicht wie ein Nebenbei-Update. Gerade weil Cilium tief im Netzwerkpfad sitzt, gehören Änderungen getestet, versioniert und nachvollziehbar dokumentiert.

Transparente Verschlüsselung

Cilium verschlüsselt den Traffic zwischen Nodes transparent. IPsec gilt hier als klassischer Ansatz, WireGuard als moderne Variante. Das Schöne dabei: Trotz Verschlüsselung ändert sich für Ihre Anwendungen nichts. Die Pods sprechen weiterhin Pod-IPs, Service-IPs oder DNS-Namen an, die Verschlüsselung läuft darunter transparent im Cilium-Datapath ab. Für Admins ist WireGuard vor allem deshalb attraktiv, weil Sie damit das Sicherheitsniveau des Cluster-Netzwerks anheben, ohne jede Anwendung einzeln auf TLS oder mTLS umbauen zu müssen.

Sie aktivieren WireGuard direkt über die Helm-Konfiguration von Cilium. Fügen Sie dafür die in Listing 2 beschriebenen Optionen bei Installation oder Update von Cilium hinzu.

Bevorzugen Sie den direkten Weg über die Cilium-Konfiguration, führen Sie stattdessen folgendes Kommando aus:

Nach der Änderung vergeht wieder ein kurzer Moment, bis der Cluster vollständig umgestellt ist. Bei den vorhandenen Workloads sollte dabei kein Verbindungsabbruch auftreten. Ihr Monitoring sollte die Funktionalität der Workloads währenddessen im Blick behalten und Sie im Zweifel umgehend alarmieren. Treten Probleme auf, setzen Sie die Änderung mit

zunächst wieder zurück. Auf den einzelnen Nodes prüfen Sie direkt mit Wire-Guard, ob diese bereits verschlüsselt untereinander kommunizieren. Installieren Sie dafür die WireGuard-Userspace-Tools und rufen folgendes Kommando auf:

Die Antwort sollte der Darstellung in Bild 5 entsprechen. Die Anzeige liefert Peers, öffentliche Schlüssel, Endpoints und Hand-shake-Informationen. Gerade die Hand-shakes verdienen im Betrieb Aufmerksamkeit: Ist ein Peer konfiguriert, findet aber nie ein Handshake statt, blockiert häufig das darunterliegende Netz die Verbindung.

Planen Sie für den Betrieb von Wire- Guard den UDP-Port 51871 explizit in der Firewall ein. Dieser Port muss zwischen allen Nodes erreichbar bleiben. Prüfen Sie dafür im Vorfeld auch Security Groups, Firewalls, Network ACLs und einzelne Node-Firewalls.

Beachten Sie bei einer späteren Fehlersuche in Ihrem Netzwerk, dass WireGuard ausschließlich den Traffic zwischen den Nodes verschlüsselt. Traffic zwischen Pods auf demselben Node bleibt unverschlüsselt, da diese Pakete den Node gar nicht erst verlassen und folglich nicht durch den WireGuard-Tunnel laufen.

Ebenfalls wichtig: Das Aktivieren von WireGuard macht möglicherweise Anpassungen an der MTU notwendig. Betreiben Sie Cilium im Tunnel-Modus und aktivieren zusätzlich WireGuard, kann eine doppelte Kapselung entstehen, das Paket wird dann sowohl verschlüsselt als auch getunnelt. Prüfen Sie deshalb nicht nur mit kleinen Ping-Tests, sondern auch mit größeren Paketen und echten Applikationsverbindungen, ob das Netzwerk stabil bleibt. So erkennen Sie frühzeitig, ob Fragmentierung oder zu große Pakete die Verbindungen später stören.

Transparente Verschlüsselung ersetzt selbstverständlich keine Anwendungssicherheit. WireGuard schützt zwar den Transport zwischen Nodes, authentisiert aber nicht automatisch die Benutzer des Clusters oder einzelner Anwendungen. Auch TLS zwischen Services macht Wire- Guard nicht überflüssig. Setzen Sie WireGuard daher eher als Infrastruktur-Baustein ein, etwa um Nodes über Datacenter-Grenzen hinweg zu verbinden und versehentliche unverschlüsselte Datenübertragung von vornherein auszuschließen.

Fazit

Cilium verändert den Blick auf Kubernetes-Netzwerke grundlegend, weg von der starren IP-Logik klassischer iptables-Regelketten, hin zu einem Modell, das Workloads anhand ihrer Identität behandelt. Wer eBPF als reines Performancefeature abtut, verkennt den eigentlichen Kern: Cilium bietet Ihnen mit programmierbarem Kernel-Datapath, identitätsbasierten Policys und integrierter Observability ein komplett neues Betriebsmodell, das der Dynamik moderner Cluster tatsächlich gerecht wird.

Besonders die Kombination aus Policy-Engine und Hubble zahlt sich im Alltag aus. Statt sich durch Conntrack-Tabellen und verschachtelte NAT-Regeln zu wühlen, sehen Sie auf einen Blick, welche Workloads kommunizieren, welche Policy eine Verbindung erlaubt oder blockiert hat und wo im Datapath eine Entscheidung fällt. Für Admins und Security-Teams bedeutet das weniger Rätselraten und mehr belastbare Fakten, gerade wenn ein Cluster über Monate gewachsen ist und niemand mehr sämtliche Abhängigkeiten im Kopf hat.

Der Umstieg gelingt dabei selten über Nacht. CNI-Chaining erlaubt Ihnen einen behutsamen Einstieg, ohne das bestehende Setup sofort über Bord zu werfen, und auch danach bleibt Cilium kein Selbstläufer: Map-Größen, Connection-Tracking-Auslastung und Policyanzahl verdienen dauerhafte Aufmerksamkeit. Wer Netzwerkregeln wie Code behandelt, reviewbar, versioniert und nachvollziehbar, schöpft das Potenzial von Cilium tatsächlich aus.

Mit WireGuard-Verschlüsselung rundet Cilium das Sicherheitsbild weiter ab, ersetzt dabei aber bewusst keine Anwendungssicherheit und kein TLS zwischen Services. Wer diese Grenzen kennt und Cilium als das versteht, was es ist, nämlich ein leistungsfähiger Infrastruktur-Baustein und kein Allheilmittel, gewinnt am Ende genau das, was in hochdynamischen Kubernetes-Umgebungen zählt: Transparenz, Kontrolle und ein Netzwerk, das sich nachvollziehen statt nur ertragen lässt.

Kubernetes-Verwaltung mit Cilium und Hubble