News for hackers. Stuff that matters.
Re:Kubernetes Failure Stories by takeda on Tuesday January 29, 2019 @03:20AM (#19024683)
We use haproxy. I wrote code [1] that configures it based on Consul to do load balance. It has been running in production for 2 years without issue (tested with consul 1.0.6)

For people wondering why not use consul template, this has benefit of understanding haproxy, and it minimizes numbers of restarts to make changes.

Using haproxy over and has the benefit that if Winkle or consul goes down things continue to work, just not updates.

[1] https://github.com/takeda/winkle

Re:Kubernetes Failure Stories by merb on Wednesday January 30, 2019 @06:39AM (#19034301)
Haproxy only solves a single Part of the Problem. If you do DNS based failover you should really Check how clients behave, when one node goes down. Without a floating ip or a cloud lb, some stuff will be troublesome
Re:Kubernetes Failure Stories by takeda on Wednesday January 30, 2019 @10:52PM (#19042176)
The haproxy method doesn't rely on DNS at all so I'm a bit confused.
Re:Kubernetes Failure Stories by merb on Wednesday February 06, 2019 @12:07PM (#19097045)
well either it uses DNS for failover or you have ipvs (lvs, keepalived) enabled or worse if the machine with haproxy crashes your basically dead. Of course there is also bgp and anycast, but this is not "cheap"
Re:Kubernetes Failure Stories by takeda on Wednesday February 06, 2019 @01:24PM (#19098014)
That's not how it works. It is very similar to sidecar approach which various service discovery solutions have. You have haproxy running locally on localhost and you communicate with it, the haproxy then routes the request to right nodes. No DNS, no LVS and no keepalived.
Re:Kubernetes Failure Stories by merb on Wednesday February 06, 2019 @05:36PM (#19100834)
well I've talked about edge Load Balancing..