Kube-Proxy Modes: Iptables vs. IPVS

What kube-proxy Actually Does

Before comparing modes, it helps to understand what kube-proxy is solving. A Service has one stable IP and potentially dozens of backing Pods whose IPs change constantly. kube-proxy's job is to intercept packets destined for the Service IP and redirect them to a real Pod IP — a process called DNAT (Destination Network Address Translation). The two main mechanisms for doing this are iptables and IPVS.

Mode 1: Iptables (The Default)

iptables is a Linux firewall and packet-filtering framework that has been part of the kernel since the late 1990s. kube-proxy uses it by writing rules into the kernel's NAT table, specifically the PREROUTING and OUTPUT chains.

When a new Service is created, kube-proxy writes a chain of rules like this:

1. A rule in KUBE-SERVICES matches the Service's ClusterIP and port, then jumps to a Service-specific chain (e.g., KUBE-SVC-XXXXXXXX).
2. Inside that chain, each backing Pod gets a rule with a probability weight. For three Pods, the first rule fires with 33% probability, the second with 50% of the remainder (effectively 33%), and the third catches everything else.
3. Each Pod-specific rule (KUBE-SEP-XXXXXXXX) performs the actual DNAT, rewriting the destination IP to the Pod's real IP.

The critical limitation is O(n) lookup complexity. iptables rules are evaluated sequentially. With 100 Services, a packet checks roughly 100 rules before finding its match. With 10,000 Services, it checks 10,000 rules. Every new TCP connection triggers this full traversal, burning CPU cycles proportional to cluster size.

Mode 2: IPVS (The High-Performance Alternative)

IPVS (IP Virtual Server) is a Linux kernel module in the netfilter subsystem, purpose-built for load balancing. It was originally designed for high-availability web clusters and predates Kubernetes by over a decade.

Instead of writing sequential firewall rules, kube-proxy configures IPVS virtual servers using a hash table data structure. The kernel computes a hash of the destination IP and port, looks up the entry directly, and finds the backend list in a single operation — O(1) complexity regardless of how many Services exist.

IPVS also supports richer load balancing algorithms beyond random selection:
- Round Robin (rr) — default, cycles through backends in order
- Least Connection (lc) — sends new connections to the backend with fewest active connections
- Source Hash (sh) — consistent hashing based on client IP, useful for session affinity

To enable IPVS mode, the node must have the ip_vs, ip_vs_rr, ip_vs_wrr, ip_vs_sh, and nf_conntrack kernel modules loaded, and the mode is set in the kube-proxy ConfigMap's KubeProxyConfiguration — setting mode: "ipvs" and, optionally, a non-default scheduler like least-connection.

The trade-off: IPVS is harder to inspect manually. Most engineers know iptables-save; fewer know ipvsadm. When debugging, you need to know which mode you're in before reaching for the right tool.