-
Notifications
You must be signed in to change notification settings - Fork 325
add initial experimental v2 AWS cloud provider #114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Signed-off-by: Andrew Sy Kim <[email protected]>
/hold Requires discussion |
/lgtm |
We discussed this in the aws-provider biweekly ; there are fragmentation risks but I agree that they are outweighed by the unblocking nature of a v2. Then we can see if the changes need to be breaking (and are worth the breakage!) /lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: andrewsykim, justinsb, nckturner The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/hold cancel |
Signed-off-by: Andrew Sy Kim [email protected]
What type of PR is this?
/kind feature
What this PR does / why we need it:
Adds an initial implementation of an experimental v2 provider that is exclusively out-of-tree. The actual implementation is incomplete, this just adds the initial boilerplate code for the cloud provider interface. Future PRs will incrementally implement the entire interface.
There are many requested features about the existing AWS cloud provider that are difficult to implement since we can't break behavior against existing clusters. Some of these include but are not limited to:
In addition, the existing provider is catered towards the deprecated in-tree architecture where it relies on the kubelet, kube-controller-manager and kube-apiserver to be AWS aware. As we approach a future of only out-of-tree providers, starting fresh on a v2 provider under these new assumptions may be the right direction. The v2 provider would be a breaking change from v1, meaning existing clusters shouldn't migrate to the v2 provider. The v2 provider will only support new clusters that enable the out-of-tree cloud provider (i.e. setting --cloud-provider=external on kube components). The v1 provider is NOT being deprecated and will continue to be supported in this repo. However, a future version of Kubernetes will remove the in-tree provider from the core Kubernetes release.
Does this PR introduce a user-facing change?: