Add support for balancing traffic across multiple providers

[timoreimann]

We'd like to use Traefik in a setup where traffic can be balanced between multiple providers simultaneously.

Specifically, we maintain both a Marathon and Kubernetes cluster and have deployed certain applications whose traffic should be split between the two. We are primarily looking after even distribution (i.e., equal weights) but could imagine giving priority to one over the other as well.

I already touched on the subject in Slack and got some feedback from @emilevauge that Traefik currently does not support what we have in mind. I'd be happy to dive into the code and add support.

Here's a number of questions I came up with:

1. Are there any general concerns regarding my proposal? Things that we could address up front?
2. What kind of matching rule should we devise that tells Traefik two frontends from different providers should share their backends? For our specific use case, we've been thinking of matching frontend routes implicitly (e.g., equal set of hosts / paths / headers / etc.). This looks like a reasonable default, though I could imagine another explicit switch on top (like a configuration setting marking providers that are eligible for sharing, or maybe even something on the frontend level).
3. Somewhat related to the previous question: Do we need to make sure we don't break (or surprise) existing clients when the feature lands, especially if the matching occurs implicitly?

I have already been pointed at loadConfig() and started to think about how it'd have to be modified. It's fairly lengthy and complex and took me a while to grasp though, so I'd keen on refactoring it a bit for the better. However, I could not find any tests that would make sure I don't break anything. Did I miss those?

Thanks.

[bparli]

We're evaluating using traefik but our use case is a bit simpler. I want to use our service discovery system (Sidecar as the backend provider, however, since front end configs are out of scope for service discovery I'd like to use etcd for that piece.

I'm only now diving into the code so can't speak to a proper design for this feature; just thought I'd add our use case to the issue.

[timoreimann]

@emilevauge @vdemeester @errm and others: any opinions on my request, and in particular my questions?

I'd like to start working on a PR soon and want to make sure I'm moving in the right direction.

[timoreimann]

@bparli It sounds to me like you're looking into writing a custom provider: One that uses Sidecar to determine the set of backends and etcd to get a (static?) set of frontends. To my understanding, the result of that would still be a Configuration map eventually ending up at listenConfigurations(), thereby be subject to the same cross-provider balancing rules this issue is about to define.

Did I get that correctly?

[bparli]

@timoreimann yessir, thats what we're aiming for

[timoreimann]

I had another look at the part of the code base relevant for this feature request: As it turned out, at least a hard preference towards one particular provider is already possible if frontends match in both the path and host components, and a proper frontend priority is assigned. This is probably going to be good enough for me as we are only going to need this feature during a transition phase from one container management system (Marathon) to a new one (Kubernetes).

@bparli and other issue subscribers: Is the more generalized cross-provider routing/balancing feature request still desirable to you? Shall we keep the issue open or not?

[bparli]

Thats good enough for us too @timoreimann . Closing the issue is fine by me

[timoreimann]

Thanks @bparli 👍

Closing for now. If anyone feels like the issue should be reopened, please comment.