Topology Aware Routing

Kubernetes clusters are increasingly deployed in multi-zone environments with network traffic often relying on obscure endpoint matching and routing for a given service. Linkerd’s implementation of Kubernetes (Topology Aware Routing) provides users with a mechanism for asserting more control over endpoint selection and routing within a cluster that spans multiple zones. Users can now implement routing constraints and prefer endpoints in a specific zone in order to limit cross-zone networking costs or improve performance through lowered cross-zone latency and bandwidth constraints.

The goal of topology aware routing is to to provide a simpler way for users to prefer endpoints by basing decisions solely off the node’s topology.kubernetes.io/zone label. If a client is in zone-a, then it should prefer endpoints marked for use by clients in zone-a. When the feature is enabled and the label set, Linkerd’s destination controller will attempt to find endpoints whose routing.ForZones field matches the client’s zone.

(Topology aware routing is distinct from the trafficDistribution feature that appears in Kubernetes 1.31. trafficDistribution is not yet supported by Linkerd.)

Note

If you’re using a stable distribution of Linkerd, it may have additional features related to topology-aware routing (for example, Buoyant Enterprise for Linkerd and its HAZL feature). You can find more information about the different kinds of Linkerd releases on the Releases and Versions page.

To get started with topology aware routing take a look at the enabling topology aware routing task documentation.