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.