Cilium Kubernetes: CNI-Wahl ohne Mesh-Theater 2026

Robin, Kubernetes-Betrieb bei Pexon Consulting | 10 Min. Lesezeit | 11.09.2026

TL;DR: Cilium Kubernetes als CNI, nicht als Religion

Cilium Kubernetes ist 2026 die vernünftige Default-CNI für neue Linux-Cluster: eBPF-Dataplane, Hubble, kube-proxy-Ersatz. Pexon Consulting (80 Mitarbeitende, Deutschland, Microsoft Partner) nimmt Calico, wenn BGP oder Windows den Schnitt bestimmen. Auf wenigen Knoten gewinnt nicht der Benchmark. Es gewinnt, wer Policies und Sicht später nicht nachrüsten muss.

Das Problem: ihr sucht ein Plugin und kauft eine zweite Karriere

Die Ausschreibung sagt „Network Plugin“. Im Cluster liegt flannel oder das Distro-Default. NetworkPolicy ist eine Folie. Hubble hat niemand eingeschaltet, weil niemand Hubble gesagt hat. Sechs Monate später will Security wissen, welcher Pod mit welchem Host gesprochen hat. Dann beginnt die Suche nach einem Mesh.

Das ist die teure Reihenfolge.

Cilium Kubernetes löst zuerst die langweilige Schicht: Pod-IPs, Services, Policies. Mesh, Ingress, Cluster Mesh sind optionale Aufsätze. Wer mit dem Aufsatz startet, diskutiert Sidecars, während DNS noch über iptables stolpert.

Wir sehen das in kleinen On-Prem-Setups besonders deutlich. Drei bis sechs Knoten, local-path Storage, Rancher darüber. Die kube-proxy-Schmerzgrenze von 100 Nodes ist dort ein Mythos. Trotzdem ist ein Default-CNI ohne Flow-Sicht ein Betriebsrisiko. Nicht wegen Durchsatz. Wegen der ersten Forensik.

Pexon Consulting schneidet die CNI-Frage deshalb als Betriebsfrage, nicht als Kernel-Vortrag.

Cilium Kubernetes heißt CNI, nicht automatisch Service Mesh

Die kurze Antwort: Cilium ersetzt das Netzwerk-Plugin. Es ersetzt Istio nicht, nur weil irgendwer „eBPF Mesh“ auf eine Folie geschrieben hat.

Die Mesh-Entscheidung (Istio, Linkerd, Cilium Service Mesh) haben wir im Istio-Linkerd-Cilium-Vergleich schon gelegt. Hier bleibt die Ebene darunter. Wer beide Texte in einen rührt, kannibalisiert sich selbst und verwirrt den Suchintent.

Was die CNI-Ebene 2026 konkret kann:

eBPF im Kernel statt einer iptables-Kette, die mit jeder Service-Zahl wächst. kube-proxy-Replacement für ClusterIP, NodePort, LoadBalancer. NetworkPolicies, die Identität kennen, nicht nur CIDR. Hubble als eingebaute Flow-Sicht. Optional L7-Regeln und Gateway API, wenn ihr das wirklich braucht.

Was sie nicht kann, ohne dass ihr extra zahlt: Windows-Nodes. Einen Kernel unter 5.4 sinnvoll. Eine Entschuldigung, wenn das Hausnetz BGP vom Netzwerkteam erwartet und niemand Cilium-BGP anfassen will.

Cilium 1.20.1 ist am 18.08.2026 erschienen, parallel die Wartungsstände 1.19.7 und 1.18.13. Das Repo cilium/cilium lag am 11.09.2026 bei 24.969 GitHub-Stars. 1.21 stand da als Pre-Release. Für Prod nehmen wir den stabilen 1.20er-Zweig, nicht den Pre.

# kube-proxy weg, CNI an. Werte an eure API anpassen.
# Helm-Chart cilium/cilium --version 1.20.1, Stand 18.08.2026
helm install cilium cilium/cilium --version 1.20.1 
  --namespace kube-system 
  --set kubeProxyReplacement=true 
  --set k8sServiceHost=10.0.0.10 
  --set k8sServicePort=6443 
  --set hubble.relay.enabled=true 
  --set hubble.ui.enabled=true

Ohne k8sServiceHost nach dem kube-proxy-Kill findet Cilium die API nicht. Das ist der Klassiker, der „Cilium ist instabil“ erzeugt. Es ist eine Installationslücke.

Cilium vs Calico: wann wir welches nehmen

Unsere klare Empfehlung für neue Linux-only-Cluster 2026: Cilium. Calico bleibt die richtige Ausnahme, nicht der sentimentale Default.

Calico gewinnt, wenn eines von dreien wahr ist. Das Netzwerkteam spricht BGP und will das Cluster wie ein weiteres ASN behandeln. Es gibt Windows-Worker. Der Kernel ist so alt, dass eBPF-only ein Umbau der Nodes wäre, nicht ein Helm-Wert.

Calico verliert, wenn ihr „wir kennen iptables“ als Strategie verkauft. Der eBPF-Modus von Calico existiert. Er macht aus Calico kein Hubble. Ihr baut euch den Observability-Stack extra, den Cilium mitliefert.

Auf fünf Knoten ist der Performance-Abstand oft akademisch. Reddit hat recht: unter 20 Nodes beißt kube-proxy selten. Der Grund für Cilium Kubernetes in genau dieser Größe ist Hubble plus eine Policy-Sprache, die ihr später nicht wegwerfen müsst. Wer „erst Calico, Mesh kommt irgendwann“ plant, zahlt die zweite Einführung.

Wir raten davon ab, beide CNIs im selben Cluster zu ketten, „damit wir uns nicht festlegen“. Ein Cluster, eine Dataplane. Unterschiedliche CNIs über verschiedene Cluster der Flotte sind erlaubt. Ein Hybrid im selben Node ist Theater.

Hubble, Policies, kube-proxy: was ihr am ersten Tag wirklich braucht

Drei Schalter, nicht dreißig.

kube-proxy aus. Oder ehrlich drin lassen und den Ersatz später nachrüsten. Halb ist der Zustand, in dem niemand mehr weiß, wer Services bedient. Wir stellen den Ersatz in neuen Clustern am Tag 1. In lebenden Clustern nur mit einem Wartungsfenster und einem Rollback auf das alte Manifest.

Hubble an, mindestens Relay. UI ist Geschmack. Relay plus ein hubble observe gegen den Verdacht „der Pod kommt nicht durch“ spart die erste Nacht. Wer Hubble auslässt, hat Cilium als schnelleres flannel gekauft.

Default-Deny erst im App-Namespace, nicht clusterweit am Freitag. Clusterweites Deny ohne Inventory ist ein Sev-1, den ihr selbst auslöst. Wir setzen Allow-Listen dort, wo die Fachservices sprechen. kube-system bleibt erstmal atembar.

L7-Policies und TLS-Break sind ein eigener Schnitt. Den haben wir für den Agent-Egress schon beschrieben. In einem normalen Microservice-Keller sind sie selten Tag-1. Wer sie clusterweit auf jedes Namespace legt, kauft Zertifikate und einen Betriebsratstermin.

XDP und DSR klingen nach Rechenzentrum. Auf Broadcom-NICs im Mittelstands-Rack fällt XDP oft auf generic zurück. Dann ist der Gewinn weg. Messt, bevor ihr die Folie zeigt.

1. Kernel und NIC gegen die Cilium-Matrix halten.
2. kube-proxy-Entscheidung schreiben, nicht nur setzen.
3. Hubble-Relay als Nachweis, nicht als Spielzeug.
4. Eine NetworkPolicy für den ersten Fach-Namespace.
5. Upgrade-Zweig festlegen (1.20, nicht latest).

Woran kleine On-Prem-Cluster an Cilium scheitern

local-path und Cilium vertragen sich. Was sich nicht verträgt: ein Node, der IPv6 half-an hat, ein zweiter, der es nicht hat, und ein Chart, das Dual-Stack annimmt. Macht ein IP-Familien-Profil und bleibt dabei.

Rancher-provisionierte Cluster bringen oft ein Distro-CNI mit. Cilium danach zu installieren, ohne das alte Plugin zu entfernen, erzeugt zwei Wahrheiten auf demselben Node. Ein CNI, ein Cleanup, ein Reboot-Fenster. Kein „einfach daneben“.

aks-pilot ist die andere Falle. AKS kann Cilium als Netzwerk-Plugin liefern. On-Prem Cilium 1.20 und AKS-Cilium sind verwandt, nicht identisch in den Default-Werten. Gleiche Policy-Sprache, andere Helm-Werte. Wer Manifeste 1:1 rüberschiebt, wundert sich über Hubble, das im Pilot fehlt, weil Azure den Schalter anders nennt.

Pexon Consulting (Microsoft Partner, 30 Azure-Spezialisten) sieht denselben Ablauf: CNI zuerst in Staging, Hubble-Beweis, dann Prod. Wer in Prod „schnell Cilium“ macht, weil Calico eine Policy nicht kann, macht aus einer Policy-Lücke ein Netzwerk-Projekt.

Ein zweiter Fehler, seltener und teurer: Cilium nur auf Prod, Staging bleibt Distro-Default. Dann beweist ihr Policies dort, wo sie wehtun, und nicht dort, wo ihr sie brechen dürft. Gleiche CNI-Familie über Staging und Prod. Der aks-pilot darf abweichen, wenn Azure den Schalter anders legt. Er darf nicht die einzige Stelle sein, an der ihr Hubble zum ersten Mal seht.

Ein Satz zur Sicherheit, ohne die Hardening-Checkliste zu wiederholen: Cilium ersetzt weder CIS-Benchmarks noch RBAC. Es macht Flows sichtbar und Policies durchsetzbar. Wer das mit „wir sind gehärtet“ verwechselt, liegt falsch. Die 32-Punkte-Härtung bleibt ein eigener Text.

Häufig gestellte Fragen

Was kostet Cilium Kubernetes im Vergleich zu Calico?

Beide Open-Source-Kernprodukte sind ohne Lizenzpreis nutzbar. Geld sitzt in Einarbeitung, Policies, Hubble-Betrieb und dem ersten Upgrade. Enterprise-Angebote (Isovalent/Cisco, Tigera) sind optional. Der Einstieg bei uns ist ein Betriebsgespräch, kein Listenpreis im Artikel.

Cilium Kubernetes oder Calico: was sollen wir 2026 nehmen?

Cilium, wenn der Cluster Linux ist und ihr Sicht plus Policies wollt. Calico, wenn BGP oder Windows den Schnitt setzen. Beides im selben Cluster ist die teurere Unentschiedenheit.

Brauchen wir nach Cilium noch ein Service Mesh?

Oft nein. mTLS und Traffic-Splitting sind Mesh-Gründe, nicht CNI-Gründe. Die Mesh-Frage bleibt der Vergleichstext. Cilium als CNI verpflichtet euch nicht zum Cilium-Mesh.

Ersetzt Cilium kube-proxy wirklich?

Ja, wenn ihr kubeProxyReplacement=true setzt und die API-Adresse übergebt. Halb aktiviert, halb nicht, ist der Zustand, den wir in Reviews am häufigsten zurückbauen.

Für wen lohnt der Wechsel von einem laufenden Calico nicht?

Für Cluster, die ruhig laufen, keine L7-Frage haben und deren Team Calico kann. Ein Wechsel nur wegen Folien ist Geldverbrennung. Neu bauen ist der saubere Moment, nicht das Live-Wochenende.

Nächster Schritt

Verwandte Themen