Persistent Volume

Without PersistentVolumes, data written to a container’s own filesystem is lost when the pod is deleted or rescheduled. PVs decouple storage from the pod lifecycle: a pod writes to its PVC, the pod is deleted and replaced, and the new pod mounts the same PVC with the data intact.

How it works

A PersistentVolume is cluster storage with a lifecycle independent of any pod. A PersistentVolumeClaim is a request for storage that states a size and access modes. A control loop binds each claim to a matching volume, and the binding is one to one. If no volume matches, the claim stays unbound until one appears. With dynamic provisioning, the claim names a StorageClass and a provisioner creates the volume on demand.

Access modes describe how a volume can be mounted: ReadWriteOnce (read-write by a single node), ReadOnlyMany, ReadWriteMany and ReadWriteOncePod (a single pod). Support depends on the storage backend. On AWS, PVs are typically backed by EBS volumes through the EBS CSI driver for block storage, or EFS for shared file storage. On Azure, Azure Disk (block) or Azure Files (shared) serve the same purpose.

A practical example

A StorageClass that delays provisioning until a pod is scheduled, and a claim that uses it. The provisioner shown is a placeholder, so substitute the CSI driver for your platform:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: example.com/fast-csi
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data
spec:
  storageClassName: fast
  accessModes: [ReadWriteOnce]
  resources:
    requests:
      storage: 10Gi

A pod then lists the claim under volumes with persistentVolumeClaim.claimName: data and mounts it with volumeMounts.

Common mistakes

• Assuming a PV is a backup. It survives pod restarts, not accidental deletion or corruption, so take snapshots or backups separately.
• Forgetting the reclaim policy. Dynamically provisioned volumes default to Delete, so deleting the claim deletes the underlying storage. Retain keeps the volume but needs manual clean-up.
• Misreading ReadWriteOnce as one pod. It means one node, so several pods on the same node can share it.
• Using Immediate binding with zonal block storage, which can create a volume in a zone where the pod cannot be scheduled. WaitForFirstConsumer avoids this.
• Expecting to shrink a volume. Expansion requires allowVolumeExpansion on the class, and shrinking is not supported.

When to use it and when not to

Use PVs for databases, message queues and any workload that must keep state across restarts, usually through a StatefulSet. Do not use them for caches, scratch space or data that is cheap to rebuild, where an emptyDir volume is simpler, or for state that belongs in a managed database service. For cluster design advice see our Kubernetes consulting service.

See also

• StatefulSet
• EKS
• AKS
• Kubernetes