Open smarshie opened 1 year ago
It's somewhat a duplication of #296, but we can definitely start it very simple, adding a few more magic to our config snippets. Thanks for bringing this back to our attention.
@jcmoraisjr I've devised a workaround that I'm going to implement for our purposes.... Going to write a small Python script that runs in a pod on a loop, checking for haproxy-ingress endpoints.... whenever it finds changes it will update the config map to add peers section as standalone section under "config-sections". Will let you know how I get on
@smarshie Would you mind sharing your solution if you have a POC working? I'm very interested in testing this out.
What are you trying to do
We are trying to use peering to allow synchronisation of stick tables between Haproxy-Ingress pods, so that we can reliably stick traffic to pods when scaling up Haproxy-Ingress for reliability/availability purposes (e.g. across AWS AZs). However, as Kubernetes pod names are unpredictable, this is impossible.
What HAProxy Ingress should do or how it should behave differently
Two thoughts to help with this. Option 2) seems more comprehensive... 1) Allow deployment as a StatefulSet as well as Daemonset/Deployment, so that at least pod names can be predictable and a peer list could be built based on number of replicas in StatefulSet 2) Allow a configuration option for controller that can turn on automatic building of peer list: i.e. IngressController would monitor pods created by the Daemonset/Deployment and include peer section in config-global. It strikes me that the information to achieve this might already be getting gathered if a leader is being nominated when there are multiple pods...