init-addr currently hard-coded to "none"

[jbotelho2-bb]

We've been having an issue where haproxy-ingress reloads (e.g. when a new ingress is added) cause 503s on some applications for a couple seconds, even though the upstream endpoints are reachable and healthy. Digging into the generated-config, we noticed that it sets init-addr none on all of our backends:

backend example-ns-example-ingress-8080
    mode http
    balance roundrobin
    tcp-request content set-var(txn.namespace) str("example-ns")
    server-template server-dns 32 example-svc.example-ns.svc.cluster.local:8080 resolvers kube-dns resolve-prefer ipv4 init-addr none

It seems that this short period of 503s is due to haproxy having to re-resolve all the DNS records on startup, as according to the docs, init-addr none instructs HAProxy to ignore the previously resolved IPs available in the state file. I would have expected it to instead use the values from the state file until DNS resolution is finished, to ensure a graceful reload, given a reload script is included to make use of the state file.

Why is this set this way in the haproxy config template?

[jcmoraisjr]

Hi, thanks for the detailed description. The problem is that there is no server-state-file (by default) and libc doesn't resolve k8s services on default haproxy-ingress deployment. This config was made as a work around assuming that the resolver would work fast enough and wasn't visited anymore.

I'll have a look into this one and probably add the service IP (if exists) or the IP of the endpoints (if a headless service).

In the mean time I'd suggest you to give dynamic update a try. It works like a charm on our cluster, will update the haproxy state faster when compared to DNS discovery and would only restart haproxy in the same scenarios the DNS discovery would do.