What are you actually choosing between?
The honest framing first: kube-proxy is not a CNI. A CNI plugin (Cilium, Calico, a cloud provider's plugin) wires pod networking; kube-proxy is the separate component that implements Service virtual IPs. The real 2026 decision is between the classic stack, provider CNI plus kube-proxy, and an eBPF dataplane that absorbs both jobs.
Three realistic configurations cover almost every production cluster:
- ▸Classic: cloud or default CNI for pod networking, kube-proxy (iptables, IPVS, or nftables mode) for Services, iptables for NetworkPolicy via an add-on.
- ▸Cilium: eBPF for pod networking, Service load balancing (kube-proxy replacement), NetworkPolicy including L7 rules, plus Hubble observability.
- ▸Calico: one policy and IPAM model with a choice of dataplanes, iptables, nftables, eBPF (which can also replace kube-proxy), and Windows HNS.
Choosing means matching those to your kernel versions, team skills, and policy requirements, not picking the one with the best conference talks.
What does an eBPF dataplane actually change?
eBPF moves packet decisions from long iptables chains into hash-map lookups attached to kernel hooks. Service resolution becomes roughly constant-time instead of degrading as rule counts grow, connection tracking gets cheaper, and the dataplane gains identity context, which pod, which policy, that iptables never had. The visible wins are tail latency at scale and per-flow observability.
Where it shows up in practice:
- ▸Service scale. kube-proxy in iptables mode appends rules per Service and endpoint; clusters typically feel sync latency and CPU cost once Services reach the low thousands. IPVS and the nftables backend (GA in Kubernetes 1.33) improve this substantially, eBPF sidesteps it.
- ▸Latency. Removing conntrack and chain traversal from the hot path typically shaves service-to-service p99, with direct server return and XDP acceleration available for NodePort and load-balancer traffic.
- ▸Observability. Flow logs with pod, namespace, and policy verdict context (Cilium's Hubble, Calico's flow logs) replace guesswork with evidence. We covered the mechanics in eBPF in Production: Rewiring Networking and Observability.
- ▸Security adjacency. The same instrumentation layer powers runtime detection, see Runtime Security with eBPF: Detecting Kubernetes Threats in 2026.
The cost: you need recent kernels (Cilium documents minimums; in practice you want 5.10 or newer), and debugging moves from iptables -L to bpftool and vendor CLIs, a real skills investment.
When is the default CNI plus kube-proxy fine?
Often. A cluster with a few dozen nodes, hundreds (not thousands) of Services, standard L3/L4 NetworkPolicy needs, and no multi-cluster ambitions runs perfectly well on the provider default. Every hop you do not customize is a hop your provider patches, upgrades, and supports. Do not adopt an eBPF dataplane to solve problems you do not have.
Signals that the default remains the right call:
- ▸Support boundaries matter. Managed add-ons keep the CNI inside the provider's support contract; a self-managed Cilium install on EKS moves networking incidents onto your on-call.
- ▸Windows nodes. eBPF dataplanes are Linux-only; mixed clusters need Calico's HNS dataplane or the provider default.
- ▸Team size. If nobody on the team can read a BPF map or a Hubble flow, the observability benefit is theoretical while the operational risk is immediate.
- ▸Scale honesty. The iptables scaling cliff is real but further away than vendors imply, and kube-proxy's nftables mode extends the runway. Most startups never reach it, the same sizing honesty argued in Kubernetes for Startups: When You Need It and When You Don't.
What does Cilium give you beyond networking?
Cilium, a CNCF-graduated project, bundles what used to be four add-ons: kube-proxy replacement, L7-aware NetworkPolicy (HTTP methods, paths, Kafka topics) enforced via Envoy, Hubble flow observability, transparent WireGuard or IPsec encryption, ClusterMesh for multi-cluster connectivity, and a Gateway API implementation for north-south traffic.
The consolidation is the argument: one Helm release replaces a CNI, kube-proxy, an ingress controller, a service-mesh-lite mTLS layer, and a flow-log agent. That reduces moving parts but concentrates risk, a Cilium upgrade now touches everything, so treat its version lifecycle with the discipline you apply to Kubernetes itself. If you operate several clusters, standardizing on one dataplane across the fleet pays compound dividends, as argued in From Pet Clusters to a Fleet: Multi-Cluster Kubernetes Without Snowflakes. Also relevant for EU teams: dual-stack support is mature, which matters if you are executing the plan in Shipping IPv6 in Production: A Pragmatic Dual-Stack Playbook.
Vendor context, stated plainly: Isovalent, Cilium's originating company, was acquired by Cisco in 2024. The project remains CNCF-governed with a broad contributor base, but factor commercial-support geography into procurement.
Where does Calico still win?
Calico wins on deployment breadth and routing pragmatism. It offers the same policy model across iptables, nftables, eBPF, and Windows dataplanes, first-class BGP peering with your physical network, flexible IPAM, and a long on-prem track record. For bare-metal clusters that must advertise pod or service routes to top-of-rack switches, it remains the default answer.
Specific strengths:
- ▸BGP as a feature, not an afterthought. Calico peers with datacenter fabrics to run non-overlay routed networking, no encapsulation tax, and load-balancer IPs advertised straight from nodes.
- ▸Dataplane portability. You can run the standard dataplane today and switch to Calico's eBPF mode (which also replaces kube-proxy) later without changing your policy objects.
- ▸Heterogeneous estates. Windows nodes, older kernels, and air-gapped environments, common in the industrial and public-sector work we do, are supported paths, not exceptions.
- ▸Policy depth. Tiered policies and a mature enterprise offering (Tigera's commercial tiers) suit organizations with formal network-security review processes.
Cilium has been closing gaps (it ships its own BGP control plane), but for BGP-centric on-prem builds Calico's operational maturity still typically carries the decision.
What is happening with managed Kubernetes defaults?
The center of gravity has moved. GKE's Dataplane V2, Cilium-based, has been the default for new clusters for years, and AKS ships Azure CNI powered by Cilium as a GA option. On EKS, the long-standing default has been the AWS VPC CNI plus kube-proxy, but public announcements in late 2025 signaled AWS moving toward Cilium for EKS networking. Verify current defaults in AWS documentation before planning.
What this means for your decision:
- ▸On GKE and AKS, choosing Cilium-derived networking is often just accepting the managed default, you get the eBPF dataplane inside the provider support boundary.
- ▸On EKS, the calculus is shifting mid-flight: self-managing Cilium today buys capability at the cost of support surface, while the managed path may converge on the same technology. If your cluster refresh is scheduled anyway, design for the direction of travel.
- ▸Skills transfer. As managed defaults converge on Cilium-based dataplanes, Hubble-and-eBPF operational skills become portable across clouds, a hiring and training argument, not just a technical one.
Attribute-checking note: default behavior differs by cluster mode, region, and creation date on every provider; confirm against provider documentation rather than blog posts, including this one.
How do you migrate a live cluster from kube-proxy to an eBPF dataplane?
Prefer blue-green at the cluster level: build a new cluster with the target dataplane, prove policy parity, and shift workloads gradually. In-place migration is possible, per-node rollout with kube-proxy replacement enabled, but it mixes dataplanes during the transition and demands careful validation of NetworkPolicy behavior and long-lived connections.
A sequence that has held up:
- ▸Policy parity first. Convert and test every NetworkPolicy against the new dataplane; run a policy test suite that asserts both allowed and denied flows, not just the happy path.
- ▸Watch conntrack semantics. Long-lived connections (databases, gRPC streams) may reset at cutover; schedule windows and enable graceful termination features where offered.
- ▸Node-by-node, then DNS. For in-place moves, cordon and migrate nodes in small batches, verifying flows in Hubble or flow logs at each step.
- ▸Keep kube-proxy manifests recoverable until the new dataplane has survived a full traffic cycle, including batch jobs and deploy storms.
- ▸Benchmark honestly. Measure service-to-service p99 with fortio or wrk, per-node CPU at steady state, and API-driven churn with kube-burner, before and after, typical gains are real but workload-dependent, and your own numbers beat any vendor chart.
How TuniCyberLabs helps
We design, migrate, and operate Kubernetes networking for EU and North African clients: dataplane selection studies with your traffic replayed against candidates, policy-parity test harnesses, staged kube-proxy replacement rollouts, and Hubble-based observability wired into your SOC. If a CNI decision or migration is on your roadmap, our engineering team can run the evaluation with you, with numbers from your workloads, not our slides.