Cilium vs Calico: CNI-Vergleich nach Projekt-Doku, mit Entscheidungstabelle

CNI-Entscheidung für einen neuen oder bestehenden Cluster? WZ-IT plant und betreibt Kubernetes-Netzwerke: CNI und Network Policies, Gateway API, Load Balancing, DNS und TLS - und private Zugänge über NetBird statt unnötiger Public Exposure. Netzwerk & Secure Access ansehen

Cilium oder Calico? Beide setzen Kubernetes-NetworkPolicies durch, beide verbinden Pods über Nodes hinweg, beide sind weit verbreitet. Die Unterschiede liegen in Details, die erst im Betrieb auffallen: welcher Datenpfad läuft, welche Regeln und Flow-Daten im Open-Source-Umfang enthalten sind, welcher Kernel nötig ist und wie aufwendig ein späterer Wechsel wird. Dieser Vergleich stützt sich ausschließlich auf die Dokumentation der Projekte (Cilium 1.20.4, Calico Open Source 3.33), jede Aussage mit Link. Stand Oktober 2026.

Ein CNI-Plugin ist in jedem Cluster Pflicht: Es implementiert das Kubernetes-Netzwerkmodell, vergibt Pod-Adressen und verbindet Pods über Nodes hinweg. Ob es zusätzlich NetworkPolicies durchsetzt, hängt vom Plugin ab.

Inhaltsverzeichnis

• Kurzfassung
• Grunddaten im Vergleich
• Funktionen im Open-Source-Umfang
• Datenpfad: eBPF als Standard oder als Option
• Policies: ein gemeinsamer Standard, unterschiedliche Erweiterungen
• Betrieb: Kernel, Ports und Versionspflege
• Der Wechsel im laufenden Cluster
• Entscheidungstabelle: wann welches CNI
• Stand und Methodik
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides
• Quellen

Kurzfassung

• Die Standard-NetworkPolicy funktioniert auf beiden gleich. Wer Default-Deny und Freigaben nach Labels braucht, braucht keinen Wechsel des CNI.
• Im Open-Source-Umfang bringt Cilium Regeln nach Domainnamen und L7, Hubble, Cluster Mesh, einen Egress-Gateway und IPsec mit. Die Feature-Matrix der Calico-Dokumentation führt Regeln nach Domainnamen, Application-Layer-Policy, Cluster Mesh und Egress-Gateway unter Cloud und Enterprise. HTTP-Regeln beschreibt die Open-Source-Dokumentation nur über die Istio-Integration.
• Calico bietet mehrere Datenpfade (iptables, eBPF, nftables, VPP, Windows), Cilium setzt auf eBPF. Beide verlangen Linux 5.10 oder neuer.
• Ein CNI-Wechsel im laufenden Cluster ist eine Migration und keine Einstellung.

Grunddaten im Vergleich

Funktionen im Open-Source-Umfang

Die Tabelle zeigt, was die jeweilige Dokumentation im freien Umfang beschreibt. Für Calico gilt die Feature-Matrix mit den Spalten Open Source, Cloud und Enterprise. Kommerzielle Editionen sind nicht Teil des Vergleichs.

Datenpfad: eBPF als Standard oder als Option

Cilium arbeitet auf eBPF: Policies und Identitäten werden im Kernel durchgesetzt, Service-Verbindungen werden am Socket umgeschrieben und können kube-proxy vollständig ersetzen. Der Ersatz ist zuzuschalten: Der Helm-Standard ist kubeProxyReplacement=false. Der Overlay läuft standardmäßig über VXLAN, alternativ gibt es Geneve und Native Routing.

Calico führt eBPF als eine von mehreren Wahlmöglichkeiten. Der Standard ist der iptables-Datenpfad, der laut Dokumentation auf Kompatibilität mit kube-proxy und eigenen iptables-Regeln ausgelegt ist, der eBPF-Datenpfad auf Leistung und Latenz. Dieselbe Seite hält fest, dass iptables bei Policies mit einer großen Zahl von IP-Adressen (ipsets) im Micro-Benchmark in vielen Fällen besser ist als eBPF. Der eBPF-Datenpfad unterstützt weder SCTP noch den etcd-Datastore und keine Cluster mit gemischten eBPF- und Standard-Nodes. Zusätzlich beschreibt Calico einen nftables-Datenpfad, einen VPP-Datenpfad und einen Windows-Datenpfad.

Belastbare Durchsatz- oder Latenzvergleiche liefern die Dokumentationen nicht, und dieser Artikel nennt keine. Wer die Frage entscheiden muss, misst mit der eigenen Last auf der eigenen Hardware.

Policies: ein gemeinsamer Standard, unterschiedliche Erweiterungen

Der portable Teil ist die Kubernetes-NetworkPolicy. Eine Default-Deny-Regel für eingehenden Verkehr sieht auf beiden Plugins gleich aus (Beispiel der Kubernetes-Dokumentation):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress

Ohne ein Plugin, das NetworkPolicies durchsetzt, hat dieses Objekt keine Wirkung. Ein Pod ohne Policy ist standardmäßig nicht isoliert. Standard-Policies kennen nur Allow-Regeln und wirken additiv, eine Reihenfolge gibt es nicht.

Darüber hinaus unterscheiden sich die Erweiterungen. Cilium kennt Deny-Regeln, Regeln nach Domainnamen und L7-Regeln für HTTP und gRPC sowie ein eigenes Default-Verhalten: Die erste Regel, die einen Endpoint auswählt, schaltet ihn pro Richtung in Default-Deny, der Modus lässt sich auf „always“ oder „never“ stellen. Calico ordnet Regeln in Tiers mit festgelegter Rangfolge, kennt die Aktionen Allow, Deny, Log und Pass und erlaubt Staged Policies zum Testen. Tiers sind im Open-Source-Umfang enthalten. Die Kubernetes-API ClusterNetworkPolicy (noch v1alpha2) mit Admin- und Baseline-Ebene setzen beide um, Cilium ab 1.20 nach Aktivierung, Calico 3.33 über zwei feste Tiers. Das Plattform-Team kann damit Regeln setzen, die Anwendungsteams nicht übersteuern.

Die Cilium-Dokumentation warnt selbst: Bei mehreren gleichzeitig genutzten Policy-Typen lässt sich die Gesamtmenge der erlaubten Verbindungen schwer überblicken, und es können unbeabsichtigte Freigaben entstehen. Ein Satz Standard-Policies als Basis und wenige Erweiterungen darüber bleiben nachvollziehbarer.

Betrieb: Kernel, Ports und Versionspflege

Kernel und Distribution. Beide Dokumentationen nennen Linux 5.10 oder neuer (Cilium, Calico). Cilium führt Ubuntu ab 20.04, Debian ab 10, RHEL ab 8.6 und Talos ab 1.5.0, Calico Ubuntu ab 20.04, RHEL ab 8, Debian ab 10 und Talos ab 1.6. Für einzelne Cilium-Funktionen gelten höhere Kernel, etwa netkit ab 6.8. Calico verlangt, dass NetworkManager die Calico-Schnittstellen nicht verwaltet und dass Firewalld oder andere iptables-Manager deaktiviert sind.

Ports zwischen den Nodes. Diese Freigaben gehören vor der Installation in die Firewall- und Security-Group-Planung:

Versionspflege. Das CNI läuft auf jedem Node, ein Upgrade betrifft den ganzen Cluster. Beide Projekte testen gegen begrenzte Kubernetes-Versionen (Tabelle oben). Stand 28.10.2026 ist Kubernetes 1.37 aktuell, Cilium 1.20 listet 1.33 bis 1.36, Calico 3.33 testet 1.35 bis 1.37. Vor jedem Kubernetes-Upgrade gehört deshalb die Kompatibilität des CNI in die Prüfung. Wie sich Versionsstand und Upgrade-Historie als Nachweis führen lassen, beschreibt Kubernetes NIS2 und ISO 27001: Nachweise.

Standard der Distributionen. RKE2 bündelt vier CNI-Plugins und nutzt Canal (Flannel für den Verkehr zwischen Nodes, Calico für den Verkehr innerhalb eines Nodes und für Policies) als Standard, Cilium und Calico sind wählbar. k3s liefert Flannel; für ein anderes CNI wird k3s mit --flannel-backend=none gestartet, zusätzlich wird --disable-network-policy empfohlen. Talos installiert Flannel und kann auf Cilium umgestellt werden, wie Talos Linux auf Proxmox installieren beschreibt.

Weitere Komponenten. Gateway API und Egress-Gateway setzen bei Cilium den kube-proxy-Ersatz voraus. Für Gateway-Listener nutzt Cilium Envoy, standardmäßig über TPROXY mit iptables, sodass die Nodes die nötigen Netfilter-Module bereitstellen müssen. Wie Gateway API und Ingress zusammenhängen, erklärt Gateway API vs. Ingress, die Adressvergabe für LoadBalancer-Services auf Bare Metal und Proxmox MetalLB vs. kube-vip.

Der Wechsel im laufenden Cluster

Ein CNI ist die früheste Entscheidung im Cluster, weil jeder Pod beim Start vom CNI konfiguriert wird. Wer wechselt, muss alle Pods des alten CNI neu starten. Die Cilium-Dokumentation beschreibt dazu eine Migration Node für Node: Zwei Overlays mit getrennten IP-Bereichen laufen parallel, Pods auf beiden Seiten bleiben erreichbar, bis alle Nodes umgestellt sind. Eine einfache Umstellung aller Nodes mit anschließendem Neustart würde das Netz in zwei Inseln teilen.

Laut Calico-Dokumentation lässt sich ein Cluster, der bereits ein anderes CNI nutzt, nicht auf Calico migrieren. Dokumentiert ist die Migration von Flannel oder Canal, entweder mit einem Live-Migrationswerkzeug oder durch den Neuaufbau eines Clusters. Daraus folgt für die Planung: Die Entscheidung gehört an den Anfang, und ein Wechsel braucht Testumgebung, Änderungsfenster und einen Rückweg.

Entscheidungstabelle: wann welches CNI

Stand und Methodik

• Stand: 28.10.2026. Cilium 1.20.4 (Release 23.10.2026, Dokumentation „stable“), Calico Open Source 3.33 (Release 3.33.0 vom 01.10.2026, Dokumentation „latest“), Kubernetes 1.37 als aktuelle Version.
• Quellen: ausschließlich Projekt-Dokumentation, GitHub-Repositories der Projekte und CNCF. Alle Seiten am 28.10.2026 abgerufen, Links in der Quellenliste.
• Calico-Umfang: Die Aussage „nicht enthalten“ bezieht sich auf die Spalte Open Source der Feature-Matrix in der Calico-Dokumentation 3.33. Wo die Open-Source-Dokumentation darüber hinaus etwas beschreibt (HTTP-Regeln über Istio, IPsec mit VPP), ist das vermerkt. Kommerzielle Editionen und Angebote Dritter sind nicht bewertet.
• CNCF-Status Calico: Eintrag „Project Calico“ im CNCF-Landscape (landscape.yml) ohne Feld project, im Gegensatz zu Cilium mit project: graduated.
• Nicht enthalten: Durchsatz- und Latenzmessungen, Service-Mesh-Vergleich, Vergleich mit Flannel und Cloud-spezifischen CNIs.
• Beta und Preview: Funktionen mit diesem Status (ztunnel, L2 Announcements, Whisker) sind in den Tabellen gekennzeichnet. Vor dem Einsatz in Produktion ist ihr Stand zu prüfen.

Unser Vorgehen bei WZ-IT

1. Anforderungen klären. Policies (Standard oder L7/Domainnamen), Flow-Nachweise, Verschlüsselung, Gateway API, Multi-Cluster, Windows, Kernel und Distribution bestimmen die Wahl, nicht die Verbreitung des Projekts.
2. Entscheiden nach der Tabelle. Die CNI-Wahl fällt beim Cluster-Aufbau, weil ein späterer Wechsel eine Migration ist. Bei Kubernetes-Netzwerk und Secure Access gehören CNI und Network Policies mit Default-Deny, notwendigen Flows und Netzwerk-Transparenz zum Umfang.
3. Im Betrieb pflegen. Im Betrieb von Kubernetes gehört das CNI zu den Add-ons: Upgrades laufen als geplante Änderung mit Kompatibilitätsprüfung gegen die Kubernetes-Version. Managed Kubernetes kostet ab 590 € je Cluster und Monat netto inklusive drei Worker-Nodes. Monitoring erfolgt 24/7, die Reaktion auf P1-Incidents erfolgt entsprechend Service Level.
4. Einzelfragen klären. Fragen zur CNI-Auswahl oder zu einem Wechsel lassen sich ohne Vertrag über den Support klären, 120 € je Stunde netto. Stand Oktober 2026.

Private Zugänge zur Cluster-API und zu internen Diensten sind eine eigene Schicht über dem CNI: Kubernetes privat über NetBird erreichen. NetBird ersetzt das CNI nicht.

Weiterführende Guides

• Gateway API vs. Ingress: Eintrittspunkt in den Cluster, Rollenmodell und Controller-Auswahl.
• MetalLB vs. kube-vip: Load Balancing auf Bare Metal und Proxmox.
• Kubernetes privat über NetBird erreichen: Cluster-API und interne Dienste ohne öffentliche Exposition.
• Kubernetes NIS2 und ISO 27001: Nachweise: welche Nachweise der Cluster liefert, darunter Netzwerk-Richtlinien und Flow-Daten.
• Talos Linux auf Proxmox installieren: CNI-Wahl vor dem Bootstrap.
• k3s vs. RKE2 vs. Talos: welche Distribution zu welchem Betriebsmodell passt.

CNI auswählen, Policies einführen oder einen Wechsel planen: Kubernetes Netzwerk & Secure Access mit WZ-IT.

Quellen

Abruf aller Quellen am 28.10.2026.

• Cilium 1.20.4: Systemvoraussetzungen, Einführung, Network Policy, Policy-Sprache und Policy-Einführung, kube-proxy-Ersatz, Kubernetes-Kompatibilität
• Cilium 1.20.4: Hubble und Hubble Exporter, Verschlüsselung, Gateway API, Cluster Mesh, Egress-Gateway
• Cilium 1.20.4: BGP Control Plane, LB IPAM, Migration zu Cilium
• Cilium: Repository und README, Release 1.20.4, CNCF-Projektseite
• Calico Open Source 3.33: About Calico mit Feature-Matrix, Systemvoraussetzungen, eBPF-Datenpfad und eBPF-Einsatzfälle
• Calico Open Source 3.33: Policy-Tiers, GlobalNetworkPolicy, WireGuard, Flow-Logs und Whisker, Application-Layer-Policy mit Istio, IPsec mit VPP
• Calico Open Source 3.33: Ingress Gateway, Service-IPs per BGP, Migration von Flannel
• Calico: Repository und README, Release 3.33.0
• CNCF Landscape (landscape.yml)
• Kubernetes: Network Plugins, Network Policies, Patch Releases
• RKE2: Basic Network Options, K3s: Basic Network Options

Angebot zum Thema: Cilium und Network Policies