Topic 17

PersistentVolumes and Claims

PersistenceProvisioning

Durable storage in Kubernetes is built on a deliberate split. A PersistentVolume (PV) is a piece of real storage in the cluster; a PersistentVolumeClaim (PVC) is a request for storage by a Pod. The Pod asks for what it needs; the cluster supplies it. Decoupling the request from the supply is what lets the same manifest run against any storage backend.

This indirection is the heart of Kubernetes storage. A developer writes a PVC saying "I need 20Gi, read-write"; how that gets satisfied — which disk, which backend — is the cluster's concern, not the application's.

PV vs PVC: The Split

From a claim to a real disk

Podreferences a PVC

→

PVCrequest: 20Gi, RWO

→

bind

→

PVthe actual storage

→

Backendcloud disk / NFS

A PVC is what a Pod references; it states size, access mode, and optionally a StorageClass. A PV is the actual storage — a cloud disk, an NFS export, a SAN volume. Kubernetes binds a PVC to a suitable PV (or provisions one dynamically), and from then on the PVC is the Pod's handle to that storage. The Pod never names a PV directly; it always goes through its claim.

A PVC and the Pod that uses it

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data
spec:
  accessModes: ["ReadWriteOnce"]
  storageClassName: fast-ssd
  resources:
    requests:
      storage: 20Gi
---
# In the Pod:
#   volumes:
#     - name: data
#       persistentVolumeClaim:
#         claimName: data

Access Modes

Access mode declares how the volume can be mounted, and it is a frequent source of wrong assumptions. ReadWriteOnce (RWO) mounts read-write by a single node — the common case for block storage like cloud disks. ReadOnlyMany (ROX) mounts read-only by many nodes. ReadWriteMany (RWX) mounts read-write by many nodes — only some backends (NFS, certain file systems) support it; typical block storage does not. ReadWriteOncePod restricts to a single Pod.

Mode	Mount	Backed by
RWO	Read-write, one node	Cloud block disks (the usual case)
ROX	Read-only, many nodes	Shared read-only datasets
RWX	Read-write, many nodes	NFS / shared file systems only
RWOP	Read-write, one Pod	Strict single-Pod block storage

Reclaim Policy and Binding

When a PVC is deleted, the reclaim policy on its PV decides what happens to the data. Delete (common for dynamically provisioned cloud disks) destroys the underlying storage — convenient, and a way to lose data by accident. Retain keeps the PV and its data for manual recovery. Binding can be static (an admin pre-creates PVs and Kubernetes matches a claim to one) or dynamic (the cluster creates a PV on demand via a StorageClass, the modern default).

Resizing and Lifecycle

Many backends support expanding a PVC by editing its requested size, if the StorageClass allows it — but you cannot shrink a volume. A PVC stuck in Pending almost always means no PV can satisfy it: no matching static PV, or no default StorageClass for dynamic provisioning. And because cloud block disks are zonal, a Pod using one can only schedule onto nodes in that disk's zone — a constraint that surprises people when a Pod will not start in a multi-zone cluster.

Static vs dynamic provisioning

Static — an admin pre-creates PVs; claims bind to existing ones. Predictable, but manual and easy to run dry.

Dynamic — a StorageClass provisions a PV on demand when a claim is made. The modern default (Topic 18).

Common Mistakes

Assuming ReadWriteMany works on cloud block storage — it does not; that needs a shared file system.
Leaving the reclaim policy at Delete on data you cannot afford to lose.
A PVC stuck Pending because there is no default StorageClass and no matching static PV.
Expecting to shrink a volume — expansion is supported, shrinking is not.
Ignoring zonal disk topology, so a Pod cannot schedule because its disk is in another zone.

Best Practices

Let Pods reference PVCs and keep storage details (backend, class) out of the application manifest.
Choose the access mode that matches the backend — RWO for block disks, RWX only where the backend supports it.
Use Retain for stateful data you must be able to recover; reserve Delete for truly disposable volumes.
Set a default StorageClass so PVCs provision automatically and don't hang in Pending.
Account for zonal storage topology when scheduling stateful Pods in multi-zone clusters.

RelatedStorageClasses — dynamic provisioning by tier (Topic 18)CSI — the drivers that implement real backends (Topic 19)Cloud block/file storage — EBS, Persistent Disk, Azure Disk/Files as backends

Knowledge Check

What is the relationship between a PVC and a PV?

A PVC is a request for storage; a PV is the actual storage Kubernetes binds the claim to
They are two interchangeable names for the very same storage object in the API
A PV is the request for storage and a PVC supplies the backing disk it then binds the request to
A PVC is only used to request inline emptyDir scratch volumes for a Pod

Why might ReadWriteMany fail on a cloud block-storage backend?

Block disks support single-node read-write (RWO); RWX needs a shared file system like NFS
RWX is only available to control-plane Pods scheduled onto the master nodes
Block storage does not support any access mode at all, not even single-node read-write mounting
RWX requires the Retain reclaim policy to be set on the PV first

A PVC is stuck in Pending. What is the most common cause?

No PV can satisfy it — no matching static PV and no default StorageClass for dynamic provisioning
The Pod has too little memory requested to be scheduled onto any node
The reclaim policy on the bound volume is set to Retain instead of Delete
The PVC was created in a different namespace from the Pod that references it and tries to mount it

You got correct