Cilium vs Calico: CNI Comparison from Project Docs, with Decision Table

CNI decision for a new or existing cluster? WZ-IT plans and operates Kubernetes networks: CNI and network policies, Gateway API, load balancing, DNS and TLS - and private access through NetBird instead of unnecessary public exposure. See Network & Secure Access

Cilium or Calico? Both enforce Kubernetes NetworkPolicies, both connect pods across nodes, both are widely used. The differences lie in details that only show up in operations: which data path runs, which rules and flow data are part of the open-source scope, which kernel is required and how hard a later switch becomes. This comparison relies exclusively on the projects' documentation (Cilium 1.20.4, Calico Open Source 3.33), every statement with a link. As of October 2026.

A CNI plugin is mandatory in every cluster: it implements the Kubernetes network model, assigns pod addresses and connects pods across nodes. Whether it also enforces NetworkPolicies depends on the plugin.

Table of contents

• Summary
• Core facts compared
• Features in the open-source scope
• Data path: eBPF as the default or as an option
• Policies: one shared standard, different extensions
• Operations: kernel, ports and version care
• Switching in a running cluster
• Decision table: which CNI when
• Status and methodology
• How WZ-IT works
• Further guides
• Sources

Summary

• The standard NetworkPolicy works the same on both. Anyone who needs default deny and allow rules by label does not need to change the CNI.
• In its open-source scope Cilium includes rules by domain name and L7, Hubble, Cluster Mesh, an egress gateway and IPsec. The feature matrix of the Calico documentation lists rules by domain name, application layer policy, cluster mesh and egress gateway under Cloud and Enterprise. The open-source documentation describes HTTP rules only via the Istio integration.
• Calico offers several data paths (iptables, eBPF, nftables, VPP, Windows), Cilium is built on eBPF. Both require Linux 5.10 or newer.
• Switching the CNI in a running cluster is a migration, not a setting.

Core facts compared

Features in the open-source scope

The table shows what each documentation describes in the free scope. For Calico the feature matrix with the columns Open Source, Cloud and Enterprise applies. Commercial editions are not part of the comparison.

Data path: eBPF as the default or as an option

Cilium works on eBPF: policies and identities are enforced in the kernel, service connections are rewritten at the socket and can replace kube-proxy completely. The replacement has to be switched on: the Helm default is kubeProxyReplacement=false. The overlay uses VXLAN by default, with Geneve and native routing as alternatives.

Calico offers eBPF as one of several choices. The default is the iptables data path, which according to the documentation is designed for compatibility with kube-proxy and your own iptables rules, while the eBPF data path targets performance and latency. The same page states that for policies with a large number of IP addresses (ipsets), iptables is in many cases better than eBPF in micro-benchmarks. The eBPF data path supports neither SCTP nor the etcd datastore and no clusters with mixed eBPF and standard nodes. Calico also describes an nftables data path, a VPP data path and a Windows data path.

The documentations provide no reliable throughput or latency comparisons, and this article names none. Anyone who has to decide the question measures with their own load on their own hardware.

Policies: one shared standard, different extensions

The portable part is the Kubernetes NetworkPolicy. A default-deny rule for incoming traffic looks the same on both plugins (example from the Kubernetes documentation):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress

Without a plugin that enforces NetworkPolicies, this object has no effect. A pod without a policy is not isolated by default. Standard policies only know allow rules and act additively, there is no order.

Beyond that the extensions differ. Cilium knows deny rules, rules by domain name and L7 rules for HTTP and gRPC as well as its own default behaviour: the first rule that selects an endpoint switches it to default deny per direction, and the mode can be set to "always" or "never". Calico arranges rules in tiers with a defined precedence, knows the actions Allow, Deny, Log and Pass and allows staged policies for testing. Tiers are part of the open-source scope. Both implement the Kubernetes ClusterNetworkPolicy API (still v1alpha2) with its Admin and Baseline levels, Cilium from 1.20 after activation, Calico 3.33 through two fixed tiers. The platform team can use it to set rules that application teams cannot override.

The Cilium documentation itself warns: when several policy types are used at the same time, the total set of allowed connections is hard to oversee, and unintended allows can result. A set of standard policies as a base and few extensions on top remain easier to follow.

Operations: kernel, ports and version care

Kernel and distribution. Both documentations name Linux 5.10 or newer (Cilium, Calico). Cilium lists Ubuntu from 20.04, Debian from 10, RHEL from 8.6 and Talos from 1.5.0, Calico lists Ubuntu from 20.04, RHEL from 8, Debian from 10 and Talos from 1.6. Individual Cilium features need higher kernels, for example netkit from 6.8. Calico requires that NetworkManager does not manage the Calico interfaces and that Firewalld or other iptables managers are disabled.

Ports between nodes. These openings belong in the firewall and security group planning before installation:

Version care. The CNI runs on every node, an upgrade affects the whole cluster. Both projects test against a limited range of Kubernetes versions (table above). As of 28 October 2026 Kubernetes 1.37 is current, Cilium 1.20 lists 1.33 to 1.36, Calico 3.33 tests 1.35 to 1.37. CNI compatibility therefore belongs in the check before every Kubernetes upgrade. How version state and upgrade history can be kept as evidence is described in Kubernetes NIS2 and ISO 27001: the evidence a cluster can provide.

Distribution defaults. RKE2 bundles four CNI plugins and uses Canal (Flannel for traffic between nodes, Calico for traffic within a node and for policies) as the default, Cilium and Calico can be selected. k3s ships Flannel; for another CNI, k3s is started with --flannel-backend=none and --disable-network-policy is additionally recommended. Talos installs Flannel and can be switched to Cilium, as described in Install Talos Linux on Proxmox.

Further components. With Cilium, Gateway API and egress gateway require the kube-proxy replacement. For gateway listeners Cilium uses Envoy, by default via TPROXY with iptables, so the nodes must provide the necessary netfilter modules. How Gateway API and Ingress relate is explained in Gateway API vs. Ingress, address assignment for LoadBalancer services on bare metal and Proxmox in MetalLB vs. kube-vip.

Switching in a running cluster

A CNI is the earliest decision in a cluster because every pod is configured by the CNI when it starts. Anyone who switches has to restart all pods of the old CNI. The Cilium documentation describes a node-by-node migration for this: two overlays with separate IP ranges run in parallel, pods on both sides remain reachable until all nodes are converted. A simple conversion of all nodes followed by a restart would split the network into two islands.

According to the Calico documentation, a cluster that already uses another CNI cannot be migrated to Calico. Documented is the migration from Flannel or Canal, either with a live migration tool or by building a new cluster. For planning this means: the decision belongs at the start, and a switch needs a test environment, a change window and a way back.

Decision table: which CNI when

Status and methodology

• As of: 28 October 2026. Cilium 1.20.4 (released 23 October 2026, documentation "stable"), Calico Open Source 3.33 (release 3.33.0 of 1 October 2026, documentation "latest"), Kubernetes 1.37 as the current version.
• Sources: exclusively project documentation, the projects' GitHub repositories and the CNCF. All pages retrieved on 28 October 2026, links in the source list.
• Calico scope: The statement "not included" refers to the Open Source column of the feature matrix in the Calico 3.33 documentation. Where the open-source documentation describes more than that (HTTP rules via Istio, IPsec with VPP), this is noted. Commercial editions and third-party offerings are not assessed.
• CNCF status of Calico: The entry "Project Calico" in the CNCF landscape (landscape.yml) has no project field, unlike Cilium with project: graduated.
• Not included: Throughput and latency measurements, service mesh comparison, comparison with Flannel and cloud-specific CNIs.
• Beta and preview: Features with this status (ztunnel, L2 announcements, Whisker) are marked in the tables. Check their state before using them in production.

How WZ-IT works

1. Clarify requirements. Policies (standard or L7/domain names), flow evidence, encryption, Gateway API, multi-cluster, Windows, kernel and distribution determine the choice, not the popularity of the project.
2. Decide using the table. The CNI choice is made when the cluster is built because a later switch is a migration. In Kubernetes networking and secure access, CNI and network policies with default deny, necessary flows and network transparency are part of the scope.
3. Maintain in operations. In Kubernetes operations the CNI is one of the add-ons: upgrades run as a planned change with a compatibility check against the Kubernetes version. Managed Kubernetes costs from €590 excl. VAT per cluster and month including three worker nodes. Monitoring runs 24/7, the response to P1 incidents follows the service level.
4. Clarify individual questions. Questions about CNI selection or a switch can be clarified without a contract through support, €120 per hour excl. VAT. As of October 2026.

Private access to the cluster API and internal services is a separate layer above the CNI: Access Kubernetes privately with NetBird. NetBird does not replace the CNI.

Further guides

• Gateway API vs. Ingress: entry point into the cluster, role model and controller selection.
• MetalLB vs. kube-vip: load balancing on bare metal and Proxmox.
• Access Kubernetes privately with NetBird: cluster API and internal services without public exposure.
• Kubernetes NIS2 and ISO 27001: the evidence a cluster can provide: which evidence the cluster provides, including network policies and flow data.
• Install Talos Linux on Proxmox: CNI choice before the bootstrap.
• k3s vs. RKE2 vs. Talos: which distribution fits which operating model.

To select a CNI, introduce policies or plan a switch: Kubernetes Network & Secure Access with WZ-IT.

Sources

All sources retrieved on 28 October 2026.

• Cilium 1.20.4: System requirements, Introduction, Network policy, Policy language and policy introduction, kube-proxy replacement, Kubernetes compatibility
• Cilium 1.20.4: Hubble and Hubble exporter, Encryption, Gateway API, Cluster Mesh, Egress gateway
• Cilium 1.20.4: BGP Control Plane, LB IPAM, Migrating to Cilium
• Cilium: Repository and README, Release 1.20.4, CNCF project page
• Calico Open Source 3.33: About Calico with feature matrix, System requirements, eBPF data plane and eBPF use cases
• Calico Open Source 3.33: Policy tiers, GlobalNetworkPolicy, WireGuard, Flow logs and Whisker, Application layer policy with Istio, IPsec with VPP
• Calico Open Source 3.33: Ingress Gateway, Service IPs via BGP, Migration from Flannel
• Calico: Repository and README, Release 3.33.0
• CNCF Landscape (landscape.yml)
• Kubernetes: Network Plugins, Network Policies, Patch Releases
• RKE2: Basic Network Options, K3s: Basic Network Options

Related service: Cilium and network policies