Hi Willy. Am 23.05.2019 um 16:48 schrieb Willy Tarreau: > Hi Aleks, > > On Thu, May 23, 2019 at 01:12:48PM +0200, Aleksandar Lazic wrote: >> We had a interesting discussion on Kubeconf how a session table in peer's can >> survive a restart of a haproxy instance. >> >> We came to a request for enhancement (RFE) to be able to add a peer server, >> not a peer section, to a existing peers section, similar to add server for >> backend. > > It's not entirely clear to me in which case it would be useful. Do you > need to deploy new haproxy nodes on the fly and to avoid restarting the > other ones to see it as a peer maybe ?
It's an enhancement to Eduardo's requirement to sync peers. Let's say there are several haproxies in a peers cluster and one pod/container/process dies. Now the deployment (replication controller) restarts the pod which have a init-container ( https://kubernetes.io/docs/concepts/workloads/pods/init-containers/ ) which adds the new pod ip into the already running peers cluster. The init-container finish successfully and the new haproxy pod is now part of the current peers cluster. Makes sense? > Thanks to the changes Fred did which made the peers become totally regular > servers, I suspect it wouldn't be too hard to make the server-template > mechanism work the same way for peers. It's just that I'm not sure about > the expected benefits. Sounds good. I would setup a headless service ( https://kubernetes.io/docs/concepts/services-networking/service/#headless-services ) for the peers cluster. Then the server-template can resolve the service address and get the endpoints as A records back. Quote ``` Headless services Sometimes you don’t need or want load-balancing and a single service IP. In this case, you can create “headless” services by specifying "None" for the cluster IP (.spec.clusterIP). This option allows developers to reduce coupling to the Kubernetes system by allowing them freedom to do discovery their own way. Applications can still use a self-registration pattern and adapters for other discovery systems could easily be built upon this API. For such Services, a cluster IP is not allocated, kube-proxy does not handle these services, and there is no load balancing or proxying done by the platform for them. How DNS is automatically configured depends on whether the service has selectors defined. With selectors For headless services that define selectors, the endpoints controller creates Endpoints records in the API, and modifies the DNS configuration to return A records (addresses) that point directly to the Pods backing the Service. Without selectors For headless services that do not define selectors, the endpoints controller does not create Endpoints records. However, the DNS system looks for and configures either: * CNAME records for ExternalName-type services. * A records for any Endpoints that share a name with the service, for all other types. ``` How often will the DNS name be resolved with server-templates? > Cheers, > Willy Regards Aleks
