How do requests to a ClusterIP service get routed to backend pods, and what component handles the load balancing?
Quick Answer
kube-proxy programs iptables or IPVS rules on every node. Traffic to the ClusterIP virtual IP is DNAT-ed to a randomly selected healthy pod IP. No actual proxy process sits in the data path.
Detailed Answer
A ClusterIP service has no running process. It is a virtual IP that exists only in iptables/IPVS rules:
1. Control plane assigns a ClusterIP from the service CIDR. 2. Endpoints controller watches pods matching the service selector and maintains EndpointSlice objects with pod IPs. 3. kube-proxy on every node watches Services and EndpointSlices, programs iptables DNAT rules mapping ClusterIP:port to pod IPs. 4. When a pod sends traffic to ClusterIP, the kernel matches the iptables rule, randomly selects a backend pod IP, rewrites the destination. No userspace proxy involved. 5. CoreDNS resolves service-name.namespace.svc.cluster.local to the ClusterIP.
Key: kube-proxy does NOT proxy traffic. It only programs rules. Load balancing is iptables (random) or IPVS (round-robin, least-connections). Readiness probes matter because unready pods are removed from EndpointSlices.
Code Example
sudo iptables -t nat -L KUBE-SERVICES -n | grep my-service kubectl get endpointslices -l kubernetes.io/service-name=my-service -o wide kubectl get cm kube-proxy -n kube-system -o yaml | grep mode
Interview Tip
The key insight: kube-proxy does NOT proxy. It programs kernel rules. Explain: DNS -> ClusterIP -> iptables DNAT -> Pod IP. Mention iptables vs IPVS modes.