CODEWITHSUNDEEP
kubernetes
Newbie
Newbie

Reputation: 4849

When PersistentVolumes are deleted on kubernetes?

This question arose when we ran a kubectl delete -f on a file that somehow contained the declaration of the namespace where an entire test deployment existed.

The system (not configured by us, hence a bit obscure to us) had volumes provisioned by an OpenEBS system.

Within the deleted namespace there were some PVCs that had PVs provisioned on OpenEBS. When the namespace was deleted PVCs were deleted and all the PVs too.

I read quite some documentation, but I have not found an explicit answer to my question. Knowing that;

The only case when PVs are deleted as a consequence of a namespace deletion is if the namespace contains a PVC bound to a PV with a reclaimPolicy: Delete. Hence all the provisioned PVs in our system had this issue. Or m I missing something?

Upvotes: 1

Views: 1690

Answers (2)

Rotem jackoby
Rotem jackoby

Reputation: 22218

I'll refer to the title:

When PersistentVolumes are deleted on kubernetes?

In general:

The lifecycle of the PersistentVolumes dependent on the Claims for that PV.
(Weather you created the PV manually or used Dynamic Provisioning where you define a StorageClass and a PVC and the PV is created behind the scenes).

Are you using StatefulSets or Deployments?:

(1) If you're using a StatefulSet you define a Volume Claim Templates to create the PVC and you use PersistentVolumeClaim retention to controls if and how PVCs are deleted during the lifecycle of a StatefulSet.

The default policy is not to delete the PVC in cases where the StatefulSet is deleted or scaled down - so the PVC will be Retained.

For more information - see this answer in SO.

(2) If you're using a Deployment then there is no additional wrapping mechanisms like in StatefulSets and you depend directly on this lifecyle of the claims of the PV. See below.

Relevant for both cases:

Q: What happen when the PV is no longer in use?
A: Reclaim policy.
When a user is done with their volume, they can delete the PVC objects from the API that allows reclamation of the resource. The reclaim policy for a PersistentVolume tells the cluster what to do with the volume after it has been released of its claim. Currently, volumes can either be Retained, Recycled, or Deleted.

Q: Can a PV in use be removed?
A: Storage Object in Use Protection
The purpose of the Storage Object in Use Protection feature is to ensure that PersistentVolumeClaims (PVCs) in active use by a Pod and PersistentVolume (PVs) that are bound to PVCs are not removed from the system, as this may result in data loss.

Note: PVC is in active use by a Pod when a Pod object exists that is using the PVC.

If a user deletes a PVC in active use by a Pod, the PVC is not removed immediately. PVC removal is postponed until the PVC is no longer actively used by any Pods. Also, if an admin deletes a PV that is bound to a PVC, the PV is not removed immediately. PV removal is postponed until the PV is no longer bound to a PVC.

You can see that a PVC is protected when the PVC's status is Terminating and the Finalizers list includes kubernetes.io/pvc-protection.

Q: (Bonus) If a PV is deleted - does it mean that the backend storage is deleted?
A: No, the reclaim policy associated with the PersistentVolume 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, the associated storage asset in the external infrastructure is not removed.

From v1.31 you can use the PersistentVolume deletion protection finalizer feature which honours the reclaim policy before deletion through a deletion protection finalizer. Thus, you can ensure that Persistent volumes with a Delete reclaim policy are deleted only after the backing storage is deleted.

So, finalizers are added to the PV to ensure that PVs having Delete reclaim policy are deleted only after the backing storage are deleted.
The finalizer external-provisioner.volume.kubernetes.io/finalizeris added to both dynamically provisioned and statically provisioned CSI volumes.

Upvotes: 0

Sahadat Hossain
Sahadat Hossain

Reputation: 4389

Basically the flow is like:

  • when a namespace is deleted, all the objects inside this namespace is also will be deleted
  • Now, if there is any PVC in that deleted namespace then it will be deleted
  • According to the rules, If a PVC is deleted then it's bounded PV will also be deleted if the reclaimPolicy is delete.

N.B: Normally to delete a PVC first you need to delete the pods those are referencing it. And to delete a bound PV first you need to delete it's respective PVC. Deletion system is like : first pods (who are referencing that PVC) get deleted then the respective PVC and then the PV(if reclainPolicy is delete).

Upvotes: 2

Related Questions