Kubernetes externalTrafficPolicy “Cluster” and “Local”

Last updated on November 29, 2023

The difference between setting the value of “Cluster” and “Local” in Kubernetes lies in the load balancing mechanism.

...
  selector:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
  clusterIP: 10.152.183.163
  clusterIPs:
    - 10.152.183.163
  type: LoadBalancer
  sessionAffinity: None
  loadBalancerIP: 10.34.104.17
  externalTrafficPolicy: Local
  healthCheckNodePort: 32722
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  allocateLoadBalancerNodePorts: true
  internalTrafficPolicy: Cluster

From official doc

Due to the implementation of this feature, the source IP seen in the target container is not the original source IP of the client.
… service.spec.externalTrafficPolicy – denotes if this Service desires to route external traffic to node-local or cluster-wide endpoints. There are two available options: Cluster (default) and Local. Cluster obscures the client source IP and may cause a second hop to another node, but should have good overall load-spreading. Local preserves the client source IP and avoids a second hop for LoadBalancer and NodePort type services, but risks potentially imbalanced traffic spreading.

While “Cluster” allows for efficient load balancing by forwarding requests to other nodes, “Local” can result in imbalanced traffic spreading.

When “Local” is set, the load balancer distributes traffic equally between nodes, regardless of the number of pods, which can lead to inefficient resource consumption.

However, with “Cluster” set, Kubernetes balances requests based on both nodes and the number of pods, resulting in a more balanced load distribution within the cluster.

Essentially, “Local” only distributes the load within the same node pods, while “Cluster” considers both nodes and pods to avoid imbalance and ensure efficient resource consumption.