How do PersistentVolumeClaims work with StorageClasses for dynamic provisioning?
Quick Answer
A PersistentVolumeClaim (PVC) requests storage by specifying size, access mode, and StorageClass. The StorageClass tells Kubernetes which provisioner to use (e.g., AWS EBS, GCP PD). When a PVC references a StorageClass, the provisioner automatically creates a PersistentVolume matching the request -- no manual PV creation needed.
Detailed Answer
Think of dynamic provisioning like ordering a custom-built storage unit. You fill out a form (PVC) saying 'I need 100GB of fast SSD storage.' The form gets sent to a specific furniture company (StorageClass/provisioner) that builds the storage unit to your exact specifications and delivers it (PV). Without dynamic provisioning, an administrator would need to pre-build storage units of various sizes and hope one matches what you need.
A PersistentVolumeClaim is a user's request for storage. It specifies what the user needs: how much capacity (100Gi), what access mode (ReadWriteOnce for single-node access, ReadWriteMany for multi-node), and which StorageClass to use. The StorageClass is a cluster-level resource that defines HOW volumes are provisioned: which cloud provisioner to call (ebs.csi.aws.com for AWS EBS, pd.csi.storage.gke.io for GCP), what parameters to pass (volume type, IOPS, encryption), and what reclaim policy to use when the PVC is deleted (Retain keeps the data, Delete destroys it).
The dynamic provisioning flow works as follows: (1) User creates a PVC referencing storageClassName: fast-ssd. (2) The PV controller sees the unbound PVC and finds the StorageClass named fast-ssd. (3) It calls the CSI provisioner specified in the StorageClass (e.g., ebs.csi.aws.com). (4) The CSI provisioner calls the AWS API to create an EBS volume with the specified type (gp3) and size (100Gi). (5) A PersistentVolume object is created in Kubernetes representing the actual EBS volume. (6) The PV is bound to the PVC. (7) When a pod references the PVC, the kubelet mounts the EBS volume into the pod's container.
In production, StorageClasses are critical for multi-tier storage strategies. A typical cluster has several StorageClasses: standard (gp3, general purpose, default), fast-ssd (io2, high IOPS for databases), archive (sc1, cold HDD for logs), and replicated (multi-AZ replication for critical data). Each tier has different cost, performance, and durability characteristics. Developers select the appropriate tier by specifying storageClassName in their PVC.
A common production issue is zone affinity: EBS volumes are AZ-specific, so a PV created in us-east-1a can only be mounted by pods on nodes in us-east-1a. If the node in that AZ goes down and the pod is rescheduled to us-east-1b, it cannot mount the volume. This is why StatefulSet PVCs with cross-AZ scheduling need careful topology configuration using volumeBindingMode: WaitForFirstConsumer in the StorageClass, which delays volume creation until the pod is scheduled, ensuring the volume is created in the same AZ as the pod.