Cilium vs Calico: Which Kubernetes CNI Should a Small Platform Team Pick in 2026?

Key Points:

• Pick Cilium if you run clusters on more than one cloud and have no dedicated networking engineer. Cilium is a CNCF Graduated project, Google built GKE Dataplane V2 on it, and AKS offers it as "Azure CNI powered by Cilium", so what you learn on one managed cluster carries over to the next.
• Pick Calico when compatibility and debuggability matter more than feature depth. Its iptables and nftables dataplanes can be traced with tcpdump and iptables-save, it runs on older kernels and odd distributions, and Tigera sells supported tiers with compliance reporting.
• For a three-person team on one cloud, pick neither. Use the dataplane your provider already installs and patches (Amazon VPC CNI on EKS, Azure CNI on AKS, GKE Dataplane V2, Cilium on Scaleway Kapsule) and write plain Kubernetes NetworkPolicy so your rules stay portable.
• Throughput benchmarks are the wrong tiebreaker at this size. Three questions decide it: who upgrades the CNI, how many people on your team can debug it at 2 a.m., and whether policy CRDs lock you to one dataplane.
• Flannel is out as a 2026 default for anything with tenants or an auditor. The flanneld binary does not enforce NetworkPolicy, so you end up bolting a second component on anyway.
• If nobody was hired to operate Kubernetes, stop choosing a CNI. An internal developer platform like Qovery creates and upgrades the cluster, networking stack included, in your own AWS, GCP, Azure or Scaleway account, or on the Kubernetes cluster you already run.

I have watched a four-person platform team spend a month arguing about eBPF while their deploy pipeline was broken. The CNI they finally picked was fine. The month was the real cost.

So here is the verdict up front. Cilium for multi-cloud. Calico for compatibility, iptables-level debugging and paid support. Your cloud's managed dataplane for a single cloud and a tiny team. A platform like Qovery when nobody on the team was hired to run Kubernetes.

Cilium vs Calico: what is the short answer for a team with no networking engineer?

Cilium is the better default in 2026 for small platform teams running more than one cluster or more than one cloud, because the managed Kubernetes services you are most likely to use already run it, and it bundles network policy, service load balancing and flow observability in one component. Calico is the better pick when you need maximum compatibility, debugging with standard Linux tools, or paid vendor support with compliance reporting.

A CNI decides four things for you: how pods get IP addresses, how NetworkPolicy is enforced, how Service traffic is load balanced (kube-proxy or a replacement), and how much you can see when a packet gets dropped. Everything else is detail.

Three questions settle the choice for a small team. Who upgrades it? Who can debug it at 2 a.m.? Does its policy model lock you in? This guide is not a throughput shootout. Most published CNI benchmarks come from the vendors themselves, and at four engineers your bottleneck is people, not packets per second.

How should a small platform team evaluate a CNI in the first place?

Rank CNIs on operational cost, not on features. The questions that matter are whether your managed Kubernetes service installs and patches it, whether an on-call generalist can trace a dropped packet with tools they already know, whether plain Kubernetes NetworkPolicy covers your compliance story, and who you can call at 3 a.m.

Here are the six criteria I use:

1. Who maintains it. If AWS, Google, Microsoft or Scaleway installs and patches it, that is free labour. If not, you are the maintainer on every cluster.
2. Debuggability. Count the people on your team who can read iptables-save output. Then count the people who can use Hubble and bpftool. The bigger number wins.
3. Policy model. Plain NetworkPolicy is portable. CRD-based L7, FQDN and identity rules are powerful, and you will rewrite them if you switch CNI.
4. Observability included. Flow logs and policy-drop visibility without buying a second product.
5. Multi-cloud consistency. Same YAML and same behaviour on every cloud, plus Cilium Cluster Mesh if you really need cross-cluster services.
6. Upgrade blast radius. How disruptive is a CNI upgrade on a live cluster, and can you roll it back?

I am deliberately not scoring raw throughput or exotic BGP topologies. Those matter for a telco. They do not matter for a four-person team shipping a SaaS product.

Which Kubernetes CNI should you pick in 2026? The shortlist at a glance

For a small platform team the 2026 shortlist is short: Cilium for multi-cloud consistency, your cloud provider's managed dataplane for a single cloud, Calico for compatibility and paid support, Flannel only for a throwaway dev cluster, and an internal developer platform when you would rather not own the cluster at all.

If you only read one thing:

• 1 to 4 engineers, one cloud: take the managed default and write plain NetworkPolicy.
• Multi-cloud, no networking engineer: Cilium, ideally the managed variant on each cloud.
• On-prem, older kernels, or a generalist on-call: Calico.

What is Cilium best at, and who should not pick it?

Cilium is the strongest default for multi-cloud small teams because it is CNCF Graduated and sits underneath GKE Dataplane V2 and the "Azure CNI powered by Cilium" mode in AKS, so the managed service maintains it while your knowledge stays portable. Skip it if your nodes run older kernels, if your managed service does not offer it, or if nobody on call is willing to learn eBPF tooling.

Cilium is an eBPF-based CNI that can replace kube-proxy entirely. Hubble gives you flow logs and a service map, and Cluster Mesh connects services across clusters. The CNCF announced Cilium's graduation on October 11, 2023, two years after it entered incubation.

The provider wording is unambiguous. Google says "GKE Dataplane V2 is implemented using Cilium" and that NetworkPolicy "is always on" (Google Cloud). Microsoft describes Azure CNI powered by Cilium as Azure CNI's control plane combined with Cilium's data plane, optional on AKS Standard and the default on AKS Automatic (Microsoft Learn). Scaleway supports Cilium on Kapsule (Scaleway docs). That is three clouds where someone else patches it.

Where it hurts:

• New tools. Your on-call needs the cilium CLI and Hubble, not iptables-save.
• Kernel floor. Cilium documents Linux 5.10 or later, or 4.18 on RHEL 8.10 (Cilium docs). Features like IPv4 BIG TCP need 6.3.
• Harder rollback. Once kube-proxy is gone, going back is a migration, not a toggle.
• Cluster Mesh is real work. It supports 255 clusters by default (511 with tuning), but needs non-overlapping pod CIDRs and node-to-node IP connectivity across clusters, usually VPN or peering (Cilium docs).

CiliumNetworkPolicy gives you L7, FQDN and identity rules. Treat it as a per-cluster extension and keep your baseline in plain NetworkPolicy. Even managed Cilium varies: on AKS, FQDN and L7 policies need the paid Advanced Container Networking Services add-on.

If you want a vendor on the hook, Isovalent Enterprise for Cilium is now Cisco's. Cisco announced the deal in December 2023 and completed it in April 2024.

Do not pick Cilium if your fleet includes old kernels, your on-call refuses new tooling, or your only cloud ships a different dataplane you are happy with.

What is Calico best at, and who should not pick it?

Calico wins when a dropped packet has to be traceable with tools your on-call already knows, and when the cluster lives somewhere unusual. Its iptables and nftables dataplanes behave like ordinary Linux networking, it supports a wide range of distributions and kernels, and Tigera sells supported tiers with flow visualisation and compliance reporting.

Calico is one of the longest-running production CNIs. It offers iptables, nftables, eBPF, VPP and Windows dataplanes, plus optional BGP peering (Calico docs). Tigera says Calico "powers 100M+ containers across 8M+ nodes in 166 countries" (same source, vendor figure).

Calico NetworkPolicy and GlobalNetworkPolicy extend Kubernetes NetworkPolicy with ordering and cluster-wide scope. The lock-in caveat is the same as with Cilium's CRDs.

The paid tiers, Calico Enterprise (self-managed) and Calico Cloud (SaaS), add a graph of traffic flows and policy enforcement, audit-ready compliance reports for frameworks like PCI DSS, HIPAA and SOC 2, DNS and L7 policy, and support (Tigera). Calico Cloud is also sold through the AWS, Azure and Google Cloud marketplaces. Tigera does not publish list prices on that page, so ask for a quote.

Two cases where Calico clearly beats Cilium:

• An on-prem cluster on an older kernel or an unusual distribution. Calico's iptables mode does not need a 5.10 kernel.
• An on-call rotation of generalists. If your backend engineers carry the pager, tcpdump and iptables-save beat bpftool every time.

Where it falls short for multi-cloud: no major managed service I checked ships Calico as its default dataplane. Google even calls Calico its "legacy dataplane" (Google Cloud). In practice you install and upgrade it yourself on most clusters, and the best observability sits behind the paid tier.

Do not pick Calico if you run on two or more managed clouds and want the provider to patch your dataplane, or if you want free flow observability out of the box.

Should you just use the CNI your cloud provider already manages?

Yes, if you run on one cloud and have fewer than five engineers. Taking Amazon VPC CNI on EKS, Azure CNI on AKS, GKE Dataplane V2 or Cilium on Scaleway Kapsule means someone else owns installation, patching and compatibility, and you keep portability by writing plain Kubernetes NetworkPolicy instead of vendor CRDs.

Sources: AWS network policy docs, EKS Auto Mode, Amazon EKS AMI eni-max-pods, AKS CNI overview, GKE Dataplane V2, Scaleway.

The Amazon VPC CNI trade-off is concrete. Pods get real VPC IPs and work with security groups for pods. In return, pod density is capped by ENI limits: a t3.medium tops out at 17 pods without prefix delegation. Network policies apply to EC2 Linux nodes only, not Fargate or Windows.

On EKS Auto Mode, AWS says it manages "Pod networking with network policy enforcement" (AWS). AWS does not say which dataplane it uses on that page, so I won't guess.

The portability rule: write baseline rules in plain Kubernetes NetworkPolicy and treat CRD policy as a per-cloud extension you accept you will rewrite. Self-installing only becomes unavoidable when you need cross-cloud Cluster Mesh, identical L7 or FQDN egress rules for compliance, or bare-metal clusters in the fleet.

For a three-person team, this is often a better answer than both Cilium and Calico.

Do Flannel, Antrea and the simpler CNIs still make sense?

Flannel still works for a single throwaway cluster that needs pod connectivity and nothing else, but flanneld does not enforce Kubernetes NetworkPolicy, so it fails the moment you have tenant namespaces, an egress rule or an auditor. Antrea is credible but has a much smaller operator pool than Cilium or Calico, which matters more than its feature list when your team is four people.

Flannel's README says "the flanneld binary does not natively enforce Network Policies" (Flannel). You can add enforcement with the Helm chart's netpol.enabled option or pair it with Calico, the old "Canal" combination. At that point you run two components to get what one CNI does natively.

Antrea is a CNCF Sandbox project built on Open vSwitch (CNCF), with strong Windows node support and roots in the VMware ecosystem. It works. Fewer engineers on the market know it.

Weave Net is off the list. Its repository was archived on June 20, 2024 and is read-only.

My rule of thumb: if you are seriously comparing CNIs, you already need policy enforcement, and that removes Flannel.

When is the right answer to not pick a CNI at all?

When nobody on the team was hired to operate Kubernetes, the CNI question is a symptom rather than a decision. An internal developer platform that creates and upgrades clusters inside your own cloud account (Qovery, or alternatives like Northflank BYOC and Porter) removes the decision instead of making it easier, because the platform owns the cluster lifecycle and the networking stack that comes with it.

Qovery creates and manages Kubernetes clusters in your own AWS, GCP, Azure or Scaleway account, and it also runs on an existing Kubernetes cluster you already have (Qovery docs). The cloud bill, committed-use discounts and data stay in your name.

What your engineers get instead of a CNI debate: git-push deployments, a preview environment per pull request, auto-stop for non-production environments, per-environment RBAC, and managed cluster upgrades.

To be clear about the boundary: Qovery is not a CNI and does not replace Cilium or Calico. It owns the cluster lifecycle, so your team is not the one choosing, installing and upgrading the dataplane. For what each managed cluster type includes, read the Qovery cluster docs rather than taking my word for it.

A platform is the wrong answer if you have a hard requirement for a specific dataplane, custom BGP peering, bare-metal networking, or a networking team that wants direct control. Run Cilium or Calico yourself in that case.

On the alternatives: Northflank BYOC and Porter also deploy into your cloud account and each trades away some control for convenience, so compare cloud coverage and how much of the cluster you can still touch. The DIY route of Terraform plus Argo CD gives you full control and makes you the maintainer of everything, CNI included.

How do I set this up from Claude Code or Cursor?

Hand the cluster-and-deploy step to your coding agent. Install the Qovery Agent Skills once, then ask in plain language for a cluster in your own cloud account and a deployment, and the agent proposes each action for your approval before it runs.

curl -fsSL https://skill.qovery.com/install.sh | bash

# Same install, scoped to the current project
curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

# Add the Qovery MCP Server to Claude Code (OAuth, read-only by default)
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

# Write access, only when you want it (also enable write access in the Qovery Console)
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills include qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview and qovery-builder. The skills deploy, and the MCP Server operates what already exists.

Then ask something like "create a Kubernetes cluster in my GCP account with Qovery and deploy this repo", and approve each step. Full setup is in the AI agent quickstart and the Claude Code integration page.