Add documentation and release image for cleanup controller - #391
Conversation
|
Hi @justinblalock87. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions 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. |
|
/ok-to-test |
fc3f2dd to
fc607d8
Compare
| ## Overview | ||
|
|
||
| Pods using a Local Persistent Volume are always scheduled to the same Node as the Local PV it uses (as opposed to if they were using a HostPath volume, for instance). When Nodes fail while having a Local PV attached to them, Pods using the Local PV become stuck since they can't be scheduled to a deleted Node. In other words, the Local PV and its corresponding PVC aren’t cleaned up when a Node becomes unavailable and so each of them (PV/PVC/Pods) becomes stuck. This results in a degraded or unavailable workload. This controller aims to clean up the stale Local PVs and their bound PVCs after Node deletion, allowing workloads to automatically recover. | ||
|
|
There was a problem hiding this comment.
It's important to add the requirements that someone should consider before running this controller, such
as:
-
When the K8s Node is deleted, that actually means the underlying node and local PV data are already gone and irrecoverable. This is common in cloud environments, but not as common on-prem. This controller does not try to actively scrub data from the disks.
-
Some other controller, such as StatefulSet, needs to be able to recreate the PVC when it is deleted.
There was a problem hiding this comment.
Added these considerations.
| @@ -24,6 +24,7 @@ WINDOWS_DISTROS ?= | |||
| DOCKER=DOCKER_CLI_EXPERIMENTAL=enabled docker | |||
There was a problem hiding this comment.
This script also needs to be enhanced to support publishing multiple images:
https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner/blob/master/hack/release.sh#L110
There was a problem hiding this comment.
It looks like this script would already publish multiple images since it ultimately calls make cross
make cross command in the Makefile. The rest of the release.sh script determines the version number and creates a multi arch manifest for the local provisioner. I would assume the cleanup controller would just use the version of the local provisioner, and I'm wondering if a multi arch manifest is needed for this?
There was a problem hiding this comment.
The script appears to be doing some checks before "make cross", which may need to be extended to support multiple images:
|
/release-note-none |
acbd3c5 to
7c6f4f0
Compare
|
/approve One minor comment and we should be good to go! |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: justinblalock87, msau42 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
8b55e29 to
3a92ef7
Compare
|
/lgtm |
3a92ef7 to
f613a66
Compare
f613a66 to
96b0be1
Compare
Updated a grammatical error |
|
/lgtm |
What type of PR is this?
/kind documentation
What this PR does / why we need it:
Adds an example deployment and RBAC for the cleanup controller. This also adds the controller image to be pushed on release.
Special notes for your reviewer:
Release note: