Skip to content

CNI Comparison — Cilium vs Calico vs Flannel

Canonical comparison of the three most common open-source Kubernetes CNI plugins: Cilium, Calico and Flannel. Versions, licenses and feature status follow the topic pages (checked 2026-09-25). "Calico" means Calico Open Source unless a row says Enterprise or Cloud.

Quick Reference

Dimension Cilium Calico Flannel
Latest Version 1.20.2 (2026-09-15) v3.32.2 (2026-08-29) v0.28.9 (2026-08-07)
Data Plane eBPF (TC/tcx, XDP, socket hooks). veth or netkit (beta) iptables (default), nftables (GA 3.31), eBPF, Windows HNS, VPP Kernel routing with VXLAN (default), host-gw or WireGuard backends. iptables for masquerade/forward rules, nftables mode experimental
Network Policies L3/L4 + L7 (HTTP, gRPC, DNS/FQDN) L3/L4 with tiers, Deny/Pass, global and host policy. L7 HTTP via Application Layer Policy (Dikastes with Istio). DNS policy: Enterprise/Cloud only None in flanneld. Via add-on: kube-network-policies (Helm option), K3s kube-router, Canal, Cilium chaining
Observability Hubble (L3-L7 flows, service map, metrics) Goldmane + Whisker flow logs (tech preview since 3.30). Dashboards in Enterprise/Cloud None built in
Service Mesh Sidecar-free (eBPF + per-node Envoy), ztunnel mTLS (beta) Bundled Istio ambient mode (tech preview in 3.32) None
Gateway API Native, Gateway API v1.6.1 Calico Ingress Gateway (Envoy Gateway build), GA in 3.31 None
BGP BGP control plane (v2 CRDs) Native (BIRD), route reflectors None
Encryption WireGuard or IPsec. ztunnel mTLS (beta) WireGuard WireGuard backend
Multi-cluster Cluster Mesh (open source, 255 or 511 clusters) Federation: Enterprise/Cloud only None
License Apache-2.0 (eBPF code GPL-2.0 / BSD-2-Clause) Apache-2.0. Enterprise/Cloud proprietary Apache-2.0
Governance CNCF Graduated (2023-10-11). Vendor: Isovalent (Cisco) Tigera. Not a CNCF project Independent flannel-io org, SUSE maintainers. Not a CNCF project
Kernel Requirement Linux >= 5.10 (or RHEL 8.10's 4.18) since 1.18. netkit >= 6.8 Linux 5.10+ (eBPF also on RHEL 8.4 kernel 4.18.0-305+). nftables 5.13+ No documented minimum. Needs br_netfilter and vxlan modules. WireGuard is in-kernel from 5.6

Which One Should I Pick?

The deciding questions are usually platform constraints (Windows nodes, kernel, non-Kubernetes hosts) and whether you need policy and observability at all, before performance.

flowchart TD
    Q1{"Need NetworkPolicy<br/>or segmentation?"}
    Q1 -->|"No: dev, CI, lab, small edge"| FL["Flannel<br/>(default in K3s)"]
    Q1 -->|Yes| Q2{"Windows worker nodes, or<br/>VMs / bare-metal hosts to protect?"}
    Q2 -->|Yes| CA1["Calico<br/>(Windows HNS data plane, host endpoints)"]
    Q2 -->|No| Q3{"Kernel 5.10+ on every node<br/>(or RHEL 8 backport)?"}
    Q3 -->|No| Q3B{"Want to keep<br/>Flannel networking?"}
    Q3B -->|Yes| CANAL["Flannel + policy add-on<br/>(kube-network-policies, K3s kube-router, Canal)"]
    Q3B -->|No| CA2["Calico iptables data plane"]
    Q3 -->|Yes| Q4{"Need open-source L7 policy, flow observability<br/>or multi-cluster?"}
    Q4 -->|Yes| CI["Cilium<br/>(Hubble, L7 HTTP/gRPC/DNS, Cluster Mesh)"]
    Q4 -->|No| Q5{"BGP peering with the physical<br/>fabric or ordered policy tiers?"}
    Q5 -->|Yes| CA3["Calico<br/>(BIRD BGP, tiers; eBPF or nftables data plane)"]
    Q5 -->|No| EITHER["Cilium or Calico:<br/>benchmark both on your kernel and NICs"]
Scenario Recommendation
Production cluster needing L7 policy, flow visibility, kube-proxy replacement Cilium: Hubble and L7 HTTP/gRPC/DNS policy are open source
Hybrid (Kubernetes + VMs + bare metal) Calico: extends policy to hosts and non-Kubernetes workloads. Cilium removed external workloads in 1.18
Windows worker nodes Calico: Windows HNS data plane. Flannel also runs on Windows (vxlan, host-gw) but without policy. Cilium is Linux only
On-prem BGP fabric, ordered policy tiers Calico: native BGP with route reflectors, tiers with Deny/Pass
Dev/test/homelab Flannel: one DaemonSet, simplest "it just works" option
K3s lightweight Flannel (embedded default, with kube-router policy) or Cilium
Zero-trust L7 policies without a service mesh Cilium: L7 enforcement in the CNI itself. Calico's open-source L7 needs Istio (Dikastes)
Existing iptables investment, older kernels Calico: iptables or nftables data plane with a path to eBPF
Open-source multi-cluster Cilium: Cluster Mesh is free. Calico federation needs Enterprise/Cloud

Data Plane Comparison

The three plugins take pod packets through very different paths. Flannel bridges pods and relies on kube-proxy and kernel routing, Calico lets Felix program one of several rule engines on routed cali* interfaces, and Cilium attaches eBPF programs to each pod interface.

flowchart LR
    subgraph FLN["Flannel (VXLAN backend)"]
        direction TB
        FP["Pod eth0"] --> FV["veth"] --> FB["cni0 bridge"]
        FB --> FK["Kernel routing<br/>+ kube-proxy iptables/IPVS rules"]
        FK --> FT["flannel.1 VTEP<br/>VXLAN UDP 8472"]
        FT --> FN["Node NIC"]
    end
    subgraph CAL["Calico"]
        direction TB
        CP["Pod eth0"] --> CV["veth cali* (routed, no bridge)"]
        CV --> CF["Felix-programmed data plane<br/>iptables / nftables / eBPF (TC)"]
        CF --> CR["Routes from BIRD (BGP)<br/>or vxlan.calico / tunl0 overlay"]
        CR --> CN["Node NIC"]
    end
    subgraph CIL["Cilium"]
        direction TB
        IP["Pod eth0"] --> IV["veth lxc* or netkit"]
        IV --> IE["eBPF at TC/tcx:<br/>policy + service LB via BPF maps"]
        IE -->|"L7 rules"| IENV["cilium-envoy"]
        IE --> IR["Native routing or<br/>cilium_vxlan / cilium_geneve"]
        IR --> IN["Node NIC (optional XDP LB)"]
    end

Feature Matrix

Feature Cilium Calico Flannel
L3/L4 Policy ✅ ✅ ⚠️ Add-on controller only
L7 Policy ✅ HTTP, gRPC, DNS/FQDN (Kafka removed in 1.20) ⚠️ HTTP method/path via Dikastes with Istio. DNS policy Enterprise/Cloud ❌
Network observability ✅ Hubble ⚠️ Whisker/Goldmane (tech preview). Full UI in Enterprise/Cloud ❌
Runtime security ✅ Tetragon (separate project) ❌ in Open Source ❌
Service mesh ✅ Sidecar-free ⚠️ Istio ambient bundle (tech preview) ❌
BGP peering ✅ ✅ ❌
Gateway API ✅ v1.6.1 ✅ Calico Ingress Gateway (GA 3.31) ❌
kube-proxy replacement ✅ ✅ eBPF and VPP data planes ❌
Windows support ❌ Linux only ✅ (HNS) ✅ (vxlan, host-gw)
Non-K8s hosts ❌ External workloads removed in 1.18 ✅ Host endpoints, VMs, OpenStack ⚠️ Connectivity only, with etcd as datastore
Bandwidth management ✅ EDT-based bandwidth manager ✅ QoS controls since 3.30 (bandwidth, packet rate, connections). eBPF QoS since 3.31 ❌
AI Assistant ❌ ⚠️ Enterprise/Cloud only (Winter 2026) ❌

Performance Estimates

Directional only

The throughput row comes from one third-party test (sanj.dev: cross-node pod-to-Service iperf3, 8 parallel streams, AWS c5.4xlarge; Cilium 1.17, Calico 3.31 iptables, Flannel 0.26 VXLAN; figures as indexed on 2026-09-27). It is not a controlled upstream benchmark. The topic pages list what each project publishes (Cilium, Calico, Flannel). Benchmark your own kernel, NICs and pod density.

Metric Cilium (eBPF) Calico (eBPF) Calico (iptables) Flannel (VXLAN)
Throughput (sanj.dev test) 28.5 Gbps Not measured in that test 22.1 Gbps 20.3 Gbps
Latency Low (hash-map lookup) Low Grows with rule count (linear chain) Encapsulation overhead (50 B VXLAN header)
CPU overhead Low (kernel-space) Low (eBPF mode) High with many rules Low (no policy processing)
Scale No Cilium-published maximum. Kubernetes documents 5,000 nodes; the official scalability report tested 1,000. Endpoint map 64k per node No published hard limits. BGP full mesh to ~100 nodes, then route reflectors No published limit. Pods per node bounded by the node subnet (/24 = 254 IPs) and kubelet maxPods (110) Same

The Flannel scale cell applies to Flannel only. An earlier "1,000 pods" limit for Flannel had no source and was removed.

Resource Consumption

Memory and CPU overhead per node vary across CNIs.

Single third-party source

The per-node memory and CPU tables below are the results of a single third-party test (sanj.dev CNI benchmark guide, 2026; AWS c5.4xlarge; Cilium 1.17, Calico 3.31, Flannel 0.26), not upstream specifications. The post's search-indexed text (checked 2026-09-28) shows the Cilium memory figures (180 MB at 100 pods, 280 MB at 250, 450 MB at 500+) and describes Flannel as steady at 50-80 MB per node. The only upstream-sourced numbers are Flannel's manifest request of 100m CPU / 50Mi memory per node and the Cilium scalability report (agent at most 573 MiB with 50,000 pods on 1,000 nodes).

Memory Consumption Per Node

Per-node memory measured in the sanj.dev test:

Pod Density Cilium Calico Flannel
50 pods ~150 MB ~100 MB ~55 MB
100 pods ~180 MB ~120 MB ~60 MB
250 pods ~280 MB ~160 MB ~65 MB
500+ pods ~450 MB ~220 MB ~68 MB

At cluster scale, memory adds up (derived by multiplying the per-node estimates):

Cluster Size Cilium (total) Calico (total) Flannel (total)
100 nodes ~18-28 GB ~12-16 GB ~5.5-6.8 GB
1,000 nodes ~180-280 GB ~120-160 GB ~55-68 GB
5,000 nodes ~900 GB-1.4 TB ~600-800 GB ~275-340 GB

CPU Overhead

Average CPU during the same sanj.dev throughput test:

CNI Avg CPU (TCP) Avg CPU (UDP) Notes
Cilium ~10% ~18% eBPF bypasses netfilter stack
Calico (iptables) ~25% ~35% Linear chain walk at scale
Calico (eBPF) ~12% ~20% Comparable to Cilium
Flannel ~10% ~16% Lightweight but no policy processing

Run your own numbers

Use iperf3 with parallel streams between pods on different nodes, with your real policy set loaded. Results vary with kernel version, NIC driver, MTU and pod density.

Operational Complexity

Installation & Upgrade

Dimension Cilium Calico Flannel
Install method Helm chart or cilium install (cilium-cli) Tigera Operator (manifest or Helm) or plain manifests Single DaemonSet manifest or Helm chart. Embedded in K3s
Time to first pod (estimate) 5-10 min 3-5 min 1-2 min
Upgrade process Rolling via Helm with pre-flight checks. One minor at a time Rolling via operator or Helm. 3.32 adds an optional migration from the aggregated API server to native v3 CRDs (tech preview) kubectl apply or helm upgrade
Upgrade risk Medium: features are removed on schedule (for example Kafka L7 in 1.20). Read upgrade notes Low-Medium Very low
CRD count (approx.) 25+ CRDs 15+ CRDs 0 CRDs
Config surface area (approx.) Large (200+ Helm values) Medium (operator resources + FelixConfiguration) Small (net-conf.json + flags)

Debugging & Observability Tools

Tool Cilium Calico Flannel
Built-in CLI cilium status (cilium-cli), cilium-dbg status / cilium-dbg monitor in the agent pod calicoctl node status, calicoctl ipam check None (check subnet.env, node annotations, /healthz)
Flow visibility Hubble UI + CLI (L3-L7) Whisker UI (Open Source, tech preview). Enterprise/Cloud dashboards tcpdump only
Policy troubleshooting hubble observe --verdict DROPPED, cilium-dbg endpoint get calicoctl get networkpolicy / globalnetworkpolicy, Whisker flow logs, staged policies N/A (depends on add-on)
eBPF inspection cilium-dbg bpf * commands calico-node -bpf conntrack dump / nat dump / policy dump (eBPF mode) N/A
Prometheus metrics Comprehensive (agent, operator, Hubble) Good (Felix, Typha) Minimal

Community & Support

Dimension Cilium Calico Flannel
GitHub stars (dated snapshots) ~22k+ (2026-07) ~6k+ (2026-07) ~9k+ (recorded by 2026-08)
Governance CNCF Graduated (2023-10-11) Tigera-owned, not CNCF Independent flannel-io org (4 SUSE maintainers), not CNCF. Originally CoreOS
Commercial support Isovalent (Cisco): Isovalent Enterprise for Cilium Tigera: Calico Enterprise, Calico Cloud No dedicated vendor product
Release cadence Feature release about every 6 months, monthly patches, 3 stable branches Minor about every 6 months, two newest minors patched Patch releases every few weeks in 2026, only latest release patched

Multi-cluster & Federation

Capability Cilium ClusterMesh Calico Federation Flannel
Availability Open source (Apache 2.0) Calico Enterprise / Cloud only N/A
Setup CLI-driven (cilium clustermesh enable, cilium clustermesh connect) Manual kubeconfig + manifests N/A
Service discovery Global services, MCS-API (stable in 1.20) Federated Services controller N/A
Cross-cluster policy Full identity-based L3-L7 Federated tiers + endpoint identity N/A
Routing requirement Non-overlapping PodCIDRs, IP reachability, unique cluster.id Pod IPs routable (overlay or BGP) N/A
Observability Hubble across clusters Dynamic Service Graph (Enterprise) N/A
Max clusters 255 (default) or 511 (maxConnectedClusters, set at install; halves identities) Not published: the Calico Enterprise federation docs state no cluster limit (checked 2026-09-27) N/A

Cilium ClusterMesh is free; Calico federation is not

Cilium ClusterMesh ships in the open-source release. Calico's full multi-cluster federation (federated endpoint identity, federated services, federated tiers) requires Calico Cloud or Calico Enterprise, a paid product. All clusters in a Cilium mesh form one trust domain.

Migration Paths

CNI migrations restart pods

Every CNI migration re-attaches pod interfaces, so every pod restarts. Plan a maintenance window, use a rolling node-drain strategy, or build a new cluster and cut over blue/green.

Flannel to Cilium (Most Common)

The most frequently traveled path, especially for K3s clusters that outgrow Flannel's lack of built-in policy.

  1. If you only need policy, consider keeping Flannel and adding kube-network-policies, Canal or Cilium in CNI chaining mode first (least disruptive).
  2. For a full switch, follow Cilium's Migrating a cluster to Cilium guide: Cilium runs a second overlay with its own pod CIDR and encapsulation port, then nodes are migrated one at a time.
  3. Remove Flannel: delete the DaemonSet (or disable it on K3s), ip link delete flannel.1 and cni0 on each node, and remove the Flannel CNI config.
  4. Validate with cilium connectivity test.

K3s-specific: disable Flannel at install

On K3s, start servers with --flannel-backend=none --disable-network-policy before installing Cilium. Flannel is embedded in K3s (no DaemonSet), so retrofitting means reconfiguring servers. Details: Flannel how-to: migrate.

Calico to Cilium

  1. Audit existing policies: Cilium enforces standard Kubernetes NetworkPolicy. Calico NetworkPolicy/GlobalNetworkPolicy resources (tiers, Deny/Pass ordering) need manual conversion to CiliumNetworkPolicy / CiliumClusterwideNetworkPolicy.
  2. Deploy Cilium alongside using the same per-node migration procedure (separate pod CIDR and overlay port).
  3. Cordon, drain and migrate nodes one by one.
  4. Validate with the cilium connectivity test suite.

Flannel to Calico

  1. Or add policy only: Canal keeps Flannel networking and adds Calico policy.
  2. For a full switch: remove the Flannel DaemonSet and clean up the CNI config (/etc/cni/net.d/) and flannel.1/cni0 links.
  3. Install Calico via the Tigera Operator or manifests.
  4. Restart all pods to pick up the new CNI, fastest via a rolling node drain.

ARM & Edge Support

Capability Cilium Calico Flannel
ARM64 (aarch64) Supported Supported (eBPF: x86-64 and arm64 only) Supported
ARM32 (armhf) Not supported Not supported (x86-64, arm64, ppc64le, s390x) Supported
K3s integration Custom install (disable Flannel first) Custom install (disable Flannel first) Embedded default
MicroK8s microk8s enable cilium add-on Default CNI Available
KubeEdge Supported Supported Supported
Talos Linux Documented (Talos >= 1.5.0) Supported Default CNI
Per-node overhead (estimate) ~150-200 MB ~100-120 MB ~55 MB (manifest requests 50Mi)
Kernel requirement >= 5.10 (RHEL 8.10 4.18) 5.10+ (RHEL 8.4 backport for eBPF) No documented minimum

Lightweight K8s Distribution Defaults

Distribution Default CNI Cilium Viable? Notes
K3s Flannel (VXLAN), plus embedded kube-router policy controller Yes (disable Flannel) Most popular edge distro. ARM + x86 parity
MicroK8s Calico Yes (add-on) Canonical-backed. ARM64 + x86 + s390x
k0s kube-router Yes (custom) Mirantis-backed
RKE2 Canal (Calico policy + Flannel networking) Yes (supported option) SUSE Rancher enterprise Kubernetes

Edge recommendation

For resource-constrained edge nodes (Raspberry Pi, IoT gateways), Flannel on K3s is the lightest option (50Mi memory request). Move to Cilium or Calico when you need richer policy, observability, or L7 enforcement.

Major cloud providers converged on Cilium as the advanced networking option:

  • GKE: Dataplane V2 is built on Cilium (GA since 2021, GKE 1.20.6-gke.700)
  • AKS: "Azure CNI Powered by Cilium" (GA since May 2023, Linux nodes only)
  • EKS: Cilium available via Helm (including ENI IPAM mode). AWS VPC CNI remains the default

Sources