Your choice of CNI plugin is one of the most consequential decisions you will make when building a Kubernetes platform. It determines how pods communicate, how network policies are enforced, how you observe traffic, and — increasingly — how you implement service mesh and runtime security. Get it wrong, and you inherit performance bottlenecks, observability blind spots, and security gaps that are painful to remediate later.
At Tasrie IT Services, we manage production clusters running both Cilium and Calico across AWS, Azure, and GCP. We have migrated workloads from one to the other, debugged CNI-related incidents at 3 AM, and benchmarked both under real production loads. This guide distils what we have learned into a practical, honest comparison for 2026 — not a theoretical overview, but a field report from teams that operate both daily.
If you are evaluating CNIs for a new cluster or considering a migration from Calico to Cilium, this is the guide we wish we had when we started.
Architecture: How They Actually Work
The fundamental architectural difference between Cilium and Calico shapes every downstream trade-off. Understanding this distinction is more important than any feature comparison table.
Cilium: eBPF-Native from the Ground Up
Cilium was purpose-built around eBPF (extended Berkeley Packet Filter), a technology that allows custom programs to run inside the Linux kernel without modifying kernel source code or loading kernel modules. Every packet that enters or leaves a pod passes through eBPF programs that Cilium compiles and attaches to network interfaces.
The architecture consists of three core components:
- Cilium Agent — Runs as a DaemonSet on every node. Translates Kubernetes network policies and service definitions into eBPF programs, compiles them, and loads them into the kernel.
- Cilium Operator — A single cluster-wide deployment handling IPAM, garbage collection of stale resources, and synchronisation of cluster-wide state.
- Hubble — Built-in observability layer that taps into eBPF data paths to provide real-time flow visibility, DNS query logging, and L7 protocol inspection without requiring packet capture.
Cilium’s policy model is identity-based rather than IP-based. Pods are assigned cryptographic identities derived from their Kubernetes labels, service accounts, and namespaces. Network policies reference these identities, not IP addresses, meaning policies survive pod rescheduling and IP changes without any rule updates.
Cilium also replaces kube-proxy entirely. Service routing is handled via eBPF hash table lookups with O(1) complexity — the time to resolve a service is constant regardless of whether your cluster has 10 services or 10,000.
Kernel requirement: Cilium requires Linux kernel 4.19.57 or newer for full eBPF functionality. Modern managed Kubernetes services (GKE, AKS, EKS) all meet this requirement, but on-premises deployments running older distributions may need kernel upgrades.
Calico: Multi-Dataplane Flexibility
Calico takes a fundamentally different architectural approach. Rather than committing to a single data plane technology, Calico supports multiple data planes — iptables, nftables, eBPF, Windows HNS, and VPP — allowing operators to choose the best fit for their environment.
The control plane is more complex, with four key components:
- Felix — Per-node agent responsible for programming routes, ACLs, and network policies into the chosen data plane.
- BIRD — BGP daemon that distributes routing information between nodes. This is Calico’s traditional strength: pods receive routable IP addresses advertised via BGP, eliminating the need for overlay encapsulation.
- Typha — Fan-out proxy that sits between the Kubernetes API server and Felix agents, reducing API server load at scale. Critical for clusters above 100 nodes.
- confd — Watches the Kubernetes datastore and generates BIRD configuration updates.
Calico’s policy model extends the standard Kubernetes NetworkPolicy with GlobalNetworkPolicy (cluster-wide rules), HostEndpoint protection (securing the node itself), and NetworkSets (reusable IP address groups). These extensions are particularly valuable in regulated environments that require cluster-wide security baselines.
The Core Distinction
Cilium is eBPF-native and eBPF-only. Every feature — networking, policy enforcement, observability, service mesh — runs through eBPF programs in the kernel. Calico is eBPF-capable but multi-dataplane, giving it broader compatibility (including Windows and older kernels) at the cost of a more complex architecture. For teams building on our Kubernetes networking and CNI deep dive, this architectural divergence is the starting point for every decision that follows.
Feature-by-Feature Comparison
The following table captures every major feature category. We have verified each entry against the Cilium 1.16+ documentation and Calico 3.28+ documentation.
| Feature | Cilium | Calico |
|---|---|---|
| Data Plane | eBPF only | iptables, nftables, eBPF, Windows HNS, VPP |
| L3/L4 Network Policy | Yes | Yes (+ GlobalNetworkPolicy) |
| L7 Network Policy | Yes (HTTP, gRPC, Kafka, DNS) | Enterprise only |
| Identity-Based Policy | Yes (labels, service accounts) | Partial (IP/label-based) |
| DNS/FQDN Policy | Yes (via DNS proxy) | Yes (native DNS integration, no proxy) |
| kube-proxy Replacement | Yes | Yes (eBPF mode) |
| Encryption | WireGuard, IPsec | WireGuard (host-to-host only in open source) |
| Observability | Hubble (built-in, L7-aware) | Prometheus/Grafana integration |
| Service Mesh | Built-in (sidecar-free, eBPF-based) | No native service mesh |
| Multi-Cluster | Cluster Mesh (up to 255 clusters) | Federation via BGP/overlay |
| BGP Support | Control-plane only (route advertisement) | Full BGP with BIRD daemon |
| Windows Support | No | Yes (Windows HNS data plane) |
| Bandwidth Management | Yes (eBPF-based rate limiting) | Yes (via annotations) |
| Egress Gateway | Yes | Enterprise only |
| Runtime Security | Tetragon (eBPF-based) | Not available |
| CNCF Status | Graduated (October 2023) | Not a CNCF project (Tigera-owned) |
Two rows in this table deserve particular attention because they are nuanced in ways that competitor comparisons rarely address.
DNS/FQDN Policy: Cilium routes DNS queries through a transparent proxy to inspect and enforce FQDN-based rules. This works reliably but introduces a component that can become a bottleneck under extreme DNS load. Calico, by contrast, hooks into DNS responses natively without a proxy layer — Tigera has documented this architectural advantage. In our experience, the difference only matters in clusters generating more than 50,000 DNS queries per second.
Windows Support: This is a genuine Calico advantage that is underemphasised in most comparisons. If your organisation runs mixed Windows and Linux workloads — common in enterprises with .NET applications alongside Linux microservices — Calico is currently your only viable option. Cilium has no Windows support and no publicly announced roadmap for it.
Performance Benchmarks
Performance claims without methodology are marketing. Here is what the data actually shows, drawing from Cilium’s official benchmark documentation, independent community benchmarks, and our own testing.
Throughput
| Scenario | Cilium | Calico (BGP/iptables) | Notes |
|---|---|---|---|
| Pod-to-Pod | ~9.2 Gbps | ~8.5 Gbps | Minimal difference for most workloads |
| Pod-to-Service | ~28.5 Gbps | ~22.1 Gbps | Cilium’s eBPF service routing advantage |
| With WireGuard encryption | ~7.8 Gbps | ~7.2 Gbps | Encryption cost is similar for both |
The headline number is the pod-to-service gap: Cilium delivers approximately 25% higher throughput in service routing scenarios. This matters for east-west traffic-heavy architectures — microservices communicating through Kubernetes Services rather than direct pod IPs.
Latency
| Metric | Cilium | Calico (BGP) |
|---|---|---|
| Pod-to-Pod P50 | ~0.20 ms | ~0.25 ms |
| API Gateway P99 | ~0.8 ms | ~1.2 ms |
For clusters with fewer than 1,000 services, the latency difference is negligible in practice. The gap opens at scale because of how each CNI handles rule lookup. Cilium and Calico’s eBPF mode use hash tables with O(1) constant-time lookups — the time to match a rule is the same whether there are 10 rules or 10,000. Standard Calico with iptables reads rules sequentially (O(n)), meaning processing 10,000 rules takes proportionally longer than processing 10.
CPU and Memory Overhead
This is where the conversation gets honest. Cilium is not free:
- Cilium CPU: less than 10% utilisation when pushing 100 Gbps traffic; 0.15% average in steady state on a 2 vCPU node
- Calico nftables CPU: 15-20% at the same 100 Gbps throughput
- Cilium memory: Adds 12-17 GB of RAM across a 100-node cluster compared to a lightweight CNI like Flannel. The Cilium agent itself consumes 150-250 MB per node depending on the number of endpoints and policies.
The trade-off calculation: throughput gains from Cilium typically allow a 10-15% node count reduction in compute-heavy clusters, which offsets (and often exceeds) the additional memory cost. We have seen teams that focus on Kubernetes cost optimisation achieve meaningful savings by switching to Cilium and right-sizing their node pools.
When Performance Differences Actually Matter
For clusters under 200 nodes with fewer than 500 services, both CNIs perform well enough that the performance delta will not be your deciding factor. The performance gap becomes material when:
- You run 500+ services with heavy east-west traffic
- You enforce thousands of network policy rules
- You need sub-millisecond P99 latencies for internal service communication
- Your cluster experiences rapid service churn (frequent deployments creating/destroying iptables rules)
Cloud Provider Integration
The cloud provider landscape has shifted decisively toward Cilium. Both Google Cloud and Microsoft Azure now offer Cilium as their recommended advanced networking option.
GKE Dataplane V2
GKE Dataplane V2 is built on Cilium. When you enable Dataplane V2 on a GKE cluster, you are running Cilium — Google maintains and integrates it into the GKE control plane. This means:
- eBPF-based packet processing replaces kube-proxy
- Kubernetes NetworkPolicy enforcement is handled by Cilium
- Network policy logging is available natively
- Google manages Cilium upgrades as part of GKE node pool updates
If you are running GKE with Dataplane V2 enabled, you are already running Cilium. The decision has been made for you.
Azure CNI Powered by Cilium
Microsoft’s Azure CNI Powered by Cilium integrates Cilium’s eBPF data plane with AKS. It replaces kube-proxy, provides eBPF-based network policy enforcement, and supports Azure-native IPAM. However, it currently supports Linux node pools only — if you need Windows containers on AKS, you will need standard Azure CNI with Calico for network policy.
Amazon EKS
EKS uses the AWS VPC CNI plugin by default, which assigns pods real VPC IP addresses. Neither Cilium nor Calico is the default. Both can be installed alongside or as a replacement for the VPC CNI. In practice, many teams running production EKS clusters — particularly those following EKS architecture best practices — deploy Cilium in chaining mode (handling policy and observability) while keeping the VPC CNI for IPAM.
Summary Table
| Cloud Provider | Default CNI | Cilium Integration | Calico Integration |
|---|---|---|---|
| GKE | GKE Dataplane V2 | Built-in (Dataplane V2 = Cilium) | Third-party install |
| AKS | Azure CNI | Azure CNI Powered by Cilium (Linux only) | Supported; works with Windows nodes |
| EKS | AWS VPC CNI | Install alongside or replace VPC CNI | Install alongside VPC CNI |
| OpenShift | OVN-Kubernetes | Third-party install | Commonly deployed |
| Rancher/RKE2 | Canal (Calico + Flannel) | Supported alternative | Default in many setups |
The direction is clear: major cloud providers are converging on Cilium for advanced networking. For teams evaluating EKS vs AKS vs GKE, CNI integration has become a meaningful differentiator.
Security Deep Dive
Network security is where the architectural differences between Cilium and Calico produce the most visible practical impact.
L7 Network Policies
Cilium’s L7 policy support is genuinely differentiated. Standard Kubernetes NetworkPolicy operates at L3/L4 — you can allow or deny traffic based on IP addresses, ports, and protocols. Cilium extends this to application-layer protocols:
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: restrict-api-access
spec:
endpointSelector:
matchLabels:
app: payment-service
ingress:
- fromEndpoints:
- matchLabels:
app: checkout-service
toPorts:
- ports:
- port: "8080"
protocol: TCP
rules:
http:
- method: POST
path: "/api/v1/payments"This policy allows the checkout service to make POST requests only to the /api/v1/payments endpoint on the payment service. Any other HTTP method or path is denied. Calico cannot express this level of granularity in its open-source edition — L7 filtering requires Calico Enterprise.
Similar policies exist for gRPC (filtering by service and method), Kafka (filtering by topic and client ID), and DNS (allowing specific domain lookups). For organisations implementing Kubernetes security best practices, L7 policies are a significant step beyond what standard NetworkPolicy provides.
Identity-Based Security Model
Cilium’s identity-based approach assigns a cryptographic identity to each group of pods sharing the same security-relevant labels. Network policies reference these identities rather than IP addresses. The practical benefit: when a pod is rescheduled to a different node and receives a new IP address, all policies remain in effect without any rule updates. In traditional IP-based enforcement (including Calico’s default mode), there is a brief window during pod rescheduling where policies may not apply correctly until the new IP propagates through the rules.
Tetragon: Runtime Security
Tetragon is an eBPF-based runtime security enforcement and observability tool in the Cilium ecosystem. It operates at the kernel level to detect and prevent:
- Unexpected process execution (e.g., a container running a shell when it should only run a Go binary)
- Suspicious file access patterns
- Privileged escalation attempts
- Network connections from unexpected processes
Tetragon is not technically part of Cilium’s CNI functionality, but it is part of the broader Cilium ecosystem and leverages the same eBPF infrastructure. No equivalent exists in Calico’s ecosystem.
Calico’s Security Strengths
Calico has its own advantages, particularly for enterprise compliance:
- GlobalNetworkPolicy enforces cluster-wide security baselines that individual namespace owners cannot override — essential for multi-tenant clusters following Kubernetes multi-tenancy isolation patterns
- HostEndpoint protection secures the node itself, not just pod traffic
- NetworkSets define reusable groups of IP addresses for policy rules, simplifying management of allow-lists and deny-lists
- Compliance reporting in Calico Enterprise provides audit trails and policy impact analysis
Observability: Hubble vs Prometheus/Grafana
Observability is one of Cilium’s strongest differentiators and one of the most practical reasons teams choose it.
Hubble
Hubble is Cilium’s built-in observability platform. Because it taps directly into eBPF data paths, it provides:
- Real-time flow visibility — Every packet flowing between pods, services, and external endpoints is visible without tcpdump or packet capture.
- DNS query logging — See exactly which pods are resolving which domain names, and whether DNS policies are being enforced.
- L7 protocol metrics — HTTP request/response codes, latency distributions, and error rates per service pair.
- Network policy verdicts — For every flow, Hubble shows whether it was allowed or denied and which policy made the decision.
Hubble includes a CLI (hubble observe), a web UI, and a Relay component for cluster-wide aggregation. The practical difference compared to traditional monitoring is immediacy: when a network policy blocks traffic it should not (or vice versa), Hubble shows you the exact flow, the policy verdict, and the identity of both endpoints in real time.
Calico’s Observability Approach
Calico does not include a built-in observability tool comparable to Hubble. Instead, it exports metrics to Prometheus and Grafana — Felix metrics (policy processing time, active endpoints), BIRD metrics (BGP session state, route counts), and Typha metrics (client connections, cache hit rates).
This approach works well for teams that already have a mature Prometheus/Grafana stack, but it provides aggregate metrics rather than per-flow visibility. Debugging a specific denied connection requires examining Felix logs rather than querying a purpose-built flow observation tool. Calico Enterprise adds a web-based flow log viewer, but this is not available in the open-source edition.
Enterprise Editions: Isovalent vs Tigera
Both CNIs have commercial enterprise offerings that extend the open-source editions with additional features, support, and compliance tooling.
Isovalent Enterprise (Cilium)
Isovalent (acquired by Cisco in 2024) offers the enterprise platform built on Cilium with:
- Timescale-based flow log storage and historical querying
- Enterprise-grade Hubble UI with RBAC and team-based views
- Advanced threat detection using eBPF-based behavioural analysis
- FIPS 140-2 validated cryptography
- 24/7 SLA-backed support from the Cilium maintainers
Calico Enterprise and Calico Cloud
Tigera offers two commercial products:
- Calico Enterprise — Self-managed, adds L7 policy, egress gateway, compliance reporting, flow log visualisation, SIEM integration, and anomaly detection
- Calico Cloud — SaaS-managed version of Calico Enterprise with simplified deployment
Tigera publishes a detailed feature comparison between open-source Calico, Calico Enterprise, and Calico Cloud. Key enterprise-only features include L7 network policies, egress gateway, DNS policy audit logging, and PCI/SOC2 compliance dashboards.
Which Enterprise Edition?
For organisations that have already standardised on Cilium, Isovalent Enterprise is the natural choice. For teams running Calico with specific compliance requirements (PCI DSS, HIPAA), Calico Enterprise provides purpose-built audit and reporting tools that are difficult to replicate manually. The pricing models differ: Isovalent typically charges per node per month on an annual subscription, whilst Tigera offers both per-node and consumption-based pricing.
Migration: From Calico to Cilium
This is the section most CNI comparisons skip entirely, yet it is the question we hear most frequently from teams that have decided Cilium is the right long-term choice but are running Calico today.
Node-by-Node Live Migration
Cilium’s official migration documentation supports a node-by-node live migration approach that avoids cluster downtime:
- Install Cilium in per-node mode alongside the existing CNI. Cilium takes over networking on each node as it is cordoned, drained, and uncordoned.
- Cordon and drain a node — Existing pods are rescheduled to remaining Calico nodes.
- Restart the node’s kubelet with Cilium as the CNI. New pods scheduled on this node use Cilium.
- Uncordon the node and repeat for the next node.
- Remove the old CNI once all nodes are migrated.
During migration, pods on Cilium nodes can communicate with pods on Calico nodes through the cluster’s overlay or underlay network. The migration is transparent to applications.
Network Policy Conversion
Isovalent provides a Calico Network Policy Converter tool that translates Calico-specific policy resources (GlobalNetworkPolicy, HostEndpoint, NetworkSets) into CiliumNetworkPolicy equivalents. Standard Kubernetes NetworkPolicy objects work with both CNIs without modification.
Real-World Case Studies
DB Schenker — One of the world’s largest logistics companies, migrated from Calico to Cilium across their production Kubernetes clusters. The migration was driven by the need for L7 visibility and Hubble’s flow observability. They reported zero downtime during the node-by-node migration process.
Samsung Ads — Completed a live migration from Calico to Cilium on production clusters handling real-time ad-serving traffic. Their blog documents the full migration process, including challenges with IPAM transitions and DNS policy conversion. Post-migration, they reported a 33% reduction in P99 latency for their API gateway services.
Migration Checklist
Before starting a Calico-to-Cilium migration:
- Verify all nodes run Linux kernel 4.19.57+ (check with
uname -r) - Audit existing Calico-specific policies (GlobalNetworkPolicy, HostEndpoint) for conversion
- Confirm no Windows nodes are in the cluster (Cilium does not support Windows)
- Test Cilium in a staging environment that mirrors production topology
- Validate application connectivity after each node migration
- Plan Hubble deployment for post-migration observability
- Update monitoring dashboards to include Cilium and Hubble metrics
- Review Kubernetes migration strategy for broader migration planning
Decision Framework: Which Should You Choose?
After managing both CNIs across dozens of production clusters, here is our straightforward recommendation framework.
Choose Cilium When:
- Greenfield cloud-native platforms on modern Linux kernels — Cilium is the technically superior choice for new deployments in 2026
- Running on GKE (Dataplane V2) or AKS (Azure CNI Powered by Cilium) — it is already your CNI; standardise on it
- You need L7 network policies — HTTP path/method filtering, gRPC service filtering, Kafka topic filtering
- Built-in observability matters — Hubble provides flow-level visibility without deploying additional tools
- Large clusters with 500+ services — eBPF’s O(1) rule lookup scales better than iptables
- Sidecar-free service mesh — Cilium’s eBPF-based service mesh avoids the overhead and complexity of sidecars
- Runtime security — Tetragon provides kernel-level security enforcement unavailable in any other CNI ecosystem
- Multi-cluster networking — Cluster Mesh supports up to 255 clusters with global service discovery
Choose Calico When:
- Mixed Windows and Linux workloads — Calico is the only mature CNI supporting Windows containers
- On-premises with existing BGP infrastructure — Calico’s native BGP support with BIRD integrates with established network engineering practices
- Older Linux kernels — If you cannot run kernel 4.19.57+, Calico’s iptables data plane works on older kernels
- Regulatory compliance — GlobalNetworkPolicy and Calico Enterprise’s compliance reporting tools are mature and well-understood by auditors
- Rancher/RKE2 environments — Calico is the default and best-integrated option
- Teams that prefer traditional debugging workflows — iptables is more familiar to most network engineers than eBPF
A Note on Flannel
Flannel remains a valid choice for development environments, learning labs, and single-node clusters where simplicity is the priority. It provides basic pod-to-pod connectivity with no network policy support, no observability, and no encryption. If you are running anything in production, you should be using Cilium or Calico.
The Honest Summary
If you are starting fresh in 2026, choose Cilium. The eBPF architecture provides better performance at scale, deeper observability with Hubble, L7 policy enforcement, sidecar-free service mesh, and runtime security with Tetragon. The major cloud providers have already voted by integrating Cilium into their managed offerings. The CNCF graduated Cilium in October 2023, and the project’s community — with 21,000+ GitHub stars and 900+ contributors — is growing faster than any other CNI.
If you are running Calico successfully in production and have no pressing need for L7 policies or Hubble, there is no urgency to migrate. Calico remains a stable, proven CNI, especially for enterprises with Windows workloads, BGP requirements, or older kernel constraints. But if your roadmap includes advanced network policies, service mesh, or runtime security, plan the migration sooner rather than later — the gap between the two ecosystems is widening.
Need Help Choosing or Migrating Your CNI?
Selecting the right CNI — and migrating between them without downtime — requires deep Kubernetes networking expertise and production experience with both platforms. A misstep during CNI migration can take down pod-to-pod communication across your entire cluster.
Our team provides comprehensive Kubernetes consulting services to help you:
- Evaluate and select the right CNI based on your workloads, cloud provider, compliance requirements, and team capabilities
- Plan and execute Calico-to-Cilium migrations using the node-by-node approach, validated with real production traffic
- Implement Cilium network policies including L7 rules, identity-based enforcement, and Hubble observability
- Optimise cluster networking performance with eBPF tuning, WireGuard encryption, and service mesh integration
We have performed CNI migrations and deployments across GKE, AKS, and EKS for organisations ranging from startups to global enterprises.