CNI-Vergleich 2026 – Cilium, Calico, OVN-Kubernetes, Kube-OVN, Antrea, Flannel/Canal

Kurzfassung

Sieben Kandidaten, jeder in einem Satz. Wer wenig Zeit hat, liest nur diesen Abschnitt und Abschnitt 7.

CNI	In einem Satz
Cilium	eBPF-Komplettpaket: Netzwerk, kube-proxy-Ersatz, L7-Policy, Observability, Gateway API.
Calico	Der Allrounder mit wählbarem Datapath (nftables, eBPF, …) und nativem BGP.
OVN-Kubernetes	OVS/OVN-basiert, Default in OpenShift, stark bei Multi-Tenancy (UDN) und BGP/EVPN.
Kube-OVN	SDN-Denke im Cluster: VPCs, Subnetze, Underlay-VLANs, KubeVirt-freundlich.
Antrea	OVS-basiert, sauberes Tiered-Policy-Modell, gute Windows-Unterstützung, Broadcom-Umfeld.
Flannel / Canal	Minimal: Overlay ohne (Flannel) bzw. mit Calico-Policies (Canal). Default in k3s bzw. RKE2.

Faustregel: Die Plattform entscheidet zuerst, die Anforderung danach. Wer OpenShift fährt, fährt OVN-Kubernetes. Wer frei wählt, landet meist bei Cilium oder Calico.

Versionsstand dieses Artikels

Kubernetes 1.36 · Cilium 1.20 · Calico 3.32 · OpenShift 4.21/4.22 · Antrea 2.x · RKE2 mit Canal-Default. CNI-Projekte veröffentlichen schnell und entfernen auch in Minor-Releases Features – vor jedem Upgrade die Release Notes lesen.

Was ein CNI eigentlich tut

Die CNI-Spezifikation selbst ist nur die Steckdose. Alles, worüber man beim Vergleich streitet, ist Zusatzleistung des jeweiligen Projekts.

Das Pod-Netz als Postsystem

Aufgabe	Post-Analogie	Technik
IPAM	Hausnummern vergeben	Pod-CIDR pro Node oder Cluster-Pools
Datapath	Straßen und Sortierzentren	Routing, Bridge, Overlay (VXLAN/Geneve), eBPF, OVS
NetworkPolicy	Pförtner mit Zugangsliste	iptables/nftables-Regeln, eBPF-Maps, OVS-Flows
Service-Load-Balancing	Weiterleitungsstelle für Sammeladressen	kube-proxy oder CNI-eigener Ersatz
Verschlüsselung	Brief im versiegelten Umschlag	WireGuard, IPsec
Observability	Sendungsverfolgung	Flow-Logs, Hubble, Traceflow, ovn-trace

Die Spezifikation ist nur die Steckdose

Kubelet bzw. Container-Runtime rufen beim Pod-Start ein Binary mit ADD auf, beim Löschen mit DEL. Mehr schreibt die CNI-Spezifikation nicht vor. Policies, Load-Balancing, BGP, Verschlüsselung – all das ist Eigenleistung des Plugins und der Grund, warum die Projekte so unterschiedlich ausfallen.

CNI verbindet den Pod. Alles andere verkauft das Plugin extra.

Die drei Datapath-Familien

Der Datapath bestimmt Performance, Debugging-Werkzeuge und Kernel-Anforderungen stärker als jedes Feature-Häkchen. Er ist die eigentliche Entscheidung.

iptables / nftables · der Türsteher mit Gästeliste

Bild: Bei iptables liest der Türsteher die Liste von oben nach unten, bei nftables ist sie nach Namen sortiert (Sets und Maps).

iptables skaliert linear mit der Anzahl Regeln und Services, nftables deutlich besser.
kube-proxy hat einen nftables-Modus (GA seit Kubernetes 1.33); IPVS ist deprecated – neue Cluster sollten nicht mehr darauf aufsetzen.
Debugging: nft list ruleset, iptables-save, conntrack -L – vertraut, aber bei tausenden Regeln unübersichtlich.

eBPF · der Chip am Eingang

Bild: Ein Chip scannt den Stempel. Hash-Lookup statt Liste – die Kosten bleiben fast konstant, egal wie viele Services existieren.

Programme hängen an tc, XDP, cgroup-Hooks oder Sockets. Service-Auflösung passiert oft schon beim connect(), nicht erst pro Paket.
Voraussetzung: moderner Kernel (Richtwert 5.10+, RHEL-Kernel mit Backports gelten als äquivalent).
Debugging: bpftool, Hubble, cilium-dbg, calico-bpf – mächtig, aber neue Werkzeuge lernen.

Open vSwitch / OVN · der programmierbare Rangierbahnhof

Bild: OVS schaltet Weichen anhand von Flow-Tabellen, OVN schreibt den zentralen Fahrplan (logische Switches, Router, ACLs) und übersetzt ihn in Flows pro Node.

Stark bei SDN-Konzepten: logische Router, VRFs, Tenants, Underlay-Anbindung, Hardware-Offload.
Debugging: ovn-trace, ovnkube-trace, ovs-ofctl dump-flows – präzise, aber steile Lernkurve.

Overlay gegen natives Routing

Modus	Bild	Overhead	Wann
Overlay (VXLAN/Geneve/IPIP)	Brief im Brief	20–100 Byte pro Paket, MTU sinkt	Unterlay ist fremd oder nicht steuerbar
Native Routing / BGP	Echte Adresse im Telefonbuch des Rechenzentrums	keiner	Netzwerkteam spielt mit, Pod-IPs sollen von außen erreichbar sein

MTU-Richtwerte bei 1500er Unterlay: IPIP −20, VXLAN −50, Geneve (OVN-K) −100, WireGuard −60 (IPv4) bzw. −80 (IPv6).

Verschlüsselung und Overlay addieren sich. Wer Geneve mit WireGuard kombiniert, verliert 160 Byte – das ist die häufigste Ursache für „kleine Requests gehen, große hängen“.

Die Kandidaten im Profil

Jeweils Stand, Stärken, Schwächen und typischer Einsatz. Die Merksätze am Ende jedes Profils sind das, was hängenbleiben soll.

Cilium · das eBPF-Komplettpaket

Stand: 1.20 (Juli 2026), unterstützt werden jeweils die drei letzten Minor-Releases (1.18–1.20). CNCF Graduated. Kommerziell: Isovalent (Cisco).

Stärken

Vollständiger kube-proxy-Ersatz in eBPF, inklusive Maglev, DSR, Socket-LB.
Hubble: Flow-Observability bis L7, ohne Sidecar.
L7-Policies (HTTP, gRPC, Kafka, DNS/FQDN) über einen Envoy pro Node.
Gateway API und Ingress eingebaut; 1.20 ergänzt unter anderem ExternalAuth sowie TCPRoute und UDPRoute.
BGP Control Plane, Cluster Mesh (Multi-Cluster), Egress Gateway, WireGuard/IPsec.
Schrittweise Migration von anderen CNIs Node für Node möglich.

Schwächen

Viele Schalter, viele Wechselwirkungen. Kube-proxy-Ersatz, Routing-Modus und Encryption müssen zusammenpassen.
Kernel-abhängig; exotische oder gehärtete Kernel können Features verhindern.
Envoy und BPF-Maps kosten Speicher pro Node.
Einige Enterprise-Features (erweiterte Hubble-UI, Timescape) nur in Isovalent Enterprise.

Typischer Einsatz: Greenfield auf Vanilla, RKE2 oder Talos, Managed Clouds (GKE Dataplane V2 und AKS nutzen Cilium unter der Haube), Umgebungen mit hohem Observability- und Zero-Trust-Anspruch.

Cilium ist das Schweizer Taschenmesser – man muss wissen, welche Klinge offen ist.

Calico · der Baukasten mit austauschbarem Motor

Stand: 3.32 (April 2026, passend zu Kubernetes 1.36). Open Source (Apache 2.0), nicht CNCF. Kommerziell: Calico Enterprise/Cloud.

Stärken

Wählbarer Datapath: iptables, nftables (GA seit 3.31), eBPF, VPP, Windows HNS – Wechsel per linuxDataplane in der Installation-CR.
BGP als Kernkompetenz (BIRD): Pod-IPs ohne Overlay ins Rechenzentrum routen.
Tiered Policies, GlobalNetworkPolicy, Host-Endpoint-Schutz.
Observability-UI Whisker mit Flow-Aggregator Goldmane (seit 3.30).
3.32: KubeVirt-Live-Migration mit IP-Persistenz, sidecarlose mTLS via Istio Ambient, eBPF-Maglev.
Beste Windows-Unterstützung unter den großen CNIs.

Schwächen und Breaking Changes

AdminNetworkPolicy und BaselineAdminNetworkPolicy sind in 3.32 entfernt; vor dem Upgrade auf ClusterNetworkPolicy migrieren.
calico-apiserver ist deprecated, Ersatz sind native v3-CRDs.
L7-Features im OSS-Teil schmaler als bei Cilium.

Typischer Einsatz: On-Prem mit BGP-Anbindung, gemischte Linux/Windows-Cluster, Teams, die schrittweise von iptables zu nftables oder eBPF wollen.

Calico ist der Baukasten: gleiche Policies, austauschbarer Motor.

OVN-Kubernetes · das Netz, das OpenShift mitbringt

Stand: Default-CNI in OpenShift (OpenShift SDN ist seit 4.17 entfernt). Upstream-Projekt ovn-kubernetes, Hauptträger Red Hat.

Stärken

Geneve-Overlay, Service-LB direkt in OVN – OpenShift kommt ohne kube-proxy aus.
User-Defined Networks (UDN/CUDN): echte Netzwerk-Isolation pro Namespace, Layer2-/Layer3-/Localnet-Topologien, überlappende CIDRs möglich.
RouteAdvertisements: Pod-Netz, CUDNs und EgressIPs per BGP (FRR-K8s) ins Provider-Netz annoncieren; OpenShift 4.22 ergänzt BGP-EVPN für primäre CUDNs.
EgressIP, EgressFirewall, AdminNetworkPolicy, IPsec, Hardware-Offload.
Sehr gut mit OpenShift Virtualization (Layer2-UDN für VM-Live-Migration).

Schwächen

Außerhalb von OpenShift wenig verbreitet, kaum Hersteller-Support.
Debugging erfordert OVN-Wissen (logische Switches, Router, ACL-Tiers).
Geneve kostet 100 Byte MTU.

Typischer Einsatz: OpenShift – Punkt. Alternativen sind dort nur als zertifizierte Partner-CNIs mit eigenem Support-Vertrag sinnvoll.

OVN-K ist das Fundament des Hauses – man tauscht es so selten wie eines.

Kube-OVN · die kleine OpenStack-Netzwelt

Stand: CNCF Sandbox. Ebenfalls OVN/OVS, aber mit anderem Ziel als OVN-Kubernetes.

Stärken

VPC-Modell: Tenants mit eigenen Adressräumen, NAT-Gateways, EIPs, Security Groups.
Subnetze pro Namespace, statische IPs, Underlay-/VLAN-Modus ohne Overlay.
KubeVirt-Live-Migration ohne Verbindungsabbruch.
Kann als Secondary CNI neben Cilium oder Calico laufen (via NAD).
DPDK, OVS-Hardware-Offload, Traffic-Mirroring, kubectl ko für Diagnose.

Schwächen

Hohe Komplexität, SDN-Kenntnisse vorausgesetzt.
Community und Hauptentwickler stark im chinesischen Raum; in Europa wenig kommerzieller Support.

Typischer Einsatz: Private-Cloud- und IaaS-Plattformen auf Kubernetes, VM-lastige Umgebungen, Underlay-Anbindung an bestehende VLANs.

Kube-OVN baut dir eine kleine OpenStack-Netzwelt in den Cluster.

Antrea · Firewall-Denke auf OVS

Stand: 2.x, CNCF Sandbox. Hauptträger Broadcom (ehemals VMware).

Stärken

OVS-Datapath, eigener Proxy (AntreaProxy) als kube-proxy-Ersatz.
Tiered Policy-Modell (ClusterNetworkPolicy, Prioritäten, Node-Policies) – gut für Security-Teams mit Firewall-Hintergrund.
Traceflow: Paketpfad inklusive Policy-Entscheidungen simulieren.
Gute Windows-Unterstützung, Egress-Gateways, Multi-Cluster, IPsec/WireGuard.

Schwächen

Momentum außerhalb des VMware/Broadcom-Ökosystems gering.
Kleinere Community, weniger Drittanbieter-Integrationen.

Typischer Einsatz: vSphere Kubernetes Service und Tanzu-Umfeld, Windows-lastige Cluster.

Antrea ist die Firewall-Denke auf OVS – solide, aber zuhause im Broadcom-Haus.

Flannel und Canal · das Kabel und das Kabel mit Pförtner

Flannel

Nur Pod-Konnektivität: VXLAN, host-gw oder WireGuard. Keine NetworkPolicies.
Default in k3s. Klein, schnell verstanden, kaum Betriebsaufwand.
Nicht für gehärtete oder Compliance-Umgebungen.

Canal

Flannel für den Transport zwischen Nodes, Calico für Policies auf dem Node.
Default-CNI in RKE2. Solider Einstieg, NetworkPolicies funktionieren.
Grenzen: kein BGP, kein eBPF, keine Windows-Nodes, Observability minimal.

Flannel ist das Kabel, Canal ist das Kabel mit Pförtner.

Abgekündigt oder Randnotiz

Weave Net: seit dem Ende von Weaveworks (2024) praktisch ohne Pflege – migrieren.
OpenShift SDN: entfernt seit OpenShift 4.17.
Multus: kein Primär-CNI, sondern Meta-Plugin für zusätzliche Interfaces (SR-IOV, macvlan, VLAN). In RKE2 und OpenShift mitgeliefert.

Vergleichstabelle

Zwölf Kriterien über alle sieben Kandidaten. Auf schmalen Bildschirmen seitlich scrollbar.

Kriterium	Cilium	Calico	OVN-K	Kube-OVN	Antrea	Canal	Flannel
Datapath	eBPF	nftables / iptables / eBPF / VPP	OVS/OVN	OVS/OVN	OVS	iptables + Linux-Routing	Linux-Routing
Overlay	VXLAN, Geneve, native	IPIP, VXLAN, keins (BGP)	Geneve	Geneve, VXLAN, Underlay	Geneve, VXLAN, GRE	VXLAN	VXLAN, host-gw
kube-proxy-Ersatz	ja, vollständig	ja (eBPF-Modus)	ja (OVN-LB)	ja (OVN-LB)	ja (AntreaProxy)	nein	nein
Erweiterte Policies	CNP/CCNP, FQDN, L7	Tiers, GNP, ClusterNetworkPolicy	ANP, EgressFirewall	Security Groups, ACL	Tiers, ACNP	Calico-Basis	keine
L7-Policy	ja (Envoy)	über Istio Ambient	nein	nein	eingeschränkt	nein	nein
Verschlüsselung	WireGuard, IPsec	WireGuard	IPsec	eingeschränkt	IPsec, WireGuard	WireGuard (Flannel)	WireGuard
BGP	ja	ja (Kernfeature)	ja (FRR-K8s, EVPN)	ja	ja	nein	nein
Observability	Hubble	Whisker / Goldmane	Network Observability Operator (OCP)	Metriken, Mirror, kubectl ko	Traceflow, Flow-Exporter	minimal	minimal
Windows-Nodes	nein (praktisch)	ja	ja (Hybrid-Overlay, OCP)	nein	ja	nein	ja
KubeVirt / VMs	begrenzt	ja (3.32 Live-Migration)	stark (UDN)	stark	begrenzt	nein	nein
Governance	CNCF Graduated, Isovalent/Cisco	Tigera	Red Hat	CNCF Sandbox	CNCF Sandbox, Broadcom	SUSE (RKE2)	Community
Lernkurve	hoch	mittel	hoch	hoch	mittel	niedrig	sehr niedrig

Plattform-Kontext

Die erste Frage ist nicht „welches CNI ist das beste“, sondern „was bringt meine Plattform mit und was unterstützt der Hersteller“.

Plattform	Default	Realistische Alternativen
OpenShift	OVN-Kubernetes	Cilium/Calico nur als zertifizierte Partner-CNIs
RKE2	Canal	Cilium, Calico, Flannel mitgeliefert; `cni:` in `/etc/rancher/rke2/config.yaml`; Multus zusätzlich
k3s	Flannel	beliebig mit `--flannel-backend=none`
kubeadm / Talos	keiner	freie Wahl, meist Cilium oder Calico
GKE	Dataplane V2 (Cilium)	–
AKS	Azure CNI (Option: powered by Cilium)	–
EKS	Amazon VPC CNI	Cilium/Calico im Chaining- oder Overlay-Modus

RKE2-Hinweis: Nur Calico und Flannel unterstützen dort Windows-Nodes. Wer Cilium mit kube-proxy-Ersatz nutzt, setzt zusätzlich disable-kube-proxy: true.

Policy-Landschaft 2026

Der Standard kann wenig, die CNI-eigenen CRDs können viel – und binden an das Plugin. Die Mischung entscheidet darüber, ob ein CNI-Wechsel später machbar bleibt.

Drei Ebenen

NetworkPolicy (networking.k8s.io/v1): kleinster gemeinsamer Nenner – nur L3/L4, nur Namespace-Scope, kein explizites Deny.
Cluster-weite Policies (network-policy-api): AdminNetworkPolicy und BaselineAdminNetworkPolicy werden upstream zu ClusterNetworkPolicy zusammengeführt. Calico hat ANP/BANP in 3.32 bereits entfernt – bei anderen CNIs den Migrationspfad pro Release prüfen.
CNI-eigene CRDs (CiliumNetworkPolicy, Calico GlobalNetworkPolicy, Antrea ClusterNetworkPolicy, OVN-K EgressFirewall): bieten mehr, binden aber an das Plugin.

Faustregel: Baseline mit Standard-NetworkPolicy und Default-Deny pro Namespace. CNI-eigene CRDs nur für das, was der Standard nicht kann – FQDN, L7, Cluster-Scope. So bleibt ein CNI-Wechsel machbar.

Compliance-Bezug: Anforderungen wie BSI APP.4.4 zur Netzsegmentierung setzen durchgesetzte Policies voraus. Flannel allein erfüllt das nicht.

Entscheidungshilfe

Drei Fragen in fester Reihenfolge. Die erste erledigt die meisten Fälle bereits.

Der Entscheidungsbaum

Die drei Fragen in Reihenfolge

PlattformWas bringt sie mit, was unterstützt der Hersteller?
AnforderungL7, BGP, VMs, Windows, Compliance?
KönnenWer debuggt das nachts um drei? eBPF- und OVN-Wissen sind nicht selbstverständlich.

P-A-K: Plattform, Anforderung, Können – in genau dieser Reihenfolge.

Betrieb und Migration: typische Fallen

Sieben Fehlerbilder, die im Betrieb und beim Wechsel immer wieder auftreten – die meisten melden sich nicht mit einer klaren Fehlermeldung.

Falle	Symptom	Gegenmaßnahme
MTU falsch	kleine Requests gehen, große hängen (TLS-Handshake, Uploads)	Overlay- und Encryption-Overhead addieren, Path-MTU testen (`ping -M do -s …`)
kube-proxy doppelt	Services flappen, doppelte NAT-Regeln	Bei kube-proxy-Ersatz kube-proxy wirklich entfernen, Reste mit `kube-proxy --cleanup` beseitigen
Kernel zu alt	eBPF-Features fehlen still oder Agent startet nicht	Kernel-Matrix des CNI vor dem Rollout prüfen
Big-Bang-CNI-Wechsel	Totalausfall des Pod-Netzes	Node-weise Migration (Cilium-Migrationsmodus, Calico-Migration) oder neuen Cluster aufbauen
CNI-eigene CRDs überall	Wechsel wird zum Rewrite	Standard-NetworkPolicy als Baseline
Breaking Changes im Minor	Policies greifen nach dem Upgrade nicht mehr	Release Notes lesen – Beispiel: Calico 3.32 entfernt ANP/BANP
Air-gapped	Images für Agent, Operator, Envoy, Hubble fehlen	Vollständige Image-Liste aus dem Helm-Chart ziehen und spiegeln

Ein CNI-Wechsel ist ein Umzug bei laufendem Betrieb – erst Adressen und Wege klären, dann Möbel tragen.