Open ctreatma opened 10 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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
/reopen
@cprivitere: Reopened this issue.
/remove-lifecycle rotten
/triage accepted
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
loadBalancerID
in 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.