Cilium vs Calico
Cilium vs Calico compared for 2026: Cilium 1.20 with its eBPF data plane, kube-proxy replacement, Hubble, L7 and DNS policy, Cluster Mesh and Gateway API vs Calico 3.33 with iptables, nftables, eBPF, Windows and VPP data planes, BGP, policy tiers, Whisker flow logs and what Calico Cloud and Enterprise add, with platform support, migration limits, release cadence and a clear pick per situation.
Quick Answer
Cilium and Calico are the two Apache-2.0 Kubernetes CNIs most teams shortlist when they outgrow a basic overlay. Cilium is eBPF-only: it can fully replace kube-proxy, ships Hubble for flow and HTTP-level observability, enforces L3 to L7 policy including DNS (FQDN) rules, connects clusters with Cluster Mesh, and implements Gateway API v1.6.3 itself, all in the open-source project. It is a CNCF graduated project (October 2023); 1.20.4 shipped on 23 October 2026 and it runs only on AMD64 and AArch64 Linux with kernel 5.10 or later. Calico, maintained by Tigera, lets you pick the data plane: iptables (default), nftables, eBPF, Windows HNS or VPP, with BGP routing built in, x86-64, arm64, ppc64le and s390x support, and hierarchical policy tiers and staged policies in open source. Its 3.33.0 release (1 October 2026) is tested on Kubernetes 1.35 to 1.37. The catch is the edition line: DNS/FQDN policy, application-layer policy, egress gateways and cluster mesh are listed only for Calico Cloud ($0.025 per vCPU-hour) and Calico Enterprise. Pick Cilium if you want eBPF networking, L7 visibility and multi-cluster for free on Linux; pick Calico for Windows nodes, BGP-centric on-prem networks or a conservative iptables or nftables data plane.
Last updated November 15, 2026. Covers Cilium 1.20.4 (23 October 2026, with 1.19.10 and 1.18.16; 1.21.0-pre.4 on 2 November) and Calico Open Source 3.33.0 (1 October 2026) with 3.32.4 (11 November 2026), using docs.cilium.io (system requirements, kube-proxy-free, Cluster Mesh, DNS policy, WireGuard, mutual authentication, Gateway API, Kubernetes compatibility, migration, release organization), the Cilium 1.20.0 release notes, the CNCF project page, docs.tigera.io (requirements, edition matrix, eBPF, nftables, WireGuard, BGP, Whisker, Istio L7, Ingress Gateway), Tigera's Calico pricing page and the GitHub API, all read on 15 November 2026.
| Feature | Cilium | Calico |
|---|---|---|
| License & Governance | Apache-2.0; CNCF graduated project (accepted 13 Oct 2021, graduated 11 Oct 2023) | Apache-2.0; maintained by Tigera (not a CNCF project) |
| Data Plane Options | eBPF only (optional netkit device mode on kernel 6.8+) | Standard Linux iptables (default), nftables, eBPF, Windows HNS and VPP |
| kube-proxy Replacement | Yes: full replacement via eBPF socket-LB, Maglev, DSR (IPv4 option, Geneve, IPIP), hybrid DSR/SNAT and XDP acceleration | Only in eBPF mode (operator disables kube-proxy on kubeadm clusters); otherwise works with iptables, ipvs or nftables kube-proxy |
| CPU Architectures & OS | Linux on AMD64 and AArch64 | Linux on x86-64, arm64, ppc64le and s390x, plus Windows worker nodes |
| Minimum Linux Kernel | 5.10+ (or 4.18 on RHEL 8.10); IPv6 BIG TCP 5.19, IPv4 BIG TCP 6.3, netkit 6.8 | 5.10+ (eBPF mode also accepts RHEL 8.4 kernel 4.18.0-305) |
| Datastore | Kubernetes CRDs by default; optional etcd 3.1+ for identity management in larger clusters | Kubernetes API datastore or etcdv3 (eBPF mode needs the Kubernetes datastore) |
| Routing & Overlays | Encapsulation (VXLAN or Geneve) or native routing | IP-in-IP (default), VXLAN or unencapsulated BGP routing |
| BGP | BGP Control Plane (CiliumBGP* resources) to advertise pod CIDRs and service IPs | Built in: full-mesh iBGP by default (fine to about 100 nodes per Calico), route reflectors and external peering beyond |
| Kubernetes NetworkPolicy | ||
| Extended Policy Model | CiliumNetworkPolicy and CiliumClusterwideNetworkPolicy with identity (label) based L3/L4/L7 rules | Calico NetworkPolicy and GlobalNetworkPolicy, hierarchical tiers, staged policies, network sets, host endpoint policy |
| DNS / FQDN Policy | Yes, in open source (toFQDNs rules with wildcard patterns) | Calico Cloud and Enterprise only |
| L7 (HTTP) Policy | Yes, in open source (HTTP-aware rules via the embedded Envoy proxy) | Application-layer policy listed for Cloud/Enterprise; open source offers HTTP policy only through Istio's Envoy with the Dikastes sidecar |
| Transparent Encryption | WireGuard (UDP 51871) or IPsec with key rotation; node-to-node encryption in beta | WireGuard for IPv4 and IPv6, inter-node pod and host-network traffic |
| Flow Observability | Hubble: flow logs, service dependency map, DNS and HTTP metrics, Hubble UI, Prometheus/Grafana integration | Goldmane flow logs API and Whisker web console (tech preview, in-memory); richer logs and dashboards in paid tiers |
| Multi-cluster | Cluster Mesh: flat pod IP space, global services, service affinity, cluster-aware policy, no extra gateway hop | Cluster mesh in Calico Cloud and Enterprise only |
| Egress Gateway | Yes, in open source (CiliumEgressGatewayPolicy) | Calico Cloud and Enterprise only |
| Ingress & Gateway API | Built-in Gateway API v1.6.3 implementation (HTTPRoute, GRPCRoute, TLSRoute; TCPRoute/UDPRoute since 1.20) | Calico Ingress Gateway: a hardened Envoy Gateway distribution implementing Gateway API |
| LoadBalancer IPs | LB IPAM plus BGP or L2 announcements (L2 is beta) | Service LoadBalancer IPAM plus BGP advertisement of service IPs |
| Migrating from Another CNI | Documented node-by-node migration from another CNI | Docs: a cluster already using another CNI cannot be migrated to Calico |
| Tested Kubernetes Versions | 1.33, 1.34, 1.35 and 1.36 e2e tested for 1.20 | 1.35, 1.36 and 1.37 tested for 3.33 |
| Release Cadence | Feature release about every six months; three stable branches maintained (1.20, 1.19, 1.18) | Minor releases with patch lines for recent minors (3.33.0 Oct 2026, 3.32.4 Nov 2026, 3.31.7 Aug 2026) |
| Commercial Editions & Pricing | Isovalent Enterprise Platform (no public price) | Calico Cloud Free Tier (one cluster, one user, 24 h retention), Calico Cloud $0.025 per vCPU-hour, Calico Enterprise custom pricing |
| Latest Release (Nov 2026) | 1.20.4 (23 Oct 2026); 1.21.0-pre.4 (2 Nov 2026) | 3.33.0 (1 Oct 2026); 3.32.4 patch (11 Nov 2026) |
Cilium
Cilium is an open-source, eBPF-based networking, security and observability layer for Kubernetes. It provides the CNI, can replace kube-proxy with eBPF socket and XDP load balancing, enforces identity-based L3 to L7 network policy, and includes Hubble for flow visibility, plus Cluster Mesh, BGP, egress gateway and a built-in Gateway API implementation. It joined the CNCF in October 2021 and graduated on 11 October 2023; Isovalent, the company that created Cilium, sells the Isovalent Enterprise Platform on top of it.
Pros
- Full kube-proxy replacement built on eBPF socket-LB, with Maglev consistent hashing, Direct Server Return modes and XDP acceleration for NodePort and LoadBalancer traffic
- DNS-based (FQDN) egress rules and HTTP-aware L7 policy are part of the open-source project, not a paid tier
- Hubble gives per-flow, DNS and HTTP visibility (service maps, 4xx/5xx rates, latency percentiles, dropped-by-policy flows) without sidecars
- Cluster Mesh, BGP Control Plane, LB IPAM, egress gateway and WireGuard or IPsec encryption all ship in the same open-source agent
- Gateway API v1.6.3 core conformance with GRPCRoute and TLSRoute; 1.20 added TCPRoute, UDPRoute, BackendTLSPolicy and ExternalAuth
- Documented node-by-node migration path from another CNI without a full cluster outage
Cons
- Linux-only on AMD64 and AArch64; no Windows nodes, ppc64le or s390x builds listed in its system requirements
- Needs kernel 5.10 or later (4.18 on RHEL 8.10), and features such as BIG TCP and netkit need 5.19 to 6.8
- eBPF datapath is harder to debug with familiar iptables tooling; you learn the cilium and hubble CLIs instead
- Mutual authentication is still beta and documented as incomplete, so it is not a drop-in replacement for a service mesh's mTLS
- Commercial support comes mainly from Isovalent, which does not publish a price for its enterprise distribution
Best For
Linux-only clusters on recent kernels that want eBPF networking, kube-proxy replacement, L7 and DNS-aware policy, Hubble visibility and multi-cluster networking without buying a commercial tier.
Calico
Calico is an open-source networking and network security platform for Kubernetes, VMs and bare-metal hosts, maintained by Tigera. Calico Open Source provides the CNI, IPAM, BGP routing and Calico network policy across a choice of data planes: standard Linux iptables, nftables, eBPF, Windows HNS and VPP. Tigera sells Calico Cloud (SaaS, with a free single-cluster tier) and Calico Enterprise (self-managed), which add DNS policy, application-layer policy, egress gateways, cluster mesh and security analytics.
Pros
- Choice of data planes in one project: iptables (default), nftables, eBPF, Windows HNS and VPP, switchable per cluster
- Runs on x86-64, arm64, ppc64le and s390x, and supports Windows worker nodes
- Mature BGP networking: full-mesh iBGP by default, route reflectors for large clusters, direct peering with your routers without an overlay
- Hierarchical policy tiers, staged policies, global default-deny and host endpoint policy are all in the open-source edition
- Can run as a policy engine alongside the AWS VPC CNI, Azure VNet CNI or flannel
- Calico Cloud publishes a usage price ($0.025 per vCPU-hour), unlike Isovalent
Cons
- DNS/FQDN policy, application-layer policy, egress gateway and cluster mesh are listed only for Calico Cloud and Calico Enterprise
- Its own docs say a cluster that already uses another CNI cannot be migrated to Calico
- eBPF mode has gaps: no IPIP (use VXLAN), no etcd datastore, no SCTP, and on AKS with Azure CNI kube-proxy cannot be disabled
- Open-source flow logs (Goldmane API and Whisker console) are tech preview, in-memory only, and need an operator or Helm install
- Not a CNCF project; governance sits with a single vendor
Best For
Clusters with Windows or non-x86/ARM nodes, BGP-routed on-prem networks, teams that want a conservative iptables or nftables data plane, or a policy engine layered on a cloud provider's CNI.
Data planes: eBPF-only versus pick-your-own
The architectural split is simple. Cilium is built on eBPF and nothing else: its agent compiles and loads eBPF programs that do routing, NAT, load balancing and policy enforcement inside the kernel, and on kernel 6.8 and later it can attach pods with netkit devices. That design is why Cilium can fully replace kube-proxy, using socket-level load balancing so connections to a ClusterIP are translated at connect time, plus Maglev hashing, several Direct Server Return modes and XDP acceleration for NodePort and LoadBalancer traffic. Calico treats the data plane as a choice. The default is the standard Linux iptables path, which works with kube-proxy and coexists with your own rules; nftables mode matches the nftables kube-proxy that went beta in Kubernetes 1.31; eBPF mode disables kube-proxy and adds connect-time load balancing; Windows HNS covers Windows nodes; and VPP is listed only for the open-source edition. Calico's own eBPF guidance is refreshingly frank that iptables with ipsets can beat eBPF in some policy micro-benchmarks, and its eBPF mode has documented gaps: no IPIP overlay (use VXLAN), no etcd datastore and no SCTP. If you want one tuned eBPF stack, Cilium is the deeper implementation; if you want the option to stay on iptables or nftables, only Calico offers it.
Network policy: what is free and what is paid
Both enforce standard Kubernetes NetworkPolicy and add their own CRDs, but the open-source boundaries differ sharply. Cilium's CiliumNetworkPolicy and CiliumClusterwideNetworkPolicy select endpoints by security identity derived from labels, and the open-source project includes DNS-based egress rules (toFQDNs with wildcard patterns, so a pod can reach api.github.com but nothing else) and HTTP-aware L7 rules enforced through its embedded Envoy. Calico's open-source model is strong on structure: hierarchical policy tiers so a platform team's guardrails always evaluate before application teams' rules, staged policies you can deploy before enforcing, GlobalNetworkPolicy for cluster-wide defaults, network sets for IP ranges, and host endpoint policy that turns Calico into a host firewall for nodes and VMs. But Tigera's edition matrix lists DNS/FQDN policy, application-layer policy, policy for services, policy recommendations and previews of staged policy as Calico Cloud or Enterprise features. Open-source Calico can enforce HTTP rules only by integrating with Istio, using the Dikastes sidecar beside Envoy, which requires Istio 1.22+ with native sidecars and Kubernetes 1.29+. So if FQDN egress control or L7 rules are hard requirements and the budget is zero, Cilium is the only one of the two that meets them in open source.
Observability: Hubble versus Whisker
Cilium's Hubble is a mature part of the project: it is distributed across nodes, records every flow with verdicts, and answers questions such as which services talk to each other, which connections were dropped by policy, which pods failed DNS resolution in the last five minutes, and what the 4xx, 5xx and p95 or p99 latency rates are between two services, all from eBPF without sidecars. It has a CLI, a UI with a service map, and Prometheus and Grafana integration, and it is the strongest reason teams pick Cilium even when they do not need its other features. Calico Open Source added its own flow visibility in 3.30: Goldmane aggregates flow logs into a gRPC API and Whisker is a web console that streams them. Both are installed by default on new operator or Helm installs of 3.30 and later, but they are tech preview, keep data in memory only, do not support manifest-based installs and are not switched on automatically when you upgrade from an older release. Longer retention, HTTP, DNS, audit and BGP logs, dashboards, a service graph and alerting are in Calico Cloud (7-day retention) and Calico Enterprise (unlimited). For deep troubleshooting on a free stack, Hubble is further along.
Routing, platforms and multi-cluster
Calico grew up as a routed network and it shows. With BGP enabled it builds a full mesh of iBGP sessions between nodes, which Calico describes as fine for roughly 100 nodes, and recommends route reflectors beyond that; nodes can also peer with top-of-rack routers so pod IPs are routable on your network with no overlay at all, with IP-in-IP (the default) or VXLAN when you do need encapsulation. It also runs on x86-64, arm64, ppc64le and s390x and supports Windows workers, which settles the choice for mixed fleets. Cilium supports native routing or VXLAN and Geneve tunnels and has a BGP Control Plane for advertising pod CIDRs and LoadBalancer IPs from its LB IPAM, plus beta L2 announcements for small bare-metal clusters, but its requirements list only AMD64 and AArch64 Linux. Multi-cluster is where the free tiers diverge again: Cilium Cluster Mesh gives a flat pod IP space across clusters, global services with local or remote affinity and cluster-aware policy, with traffic going node to node without an extra gateway. Calico's cluster mesh and egress gateways are listed only for its Cloud and Enterprise editions.
Operations, upgrades, migration and cost
Cilium ships a feature release about every six months and maintains three stable branches; on 23 October 2026 it published 1.20.4, 1.19.10 and 1.18.16 together, and 1.21 is in pre-release. Calico's 3.33.0 arrived on 1 October 2026 while 3.32 kept receiving patches (3.32.4 on 11 November). Mind the test matrices: Cilium 1.20 is e2e tested on Kubernetes 1.33 to 1.36, while Calico 3.33 is tested on 1.35 to 1.37, so a cluster still on 1.33 or 1.34 should check Calico's older lines. Migration is the most underrated difference. Cilium documents migrating a running cluster from another CNI node by node, with an example you can rehearse in kind. Calico's requirements page states that a cluster already using another CNI cannot be migrated to Calico, though it can run alongside flannel or the AWS and Azure CNIs as a policy engine. On cost, both open-source projects are free. Tigera publishes Calico Cloud at $0.025 per vCPU-hour, so ten 8-vCPU nodes (80 vCPUs) running a 730-hour month list at about $1,460 per month; Calico Enterprise is quoted per customer. Isovalent does not publish prices for its Cilium-based enterprise platform, so compare quotes rather than list prices.
Verdict
Pick Cilium when your nodes are AMD64 or AArch64 Linux on kernel 5.10 or newer and you want the most capability from the free project: it replaces kube-proxy, gives you DNS and HTTP-aware policy, Hubble flow visibility, Cluster Mesh, an egress gateway and a Gateway API implementation without a licence conversation. That makes it our default pick for new Linux clusters, provided someone on the team is willing to learn eBPF-era debugging with the cilium and hubble CLIs. Pick Calico when you run Windows worker nodes, ppc64le or s390x hardware, or an on-prem network built around BGP where you want pods routed natively without an overlay; when you prefer a conservative iptables or nftables data plane that behaves like the rest of your Linux estate; or when you only need a policy engine on top of the AWS VPC CNI or Azure CNI. Calico's open-source policy model (tiers, staged policies, host endpoints) is excellent, but if your requirements include FQDN egress rules, L7 policy, multi-cluster or egress gateways, budget for Calico Cloud at $0.025 per vCPU-hour or Calico Enterprise, or choose Cilium. One practical tie-breaker: Cilium documents a node-by-node migration from another CNI, while Calico's docs say an existing cluster on another CNI cannot be migrated to it, so moving an existing cluster usually favours Cilium.