Cilium vs Calico: eBPF vs iptables im CNI-Vergleich

TL;DR

Cilium nutzt eBPF statt iptables und bietet L7-Visibility, Hubble Observability und bessere Performance bei grossen Clusters. Calico ist ausgereifter, einfacher zu debuggen und reicht fuer die meisten Setups. Ab 500+ Services lohnt sich der Umstieg auf Cilium.

Das Kernproblem: iptables skaliert nicht linear

Jeder Kubernetes-Service erzeugt iptables-Regeln auf jedem Node. Bei 100 Services kein Problem. Bei 2.000 Services hat jeder Node 40.000+ Regeln. Jedes Paket wird sequentiell gegen diese Regeln geprueft. Updates dauern Sekunden statt Millisekunden.

Calico nutzt iptables (optional eBPF seit v3.13). Cilium hat eBPF von Anfang an als Kern-Architektur. Das ist der fundamentale Unterschied -- alles andere folgt daraus.

Architektur-Vergleich

Calico

Calico laeuft als DaemonSet mit zwei Hauptkomponenten: calico-node (Felix + BIRD) auf jedem Node und calico-kube-controllers fuer die Kubernetes-API-Integration. Felix programmiert iptables-Regeln (oder eBPF-Maps im eBPF-Modus). BIRD verteilt Routen per BGP.

# Calico-Installation via Operator
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.29.1/manifests/tigera-operator.yaml

cat <<EOF | kubectl apply -f -
apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
  name: default
spec:
  calicoNetwork:
    ipPools:
    - cidr: 10.244.0.0/16
      encapsulation: VXLANCrossSubnet
      natOutgoing: Enabled
    linuxDataplane: Iptables
EOF

Cilium

Cilium deployed einen Agent als DaemonSet plus den Cilium-Operator. Der Agent kompiliert eBPF-Programme und laedt sie in den Kernel. Kein BIRD, kein iptables (im kube-proxy-replacement-Modus).

# Cilium-Installation via Helm
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium \
  --version 1.16.5 \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost="API_SERVER_IP" \
  --set k8sServicePort="6443" \
  --set hubble.enabled=true \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true

Performance

Getestet auf einem 10-Node-Cluster (Bare Metal, 25 Gbit NICs, Kernel 6.6):

Die Rohperformance-Unterschiede sind bei kleinen Clusters marginal. Der Service-Update-Zeitraum ist der entscheidende Faktor bei Skalierung.

NetworkPolicies

Beide unterstuetzen Standard-Kubernetes-NetworkPolicies. Die Unterschiede liegen in den erweiterten Policies.

Calico NetworkPolicy

Calico bietet GlobalNetworkPolicy (clusterweite Regeln) und NetworkSet (IP-Gruppen). L3/L4-Filtering ist solide, L7 nur mit Calico Enterprise.

# Calico: Namespace-Isolation mit globalem Deny
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: default-deny
spec:
  namespaceSelector: has(isolation)
  types:
  - Ingress
  - Egress
  egress:
  - action: Allow
    protocol: UDP
    destination:
      ports: [53]
      selector: k8s-app == 'kube-dns'

Cilium NetworkPolicy

CiliumNetworkPolicy kann L7-Traffic filtern: HTTP-Methoden, Pfade, Header, DNS-Domains, Kafka Topics, gRPC-Methoden. Das laeuft direkt im eBPF-Programm.

# Cilium: L7-HTTP-Filtering
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-access
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: GET
          path: "/api/v1/.*"
        - method: POST
          path: "/api/v1/orders"
  egress:
  - toFQDNs:
    - matchName: "api.stripe.com"
    toPorts:
    - ports:
      - port: "443"

Der L7-Filter ist ein Killer-Feature. Ohne Cilium braeuchtet ihr dafuer einen Service Mesh wie Istio.

Observability: Hubble vs Calico Enterprise

Hubble (Cilium, Open Source)

Hubble ist in Cilium integriert. Es zeigt Netzwerk-Flows, Service-Maps und DNS-Queries in Echtzeit. Die Hubble UI visualisiert Abhaengigkeiten zwischen Services.

# Hubble CLI installieren
HUBBLE_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/hubble/master/stable.txt)
curl -L --remote-name-all https://github.com/cilium/hubble/releases/download/$HUBBLE_VERSION/hubble-linux-amd64.tar.gz
tar xzvf hubble-linux-amd64.tar.gz
sudo mv hubble /usr/local/bin/

# Port-Forward und Flows beobachten
cilium hubble port-forward &
hubble observe --namespace production

# Flows nach HTTP-Status filtern
hubble observe --namespace production --http-status 500

# Service-Map als DOT-Graph
hubble observe --namespace production -o dot > service-map.dot

Hubble liefert ohne Sidecar-Proxies das, wofuer ihr sonst Istio plus Kiali braeuchtet.

Calico Enterprise / Calico Cloud

Calico Open Source hat minimale Observability: calicoctl fuer Policy-Debugging, Flow-Logs nur ueber Calico Enterprise (kostenpflichtig).

Calico Enterprise bietet Flow Visualization, Compliance Reports und Threat Detection. Kostet aber signifikant -- erwartet 5-stellige Jahreslizenzkosten fuer groessere Clusters.

# Calico OSS: Policy-Debugging
calicoctl get networkpolicy -n production -o yaml
calicoctl node status

# Flow-Logs gibt es nur in Calico Enterprise
# Open Source: tcpdump oder eBPF-Tools manuell

Komplexitaet und Betrieb

Debugging

Calico (iptables-Modus) laesst sich mit Standard-Linux-Tools debuggen:

# iptables-Regeln anzeigen
iptables -t filter -L -n -v | grep cali
iptables -t nat -L -n -v | grep KUBE

# Routing pruefen
ip route | grep bird
calicoctl node status

Cilium braucht eigene Tools:

# Cilium-Status pro Node
kubectl exec -n kube-system ds/cilium -- cilium status
kubectl exec -n kube-system ds/cilium -- cilium endpoint list

# BPF-Maps inspizieren
kubectl exec -n kube-system ds/cilium -- cilium bpf ct list global | head -20
kubectl exec -n kube-system ds/cilium -- cilium bpf policy get <endpoint-id>

# Connectivity-Test
cilium connectivity test

eBPF-Debugging ist weniger intuitiv als iptables. Teams brauchen Einarbeitungszeit.

Kernel-Anforderungen

Aeltere RHEL 7/8 Systeme mit Kernel 3.10/4.18 koennen Cilium nicht nutzen. Calico laeuft dort problemlos.

Wann Cilium, wann Calico

Calico waehlen wenn

• Euer Cluster hat unter 500 Services
• Ihr braucht BGP-Peering mit physischen Routern
• Das Team kennt iptables und Linux-Networking
• Ihr nutzt aeltere Kernel-Versionen (RHEL 7/8)
• Budget fuer Calico Enterprise vorhanden (fuer Observability)

Cilium waehlen wenn

• Cluster mit 500+ Services oder hohem Throughput
• L7-NetworkPolicies ohne Service Mesh gebraucht werden
• Netzwerk-Observability mit Hubble gewuenscht
• WireGuard-Encryption fuer Pod-Traffic
• Service Mesh ohne Sidecars (sidecar-free via eBPF)

Migration Calico zu Cilium

Eine In-Place-Migration ist moeglich, aber nicht trivial. Der sicherste Weg:

1. Neuen Cluster mit Cilium aufsetzen
2. Workloads migrieren
3. NetworkPolicies in CiliumNetworkPolicy uebersetzen (Standard-K8s-Policies funktionieren unveraendert)
4. L7-Policies schrittweise ergaenzen

In-Place: Calico-DaemonSet entfernen, Cilium deployen, alle Pods neu starten. Kurze Netzwerk-Unterbrechung unvermeidbar.

FAQ

Kann ich Calico im eBPF-Modus nutzen statt Cilium?

Ja, seit Calico 3.13. Die Performance ist vergleichbar. Ihr verliert aber L7-Policies und Hubble. Calico-eBPF ist sinnvoll, wenn ihr Calico schon nutzt und nur die iptables-Skalierungsprobleme loesen wollt.

Ist Cilium schwerer zu betreiben als Calico?

Ja, die Lernkurve ist steiler. eBPF-Debugging erfordert neue Tools und Denkweisen. Nach 2-3 Wochen Einarbeitung ist der Unterschied aber gering. Hubble macht vieles einfacher als vergleichbare Calico-OSS-Tools.

Was ist mit Flannel oder Weave?

Flannel ist minimal und reicht fuer einfache Setups (K3s nutzt es als Default). Es hat keine NetworkPolicies. Weave wird nicht mehr aktiv entwickelt. Fuer neue Cluster: Calico oder Cilium.

Brauche ich noch kube-proxy mit Cilium?

Nein. Cilium ersetzt kube-proxy vollstaendig im kubeProxyReplacement=true-Modus. Das eliminiert eine Komponente und verbessert die Performance. Bei Calico bleibt kube-proxy meistens aktiv.

Wie hoch ist der Aufwand fuer eine Migration?

Plant 1-2 Tage fuer einen kleinen Cluster (unter 20 Nodes). Bei grossen Clusters mit vielen NetworkPolicies: 1-2 Wochen, inklusive Test und Policy-Konvertierung. Standard-Kubernetes-NetworkPolicies funktionieren auf beiden CNIs.

Steht bei euch eine CNI-Entscheidung oder Migration an? Ich unterstuetze bei Architektur-Review, Performance-Tests und der Umsetzung -- herstellerunabhaengig.

Weiterführende Artikel:

• Kubernetes Network Policies: Calico & Cilium Guide
• Kubernetes Network Security: Zero Trust umsetzen