222d247489
Automatic merge from submit-queue (batch tested with PRs 46489, 46281, 46463, 46114, 43946) AWS: consider instances of all states in DisksAreAttached, not just "running" Require callers of `getInstancesByNodeNames(Cached)` to specify the states they want to filter instances by, if any. DisksAreAttached, cannot only get "running" instances because of the following attach/detach bug we discovered: 1. Node A stops (or reboots) and stays down for x amount of time 2. Kube reschedules all pods to different nodes; the ones using ebs volumes cannot run because their volumes are still attached to node A 3. Verify volumes are attached check happens while node A is down 4. Since aws ebs bulk verify filters by running nodes, it assumes the volumes attached to node A are detached and removes them all from ASW 5. Node A comes back; its volumes are still attached to it but the attach detach controller has removed them all from asw and so will never detach them even though they are no longer desired on this node and in fact desired elsewhere 6. Pods cannot run because their volumes are still attached to node A So the idea here is to remove the wrong assumption that callers of `getInstancesByNodeNames(Cached)` only want "running" nodes. I hope this isn't too confusing, open to alternative ways of fixing the bug + making the code nice. ping @gnufied @kubernetes/sig-storage-bugs ```release-note Fix AWS EBS volumes not getting detached from node if routine to verify volumes are attached runs while the node is down ``` |
||
|---|---|---|
| .. | ||
| providers | ||
| BUILD | ||
| cloud.go | ||
| doc.go | ||
| OWNERS | ||
| plugins.go | ||
| README.md | ||
Deprecation Notice: This directory has entered maintenance mode and will not be accepting new providers. Cloud Providers in this directory will continue to be actively developed or maintained and supported at their current level of support as a longer-term solution evolves.
Overview:
The mechanism for supporting cloud providers is currently in transition: the original method of implementing cloud provider-specific functionality within the main kubernetes tree (here) is no longer advised; however, the proposed solution is still in development.
Guidance for potential cloud providers:
- Support for cloud providers is currently in a state of flux. Background information on motivation and the proposal for improving is in the github proposal.
- In support of this plan, a new cloud-controller-manager binary was added in 1.6. This was the first of several steps (see the proposal for more information).
- Attempts to contribute new cloud providers or (to a lesser extent) persistent volumes to the core repo will likely meet with some pushback from reviewers/approvers.
- It is understood that this is an unfortunate situation in which 'the old way is no longer supported but the new way is not ready yet', but the initial path is unsustainable, and contributors are encouraged to participate in the implementation of the proposed long-term solution, as there is risk that PRs for new cloud providers here will not be approved.
- Though the fully productized support envisioned in the proposal is still 2 - 3 releases out, the foundational work is underway, and a motivated cloud provider could accomplish the work in a forward-looking way. Contributors are encouraged to assist with the implementation of the design outlined in the proposal.
Some additional context on status / direction:
- 1.6 added a new cloud-controller-manager binary that may be used for testing the new out-of-core cloudprovider flow.
- Setting cloud-provider=external allows for creation of a separate controller-manager binary
- 1.7 adds extensible admission control, further enabling topology customization.