Why PersistentVolumes Exist
Pods are ephemeral: when a Pod is deleted or rescheduled, any data written to its container filesystem is lost. Kubernetes solves this with a two-object abstraction: a PersistentVolume (PV) represents a real piece of storage in the cluster (an EBS volume, an NFS export, a Ceph RBD image), while a PersistentVolumeClaim (PVC) is a request for storage made by a developer. This separation lets cluster administrators manage the messy details of storage backends while application authors just ask for '10Gi, ReadWriteOnce' without knowing or caring what disk technology backs it.
Cricket analogy: Think of a PV like the actual turf pitch at a stadium prepared by the ground staff, and a PVC like a team simply booking 'Pitch 3 for the afternoon match' without needing to know how it was rolled or watered.
Access Modes and Binding
Every PV declares one or more access modes: ReadWriteOnce (RWO, mountable read-write by a single node), ReadOnlyMany (ROX, read-only by many nodes), ReadWriteMany (RWX, read-write by many nodes), and ReadWriteOncePod (RWOP, restricting mount to a single Pod, added to prevent accidental multi-attach even within one node). When a PVC is created, the control plane's binding process searches for a PV that satisfies the requested size, access mode, and StorageClass, then binds the two in a 1:1 relationship recorded in both objects' specs; a bound PV cannot be claimed by another PVC until released.
Cricket analogy: RWO is like a single set for the day being exclusively assigned to one net-bowling batter, while RWX is like a shared practice net where multiple bowlers can bowl to different batters simultaneously.
Reclaim Policy and Lifecycle
When a PVC is deleted, the bound PV's reclaimPolicy determines what happens to the underlying storage: Retain keeps the PV and its data around in a Released state for manual cleanup, Delete removes both the PV object and the backing storage asset (common for dynamically provisioned cloud volumes), and the deprecated Recycle performed a basic scrub. Choosing Retain for production databases avoids accidental data loss, at the cost of requiring an operator to manually reclaim or delete the orphaned volume afterward.
Cricket analogy: Retain is like keeping a rain-affected pitch covered and unused after a match for the curator to inspect, while Delete is like immediately re-turfing the practice strip for the next game.
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-database-01
spec:
capacity:
storage: 20Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: manual-ssd
csi:
driver: ebs.csi.aws.com
volumeHandle: vol-0abcd1234ef567890
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: postgres-data-claim
namespace: production
spec:
accessModes:
- ReadWriteOnce
storageClassName: manual-ssd
resources:
requests:
storage: 20GiA PVC's storageClassName, accessModes, and requested size must all be satisfiable by an available PV or the claim stays Pending indefinitely. Always check kubectl describe pvc <name> for binding events before assuming a stuck Pod is a scheduling issue.
- PersistentVolumes represent real storage; PersistentVolumeClaims are requests for storage that get bound to a matching PV.
- Access modes (RWO, ROX, RWX, RWOP) constrain how many nodes/Pods can mount a volume simultaneously.
- Binding is 1:1 and based on matching size, access mode, and StorageClass.
- reclaimPolicy (Retain vs Delete) controls what happens to storage after the claim is deleted.
- Retain requires manual cleanup but protects against accidental data loss; Delete automatically removes backing storage.
- kubectl describe pvc is the primary tool for diagnosing stuck bindings.
Practice what you learned
1. What happens when a PVC with reclaimPolicy Delete is removed and its bound dynamically provisioned PV existed only for that claim?
2. Which access mode restricts a volume to being mounted read-write by only a single Pod, even within the same node?
3. What state does a PV enter after its bound PVC is deleted with reclaimPolicy set to Retain?
4. What is the primary reason a PVC stays in Pending state?
Was this page helpful?
You May Also Like
Storage Classes
Understand how StorageClass objects define provisioners, parameters, and policies that govern how storage is dynamically created in Kubernetes.
Dynamic Provisioning
See how Kubernetes automatically creates storage volumes on demand via CSI provisioners instead of requiring admins to pre-create PVs.
Stateful Application Patterns
Explore how StatefulSets, headless Services, and volumeClaimTemplates combine to run databases and other stateful workloads reliably on Kubernetes.
Volume Snapshots
Learn how the Kubernetes VolumeSnapshot API enables point-in-time backups and cloning of PersistentVolumes via the CSI snapshot controller.