How does Kubernetes store data persistently using Volumes, PersistentVolumes, and PersistentVolumeClaims?
Quick Answer
Volumes attach storage to Pods but are tied to the Pod lifecycle. PersistentVolumes (PVs) are cluster-level storage resources that exist independently of Pods. PersistentVolumeClaims (PVCs) are requests for storage that bind to PVs — this three-layer abstraction separates storage provisioning (admin) from storage consumption (developer).
Detailed Answer
Think of it like renting storage space. A basic Volume is like a temporary locker at the gym — it exists while you're working out (Pod is running) and gets emptied when you leave (Pod is deleted). An emptyDir volume is exactly this: scratch space that dies with the Pod. But what if you need a permanent storage unit?
That's where PersistentVolumes and PersistentVolumeClaims come in. A PersistentVolume (PV) is like a storage unit in a warehouse that exists independently — the warehouse manager (cluster admin) provisions it, and it's available whether or not anyone is currently using it. It might be backed by an AWS EBS disk, a Google Persistent Disk, or an NFS share. The PV has a specific size, access mode (ReadWriteOnce, ReadOnlyMany, ReadWriteMany), and reclaim policy (what happens when nobody needs it anymore).
A PersistentVolumeClaim (PVC) is a tenant's request: 'I need 10Gi of fast SSD storage with read-write access.' Kubernetes matches this claim against available PVs and binds them together. The developer creating the PVC doesn't need to know whether the storage is EBS, GCE PD, or NFS — they just ask for what they need. This separation of concerns is the entire point: admins manage physical storage, developers request logical storage.
In modern clusters, you rarely create PVs manually. Instead, you use StorageClasses, which enable dynamic provisioning. A StorageClass defines a 'recipe' for creating storage: the provisioner (like ebs.csi.aws.com), the disk type (gp3, io2), and the reclaim policy. When a PVC references a StorageClass, Kubernetes automatically creates a matching PV on-demand. This is how EKS, GKE, and AKS work — you create a PVC, and within seconds a cloud disk is provisioned and attached to your node.
The most critical gotcha with persistent storage: by default, a PV's reclaimPolicy is 'Delete', meaning when you delete the PVC, the underlying cloud disk is ALSO deleted — along with all your data. For any database or stateful application, you must set reclaimPolicy to 'Retain'. Additionally, ReadWriteOnce volumes can only be attached to a single node at a time. If your Pod gets rescheduled to a different node, it must wait for the volume to detach from the old node and attach to the new one — this can take 1-3 minutes on AWS EBS, during which your application is down. This is why StatefulSets (not Deployments) are used for databases.