Why Pods Need Persistent Storage
Container filesystems are ephemeral: when a Pod is deleted or rescheduled, any data written to its local filesystem is lost. Kubernetes solves this with a storage abstraction layer built around PersistentVolumes (PVs) and PersistentVolumeClaims (PVCs), which let application data outlive individual Pod restarts and even node failures.
Cricket analogy: Like a player's personal scorebook being wiped clean every time they're rotated out of the squad, losing all their career stats, container filesystems are ephemeral — PVs and PVCs give data a permanent record that survives Pod restarts.
PersistentVolumes: Cluster Storage Resources
A PersistentVolume is a cluster-scoped storage resource, provisioned either statically by an administrator or dynamically by a StorageClass. It represents an actual piece of storage — an NFS share, a cloud disk, a local SSD — independent of any Pod's lifecycle.
Cricket analogy: Like a stadium's actual physical pitch existing independently of which two teams are currently playing on it, a PersistentVolume is real cluster-scoped storage — an NFS share, cloud disk, or SSD — that outlives any single Pod.
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-app-data
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: manual
hostPath:
path: /mnt/data/appPersistentVolumeClaims: Requesting Storage
A PersistentVolumeClaim is a namespaced request for storage made by a user or application. Kubernetes binds a PVC to a suitable PV based on capacity, access modes, and storage class. Pods then reference the PVC by name, never the underlying PV directly — once bound, a PVC is mounted into a container using a volumes entry that references claimName (e.g. persistentVolumeClaim: { claimName: app-data-claim }), along with a matching volumeMounts path inside the container spec.
Cricket analogy: Like a player submitting a request for a specific type of training slot and the board matching them to an available facility by capacity and location, a PVC is a namespaced request Kubernetes binds to a suitable PV.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: app-data-claim
namespace: production
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
storageClassName: manualDynamic Provisioning with StorageClasses
In most production clusters, administrators never hand-create PVs. Instead, a StorageClass defines a provisioner (such as a cloud CSI driver) that dynamically creates a PV on demand whenever a matching PVC is created, eliminating manual storage management.
Cricket analogy: Like a groundskeeper no longer hand-preparing each pitch because an automated system provisions a fresh one on demand whenever a match is scheduled, a StorageClass dynamically creates a PV whenever a matching PVC appears.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast-ssd
provisioner: ebs.csi.aws.com
parameters:
type: gp3
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumervolumeBindingMode: WaitForFirstConsumer delays volume binding until a Pod that uses the PVC is scheduled, allowing the scheduler to pick a node in the correct availability zone for the storage.
The reclaimPolicy determines what happens to the underlying storage after a PVC is deleted. Retain preserves data for manual recovery, while Delete permanently removes the volume — choose carefully for production data to avoid accidental data loss.
- PVs are cluster-scoped; PVCs are namespaced and bind to a matching PV.
- Access modes include ReadWriteOnce, ReadOnlyMany, and ReadWriteMany.
- StorageClasses enable dynamic provisioning via a CSI provisioner.
- reclaimPolicy (Retain/Delete/Recycle) controls PV fate after PVC deletion.
- Pods reference storage only through a PVC's claimName, never a PV directly.
- volumeBindingMode: WaitForFirstConsumer avoids scheduling/zone mismatches.
Practice what you learned
1. What is the primary purpose of a PersistentVolumeClaim?
2. Which field on a StorageClass delays volume binding until a Pod is scheduled?
3. What happens to a PersistentVolume with reclaimPolicy: Delete after its bound PVC is deleted?
4. Which access mode allows a volume to be mounted read-write by multiple nodes simultaneously?
5. In a Pod spec, how is a PVC attached to a container?
Was this page helpful?
You May Also Like
Volumes and Persistent Storage
Learn how Docker volumes and bind mounts persist and share data beyond a container's lifecycle, and when to use each option.
StatefulSets and DaemonSets
Explore two specialized workload controllers: StatefulSets for stable, ordered identity and storage, and DaemonSets for one-Pod-per-node deployments.
Namespaces and Resource Quotas
Understand how Kubernetes Namespaces provide multi-tenant isolation and how ResourceQuotas and LimitRanges enforce fair compute usage across teams.
Kubernetes Architecture
A tour of Kubernetes cluster architecture, covering control plane components and worker node components and how they interact.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics