Kubernetes Service Traffic Policy Management

Kubernetes Service Traffic Policy Management refers to the deliberate configuration and ongoing governance of the fields that control how traffic is distributed across a Service's backends and across the cluster's topology, treating traffic policy as a distinct management concern from Service type or port configuration, since the same Service type can behave very differently in practice depending on how its traffic policy fields are set.

Traffic Policy Fields Overview

externalTrafficPolicy

externalTrafficPolicy governs how traffic arriving from outside the cluster, through a NodePort or LoadBalancer Service, is distributed once it reaches a node. Cluster, the default, allows any node to forward traffic to any ready backend anywhere in the cluster; Local restricts forwarding to backends on the same node, dropping traffic if none exist locally.

spec:
  type: LoadBalancer
  externalTrafficPolicy: Local

internalTrafficPolicy

internalTrafficPolicy applies the same Cluster/Local choice to traffic originating from inside the cluster targeting a ClusterIP, allowing topology-aware routing for internal traffic as well, which is useful when a Service's consumers and backends are colocated on the same nodes and cross-node forwarding is undesirable for latency or cost reasons.

spec:
  internalTrafficPolicy: Local

trafficDistribution

The trafficDistribution field provides finer-grained control than the binary Local/Cluster choice, allowing a preference such as PreferClose to favor routing traffic to topologically nearby endpoints (same zone, for instance) when available, falling back to broader distribution only when no close endpoint exists, balancing locality preference against strict availability guarantees.

spec:
  trafficDistribution: PreferClose

Tradeoffs Managed Through Traffic Policy

Source IP Preservation vs. Load Distribution

The central tradeoff traffic policy management navigates is between preserving the original client source IP (favoring Local policies, which avoid the SNAT rewrite that Cluster policy requires) and achieving even load distribution across all backends regardless of node placement (favoring Cluster policy). Workloads that depend on knowing the real client IP — for access logging, geo-based logic, or IP-based rate limiting — generally require Local traffic policy despite its distribution tradeoffs.

spec:
  externalTrafficPolicy: Local

String clientIp = request.getRemoteAddr();

Even Placement as a Prerequisite for Local Policy

Because Local policy only forwards to nodes with a local ready backend, traffic policy management must be paired with workload placement strategy: if backing pods are concentrated on a small subset of nodes, Local policy combined with an external load balancer that does not account for backend distribution can produce significant load imbalance across nodes, even though each individual pod-to-node routing decision is technically correct.

Zone-Aware Traffic Policy

Topology-Aware Routing Motivation

In clusters spanning multiple availability zones, traffic policy management increasingly favors keeping traffic within the originating zone when possible, reducing cross-zone data transfer cost and latency, which is the specific motivation behind trafficDistribution: PreferClose as an alternative to the coarser node-local Local policy.

apiVersion: v1
kind: Service
metadata:
  name: ledger-api
spec:
  trafficDistribution: PreferClose
  ports:
    - port: 80
      targetPort: 8080

Graceful Degradation When Locality Is Unavailable

A well-managed zone-aware traffic policy degrades gracefully: if no in-zone endpoint is currently ready, traffic falls back to any available endpoint elsewhere rather than failing outright, preserving availability as the higher-priority guarantee over strict locality.

Interaction With Health and Readiness

Health Check Node Ports Under Local Policy

When externalTrafficPolicy: Local is set on a LoadBalancer Service, Kubernetes automatically exposes a healthCheckNodePort, which an external load balancer uses to determine which nodes currently have ready local backends and should receive traffic, meaning traffic policy management is tightly coupled with configuring the external load balancer to actually consume this health signal correctly.

kubectl get service ledger-api-public -o jsonpath='{.spec.healthCheckNodePort}'

Auditing Traffic Policy Configuration

Detecting Misaligned Policy Choices

Periodic review of Service traffic policy settings against actual workload placement and consumer requirements is a management practice that catches configurations set once at creation time but never revisited as a workload's node distribution or client IP requirements changed, which can silently degrade either load balance quality or source IP fidelity without triggering any error condition.

kubectl get services --all-namespaces -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.externalTrafficPolicy}{"\n"}{end}'