Developers request storage with a PVC; the platform decides what real disk backs it.

You almost never create PersistentVolumes by hand. A StorageClass describes how to create one on demand when a claim appears.

PVC = request

Namespaced. Says how much, which access mode, which class. This is all the app team writes.

PV = the real volume

Cluster-scoped object that represents an actual disk. Created by the CSI provisioner.

`reclaimPolicy`

Delete destroys the disk with the PVC. Retain keeps data and needs manual cleanup. Use Retain for critical data.

A claim asks, a class provisions, a driver delivers

A Volume attaches storage to a Pod, but for durable data you use the PVC/PV pattern, which separates concerns. A PersistentVolumeClaim is the application's request: size, access mode and storage class. A PersistentVolume represents an actual piece of storage. The control plane binds a claim to a suitable volume, and the Pod simply mounts the claim by name.

In modern clusters volumes are provisioned dynamically. A StorageClass names a provisioner (a CSI driver) and parameters such as disk type. When a PVC referencing the class appears, the driver creates a real disk through the cloud or storage API, creates the PV object and binds it. Reveal the five steps with the right arrow.

The reclaimPolicy on the class or volume decides what happens when the claim is deleted. With Delete, the underlying disk is destroyed immediately and the data is gone; with Retain, the disk and data are kept and an administrator must clean up or reuse them. For genuinely critical data Retain is the safer default.

Operational note: StorageClass names and defaults differ per platform. GKE ships classes backed by Persistent Disk and Hyperdisk, EKS by EBS (and EFS through a separate driver), and on-prem clusters need you to install a provisioner such as Longhorn, Rook-Ceph or an NFS provisioner before PVCs can bind at all.