Kubernetes Service Traffic Architecture

Kubernetes Service Traffic Architecture explains how services route traffic within a cluster using DNS, IP, and load balancing for reliable communication.

Kubernetes Service Traffic Architecture is the concrete path a packet actually travels from a client to a backend Pod when addressed to a Service, tracing the specific data-plane mechanism, iptables rules, IPVS virtual servers, or eBPF programs, that kube-proxy or an equivalent component programs on each node to implement that redirection, and how this path differs depending on Service type and the traffic's point of origin. Where Service definition describes the abstraction a client relies on, Service traffic architecture describes the actual packet-level mechanics that make that abstraction real.

iptables-Mode Traffic Path

Chain Structure

In iptables mode, kube-proxy formally programs a hierarchy of custom iptables chains: a top-level KUBE-SERVICES chain matches packets destined for any Service's virtual IP and jumps to a per-Service chain, which in turn uses probabilistic matching to jump to one of several per-endpoint chains, each performing destination NAT to a specific backend Pod's real IP address.

iptables -t nat -L KUBE-SERVICES -n
iptables -t nat -L KUBE-SVC-XXXX -n
iptables -t nat -L KUBE-SEP-XXXX -n

packet \to KUBE-SERVICES \to KUBE-SVC-* \to KUBE-SEP-* \to DNAT to pod IP

Rule Regeneration on Change

kube-proxy in iptables mode formally regenerates the complete relevant rule set whenever it observes a change to a watched Service or EndpointSlice, rather than performing an incremental, single-rule update, an architectural choice that trades update latency at very large Service counts for simplicity of implementation.

IPVS-Mode Traffic Path

Virtual and Real Servers

In IPVS mode, kube-proxy formally creates one IPVS virtual server per Service IP and port, and one real server entry per backend endpoint, relying on the Linux kernel's IP Virtual Server subsystem to perform load balancing using an actual, purpose-built load-balancing data structure rather than sequential rule matching.

ipvsadm -L -n
ipvsadm -L -t 10.96.0.10:80 -n

packet \to IPVS virtual server \to scheduler selects real server \to forward to pod IP

Selectable Load-Balancing Algorithms

IPVS mode formally exposes a choice of scheduling algorithms, round-robin, least connection, and others, at the kernel level, a capability iptables mode's rule-based matching does not architecturally provide.

eBPF-Based Traffic Path

Programmatic Packet Redirection

An eBPF-based data plane formally attaches programs at defined kernel hook points, such as tc (traffic control) or XDP (eXpress Data Path), that inspect and redirect Service-destined packets directly within the kernel's packet-processing path, without traversing traditional netfilter/iptables rule chains at all.

cilium service list
cilium bpf lb list

packet \to eBPF hook (XDP/tc) \to lookup service map \to redirect to pod

Traffic Path by Service Type

ClusterIP

Traffic to a ClusterIP Service is formally intercepted and redirected entirely within the cluster's internal data plane, matched against the Service's virtual IP by whichever mechanism, iptables, IPVS, or eBPF, kube-proxy is configured to use on the originating node.

NodePort

Traffic arriving at a node's NodePort is formally captured by the same data-plane mechanism at the point of ingress to that node, then redirected identically to how ClusterIP traffic is handled, potentially forwarding the packet on to a different node entirely if the selected backend Pod does not reside on the node that received the traffic.

externalTrafficPolicy

The externalTrafficPolicy field formally controls whether NodePort/LoadBalancer traffic may be forwarded to a Pod on a different node (Cluster, the default, offering better load distribution) or must be forwarded only to a Pod on the same node that received the traffic (Local, preserving the original client source IP but limiting load distribution to nodes actually hosting a backend Pod).

spec:
  type: LoadBalancer
  externalTrafficPolicy: Local

Local : preserve source IP, Cluster : preserve load balance

Source IP Preservation

NAT and Its Consequence

Because destination NAT rewrites the packet's destination address, and in some configurations its source address as well (source NAT, or masquerading), the backend Pod may formally observe a different source IP than the original client, a consequence directly tied to the specific traffic path and externalTrafficPolicy configuration in effect.

kubectl exec -it debug-pod -- curl -s ifconfig.me

Why Traffic Architecture Varies by Implementation

Because kube-proxy's underlying data-plane mechanism is itself a configurable, pluggable choice, iptables, IPVS, or an entirely separate eBPF-based dataplane, the exact packet path a given cluster uses to realize the Service abstraction is an implementation detail below the Service API itself, chosen based on the performance, feature, and operational tradeoffs each mechanism presents at the specific scale and workload pattern a cluster is running.