Volumes & PV/PVC
Files a container writes share the container's lifetime. Restart the Pod and the place is empty; move it to another node and that becomes obvious. Data that has to survive belongs outside the Pod — and there the Pod doesn't pick a disk itself, it writes down how much and in what mode it needs as a PersistentVolumeClaim.
01Volumes & PV/PVC
Concept at a GlanceFiles written inside the container · gone on restart
Files a container leaves behind pile up in its writable layer. Nothing is wrong with that while the Pod keeps running.
Attach an emptyDir and containers in the same Pod see the same files. That volume's lifetime still ends with the Pod.
When the container dies and comes back, the writable layer starts fresh. The files it just received are not there.
Restart the whole Pod on another node and it is plainer still: that node never had those files in the first place.
So this is a place for caches and scratch files. Put uploads or a database here and a restart is the same as losing them.
A volume attached by claim · it stays as Pods come and go
A Pod doesn't pick a disk. It only writes down how much space and which access mode it needs, as a claim.
If a volume already matches, that one is used. If none does, the StorageClass reads the claim and provisions one on the spot.
The provisioned volume is bound to that claim — a one-to-one tie no other claim can cut into.
The bound volume appears as a path inside the container. The app simply writes to a directory.
The Pod can die and come back — the claim stays, so it attaches to the same volume and the files are still there.
Access mode is the constraint. ReadWriteOnce can be written from one node only, so Pods spread across nodes can't attach together.
Deleting the Pod doesn't delete the volume. That moment comes when the claim is deleted, and the reclaim policy decides whether the volume goes with it.
02 Understand It Simply
For EveryoneFiles written inside a pod live only as long as the pod. A volume requested through a PVC outlives it, so deleting and recreating the pod reattaches the same data.
A volume such as emptyDir lives as long as the Pod, and a container's writable layer is new again the moment the container restarts.
A PVC is a request written in capacity, access mode, and StorageClass; a matching PV is bound to it, or the StorageClass provisions one on the spot.
The bound volume is mounted at a path inside the container, so the app just writes to a directory.
Access mode is the real constraint: ReadWriteOnce can be written from a single node, so Pods spread across nodes can't attach together.
When each Pod needs a volume of its own, a StatefulSet is what keeps the pairs straight.
- –Placing data that must survive (databases
- –uploads)
- –telling cache apart from durable state
- –choosing access modes and StorageClasses
- –and tracing where data goes when a Pod restarts or moves
03 Frequently Asked Questions
FAQWhat is Volumes & PV/PVC?+
Files a container writes share the container's lifetime. Restart the Pod and the place is empty; move it to another node and that becomes obvious. Data that has to survive belongs outside the Pod — and there the Pod doesn't pick a disk itself, it writes down how much and in what mode it needs as a PersistentVolumeClaim.
Where is Volumes & PV/PVC used?+
Placing data that must survive (databases, uploads), telling cache apart from durable state, choosing access modes and StorageClasses, and tracing where data goes when a Pod restarts or moves.
What's a simple analogy for Volumes & PV/PVC?+
Files written inside a pod live only as long as the pod. A volume requested through a PVC outlives it, so deleting and recreating the pod reattaches the same data.