Q: What is kube-proxy, how does it handle Service routing, and what are the differences between iptables, IPVS, and eBPF mode?
Deep architectural explanation of how kube-proxy programs node-level networking to route ClusterIP service traffic to backend Pods using iptables, IPVS, and modern eBPF.
🛠️ Production Runbook & Step-by-Step Resolution
iptables Mode Mechanics & O(n) Scaling Limits
In iptables mode, kube-proxy creates chains in the NAT table. For every Service, it adds sequential rules using the statistic module for random load balancing. However, iptables evaluates rules sequentially—in clusters with 5,000+ services, packet evaluation overhead causes severe CPU spikes and latency.
iptables -t nat -L KUBE-SERVICES -n -v
iptables -t nat -L KUBE-SVC-XYZ -n -vIPVS Mode & O(1) Hash Table Routing
IPVS (IP Virtual Server) is a transport-layer load balancer built into the Linux kernel. It uses hash tables (O(1) lookup complexity) that maintain consistent throughput regardless of whether the cluster has 10 services or 50,000 services.
eBPF (Cilium / Kube-Proxy Replacement)
Modern CNI solutions like Cilium completely replace kube-proxy using eBPF programs attached to Linux socket layers (sockops) and tc (traffic control), bypassing the entire netfilter/iptables subsystem for near-native wire speeds.
- kube-proxy watches Services and EndpointSlices to program Linux kernel forwarding tables.
- iptables mode: uses sequential rule evaluation; fine for small clusters but suffers O(n) latency at scale.
- IPVS mode: uses in-kernel hash tables with O(1) lookup performance for enterprise-scale clusters.
- eBPF mode (Cilium): bypasses iptables/netfilter completely at the socket layer for maximum throughput.