kube-proxy: iptables vs IPVS
How does kube-proxy pick a backend, and why does the mode matter at scale? In iptables mode a packet to a ClusterIP walks KUBE-SERVICES into a per-Service chain that picks an endpoint by probability, then a per-endpoint chain DNATs it to the Pod. IPVS mode makes the same choice with an in-kernel hash table, trading the rule walk for constant-time lookup, though v1.35 deprecates it in favour of nftables. Either mode turns the ClusterIP into one chosen backend.
Play the animation 3 steps, animated, best on a wide screen
kube-proxy: iptables vs IPVS, step by step
-
In iptables mode the packet walks a chain box by box. It enters KUBE-SERVICES, jumps to the per-Service KUBE-SVC chain that picks an endpoint by statistic random, then a KUBE-SEP chain DNATs it to that Pod, here 10.244.2.7. The kernel walks these rules in sequence, so the chain grows O(n) with the number of Services.
Play from step 1 -
In IPVS mode the same kind of connection skips the walk. The Service is a virtual server and its endpoints are real servers in an in-kernel hash table, so a backend is found in one constant-time lookup no matter how many Services exist, here 10.244.3.9, picked by a scheduling algorithm such as round-robin, the default, or least-connection.
Play from step 2 -
Either mode turns the ClusterIP into a ready backend, and what scale exposes is the lookup. With thousands of Services the iptables chain is thousands of rules long and every new one slows the walk, while the IPVS hash stays one step. Large clusters long preferred IPVS for that, but it has been deprecated since v1.35 and may be removed in a future release, with nftables as its replacement.
Play from step 3