What is a Kubernetes Persistent Volume?
Learn how Kubernetes Persistent Volumes and Claims decouple storage from Pod lifecycle, plus access modes and reclaim policies.
Expected Interview Answer
A Persistent Volume (PV) is a cluster-level piece of storage provisioned either statically by an admin or dynamically via a StorageClass, and it exists independently of any Pod’s lifecycle so data survives Pod restarts, rescheduling, or deletion.
A PV is a cluster resource, not namespaced, representing actual backing storage such as an AWS EBS volume, an NFS share, or a cloud provider disk, with defined capacity, access modes (ReadWriteOnce, ReadOnlyMany, ReadWriteMany), and a reclaim policy. Applications never reference a PV directly; instead they create a PersistentVolumeClaim (PVC) — a namespaced request for storage with a desired size and access mode — and Kubernetes binds that PVC to a matching PV, a one-to-one binding that persists even if the requesting Pod is deleted and recreated. A Pod mounts storage by referencing its PVC in the volumes section, so the same underlying data is remounted whenever a new Pod claiming that PVC starts, which is exactly how a StatefulSet keeps each replica’s data stable across rescheduling. When a PVC is deleted, the reclaim policy on the bound PV decides what happens next: Retain keeps the underlying storage and data intact for manual recovery, Delete removes the underlying storage entirely, and the deprecated Recycle wiped and reused it.
- Decouples storage lifecycle from any single Pod's lifecycle
- Lets applications request storage abstractly via PVCs without knowing infrastructure details
- Supports dynamic provisioning so storage is created on demand
- Provides configurable reclaim policies to protect or clean up data on release
AI Mentor Explanation
A Persistent Volume is like a dedicated equipment locker at the stadium assigned to a specific player, existing independently of which specific match day it is. The player does not carry a personal storage room around — they file a locker request (the claim) with the ground staff, who match them to an available locker of the right size. Even if the player is rested for a match and a substitute comes in, the locker stays reserved and its contents untouched until the original player’s claim is released. Whether the ground staff keeps the gear after the player leaves the team, or clears the locker for someone else, depends entirely on the retention policy set for that locker.
Step-by-Step Explanation
Step 1
Provision the PV
An admin creates a PV statically, or a StorageClass provisions one dynamically when a claim is made.
Step 2
Create a PVC
An application requests storage via a namespaced PersistentVolumeClaim specifying size and access mode.
Step 3
Kubernetes binds PVC to PV
A matching, available PV is bound one-to-one to the PVC.
Step 4
Mount and reclaim
Pods mount the volume via the PVC; when the PVC is deleted, the PV's reclaim policy (Retain/Delete) decides the storage's fate.
What Interviewer Expects
- Understanding of PV as cluster-level storage decoupled from Pod lifecycle
- Knowledge of the PVC-to-PV binding model and how applications request storage
- Awareness of access modes (ReadWriteOnce, ReadOnlyMany, ReadWriteMany)
- Ability to explain reclaim policies and their data-retention implications
Common Mistakes
- Confusing a PV with a PVC (backing storage vs the request for it)
- Assuming Pod deletion also deletes the underlying persistent data
- Not knowing that access modes constrain how many nodes can mount a volume simultaneously
- Forgetting that the reclaim policy determines whether data survives PVC deletion
Best Answer (HR Friendly)
“A Persistent Volume is storage that exists independently of any single Pod, so if a Pod crashes or gets rescheduled, its data is not lost — the application just reconnects to the same storage through a claim. It is what lets stateful things like databases run reliably in Kubernetes, because the actual data lives outside the ephemeral container lifecycle.”
Code Example
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: db-data-claim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
---
apiVersion: v1
kind: Pod
metadata:
name: postgres
spec:
containers:
- name: postgres
image: postgres:16
volumeMounts:
- mountPath: /var/lib/postgresql/data
name: data
volumes:
- name: data
persistentVolumeClaim:
claimName: db-data-claimFollow-up Questions
- What is the difference between a PersistentVolume and a PersistentVolumeClaim?
- What are the three access modes and what do they mean?
- What is the difference between the Retain and Delete reclaim policies?
- How does dynamic provisioning via a StorageClass differ from static PV creation?
MCQ Practice
1. What is a PersistentVolumeClaim?
A PVC is an application's namespaced request for storage; Kubernetes binds it to a suitable, available PersistentVolume.
2. What happens to Pod data stored on a PV when the Pod is deleted and recreated?
A PV exists independently of any Pod; as long as the PVC persists, a new Pod mounting the same claim gets the same data back.
3. What does the Retain reclaim policy do when a bound PVC is deleted?
Retain preserves the PV and its data after the PVC is deleted, requiring manual cleanup or reclamation by an admin.
Flash Cards
What is a Persistent Volume? — Cluster-level storage that exists independently of any Pod's lifecycle.
What is a PersistentVolumeClaim? — A namespaced request for storage that binds one-to-one to a matching PV.
Name the three PV access modes. — ReadWriteOnce, ReadOnlyMany, ReadWriteMany.
Retain vs Delete reclaim policy? — Retain keeps data after PVC deletion for manual recovery; Delete removes the underlying storage entirely.