In a September 21 post, Kubernetes introduced the PersistentVolumeClaimUnusedSinceTime feature gate as a default-on beta in 1.37. A PVC (PersistentVolumeClaim) is the object through which a Pod requests storage.
The PVC protection controller adds an Unused condition to each PVC. Unused=True means no non-terminal Pod references that PVC.
Even an unschedulable Pending Pod counts as use. Pods that are Succeeded or Failed do not count.
The post gives this command to check the condition status.
kubectl get pvc my-data -o jsonpath='{.status.conditions[?(@.type=="Unused")].status}'Caveats: observed time and stale conditions after disabling
According to KEP-5541, lastTransitionTime is when the controller observed that no Pod referenced the PVC. It is not when the volume was actually unmounted at the infrastructure level, and the reported unused duration can be shorter than actual but not longer.
When the feature is disabled, existing Unused conditions stay in etcd but are no longer updated. Right after an upgrade, a PVC may have no condition until a transition is observed.
Automatically deleting unused PVCs is explicitly a non-goal. The behavior described here is as defined in the sources, not observed on a test cluster.
What the reclaim policy actually deletes
The reclaim policy decides what a cleanup does. With supported plugins, the Delete policy removes both the PersistentVolume and the underlying storage.
Dynamically provisioned volumes follow the StorageClass reclaim policy, which defaults to Delete. A no-reference signal alone cannot tell whether the data can be deleted.
Starting with a read-only review list
Collect Unused=True PVCs into a read-only list first. Before any cleanup, confirm the owner, reuse plans, backups and the actual reclaim policy.
If the condition is missing or the feature was disabled for a period, its value alone is not enough evidence.
The Unused condition is not permission to delete but a list of PVCs someone needs to check.