Leadership1 publisher3 min readPublished
Kubernetes 1.37 stamps every idle storage claim with the time it went unused
Kubernetes 1.37 turns on the PVC Unused condition by default and records when each storage claim stopped being referenced by a live pod. Finding idle claims is now built in, so platform teams have to decide who sets the deletion threshold and who answers for a mistake.
The Board Room · Leadership desk
What happened
- Until now, telling whether a claim was still in use meant cross-referencing pods, volumes and claims over time, often with custom monitoring scripts.
- Kubernetes still does not delete a claim when its pods are removed, to guard against accidental data loss, so orphaned claims keep adding to cloud storage bills.
- Pods that have finished, in phase Succeeded or Failed, do not count as users, so a completed batch job's claim switches to Unused.
Compiled by The Board RoomSomething wrong?How this is made
Why it matters
- capability Once clusters reach 1.37, platform teams can read whether a claim is idle straight from its status, and the scripts built to cross-reference pods and claims can be retired.
- exposure A deletion rule based on age will pick up claims holding output from jobs that finished long ago, so a careless threshold turns a storage saving into lost data.
- decision Someone now has to pick the idle threshold and approve deletions in production; the 30-day figure in the project's post comes from an example query.
- precedent The project limits its own automation example to development environments, which gives teams writing a first cleanup rule a stated boundary to start from.
The board-deck version of this release is that Kubernetes now finds abandoned storage on its own. The condition actually answers a narrower question. The PVC protection controller already watches pods. It now sets the condition based on whether any pod that has not terminated references the claim [2][7]. A pending pod counts, even one with an impossible node selector, because the project treats the intent to use a volume as use [6]. A pod that has finished does not count [5].
The homegrown tooling goes away. To tell whether a claim was in use, administrators used to cross-reference pods, volumes and claims across a long window of time, and many built monitoring pipelines and scripts to do it [4]. The post puts the question those scripts answered as "Is anything actually using this volume?" [12]. In 1.37 the answer is in the claim's status, with the reason NoPodsUsingPVC when nothing is using it [13].
Batch work is where a claim nobody references and a claim nobody needs come apart. A job with restartPolicy: Never that writes results to a claim leaves that claim at Unused=True as soon as it finishes [5]. The lastTransitionTime field records the moment of that change, and the post shows a query for claims idle more than 30 days [8]. Used as a deletion rule, that query would pick up the output of any such job that last ran more than a month ago [1].
Kubernetes still refuses to delete claims when their pods go away. The post gives protection against accidental data loss as the reason [3]. The project added a signal and left deletion where it was. Its user stories show where it expects automation to start. One is a DevOps engineer who wants to list Unused claims "so I can automate cleanup in development environments" [10]. The other is a storage administrator who wants to find orphaned volumes and "schedule them for deletion" [11].
This quarter's decision is administrative. In my view the project's development-environment scope is the right place for a first rule, with a named person picking the threshold and approving any deletion in production. That choice has a consequence next quarter. Once a rule deletes by age, a false positive is lost data with an owner attached. It gets weighed against the cloud storage costs that orphaned claims were adding in the first place [3].
None of this has to happen this week. Version 1.36 shipped the feature as an alpha that had to be switched on explicitly. The 1.37 beta is on by default and has full end-to-end test coverage, according to the project [9]. The condition appears on claims automatically once a cluster runs 1.37 [1]. The post does not say what lastTransitionTime will show on claims that were already idle before an upgrade [8]. If it records the moment the controller first set the condition, a 30-day rule run in the month after an upgrade would find nothing older than the upgrade itself [8].
What to watch
- Whether the Kubernetes project documents what lastTransitionTime shows on claims that were already idle when a cluster upgrades to 1.37.
- Whether the Unused condition's handling of pending and terminated pods changes before the feature graduates from beta to stable.