Hi Baptiste, Baptiste Assmann wrote on 11.08.2017:
> Hi All > So, I enabled latest (brilliant) contribution from Olivier into my > Kubernetes cluster and I discovered it did not work as expected. > After digging into the issues, I found 3 bugs directly related to the > way SRV records must be read and processed by HAProxy. > It was clearly hard to spot them outside a real orchestrator :) > Please find in attachment 3 patches to fix them. > Please note that I might have found an other bug, that I'll dig into > later. > When "scalling in" (reducing an app footprint in kubernetes), HAProxy > considers some servers (pods in kubernetes) in error "no dns > resolution". This is normal. What is not normal is that those servers > never ever come back to live, even when I scale up again... > Note that thanks to (Salut) Fred contribution about server-templates > some time ago, we can do some very cool fancy configurations like the > one below: (I have a headless service called 'red' in my kubernetes, it > points to my 'red' application) > backend red > server-template red 20 _http._tcp.red.default.svc.cluster.local:8080 > inter 1s resolvers kube check > In one line, we can enable automatic "scalling follow-up" in HAProxy. ... for headless services only, right. For services is the normal resolution enough, imho. 8-O. I don't say the word amazing very often but now it fit's. That's amazing ;-) It would be interesting, at least for me, to have haproxy as a 'service controller', instead of the kube-proxy ;-) Do you also use haproxy for ingress in your kubernetes cluster? f. e. https://github.com/kubernetes/ingress/tree/master/examples/deployment/haproxy > Baptiste -- Best Regards Aleks
