Hi >Von: Clayton Coleman [mailto:[email protected]] >Gesendet: Freitag, 09. September 2016 17:25 >An: Aleksandar Lazic <[email protected]> >Cc: Diego Castro <[email protected]>; users ><[email protected]> >Betreff: Re: HAProxy Router > > Ingress is basically just an evolution of the route concept in Kubernetes.
Ah you refer to the ingress handler in Kubernetes. > We started it there and have let it soak a bit since routes were in > production use and we had very clear goals. > > An ingress controller in Kube is an Openshift Router. > The F5 router is a controller that programs F5 to respond to routes. > The HAproxy router is actually a controller that runs in each HAProxy pod and > generates a config file from a template - we call that a "template router" > because it can be used to generate Apache / NGINX / <config driven proxy> as > needed. > We do extensive security , performance, and reliability testing on the > routers, so think of them as rock solid versions of the ingress controllers > in Kube. > > The big things ingress does not do yet is security (making sure different > tenants can't steal each other's hostnames) and a few functional gaps (the > new A/B feature in Openshift). > Ben and Rajat have been working on identifying those gaps for improving > ingress to where we can rely on it in a productized form. We also want to do > it in a way that folks get the benefits of both - UI and CLI tooling that > make it easy to work with routes, but some of the more flexibility ingress > could be capable of (binding multiple services into the same ingress is > something we do with routes, but is more convenient for end users). Full ack. Best regards Aleks >On Sep 9, 2016, at 2:30 AM, Aleksandar Lazic ><[email protected]> wrote: >Hi. >Isn't the "router" also a ingress router? >What's the difference for you between the "router" and the "ingress". >Best regards >Aleks >Von: Clayton Coleman >Gesendet: Freitag, 9. September 05:19 >Betreff: Re: HAProxy Router >An: Diego Castro >Cc: users >Actually - we're not deprecating or removing routers or the router. We're >just adapting to also support ingress. There will be a very long period where >both routes and ingress happily coexist. >On Thu, Sep 8, 2016 at 11:35 AM, Diego Castro <[email protected]> >wrote: > >On Wed, Sep 7, 2016 at 1:21 PM, Andy Grimm <[email protected]> wrote: >On Wed, Sep 7, 2016 at 11:22 PM, Diego Castro <[email protected]> >wrote: >Hello, list. >We have been running Origin since last November and i'd like to share some >experiences, pains and thoughts. >Our origin cluster has about 25 servers including masters,nodes and routers. >We have roughly 500 applications exposing services and a bunch of HPA firing >up containers all the time. >1) Resource consumption: i noticed during the day a increase of memory >consumption due multiple reloads, a lot of process keep running until the >connections is finished or OOM kill. Other issue regarding restarts is that >due to TCP SYN DROP iptables we are facing some high latencies. What can we >do to reduce restart overhead ? >You seem to have several questions intertwined here, and I am by no means an >expert on this, but on the "lots of processes keep running" topic, you may be >hitting https://bugzilla.redhat.com/show_bug.cgi?id=1364870 (though this >manifests as more of a CPU consumption issue than a memory issue). In short, >what we've seen is cases where haproxy connections are "orphaned", so the old >processes never exit -- they continuously think they have one or two "jobs" >left, but they never actually handle them. I think this is fixed in the >latest 1.5.x release of haproxy, but have not had a chance to test yet. > >In 3.3 there are some more knobs you can set to limit the length of time that >an haproxy will stay around after a restart, you may wish to try playing wit >hthat... but the underlying bug is still there in 3.3. >Understood, i'll give it a try. > > > >2) Metrics: Would be nice to pull some metrics from the routers, something >like general network i/o and per endpoint traffic, i found a prometheus export >but due to process restart the endpoint states are cleaned. HAProxy 1.6 have a >fix for that (http://blog.haproxy.com/2015/10/14/whats-new-in-haproxy-1-6/). >Do we have plans to upgrade to 1.6 ? What kind of metrics do we have available >today? >The lack of metrics is a problem, and there's no great answer to your question/ >There are no plans to go to 1.6 at the moment, but we do need to solce the >stats problem, and we need to solve the reload problem, so we may end up >moving. But we are investigating upstream ingress and trying to get support >for that into OpenShift so we can migrate and deprecate the router. >Nice, i'd like to track this work, can you point me on the right direction? >-ben > >--- >Diego Castro / The CloudFather >GetupCloud.com - Eliminamos a Gravidade >_______________________________________________ >users mailing list >[email protected] >http://lists.openshift.redhat.com/openshiftmm/listinfo/users
_______________________________________________ users mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/users
