Transit sets a PV reclaimPolicy of Delete for dynamically provisioned disks. What happens when the bound PVC is deleted?
Select an answer to reveal the explanation.
Short Explanation
Delete reclaim is the self-cleaning rental car—turn in the keys (delete the PVC) and the car gets returned to the lot (backend disk goes away). Great for disposable data; terrifying for irreplaceable archives. Know that policy before you delete claims.
Full Explanation
When transit sets a PV reclaimPolicy of Delete for dynamically provisioned disks, deleting the bound PVC typically deletes the PersistentVolume and the external backend disk according to that policy. Delete reclaim is the self-cleaning rental car—turn in the keys and the asset returns to the cloud lot. Appropriate for disposable data; dangerous for irreplaceable archives.
PVC deletion is not blocked forever unless an administrator annotates force-retain as the standard Delete behavior. Kubernetes does not convert the PV to hostPath to keep the cloud disk indefinitely. Delete does affect external volumes for dynamic provisioners—it is not “PVC object only.”
Exam caveat: timing can involve finalizers while volumes are still mounted. Always know reclaimPolicy before deleting claims in production municipal systems. Retain is the alternative when humans must review data first.
Operational check: in a non-prod class with Delete, create PVC+PV, delete the PVC, confirm the PV and cloud disk disappear, and document which transit classes use Delete versus Retain. Keep civic change tickets precise: record object names, namespaces, and before/after observations so the next on-call engineer can replay the fix without guesswork.