Use StorageClasses for Dynamic Provisioning

Why this matters

Nobody carves hundreds of PVs by hand. A StorageClass names a provisioner plus parameters; any claim naming the class triggers automatic volume creation sized to the request. The default class catches bare claims. The exam tests the chain end to end because dynamic provisioning is how every real cluster serves state.

Concepts

A StorageClass holds the provisioner (driver name), parameters (type, zone, filesystem, performance tier), reclaimPolicy (usually Delete for dynamic volumes), volumeBindingMode (Immediate versus WaitForFirstConsumer), and allowVolumeExpansion. Mark one class default with the beta annotation and unmarked claims bind to it instead of Pending forever.

WaitForFirstConsumer delays provisioning until a pod schedules: the volume lands in the right zone with the pod instead of stranding capacity elsewhere. Expansion needs both the class flag and a driver that supports it: edit the PVC to a larger size, watch FileSystemResizePending, and confirm the new size inside the pod (some filesystems need the pod restart the event names).

Worked example

Default class first, then a claim that provisions itself:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: kubernetes.io/no-provisioner   # lab placeholder shape
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata: { name: auto-claim, namespace: demo }
spec:
  accessModes: [ReadWriteOnce]
  resources: { requests: { storage: 2Gi } }

With a real driver, the claim provisions instead of Pending: kubectl get pvc shows Bound with an auto-created PV. Expansion drill: edit to 4Gi, watch the resize events, exec into the pod and confirm with df.

Exam notes

No default class plus no className means Pending on clusters without static volumes: the class is the fix, not bigger PVs. Immediate binding can strand zones: prefer WaitForFirstConsumer wherever topology matters. And expansion is one-directional: shrinking a claim is rejected, so size edits only grow.