Mitigate LB service disruption caused by Metallb LoadBalancerClass implementation
Summary
Implement a solution to make Metallb running with LoadBalancerClass handle also services that don't specify LoadBalancerClass.
Context
LoadBalancerClass support on Metallb was introduced and starting with Sylva v1.4.0, MetalLB handles only loadBalancer services having loadBalancerClass: sylva.org/metallb-class in their specs.
This means that loadBalancer services will need to have loadBalancerClass: sylva.org/metallb-class if it is desired to expose these services using MetalLB and a different loadBalancerClass value if another load balancers (like kube-vip) is deployed on the cluster.
When upgrading a cluster to Sylva v1.4.0, user-defined loadBalancer Services will be interrupted during the Sylva v1.4 upgrade and will not work until services are deleted and recreated with loadBalancerClass: sylva.org/metallb-class spec. This operation would need to be handled by the users according to the lifecycle of the workload and needs to be synchronized with the upgrade of the workload cluster.
The proposal in this issue helps in avoiding service impact and removes the need to have CNF teams involved during cluster upgrades, because services declared without loadBalancerClass spec will still be handled by Metallb even after upgrading to Sylva v1.4.x.
Implementation details
The agreed solution is: starting with Sylva v1.4.x, run a modified MetalLB implementation with a custom controller image that ensures handling of services without loadBalancerClass when loadBalancerClass is configured on MetalLB.
From the first analysis, the identified code change is having this line of code changed to return false and then build/maintain a custom controller image for every MetalLB version used in Sylva releases. The first custom MetalLB controller image (for Sylva v1.4.x) needs to be built on top of v0.14.9 release of Metallb code.
Target solution
The implementation in this issue would be the short/mid term solution.
But the target solution is to ask for a feature in upstream Metallb to provide an option to change Metallb behavior for handling services without loadBalancerClass when Metallb has loadBalancerClass set. This option is already provided by kube-vip.
A similar feature request was created in the past in upstream Metallb, but was closed due to the lack of argumentation and of actual utility for the use-case of the requestor.
This issue is not addressing the feature request in upstream Metallb, this will be handled as part of a different issue.