Kubernetes Storage
Volumes, PersistentVolume/PVC and StorageClass, static vs dynamic provisioning, access modes and reclaim policies, CSI, and StatefulSet storage.
8 questions
JuniorTheoryVery commonWhat is a PersistentVolume versus a PersistentVolumeClaim, and how do they bind?
What is a PersistentVolume versus a PersistentVolumeClaim, and how do they bind?
A PersistentVolume (PV) is a cluster-scoped storage resource — the real disk. A PersistentVolumeClaim (PVC) is a namespaced request for a size and access mode. A pod references the PVC; Kubernetes binds it to a matching PV and mounts it.
Common mistakes
- ✗Thinking a PVC is the disk and a PV is the request — it is the reverse
- ✗Believing a PV is namespaced like a PVC rather than cluster-scoped
- ✗Mounting a PV directly in a pod instead of referencing a PVC
Follow-up questions
- →What happens to a PVC that finds no matching PV to bind to?
- →Can two pods in different namespaces share one PVC?
JuniorTheoryCommonWhat is a StorageClass, and what is dynamic versus static provisioning?
What is a StorageClass, and what is dynamic versus static provisioning?
A StorageClass is a template naming a provisioner plus its parameters (disk type, zone). Static provisioning means an admin pre-creates PVs by hand. Dynamic provisioning means a PVC referencing a StorageClass makes the provisioner create a PV on demand.
Common mistakes
- ✗Thinking a StorageClass stores data itself rather than naming a provisioner
- ✗Believing dynamic provisioning still needs pre-created PVs
- ✗Confusing static (admin-made PVs) with dynamic (provisioner-made PVs)
Follow-up questions
- →What happens to a PVC when the cluster has no default StorageClass?
- →Where do a StorageClass parameters like disk type and zone come from?
JuniorTheoryCommonWhat volume types exist (emptyDir, hostPath, configMap, PVC) and what are their lifetimes?
What volume types exist (emptyDir, hostPath, configMap, PVC) and what are their lifetimes?
emptyDir is scratch space tied to the pod — erased when the pod is deleted. hostPath mounts a node directory (node-local, a portability footgun). configMap and secret project config as read-only files. A PVC-backed volume is persistent and outlives the pod. So lifetime depends on the type.
Common mistakes
- ✗Assuming emptyDir persists across a pod delete like a PVC does
- ✗Using hostPath in portable workloads, coupling the pod to one node
- ✗Thinking configMap is writable storage rather than read-only projection
Follow-up questions
- →Why is hostPath discouraged in multi-node clusters?
- →How do you share files between containers in the same pod?
MiddleTheoryCommonWhat do access modes RWO, ROX and RWX mean, and what limits RWX in practice?
What do access modes RWO, ROX and RWX mean, and what limits RWX in practice?
RWO (ReadWriteOnce) — one node mounts read-write; several pods on that node still share it. ROX (ReadOnlyMany) — many nodes read-only. RWX (ReadWriteMany) — many nodes read-write. Modes are enforced per node, not per pod. RWX needs a networked filesystem like NFS; most block volumes offer only RWO.
Common mistakes
- ✗Reading RWO as one pod rather than one node mounting read-write
- ✗Assuming any volume supports RWX without a networked filesystem
- ✗Thinking modes are enforced per pod instead of per node
Follow-up questions
- →Why can two pods on the same node share an RWO volume but not on different nodes?
- →Which storage backends actually provide RWX?
MiddleDebuggingCommonA pod is stuck because its PVC stays Pending — diagnose and fix it
A pod is stuck because its PVC stays Pending — diagnose and fix it
A Pending PVC never bound: provisioning could not satisfy the claim. The describe event says StorageClass fast-ssd is not found, so no provisioner ran. Other causes: no default StorageClass, or no PV matching the claim. Fix: reference an existing StorageClass, or set a default.
Open full question →Common mistakes
- ✗Blaming the pod or image when the event points at storage provisioning
- ✗Ignoring the describe events, which name the exact provisioning failure
- ✗Assuming a Pending PVC will bind on its own without a valid StorageClass
Follow-up questions
- →How would the diagnosis change if there were no ProvisioningFailed event at all?
- →How do you mark a StorageClass as the cluster default?
MiddleTheoryCommonHow does a StatefulSet give each replica its own stable PVC via volumeClaimTemplates?
How does a StatefulSet give each replica its own stable PVC via volumeClaimTemplates?
A volumeClaimTemplates block makes the StatefulSet create one PVC per replica, named by ordinal (data-web-0, data-web-1). Each pod keeps that same sticky PVC across reschedules and restarts, so a replica's identity and its data stay bound together — unlike a Deployment, whose pods share or lose one volume.
Common mistakes
- ✗Thinking StatefulSet replicas share one PVC like a Deployment
- ✗Assuming the per-replica PVC is recreated empty on every reschedule
- ✗Believing ordinal PVC names are cosmetic rather than sticky identity
Follow-up questions
- →What happens to the per-replica PVCs when you scale a StatefulSet down?
- →Why does a StatefulSet need a headless Service alongside its storage?
MiddleTheoryOccasionalWhat is CSI, and why did Kubernetes move storage drivers out of tree?
What is CSI, and why did Kubernetes move storage drivers out of tree?
CSI (Container Storage Interface) is a standard gRPC API letting vendors ship storage drivers as pods, released independently of Kubernetes. In-tree drivers were compiled into Kubernetes, so each fix waited on a core release. CSI decouples them and unlocks snapshots and expansion.
Common mistakes
- ✗Thinking CSI drivers are still compiled into the Kubernetes binary
- ✗Assuming CSI is cloud-only rather than an open vendor-neutral API
- ✗Believing in-tree drivers had an independent release cadence
Follow-up questions
- →How does a CSI driver register itself with the kubelet on each node?
- →What new capabilities did CSI enable that in-tree drivers lacked?
MiddleTheoryOccasionalWhat do reclaim policies Retain, Delete and Recycle do when a PVC is deleted?
What do reclaim policies Retain, Delete and Recycle do when a PVC is deleted?
The reclaim policy decides a PV's fate once its bound PVC is deleted. Delete removes the PV and its backing disk — a real data-loss risk. Retain keeps the PV and data, marked Released, for manual recovery. Recycle (deprecated) scrubbed and reused it. Dynamic PVs default to Delete.
Common mistakes
- ✗Assuming the default is Retain when dynamic PVs default to Delete
- ✗Thinking Delete only unmounts rather than destroying the disk
- ✗Believing Recycle is current — it is deprecated and removed
Follow-up questions
- →How do you switch a bound PV from Delete to Retain safely?
- →After Retain releases a PV, what steps rebind its data to a new PVC?
