Topic 18

StorageClasses

ProvisioningPolicy

A StorageClass defines a kind of storage the cluster can provision on demand — a tier like fast SSD, cheap HDD, or regional replicated disk. When a PVC names a class, the cluster creates a matching PV automatically. This is dynamic provisioning, and it is how storage works on any modern cluster.

Without StorageClasses, an admin would pre-create every PV by hand. With them, developers request storage by tier and the right disk appears. The class is where the storage policy lives.

What a StorageClass Defines

A StorageClass names a provisioner (the CSI driver that creates the storage) and a set of parameters passed to it — disk type, IOPS, replication, encryption. A cluster usually has several: a default general-purpose class, a high-performance class, perhaps a cheap archival one. A PVC selects a class by name, or falls back to the cluster's default.

A StorageClass for fast SSD

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  iops: "5000"
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
reclaimPolicy: Delete

The Default Class

One StorageClass can be marked default. A PVC that omits storageClassName gets the default; if there is no default and the PVC names none, it stays Pending forever. This is one of the most common "my PVC won't bind" causes on a fresh or misconfigured cluster — there is simply no class to provision from.

Binding Mode: The Topology Trap

volumeBindingMode decides when the volume is provisioned. Immediate provisions as soon as the PVC is created — but in a multi-zone cluster that can place the disk in one zone and then the Pod cannot schedule there, a classic deadlock. WaitForFirstConsumer delays provisioning until a Pod using the PVC is scheduled, so the disk is created in the right zone for that Pod. On multi-zone clusters, WaitForFirstConsumer is almost always the correct choice.

Expansion and Reclaim

The class also sets allowVolumeExpansion (whether PVCs of this class can grow) and the reclaimPolicy inherited by the PVs it provisions (Delete or Retain). Choosing the right tier matters operationally: putting a write-heavy database on a slow, cheap class will throttle it, and putting throwaway scratch on an expensive replicated class wastes money. The class is where you encode those trade-offs once, for everyone.

Immediate vs WaitForFirstConsumer

Immediate — provisions the disk as soon as the PVC is created. Risks placing it in a zone the Pod can't schedule into.

WaitForFirstConsumer — waits until a Pod is scheduled, then provisions in that Pod's zone. The right default for multi-zone clusters.

Common Mistakes

No default StorageClass, so PVCs without an explicit class hang in Pending.
Using Immediate binding on a multi-zone cluster and deadlocking Pod scheduling against disk zone.
Forgetting allowVolumeExpansion, then being unable to grow a volume that filled up.
Putting a write-heavy workload on a cheap, slow class and blaming the application for the latency.
Leaving reclaimPolicy: Delete on a class used for data you need to keep.

Best Practices

Define a sensible default StorageClass so ordinary PVCs provision without ceremony.
Use WaitForFirstConsumer on multi-zone clusters to avoid zone-mismatch scheduling failures.
Set allowVolumeExpansion: true so volumes can grow without recreating the workload.
Offer a small set of named tiers (fast, standard, cheap) and match each workload to the right one.
Choose the reclaim policy per class deliberately — Retain for data, Delete for scratch.

RelatedPersistentVolumeClaims — what selects a class (Topic 17)CSI drivers — the provisioners a class points at (Topic 19)Cloud storage tiers — gp3 / pd-ssd / Premium as the parameters

Knowledge Check

What does volumeBindingMode: WaitForFirstConsumer fix on a multi-zone cluster?

It delays disk provisioning until a Pod is scheduled, so the disk lands in the Pod's zone
It speeds up provisioning by creating every zonal disk ahead of time, before any Pod is scheduled
It allows ReadWriteMany access on ordinary cloud block storage disks
It makes the provisioned volume survive a full cluster deletion

A PVC with no storageClassName stays Pending on a cluster. Likely cause?

There is no default StorageClass to provision from
The PVC requested too little storage to meet the cluster's minimum disk size
The reclaim policy on the bound volume is set to Retain
The consuming Pod is missing a readiness probe

Where is the choice of disk type, IOPS, and encryption configured?

In the StorageClass parameters passed to the provisioner
In each Pod's securityContext under its fsGroup and runAsUser settings
In the PersistentVolumeClaim's requested access mode and capacity fields
In the container image's build layers

You got correct