Volumes & Storage
Persist data beyond a Pod's life with PersistentVolumes, claims, and storage classes.
A container’s filesystem is ephemeral — it’s lost when the Pod restarts. To persist data, Kubernetes uses volumes. The durable abstraction has three parts:
- PersistentVolume (PV) — a piece of real storage (a cloud disk, NFS share)
- PersistentVolumeClaim (PVC) — a Pod’s request for storage of a size/mode
- StorageClass — defines how to dynamically provision PVs on demand
A Pod mounts a PVC; the StorageClass provisions a matching PV automatically. Access
modes matter: ReadWriteOnce (one node), ReadOnlyMany, ReadWriteMany.
Stateful apps pair this with StatefulSets for stable per-Pod storage.
apiVersion: v1
kind: PersistentVolumeClaim
metadata: { name: data }
spec:
accessModes: ["ReadWriteOnce"]
storageClassName: standard
resources: { requests: { storage: 10Gi } }
---
# In a Pod spec:
volumes:
- name: data
persistentVolumeClaim: { claimName: data }
containers:
- name: db
volumeMounts: [{ name: data, mountPath: /var/lib/data }]- Explain the roles of PV, PVC, and StorageClass.
- Write a PVC requesting 10Gi with ReadWriteOnce.
- Mount that PVC into a container at a path.
- Why do databases use StatefulSets with persistent volumes?
Cheat Sheet▾
| Object | Role |
|---|---|
| PersistentVolume | Actual storage resource |
| PersistentVolumeClaim | A Pod’s storage request |
| StorageClass | Dynamic provisioning |
| ReadWriteOnce | One node mounts read/write |
| ReadWriteMany | Many nodes read/write |
| emptyDir | Ephemeral scratch (Pod life) |
Common Interview Questions▾
What's the relationship between a PV, PVC, and StorageClass?
A PVC is a Pod’s request for storage; a StorageClass dynamically provisions a PersistentVolume to satisfy it. The Pod mounts the PVC, decoupled from the underlying storage.
Why are PVCs used instead of mounting storage directly?
They decouple the Pod from the storage implementation — the Pod requests size and access mode, and the cluster provisions matching storage, keeping manifests portable.