Pods need to talk to each other. The CNI plugin is the thing that makes that work. Most clusters use whatever the managed Kubernetes service provides — AWS VPC CNI on EKS, Calico on GKE, Azure CNI on AKS — and that is usually fine. When it is not, the choice of CNI plugin determines what kinds of networking, observability, and policy you can have.
This post is the practical comparison of the major CNI options: when defaults are enough, when to switch, and what each one gives you.
What a CNI Plugin Actually Does
CNI — Container Network Interface — is the specification for how container runtimes set up pod networking. The plugin handles:
- Assigning IP addresses to pods
- Setting up routes so pods can reach each other and the outside world
- Implementing NetworkPolicy (the Kubernetes object for "can pod A talk to pod B")
- Possibly providing observability, encryption, or advanced features
Different CNI plugins implement this in dramatically different ways. The choice affects performance, debugging, and what features are available.
The Major Options
Calico
The most-deployed CNI for self-managed Kubernetes. Mature, well-documented, supports both Linux netfilter and eBPF data planes.
Strengths:
- Mature NetworkPolicy support
- BGP-based routing (works at any scale)
- eBPF mode for performance
- Strong documentation and ecosystem
Weaknesses:
- BGP can be unfamiliar to teams without networking background
- More configuration surface than simpler alternatives
Calico is the safe default for self-managed Kubernetes.
Cilium
The newer entrant, but rapidly becoming the default in 2026. Built on eBPF from the ground up.
Strengths:
- eBPF-native (significant performance and observability advantages)
- Hubble (observability layer) shows every pod-to-pod connection
- L7 (HTTP, gRPC) network policies, not just L3/L4
- Replaces kube-proxy entirely on modern clusters
Weaknesses:
- Higher kernel version requirements (eBPF features)
- Steeper learning curve for advanced features
Cilium has become the default CNI for several managed services (GKE Dataplane V2, AKS) because of its eBPF capabilities.
AWS VPC CNI
The AWS-native CNI for EKS. Pods get real VPC IPs from the AWS subnet.
Strengths:
- Pods are first-class VPC citizens (security groups apply, AWS networking just works)
- No overlay network, no encapsulation overhead
- Default on EKS
Weaknesses:
- IP exhaustion in busy clusters (one IP per pod from VPC pool)
- NetworkPolicy support requires installing Calico alongside
- AWS-specific
For most EKS clusters, the VPC CNI works fine. The IP exhaustion concern matters at very large scale.
Flannel
The simplest CNI. Provides basic overlay networking.
Strengths:
- Easy to set up
- Low operational burden
- Good for small clusters
Weaknesses:
- No NetworkPolicy support
- Limited observability
- Less suitable for production at scale
Flannel is a development/learning CNI. Production deployments outgrow it quickly.
Other Mentions
- Cilium-CNI / Calico are most common in 2026.
- Weave Net was popular but has stagnated; not recommended for new deployments.
- kube-router is lightweight and simple but smaller community.
- Antrea (VMware) has VMware-specific advantages but smaller general adoption.
When the Default Is Fine
If you are on a managed Kubernetes service (EKS, GKE, AKS), the default CNI is usually fine:
- Standard pod-to-pod networking works
- Basic NetworkPolicy works (sometimes with an addon)
- The cluster networks integrate with the cloud's broader networking
Switching off the default is operational work. The gain has to justify it.
When to Switch
Concrete reasons to switch from the default:
Performance. You need higher throughput, lower latency, or fewer CPU cycles per packet than the default offers. Cilium's eBPF data plane is meaningfully faster than iptables-based alternatives for high-throughput services.
Observability. You need to see pod-to-pod traffic without instrumenting applications. Cilium's Hubble provides this; the default CNIs do not.
L7 policies. You want to enforce policies based on HTTP paths, methods, or gRPC services. Cilium supports L7 policy; most others do not.
IP exhaustion. Your cluster has more pods than the AWS VPC CNI can support. Switching to a CNI with smaller IP allocation (Calico in IPAM mode) or with an overlay network solves it.
Encryption. You need transport-level encryption between nodes without a service mesh. Cilium and Calico both support WireGuard-based encryption.
Cross-cluster networking. Multi-cluster pods communicating directly. Cilium Cluster Mesh handles this; most others do not.
NetworkPolicy
NetworkPolicy is Kubernetes' API for "which pods can communicate." Most CNIs support it, but the support varies.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: db-access
spec:
podSelector:
matchLabels: { app: database }
ingress:
- from:
- podSelector:
matchLabels: { tier: backend }
ports:
- port: 5432
This policy says only pods labeled tier=backend can reach the database on port 5432.
CNI support:
- Calico, Cilium: full NetworkPolicy support, plus extensions for L7 policy.
- AWS VPC CNI: requires installing Calico alongside, or use the newer AWS Network Policy support.
- GKE default: supports NetworkPolicy if explicitly enabled.
- Flannel: no NetworkPolicy support.
For any production cluster: NetworkPolicy support is essential. Defaulting to "allow all" between pods is a security failure waiting to be exploited.
Performance Comparison
In rough numbers, for typical workloads:
- AWS VPC CNI (no overlay): highest performance, lowest CPU.
- Cilium (eBPF): very close to AWS VPC CNI performance, with more features.
- Calico (iptables): good performance, more CPU under heavy NetworkPolicy.
- Calico (eBPF): comparable to Cilium.
- Flannel: good for small clusters, less optimized for scale.
For most workloads, the differences are noticeable in benchmarks but not in user-visible performance. For very high-throughput services, eBPF CNIs are measurably faster.
Operational Complexity
What it takes to operate each in production:
- AWS VPC CNI: managed by EKS. Low operational burden, low flexibility.
- GKE default Calico/Cilium: managed by GKE. Low burden.
- Self-managed Calico: moderate. Some BGP knowledge useful for large deployments.
- Self-managed Cilium: moderate-to-high. eBPF requires understanding more of the kernel.
- Flannel: lowest, but feature-limited.
For teams without dedicated network expertise, sticking with the managed default is usually the right call. Cilium's eBPF features are powerful but require investment to operate well.
Picking a CNI
For a managed Kubernetes service: start with the default. Move to something else only if you have a specific reason.
For self-managed Kubernetes: Calico or Cilium. Calico if simplicity and broad maturity matter most; Cilium if eBPF features are valuable.
For specific scenarios:
- High-throughput, latency-sensitive: Cilium or AWS VPC CNI.
- L7 policy needs: Cilium.
- Tight VPC integration on AWS: AWS VPC CNI.
- Cross-cluster pods: Cilium Cluster Mesh.
Migration
CNI migration is painful. The CNI affects every pod; switching requires rolling every node.
Two patterns:
In-place migration. Drain a node, replace the CNI, re-add the node. Works but is delicate; one mistake takes down the cluster.
New node group migration. Spin up a new node group with the new CNI, cordon and drain the old node group, migrate workloads. Safer, more capacity overhead during transition.
A real CNI migration takes a few days of careful operational work. Plan it like a major change, not a routine update.
What the Future Looks Like
eBPF-based CNIs (Cilium, Calico eBPF mode) are the direction. The performance and observability advantages compound. New deployments increasingly start there.
The AWS VPC CNI remains the default for EKS, with NetworkPolicy support catching up to alternatives. For most EKS clusters, that combination is sufficient.
CNI matters less than it used to, in one sense: defaults are now genuinely good. CNI matters more than it used to, in another: features like L7 policy and Hubble observability are only available with specific CNI choices.
Evaluating CNI options for a new cluster, or considering switching from the default? We help teams scope CNI decisions based on actual networking needs. scopeforged.com