Cilium vs Calico

The two leading Kubernetes CNIs compared: eBPF data planes, L7 policy, observability, and operational trade-offs.

Feature Matrix	Cilium eBPF-native networking, observability, and security for Kubernetes.	Calico Battle-tested CNI with rich policy tiers and first-class BGP support.
Data Plane Cilium was built on eBPF; Calico added it as a mode.	eBPF-native; can fully replace kube-proxy	iptables/IPVS standard mode, with an optional eBPF data plane
Network Policy Cilium does L7 natively; Calico's policy tiers excel at org-wide guardrails.	K8s policies + CiliumNetworkPolicy: L7 (HTTP/gRPC/Kafka), DNS-aware egress	K8s policies + tiered GlobalNetworkPolicies; L7 requires the Envoy add-on
Observability Hubble is the strongest free observability story in CNI land.	Hubble: flow logs, service map, golden-signal metrics built in	Flow logs largely via commercial Calico offerings (Whisker/Enterprise)
Service Mesh Cilium folds mesh features into the CNI layer.	Sidecar-free mesh with mutual TLS via WireGuard/SPIFFE	Not in scope — pair with Istio/Linkerd
Performance Both are fast — architecture differs more than benchmarks do.	Excellent at scale; eBPF avoids per-packet iptables traversal	Excellent and famously predictable; eBPF mode closes the gap
Operational Complexity Calico remains the pragmatic choice for bare metal and BGP shops.	More moving parts; newer kernels required for full features	Simpler mental model, older-kernel-friendly, BGP maturity for on-prem
Managed K8s Defaults Your cloud may have already made this decision for you.	Default/native in GKE Dataplane V2 and AKS (Azure CNI powered by Cilium)	Common default for EKS self-managed policy and many on-prem distros
When to Choose Both are CNCF-graduated-quality choices — pick by workload, not hype.	L7 policy, deep observability, kube-proxy replacement, mesh-without-sidecars	BGP/on-prem networks, policy tiers, conservative kernels, simpler ops

Cilium vs Calico on AKS: A Hands-On Comparison

Real-world testing of both CNIs on AKS — policy behavior, performance, and the migration gotchas.

Read the Blog Post

Cilium vs Calico: how to choose

Cilium and Calico are both mature CNIs with network policy support, and the architectural difference is eBPF-first versus a longer track record with more deployment flexibility. Cilium implements networking, load balancing and observability in eBPF, and can run without kube-proxy. Calico supports multiple dataplanes — standard Linux networking, eBPF, or VPP — and has been in production longer across a wider variety of environments.

For basic pod networking and Kubernetes NetworkPolicy, both do the job and you would struggle to justify a migration on that basis alone. The decision is made by what you need beyond the baseline.

Cilium's differentiator is observability and identity-aware policy. Hubble gives flow visibility with service identity rather than IP addresses, which is the difference between debugging a policy in minutes and reverse-engineering it from packet captures. Its policy model extends to DNS names, HTTP methods and paths. Calico's differentiator is operational breadth: BGP peering with physical infrastructure, a well-trodden path on-premises, and fewer surprises on older kernels.

Decision matrix: which one fits your situation

Your situation	Use	Why
Need to see and debug what policies do	Cilium	Hubble shows flows by service identity, not by IP. This is the biggest practical difference.
Policy on DNS names, HTTP paths or methods	Cilium	Layer 7 aware policy is native rather than requiring a service mesh.
BGP peering with physical network gear	Calico	Mature BGP support is a long-standing strength, especially on-premises.
Older kernels or constrained environments	Calico	Standard dataplane has far lower kernel requirements than eBPF.
Want to remove kube-proxy	Cilium	kube-proxy replacement is a first-class, well-documented mode.
Managed cluster with a bundled CNI that works	Keep it	Replacing a working CNI is disruptive. Change it for a specific capability, not on principle.

The migration is the expensive part

Changing CNI on a live cluster is not a routine operation. Pod IPs change, connectivity is interrupted while the dataplane switches, and network policies have to be translated and verified. Any policy expressed in CNI-specific CRDs rather than standard NetworkPolicy needs rewriting.

The honest advice: on a new cluster, choose deliberately. On an existing one, the safe path is a new cluster with the new CNI and a workload migration, not an in-place swap. If the only motivation is that the other one is newer, that is not a good enough reason to spend the outage.

Frequently asked questions

Is eBPF meaningfully faster?

Measurably, in specific places — service load balancing at scale and bypassing iptables rule traversal, where the win grows with the number of services. For an ordinary cluster with modest service counts you are unlikely to notice it in application latency. Choose Cilium for observability and policy expressiveness; treat the performance as a bonus rather than the reason.

Do I need a service mesh with either?

Less often than you would think. Both handle network policy, and Cilium adds Layer 7 policy and flow visibility that cover a meaningful part of why teams reach for a mesh. If you need mutual TLS everywhere, request-level retries, traffic splitting and fine-grained routing, you still want a mesh. If you mainly need to control and observe what talks to what, the CNI may be enough.

Can I use standard NetworkPolicy with both?

Yes, and you should default to it. Kubernetes NetworkPolicy is portable across CNIs; CiliumNetworkPolicy and Calico's own CRDs are not. Use the standard resource for everything it can express and drop to CNI-specific policy only where you genuinely need Layer 7 rules or richer selectors — that keeps most of your policy portable.

Which do managed Kubernetes services support?

Both are available across the major managed offerings, though the integration depth varies — some ship one as a supported add-on and treat the other as bring-your-own. Check what your provider supports natively before planning, because running an unsupported CNI shifts upgrade compatibility onto you.