How do Persistent Volumes and Persistent Volume Claims work in Kubernetes?
Learn how Persistent Volumes and Persistent Volume Claims work in Kubernetes, including binding, access modes, StorageClass provisioning, and reclaim policies.
Expected Interview Answer
A PersistentVolume (PV) is a piece of cluster storage provisioned by an administrator or dynamically by a StorageClass, while a PersistentVolumeClaim (PVC) is a user's request for storage of a certain size and access mode. Kubernetes binds a PVC to a matching PV, and pods mount the PVC to get durable storage that outlives the pod.
PVs decouple storage from pods: the PV describes the actual backend (EBS, NFS, Ceph, etc.), and the PVC is an abstract request so the app author does not need to know the backend details. With dynamic provisioning, a PVC referencing a StorageClass triggers automatic creation of a matching PV. Key attributes include capacity, access modes (ReadWriteOnce, ReadOnlyMany, ReadWriteMany, ReadWriteOncePod), and the reclaim policy (Retain or Delete) that decides what happens to the PV when the PVC is released.
- Decouples storage lifecycle from pod lifecycle
- Data survives pod restarts and rescheduling
- Dynamic provisioning via StorageClass removes manual PV creation
- Abstracts backend details away from app authors
- Access modes and reclaim policies give fine control over sharing and cleanup
AI Mentor Explanation
A PersistentVolume is a locker already installed in the pavilion, stocked with kit. A PersistentVolumeClaim is a player's request slip saying I need a locker of this size with this access. The ground staff match the slip to a suitable locker and hand over the key; even when the player is subbed off, the kit stays in the locker for whoever holds that claim.
Step-by-Step Explanation
Step 1
Provision storage
An admin creates a PV, or a StorageClass enables dynamic provisioning so PVs are created on demand.
Step 2
Request with a PVC
A user creates a PVC specifying storage size, access mode, and optionally a storageClassName.
Step 3
Binding
Kubernetes matches the PVC to a suitable PV (or dynamically provisions one) and binds them one-to-one.
Step 4
Mount in a pod
The pod references the PVC under volumes, and containers mount it via volumeMounts to read and write durable data.
Step 5
Release and reclaim
When the PVC is deleted, the PV's reclaim policy (Retain or Delete) decides whether data is preserved or the volume is removed.
What Interviewer Expects
- Clear PV (supply) versus PVC (demand) distinction
- Understanding of binding and one-to-one relationship
- Knowledge of access modes and their meaning
- Dynamic provisioning via StorageClass
- Reclaim policies (Retain vs Delete) and their consequences
Common Mistakes
- Confusing which object is the request (PVC) and which is the supply (PV)
- Thinking storage is tied to the pod lifecycle rather than the PVC
- Assuming ReadWriteOnce means many pods on many nodes can write
- Forgetting that a StorageClass enables dynamic provisioning
- Overlooking the reclaim policy and accidentally deleting data
Best Answer (HR Friendly)
“In Kubernetes, a Persistent Volume is actual storage the cluster provides, and a Persistent Volume Claim is an app's request for some of that storage. Kubernetes matches the request to available storage so the app's data is saved safely and stays around even if the app restarts.”
Code Example
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: data-claim
spec:
accessModes:
- ReadWriteOnce
storageClassName: standard
resources:
requests:
storage: 5Gi
---
apiVersion: v1
kind: Pod
metadata:
name: app
spec:
containers:
- name: app
image: busybox:1.36
command: ["sh", "-c", "echo hello > /data/out.txt && sleep 3600"]
volumeMounts:
- name: store
mountPath: /data
volumes:
- name: store
persistentVolumeClaim:
claimName: data-claimkubectl get pvc data-claim
kubectl get pv
kubectl describe pvc data-claimFollow-up Questions
- What is the difference between the Retain and Delete reclaim policies?
- How does dynamic provisioning with a StorageClass work?
- What does the ReadWriteOncePod access mode add over ReadWriteOnce?
- Can two pods share the same PVC, and under what conditions?
- What happens to a PVC that finds no matching PV?
MCQ Practice
1. Which object represents a user's request for storage?
A PVC is the request for storage; the PV is the actual provisioned storage that satisfies it.
2. What enables dynamic provisioning of PVs?
A StorageClass defines how to dynamically provision PVs when a PVC references it.
3. What does the Retain reclaim policy do when a PVC is deleted?
Retain preserves the PV and its data so an admin can recover or clean it up manually.
Flash Cards
PV vs PVC — PV is provisioned storage (supply); PVC is a user's request for storage (demand).
What binds a PVC to a PV? — Kubernetes matches size and access mode and binds them one-to-one, or dynamically provisions a PV.
Role of a StorageClass — Enables dynamic provisioning so a PV is created automatically for a PVC.
Reclaim policy options — Retain (keep data for manual handling) or Delete (remove the PV and its data).
Does storage die with the pod? — No — data lives with the PVC/PV and survives pod restarts and rescheduling.