In Kubernetes, what happens to a Persistent Volume (PV) when its Persistent Volume Claim (PVC) is deleted and the PV has a Delete reclaim policy?
Think about what Delete reclaim policy means for storage lifecycle.
With the Delete reclaim policy, deleting the PVC causes Kubernetes to delete the PV and its associated storage resource automatically.
What is the behavior of a Persistent Volume (PV) with a Retain reclaim policy after its Persistent Volume Claim (PVC) is deleted?
Consider what manual steps are needed when reclaim policy is Retain.
With Retain policy, the PV is not deleted after PVC deletion. It stays in Released state and requires manual intervention to clean or reuse.
Given a Persistent Volume with reclaim policy set to Retain, what is the status of the PV after its bound Persistent Volume Claim is deleted?
kubectl get pv my-pvCheck the PV lifecycle states after PVC deletion with Retain policy.
When PVC is deleted and PV has Retain policy, PV status changes to Released indicating it is no longer bound but data remains.
Which sequence correctly describes the steps to reuse a Persistent Volume (PV) that has a Retain reclaim policy after its Persistent Volume Claim (PVC) was deleted?
Think about cleaning data before making PV available again.
First, data must be cleaned manually. Then PV status is reset to Available. Next, a new PVC is created to bind to the PV.
A Persistent Volume (PV) with reclaim policy set to Delete is not deleted after its Persistent Volume Claim (PVC) was removed. What is the most likely cause?
Consider what might prevent Kubernetes from deleting storage resources.
Finalizers on the storage resource can block deletion even if reclaim policy is Delete, causing PV to remain.