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
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?
The text was updated successfully, but these errors were encountered:
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.
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?
tux-o-matic
changed the title
Clarify if KeepalivedGroup must be in the same Namespace as the Service using it
Clarify how KeepalivedGroup work in a different Namespace then the Services using it
Jul 7, 2022
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?
The text was updated successfully, but these errors were encountered: