Split traffic based on headers

[sudermanjr]

Feature Request

What problem are you trying to solve?

I would like to be able to do complex deployment scenarios where multiple versions of an application are running and the service mesh controls how traffic is routed to the versions. The routing rules could use different criteria, such as request header, or a percentage of traffic that will go to each version of the application.

The exact deployment scenario that I am envisioning is this process (fully automated):

1. Deploy v2 of application and route zero traffic
2. Allow requests with a specific header to reach the new version in order to run automated tests against it.
3. Some small portion of production traffic is now routed to the new version (say 10%). During this time, there are key metrics that are monitored. If any of the metrics break a threshold, then the traffic split is rolled back.
4. Eventually, perhaps after several stages of this or more testing, the final split is set to 0/100 and all traffic is being routed to the new version.

Any alternatives you've considered?

There are other products that solve this problem, but none of them have been completely satisfactory.

Is there another way to solve this problem that isn't as good a solution?

How would users interact with this feature?

There are a couple ways to handle this that I can think of.

1. With a CRD definition that specifies the version to route to and the rules. Something like Istio's virtualservice/destinationrule, or something like a dtab from linkerd

2. Annotations. The service that points to the sets of pods could have annotations that dictate the routing.

[alpeb]

We've just released version 2.4 which provides support for traffic splitting. From our latest blog post:

Linkerd’s new traffic splitting feature allows users to dynamically control the percentage of traffic destined for a service. This powerful feature can be used to implement rollout strategies like canary releases and blue-green deploys by incrementally shifting request traffic between Kubernetes services.

That functionality is exposed through SMI, the Service Mesh Interface. This allows other products to leverage our traffic splitting functionality through a standard API. Flagger in particular, allows you to drive canary deployments in exactly the way you describe. Let us know how that works out for you!

[migolfi]

I have a scenario that would benefit greatly from broader routing features. Right now I'm using Traefik for routing ingress and header matching to drive versioned services in Kubernetes. Currently this only works for ingress traffic and not service-to-service.

Having header based routing would allow us to version services internally to the cluster. An approach like this could work in our scenario.

[alpeb]

@migolfi Please check Flagger's A/B Testing docs for Linkerd, that might be exactly what you're looking for...

[migolfi]

Thanks @alpeb!
This looks great and looks like it would resolve the scenario I'm facing right now. Although I'm not currently using Nginx at all. Will Linkerd rely on using Nginx for routing as a longterm solution?

[alpeb]

Sorry, I totally disregarded this was dependent on nginx/gloo for the header routing part. From what I know we don't have plans to rely on nginx for routing.
Obviously, you could add an nginx ingress just for fronting your services, but that might be too much...

[migolfi]

@alpeb That would work for a temporary solution. I'd also be looking towards a longer term solution. It looks like the SMI spec does not yet specify header routing.

A couple of questions:

• Does Linkerd provide its own schema for TrafficSplit or does it solely use the SMI spec?
• It looks like there's an open issue on the SMI spec for supporting A/B. Would this work?

Apologies in advance if I'm missing the mark, I'm trying to learn the spec at the same time

[sudermanjr]

I did some preliminary testing and seems like in conjunction with Flagger this should all do what I need. Thanks!

[wmorgan]

@sudermanjr That's great to hear!

@migolfi Great questions. I'll leave those for @grampelberg, our resident SMI expert, to answer

[grampelberg]

Does Linkerd provide its own schema for TrafficSplit or does it solely use the SMI spec?

Yup, we’re using the code from deislabs/smi-sdk-go in fact.

It looks like there's an open issue on the SMI spec for supporting A/B. Would this work?

It sounds like that’d fit your use case? We’ll be chatting about the next version of TrafficSplit soon, so please make sure to comment on that issue with your use case!

[migolfi]

@grampelberg - I'm essentially trying to do A/B with inclusion of multiple microservices. Great! Looking forward to those conversations.

[migolfi]

Hey everyone, seeing this issue is closed I just wanted to check if header-based splitting is still planned and if so, should I open a new issue for it?

[grampelberg]

@migolfi still planned, would you mind opening an issue that is specific to your use case? Maybe call out why the flagger solution doesn't work for you?