6/760 min
Storage & Ingress
PersistentVolumes — Storage Lifecycle
Decouple storage from pods: PersistentVolumes, PersistentVolumeClaims, and StorageClasses for dynamic provisioning.
intermediate60 minRead → Lab → Quiz → Practice
🧠 Brain Warm-Up
🧠 Brain Warm-Up: A pod crashes and is rescheduled to a different node. An emptyDir volume is gone. A hostPath volume might have data on the wrong node. What storage abstraction would let the pod resume with the same data regardless of which node it lands on?
The Storage Abstraction Stack
Pod
└── Volume (PVC reference)
└── PersistentVolumeClaim (namespace-scoped request)
└── PersistentVolume (cluster-scoped actual storage)
└── Storage backend (NFS, cloud disk, hostPath...)PV: Cluster-scoped storage resource. Provisioned by an admin or dynamically.
PVC: Namespace-scoped claim by a workload. Specifies size, access mode, StorageClass.
StorageClass: Defines a provisioner. Enables dynamic PV creation on demand.
Binding
PVC binding is automatic when a PV matches:
- PVC requested size ≤ PV capacity
- Access modes overlap
- StorageClass matches (or both empty)
Once bound, the PVC and PV are exclusive to each other.
Access Modes
| Mode | Short | Meaning |
|---|---|---|
| ReadWriteOnce | RWO | One node, read+write |
| ReadOnlyMany | ROX | Many nodes, read-only |
| ReadWriteMany | RWX | Many nodes, read+write |
Most cloud block devices only support RWO. NFS supports RWX.
Reclaim Policies
| Policy | After PVC deleted |
|---|---|
| Retain | PV stays, data kept, must manually reclaim |
| Delete | PV and backing storage deleted |
| Recycle | Deprecated — rm -rf then reuse |
Dynamic Provisioning with StorageClass
Instead of pre-creating PVs, a StorageClass provisions them on demand:
PVC created → StorageClass provisioner creates PV → PVC binds to PV
minikube has a default StorageClass (standard) backed by hostPath.