Persistent Volume Claim
A PersistentVolumeClaim requests storage capacity and access through the Kubernetes API. It usually leaves asset selection to the cluster, but can name a specific PV with volumeName. Provisioning and consumption remain separate responsibilities.
A PV represents storage available to the cluster; a PVC binds a workload’s request to that storage. Its lifecycle is independent of any one Pod.
That abstraction can make a 20 GiB claim reusable across environments, provided their storage classes, drivers and topology satisfy the same requirements. A host directory can also be declared with Kubernetes hostPath; a PVC adds a separate binding and storage lifecycle rather than being the only cluster-level way to mount storage.
Where the volume comes from
Static provisioning uses PVs prepared by an administrator. Dynamic provisioning can create storage for a claim through its configured StorageClass and provisioner.
An omitted storageClassName can receive the default class; storageClassName: "" requests no class. A Pending claim is not proof of a missing class: WaitForFirstConsumer intentionally defers binding until a consuming Pod is created so placement requirements can inform storage selection. Inspect claim and Pod Events, class settings and provisioner health.
Deleting an individual Pod does not by itself delete its PV. Whether the data survives deletion of the claim is a separate policy decision.
The default that deletes your disk
After a claim is released, the PV’s reclaim policy determines the next step. Delete can remove both the PV object and the backing asset when the volume plugin supports it. Retain preserves the asset for manual handling. Recycle is deprecated.
A dynamically provisioned PV inherits its StorageClass reclaim policy, which defaults to Delete. Inspect the PV itself for the current value; its policy may have been changed after creation.
Chain those. Dynamic provisioning is the convenient route, it inherits the class’s policy, and the policy defaults to Delete. So deleting a PVC — or a namespace that contains one — can destroy the real disk, and nothing in the manifest that did it mentions deletion.
With Retain, the released PV still holds the former claimant’s data and is not automatically available to a new claimant. Recovery must preserve that asset. Confirm its identity and prior attachment, then use a driver-appropriate rebinding procedure; the documentation describes creating a PV that refers to the same retained asset. Cleaning the data and deleting the backing asset belong to disposal, not recovery. Do not run those destructive steps when the objective is to retain the data.
Three things to do with that, in order of how quickly they pay off.
- Inspect the bound PV. Follow the PVC’s volumeName and read persistentVolumeReclaimPolicy. Also check the StorageClass and any controller retention policy that may delete the claim.
- Choose a recovery and disposal policy. A disposable cache may suit Delete; valuable database data may require Retain and a controlled recovery procedure. The workload’s recovery requirements decide.
- Keep independent backups. Retain avoids automatic backing-asset deletion through reclaim, but does not protect against corruption, storage failure or an administrator deleting that asset.
For StatefulSets, claim retention comes first. persistentVolumeClaimRetentionPolicy.whenDeleted and whenScaled default to Retain; supported versions also allow Delete for template-created claims affected by those actions. A deleted PVC then follows its PV’s reclaim policy. A replacement Pod after failure can reuse the existing claim.
Mount scope and write protection are separate
A claim states an access mode, and the modes are easy to misread in two separate ways.
| Mode | What it actually says |
|---|---|
| ReadWriteOnce (RWO) | Read-write on one node; multiple Pods on that node may use it |
| ReadOnlyMany (ROX) | Read-only access capability from multiple nodes; verify actual write protection |
| ReadWriteMany (RWX) | Read-write access from multiple nodes, where supported by the driver |
| ReadWriteOncePod (RWOP) | One Pod across the cluster; CSI only, with compatible driver and sidecars |
RWO does not serialize application writes. Two Pods on one node may write concurrently; whether that is safe depends on locking and the application’s storage contract. RWOP provides the single-Pod restriction. It is stable since Kubernetes 1.29 and requires compatible CSI components; verify the documented sidecar requirements for the installed driver.
Access modes participate in matching and can constrain mounting. The separate warning is that they do not enforce write protection after mount: ROX alone does not guarantee that writes are impossible. Driver attachment and mount restrictions still matter.
Where read-only access is required, verify read-only mount settings and storage permissions or credentials across all relevant access paths. Application-level correctness still needs its own controls.
A volume uses one access mode at a time even if its PV lists several supported modes. The capability list does not establish how it is currently mounted.
Per-replica storage
Stable replica identity and dedicated storage are different requirements. When a StatefulSet defines volumeClaimTemplates, each Pod receives one PVC for each template. A workload needing stable identity alone need not define those templates. An omitted class can still select the default class.
PVCs are namespaced; PVs are cluster-scoped. Moving between namespaces therefore requires a planned storage transition, not renaming a claim. Namespace deletion can remove PVCs and initiate reclaim of their backing PVs after applicable protection handling. Inspect each binding and policy before teardown. See Ephemeral by Default for the workload context, and desired state and control loop for its controllers.
References
Discover more from Insightful Data Lab
Subscribe to get the latest posts sent to your email.