Cilium or Calico for Kubernetes networking: which fits your cluster
Choose Cilium if you want one eBPF-based component to handle pod networking, kube-proxy replacement, flow visibility and node-to-node encryption on Linux nodes. Choose Calico if you run Windows worker nodes, want the VPP data plane, or prefer a networking project maintained by Tigera under Apache-2.0. Both are established choices for self-managed clusters on virtual machines and bare metal, so the decision depends on facts about your environment: your node operating systems, the network policy you already run, how much flow observability your security team needs, and what your engineers can operate. Confirm each point against the maintainers' current documentation before you commit.
Cilium fits best when networking requirements extend beyond policy. Its eBPF hash tables can fully replace kube-proxy, which moves Service handling out of the iptables path. Hubble adds service maps and flow visibility, so platform and security teams can see which workloads communicate. Built-in options include encryption with IPsec or WireGuard, ztunnel for mesh traffic, and Gateway API support without per-pod proxies. These features carry the most value when you plan to consolidate CNI, Service load balancing and encryption into one component. Before adopting them, confirm kernel and node OS support for the eBPF features you need, because those requirements determine which hosts you can build on.
Calico fits best when platform constraints come first. Its data plane choices include eBPF, standard Linux networking, Windows and VPP, so it can serve mixed clusters with Windows workers or teams that already operate VPP. Calico is Apache-2.0 licensed and maintained by Tigera, which matters if your procurement or compliance review asks who owns the roadmap and under what license. Existing policy is often the deciding factor: if your clusters already use Calico network policy objects, moving to Cilium means translating and retesting those rules. As of October 2026, the latest releases listed were Cilium v1.20.3 and Calico v3.33.0, so check each project's release notes against your Kubernetes version before you pilot either one.
Which CNI fits which cluster scenario
This table maps common cluster scenarios to the CNI that fits best and the fact you must confirm before deciding. Treat each row as a starting point, since several answers depend on Windows scope, encryption options or audit evidence in the release you plan to run. Cilium leads where eBPF kube-proxy replacement, Hubble visibility and built-in encryption matter, while Calico leads where Windows data planes or an existing Calico policy estate decide the question.
| Scenario | Better fit | Reason and what to confirm |
|---|---|---|
| Linux-only cluster replacing kube-proxy | Cilium | Cilium's README describes full kube-proxy replacement using eBPF hash tables. Confirm kernel and distribution requirements for your nodes before the change. |
| Cluster with Windows worker nodes | Calico, if Windows is required | Calico lists a Windows data plane among its choices. Confirm Windows support scope, supported Kubernetes versions and feature parity in the Calico release you will run. |
| Flow visibility for audits | Cilium | Hubble provides flow visibility and service maps. Confirm whether its flow data, fields and retention meet your evidence requirements, since visibility data is not the same as an audit log. |
| Cluster already running Calico policy | Calico, unless a Cilium feature is required | Staying avoids a cluster-level CNI change. Confirm how your existing policies map to a Cilium model before any migration is scoped. |
| Encryption in transit between nodes | Cilium, once options are confirmed | Cilium's README lists IPsec, WireGuard and ztunnel. Confirm which encryption options Calico offers in your release and how key management works for each. |
| Multi-cluster connectivity | Depends on the requirement | Neither project's supplied facts cover multi-cluster behavior in detail. Confirm the multi-cluster features, supported topologies and Kubernetes version skew with each vendor's current documentation. |
How Cilium and Calico build the data plane
Both plugins give Kubernetes pods networking and enforce network policy, but they reach that goal through different data planes. The cards below explain what each choice means for node operating systems, kube-proxy, encryption, observability and the people who troubleshoot the cluster at 2 a.m.
Cilium's eBPF data plane
Cilium programs the Linux kernel with eBPF and uses it for packet forwarding, load balancing and policy. Cilium can fully replace kube-proxy using eBPF hash tables, so service routing moves out of iptables rules. The operational consequence is that your nodes must run a kernel that supports the eBPF features Cilium needs, so check the kernel and distribution requirements in the Cilium documentation before you commit. Your troubleshooting shifts toward the Cilium agent and kernel-level tooling, which your team must know how to read.
Hubble for flow visibility
Hubble is Cilium's observability layer and provides service maps and flow visibility for traffic between workloads. It matters most when a policy drops a connection and the team needs to see which identity, namespace or service made the decision. Hubble is part of the Cilium project, so the same data source serves both networking and security reviews. Confirm which Hubble components, retention settings and UI options your chosen Cilium version ships, and plan where flow data is stored, since it can grow quickly on busy clusters.
Mesh features and encryption without proxies
Cilium offers service mesh features such as encryption with IPsec, WireGuard or ztunnel and Gateway API support without per-pod proxies. For teams that want in-transit encryption between nodes, this is a decision point: choose the encryption mode that your kernel, MTU and key management can support. Ask which mode your security baseline requires and whether ztunnel is needed for workload identity. Test encrypted throughput and failure behavior in your own environment, since this document supplies no benchmark numbers.
Calico's selectable data planes
Project Calico offers eBPF, standard Linux, Windows and VPP data plane choices. That flexibility matters when your fleet mixes Linux and Windows nodes, or when a Linux-only eBPF data plane does not fit your kernel or host policy. Choosing the standard Linux data plane keeps iptables-based behavior familiar to operators, while the eBPF option moves you closer to Cilium's model. Confirm which data plane combinations your Calico version supports for each node OS before you finalize the cluster design.
Tigera's maintenance model
Project Calico is Apache-2.0 licensed and created and maintained by Tigera. Calico's release cadence, roadmap and support arrangements therefore depend on one commercial steward, while Cilium is a CNCF graduated project. Ask Tigera which support tier covers your Calico version, how long each release line is maintained and which features sit behind commercial offerings. Also check the latest release stated in the Calico repository, which was v3.33.0 when read in October 2026, against your upgrade plan.
Node OS and day-two troubleshooting
Each architecture sets different requirements for node operating systems and different habits for operators. Cilium's eBPF path depends on kernel features, so kernel upgrades become networking changes. Calico's standard Linux and Windows data planes keep more of the packet path in iptables or Windows networking. Before choosing, have your platform team test node image upgrades, decide who owns kernel-level debugging and confirm which tools your on-call engineers can use during a live policy incident.
Feature facts: kube-proxy replacement, observability and mesh
This table sets the supplied facts for Cilium and Calico against the feature areas that drive a CNI decision. Where a cell shows a confirmation item instead of a fact, the supplied research does not settle that point, so check it with Tigera or the Cilium documentation before you commit. Read the rows on license and release status first, then the rows on kube-proxy replacement, observability and encryption.
| Capability | Cilium | Calico |
|---|---|---|
| License | User-space code under Apache-2.0; BPF code under GPL-2.0 and BSD-2-Clause | Apache-2.0 |
| CNCF status | CNCF graduated project | Confirm current CNCF status with Tigera; not covered by supplied facts |
| Latest release | v1.20.3, dated October 15, 2026 | v3.33.0, latest on the GitHub releases page as read in October 2026 |
| kube-proxy replacement | Can fully replace kube-proxy using eBPF hash tables | Confirm with Tigera which Calico data plane and configuration support kube-proxy replacement |
| Flow observability | Hubble provides service maps and flow visibility | Not covered by supplied facts; confirm the flow visibility tooling Tigera offers and its license |
| Encryption in transit | IPsec, WireGuard or ztunnel | Confirm supported encryption options with Tigera |
| Gateway API support | Included, without per-pod proxies | Confirm Gateway API support and version with Tigera |
| Data planes | eBPF-based data path | eBPF, standard Linux, Windows and VPP data plane choices |
| Windows node support | Confirm with the Cilium docs before relying on it | Windows data plane available |
What the licenses and editions mean for each CNI
Cilium's licensing splits along the boundary between its user-space code and the programs it loads into the Linux kernel. The user-space code is Apache-2.0, while its BPF code is dual-licensed under GPL-2.0 and BSD-2-Clause, so the license that applies depends on which part of the stack you are reading, building or changing. The project is a CNCF graduated project for networking, observability and security built on eBPF, so platform teams usually review the kernel-side code as closely as the controllers around it. Review the cilium/cilium repository directly before you rely on this summary.
- User-space code is Apache-2.0. Most of the code your operators read, patch and rebuild falls under this permissive license, which keeps internal modification straightforward for many teams.
- BPF code offers two license options. Dual licensing as GPL-2.0 or BSD-2-Clause applies to the BPF programs, and legal review should confirm which option fits your distribution model.
- Internal use differs from shipping. Running a build inside your own clusters raises a different question from packaging Cilium inside a product you sell or give to customers.
- Current stable release. Cilium v1.20.3, dated October 15, 2026, is the latest stable release listed in the repository, so pin and validate the version you deploy.
Before you standardize, read the LICENSE files in the repository you will build from, ask your counsel how the GPL-2.0 and BSD-2-Clause options apply to your use, and confirm with the vendor whether any paid support or enterprise option exists and whether a feature you need sits behind it.
Project Calico is Apache-2.0 licensed cloud native networking and network security, created and maintained by Tigera. The project carries one permissive license, which makes the internal-use question simpler than a split license would. Most of the evaluation then moves to the data plane choice, because Calico offers eBPF, standard Linux, Windows and VPP data planes, and each one may bring different operational and support questions. Check the projectcalico/calico repository for the license text that governs the version you deploy.
- One license for the project. The repository is Apache-2.0, so review centers on the code you run, modify and package.
- Vendor stewardship. Tigera created and maintains the project. Ask Tigera how it sequences roadmap work, security fixes and long-term maintenance for the edition you intend to use.
- Data plane choice affects what you operate. Teams that run Windows nodes or VPP alongside Linux should confirm the support status and documentation of each data plane they include.
- Current release. Calico v3.33.0 is the latest release on the GitHub releases page as read in October 2026, so confirm that the minor version supports your Kubernetes version before you pin it.
Confirm with Tigera whether any commercial offering contains a capability you need, such as a specific policy or observability feature, and get the answer in writing. Do not assume the open-source build includes every capability described in the documentation.
Two different questions drive license review for a CNI: whether your own teams can run and modify the software, and whether you can package it for others. For internal deployments, the license terms of both projects raise few obstacles in most readings. Shipping a product, appliance or managed service changes the review, because the artifact you deliver becomes the object that needs a license review. Have counsel confirm the position for your jurisdiction and your specific delivery model.
- Internal operation is the common case. Running either project in your own clusters, including patched builds, is generally covered by the Apache-2.0 terms for Calico and the user-space terms for Cilium.
- Source is not the whole inventory. A license on a source repository does not automatically cover every binary, container image, Helm chart or bundled dependency, so list each artifact you ship.
- Kernel-side terms need a record. For Cilium, the BPF programs carry GPL-2.0 or BSD-2-Clause terms, so state which option you rely on in your bill of materials.
- Notices and attribution. Keep license texts and notices in your distribution and record the exact version each came from, so audit evidence matches what runs in production.
- Support is a separate contract. Redistribution rights do not include vendor support. Ask each vendor directly what support, patch and indemnity terms it offers, if any.
Build a bill of materials for the exact versions you ship, have counsel review it, and confirm any paid support or enterprise terms in writing with each vendor before you commit to a delivery model.
What drives the running cost of Cilium and Calico
Both plugins are free to run under their stated licenses, so the running cost is engineering time. Cilium's user-space code is Apache-2.0 and its BPF code is dual-licensed GPL-2.0 and BSD-2-Clause, while Project Calico is Apache-2.0 licensed. The money goes to the people who design network policy and observability, who carry out cluster upgrades, who troubleshoot packet paths and who keep node operating systems within what the chosen data plane needs. Any paid support from Tigera or a commercial partner is a separate line item that you choose to add. Cilium's Hubble and Calico's flow and policy tooling both generate data that needs storage and retention, and that storage cost recurs with cluster size and traffic volume.
Most of the cost is one-time design work and recurring upgrade work. The one-time items are the initial data plane decision, the kube-proxy replacement (for Cilium) or equivalent service path design, the migration of existing NetworkPolicy or Calico policy objects, and the rewrite of policy into whatever model your team standardizes on. The recurring items are upgrades, on-call time for network incidents and observability storage. Kubernetes publishes releases about three times per year on a cycle of about 14 weeks, so a CNI upgrade that tracks the platform is a predictable recurring task rather than an occasional project. The version skew policy allows kubelets to be up to three minor versions older than kube-apiserver, so nodes can lag the control plane, but the CNI must still work with every version in your fleet during the rollout. Plan one test cluster per upgrade cycle and confirm the Cilium and Calico compatibility matrix for each target Kubernetes minor before scheduling it.
Ask for a quote that prices each component separately. Request the written scope for policy design and migration, the observability stack and its retention period, the upgrade calendar for the next twelve months, the node OS and kernel requirements you must meet for the chosen data plane, and the on-call model you expect your team to run. Ask whether a retainer covers upgrades, continuous testing and troubleshooting, and what is excluded. Confirm with Tigera or Isovalent whether any paid support tier matters for your risk profile, and ask the implementer to state which items are fixed-scope and which are billed as they arise. Request a rollback plan for each upgrade, since that work is the most common source of unplanned effort.
Moving a live cluster from Calico to Cilium or back
This sequence moves a running Kubernetes cluster between Calico and Cilium with the least disruption, keeping standard NetworkPolicy intent intact while rebuilding the CNI-specific pieces. It ends with a cluster that runs one CNI, verified connectivity and documented rollback steps.
Inventory policies, CNI objects and dependencies
The platform team lists every NetworkPolicy in each namespace and separates standard Kubernetes policies from Calico-specific resources such as GlobalNetworkPolicy and other Calico custom resources. They also record IP pools, encapsulation settings, BGP peering, any Calico-based egress or encryption configuration, and which workloads depend on kube-proxy behavior. Output: a signed-off inventory where every object is tagged as portable or rebuilt. Done when the team can point to a replacement for each Calico-only object.
Decide data plane and encryption settings
The network and security leads choose the target data plane, whether Cilium will replace kube-proxy, and which encryption mode applies in transit, such as IPsec, WireGuard or ztunnel for Cilium, or the encryption options Calico offers in the target version. They also confirm how Hubble or the replacement observability stack will be fed. Output: a written design record that names the chosen options and the reason for each. Confirm every setting against the current Cilium and Calico documentation for the target version before the record is approved.
Rehearse the migration in a non-production cluster
The team builds a non-production cluster at a Kubernetes version that matches production, installs the planned CNI and loads a copy of the policy set. They run representative application traffic, service lookups, ingress paths and egress checks, then record which flows the policy set allows and denies. Output: a test report listing every policy that behaves differently from production, with a fix or an accepted exception for each. Repeat the rehearsal until the report shows no unexplained differences.
Schedule cutover by node or cluster
The team selects the cutover unit, either one node pool at a time or a whole cluster when a second cluster can take the workload. They write the change window, the owner of each step, the health checks that gate progress and the rollback trigger. The exact cutover method, including whether a dual-CNI or drain-based approach is supported, must be confirmed against the vendor documentation for the target version. Output: an approved runbook that the on-call team has read.
Cut over nodes and validate service connectivity
Engineers drain each node, switch its CNI and bring it back into service, then move to the next unit only after the health checks pass. After kube-proxy behavior changes, they test ClusterIP, NodePort, LoadBalancer and DNS resolution from pods and from outside the cluster, and they confirm that policies still allow and deny the expected flows. Output: a per-node checklist with timestamps and test results. Done when every node reports the new CNI and the connectivity suite passes across the cluster.
Rebuild observability, alerts and encryption checks
The monitoring team recreates dashboards and alerts that depended on Calico metrics, and it adds Cilium or Calico flow and health data to the logging pipeline. The security team verifies that encryption is active on pod-to-pod traffic, using the verification method the vendor documents for the chosen mode. Output: a dashboard and alert inventory that replaces the old one, plus a signed encryption check. Dashboards built for the old CNI are retired only after the new ones show equivalent signals.
Retire the old CNI and document the result
After every node runs the target CNI and a soak period passes without unresolved incidents, the team removes the old CNI components, leftover configuration, custom resources and firewall rules. They update the cluster build documentation, the configuration baseline and the evidence folder used for compliance reviews. Output: a clean cluster with one CNI, a retirement record and a tested rollback procedure kept on file for the next change. Confirm removal steps with the vendor documentation for the version in use.
Where CNI implementation projects usually run long
Most of the effort in a Cilium or Calico project sits after the CNI installs cleanly. Installation during cluster bootstrap with kubeadm is the short step. The longer work is validating kube-proxy replacement, which means confirming that Cilium's eBPF service handling or Calico's eBPF data plane gives the same service reachability your workloads expect, and that NodePort, external traffic policy and health checks behave as before. Plan a parallel test cluster for this, and confirm each option against the current documentation for your chosen release rather than assuming defaults carry over from a blog post or an older cluster.
Policy is the next place schedules slip. Teams usually start by building policy from observed traffic: Hubble flow data for Cilium, or Calico flow logs for Calico, turned into CiliumNetworkPolicy or NetworkPolicy objects. The overrun comes from undocumented east-west traffic, such as node-level health probes, DNS to a non-standard resolver, sidecar traffic or a monitoring agent scraping pods across namespaces. Each missed flow becomes a broken workflow after enforcement. Ask the platform owner for a list of every namespace that talks to another, and run observation mode long enough to cover month-end batch jobs and failover drills. Windows node edge cases and encryption rollout (IPsec or WireGuard on Cilium, the equivalent options on Calico) add separate test matrices that are easy to underestimate.
Upgrades close the plan. Kubernetes requires kube-apiserver to move one minor version at a time, ahead of kube-controller-manager, kube-scheduler and kubelets, and kubelets may trail the API server by up to three minor versions. Your CNI upgrade must fit inside that sequence, so test the CNI version against every Kubernetes minor version you will run during the upgrade window. Also decide where Hubble or Calico flow data lands in your logging stack before go-live, because retrofitting log routing and retention after policy enforcement starts is the step teams most often postpone. Ask your implementation partner to write these checks into the fixed scope, with acceptance criteria per cluster.
Questions buyers ask before choosing a CNI
Is the CNI cost a license cost or an engineering cost?
For most teams the bigger cost is engineering time, not licensing. Both Cilium and Calico are open-source projects under Apache-2.0 (Cilium's BPF code is dual-licensed GPL-2.0 and BSD-2-Clause), so the software itself carries no license fee. The recurring costs sit in people: staff who learn the chosen data plane, tune network policy, run upgrades and troubleshoot flows. Calico's enterprise offering from Tigera and any vendor support contract are separate commercial decisions, so ask Tigera or a vendor for written pricing. When you request a quote from DeployOpen, the scope drives the figure: cluster count, policy complexity, observability requirements and upgrade cadence.
How much work does switching CNI on a running cluster take?
Switching CNI on a live cluster is disruptive and should be treated as a migration project, not a configuration change. Pod networking is replaced, so you need a maintenance window, a tested rollback path and a clear view of every NetworkPolicy, service and workload that depends on the current plugin. Cilium's kube-proxy replacement changes how services are load balanced, which adds a second variable. Plan for a staging cluster that mirrors production, run connectivity tests and confirm that observability tooling still receives data. The effort grows with cluster count and the number of policies in use. Confirm the exact procedure against each project's current documentation for your Kubernetes version.
Can our team choose and run a CNI without a partner?
A capable platform team can run either plugin without a partner, provided it has Kubernetes networking depth, access to a non-production cluster and time to test. Teams without that depth often benefit from an outside review of the design before go-live. DeployOpen plans, implements, hardens and documents self-hosted platforms inside the client's own infrastructure, and most engagements are fixed-scope with scope and deliverables agreed in writing before work starts. Ongoing upgrades and testing are available as retainers. Use the decision in this guide to test your own readiness: if nobody on the team has debugged a policy drop in production, scope a review or a pilot before you commit.
How long does a typical CNI implementation take?
No reliable duration figure applies to every environment, so ask for one based on your own cluster. The main drivers are the number of clusters, whether you are installing on a new cluster or migrating a running one, how many network policies exist and how much observability you need to build. Hardware and network topology matter too: bare metal, virtual machines and air-gapped networks each add their own steps. Kubernetes upgrade timing can also constrain the work, because the version skew policy requires kube-apiserver to be upgraded one minor version at a time before the other control plane components and kubelets. Ask any provider, including DeployOpen, for a written timeline tied to a defined scope.
Does choosing Cilium or Calico change how Kubernetes authenticates users?
No. The CNI handles pod networking and network policy, not user identity. Kubernetes authenticates users itself, using X.509 client certificates, bearer tokens including OpenID Connect and JWT tokens, webhook token authentication or an authenticating proxy. Your identity provider integration, kubeconfig setup and RBAC rules stay the same whichever plugin you run. Confirm this during testing by checking that a user's access is unchanged after the CNI switch. The Kubernetes authentication documentation describes each method in detail.
Does the CNI affect how Kubernetes Secrets are encrypted?
No. Secrets are stored unencrypted in etcd by default, and that stays true whether the cluster runs Cilium or Calico. You must configure encryption at rest for etcd separately, restrict list and watch access with least-privilege RBAC, or move sensitive values to an external store through the Secrets Store CSI Driver. Network policy can limit which pods reach the API server or other services, but it does not protect data already written to etcd. Include an etcd encryption check in your hardening review, and back up etcd using the documented etcdctl snapshot save procedure.
How DeployOpen helps choose, implement or migrate a Kubernetes CNI
DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, including Kubernetes clusters on virtual machines and bare metal. For Cilium vs Calico, we start from your network policy, observability and cluster requirements, then deliver a written, fixed-scope engagement you can review before any work begins.
How we scope
- Review your cluster topology, node operating systems and existing network policy inventory before recommending a CNI.
- Define in writing whether the work covers selection, a new install, or a migration from the other CNI.
- Agree on whether kube-proxy replacement, Hubble-style flow visibility or Calico's Windows and VPP data planes are in scope.
How we build
- Deploy the chosen CNI in a lab cluster that mirrors your node counts, kernel versions and routing design.
- Translate existing Kubernetes NetworkPolicy and any Calico or Cilium policy objects into tested, version-controlled manifests.
- Run connectivity, policy and failure tests, and security testing on the cluster where your scope includes it.
How we hand over
- Deliver installation and configuration documentation, including upgrade and rollback steps for the CNI and its kernel dependencies.
- Document policy ownership, observability settings and the evidence you can supply to internal or external assessors.
- Walk your platform and security teams through runbooks so they can operate the network layer without us.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial engagement.
- Retainers can cover CNI version upgrades aligned with your Kubernetes version skew window and release schedule.
- Ask us to confirm the vendor support terms for your chosen CNI and any paid edition before you sign.
