Kubernetesは9月21日の記事で、PersistentVolumeClaimUnusedSinceTime機能ゲートを1.37のデフォルト有効ベータとして紹介した。PVC（PersistentVolumeClaim）はPodがストレージを要求するためのオブジェクトだ。

PVC保護コントローラーが各PVCにUnused条件を付ける。Unused=Trueは、終了していないPodがそのPVCを参照していないことを意味する。

スケジュールできないPendingのPodも使用中と数える。Succeeded（完了）やFailed（失敗）のPodは除外する。

記事は条件の状態を確認するコマンドを次のように示している。

kubectl get pvc my-data -o jsonpath='{.status.conditions[?(@.type=="Unused")].status}'

注意点：観測時刻と機能無効化後の古い条件

KEP-5541によると、lastTransitionTimeはコントローラーがPodの参照がないことを観測した時刻だ。インフラで実際にアンマウントされた時刻ではなく、報告される未使用期間は実際より短いことはあっても長くはならない。

機能を無効にすると、既存のUnused条件はetcdに残るがそれ以上更新されない。アップグレード直後のPVCには、遷移が観測されるまで条件がないことがある。

未使用PVCの自動削除は設計目標から明示的に外されている。ここで述べた動作は資料上の定義であり、テストクラスターで観測した結果ではない。

回収ポリシーが決める実際の削除範囲

整理作業の結果は回収ポリシー（reclaim policy）が決める。対応プラグインでは、DeleteポリシーがPersistentVolumeと実際のストレージを一緒に削除する。

動的に作成されたボリュームはStorageClassの回収ポリシーに従い、そのデフォルトはDeleteだ。参照がないというシグナルだけでは、データを削除してよいかは分からない。

読み取り専用の確認リストから始める手順

まずUnused=TrueのPVCを読み取り専用のリストにまとめる。整理の前に、所有者、再利用の予定、バックアップ、実際の回収ポリシーを確認する。

条件がない場合や機能を無効にしていた期間がある場合、その値だけでは根拠が足りない。

Unused条件は削除の許可ではなく、誰かが確認すべきPVCのリストだ。