PR #53 already addresses this concern, but only partially. Its impact is, unfortunately, quite limited. It's quite rare that a service would have multiple VIPs such that they would be balanced.
The current shortcoming is that if one deploys keepalived-operator on OKD/Openshift 4.x, most VIPs would be colocated on a single node. This is especially problematic for services that require quorum, like kafka or mongodb with multiple instances. It's also affecting traffic scalability, as all traffic is mostly handled by a single node.
Ideally, by default, keepalived-operator would try to randomize the VIP distribution across the members. Further, it would be great if based on an annotation, some VIPs are kept on different members (for example, create an "anti-affinity" for kafka broker services, such that they are not placed on the same node).
PR #53 already addresses this concern, but only partially. Its impact is, unfortunately, quite limited. It's quite rare that a service would have multiple VIPs such that they would be balanced.
The current shortcoming is that if one deploys keepalived-operator on OKD/Openshift 4.x, most VIPs would be colocated on a single node. This is especially problematic for services that require quorum, like kafka or mongodb with multiple instances. It's also affecting traffic scalability, as all traffic is mostly handled by a single node.
Ideally, by default, keepalived-operator would try to randomize the VIP distribution across the members. Further, it would be great if based on an annotation, some VIPs are kept on different members (for example, create an "anti-affinity" for kafka broker services, such that they are not placed on the same node).