TL;DR

Calico setzt auf bewährte iptables-Regeln und BGP-Routing, Cilium nutzt eBPF im Linux-Kernel für höhere Performance und tiefere Observability. Calico ist einfacher aufzusetzen und hat die längere Track-Record. Cilium bietet mit Hubble ein eingebautes Netzwerk-Monitoring und skaliert besser bei vielen Network Policies. Die Wahl hängt vom Cluster-Umfang und den Anforderungen an Observability ab.

Calico vs Cilium: Welches CNI für deinen Cluster?

Die Wahl des CNI-Plugins bestimmt, wie Pods kommunizieren, wie Network Policies durchgesetzt werden und welche Debugging-Tools dir zur Verfügung stehen. Calico und Cilium sind die zwei dominanten Open-Source-Optionen — aber sie funktionieren grundlegend unterschiedlich.

Architektur im Überblick

Calico verwendet Linux-iptables für Paketfilterung und unterstützt BGP für Routing zwischen Nodes. Das ist erprobt und vorhersagbar. Cilium dagegen lädt eBPF-Programme direkt in den Linux-Kernel. Pakete werden verarbeitet, bevor sie den normalen Netzwerk-Stack durchlaufen.

# Calico-Architektur prüfen (nach Installation)
kubectl get pods -n calico-system
kubectl get ippools.crd.projectcalico.org -o yaml

# Cilium-Architektur prüfen
kubectl get pods -n kube-system -l k8s-app=cilium
cilium status

Der Unterschied zeigt sich besonders bei der Skalierung: iptables-Regeln wachsen linear mit der Anzahl der Services und Policies. eBPF-Maps dagegen bieten O(1)-Lookups, unabhängig von der Regelanzahl.

Installation

Calico mit Helm installieren

# Tigera Operator installieren
helm repo add projectcalico https://docs.tigera.io/calico/charts
helm repo update

kubectl create namespace tigera-operator

helm install calico projectcalico/tigera-operator \
  --namespace tigera-operator \
  --set installation.cni.type=Calico \
  --set installation.calicoNetwork.ipPools[0].cidr=10.244.0.0/16 \
  --set installation.calicoNetwork.ipPools[0].encapsulation=VXLAN

# Status prüfen
kubectl rollout status daemonset calico-node -n calico-system --timeout=120s

Cilium mit Helm installieren

helm repo add cilium https://helm.cilium.io/
helm repo update

helm install cilium cilium/cilium \
  --namespace kube-system \
  --set ipam.mode=kubernetes \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true \
  --set kubeProxyReplacement=true

# Cilium CLI für Status-Checks
cilium status --wait

Cilium kann mit kubeProxyReplacement=true den kube-proxy komplett ersetzen. Das eliminiert iptables-basiertes Service-Routing und verbessert die Latenz bei vielen Services.

Network Policies im Vergleich

Beide CNIs unterstützen Standard-Kubernetes-NetworkPolicies. Die Syntax ist identisch — der Unterschied liegt in den erweiterten Features.

Standard NetworkPolicy (funktioniert mit beiden)

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-allow-frontend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

Calico: GlobalNetworkPolicy

Calico bietet Cluster-weite Policies über ein eigenes CRD:

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: deny-external-egress
spec:
  selector: env == 'production'
  types:
    - Egress
  egress:
    - action: Allow
      destination:
        selector: all()
    - action: Deny
      destination:
        notNets:
          - 10.0.0.0/8

Cilium: CiliumNetworkPolicy mit L7-Filtering

Cilium kann Traffic auf Layer 7 filtern — zum Beispiel nur bestimmte HTTP-Pfade erlauben:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-l7-policy
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: api-gateway
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: GET
                path: "/api/v1/.*"

Vergleichstabelle

Observability: Hubble vs Calico-Metriken

Ciliums größter Vorteil ist Hubble. Es erfasst jeden Netzwerk-Flow im Cluster und bietet eine grafische UI dazu.

# Hubble CLI installieren
export 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 zu Hubble Relay
kubectl port-forward -n kube-system svc/hubble-relay 4245:80 &

# Live-Flows beobachten
hubble observe --namespace production
hubble observe --verdict DROPPED --last 50

Bei Calico beschränkt sich das Monitoring auf Prometheus-Metriken und Felix-Logs:

# Calico-Felix-Metriken aktivieren
kubectl patch felixconfiguration default \
  --type merge \
  --patch '{"spec":{"prometheusMetricsEnabled": true}}'

# Policy-Denies in den Logs finden
kubectl logs -n calico-system -l k8s-app=calico-node | grep -i denied

Wann welches CNI?

Calico wählen, wenn:

• Der Cluster auf älteren Kernels läuft (< 4.19)
• BGP-Peering mit physischer Netzwerk-Infrastruktur nötig ist
• Ein schlankes, bewährtes Setup reicht
• Das Team keine eBPF-Erfahrung hat

Cilium wählen, wenn:

• L7-Network-Policies gebraucht werden
• Netzwerk-Observability (Hubble) wichtig ist
• kube-proxy ersetzt werden soll
• Der Cluster viele Services hat (> 500) und iptables-Skalierung ein Problem wird

FAQ

Kann ich von Calico zu Cilium migrieren?

Ja, aber es erfordert eine Downtime oder einen Rolling-Migration-Ansatz. Cilium bietet ein offizielles Migrationstool. In der Praxis ist ein neuer Cluster mit Cilium oft einfacher als eine In-Place-Migration.

Unterstützt Calico auch eBPF?

Ja, seit Calico 3.13 gibt es einen eBPF-Dataplane-Modus. Dieser ist allerdings weniger ausgereift als Ciliums eBPF-Implementierung und bietet nicht das gleiche Feature-Set wie Hubble.

Welches CNI hat bessere Performance?

In Benchmarks zeigt Cilium mit eBPF niedrigere Latenz und höheren Durchsatz, besonders bei vielen Network Policies. Bei kleinen Clustern mit wenigen Policies ist der Unterschied vernachlässigbar.

Funktionieren beide CNIs mit Service Meshes?

Ja. Calico arbeitet problemlos mit Istio und Linkerd zusammen. Cilium bietet mit Cilium Service Mesh eine eigene, Sidecar-freie Alternative, die eBPF statt Envoy-Proxies nutzt.

Welches CNI nutzen Managed-Kubernetes-Anbieter?

GKE Dataplane v2 basiert auf Cilium. AKS bietet sowohl Calico als auch Cilium als Option. EKS nutzt standardmäßig das AWS VPC CNI, unterstützt aber Calico für Network Policies.