Path based routing support?

[gustav-b]

(I'm new to Deis workflow and k8s so excuse me if this question is misplaced.)

A common microservice routing pattern is to route requests to services/apps based on path prefix, e.g.:

example.com/a → app1
example.com/b → app2

Instead of the host based described in the documentation:

a.example.com → app1
b.example.com → app2

Does the deis router in any way support this? Or is it out of scope of router and should be handled at some other level?

[krancour]

It is not currently supported. We would have to think through a lot of things first before adding such a feature because there is so much going on in both the router and controller that is predicated on the notion that each app has it's own subdomain and/or custom / "vanity" domain(s). Thinking through this should happen at some point, because I think we would need to handle arbitrarily complex routing rules if we want to eventually evolve the router into a proper k8s ingress controller. That said, I don't think this is a feature we'd prioritize highly, but I will at least start thinking it over.

[krancour]

I don't believe we can reasonably implement this feature without breaking changes. Closing.

[ghost]

sad to hear this, basically a thing possible in one command line on flynn or aws api gateway.

[krancour]

@pouledodue I understand that people want this feature, but try to appreciate that until we're prepared to have a major release, we need to avoid introducing breaking changes... unless they're buried behind a feature flag. If we're going to make significant changes to the router, we shouldn't stop with path based routing. We would also want to see it become a proper ingress controller and support for Let's Encrypt is another oft-requested feature. I also believe that any major changes to the router should see most of its features go away so that the router just routes and doesn't pull double-duty as a one-size-fits-all web server. (Providing a single web server implementation that meets everyone's needs, even if it is highly configurable, has proven to be tremendously difficult). Last, but not least, remember that most such changes to the router need to be complimented by non-trivial changes to the controller, and possibly the CLI.

All this being said, there's good news on this front. I've created a proposal in deis/workflow#584 that we should add opt-in (i.e. behind a feature flag) support for Traefik as an ingress controller (and as an alternative to the existing router). Note that this would require some controller changes, and to enable path-based routing, those controller changes would be extensive and would require complimentary CLI changes as well. So this is a non-trivial amount of work, but I believe this is a more forward thinking approach than continuing to increase the complexity of the existing router.

[krancour]

I have also opened this PR to add a chart for a Traefik-based ingress controller. This should make it easier for people to start experimenting with a lighter weight router alternative.

https://github.com/kubernetes/charts/pull/146