You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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...
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
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...
The text was updated successfully, but these errors were encountered:
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
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...
The text was updated successfully, but these errors were encountered: