From e1d20f75eb47c129eb1f84d7a25f558aea9de0eb Mon Sep 17 00:00:00 2001 From: Deepak Kinni Date: Fri, 26 Jul 2024 13:51:06 -0700 Subject: [PATCH] Apply suggestions from code review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: 杨朱 · Kiki Co-authored-by: Nate W --- ...2024-06-19-Honor-PV-Reclaim-Policy-Beta.md | 45 ++++++++++--------- 1 file changed, 23 insertions(+), 22 deletions(-) diff --git a/content/en/blog/_posts/2024-06-19-Honor-PV-Reclaim-Policy-Beta.md b/content/en/blog/_posts/2024-06-19-Honor-PV-Reclaim-Policy-Beta.md index ba47eeca87c47..821f666220b62 100644 --- a/content/en/blog/_posts/2024-06-19-Honor-PV-Reclaim-Policy-Beta.md +++ b/content/en/blog/_posts/2024-06-19-Honor-PV-Reclaim-Policy-Beta.md @@ -8,11 +8,11 @@ author: > --- [PersistentVolume](/docs/concepts/storage/persistent-volumes/) (or PVs for short) are -associated with [Reclaim Policy](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#reclaim-policy). +associated with [Reclaim Policy](/docs/concepts/storage/persistent-volumes/#reclaim-policy). The Reclaim Policy is used to determine the actions that need to be taken by the storage backend on deletion of the PV. Where the reclaim policy is `Delete`, the expectation is that the storage backend -releases the storage resource that was allocated for the PV. In essence, the reclaim +releases the storage resource allocated for the PV. In essence, the reclaim policy needs to honored on PV deletion. With the recent Kubernetes v1.31 release, a beta feature lets you configure your @@ -22,23 +22,23 @@ cluster to behave that way and honor the configured reclaim policy. ## How did reclaim work in previous Kubernetes releases? [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/#Introduction) (or PVC for short) is -a request for storage by a user. A PV and PVC are considered [Bound](/docs/concepts/storage/persistent-volumes/#Binding) -if there is a newly created PV or a matching PV is found. The PVs themselves are +a user's request for storage. A PV and PVC are considered [Bound](/docs/concepts/storage/persistent-volumes/#Binding) +if a newly created PV or a matching PV is found. The PVs themselves are backed by a volume allocated by the storage backend. Normally, if the volume is to be deleted, then the expectation is to delete the -PVC for a bound PV-PVC pair. However, there are no restrictions to delete a PV -prior to deleting a PVC. +PVC for a bound PV-PVC pair. However, there are no restrictions on deleting a PV +before deleting a PVC. -First, I'll demonstrate the behavior for clusters that are running an older version of Kubernetes. +First, I'll demonstrate the behavior for clusters running an older version of Kubernetes. -#### Retrieve an PVC that is bound to a PV +#### Retrieve a PVC that is bound to a PV Retrieve an existing PVC `example-vanilla-block-pvc` ``` kubectl get pvc example-vanilla-block-pvc ``` -The following output shows the PVC and it's `Bound` PV, the PV is shown under the `VOLUME` column: +The following output shows the PVC and its `Bound` PV; the PV is shown under the `VOLUME` column: ``` NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE example-vanilla-block-pvc Bound pvc-6791fdd4-5fad-438e-a7fb-16410363e3da 5Gi RWO example-vanilla-block-sc 19s @@ -63,7 +63,7 @@ persistentvolume "pvc-6791fdd4-5fad-438e-a7fb-16410363e3da" deleted kubectl get pv pvc-6791fdd4-5fad-438e-a7fb-16410363e3da ``` -It can be observed that the PV is in `Terminating` state +It can be observed that the PV is in a `Terminating` state ``` NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-6791fdd4-5fad-438e-a7fb-16410363e3da 5Gi RWO Delete Terminating default/example-vanilla-block-pvc example-vanilla-block-sc 2m23s @@ -91,14 +91,14 @@ kubectl get pv pvc-6791fdd4-5fad-438e-a7fb-16410363e3da Error from server (NotFound): persistentvolumes "pvc-6791fdd4-5fad-438e-a7fb-16410363e3da" not found ``` -Although the PV is deleted the underlying storage resource is not deleted, and +Although the PV is deleted, the underlying storage resource is not deleted and needs to be removed manually. -To sum it up, the reclaim policy associated with the Persistent Volume is currently -ignored under certain circumstance. For a `Bound` PV-PVC pair the ordering of PV-PVC +To sum up, the reclaim policy associated with the Persistent Volume is currently +ignored under certain circumstances. For a `Bound` PV-PVC pair, the ordering of PV-PVC deletion determines whether the PV reclaim policy is honored. The reclaim policy -is honored if the PVC is deleted first, however, if the PV is deleted prior to -deleting the PVC then the reclaim policy is not exercised. As a result of this behavior, +is honored if the PVC is deleted first; however, if the PV is deleted prior to +deleting the PVC, then the reclaim policy is not exercised. As a result of this behavior, the associated storage asset in the external infrastructure is not removed. ## PV reclaim policy with Kubernetes v1.31 @@ -107,12 +107,13 @@ The new behavior ensures that the underlying storage object is deleted from the #### How to enable new behavior? -To make use of the new behavior, you must have upgraded your cluster to the v1.31 release of Kubernetes. -You need to make sure that you are running the CSI [`external-provisioner`](https://github.com/kubernetes-csi/external-provisioner) version `5.0.1`, or later. +To take advantage of the new behavior, you must have upgraded your cluster to the v1.31 release of Kubernetes +and run the CSI [`external-provisioner`](https://github.com/kubernetes-csi/external-provisioner) version `5.0.1` or later. #### How does it work? -For CSI volumes, the new behavior is achieved by adding a finalizer `external-provisioner.volume.kubernetes.io/finalizer` on new and existing PVs, the finalizer is only removed after the storage from backend is deleted. +For CSI volumes, the new behavior is achieved by adding a finalizer `external-provisioner.volume.kubernetes.io/finalizer` on new and existing PVs. The finalizer is only removed after the storage from the backend is deleted. +` An example of a PV with the finalizer, notice the new finalizer in the finalizers list @@ -159,7 +160,7 @@ status: phase: Bound ``` -The presence of the finalizer prevents the PV object from being removed from the +The the finalizer prevents the PV object from being removed from the cluster. As stated previously, the finalizer is only removed from the PV object after it is successfully deleted from the storage backend. To learn more about finalizers, please refer to [Using Finalizers to Control Deletion](/blog/2021/05/14/using-finalizers-to-control-deletion/). @@ -168,11 +169,11 @@ Similarly, the finalizer `kubernetes.io/pv-controller` is added to dynamically p #### What about CSI migrated volumes? -The fix is applicable to CSI migrated volumes as well. +The fix applies to CSI migrated volumes as well. ### Some caveats -The fix is not applicable to statically provisioned in-tree plugin volumes. +The fix does not apply to statically provisioned in-tree plugin volumes. ### References @@ -190,4 +191,4 @@ Special thanks to the following people for the insightful reviews, thorough cons * Xing Yang (xing-yang) * Matthew Wong (wongma7) -Those interested in getting involved with the design and development of CSI or any part of the Kubernetes Storage system, join the [Kubernetes Storage Special Interest Group (SIG)](https://github.com/kubernetes/community/tree/master/sig-storage). We’re rapidly growing and always welcome new contributors. \ No newline at end of file +Join the [Kubernetes Storage Special Interest Group (SIG)](https://github.com/kubernetes/community/tree/master/sig-storage) if you're interested in getting involved with the design and development of CSI or any part of the Kubernetes Storage system. We’re rapidly growing and always welcome new contributors. \ No newline at end of file