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
currently each KeepalivedGroup supports up to 255 services.
This limit is due to the way keepalived works and how the operator was designed: each services maps to a keepalived vrrp instance. With a different design where each vrrp instance can carry more than one VIP, it's possible to go beyond that limit.
Here is a possible design:
a function maps services/VIPs to vrrp instance in a way that can be calculated at any point in time, so no state has to be held anywhere. For example sha256(namespace/service/VIP) mod 255. The pseudo randomness of the hash function ensures that VIPs are rather evenly distributed across vrrp groups.
during the reconcile cycle VIPs are assigned via the above function and the keepalived map is computed.
This will allow supporting an unlimited number of VIPs/services. The only downside is that VIPs from different services share the same fail-over dynamic. This is not usually an issue.
The text was updated successfully, but these errors were encountered:
currently each KeepalivedGroup supports up to 255 services.
This limit is due to the way keepalived works and how the operator was designed: each services maps to a keepalived vrrp instance. With a different design where each vrrp instance can carry more than one VIP, it's possible to go beyond that limit.
Here is a possible design:
This will allow supporting an unlimited number of VIPs/services. The only downside is that VIPs from different services share the same fail-over dynamic. This is not usually an issue.
The text was updated successfully, but these errors were encountered: