Did you know Kube-proxy doesn’t perform load-balancing itself? It’s iptables (by default).
If you’ve run applications in Kubernetes, you’ve probably heard of Kube-proxy, the service responsible for routing traffic to Services.
But the interesting twist is that Kube-proxy doesn’t perform the routing, and iptables does (or IPVS, or nftables).
⚙️ How it works:
When you define a Service, Kubernetes will assign it an IP address.
Kube-proxy watches for these events and creates iptables rules that handle routing.
The iptables rules will:
- Forward new connections with a destination of the Service IP to a Pod IP
- Use the statistics module to select which Pod IP to forward the connection to
I like to think of it as follows: Kube-proxy identifies the need for routing, and iptables does the work.
🤔 Why it’s important:
If you plan to use gRPC, this is critical to understand.
gRPC uses HTTP/2 as its underlying protocol, which sends multiple requests down a single connection.
Since iptables forwards traffic at a connection level (layer 4), multiple requests down a single connection will all land on the same pod, even if more are available.
You might assume traffic will be balanced across pods, and be surprised to find it is not.
You're fine if you use HTTP/1.1 (without connection reuse). But anything that keeps long-lived connections open or sends multiple requests down a single connection, Kube-proxy won’t cut it.
🔭 What’s Next:
Scaling has been a challenge for iptables, as having lots of rules and connection tracking are known bottlenecks.
IPVS and nftables (iptables successor) have been introduced as new options for routing and load-balancing.
Both are still layer 4.
If you need layer 7 (request level routing), that’s where Istio comes in.
🧠 Final Thoughts:
Understanding Kube-proxy, iptables, and gRPC & HTTP/2 work is essential for anyone building fast, scalable backend systems on Kubernetes.
You can’t optimize what you don’t understand.
🔗 References:
Here are some reference links for those looking for a deeper dive.