Demystifying Kubernetes Service Implementation: Load Balancing, Sidecars, and iptables

Kubernetes services are essentially load balancers or reverse proxies that expose a virtual IP and port, forwarding traffic to a set of backend Pods, each with its own IP and port.

Rather than deploying a single dedicated load‑balancing node, Kubernetes implements the proxy as a sidecar on every cluster node. Each node runs a reverse‑proxy sidecar that intercepts service traffic and forwards it to the appropriate Pod, mirroring the sidecar pattern used in service meshes.

The controller that configures these sidecars is kube‑proxy . kube‑proxy watches the API server for service creation events and translates service specifications into proxy configuration rules.

Service traffic is handled by DNAT (Destination NAT): packets sent to the service IP/port are rewritten to the IP/port of a selected backend Pod. This rewrite must occur before routing, so kube‑proxy injects DNAT rules into the PREROUTING and OUTPUT chains of the netfilter framework.

Netfilter provides a filter framework with five hook points (PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING). By adding NAT rules at PREROUTING (for Pod‑to‑service traffic) and OUTPUT (for host‑to‑service traffic), the service IP is translated to the target Pod IP, after which normal routing forwards the packet.

iptables implements netfilter tables and chains. Kubernetes creates custom chains such as KUBE‑SERVICE (entry point for all services), KUBE‑SVC‑XXXX (per‑service chain), and KUBE‑SEP‑XXXX (per‑endpoint chain). The service chain randomly jumps to an endpoint chain, achieving load‑balancing.

To make the filter framework more modular, netfilter uses tables to separate filtering logic from the packet pipeline. Custom chains allow complex rules to be organized and reused, decoupling the processing logic from the fixed hook points.

The article also uses analogies (water‑pipe filtering) to illustrate why fixing the insertion points (hook locations) and abstracting processing steps (chemical vs. physical changes) leads to a cleaner, more maintainable design.

In summary, Kubernetes services rely on per‑node sidecar proxies managed by kube‑proxy, which program iptables/netfilter to perform DNAT at PREROUTING and OUTPUT, effectively turning the service IP into a load‑balanced endpoint selector.