Hi, Willy. Thanks for the reply. The version of haproxy installed into the container is:
$ /usr/sbin/haproxy --version HA-Proxy version 1.5.14 2015/07/02 Also, for completeness: $ uname -a Linux haproxy 3.19.0-30-generic #34-Ubuntu SMP Fri Oct 2 22:08:41 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux I don't believe ipv6 addresses are coming back in our cluster. I did an nslookup on that name from inside the container earlier and just got back the internal ipv4 address. Thanks a bunch for the assistance. At the moment we have reverted the config to use private IPs, but I would like to pursue this if there is a chance to get names working, so let me know if there is any additional info I can provide. Regards, On Fri, Oct 16, 2015 at 1:20 PM, Willy Tarreau <w...@1wt.eu> wrote: > Hi, > > On Fri, Oct 16, 2015 at 12:26:20AM -0400, Mark Betz wrote: > > 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! > > What exact version are you using (haproxy -vv) ? I'd be interested to > see if you're using getaddrinfo() or gethostbyname() (this will appear > in the dump above). Getaddrinfo() is known for being able to produce > such oddities in certain corner cases, and there was a recent fix for > a somewhat related issue appearing on freebsd and apparently not on > linux. Depending on your version, it may mean that linux is in fact > impacted as well or that the fix caused some breakage there. That's > just a supposition of course. > > Also could you check that you only have IPv4 addresses for this name : > > host -a logdata-svc.default.svc.cluster.local > > I wouldn't be surprized if you got an IPv6 address while IPv6 is > currently not enabled on your system for example, preventing the > address from being used. > > Regards, > willy > > -- Mark Betz Sr. Software Engineer *icitizen* Mobile: 908-328-8666 Office: 908-223-5453 Email: mark.b...@icitizen.com Twitter: @markbetz
