Praxisbericht: Kubernetes-Netzwerk ohne OverengineeringCilium: Time to say goodbye – Warum wir eBPF aus unserem Kubernetes-Cluster entfernt haben

Cilium gilt als moderne High-Performance-Lösung für Kubernetes-Netzwerke – und das völlig zurecht. Doch nicht jedes Cluster profitiert von der zusätzlichen Komplexität von eBPF, Hubble und tiefgreifenden Kernel-Eingriffen. In diesem Erfahrungsbericht teilen wir unsere Learnings mit Cilium in einem produktiven AWS-EKS-Cluster, warum wir die Reißleine gezogen haben und weshalb „langweilige“ Netzwerk-Setups für viele Teams die wirtschaftlichere und stabilere Wahl sind.

Auf einen Blick: Warum wir uns gegen Cilium entschieden haben (TL;DR)

Für alle, die vor der Wahl des passenden Container Network Interface (CNI) stehen oder überlegen, Cilium einzuführen, hier unsere wichtigsten Erkenntnisse zusammengefasst:

• Ursprünglicher Treiber: Wir wollten HTTP-Responses und Statuscodes von ausgehenden Requests an externe APIs ohne invasive Sidecars via Hubble observieren.
• Die operative Realität: Das Debugging verlagerte sich von bewährten Linux-Werkzeugen (tcpdump, iptables) hin zu eBPF-Spezialtools (cilium-dbg, BPF-Maps). Das erhöhte die kognitive Last im Team drastisch.
• Upgrades als Risikoherd: Jedes Kubernetes- und Node-AMI-Upgrade auf AWS EKS erforderte eine genaue Prüfung der eBPF-Kompatibilität und Cilium-CRD-Versionen.
• Ressourcenaufwand vs. Mehrwert: Das Betreiben von Cilium-Agenten, Hubble Relay und Hubble UI verbrauchte messbar Node-Ressourcen für Features, die wir abseits des API-Monitorings kaum nutzten.
• Die Konsequenz: Rückkehr zum nativen AWS VPC CNI in Verbindung mit anwendungsseitigem Monitoring über OpenTelemetry und Standard-Prometheus-Metriken.
• Fazit: Für Hyper-Scale-Umgebungen und komplexe Service-Meshes ist Cilium hervorragend. Für Standard-Webanwendungen und mittelgroße Cluster ist es oft klassisches Overengineering.

1. Warum wir uns für Cilium entschieden haben: Die eBPF-Vision

Wer sich in der Cloud-Native-Welt mit Kubernetes-Networking beschäftigt, stößt unweigerlich auf Cilium. Das von Isovalent ins Leben gerufene und inzwischen von der CNCF graduierte Projekt verspricht eine Revolution des Linux-Kernels: Statt Pakete über langsame iptables-Ketten oder IPVS zu schleusen, klinkt sich Cilium über eBPF (Extended Berkeley Packet Filter) direkt in den Datenpfad des Kernels ein.

In unserem früheren Grundlagenartikel Verwendung von Cilium für Kubernetes-Netzwerke und Beobachtbarkeit hatten wir diese Vorteile bereits ausführlich beleuchtet:

• High-Performance Routing: Nahezu latenzfreie Paketverarbeitung auf Kernel-Ebene.
• Erweiterte Network Policies: Filterung auf Layer 7 (z. B. nach HTTP-Methoden, Pfaden oder DNS-Namen).
• Integrierte Observability mit Hubble: Transparenz über jeden einzelnen Flow im Cluster ohne Code-Änderungen.
• Ersatz für kube-proxy: Beseitigung von Skalierungslimits großer iptables-Regelsätze.

Unser konkreter Usecase: Externe API-Observability

Der finale Impuls für den Einsatz in unserem AWS-Kubernetes-Cluster (AWS EKS) war ein scheinbar simpler operativer Bedarf: Unsere Microservices kommunizieren intensiv mit externen Drittanbieter-APIs (Payment-Gateways, CRM-Systeme, Logistik-Schnittstellen).

Wir wollten wissen:

1. Wie viele externe Requests scheitern mit HTTP-Statuscodes wie 429 Too Many Requests oder 502 Bad Gateway?
2. Wie hoch sind die Latenzen zu spezifischen externen FQDNs?
3. Welche Pods verursachen unerwarteten Egress-Traffic?

Die Vision mit Cilium und Hubble klang perfekt: Kein mühsames Einbauen von Logging-Clients in jeden einzelnen Microservice, keine zusätzlichen Sidecar-Proxies wie Envoy pro Pod. Hubble versprach, all diese Layer-7-Metriken transparent aus dem Kernel abzufangen und via Hubble-UI sowie Prometheus bereitzustellen.

2. Die operative Realität: Der versteckte Preis von eBPF

Die Implementierung funktionierte zunächst wie demonstriert. Hubble lieferte schöne Service-Maps und detaillierte Flow-Logs. Doch im laufenden Produktivbetrieb über mehrere Monate zeigte sich die Kehrseite der Medaille: Komplexität verschwindet nicht, sie verlagert sich nur.

Neues Debugging-Paradigma: Wenn tcpdump und iptables nicht mehr helfen

In einem klassischen Linux- und Kubernetes-Setup greifen Ingenieure bei Netzwerkproblemen auf ein vertrautes Arsenal zurück: tcpdump, ping, traceroute, netstat, iptables-save oder conntrack. Diese Werkzeuge sind seit Jahrzehnten Standard und jedem Systemadministrator in Fleisch und Blut übergegangen.

Unter Cilium verändert sich die Spielwiese radikal:

• Da eBPF-Programme an TC- (Traffic Control) und XDP-Hooks ansetzen, sieht tcpdump auf dem Host-Interface oft nicht mehr die Pakete, die man erwartet.
• Routing-Entscheidungen und NAT-Übersetzungen passieren in BPF-Maps im Kernel-Speicher.
• Bei Paketverlusten reicht kein einfaches Syslog-Tailen mehr. Man muss Werkzeuge wie cilium-dbg monitor --type drop oder bpftool map dump bemühen.

Für ein On-Call-Team bedeutet das: Tritt nachts um 3:00 Uhr ein obskurer Verbindungsfehler zwischen zwei Services auf, hilft das jahrelang aufgebaute Linux-Netzwerkwissen nur noch bedingt weiter. Plötzlich muss sich der diensthabende Entwickler mit BPF-Bytecode, Tail-Calls und Map-Limitierungen auseinandersetzen. Die kognitive Last für das gesamte Team stieg spürbar an.

# Vor Cilium: Vertrautes Paket-Tracing auf dem Node
sudo tcpdump -nn -i any port 443

# Mit Cilium: Spezialisierte eBPF-Kommandos und BPF-Map-Inspektion
cilium-dbg monitor --type drop
cilium-dbg bpf nat list
cilium-dbg endpoint list

Upgrade-Komplexität: Doppelte Abhängigkeiten bei Cluster-Updates

In einer verwalteten Cloud-Umgebung wie AWS EKS profitiert man normalerweise von automatisierten, schmerzlosen Updates: Amazon stellt neue Node-AMIs bereit, man rollt die Worker-Nodes durch, fertig.

Mit Cilium wurde dieser Prozess deutlich riskanter:

1. Kernel-Kompatibilität: Cilium hängt extrem stark von spezifischen Kernel-Versionen und BPF-Features des Host-Betriebssystems ab. Ein scheinbar harmloses AMI-Update mit neuem Kernel-Patchstand führte in der Vergangenheit zu unerwarteten Inkompatibilitäten.
2. Kopplung von Helm- und CRD-Upgrades: Vor jedem Kubernetes-Upgrade mussten wir zunächst die Cilium-Helm-Charts und deren Custom Resource Definitions (CiliumNetworkPolicy, CiliumClusterwideNetworkPolicy, CiliumNode) synchronisieren.
3. Fehlersuche bei Rollouts: Gab es nach einem Node-Restart Verbindungsprobleme, war unklar: Lag es an AWS EKS, an den Node-Security-Groups oder am eBPF-Bootstrap von Cilium?

Observability-Overhead: Hubble für HTTP-Monitoring?

Unser Hauptgrund für Cilium war die Beobachtbarkeit externer HTTP-Calls. Nach einigen Monaten zogen wir nüchtern Bilanz:

• Ressourcenverbrauch: Der cilium-agent auf jeder Node sowie die zentralen Komponenten hubble-relay und hubble-ui belegten kontinuierlich CPU und Arbeitsspeicher, der unseren eigentlichen Workloads fehlte.
• Hohe Kardinalität: Das Erfassen jedes einzelnen Netzwerk-Flows erzeugte riesige Datenmengen, die Prometheus belagerten.
• Anwendungsnahe Alternativen: Wir stellten fest, dass standardisierte Application-Tracing-Lösungen (wie OpenTelemetry oder strukturierte Logs mit Prometheus-Metriken im App-Code) denselben Zweck erfüllten – allerdings mit Kontext: Die Anwendung weiß nämlich nicht nur, dass ein Call 500 lieferte, sondern auch für welchen Kunden und mit welchem Payload.

Hubble lieferte uns Kernel-Daten, aber die fachliche Relevanz im Application-Monitoring blieb oft auf der Strecke.

Dokumentationslücken bei Cloud-Provider-Integrationen

Cilium verfügt über eine umfangreiche Dokumentation, doch sobald man spezifische Provider-Features nutzt – etwa AWS IAM Roles for Service Accounts (IRSA), AWS Security Groups per Pod, native ENI-Zuweisung oder ALB Ingress Controller –, stößt man auf Sonderfälle. Viele Online-Tutorials und Community-Foren setzen auf Standard-Bare-Metal-Setups auf. Das Debugging von Hybrid-Konfigurationen (Cilium Chaining vs. Cilium Native Routing) kostete unverhältnismäßig viel Research-Zeit.

3. Der direkte CNI-Vergleich: Cilium vs. AWS VPC CNI vs. Calico

Um eine fundierte Entscheidung für die Zukunft zu treffen, stellten wir die gängigen Netzwerk-Optionen für AWS EKS einander gegenüber:

Das Fazit des Vergleichs war eindeutig: Der AWS VPC CNI ist für EKS-Workloads das einfachste, bestintegrierte und wartungsärmste Setup. Jeder Pod erhält eine echte IP-Adresse aus dem AWS Subnet, AWS VPC Flow Logs funktionieren out-of-the-box und Sicherheitsgruppen können direkt an Pods gehängt werden.

4. Der Lackmustest: Wann lohnt sich Cilium – und wann ist es Overengineering?

Cilium ist kein schlechtes Produkt – im Gegenteil: Es ist eines der innovativsten Open-Source-Projekte im Cloud-Native-Bereich. Doch wie bei vielen Trends verfällt die Tech-Branche leicht dem Drang, Lösungen für Probleme zu implementieren, die man selbst gar nicht hat.

Mit folgendem Fragenkatalog kannst du prüfen, ob Cilium für deine Infrastruktur sinnvoll ist:

                  ┌────────────────────────────────────────┐
                  │ Benötigt dein Cluster Multi-Cloud Mesh │
                  │ oder mehr als 5.000 Pods zeitgleich?   │
                  └──────────────────┬─────────────────────┘
                                     │
                     ┌───────────────┴───────────────┐
                    JA                              NEIN
                     │                               │
           ┌─────────▼────────┐          ┌───────────▼─────────────┐
           │ Cilium empfohlen │          │ Brauchst du zwingend    │
           └──────────────────┘          │ Layer-7 Network Policies│
                                         │ auf Kernel-Ebene?       │
                                         └───────────┬─────────────┘
                                                     │
                                     ┌───────────────┴───────────────┐
                                    JA                              NEIN
                                     │                               │
                           ┌─────────▼────────┐          ┌───────────▼─────────────┐
                           │ Cilium evaluieren│          │ Bleibe beim Cloud-      │
                           └──────────────────┘          │ nativen CNI (z.B. AWS   │
                                                         │ VPC CNI / Azure CNI)!   │
                                                         └─────────────────────────┘

Cilium ist die richtige Wahl, wenn...

• Große Skalierung gefordert ist: Dein Cluster umfasst hunderte Nodes und zehntausende Pods, bei denen kube-proxy und iptables an ihre Leistungsgrenzen stoßen.
• Cluster Mesh / Multi-Cloud Pflicht ist: Du verbindest mehrere Kubernetes-Cluster über Cloud-Grenzen hinweg transparent auf Netzwerkebene.
• Strikte Zero-Trust L7-Policies erforderlich sind: Du musst feingranulare HTTP- und DNS-Richtlinien erzwingen, ohne ein vollständiges Service Mesh (wie Istio oder Linkerd) zu betreiben.
• Spezifisches eBPF-Know-how im Team vorhanden ist: Dein Team kann Kernel-Dumps interpretieren und BPF-Tracing sicher anwenden.

Ein einfacheres CNI ist die bessere Wahl, wenn...

• Kleine bis mittelgroße Cluster betrieben werden: Dein Workload besteht aus Standard-Web-APIs, E-Commerce-Plattformen oder Unternehmensanwendungen.
• Wartungsarmut Priorität hat: Upgrades sollen geräuschlos durchlaufen, ohne dass man Helm-Release-Notizen nach Breaking Changes in BPF-Maps durchforsten muss.
• Standard-Monitoring ausreicht: Application Performance Monitoring (APM), Prometheus und Grafana decken deinen Observability-Bedarf vollständig ab.
• Klassische Linux-Tools genutzt werden: Das Team möchte bei Netzwerkausfällen mit tcpdump, traceroute und Cloud-eigenen Flow-Logs debuggen.

In unserem Fall lautete das ehrliche Urteil: Wir hatten uns einen Formel-1-Wagen gekauft, um im Berufsverkehr Brötchen zu holen.

5. Warum „Boring Infrastructure“ in der Produktion gewinnt

In seinem bekannten Essay „Choose Boring Technology“ beschreibt Dan McKinley, dass jedes Entwicklungsteam nur über ein begrenztes Kontingent an „Innovation Tokens“ verfügt. Wer diese Tokens für Basisinfrastruktur wie das Netzwerk-Interface ausgibt, hat weniger Energie für den eigentlichen Geschäftswert seiner Applikationen.

Netzwerke im Kubernetes-Cluster sollten wie fließendes Wasser sein: unsichtbar, verlässlich und langweilig.

Die Vorteile von langweiliger Technologie im Cluster:

1. Geringere kognitive Belastung: Niemand muss Schulungen über eBPF-Bytecode absolvieren, um ein Routing-Problem zu analysieren.
2. Kürzere Mean Time to Recovery (MTTR): Im Ernstfall greifen etablierte Runbooks und weltweit dokumentierte Best Practices.
3. Resiliente Update-Zyklen: Verwaltete Managed-Kubernetes-Upgrades (wie bei AWS EKS oder Google GKE) funktionieren ohne stundenlange Vorab-Tests von Drittanbieter-Kernelmodulen.
4. Optimierte Kosten: Weniger DaemonSets bedeuten mehr freie CPU- und RAM-Kapazitäten für Pods, wie wir auch in unserem Leitfaden zur Azure Kubernetes Kostenoptimierung betonen.

6. Unser Rückweg: Wie wir Cilium deinstalliert und migriert haben

Der Entschluss stand fest: Cilium musste weichen. Doch wie baut man ein CNI aus einem produktiven Kubernetes-Cluster zurück, ohne Ausfallzeiten zu riskieren?

Die Migrationsschritte im Überblick

Eine CNI-Migration im laufenden Cluster gleicht einer Operation am offenen Herzen. Wir gingen deshalb in vier strukturierten Phasen vor:

# 1. Bestandsaufnahme bestehender Cilium-Ressourcen
kubectl get ciliumnetworkpolicies -A
kubectl get ciliumclusterwidenetworkpolicies

# 2. Übersetzung in Standard-Kubernetes-NetworkPolicies
# (Ersetzen proprietärer L7-Regeln durch Standard L3/L4 Egress/Ingress)

# 3. Vorbereitung der neuen Node-Gruppe mit AWS VPC CNI und kube-proxy
# Nodes werden provisioniert, während Cilium noch auf alten Nodes läuft

# 4. Schrittweises Draining der alten Cilium-Nodes
kubectl cordon <node-name>
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

1. Policy-Translation: Alle CiliumNetworkPolicies wurden analysiert. Da wir auf L7-Filterung verzichten konnten, überführten wir die Regeln in standardisierte Kubernetes NetworkPolicy-Objekte.
2. Egress-Monitoring ins APM verlagern: Für das Tracking externer HTTP-Statuscodes statteten wir unsere zentralen HTTP-Clients in den Services mit OpenTelemetry-Instrumentierung aus. Dadurch erhielten wir nicht nur Statuscodes, sondern auch User-IDs und Transaktionskontexte.
3. Parallele Node-Pools aufsetzen: Wir erstellten neue Worker-Node-Pools, auf denen der offizielle aws-node (AWS VPC CNI) sowie kube-proxy konfiguriert waren.
4. Schrittweises Draining & CNI-Deinstallation: Über kubectl drain wanderten die Workloads kontrolliert von den alten Cilium-Nodes auf die neuen AWS-VPC-Nodes. Nach erfolgreichem Umzug aller Pods wurden das Cilium-Helm-Release und die verbliebenen CRDs restlos deinstalliert.

Die Resultate nach dem Rollback

Seit der Rückkehr zum Standard-Netzwerk beobachten wir messbare Verbesserungen:

• Null CNI-bezogene Incident-Tickets: In den vergangenen sechs Monaten gab es kein einziges ungeklärtes Netzwerkproblem.
• Problemlose EKS-Upgrades: Die Cluster-Upgrades auf die neuesten Kubernetes-Versionen liefen vollautomatisiert und ohne Zwischenfälle durch.
• Ressourceneinsparung: Pro Node wurden ca. 200–400 MB RAM und wertvolle CPU-Zyklen frei, die zuvor für Cilium-Agenten und BPF-Maps reserviert waren.
• Vereinfachtes Onboarding: Neue Entwickler und DevOps-Kollegen finden ein vertrautes Standard-EKS-Setup vor und können sofort produktiv arbeiten.

7. Fazit: Die richtige Komplexität für dein Team wählen

Cilium ist ein Meilenstein der Cloud-Native-Entwicklung und eBPF zweifellos eine zukunftsweisende Technologie. Wer riesige Cluster betreibt, Telco-Workloads stemmt oder BGP-Peering im eigenen Rechenzentrum benötigt, trifft mit Cilium eine exzellente Wahl.

Für die Mehrheit der Unternehmen mit kleinen bis mittelgroßen Workloads auf AWS, Azure oder Google Cloud gilt jedoch: Technischer Minimalismus ist ein Feature, kein Mangel.

Die Frage vor jeder Architekturentscheidung sollte nicht lauten: „Was kann dieses Tool alles?“, sondern: „Können wir den operativen Preis dieses Tools über die nächsten fünf Jahre rechtfertigen?“

Manchmal ist der mutigste Schritt im Cloud-Engineering nicht das Einführen der neuesten High-End-Technologie – sondern der bewusste Abschied davon.

8. Häufig gestellte Fragen (FAQ)

Warum haben wir uns gegen Cilium im Kubernetes-Cluster entschieden?

Die operative Komplexität von eBPF, veränderte Debugging-Workflows (z. B. cilium-dbg statt gewohntem tcpdump), Upgraderisiken bei Node- und Kernel-Updates sowie der zusätzliche Ressourcen-Overhead von Hubble standen in keinem Verhältnis zu unserem tatsächlichen Nutzen im AWS EKS Cluster.

Welche Alternative zu Cilium nutzen wir jetzt auf AWS EKS?

Wir setzen auf den nativen AWS VPC CNI in Kombination mit Standard-Kubernetes-Komponenten (kube-proxy). Für die Layer-7-Observability externer API-Calls nutzen wir anwendungsseitiges Application Performance Monitoring (APM) und OpenTelemetry statt Kernel-Level-Tracing.

Welche Nachteile bringt eBPF im täglichen Kubernetes-Betrieb mit sich?

eBPF klinkt sich tief in den Linux-Kernel ein und umgeht herkömmliche Stacks wie iptables und conntrack. Standardwerkzeuge wie tcpdump greifen nicht wie gewohnt. Fehlersuche erfordert spezialisiertes Wissen über eBPF-Maps, BPF-Bytecode und Werkzeuge wie bpftool oder cilium-dbg.

Ist Cilium generell eine schlechte CNI-Lösung?

Nein, keineswegs. Cilium ist eine hochentwickelte Spitzenlösung für Kubernetes. Für sehr große Cluster mit tausenden Services, Multi-Cluster-Mesh-Anforderungen oder strikten Layer-7-Sicherheitsrichtlinien ist Cilium oft unschlagbar. Für typische kleine bis mittlere Cloud-Cluster ist es jedoch häufig Overengineering.

Wie aufwendig ist die Deinstallation oder Rückmigration von Cilium?

Eine Migration erfordert sorgfältige Planung: Übersetzung bestehender CiliumNetworkPolicies in native Kubernetes NetworkPolicy-Ressourcen, schrittweises Draining der Node-Pools, Bereinigung von eBPF-Mounts (/sys/fs/bpf) und die Neuinstallation des Ziel-CNIs (z. B. AWS VPC CNI) mit anschließendem Routing-Test.

Was bedeutet das Prinzip „Choose Boring Technology“ in Kubernetes?

Es besagt, dass man für kritische Basisinfrastruktur etablierte, gut verstandene und wartungsarme Werkzeuge wählen sollte. Wenn nachts ein Incident auftritt, zählt die schnelle Lösbarkeit mit vertrauten Standard-Werkzeugen mehr als die theoretische Eleganz modernster Technologien.

Suchst du Unterstützung bei der Optimierung deiner Kubernetes-Architektur oder möchtest du Overengineering im Cluster vermeiden? Erfahre mehr über unsere Cloud-Native Beratung, unsere Services für Migration auf Kubernetes oder nimm direkt Kontakt mit unseren Experten für Docker & Kubernetes auf.