cluster-api-provider-aws
cluster-api-provider-aws copied to clipboard
kubernetes-sigs
Control Plane Load Balancer Attachments management from Machine
/kind feature
Describe the solution you'd like
Currently, the AWSCluster resource allows specification of a single classic load balancer (in spec and status). This works well when the AWSCluster is being managed by the AWSCluster controller, however, with the introduction of the Externally Managed Cluster Infrastructure concept, this could present a limitation to external cluster infrastructure provisioners.
Other infrastructure provisioners may use other types of load balancers (eg Network Load Balancers) or may even use multiple load balancers (one for external traffic and one for internal traffic, for security reasons). With the current design of the AWSCluster resource, this cannot be supported by external provisioners who intend to use the AWSMachine controller to provision AWS infrastructure for Machines.
The following needs to be met to allow internal and external management of cluster infrastructure:
- The
AWSMachinecontroller must assume the load balancer attachment for control plane machines is optional (perhaps this is also done by some other component) - The
AWSMachinecontroller should be able to attach multiple load balancers to a single machine- These load balancers may be of different types (eg Classic ELB and NLB)
- The AWSCluster resource should be extended to allow many (or no) load balancers
- In Spec and Status, there should be lists of load balancers rather than a single instance as is today
- This should also allow for multiple types of load balancers as per the provisioner requirements
Environment:
- Cluster-api-provider-aws version:
- Kubernetes version: (use
kubectl version): - OS (e.g. from
/etc/os-release):
cc @JoelSpeed Feel free to add details to this issue if I missed anything.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs 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 or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
Most certainly not all aspects of this issue are addressed by this, but there currently is movement in using NLBs instead of classic load balancers for control-plane machines: https://github.com/kubernetes-sigs/cluster-api-provider-aws/pull/3804. There seems to be a possibility to choose the type for the LB.
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs 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 or PR as fresh with
/remove-lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The multiple load balancers (internal vs external) element here still seems important, do we want to track this still?
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:
- 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:
- Reopen this issue with
/reopen - Mark this issue as fresh with
/remove-lifecycle rotten - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
In response to this:
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:
- 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 closedYou can:
- Reopen this issue with
/reopen- Mark this issue as fresh with
/remove-lifecycle rotten- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
