Persistent Volume and Persistent Volume Claim

WHY IT EXISTS Containers are ephemeral, so anything written to a pod's local filesystem vanishes when the pod is rescheduled or dies. Stateful workloads like databases need storage that outlives the pod. Kubernetes also wanted to separate the concerns of cluster operators, who manage real storage, from application developers, who just need a volume. PersistentVolumes and PersistentVolumeClaims provide that durable, decoupled storage abstraction.

THE MENTAL MODEL Think of it like a coat check. The PersistentVolume is an actual coat hook with a coat on it, a real storage resource in the cluster. The PersistentVolumeClaim is your ticket, a request that says I need a coat of this size and access type. Kubernetes matches your ticket to an available hook and binds them. The developer holds the claim and never touches the underlying disk directly.

HOW IT WORKS A PV represents real storage with a capacity, access modes such as ReadWriteOnce or ReadWriteMany, and a reclaim policy. PVs are provisioned two ways: statically, where an admin pre-creates them, or dynamically, where a StorageClass auto-provisions a backing disk when a claim appears. A PVC specifies the requested size, access mode, and optional StorageClass. The control plane binds a claim to a suitable PV one-to-one, and the pod references the PVC in its volume spec to mount it. When the claim is deleted, the reclaim policy decides whether the PV is retained, deleted, or recycled.

WHEN IT MATTERS It matters for any stateful workload: databases, message queues, file uploads, or caches that must survive pod restarts and rescheduling. It also matters operationally, letting platform teams expose tiers of storage via StorageClasses while developers request capacity portably across clouds.

ONE CONCRETE EXAMPLE A Postgres pod needs durable storage. The developer writes a PVC requesting 20Gi with access mode ReadWriteOnce and a StorageClass of fast-ssd. The cloud provider's CSI driver dynamically provisions a 20Gi SSD, creates a matching PV, and binds it to the claim. The pod mounts the PVC at the data directory. If the pod is rescheduled to another node, the same volume reattaches, so the database data persists across the restart.