Kubernetes ClusterIP Data Path

Kubernetes ClusterIP Data Path describes the precise sequence of packet transformations and forwarding decisions a node applies when a pod sends traffic to a Service's ClusterIP, from the moment the packet leaves the client pod's network namespace to the moment it arrives, rewritten, at a backing pod's interface.

Packet Origination

Client-Side Resolution

A client pod resolves a Service name to its ClusterIP through cluster DNS, then sends traffic to that address exactly as it would to any other IP. The pod's own network stack has no special awareness that the destination is a virtual address; from the pod's perspective, it is simply routing a packet to an IP outside its local interface, which it forwards to its default gateway inside its network namespace.

Interception at the veth Boundary

As the packet crosses from the pod's network namespace into the node's root namespace through the veth pair, it becomes subject to the node's packet filtering and NAT rules. This is the point where the ClusterIP data path diverges from ordinary routing, since the node's data plane, whether iptables, IPVS, or an eBPF hook, intercepts traffic matching the ClusterIP before any standard routing lookup would otherwise send it toward a nonexistent destination.

Destination Rewriting

DNAT to a Selected Endpoint

The intercepting rule performs destination network address translation, replacing the ClusterIP and Service port with the IP address and target port of one specific backing pod, chosen according to the data plane's load balancing algorithm. This selection happens once per new connection; established connections are tracked so that subsequent packets in the same flow are consistently rewritten to the same endpoint.

Connection Tracking

The node's connection tracking subsystem records the original ClusterIP destination alongside the rewritten pod destination for each active flow, which allows return traffic from the pod back to the client to be automatically un-translated back to appear as though it originated from the ClusterIP, preserving the illusion of a stable virtual endpoint from the client's perspective.

Path Divergence by Endpoint Locality

Same-Node Delivery

If the selected backing pod happens to reside on the same node as the client, the rewritten packet is delivered directly through the node's local bridge or routing table to the target pod's veth interface, without ever traversing the physical network.

Cross-Node Delivery

If the selected backing pod resides on a different node, the rewritten packet, now addressed to a real pod IP, is handed off to the standard cross-node pod networking path, whether that is overlay encapsulation or native routing, exactly as if the client pod had addressed the destination pod directly.

Source Address Handling

Preserving Pod Source Identity

For ClusterIP traffic, the client pod's original source IP is preserved throughout the data path, since source network address translation is not required when accessing a ClusterIP from within the cluster. This means the backing pod sees the true client pod IP as the connection source, unlike some external traffic paths where SNAT is applied.

Return Traffic Path

Reverse Translation

When the backing pod sends its response, the response packet's source address is the pod's own IP, not the ClusterIP. As this response traverses back through the node that performed the original DNAT, connection tracking recognizes the reply as belonging to the tracked flow and rewrites the source address back to the ClusterIP before delivering it to the client pod, ensuring the client only ever observes traffic to and from the stable virtual address.

Failure and Edge Case Handling

Endpoint Removal Mid-Connection

If a backing pod is removed from the Service's endpoint set while a connection to it is still active, most data plane implementations allow already-established connections to continue being routed to the now-removed endpoint until they terminate naturally, while ensuring new connections are routed only to currently valid endpoints.

No Available Endpoints

If a Service has no ready backing endpoints at all, the data path has no valid rewrite target, and the connecting client typically experiences a connection refusal or timeout, since there is no pod address to substitute for the ClusterIP destination.