Skip to content

proxy: Simplify destination discovery fallback #2661

@olix0r

Description

@olix0r

Currently, the proxy routes outbound requests as follows:

  • If there is a (1) l5d-dst-override or (2) :authority/Host header on the request, this value is used to route the request.
  • If the destination name is actually an IP address, it is used as the destination address.
  • If this destination name has a (configured) suffix (e.g. .svc.cluster.local), then it is resolved through the destination service.
  • If the destination name does not match the suffix, or if the destination service is unable to resolve this service, then the destination name is resolved via DNS.
  • Otherwise, if none of these we use the original dst addr.

The intent for falling back to dns is that we want to be able to load balance requests over DNS RRs even when the destination service cannot inform of us all endpoints. Practically, this is probably an extremely rare need. It seems perfectly fine to couple load balancing to the destination service if there are other reasons to simplify, and there are...

  1. When Linkerd is applied to HTTPS ingresses, for instance, the ingress may forward requests to a default backend without modifying the request headers (i.e. resetting a host/authority or adding a dst override). This means that the outbound request may have an authority value that is self-referential, potentially creating a traffic loop!
  2. In cases when an application does its own discovery, it may attempt to resolve svc names through the destination service that do not match.

Both of these cases would be remedied by simply falling back to the original dst address instead of performing additional discovery.

The new proposed discovery logic is the following:

  • If there is a (1) l5d-dst-override or (2) :authority/Host header on the request, this value is used to route the request.
  • If this destination name has a (configured) suffix (e.g. .svc.cluster.local), then it is resolved through the destination service.
  • if the name did not match or cannot be resolved through the destination service, then the request is routed to its original dst address.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions