Wer einen Kubernetes-Cluster aufbaut, muss früh eine grundlegende Entscheidung treffen: Welches CNI-Plugin (Container Network Interface) soll das Netzwerk verwalten? Die Wahl bestimmt, wie Pods kommunizieren, wie Netzwerk-Policies durchgesetzt werden und welche Observability-Features zur Verfügung stehen.

Calico und Cilium sind die zwei am häufigsten gewählten CNI-Plugins – und sie verfolgen dabei grundlegend unterschiedliche Ansätze. Während Calico auf bewährte iptables-Mechanismen setzt, nutzt Cilium das moderne eBPF-Framework im Linux-Kernel. Ich erkläre, was das in der Praxis bedeutet und wann welche Lösung die bessere Wahl ist.

Was sind CNI-Plugins?

Kubernetes selbst implementiert kein Netzwerk – es delegiert diese Aufgabe an CNI-Plugins. Die Container Network Interface-Spezifikation definiert, wie Plugins Netzwerkinterfaces für Pods erstellen, konfigurieren und entfernen. Ein CNI-Plugin ist für folgendes zuständig:

  • Pod-Networking: Jedem Pod eine IP-Adresse zuweisen und die Kommunikation zwischen Pods ermöglichen
  • Network Policies: Kubernetes-NetworkPolicy-Objekte umsetzen (welcher Pod darf mit welchem sprechen)
  • Node-to-Node-Routing: Sicherstellen, dass Pods auf unterschiedlichen Nodes miteinander kommunizieren können

Andere bekannte CNI-Plugins sind Flannel (sehr simpel, kein Policy-Support), WeaveNet (mittlerweile deprecated) und Multus (für Multi-CNI-Setups).

Was ist Calico?

Calico (heute Teil von Tigera) wurde 2016 erstmals veröffentlicht und gehört zu den ältesten und ausgereiftesten CNI-Plugins. Es nutzt primär BGP (Border Gateway Protocol) für Layer-3-Routing zwischen Nodes und iptables (oder ipvs) für Network-Policy-Durchsetzung und Service-Routing.

Stärken von Calico:

  • Sehr stabile, battle-tested Technologie mit jahrelangem Produktionseinsatz
  • Ausgezeichnete Dokumentation und große Community
  • Funktioniert auch ohne Overlay-Netzwerk (reines BGP-Routing)
  • Eigene Policy-Erweiterungen (GlobalNetworkPolicy, HostEndpoints)
  • Gut integrierbar mit Hardware-Routern über BGP-Peering
  • Geringer Ressourcenverbrauch im Normalbetrieb

Schwächen von Calico:

  • iptables-Skalierung hat Grenzen – bei mehr als 10.000 Services merkliche Latenz
  • Observability nur über externe Tools, keine eingebaute Flow-Inspektion
  • eBPF-Mode seit 2021 verfügbar, aber als Zweitimplementierung weniger ausgereift als Cilium
  • Keine nativen L7-Policies – HTTP-Filterung erfordert einen Service Mesh

Was ist Cilium?

Cilium wurde 2016 als Open-Source-Projekt gestartet und 2021 als CNCF-Graduated-Projekt aufgenommen. Es basiert auf eBPF (extended Berkeley Packet Filter) – einer Technologie, die Programme direkt im Linux-Kernel ausführt, ohne Kernel-Patches oder Module zu benötigen.

Stärken von Cilium:

  • eBPF ermöglicht deutlich höhere Performance als iptables – besonders bei vielen Services
  • Umfangreiche L7-Network-Policies (HTTP-Methods, gRPC-Calls, Kafka-Topics filterbar)
  • Eingebauter Observability-Layer: Hubble für Flow-Inspektion bis Layer 7
  • Kube-Proxy-Ersatz – kube-proxy kann komplett entfernt werden
  • Mutual TLS zwischen Pods ohne Sidecar-Proxy (leichtgewichtiger Service Mesh)
  • Bessere Skalierung bei sehr vielen Services (O(1) statt O(n) Lookup)

Schwächen von Cilium:

  • Höherer Ressourcenverbrauch als Calico (besonders RAM)
  • Kernel-Anforderung: ≥ 4.9 (empfohlen ≥ 5.10 für volle Features)
  • Komplexere Architektur mit mehr Komponenten
  • Steilere Lernkurve, besonders bei eBPF-Troubleshooting
  • Enterprise-Features (Tetragon, erweiterte Policy) kostenpflichtig

Vergleich: Performance – eBPF vs. iptables

Das ist der technisch interessanteste Unterschied. iptables wurde ursprünglich für Firewalls entwickelt, nicht für Kubernetes-Scale-Netzwerke. Jede Regel wird sequenziell durchsucht – bei 10.000 Services mit je 5 Regeln sind das 50.000 Regelprüfungen pro Paket.

eBPF löst das anders: Programme laufen direkt im Kernel-Space, nutzen Hashmaps für O(1)-Lookups und können Pakete direkt am Network Interface umleiten. Das messbare Ergebnis in Benchmarks:

SzenarioCalico (iptables)Cilium (eBPF)Unterschied
Service-Latenz (100 Services)0,12 ms0,08 ms~33 % schneller
Service-Latenz (10.000 Services)2,8 ms0,09 ms~31× schneller
CPU pro 1M Pakete/s~12 % Core~4 % Core~67 % weniger
Connection Setup (gleicher Node)0,8 ms0,3 ms~63 % schneller

Bei kleinen Clustern (unter 100 Services) sind die Unterschiede für Anwender kaum wahrnehmbar. Bei hoher Service-Dichte oder Microservices-Architekturen mit Hunderten von Services wird der eBPF-Vorteil jedoch real.

Vergleich: Network Policies

Beide Tools implementieren die Standard-Kubernetes-NetworkPolicy-API, bieten aber sehr unterschiedliche Erweiterungen:

Calico Extended Policies:

  • GlobalNetworkPolicy: Policy gilt clusterübergreifend oder für Host-Endpunkte
  • Erweiterte Egress- und Ingress-Rules mit CIDR-Ranges
  • DNS-basierte Policies (hostname-based)
  • Aber: nur Layer 3 und Layer 4 (IP und Port)

Cilium Network Policies:

  • L7-Policies: Kontrolle auf HTTP-Method-Ebene (GET /api/* erlauben, DELETE verboten)
  • gRPC-Method-Policies (spezifische gRPC-Aufrufe erlauben/blocken)
  • Kafka-Protokoll-Policies (Topics filtern)
  • DNS-basierte Policies (FQDN-basiert via DNS-Intercepting)
  • Mutual Authentication zwischen Identitäten ohne externen Service Mesh

Cilium kann also tatsächlich HTTP-Anfragen inspizieren und filtern – das ist ein fundamentaler Unterschied zu Calico. Mit Calico braucht man dafür einen vollständigen Service Mesh wie Istio oder Linkerd.

Vergleich: Observability mit Hubble

Calico bietet selbst kaum Observability. Man braucht externe Tools für Netzwerkfluss-Sichtbarkeit:

  • Prometheus-Metriken (über calico-node exportiert)
  • Netzwerkflüsse nur über externes Flow-Logging oder Kubernetes Audit-Logs einsehbar

Cilium + Hubble ist hier kategorial besser. Hubble ist der eingebaute Observability-Layer:

  • Layer-3 bis Layer-7 Flowlogs (sieht HTTP-Requests, gRPC-Calls, DNS-Queries)
  • Web-UI und CLI für Flow-Inspektion in Echtzeit
  • Service Dependency Maps (welcher Service ruft wen mit welchen Methoden auf)
  • Prometheus-kompatible Metriken für Dashboards
  • Drop-Reasons: Warum wurde ein Paket geblockt – und durch welche Policy?

Mit Cilium + Hubble sieht man in einem Kubernetes-Cluster, welcher Pod welche HTTP-Requests an wen sendet – ohne Sidecar-Proxies, ohne zusätzliche Instrumentierung.

Vergleich: Leichtgewichtiger Service Mesh

Cilium hat die einzigartige Fähigkeit, als leichtgewichtiger Service Mesh zu funktionieren:

  • Mutual TLS (mTLS) zwischen Pods ohne Envoy-Sidecars
  • Traffic Management über CiliumNetworkPolicy
  • Kein Sidecar-Modell – deutlich weniger Overhead als Istio oder Linkerd

Calico bietet dies nicht nativ. Für Service Mesh-Funktionen braucht man Calico in Kombination mit Istio oder Linkerd – was zwei zusätzliche komplexe Systeme bedeutet.

Wann Calico, wann Cilium?

Calico ist die richtige Wahl, wenn:

  • Du auf alten Kerneln laufen musst (unter 5.4)
  • Dein Cluster klein bis mittelgroß ist (unter 500 Nodes, unter 5.000 Services)
  • BGP-Integration mit physischer Netzwerkinfrastruktur erforderlich ist
  • Du maximale Stabilität und bewährte Technologie bevorzugst
  • Einfacheres Troubleshooting mit bekannten iptables-Tools wichtig ist
  • Baremetall- oder hybride Setups mit Router-Peering geplant sind

Cilium ist die richtige Wahl, wenn:

  • Du auf modernen Kerneln läufst (≥ 5.10 empfohlen für alle Features)
  • Hohe Service-Dichte oder viele Microservices (über 1.000 Services)
  • L7-Network-Policies benötigt werden (HTTP-Filterung ohne Service Mesh)
  • Eingebaute Observability mit Hubble gewünscht ist
  • Service-Mesh-Funktionen ohne Sidecar-Overhead gewünscht werden
  • Neue Cluster ohne Legacy-Anforderungen aufgebaut werden

Fazit

Calico und Cilium sind beide exzellente CNI-Plugins, aber für unterschiedliche Szenarien:

Calico ist die sichere, konservative Wahl – ausgereifte Technologie, breite Kompatibilität, einfaches Troubleshooting. Für die meisten Self-Hoster und mittlere Unternehmen ohne extreme Service-Dichte völlig ausreichend.

Cilium ist die zukunftsgerichtete Wahl – eBPF macht echte Performance-Unterschiede bei Scale, Hubble bietet einzigartige Observability, und L7-Policies ermöglichen Sicherheitskonzepte, die Calico schlicht nicht kann.

Meine Empfehlung für neue Cluster: Cilium. Die Kernel-Anforderungen sind kein Problem mehr auf modernen Systemen, und die Observability- und Sicherheitsfeatures überwiegen die höhere Komplexität deutlich. Für bestehende Calico-Installationen lohnt sich die Migration, wenn L7-Policies oder Hubble konkrete Anforderungen erfüllen sollen.

Weiterführende Artikel

Verwandte Technologien im Techradar