Free tools Windows power users keep installed
One-click scans. No signup required.
To manage a Kubernetes PersistentVolume (PV) safely, decide how it should be provisioned, what should happen when its claim is deleted, and whether it can be expanded or snapshotted. A PV can outlive both a Pod and a PersistentVolumeClaim (PVC); deleting one does not automatically mean the others are deleted. The exact outcome depends on the PV reclaim policy, StorageClass, and storage driver.
Understand how PVs, PVCs, and StorageClasses relate
A PV is a cluster storage resource, provisioned manually or dynamically through a StorageClass. A PVC is a workload’s request for storage; Kubernetes binds it to a matching PV. The underlying storage may use NFS, iSCSI, or a provider-specific system. Kubernetes describes the interface, but not every backend’s operational guarantees. See the official Persistent Volumes documentation.
- Pod: Uses a PVC. Deleting a Pod is not the same as deleting the claim or the PV.
- PVC: Requests storage and binds to a suitable PV.
- PV: Represents the provisioned storage resource and has a reclaim policy that controls its fate after its claim is released.
- StorageClass: Describes a storage offering, including its provisioner, parameters, and default reclaim policy for dynamically provisioned volumes.
StorageClass names such as “fast” or “backed up” are labels and configuration choices; Kubernetes does not define the performance, backup, durability, or cost those names imply.
Choose the StorageClass and binding behavior
Before creating a claim, check its storageClassName, the class provisioner and parameters, and whether it should use the cluster’s default class. A PVC that omits the class can use a default StorageClass if one is configured. During a migration, multiple classes may be marked default; Kubernetes uses the most recently created default for a PVC that does not specify a class. The Kubernetes documentation recommends keeping one default where possible.
#1 Best Overall
Binding can also be delayed. With WaitForFirstConsumer, provisioning and binding wait until a Pod using the PVC is created. This can help Kubernetes account for scheduling and storage topology constraints; it also means a claim may remain unbound until a consuming Pod exists.
Decide what happens when a PVC is deleted
The key setting is persistentVolumeReclaimPolicy. For dynamically provisioned PVs, the StorageClass reclaim policy is inherited; if it is omitted, the default is Delete. The two principal policies have different consequences:
| Policy | After the claim is released | Operational implication |
|---|---|---|
Delete |
Kubernetes removes the PV and, if the volume plugin supports deletion, the backing volume. | Appropriate when automatic cleanup is intended. Do not assume the policy guarantees a particular provider’s data-erasure behavior. |
Retain |
The PV remains, typically in Released state, rather than being automatically deleted. |
An administrator must decide how to recover, preserve, or dispose of the data before the volume is reused. |
The policy belongs to the PV, and can be changed. To set a PV to retain data before deleting its claim, use the PV name in this command:
kubectl patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'Verify the result with kubectl get pv <pv-name> -o yaml and confirm spec.persistentVolumeReclaimPolicy is Retain before deleting the PVC. The official Kubernetes task guide documents changing the reclaim policy: Change the Reclaim Policy of a PersistentVolume.
Rank #3
Recover or reuse a retained volume deliberately
Retain prevents automatic reclamation; it does not create a backup, guarantee application consistency, or make the storage safe to attach to another workload. After a PVC is deleted, a retained PV may be Released and still refer to its former claim. Treat recovery as a deliberate storage operation:
- Identify the PV and verify which backend volume it represents, who owns the data, and whether the application was stopped or quiesced appropriately.
- Follow the storage provider and CSI driver’s procedure for preserving, inspecting, or restoring that data. Confirm any snapshot, backup, and consistency requirements with the provider.
- Only when ready to reuse the PV, follow Kubernetes’ documented manual reclamation procedure. It includes clearing the old claim reference and binding a replacement claim to the retained PV; do not remove claim metadata or attach the volume blindly.
- Verify the replacement PVC is bound to the intended PV and that the workload can safely read or write the data.
Retained data may require manual cleanup or backend-specific handling. Check the Kubernetes PV lifecycle guidance and the documentation for the deployed storage system before reusing or disposing of it.
Expand a PVC when the class and driver support it
Kubernetes PVC expansion is stable since v1.24 for supported volume types, but a cluster must use a StorageClass with allowVolumeExpansion: true, and the provisioner or volume type must support resizing. Expansion is for growth, not shrinking: Kubernetes does not support reducing a PVC below its current capacity. The official Persistent Volumes documentation also notes CSI support, including some migrated volume types.
- Check the claim’s StorageClass and confirm
allowVolumeExpansion: true. - Confirm that the deployed storage driver supports expansion and check whether it requires workload steps or supports growth while the volume is in use.
- Edit the PVC’s requested storage to a larger value, for example:
kubectl edit pvc <claim-name>. Changespec.resources.requests.storage; do not lower it. - Check the PVC and PV status and the capacity visible to the workload. Follow the driver-specific procedure if filesystem resizing or a workload restart is required.
If an expansion request fails, the Kubernetes documentation says it can be retried with a request smaller than the failed target but still greater than the current capacity. This is not permission to request a shrink.
Manage snapshots separately from PV reclamation
A VolumeSnapshot request binds one-to-one with a VolumeSnapshotContent. Deleting a snapshot follows its own deletion policy, not the PV reclaim policy:
Deleteremoves the backing snapshot and the content object.Retainpreserves both the backing snapshot and content object.
Snapshots require compatible cluster components and support from the storage provider or CSI driver. Kubernetes’ snapshot policy does not establish that a snapshot is application-consistent, durable, or restorable within a particular time; verify those properties and the restore procedure with the provider. See the official Volume Snapshots documentation.
Quick Recap
Use a lifecycle checklist for each workload
- Choose and explicitly name the intended StorageClass where relying on the cluster default would be ambiguous.
- Know whether provisioning and binding happen immediately or wait for a Pod because of
WaitForFirstConsumer. - Set or verify the reclaim policy before deleting a claim that holds valuable data.
- Document who performs manual recovery and what backend procedure is required for retained PVs.
- Confirm expansion and snapshot capabilities against the installed driver, Kubernetes version, and provider documentation.
- Test backup and restore expectations separately; a reclaim policy or snapshot object alone is not proof of recoverability.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
