[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: HAProxy Router

Ingress is basically just an evolution of the route concept 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).

On Sep 9, 2016, at 2:30 AM, Aleksandar Lazic
<aleksandar lazic cloudwerkstatt com> wrote:


Isn't the "router" also a ingress router?

What's the difference for you between the "router" and the "ingress".

Best regards

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 <diego castro getupcloud com> wrote:

On Wed, Sep 7, 2016 at 1:21 PM, Andy Grimm <agrimm@redhat.com> wrote:

On Wed, Sep 7, 2016 at 11:22 PM, Diego Castro <diego castro getupcloud com> 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?




Diego Castro / The CloudFather
GetupCloud.com - Eliminamos a Gravidade

users mailing list
users lists openshift redhat com

users mailing list
users lists openshift redhat com

users mailing list
users lists openshift redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]