kube-proxy and iptables vs IPVS modes
How Service virtual IPs actually route.
kube-proxy watches Services/endpoints and programs node rules so ClusterIP traffic is DNAT'd to a backend Pod; iptables uses sequential rule chains, IPVS uses a hash table with real…
What's really being asked
Deep networking knowledge: a ClusterIP is virtual and has no interface, so something must redirect packets to real Pods. That something is kube-proxy programming the kernel.
The full answer
kube-proxy runs as a DaemonSet on every node. It watches the API server for Services and their EndpointSlices and translates them into packet-rewriting rules in the node's kernel. When a Pod sends traffic to a Service's ClusterIP, those rules perform destination NAT, rewriting the destination to one of the healthy backend Pod IPs and load-balancing across them. The ClusterIP itself is never bound to a real interface; it exists only as a target in these rules. In iptables mode, kube-proxy creates chains of rules and selects a backend using random probability per rule; the downside is that matching is essentially sequential, so with thousands of Services the rule set grows large and rule updates and lookups slow down. In IPVS mode, kube-proxy uses the kernel's IP Virtual Server, which stores backends in a hash table and supports genuine load-balancing algorithms such as round-robin and least-connection, offering near-constant lookup time and far better performance at scale.
The mistakes people make
Claiming kube-proxy proxies every packet through userspace; the legacy userspace mode is obsolete, and modern modes work in the kernel. Saying iptables does real load balancing algorithms; it only does weighted random.
What usually comes next
When to prefer IPVS? Large clusters with many Services. What about eBPF dataplanes? Tools like Cilium can replace kube-proxy entirely. How are unhealthy Pods excluded? They are dropped from EndpointSlices.
A concrete example
A ClusterIP Service fronts five Pods. In iptables mode, a packet to the ClusterIP traverses a chain that with 20 percent probability each picks one of the five backends and DNATs to it. In IPVS mode, the same Service is a virtual server with five real servers in a hash table, balanced round-robin, which stays fast even as the cluster grows to thousands of Services.
Interview question
What is the main advantage of kube-proxy's IPVS mode over iptables mode in large clusters?
- a.IPVS removes the need for DNAT on Service traffic
- b.IPVS assigns a real network interface to each ClusterIP
- c.IPVS runs entirely in userspace for easier debugging
- d.IPVS uses a kernel hash table and real load-balancing algorithms, scaling better than linear iptables rule chainsCorrect
Why? this is the answer
IPVS uses an in-kernel hash table and algorithms like round-robin/least-conn, giving near-constant lookups versus iptables' growing linear chains. Both run in kernel and still rely on DNAT; ClusterIPs remain virtual.
Just read this? Test yourself on what you have been reading.
Read the original → kubernetes.io
- #kubernetes
- #kube-proxy
- #iptables
- #ipvs
- #networking
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles