How Can I Delete the Underlying Storage If It Remains After a Dynamically Created PVC is Deleted?

Symptom

After a dynamically created PVC with the reclaim policy in its StorageClass set to Delete was deleted from a cluster, the underlying storage volume of the PVC is not deleted simultaneously.

Trigger Conditions

• A PVC and its bound PV are deleted simultaneously.
• The PV bound to a PVC is deleted first and then the PVC is deleted, but the PV deletion fails due to the PVC/PV binding.

Possible Causes

Under normal circumstances, when a dynamically created PVC is deleted in the open-source csi-provisioner module, the PVC is deleted first, followed by a change in the status of the PV bound to the PVC to Released. The csi-provisioner module then listens for PV changes, proceeds to delete the underlying storage volume, and deletes the PV, completing the deletion chain.

During abnormal operations, the PV bound to a PVC may be directly deleted without deleting the PVC first. However, the kubernetes.io/pv-protection finalizer on the PV prevents immediate deletion. Instead, deletionTimestamp is added to the PV. After the PVC is deleted, the PV status is changed to Released. Although csi-provisioner listens for PV changes, it skips the process of deleting the underlying storage volume because deletionTimestamp has been added to the PV. As a result, csi-provisioner directly deletes the PV, and both the PVC and PV are deleted, but the underlying storage volume remains. For details about the code logic, see controller.

Solution

1. Manually delete the residual underlying storage volumes.
2. Directly delete the dynamically created PVCs that remained after the deletion. The PVs and underlying storage volumes will be deleted automatically.