k8s-triage-robot
commented
7 months ago The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
k8s-ci-robot
cprivitere
Version 3.7.0 introduced support for external load balancers with Equinix Metal Load Balancers (EMLB). Prior to this change, the EIP-based control plane load balancer was explicitly ignored by the load balancer controller by checking the service namespace & name. When EMLB load balancing is enabled, we bypassed that service namespace & name check so that the load balancer controller could manage the control plane load balancer.
However, since both the EIP- and EMLB-based control plane load balancers create k8s service objects, if a customer who is currently using EIP-based control plane load balancing attempts to enable EMLB load balancing for their services, the load balancer controller will see the service object for the EIP-based control plane load balancer and create an EMLB load balancer for it, even though the customer did not specify a
loadBalancerIDin order to explicitly enable EMLB-based control plane load balancing.We should update CPEM so that if the customer is using EIP-based control plane load balancing, the load balancer controller ignores the service object regardless of the currently-selected load balancer implementation. It's possible we could do this by updating the control plane EIP reconciler to add a load balancer class to the service object it creates. When a load balancer class is present, kubernetes hides the service from the cloud provider; since we're using an informer to manage the EIP-based service object, I think that enables us to continue to manage the EIP directly even though our load balancer controller can't see it.