Kubernetes NodePort Data Path

Kubernetes NodePort Data Path describes the sequence of packet transformations a node applies when external traffic arrives on a Service's designated NodePort, from the moment it hits the node's physical interface to the moment it is delivered, rewritten, to a backing pod, which may reside on an entirely different node.

NodePort Exposure Mechanics

Port Binding on Every Node

When a Service is exposed as type NodePort, the cluster reserves a port from a configurable range, by default 30000 to 32767, and every node's data plane is programmed to listen for traffic on that port, regardless of whether the node hosts any of the Service's backing pods. This uniform binding is what allows an external client to reach the Service by sending traffic to any cluster node's IP on that port.

Interception Before Local Delivery

Unlike ordinary traffic destined for a node's own listening processes, traffic arriving on a NodePort is intercepted by the node's Service data plane rules before it would be delivered to any local socket, since no real process binds that port directly; the binding is virtual, implemented through the same packet filtering infrastructure used for ClusterIP interception.

Endpoint Selection and Rewriting

Local Versus Remote Endpoint Choice

Once intercepted, the data plane selects a backing pod endpoint using the same load balancing logic used for ClusterIP traffic. That endpoint may be local to the receiving node or may reside on a different node entirely, since NodePort does not guarantee that the node receiving external traffic also hosts a matching pod.

Destination Rewriting

The packet's destination is rewritten from the node's IP and NodePort to the selected pod's IP and target port, exactly as with ClusterIP DNAT, after which the packet is forwarded either directly to a local pod or across the cluster network to a pod on a remote node.

Source Address Translation

SNAT for Cross-Node Delivery

When the selected endpoint resides on a different node than the one that received the external traffic, the receiving node typically applies source network address translation, replacing the client's original source IP with its own, so that the return path from the backing pod correctly flows back through the same node that performed the original translation rather than attempting to route directly back to the external client.

External Traffic Policy Impact

Setting a Service's external traffic policy to local changes this behavior: the receiving node only forwards traffic to pods running locally, refusing connections if no local endpoint exists, and skips source address translation entirely, preserving the true client IP at the cost of uneven load distribution across nodes.

Health Check Node Ports

Local Endpoint Advertisement

When external traffic policy is set to local, cloud load balancers sitting in front of the NodePort Service need a way to know which nodes currently have local endpoints available, since sending traffic to a node without one would result in dropped connections. Kubernetes exposes a dedicated health check NodePort for this purpose, returning success only from nodes that currently host a ready backing pod.

Return Traffic Path

Reversing the Translation

As with ClusterIP traffic, connection tracking on the node that performed the original DNAT (and possibly SNAT) ensures that response traffic from the backing pod is correctly rewritten back to appear as though it originated from the node's IP and NodePort, so the external client's view of the connection remains consistent regardless of how many internal hops and rewrites occurred.

Operational Considerations

Port Range Exhaustion

Because the NodePort range is finite and shared cluster-wide, data path management includes tracking how many Services of type NodePort are allocated, since exhausting the available port range prevents new NodePort Services from being created until existing allocations are freed.

Firewall and Security Group Alignment

Since NodePort traffic arrives directly at a node's physical interface, the data path only functions correctly if external firewalls or cloud security groups permit inbound traffic on the relevant port range to every node that could plausibly receive it, a configuration detail that sits outside Kubernetes itself but is essential to the NodePort data path functioning at all.