Dynamic request routing is one of linkerd’s more powerful and flexible features. When linkerd receives a request, it must somehow determine where to route that request. It does this by assigning a service name to the request and then applying dtab rewrites to it.
This introduces a distinction between the service destination (e.g. the
service) and the concrete destination (e.g. the staging version of the
service running in the east coast datacenter). By having applications only
address requests with a service name, they can be completely agnostic to the
By modifying the dtab, we can adjust the mapping from service name to concrete name. This lets you shift traffic from staging to prod, from one version of a service to another, or from one datacenter to another. These changes can be applied to a percentage of traffic, allowing you to shift traffic in an incremental and controlled way. This kind of traffic shifting enables things like blue-green deploys, canary, and cross-DC failover.
Using namerd enables the ability to make these dtab changes at runtime, without needing to restart linkerd.
Additional dtab rules can be specified on a per-request basis and will only be
applied to that request. Any dtab rules in the
l5d-dtab HTTP header will be
appended to the dtab used for routing that request. Since later rules have
higher precedence, this allows you to override the destination of the request.
If your application forwards the recommended HTTP headers, the additional dtab rules will propagate with the request. This allows you to test staging versions of services (even services deep within the application topology) without affecting production traffic.
For more information on the special headers that linkerd reads, see the HTTP header documentation. For a more detailed description of how linkerd routes requests, see the in-depth routing documentation.