Skip to main content
Kubernetes · Cloud cost · Data operations

Kubernetes PVC Cleanup:
A Safe Decision from the Unused Signal

Published: 1 October 2026·Zaid Aljbour, Managing Director·10 min read

Kubernetes PVC cleanup becomes more measurable in version 1.37, but it does not become automatically safe. The new Beta Unused condition shows whether a PersistentVolumeClaim (PVC) is currently referenced by no non-terminal Pod. Its lastTransitionTime gives operators a dependable starting point for review.

The signal does not prove that the data has lost business value or that a snapshot can be restored. Teams should use it to find candidates inside a controlled process—not connect it directly to a delete command.

Short answer: Inventory claims with Unused=True, wait for a period appropriate to the data, confirm ownership and recovery needs, inspect reclaim behaviour, test restoration, and delete only after recorded approval. Kubernetes starts the decision with evidence; it does not make the decision.

What the new Unused condition actually measures

Kubernetes 1.37 promotes the PersistentVolumeClaimUnusedSinceTime feature gate to Beta and enables it by default. The existing PVC protection controller sets Unused=True with reason NoPodsUsingPVC when no non-terminal Pod references the claim. A running or pending Pod that names the PVC changes the condition to False.

ObservationWhat it provesWhat remains unknown
Unused=TrueNo non-terminal Pod references the PVCOwner, data value, planned future use
lastTransitionTimeWhen the controller observed the transitionExact infrastructure unmount time
No Unused conditionNo useful conclusionFeature state, upgrade and first transition
Unused=FalseAt least one non-terminal Pod names the PVCWhether that Pod reads or writes data

A batch Pod in Succeeded or Failed phase no longer counts as a user. A Pending Pod that cannot be scheduled does count, because intent in the Pod specification is protected. The Kubernetes Enhancement Proposal (KEP) also explains that controller observation may follow the real unmount by seconds or minutes. The reported idle period can therefore be shorter than reality, but should not be longer.

Why Unused=True is not deletion approval

A PVC can intentionally exist without an active Pod. Examples include a paused test environment, a monthly batch run, an operator-triggered analysis job, a StatefulSet during migration, or data held for recovery. A deleted Deployment can also remain part of the desired state in Git, Terraform or a release system outside the cluster.

Automatic deletion is explicitly a non-goal of KEP-5541. That boundary is sound: Kubernetes understands Pod references, but not contractual retention, data classification, business ownership or restart plans. A safe workflow therefore joins technical evidence with accountable approval.

Important boundary: If an operator disables the feature gate, existing conditions remain stored in etcd but stop receiving updates. Before automating any report, verify that kube-controller-manager is actively maintaining the signal and that status-update errors are observable.

A risk matrix for unused PersistentVolumeClaims

One waiting period for every claim is convenient and unsafe. The purpose of the data should determine the delay, recovery evidence and approver. The following matrix is ATMAN’s decision model, not a Kubernetes requirement.

ClassExamplesMinimum evidence before deletion
EphemeralPreview environment, reproducible test dataOwner rule, short delay, reproducible manifest
OperationalCI cache, import staging, internal serviceDependency check, defined delay, documented recovery path
Business-criticalApplication database, production filesSnapshot or backup, successful restore test, dual approval
RegulatedAudit, contractual or personal dataRetention and deletion rule, data owner, recorded approval

Labels such as owner, data-class, retention and restore-tier make decisions reviewable. Missing labels should trigger manual clarification, not faster deletion. For cost allocation, also capture the StorageClass, requested capacity, zone and provider volume identifier.

Six gates for safe Kubernetes PVC cleanup

  1. Read candidates without mutation. List PVCs with Unused=True and lastTransitionTime across the cluster. The first automation should produce a report; it must not patch or delete anything.
  2. Verify signal health. Confirm Kubernetes 1.37, the active feature gate and recent condition transitions. Monitor pvc_protection_controller_unused_condition_syncs_total and controller errors before calculating a waiting period.
  3. Exclude planned use. Search CronJobs, paused workloads, StatefulSets, GitOps manifests, Helm releases and recovery plans. A Pod missing today can be expected to return tomorrow.
  4. Confirm the owner and protection class. Assign the namespace and claim to an accountable team. Unknown claims enter quarantine or a ticket queue; they do not enter automatic deletion.
  5. Prove the recovery path. Inspect the StorageClass and reclaim policy. Create suitable protection for valuable data. Kubernetes VolumeSnapshots require a compatible CSI driver, and the restore must work in the topology where recovery is needed.
  6. Approve, delete and reconcile. Record the candidate, idle period, owner, recovery evidence and approval. Delete the PVC in a controlled window, then reconcile the PV, provider volume, snapshot retention, application state and cost inventory.

This workflow belongs in Cloud and DevOps operations with reviewable changes. For sensitive applications, retention and deletion authority also belong in the cybersecurity and data model. If the cluster is only now moving to 1.37, keep the separate node-change and rollback assessment distinct from storage cleanup.

Reclaim policy and snapshots answer different questions

The reclaim policy controls what happens to a PersistentVolume after its claim is deleted. Dynamically provisioned volumes normally inherit it from the StorageClass. Delete can remove the external storage asset with the PV; Retain keeps it for manual recovery. Neither value decides how long the organisation should keep the data.

A VolumeSnapshot is not a universal backup either. Kubernetes exposes snapshot objects only for CSI drivers, and the driver must implement the operation. The snapshot DeletionPolicy, provider retention and topology also affect whether data survives and where it can be restored. The useful release gate is therefore not “snapshot exists”, but “restore succeeded under the required conditions”.

Frequently asked questions about Kubernetes PVC cleanup

Does Kubernetes 1.37 automatically delete unused PVCs?

No. Kubernetes only adds the informational Unused condition and a transition timestamp. The operator remains responsible for deletion policy, waiting period, approval and recovery evidence.

Does Unused=True mean the data is no longer needed?

No. It only means that no non-terminal Pod currently references the claim. Scheduled jobs, paused applications, recovery plans and dependencies outside the cluster need separate checks.

Is a VolumeSnapshot sufficient backup before deletion?

Only when CSI support, retention, topology and recovery have been verified. A snapshot that exists but has not passed a restore test is not yet dependable recovery evidence.

What waiting period should unused PVCs have?

There is no universal period. Reproducible development data may justify a short delay, while production, audit or recovery data usually needs longer, owner-specific rules. The data purpose and tested recovery objective should determine the period.

Start with a read-only report

The next step is not deletion automation. Start with a read-only report for one bounded cluster, review false candidates, and add missing ownership data. Only after recovery and approval work in practice should observation become a controlled action.

Sources and methodology

This article separates Kubernetes behaviour from ATMAN’s recommendation for a risk-based approval workflow. The matrix and six gates are technical analysis, not features or requirements of the Kubernetes project. All sources were accessed on 1 October 2026.