Clarify how KeepalivedGroup work in a different Namespace then the Services using it

[tux-o-matic]

All examples given in the doc show a KeepalivedGroup CR being created in the same Namespace as the Service referencing and needing it yet the KeepalivedGroup CR seems to have a central role that is more on cluster and admin level. What's the actual limitation?

• KeepalivedGroup CR must be in the same Namespace as the Service needing it?
• If KeepalivedGroup must be in the same Namespace, how is router id conflict avoided between multiple KeepalivedGroup?
• One KeepalivedGroup CR can be used from multiple Namespaces?
• If a KeepalivedGroup can be shared from different Namespaces, is a NetworkPolicy needed when running multi-tenant SDN?

[tux-o-matic]

I see a suggestion to not put KeepalivedGroup CRs in the same Namespace as the operator but that doesn't clarify any of the questions above. And yet the README gives an example where they live in the same Namespace.

[tux-o-matic]

Better documentation would also prevent running in this situation flagged in https://github.com/redhat-cop/keepalived-operator/issues/59

[tux-o-matic]

So trying different scenarios: a KeepalivedGroup can used by a Service in a different Namespace. kube-proxy handles traffic from the NodePort without need for a NetworkPolicy. One remaining question: how are router id conflict avoided when running multiple KeepalivedGroup with the same default multicast address?