Persistent Volume and Persistent Volume Claim
Kubernetes separates storage provisioning from consumption. A PersistentVolume is a cluster storage resource an admin or driver provisions; a PersistentVolumeClaim is a pod's request for storage.
Why it exists
Containers are ephemeral, so anything written to a pod's local filesystem vanishes when the pod is rescheduled or dies. Stateful workloads like databases need storage that outlives the pod. Kubernetes also wanted to separate the concerns of cluster operators, who manage real storage, from application developers, who just need a volume. PersistentVolumes and PersistentVolumeClaims provide that durable, decoupled storage abstraction.
The mental model
Think of it like a coat check. The PersistentVolume is an actual coat hook with a coat on it, a real storage resource in the cluster. The PersistentVolumeClaim is your ticket, a request that says I need a coat of this size and access type. Kubernetes matches your ticket to an available hook and binds them. The developer holds the claim and never touches the underlying disk directly.
How it works
A PV represents real storage with a capacity, access modes such as ReadWriteOnce or ReadWriteMany, and a reclaim policy. PVs are provisioned two ways: statically, where an admin pre-creates them, or dynamically, where a StorageClass auto-provisions a backing disk when a claim appears. A PVC specifies the requested size, access mode, and optional StorageClass. The control plane binds a claim to a suitable PV one-to-one, and the pod references the PVC in its volume spec to mount it. When the claim is deleted, the reclaim policy decides whether the PV is retained, deleted, or recycled.
When it matters
It matters for any stateful workload: databases, message queues, file uploads, or caches that must survive pod restarts and rescheduling. It also matters operationally, letting platform teams expose tiers of storage via StorageClasses while developers request capacity portably across clouds.
A concrete example
A Postgres pod needs durable storage. The developer writes a PVC requesting 20Gi with access mode ReadWriteOnce and a StorageClass of fast-ssd. The cloud provider's CSI driver dynamically provisions a 20Gi SSD, creates a matching PV, and binds it to the claim. The pod mounts the PVC at the data directory. If the pod is rescheduled to another node, the same volume reattaches, so the database data persists across the restart.
Interview question
In Kubernetes, what is the relationship between a PersistentVolume and a PersistentVolumeClaim?
- a.They are two names for the same object
- b.A PVC is only used for ephemeral scratch storage
- c.The PVC provisions physical disks while the PV consumes them
- d.The PV is the actual storage resource; the PVC is a pod's request that gets bound to a matching PVCorrect
Why? this is the answer
A PV is the provisioned storage resource and a PVC is the consumer's request that Kubernetes binds to a suitable PV. They are distinct objects, the claim does not provision hardware, and PVCs exist precisely to provide durable, not ephemeral, storage.
Just read this? Test yourself on what you have been reading.
Read the original → kubernetes.io
- #kubernetes
- #persistent-volume
- #storage
- #stateful-workloads
- #cloud-native
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles