Persistent Volumes and Persistent Volume Claims

By default, anything a container writes to its own filesystem is lost the moment that container (and its Pod) is replaced — a database storing its data files this way would lose everything on the very first restart or rescheduling, which happens routinely (a rolling update, a node failure, manual scaling). Stateful workloads (lesson 7) need storage that survives independently of any single Pod's lifecycle.

A PersistentVolume (PV) represents an actual piece of storage available to the cluster — a cloud disk, a network filesystem — created either manually by a cluster administrator or automatically via dynamic provisioning (covered next). A PV exists independently of any specific Pod; it's a resource the cluster manages, similar in spirit to how a node itself is a resource the scheduler allocates from.

A PersistentVolumeClaim (PVC) is how a Pod actually asks for storage — a request specifying how much space and what access mode it needs, without the Pod's author needing to know anything about the underlying physical storage:

Kubernetes binds a PVC to a matching PV (one whose size and access mode satisfy the request), and a Pod references the PVC — not the PV directly — in its volume configuration. This indirection is the whole point: the Pod spec stays portable across environments where the underlying storage implementation genuinely differs (a cloud disk in production, a local volume in a dev cluster), since it only ever talks to the PVC abstraction.

Manually pre-creating PVs for every possible future claim doesn't scale. A StorageClass lets a PVC trigger automatic creation of a matching PV on demand:

Instead of an administrator pre-provisioning storage speculatively, the underlying cloud provider's storage system creates a real disk the moment this PVC is created, matching whatever the named StorageClass defines (disk type, replication settings). This is what actually happens underneath lesson 7's StatefulSet example — each Pod's volumeClaimTemplates entry generates its own PVC automatically, which then dynamically provisions its own real disk.

A PV's reclaim policy decides its fate once the PVC using it is deleted: Delete destroys the underlying storage (data genuinely gone), Retain keeps the disk around for manual recovery or reuse. Dynamically provisioned volumes often default to Delete — worth confirming explicitly for anything holding data that would be expensive or impossible to regenerate, since the default behavior here can silently throw away exactly the data a StatefulSet was set up to protect.