LEARN. PRACTICE. GROW.Concept and mechanism
A PersistentVolumeClaim requests storage with characteristics; a PersistentVolume represents supplied storage. A StorageClass may define dynamic provisioning and binding behavior. With WaitForFirstConsumer, selection may wait for Pod context to respect topology. A Pending claim without a consumer does not prove driver failure. The mechanism also depends on scheduling; directly setting nodeName may bypass it and leave the flow unfinished. Read claim, Pod, and provisioner events and conditions before deleting objects that may still reference needed data.
Guided application
ReadWriteOnce refers to read-write mounting by one node, potentially allowing several Pods there to use the volume; it is neither a single-Pod guarantee nor application write coordination. ReadWriteOncePod provides another restriction when supported by CSI and applicable requirements. At retirement, Retain preserves storage for manual handling but creates no backup and sanitizes no content. For expansion, verify allowVolumeExpansion, driver and filesystem support, increase the PVC request, and observe effective capacity. The mechanism supports growing, not shrinking. Any data migration needs validation and its own recovery decision.
A 20Gi PVC needs to grow to 40Gi. Review StorageClass and events, confirm data recoverability, and validate application-observed size after the supported procedure.
Common pitfalls
Deleting a Pending claim without diagnosis; confusing RWO with one Pod; reusing Retain without checking data; declaring expansion merely by editing the PV.
Related topics: Diagnose workloads with evidence · Nodes and control plane
The Kubernetes object lifecycle and data lifecycle need coordinated decisions.
Reference: Persistent volumes · CKA Kubernetes v1.35