Separating Concerns
Kubernetes separates the responsibility of managing storage infrastructure from consuming it. This separation is intentional — it mirrors how organizations actually work. Infrastructure teams manage disks; developers consume storage. Two key objects encode this separation:
-
PersistentVolume (PV): The actual piece of storage inventory. Think of this as a specific hard drive in a data center rack, or a specific AWS EBS volume. It has a defined size (e.g.,
100Gi), access characteristics, and a lifecycle independent of any Pod. PVs are typically managed by cluster administrators or created automatically by a StorageClass. -
PersistentVolumeClaim (PVC): A request for storage made by a developer or workload. Think of it as a claim check at a coat room — you don't care which specific coat hook holds your jacket, you just want your jacket back when you need it. A developer writes a PVC saying "I need 10Gi of fast storage with read-write access," and Kubernetes figures out how to fulfill that request.
The Binding Process
When you create a Pod, you don't attach it directly to a physical disk. Instead, your Pod references a PVC by name. Kubernetes acts as the matchmaker: it scans available PVs looking for one that satisfies the PVC's requirements (size, access modes, StorageClass). When it finds a match, it binds the PVC to that PV — a one-to-one relationship. The Pod then uses the PVC to access the underlying storage.
A PersistentVolume declares its capacity, access mode, reclaim policy, and the underlying storage backend it's backed by (an EBS volume ID, for instance). A PersistentVolumeClaim, created separately by a developer, requests a size and access mode without referencing any specific PV — Kubernetes does the matching. The Pod, in turn, mounts a volume that references the PVC by name, never the PV directly — one more layer of indirection that keeps the Pod spec portable across whatever storage backend actually ends up satisfying the claim.
Access Modes
Access modes define how a volume can be mounted across nodes. This is a critical constraint that determines which workloads can use a given volume:
| Mode | Abbreviation | Meaning |
|---|---|---|
ReadWriteOnce |
RWO | Mounted read-write by a single node |
ReadOnlyMany |
ROX | Mounted read-only by many nodes |
ReadWriteMany |
RWX | Mounted read-write by many nodes |
ReadWriteOncePod |
RWOP | Mounted read-write by a single Pod (Kubernetes 1.22+) |
Not all storage backends support all access modes. AWS EBS only supports ReadWriteOnce. NFS and some cloud file systems support ReadWriteMany. Choosing the wrong access mode for your storage backend is a common source of PVC binding failures.
Interviewers often ask: "What's the difference between a PV and a PVC?" The trap is giving a pure definition. A stronger answer explains the separation of concerns: PVs are infrastructure (admin territory), PVCs are consumption requests (developer territory). Then mention that this abstraction lets developers request storage without knowing whether it's backed by EBS, NFS, or a local disk — the same way you request a hotel room without knowing which specific room you'll get.