Thanks for the reply Baptiste. Here is the dump of /etc/resolv.conf inside the container:
nameserver 10.179.240.10 nameserver 169.254.169.254 nameserver 10.240.0.1 search default.svc.cluster.local svc.cluster.local cluster.local c.icitizen-dev3-stack-1069.internal. 555239384585.google.internal. google.internal. options ndots:5 I will get some output from tcpdump and include it in a reply in a few minutes. Thanks again for your time. On Fri, Oct 16, 2015 at 1:17 AM, Baptiste <bed...@gmail.com> wrote: > > Le 16 oct. 2015 06:27, "Mark Betz" <mark.b...@icitizen.com> 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: mark.b...@icitizen.com > > 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 > -- Mark Betz Sr. Software Engineer *icitizen* Mobile: 908-328-8666 Office: 908-223-5453 Email: mark.b...@icitizen.com Twitter: @markbetz
