The Quiet End of kube-proxy: Kubernetes Networking Grows Up
For a decade, one unglamorous DaemonSet has been the thing that makes a Kubernetes Service actually work. You create a ClusterIP, and kube-proxy walks a chain of iptables rules on every node to steer packets to a pod. Simple, reliable, and — past a few thousand services — slow. That era is ending. Kubernetes is quietly replacing its networking plumbing, and the deprecation schedule is already on the calendar.
The first lever is nftables — the same job, less friction.
iptables evaluates rules sequentially: one chain entry per Service, so packet processing grows linearly (O(n)) with the number of Services. Its successor, nftables, uses verdict maps to dispatch packets in near-constant (O(1)) time, keeping per-packet latency flat even in clusters with tens of thousands of Services.
The nftables backend for kube-proxy went alpha in Kubernetes 1.29, beta in 1.31, and hit GA in 1.33 (KEP-3866, led by SIG Network). iptables stays the default for compatibility, so switching is opt-in: set mode: nftables in the kube-proxy config, or pass --proxy-mode nftables. Amazon rates it the fix for the network latency that plagues large iptables clusters. It needs a Linux kernel 5.13 or newer, and the Amazon VPC CNI has supported it since v1.23.0.
The second lever — and the bigger change — is eBPF.
Where nftables makes the same rule-walk faster, Cilium's eBPF data plane removes kube-proxy entirely. Instead of running a DaemonSet that mangles packets on the wire, it attaches eBPF programs to connect(), sendmsg(), and recvmsg() at the cgroup level and rewrites the destination before a wire-format packet ever exists. No DNAT, no conntrack overhead; service lookup is a constant-time map lookup. Maglev hashing pins a given 5-tuple to the same pod, which matters for cache layers like Redis where random backend selection scatters requests.
The managed providers have already moved. Azure CNI Powered by Cilium is GA on AKS — those clusters don't run kube-proxy at all. Google's GKE Dataplane V2 is Cilium-based, and EKS supports Cilium as the primary CNI. The recommended path on all three is now eBPF.
The old IPVS backend is on the way out.
Beyond iptables and nftables, kube-proxy had a third Linux backend, ipvs, introduced to fix large-cluster performance. It's being retired. IPVS logged a deprecation warning in Kubernetes 1.35 (KEP-5495); the new KubeProxyIPVS feature gate defaults to true in 1.37, is planned to flip to false in 1.40, and is scheduled for removal — LockToDefault — in 1.43, after which the ipvs mode will no longer exist. The migration targets are nftables or, more strategically, a full eBPF data plane.
Now the honest counterpoint.
The move isn't free, and it isn't right for every cluster. On a one-to-three-node setup, stock kube-proxy on iptables can beat Cilium on latency for pure pod-to-pod traffic — the eBPF overhead doesn't pay for itself on a couple of hundred Services worth of conntrack table. Cilium also costs more to operate: it wants a modern kernel, adds knobs, and eBPF incidents are harder to debug than reading iptables rules. The common guidance is that replacing kube-proxy starts to justify itself around five nodes or roughly a hundred Services.
So the near-term picture is two-track. Fresh clusters that aren't ready for a full CNI get the fast, incremental win — mode: nftables, one flag, no new moving parts. Clusters that need scale, identity-based policy, or a production-grade data plane go eBPF. The default isn't flipped yet, but kube-proxy's rule-chain era — the iptables bridge that carried Kubernetes through its first decade — is winding down. The only question left is which exit you take.