profile
viewpoint

Ask questionsHeader based routing

Feature Request

What problem are you trying to solve?

We would like to route requests to a service via headers on inbound requests!

How should the problem be solved?

There exists an open issue on the SMI spec that details how A/B testing could be extended to support cookies/headers/etc, instead of just weights: https://github.com/deislabs/smi-spec/issues/17.

As the SMI spec evolves beyond weighted traffic routing ie A/B or canary deployments like the linked issue above describes, it would be useful to be able to route traffic to backing services based on headers. At present, Linkerd does not support this feature, but Istio's virtualservice does - but we'd much rather use linkerd than take on istio.

Our use case, I think, is straightforward:

  1. An inbound request is decorated with a header via an ingress controller (that maps the inbound request to a header via some identity provider ie Azure Active Directory/okta/etc.)
  2. The inbound request is passed along into a service mesh, which maps the request to a backing service via the header set in 1.

This issue was opened, and it seems like the Traffic Split SMI resource mostly resolved issues in this situation, but in it's current form will not be sufficient to address the implementation we desire.

Any alternatives you've considered?

  • We've looked at flagger, which is better suited for automated container promotion.
  • Istio, but it's not an SMI compliant service mesh, and will likely not be for the nebulous future
  • Routing service to service traffic through a traefik2 ingress controller, which can match requests to services based on headers.

How would users interact with this feature?

If the API described in this issue is comprehensive enough, it would be sufficient.

Here is an example of usage that I'd like to see; an example of traffic split between 3 backing services:

apiVersion: v1beta1
kind: TrafficSplit
metadata:
  name: frontend
spec:
  service: frontend
  backends:
  - service: primary-frontend
  - service: beta-frontend
    matchRegex:
      - name: "beta users"
        x-group: "beta-users" # users who signed up for the beta
  - service: alpha-frontend
    matchRegex:
      - name: "alpha users"
        x-group: "alpha-users" # users who want to live on the bleeding edge
linkerd/linkerd2

Answer questions stale[bot]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

useful!

Related questions

linkerd2-proxy too many open files hot 1
proxy connection refused when forwarding to port 80 hot 1
TLS nginx ingress of grpc request to linkerd-meshed grpc service errors with 502 hot 1
Containers can come up without iptables rules in CNI environments hot 1
Proxy crashes when injecting NGINX ingress controller hot 1
All linkerd components in Init:CrashLoopBackOff hot 1
Containers can come up without iptables rules in CNI environments hot 1
kubeconfig using server paths does not work with tap hot 1
Proxy fails to route to updated pod deployment hot 1
Investigate into proxy injector admission timeout hot 1
Proxy fails to route to updated pod deployment hot 1
Linkerd 2.4.0: request aborted because it reached the configured dispatch deadline hot 1
Control skip port flag via custom annotation in resource hot 1
Containers can come up without iptables rules in CNI environments hot 1
Fail to inject when mTLS is enabled and there is no service account hot 1
Github User Rank List