Persistent Volume Reclaim Policy

User Guides for VMware Solutions

Audience
Public
Content Type
User Guides
Source Type
Documentation

By default within VMware Tanzu, a Persistent Volume will exist as long as the deployment - meaning it will be deleted along with the rest of the Kubernetes deployment when the devops user shuts it down. This is due to the default persistentVolumeReclaimPolicy being set to Delete. However, changing the persistentVolumeReclaimPolicy of a persistent volume to Retain enables Tanzu users to save and re-use persistent data easily.

The easiest way to retain an existing PV is with the following kubectl CLI command:

​kubectl patch pv (PV_Name) -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'

The below sequence shows an example of how to change a PV reclaim policy. Note that this operation can be done while the volume is bound to a PVC without causing any issues.

With the retention policy set to Retain, that means that the persistent data will be available to be used once either the application or the PVC are deleted.

Here we see that our PV is set to Retain and is bound to a PVC called pvc-vvols-mysql.

$ kubectl get pv

NAME                                       CAPACITY    RECLAIM POLICY   STATUS   CLAIM                     STORAGECLASS

pvc-f37c39fd-dbe9-4f27-abe8-bca85bf9e87c   6Gi         Retain           Bound    default/pvc-vvols-mysql   cns-vvols        

Looking at the PVC also confirms the connection between the PV and PVC:

$ kubectl get pvc

NAME             STATUS  VOLUME                                    CAPACITY       STORAGECLASS

pvc-vvols-mysql  Bound   pvc-f37c39fd-dbe9-4f27-abe8-bca85bf9e87c  6Gi            cns-vvols 

If we want to use the PV with a new PVC, the claim that the PV is attached to must first be removed or deleted

$ kubectl delete pvc pvc-vvols-mysql

persistentvolumeclaim "pvc-vvols-mysql" deleted

There can be a caveat with re-using a persistent volume after the associated persistent volume claim is deleted, though, and that is seen when the Persistent Volume is in the Released status after the PVC has been deleted. This is because while the PVC is gone, the claim associated with the PV still exists and needs to be manually removed.

$ kubectl get pv

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS     
            CLAIM                     STORAGECLASS

pvc-f37c39fd-dbe9-4f27-abe8-bca85bf9e87c   6Gi        RWO            Retain           Released   
            default/pvc-vvols-mysql   cns-vvols            

In order to revert the PV into an available state, the following kubectl patch command must be run against the volume to remove the stale PVC:

kubectl patch pv pvc-f37c39fd-dbe9-4f27-abe8-bca85bf9e87c -p '{"spec":{"claimRef": null}}'

With the PV patched to remove the old PVC claim, it now reverts to an available state and can be bound to a different PVC:

kubectl get pv

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      
            CLAIM   STORAGECLASS

pvc-f37c39fd-dbe9-4f27-abe8-bca85bf9e87c   6Gi        RWO            Retain           Available           cns-vvols