At this point in time, contour is still pretty new, so expect some rough edges. I did a prototype of routes with envoy (similar to contour, but preserving the router features) a few months back, and identified a set of challenges which made it not a great fit as a replacement for the OOTB openshift router
In general, when comparing to haproxy and the general state, here's the list PROs (envoy): * supports http2 natively * deeper insight into traffic passing through CONs (envoy): * scale is not great right now - even using dynamic programming i couldn't get much above 100 backends before hitting the wall (wouldn't scale to very large, dense clusters) * memory use is much higher than haproxy - so another density challenge (I was using 30GB at 1k backends, vs 5GB for 15k backends that we see with haproxy) * web sockets can't be transparent - so you have to run another port for them instead of sharing the HTTP port * SNI passthrough not ready, maybe in 6mo * reencrypt was really hacky, I couldn't get it to work right now (again, 6mo should be fixed) * general fragility - was easy to break when programming config CONs (contour, vs openshift router): * None of the security isolation stuff (preventing one tenant from using someone else's hostname) * None of the protection against bad certs (preventing someone from breaking the router by using someone else's tenant) * No status reporting back I think the biggest long term challenge with envoy will be pure scale - HAProxy is at least two orders of magnitude more efficient right now, and I think it will be a while before envoy even gets close. So if you have 10k+ frontends, haproxy is the only game in town. On ingress vs routes, routes are still more polished, so it's really just a "do you want the features routes have that ingress doesn't. On the other downsides to envoy, I expect to see progress over the next year or two to fixing it. I had originally done the prototype expecting that maybe we would use envoy as the "out of the box" plugin to the router (continuing to support routes and ingress and all the features, but with envoy underneath), but the biggest challenge is that envoy isn't really better than haproxy for the feature set that ingress and routes expose. Where envoy really shines is in something like istio, where you have a richer model for the ingress / service definition that can use the extra bells and whistles. Ultimately ingress + annotations and routes are both targeted at "simple, high scale" use of web frontends. I would expect a lot of people to have their apps "grow up" and use node ports or istio ingress as the apps get bigger and more important. I don't see them as directly competing. On Fri, Jan 19, 2018 at 1:36 PM, Srinivas Naga Kotaru (skotaru) < skot...@cisco.com> wrote: > How it is different than Openshift router and what extra benefits it > brings? Anyone educate me to understand differences or possible use cases > where it fit into eco system? Or replacing ingress controller or will it > solve ingress controller 244 address limitations? > > > > https://blog.heptio.com/announcing-contour-0-3-37f4aa7bc6f7 > > > > > > > > -- > > *Srinivas Kotaru* > > _______________________________________________ > users mailing list > users@lists.openshift.redhat.com > http://lists.openshift.redhat.com/openshiftmm/listinfo/users > >
_______________________________________________ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users