How kube-proxy Uses iptables and ipvs for Service Load Balancing in Kubernetes

kube-proxy Overview

kube-proxy

is one of the components responsible for service discovery and load balancing in a Kubernetes cluster. It runs on each node as a network proxy for Service resources and operates in two modes: iptables and ipvs.

iptables Mode

iptables

is a user‑space utility in Linux that configures kernel packet‑filtering and NAT rules. Its main functions include:

Firewall – filter or reject packets based on custom rules.

NAT – map private network addresses to external IPs.

Port forwarding – forward traffic from one interface to another.

Load balancing – use DNAT to forward traffic to multiple backend servers.

Rules are organized into tables and chains. Common tables are filter, nat, mangle, and raw. The typical packet flow is:

Examples of flow paths:

To a local process: PREROUTING → INPUT Forwarded by the node: PREROUTING → FORWARD → POSTROUTING Response from a local process:

OUTPUT → POSTROUTING

Service Load Balancing with iptables

Assume three nginx pods and a ClusterIP service (IP 10.101.57.97).

k get pod -owide
NAME                                 READY   STATUS    RESTARTS   AGE   IP            NODE
nginx-deployment-59f546cb79-2k9ng   1/1     Running   2          50m   10.244.0.28   minikube
nginx-deployment-59f546cb79-wfw84   1/1     Running   2          50m   10.244.0.30   minikube
nginx-deployment-59f546cb79-zr9xm   1/1     Running   2          50m   10.244.0.27   minikube

k get svc nginx-service
NAME           TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
nginx-service  ClusterIP   10.101.57.97   <none>        80/TCP    29m

When a client curls the service IP, the packet first hits the PREROUTING chain and matches the automatically generated KUBE‑SERVICES chain:

-A KUBE-SERVICES -d 10.101.57.97/32 -p tcp -j KUBE-SVC-V2OKYYMBY3REGZOG

The KUBE‑SVC‑V2OKYYMBY3REGZOG chain contains three rules that forward traffic to the three pod endpoints with equal probability (33.33% each):

-A KUBE-SVC-V2OKYYMBY3REGZOG -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-POZMZY2HDLRATSJV
-A KUBE-SVC-V2OKYYMBY3REGZOG -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-Z3HXRORN5VDCFRJU
-A KUBE-SVC-V2OKYYMBY3REGZOG -j KUBE-SEP-S46ZL6MIFVWDY42O

Each KUBE‑SEP‑* chain marks the packet with KUBE‑MARK‑MASQ and then DNATs it to the corresponding pod IP and port, e.g.:

-A KUBE-SEP-POZMZY2HDLRATSJV -p tcp -j DNAT --to-destination 10.244.0.27:80

ipvs Mode

IPVS

(IP Virtual Server) implements load balancing in the Linux kernel at layer 4, using scheduling algorithms such as round‑robin (rr). Example output:

TCP  10.101.57.97:80 rr
-> 10.244.0.27:80  Masq  1 0 0
-> 10.244.0.28:80  Masq  1 0 0
-> 10.244.0.30:80  Masq  1 0 0

IPVS provides higher performance because it uses a single scheduling decision instead of evaluating many iptables percentage rules, and it scales better when pods are added or removed frequently.

Combining ipvs with iptables NAT

Even when ipvs is enabled, iptables rules are still needed for SNAT/MASQUERADE of return traffic:

-A POSTROUTING -j KUBE-POSTROUTING
-A KUBE-POSTROUTING -m set --match-set KUBE-LOOP-BACK dst,dst,src -j MASQUERADE

The KUBE-LOOP-BACK ipset contains the pod IPs, ensuring that packets returning from a pod have their source address rewritten to the node’s address so the client receives the correct response.

Summary

kube-proxy can operate in iptables or ipvs mode. The iptables mode builds a chain of rules that probabilistically forward traffic to pod endpoints, while ipvs uses kernel‑level round‑robin scheduling for better performance. Regardless of the mode, iptables SNAT rules remain essential for proper return‑path handling.