2.11 Kubernetes Service Traffic Architecture

Kubernetes Service Traffic Architecture is the specific internal mechanics of how traffic destined for a Service's virtual IP is actually intercepted and redirected to a backing Pod, describing the distinct modes kube-proxy can be architected to operate in and how each mode implements the same routing contract using different underlying kernel mechanisms.

The Routing Contract Shared Across Modes

One Behavioral Guarantee, Multiple Implementations

Regardless of which mode it runs in, kube-proxy is architected to fulfill the same contract: traffic sent to a Service's virtual IP and port must be transparently redirected to one of the IP addresses and ports of a currently healthy backing Pod, without the sending client needing any awareness of the redirection.

EndpointSlices as the Common Input

Every mode of kube-proxy is architected to derive its routing rules from the same input, the EndpointSlices associated with each Service, meaning the difference between modes lies entirely in how those rules are implemented, not in what data drives them.

iptables Mode Architecture

Rule Chains Evaluated Sequentially

In iptables mode, kube-proxy is architected to install a chain of packet-filtering rules into the node's kernel, with incoming packets destined for a Service IP matched against these rules sequentially until a redirect target is selected, probabilistically distributing traffic across backing Pods.

Rule Set Grows with Service and Endpoint Count

Because this mode represents each Service and its endpoints as discrete rule entries, its architecture means the total rule set, and the cost of updating it, grows roughly in proportion to the number of Services and endpoints in the cluster.

IPVS Mode Architecture

A Purpose-Built Kernel Load Balancer

In IPVS mode, kube-proxy is architected to use the kernel's IP Virtual Server subsystem, a component purpose-built for load balancing, storing Service-to-endpoint mappings in a hash table rather than a sequentially evaluated rule chain.

Constant-Time Lookup at Scale

This architecture gives IPVS mode a lookup cost that does not grow linearly with the number of Services and endpoints in the same way iptables mode does, making it architecturally better suited to clusters with very large numbers of Services.

Mode as a Configuration Choice, Not a Different Contract

Interchangeable at the Behavioral Level

Because both modes are architected to satisfy the same Service routing contract, switching between them changes performance and scaling characteristics but does not change the observable routing behavior experienced by client Pods sending traffic to a Service.

Traffic Path Diagram