Le 16 oct. 2015 06:27, "Mark Betz" <[email protected]> a écrit : > > Hi, I have a hopefully quick question about setting up backends for resolvable internal service addresses. > > We are putting together a cluster on Google Container Engine (kubernetes) and have haproxy deployed in a container based on Ubuntu 14.04 LTS. > > Our backend server specifications are declared using an internal resolvable service name. For example: > > logdata-svc > logdata-svc.default.svc.cluster.local > > Both of these names correctly resolve to an internal IP address in the range 10.xxx.xxx.xxx, as shown by installing dnsutils into the container and running nslookup on the name prior to starting haproxy: > > Name: logdata-svc.default.svc.cluster.local > Address: 10.179.xxx.xxx > > However regardless of whether I use the short form or fqdn haproxy fails to start, emitting the following to stdout: > > [ALERT] 288/041651 (52) : parsing [/etc/haproxy/haproxy.cfg:99] : 'server logdata-service' : invalid address: 'logdata-svc.default.svc.cluster.local' in 'logdata-svc.default.svc.cluster.local:10000' > > We can use IPV4 addresses in the config, but if we do so we would be giving up a certain amount of flexibility and resilience obtained from the kubedns service name resolution layer. > > Anything we can do here? Thanks! > > -- > Mark Betz > Sr. Software Engineer > icitizen > > Email: [email protected] > Twitter: @markbetz
Hi, Weird. Configuration parsing is failing, which means it's a libc/system problem. Is your resolv.conf properly set up and the server responsive? Can you run a tcpdump at haproxy's start up and over your raw container (no dnsutils installed). Baptiste
