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

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 IP, port, or protocol.

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.

iptables organizes rules through tables and chains. Common tables are:

filter – packet filtering (most used).

nat – network address translation.

mangle – modify IP‑layer fields.

raw – bypass connection tracking.

Typical chain flow:

Examples of packet flow:

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

POSTROUTING

Service Load Balancing Example

Three nginx pods are created and exposed via a ClusterIP service (IP 10.101.57.97). The following commands show the pods and service:

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 accessing the service with curl 10.101.57.97, the packet first hits the PREROUTING chain:

:PREROUTING ACCEPT [0:0]
-A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
-A PREROUTING -d 192.168.49.1/32 -j DOCKER_OUTPUT
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER

The KUBE-SERVICES chain contains a rule for the service IP that jumps to a service‑specific chain:

-A KUBE-SERVICES -d 10.101.57.97/32 -p tcp -m comment --comment "default/nginx-service cluster IP" -j KUBE-SVC-V2OKYYMBY3REGZOG

Inside KUBE-SVC-V2OKYYMBY3REGZOG the traffic is distributed:

-A KUBE-SVC-V2OKYYMBY3REGZOG ! -s 10.244.0.0/16 -d 10.101.57.97/32 -p tcp -j KUBE-MARK-MASQ
-A KUBE-SVC-V2OKYYMBY3REGZOG -m comment --comment "default/nginx-service -> 10.244.0.27:80" -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-POZMZY2HDLRATSJV
-A KUBE-SVC-V2OKYYMBY3REGZOG -m comment --comment "default/nginx-service -> 10.244.0.28:80" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-Z3HXRORN5VDCFRJU
-A KUBE-SVC-V2OKYYMBY3REGZOG -m comment --comment "default/nginx-service -> 10.244.0.30:80" -j KUBE-SEP-S46ZL6MIFVWDY42O

The three KUBE-SEP-* chains perform DNAT to the pod IPs and mark the packets for masquerading:

-A KUBE-SEP-POZMZY2HDLRATSJV -s 10.244.0.27/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-POZMZY2HDLRATSJV -p tcp -j DNAT --to-destination 10.244.0.27:80
... (similar rules for the other two pods) ...

The KUBE-MARK-MASQ chain sets the MASQUERADE mark (0x4000) which later triggers NAT processing.

ipvs Mode

IPVS (IP Virtual Server) is a kernel module that provides high‑performance layer‑4 load balancing. Using ipvsadm the rules for the same service appear as:

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 uses round‑robin scheduling, which is more efficient than the probabilistic matching used by iptables, especially when pods are added or removed frequently.

Even with ipvs enabled, iptables is still required for SNAT (MASQUERADE) of return traffic:

-A POSTROUTING -m comment --comment "kubernetes postrouting rules" -j KUBE-POSTROUTING
-A KUBE-POSTROUTING -m comment --comment "Kubernetes endpoints dst ip:port, source ip for solving hairpin purpose" -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.

Overall, kube-proxy’s iptables mode offers flexibility, while ipvs provides superior performance for large, dynamic clusters.