Kubernetes LoadBalancer Data Path

Kubernetes LoadBalancer Data Path describes the full traffic journey for a Service exposed with type LoadBalancer, spanning the external cloud load balancer that receives internet-facing traffic, the node-level NodePort mechanism it typically forwards through, and the final translation down to a specific backing pod.

External Provisioning Layer

Cloud Load Balancer Creation

When a Service is declared with type LoadBalancer, a cloud controller manager component watches for the new Service and provisions an external load balancer resource through the cloud provider's API, configuring it to forward traffic to the cluster's nodes. This external resource exists outside the cluster's own networking stack and is the true entry point for internet-facing traffic.

Backend Target Registration

The cloud controller registers either all cluster nodes or a subset of them as backend targets for the external load balancer, typically listening on the Service's NodePort, which means the LoadBalancer data path is layered directly on top of the NodePort data path rather than replacing it.

Traffic Flow Through the Layers

From Internet to Node

An external client sends traffic to the load balancer's public IP or DNS name. The cloud load balancer distributes incoming connections across its registered node targets using its own load balancing algorithm, which operates independently of and with no visibility into Kubernetes' own Service endpoint selection.

From Node to Pod

Once traffic arrives at a chosen node on the NodePort, it follows exactly the same interception, DNAT, and forwarding sequence as ordinary NodePort traffic, potentially being forwarded again to a different node if the locally selected endpoint does not reside on the node that received the external connection.

Health Checking

Node-Level Health Probes

The external load balancer periodically health-checks its registered node targets, typically against the NodePort itself or a dedicated health check port when external traffic policy is set to local, to determine which nodes are currently viable forwarding targets. A node that fails health checks is removed from the load balancer's rotation until it passes again.

Interaction with External Traffic Policy

When external traffic policy is local, the health check reports a node as healthy only if it currently hosts at least one ready backing pod, allowing the external load balancer to avoid sending traffic to nodes that would otherwise have to forward it elsewhere, which both improves latency and preserves the original client source IP end to end.

Source Address Preservation

Proxy Protocol and Passthrough Options

Some cloud load balancers support forwarding the original client IP through a proxy protocol header or by operating in a Layer 4 passthrough mode rather than terminating and re-establishing connections themselves. Whether source IP is preserved all the way to the backing pod depends on the combination of the cloud load balancer's mode and the Service's external traffic policy setting.

TLS Termination Placement

Depending on configuration, TLS termination for LoadBalancer-exposed Services can happen at the external cloud load balancer itself or be passed through untouched to be terminated inside the cluster, which changes where in the data path encrypted traffic becomes plaintext and has direct implications for certificate management responsibility.

Multi-Node Failure Resilience

Node Removal and Rebalancing

If a node is drained, removed, or becomes unhealthy, the cloud controller manager updates the external load balancer's backend target list accordingly, and the load balancer stops sending new connections to that node, though the exact behavior for connections already in flight depends on the specific cloud provider's implementation.

Cost and Provisioning Considerations

One External Resource per Service

Because each Service of type LoadBalancer typically provisions its own distinct external load balancer resource, clusters with many externally exposed Services can accumulate significant cloud infrastructure cost, which is one of the primary motivations for using an Ingress controller, itself exposed through a single LoadBalancer Service, to multiplex many application routes behind one external endpoint.