Locality Load Balancing

 2 minute read  

This series of tasks demonstrate how to configure locality load balancing in Istio.

A locality defines the geographic location of a workload instance within your mesh. The following triplet defines a locality:

  • Region: Represents a large geographic area, such as us-east. A region typically contains a number of availability zones. In Kubernetes, the label topology.kubernetes.io/region determines a node’s region.

  • Zone: A set of compute resources within a region. By running services in multiple zones within a region, failover can occur between zones within the region while maintaining data locality with the end-user. In Kubernetes, the label topology.kubernetes.io/zone determines a node’s zone.

  • Sub-zone: Allows administrators to further subdivide zones for more fine-grained control, such as “same rack”. The sub-zone concept doesn’t exist in Kubernetes. As a result, Istio introduced the custom node label topology.istio.io/subzone to define a sub-zone.

Localities are hierarchical, in the matching order:

  1. Region

  2. Zone

  3. Sub-zone

That means that a pod running in zone bar of region foo is not considered to be local to a pod running in zone bar of region baz.

Istio uses this locality information to control load balancing behavior. Follow one of the tasks in this series to configure locality load balancing for your mesh.