PersistentVolumeClaim
Does ZopNight manage PersistentVolumeClaim?
PersistentVolumeClaims provision cloud disks billed per provisioned GB whether or not data fills them. ZopNight records each claim's requested size, StorageClass, bound volume, and phase, and flags claims stuck Pending for over 1 hour. An unbound claim blocks every pod that mounts it, while a forgotten Bound claim keeps a disk billing.
Rules that fire on PersistentVolumeClaim
A PersistentVolumeClaim is a namespace-scoped request for storage. When a StorageClass provisions it dynamically, the claim becomes a real cloud disk, and that disk bills on the size requested, not the bytes actually written.
Requested gigabytes become the billing unit
Discovery stores each claim’s requested size as the resource’s GB figure, along with its StorageClass, the bound volume’s name, and reported capacity. The number matters because provisioned storage is a flat meter: a 500 GB claim holding 20 GB of data pays for 500. Claims also outlive the workloads that created them: deleting a StatefulSet leaves the PVCs from its volumeClaimTemplates behind by design, which is the single most common way Kubernetes quietly turns into a storage bill.
Pending means a blocked workload, not waste
A claim’s phase is lowercased into its status, and pending gets its own rule: Unbound PVC (RC-1740 / RC-1840 / RC-1940, medium severity). Pending is the normal state during binding, and a WaitForFirstConsumer class deliberately waits for a pod, so the rule only fires once a claim has been Pending for more than 1 hour. The finding is framed as a provisioning failure, not waste: every pod that mounts the claim is blocked from starting, and the fix is almost always in the StorageClass, not deleting the claim a workload is waiting on.
Reading a claim out of the inventory
Each PVC lands in the inventory under its cluster with namespace, storageClassName, volumeName, and capacity in metadata, plus labels when present. That is enough to answer the three questions that matter in review: what tier of disk did this claim create, is anything actually bound to it, and which namespace owns the spend.
kubectl get pvc -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,STATUS:.status.phase,VOLUME:.spec.volumeName,CLASS:.spec.storageClassName,REQUEST:.spec.resources.requests.storageCleanup order matters
Deleting a PVC only frees the cloud disk when the bound PV’s reclaim policy is Delete. Under Retain, removing the claim converts a billing, in-use disk into a billing, orphaned one. Check the PV’s policy first, then delete the claim.