Cilium vs Calico: Welches Kubernetes-CNI gehört in Ihren Produktionscluster?

Fast jeder Vergleich „Cilium vs Calico“, den Sie gelesen haben, folgt derselben Idee: Cilium ist das moderne eBPF-Projekt, Calico das ältere mit iptables. Heute stimmt das schlicht nicht mehr. Cilium 1.20 wurde im September angekündigt, Calico Open Source 3.33 erschien am 1. Oktober, und die beiden Projekte überschneiden sich inzwischen stärker, als sie sich unterscheiden. Calico hat eine eBPF-Dataplane und unterstützt inzwischen ebenfalls netkit-Pod-Devices. Beide setzen die neue Kubernetes-ClusterNetworkPolicy durch. Beide liefern eine Gateway-API-Implementierung mit.

Die ehrliche Frage lautet also nicht mehr „Welches ist schneller?“, sondern: Welches Policy-Modell, welche Betriebsbedingungen und welches Ökosystem holen Sie sich ins Haus – und wie schwer wird es, die Entscheidung später zu revidieren? Denn das CNI ist die eine Clusterkomponente, die man fast nie billig austauscht. Das ist der Vergleich, den ich gern gehabt hätte, bevor ich eines für eine Produktionsplattform ausgewählt habe: was jedes Projekt heute tatsächlich kann, was GKE, EKS und AKS schon für Sie entschieden haben, und welche Fallen erst bei einer Migration sichtbar werden.

Die kurze Antwort

Wenn Sie nur einen Abschnitt lesen, dann diesen.

• Cilium, wenn alle Nodes Linux mit aktuellem Kernel sind und Sie anwendungsbewusste Sicherheit im Open-Source-Projekt wollen: L7-Regeln für HTTP, gRPC und Kafka, DNS-basierter Egress (toFQDNs), Flow-Observability mit Hubble, eingebaute Gateway API und Multi-Cluster-Netzwerk per Cluster Mesh. Auf GKE Dataplane V2 und Azure CNI Powered by Cilium betreiben Sie es ohnehin schon.
• Calico, wenn der Cluster heterogen oder fest mit der physischen Infrastruktur verbunden ist: Windows-Nodes, BGP-Peering mit Top-of-Rack-Switches, ältere Kernel, die eine iptables- oder nftables-Dataplane brauchen, VMs und Bare-Metal-Hosts unter derselben Policy, oder viele Teams, die Policy-Tiers mit klarer Rangfolge benötigen.
• Bewusst keines von beiden auf EKS, solange es keinen Grund gibt: Das Amazon VPC CNI ist das einzige CNI, das Amazon auf EC2-Nodes unterstützt, und es setzt Network Policies inzwischen nativ durch.

Der Rest des Artikels erklärt, warum – und wo jede dieser Empfehlungen an Grenzen stößt.

Was Cilium und Calico eigentlich sind

Cilium ist ein eBPF-basiertes Projekt für Netzwerk, Sicherheit und Observability in Kubernetes, gestartet von den Gründern von Isovalent. Es kam 2021 zur CNCF und ist seit Oktober 2023 ein Graduated-Projekt. Um das CNI herum liegen Hubble für Flow-Observability, eine eingebaute Gateway-API-Implementierung und Cluster Mesh für Multi-Cluster-Netzwerke.

Calico wird von Tigera entwickelt und gepflegt. Calico Open Source ist der freie Kern, der über Clouds und Distributionen hinweg läuft; Calico Cloud und Calico Enterprise sind die kommerziellen Editionen mit Funktionen wie DNS-Policies, Egress-Gateways und Multi-Cluster-Verwaltung. Calico reicht außerdem über Kubernetes-Pods hinaus zu VMs, Bare-Metal-Hosts und OpenStack.

Beide sind Open Source, beide laufen in sehr großem Maßstab produktiv, und hinter beiden steht ein kommerzielles Unternehmen. Das zählt weniger für die Funktionen als für den Support: Prüfen Sie, zu welcher Edition eine Funktion gehört, bevor Sie damit planen.

Was ein CNI tatsächlich entscheidet (und warum die Wahl klebt)

Ein Container-Network-Interface-Plugin ist nicht nur „das Ding, das Pods eine IP gibt“. In einem Produktionscluster verantwortet es vier Aufgaben:

1. IP-Adressverwaltung – aus welchem Bereich die Pod-Adresse stammt und ob dieser Bereich außerhalb des Clusters routbar ist.
2. Konnektivität – Overlay (VXLAN, Geneve, IP-in-IP) oder natives Routing, und ob die Nodes BGP mit dem Netz sprechen.
3. Network Policy – Kubernetes-NetworkPolicy (und oft eine reichhaltigere eigene CRD) in Paketfilterregeln auf jedem Node übersetzen.
4. Service-Load-Balancing – optional kube-proxy ersetzen, sodass Traffic an eine ClusterIP in der Dataplane des CNI statt in iptables-Ketten übersetzt wird.

Weil das CNI den Adressplan und die Dataplane besitzt, heißt ein Austausch: jeden Pod neu adressieren. Die Plattformen wissen das und frieren die Entscheidung ein. GKE schreibt, dass Dataplane V2 „nur beim Erstellen eines neuen Clusters aktiviert werden kann“. RKE2 unterstützt keinen Wechsel des primären CNI nach dem ersten Start. Behandeln Sie diese Entscheidung wie die Wahl einer Datenbank-Engine: Migrieren geht, aber es kostet.

Architektur: Identitäten in eBPF-Maps vs. Policy-Engine mit austauschbaren Dataplanes

Der tiefste Unterschied zwischen den Projekten ist nicht eBPF, sondern wie sie „wer darf mit wem sprechen“ abbilden.

Cilium leitet aus den Labels jedes Pods eine numerische Security Identity ab und legt Identitäten, Endpunkte, Services und Policies in eBPF-Maps im Kernel ab. Kommt ein Paket an, schlägt ein eBPF-Programm die Quell-Identität nach, statt eine Liste von IP-Adressen auszuwerten. Dadurch ist die Policy unabhängig vom Pod-Churn, und Cilium kann jedem Flow reichhaltige Metadaten für Hubble mitgeben. Der Preis: Identitäten sind endlich. Microsofts AKS-Dokumentation warnt, dass Workloads mit hohem Churn wie Spark-Jobs einen Cluster an das Limit von 65.535 Identitäten bringen können, und empfiehlt, volatile Labels aus der Identitätsberechnung auszuschließen.

Calico ist um Felix herum gebaut, einen Agenten auf jedem Node, der Policies aus Labels und Selektoren berechnet und in die gewählte Dataplane schreibt: iptables, nftables, eBPF, Windows oder VPP. BGP-Routing übernahm historisch BIRD – deshalb passt Calico so natürlich in Netze, die schon BGP sprechen. In 3.33 programmiert standardmäßig Felix statt BIRD die Cluster-Routen für IP-in-IP-Pools; die Programmierung dieser Routen über BIRD ist abgekündigt, die Entfernung ist für 3.35 geplant.

Cilium ist eine eBPF-Dataplane mit einem Policy-Modell obendrauf. Calico ist ein Policy-Modell mit mehreren Dataplanes darunter. Die meisten praktischen Unterschiede in diesem Artikel folgen aus diesem einen Satz.

Dataplanes heute: eBPF überall, aber mit unterschiedlichen Notausgängen

So stehen die beiden nach den Herbst-Releases da:

Einige Zeilen verdienen einen zweiten Blick.

netkit. netkit ist ein neueres Linux-Netzwerkdevice, das veth-Paare für Container ersetzen soll: Das BPF-Programm wird Teil des Devices selbst, statt von außen an ein veth-Paar gehängt zu werden, was Overhead aus dem Pfad des Pods nimmt. Ursprünglich brauchte es Kernel 6.8. Die Ankündigung von Cilium 1.20 verweist auf netkit im Einsatz bei Meta und ByteDance; ByteDance berichtet von rund 10 % Gewinn. Ciliums neuer auto-Modus nimmt netkit, wenn der Kernel es unterstützt, sonst veth; Standard bleibt veth. Calico 3.33 geht einen kleineren Schritt: Sein CNI kann über die optionale Einstellung device_type netkit-Pod-Devices anlegen (Kernel 6.7+, Standard bleibt veth), und die eBPF-Dataplane hängt sich auf diesen Devices standardmäßig über die netkit-API ein, anderswo über TCX.

Der iptables-Notausgang. Cilium hat keinen Fallback ohne eBPF. Gehören Kernel oder gehärtete Images zu Ihrer Flotte, in denen eBPF eingeschränkt ist, ist Calicos Fähigkeit, dieselbe Policy auf iptables oder nftables laufen zu lassen, ein echter Betriebsvorteil und kein Altlasten-Feature. 3.33 bringt zusätzlich optionales nftables-Flowtable-Offload, mit dem etablierte Verbindungen den Großteil des Regelwerks überspringen.

Footprint. Beide Projekte haben dieses Jahr abgespeckt: Das cilium-cni-Binary schrumpfte in 1.20 von 76 MB auf 16 MB, und Calico 3.33 konsolidiert die calico-node-Dienste – laut Tigera rund 200 MB weniger Speicher pro Node – und liefert ein einziges Image quay.io/calico/calico.

Auf einer Managed-Plattform kommen die Betriebsgrenzen vom Anbieter, nicht vom Projekt. Google dokumentiert zum Beispiel, dass der Dataplane-V2-Agent (anetd) auf Nodes mit vielen kurzlebigen TCP-Verbindungen zwei bis drei vCPUs verbrauchen kann, empfiehlt Keep-Alives und Connection Pooling und reserviert 0,25 % des Node-Speichers für die größten eBPF-Maps. Das ist kein Grund gegen eBPF, aber ein Grund, Ihr eigenes Traffic-Muster zu testen, statt irgendeinem Benchmark zu glauben – auch nicht denen der Hersteller.

Network Policy: Der Unterschied, den Sie wirklich spüren

Beide Projekte setzen Standard-Kubernetes-NetworkPolicy durch. Wenn Sie nur die schreiben, reicht jedes. Die Unterschiede beginnen, sobald Sie mehr brauchen als L3/L4-Regeln innerhalb eines Namespaces.

Cilium Network Policy: L7- und DNS-Regeln im Open-Source-Projekt

Cilium ergänzt CiliumNetworkPolicy und CiliumClusterwideNetworkPolicy. Die Kernfunktionen sind L7-Regeln – HTTP-Methoden und -Pfade, gRPC, Kafka – und DNS-basierter Egress. Diese Policy erlaubt nur dem Checkout-Service einen einzigen Endpunkt der Payments-API und lässt Payments genau einen externen Hostnamen erreichen:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: payments-api
  namespace: shop
spec:
  endpointSelector:
    matchLabels:
      app: payments
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: checkout
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: POST
                path: "/v1/charges"
  egress:
    # DNS erlauben, damit die FQDN-Regel unten die IPs lernen kann
    - toEndpoints:
        - matchLabels:
            "k8s:io.kubernetes.pod.namespace": kube-system
            "k8s:k8s-app": kube-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: ANY
          rules:
            dns:
              - matchPattern: "*"
    - toFQDNs:
        - matchName: "api.stripe.com"
      toPorts:
        - ports:
            - port: "443"
              protocol: TCP

Eine normale NetworkPolicy kann keine dieser Regeln ausdrücken. Das ist der Kern von Ciliums Reiz für Zero Trust im Cluster – und der Grund, warum GKE (FQDN-Network-Policies) und AKS (FQDN-Filterung und L7-Policies über Advanced Container Networking Services) ihre Premium-Netzwerkfunktionen darauf aufbauen.

Calico Network Policy: Tiers und Governance im Open-Source-Projekt

Calicos Open-Source-Edition beantwortet eine andere Frage: Wer darf wen überstimmen? Policies liegen in geordneten Tiers. Ein Security-Team kann einen Tier mit hoher Priorität besitzen, den Anwendungsteams nicht umgehen können, und eine Pass-Aktion reicht die Entscheidung an den nächsten Tier weiter:

apiVersion: projectcalico.org/v3
kind: Tier
metadata:
  name: security
spec:
  order: 300
---
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: security.isolate-prod
spec:
  tier: security
  order: 100
  namespaceSelector: env == "prod"
  types:
    - Ingress
  ingress:
    - action: Deny
      source:
        namespaceSelector: env == "dev"
    - action: Pass

Dev erreicht Prod nie, egal was ein Anwendungsteam im eigenen Namespace schreibt; alles andere geht an den Default-Tier, in dem die normalen Kubernetes-Policies liegen. Dazu kommen Staged Policies – vorab sehen, was eine Policy erlauben oder blockieren würde, bevor sie greift – und Host Endpoints, die Nodes, VMs und Bare-Metal-Server unter dieselbe labelbasierte Policy stellen. Zusammen ist das ein starker Werkzeugkasten für Plattformteams.

Was Calico Open Source nicht enthält, sind DNS-basierte Policies: Tigeras eigene Feature-Matrix führt DNS/FQDN-Policies, Egress-Gateways und Cluster Mesh als Funktionen von Calico Cloud und Calico Enterprise. Ist FQDN-Egress Pflicht und wollen Sie bei Open Source bleiben, kann allein das den Vergleich entscheiden.

Die gemeinsame Basis: ClusterNetworkPolicy

Die gute Nachricht: Die Kubernetes-Community schließt die Lücke für clusterweite Regeln. ClusterNetworkPolicy (policy.networking.k8s.io/v1alpha2) gibt Plattformteams einen Admin-Tier, der Namespace-Policies überstimmt, und einen Baseline-Tier, den Namespace-Policies überstimmen dürfen:

apiVersion: policy.networking.k8s.io/v1alpha2
kind: ClusterNetworkPolicy
metadata:
  name: deny-dev-to-prod
spec:
  tier: Admin
  priority: 10
  subject:
    namespaces:
      matchLabels:
        env: prod
  ingress:
    - name: deny-from-dev
      action: Deny
      from:
        - namespaces:
            matchLabels:
              env: dev

Cilium 1.20 unterstützt sie. Calico bildet sie direkt auf Tiers ab: Admin-Policies landen im eingebauten Tier kube-admin, Baseline-Policies in kube-baseline, und 3.33 unterstützt darin benannte Ports. Eine Warnung: EKS setzt dieselbe Idee nativ im VPC CNI um, aber unter einer eigenen API-Gruppe, networking.k8s.aws/v1alpha1. YAML zwischen Clouds zu kopieren ist weniger portabel, als der Name vermuten lässt.

Observability: Hubble vs. Whisker

Network Policies ohne Flow-Sichtbarkeit zu debuggen ist Raten. Deshalb wiegt dieser Punkt mehr, als er in einer Feature-Liste aussieht.

Ciliums Hubble ist die ausgereifteste Open-Source-Antwort: Sichtbarkeit pro Flow mit Quell- und Ziel-Identität, L7-Metadaten, wo eine L7-Policy greift, und Policy-Verdicts. In 1.20 kann Hubble zudem Audit-Verdicts mit der auslösenden Policy verknüpfen – „Was würde brechen, wenn ich das durchsetze?“ wird damit eine Frage, die Sie mit Daten beantworten. Auf Managed-Plattformen taucht dieselbe Idee als GKE-Dataplane-V2-Observability mit Network-Policy-Logging und als Container Network Observability in AKS auf.

Calicos Whisker ist eine Web-Konsole für Flow-Logs, gespeist von einem Flow-Aggregator und gestützt auf eine Flow-Logs-API – beides in 3.33 noch eine Technology Preview. Die Aufbewahrung in der Open-Source-Edition ist In-Memory; längere Aufbewahrung, Dashboards und der Service-Graph gehören zu den kommerziellen Editionen. Calicos eigentliche Observability-Stärke sind die Staged Policies: Sie sehen die Wirkung einer Policy-Änderung auf echte Flows, bevor irgendetwas durchgesetzt wird.

Ist Observability Ihr Haupttreiber, liegt Cilium im Open-Source-Bereich heute vorn. Ist Ihre größte Sorge, mit einer Policy-Änderung die Produktion zu brechen, ist Calicos Staged-Workflow das direktere Werkzeug.

Verschlüsselung und mTLS

Beide Projekte verschlüsseln Pod-zu-Pod-Traffic zwischen Nodes mit WireGuard – der einfache Standard für Anforderungen wie „alles im Transit verschlüsseln“. Cilium unterstützt zusätzlich IPsec.

Die interessanteste neue Entwicklung liegt bei Cilium: Sidecar-loses Mutual TLS mit ztunnel, gemeinsam von Microsoft und Isovalent gebaut. Es ist seit 1.19 Beta, nutzt TLS 1.3 über HBONE, wird pro Namespace mit dem Label io.cilium/mtls-enabled=true eingeschaltet und kann eine interne CA oder SPIRE verwenden. Anders als WireGuard oder IPsec zwischen Nodes verschlüsselt es auch Traffic zwischen Pods auf demselben Node. Ciliums ältere Mutual-Authentication-Funktion ist zugunsten dessen abgekündigt. Calicos Gegenstück ist die Integration mit dem Istio Ambient Mode, in 3.33 weiterhin eine Technology Preview.

Ein Compliance-Hinweis für regulierte Umgebungen: Calico 3.33 hat den FIPS-Modus entfernt. Hängt Ihr aktuelles Deployment davon ab, upgraden Sie nicht im Autopilot-Modus – klären Sie das mit Ihren Auditoren und mit Tigera, bevor Sie das nächste Release planen.

Gateway API: Beide liefern eine, unterschiedlich gebaut

Seit Ingress NGINX im März 2026 sein Lebensende erreicht hat, zählt die Nord-Süd-Frage mehr als sonst.

• Cilium implementiert die Gateway API nativ über seinen eingebauten Envoy-Proxy. 1.20 geht auf Gateway API v1.6: TCPRoute und UDPRoute (jetzt im Standard-Channel), ListenerSets, ein CORS-Filter, Redirects mit 303/307/308 und ein ExternalAuth-Filter, der eine Anfrage an einen Auth-Service weiterleitet und auf dessen Antwort 200, 302, 401 oder 403 reagiert.
• Calico liefert das Calico Ingress Gateway, ein mitgeliefertes Envoy Gateway – in 3.33 v1.9.1 mit Gateway-API-CRDs v1.6.1, was Kubernetes ab 1.33 voraussetzt.

Beide sind ein vernünftiger Ersatz für Ingress NGINX. Der architektonische Unterschied: Ciliums Gateway ist in das CNI eingebaut, das Sie ohnehin betreiben, Calicos ist ein separates Envoy-Gateway-Deployment, das Calico paketiert und verwaltet. Auf GKE verwenden Sie meist ohnehin Googles eigenen Gateway-Controller – siehe GKE Gateway API statt Ingress NGINX für diese Entscheidung.

Was GKE, EKS und AKS schon für Sie entschieden haben

Auf einem Managed Service ist „Cilium vs Calico“ meist eine kleinere Frage, als es scheint.

GKE. Dataplane V2 basiert auf Cilium, läuft als DaemonSet anetd, ist Standard für neue Autopilot-Cluster und Googles empfohlenes Netzwerk-Plugin für alle Cluster. Network Policy ist immer aktiv, Network-Policy-Logging ist eingebaut, und Services laufen dort ohne kube-proxy. Die ältere Dataplane basiert auf Calico und ist nur auf Standard-Clustern verfügbar; das Aktivieren erstellt die Nodes neu und kostet in kube-system rund 128 MB Speicher und 300 Millicores CPU. Zwei Grenzen sollten Sie kennen: Dataplane V2 lässt sich auf bestehenden Clustern nicht aktivieren, und Cluster mit der CRD CiliumNetworkPolicy sind auf 1.000 Nodes begrenzt, während CiliumClusterwideNetworkPolicy bis 5.000 unterstützt. Außerdem unterstützt GKE keine eigenen eBPF-Programme auf Dataplane-V2-Nodes – eine echte Einschränkung, falls Sie eBPF-basierte Werkzeuge ergänzen wollten. Das größere Härtungsbild zeigt die Secure-by-Default-GKE-Referenzarchitektur.

EKS. Das Amazon VPC CNI ist das einzige CNI, das Amazon EKS auf EC2-Nodes unterstützt; Fargate läuft nur mit dem VPC CNI, und EKS Auto Mode unterstützt keine alternativen CNI- oder Network-Policy-Plugins. Ab VPC CNI 1.21 setzt es Standard-Network-Policies und eine Admin-ClusterNetworkPolicy nativ durch. Cilium oder Calico können Sie trotzdem installieren – AWS führt Isovalent und Tigera als Partner –, empfiehlt dann aber kommerziellen Support oder eigene Expertise. Auf EKS Hybrid Nodes dagegen unterstützt Amazon die Kernfunktionen von Cilium und Calico. Eine scharfe Kante: Traffic von und zu Pods mit Security Groups for Pods unterliegt nicht der Calico-Policy, sondern nur den Security Groups.

AKS. Microsoft empfiehlt für Network Policies Azure CNI Powered by Cilium, die Standard-Netzwerkkonfiguration in AKS Automatic. Es läuft ohne kube-proxy, nur auf Linux, und unterstützt CiliumNetworkPolicy und CiliumClusterwideNetworkPolicy direkt; FQDN-Filterung, L7-Policies, WireGuard und Flow-Observability kommen über Advanced Container Networking Services. Calico wird nur für Standard-Kubernetes-Network-Policies unterstützt – andere Calico-Funktionen testet und unterstützt AKS nicht –, ist aber die Engine für Windows-Node-Pools. Da Azure Network Policy Manager seit dem 30. September 2026 auf Windows-Nodes nicht mehr unterstützt wird und auf Linux 2028 ausläuft, ist das AKS-Bild einfach: Cilium für Linux, Calico, wo Windows im Spiel ist.

Selbst betriebene Distributionen. k3s nutzt standardmäßig Flannel mit kube-router für Network Policies; für Cilium oder Calico starten Sie den Server mit --flannel-backend=none und --disable-network-policy und installieren dann das CNI. RKE2 liefert Canal (Standard – Flannel zwischen den Nodes, Calico für Policies), Cilium, Calico und Flannel mit. Nur Calico und Flannel unterstützen dort Windows-Nodes, und Canal wird auf Clustern mit Windows-Nodes nicht unterstützt. Wenn Sie die Distribution noch wählen, behandelt der Vergleich k3s vs k0s vs MicroK8s vs RKE2 diese Standards ausführlicher.

Auf GKE und AKS heißt „Cilium wählen“ meist: den Plattform-Standard akzeptieren. Die echte Entscheidung zwischen Cilium und Calico fällt auf selbst betriebenen Clustern, On-Prem, am Edge und überall dort, wo Windows-Nodes oder eine BGP-Fabric beteiligt sind.

Skalierung und Multi-Cluster

Beide Projekte betreiben sehr große Cluster; die Unterschiede liegen darin, wie sie Cluster miteinander verbinden.

Cilium Cluster Mesh ist Teil des Open-Source-Projekts: Es verbindet standardmäßig bis zu 255 Cluster, bietet clusterübergreifende Service Discovery und Policies, und 1.20 erklärt die Implementierung der Kubernetes Multi-Cluster Services API für stabil. Eine neue Policy-Entity cluster-mesh erlaubt Regeln für „jeden Workload im Mesh“, ohne Cluster einzeln aufzuzählen.

Calico geht netzwerkzentriert vor: Mit BGP lassen sich Cluster und physische Fabric so verbinden, dass Pod-IPs über sie hinweg routbar sind. Calicos verwaltetes Multi-Cluster-Produkt, Cluster Mesh, und die Multi-Cluster-Policy-Verwaltung gehören zu Calico Cloud und Calico Enterprise, nicht zur Open-Source-Edition.

Heißt die Anforderung „viele Cluster, ein Service- und Policy-Modell“ und wollen Sie bei Open Source bleiben, liegt Cilium vorn. Heißt sie „Pods als vollwertige Teilnehmer meines gerouteten Rechenzentrumsnetzes“, ist Calicos BGP-Erbe genau der Grund, warum es existiert.

Migration von Calico zu Cilium: Erst lesen, dann planen

Die meisten Teams, die beide vergleichen, betreiben bereits Calico und überlegen den Wechsel. Cilium dokumentiert einen Live-Migrationspfad, und der ist wirklich clever: Cilium im sekundären Modus mit eigenem Pod-CIDR, Cluster-Pool-IPAM und eigenem Encapsulation-Port installieren (das Beispiel nutzt VXLAN auf Port 8473), sodass beide Overlays parallel existieren und die Linux-Routingtabelle ihren Traffic trennt. Dann Node für Node: cordon und drain, Node labeln, damit eine CiliumNodeConfig Cilium seine CNI-Konfiguration schreiben lässt, Cilium-Agent neu starten, Node rebooten, prüfen, uncordon.

Lesen Sie dann den Abschnitt zu den Einschränkungen derselben Anleitung. Die Migration ist nicht mit BGP-basiertem Routing getestet und nicht mit einem bestehenden NetworkPolicy-Provider – und Ciliums eigene Policy-Durchsetzung muss während der Migration mit policyEnforcementMode: never laufen, weil sonst Traffic von noch nicht migrierten Pods verworfen werden könnte. Ein produktiver Calico-Cluster hat fast immer Policies, und viele On-Prem-Cluster nutzen BGP. Anders gesagt: Genau die Cluster, die diese Migration am ehesten wollen, sind die, mit denen sie nicht getestet wurde.

Eine pragmatische Reihenfolge:

1. Policies inventarisieren und übersetzen, mit besonderem Blick auf ipBlock-Regeln und Calico-Tiers, für die es in Cilium keine Eins-zu-eins-Entsprechung gibt.
2. Auf einem Klon proben, mit laufendem Konnektivitätsmonitor, wie es die Anleitung selbst dringend empfiehlt.
3. Entscheiden, ob ein Zeitfenster ohne Policies akzeptabel ist. Wenn nicht: einen neuen Cilium-Cluster bauen und Workloads per Blue/Green oder GitOps-gesteuerter Umschaltung umziehen.
4. Auf AKS das unterstützte In-Place-Upgrade der Dataplane von Azure CNI auf Cilium nutzen (kubenet-Cluster gehen zuerst auf Azure CNI Overlay). Auf GKE gibt es keinen In-Place-Weg zu Dataplane V2: Das ist ein neuer Cluster.

Stolperfallen, die Sie vor dem Upgrade kennen sollten

Calico 3.33

• eBPF auf Kernel 5.15 ist in 3.33 kaputt – eine bekannte Regression: Das Host-Endpoint-Programm ist über das Verifier-Limit gewachsen. Workaround: Kernel ab 6.8 oder vorerst 3.32. Das betrifft alle mit Ubuntu-22.04-Images, einschließlich des Standard-Node-Images von AKS für Kubernetes 1.25 bis 1.34.
• Der FIPS-Modus ist weg. Regulierte Deployments brauchen vor dem Upgrade einen Plan.
• Native v3-CRDs sind GA, der aggregierte API-Server ist abgekündigt. Das vereinfacht Installationen, ändert aber, wie Werkzeuge mit Calico-Ressourcen sprechen.
• Die Programmierung von IP-in-IP-Cluster-Routen über BIRD ist abgekündigt, die Entfernung ist für 3.35 geplant; Felix verwaltet diese Routen jetzt standardmäßig.

Cilium 1.20

• Die alte Mutual Authentication ist abgekündigt zugunsten von mTLS über ztunnel.
• cilium-dbg bgp-Befehle sind abgekündigt zugunsten neuer Shell-Befehle für die GoBGP-basierte Control Plane.
• Identity-Churn bleibt die klassische Skalierungsfalle: Labels mit hoher Kardinalität ausschließen, bevor sie den Identitätsraum erschöpfen.
• Auf GKE können andere eBPF-Werkzeuge mit Dataplane V2 kollidieren; Google dokumentiert einen Fall, in dem Microsoft Retina verhinderte, dass Pods Services erreichen.

Die Entscheidung in fünf Fragen

1. Betreiben Sie Windows-Nodes? Dann Calico, zumindest für diese Nodes. Cilium unterstützt Windows nicht.
2. Sind Sie auf GKE oder AKS? Nutzen Sie die Cilium-basierte Dataplane der Plattform, solange es keinen konkreten Grund dagegen gibt. Auf EKS starten Sie mit den nativen Network Policies des VPC CNI.
3. Brauchen Sie L7-Policies, FQDN-Egress oder Multi-Cluster-Netzwerk im Open-Source-Projekt? Das spricht für Cilium.
4. Müssen Pods auf einer BGP-Fabric routbar sein, oder sollen VMs und Bare-Metal-Hosts dieselbe Policy wie Pods bekommen? Das spricht für Calico.
5. Schreiben mehrere Teams Policies, und muss ein Security-Team immer gewinnen? Calicos Tiers sind das direkteste Modell; auf Cilium decken die neuen Admin- und Baseline-Tiers von ClusterNetworkPolicy die häufigen Fälle inzwischen ab.

Fazit

Heute sind Cilium und Calico beide exzellent, beide nutzen eBPF, und beide bewegen sich auf dieselben Upstream-APIs zu: Gateway API für eingehenden Traffic, ClusterNetworkPolicy für Plattform-Leitplanken. Wer nach Benchmark entscheidet, entscheidet nach dem unwichtigsten Unterschied.

Cilium ist der bessere Standard für einen reinen Linux-Cluster im Cloud-native-Stil, der seinen Traffic bis L7 verstehen will – und auf GKE und AKS ist es bereits der Standard. Calico ist die bessere Wahl für einen heterogenen oder infrastrukturgebundenen Cluster: Windows-Nodes, BGP-Fabrics, ältere Kernel, VMs unter derselben Policy und Organisationen, in denen Policy-Governance mehr zählt als Paketmagie.

Was auch immer Sie wählen: Wählen Sie, als würden Sie es für die gesamte Lebensdauer des Clusters behalten, denn die eigentlichen Kosten stecken in der Migration. Und bevor Sie irgendeiner Policy vertrauen – auch denen, die Sie für das andere CNI geschrieben haben –, prüfen Sie Ihre ipBlock-Regeln.

Weiterlesen: Für die Plattform über dem Netzwerk siehe Platform Engineering auf Kubernetes; was die Managed Services tatsächlich für Sie betreiben, zeigt Managed Kubernetes: Was EKS, AKS und GKE wirklich verwalten.