Feb 21, 2024: Announcing Linkerd 2.15 with support for VM workloads, native sidecars, and SPIFFE! Read more »

This is not the latest version of Linkerd!
This documentation is for Linkerd 1.x, an older version with some significant differences. You may want to see the Linkerd 2.x (current) documentation instead.

Service discovery

A large part of the complexity inherent in running multi-service applications stems from service discovery. Unfortunately, as the complexity and scale of the application increases, service discovery becomes difficult to avoid. Linkerd is explicitly designed to reduce this complexity by:

  1. Abstracting away the specifics of the underlying service discovery mechanism.
  2. Providing upgrade paths that allow you to choose appropriate service discovery endpoints.
  3. Encouraging best practices based on years of experience using service discovery in production systems.

Linkerd abstracts over service discovery mechanisms to treat them in a simple, uniform way: as simple data stores that are able to resolve concrete names into a set of addresses.

This minimalist interaction, combined with Linkerd’s routing rules, provides powerful control while reducing complexity. For example, Linkerd is able to use multiple service discovery endpoints and to express precedence and failover between them.

Linkerd has the ability to treat service discovery as authoritative or advisory. Authoritative service discovery is configured by default, but can be toggled via Linkerd’s enableProbation load balancer configuration. In authoritative mode, Linkerd will stop sending traffic to an instance when it is removed from service discovery.

Advisory service discovery is not appropriate for all environments, so it is not enabled by default. In many environments, however, advisory service discovery helps protect against failures in the service discovery backend, including complete outages and missing or invalid data. In advisory mode, Linkerd may continue to send traffic to an address after it has been removed from service discovery, provided the endpoint is still available and serving traffic.

In either authoritative or advisory mode, an instance does not need to be removed from service discovery to stop receiving traffic. If the instance simply stops accepting requests, Linkerd’s load-balancing algorithms are designed to handle gracefully instances that become unhealthy or disappear.

Lookups in service discovery are controlled by dtab rules. This means that these lookups comprise part of the routing logic for a request.