StorageClasses & Dynamic Provisioning

In one line

A StorageClass lets Kubernetes automatically create a new PersistentVolume on demand, exactly matching what a PVC asks for — removing the need to manually pre-create storage before any application can use it.

0/4 · 0%

Think of it like this

A hotel that builds a new room on demand the moment a guest checks in, rather than requiring every possible room to already exist and sit empty waiting for someone to need it — DYNAMIC PROVISIONING creates exactly the storage that's needed, exactly when a PVC actually asks for it, rather than requiring someone to have manually pre-created a matching PersistentVolume in advance.

Key ideas

01
Without dynamic provisioning, someone (a cluster administrator) has to manually create a PersistentVolume BEFORE any PVC can bind to it — genuinely impractical at real scale, where applications are deployed constantly and pre-guessing every future storage need isn't realistic.
02
A STORAGECLASS describes HOW to dynamically provision storage — which underlying storage system to use (an AWS EBS volume type, a GCP persistent disk type, an on-prem storage driver) and its specific parameters (disk type, IOPS, replication). When a PVC references a StorageClass by name (or uses the cluster's configured DEFAULT StorageClass, if one exists), Kubernetes automatically creates a brand-new, exactly-matching PersistentVolume on demand.
03
This means the everyday real workflow almost never involves manually creating a PersistentVolume at all — you write a PVC specifying a size and (optionally) a StorageClass, apply it, and a real, correctly-sized disk is provisioned for you automatically, entirely behind the scenes, within seconds.
04
Different StorageClasses typically represent different PERFORMANCE/COST trade-offs available from the underlying cloud provider — a fast-ssd StorageClass for a database needing low latency, a standard StorageClass for less performance-sensitive bulk storage, both coexisting in the same cluster, chosen per-PVC based on what that specific workload actually needs.
05
kubectl get storageclass lists every StorageClass available in the cluster, with one commonly marked (default) — a PVC that doesn't specify a StorageClass at all uses whichever one is marked default, which is exactly why a genuinely surprising or wrong disk type can occasionally get provisioned if a team isn't aware of what their cluster's default actually is.

Code & diagrams

DynamicProvisioningdiagram

A PVC asking for storage automatically gets a freshly-created, matching PersistentVolume — nobody pre-created it.

Rendering diagram…

storageclass-and-pvc.yamlmarkdown

No PersistentVolume is created manually anywhere — the StorageClass handles it automatically.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: ebs.csi.aws.com     # the actual driver that creates real disks (AWS example)
parameters:
  type: gp3
  iops: "5000"
reclaimPolicy: Delete             # delete the real disk when the PVC is deleted (vs Retain)
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: fast-db-storage
spec:
  storageClassName: fast-ssd       # references the StorageClass by name
  accessModes: ["ReadWriteOnce"]
  resources:
    requests:
      storage: 20Gi

storageclasses.shmarkdown

Watch a real PersistentVolume get created automatically, with nobody having pre-made it.

# See what StorageClasses already exist, and which is the default
kubectl get storageclass

kubectl apply -f storageclass-and-pvc.yaml

# The PVC should bind quickly, WITHOUT anyone having manually created a matching PV first
kubectl get pvc fast-db-storage
# STATUS: Bound

# Confirm a brand-new PersistentVolume was created automatically to satisfy it
kubectl get pv
# a new PV appears, matching the requested 20Gi and the fast-ssd class

Explain it without notes

Why is dynamic provisioning via a StorageClass considered essential at real scale, compared to manually pre-creating PersistentVolumes?

A PVC doesn't specify storageClassName at all. What actually determines what kind of storage it gets?

Practice

If you have access to a cluster with dynamic provisioning configured (most managed cloud clusters have this by default), create the example StorageClass and PVC, and confirm a new PersistentVolume is created automatically.

Run kubectl get storageclass and identify which one (if any) is marked as the cluster's default.

Trade-offs

↔
Dynamic provisioning is genuinely essential at scale, but it does mean storage can be created (and billed for) automatically without a human explicitly approving each specific disk — a reclaimPolicy of Delete (this topic's example) also means deleting a PVC by mistake genuinely deletes the real underlying disk and its data, which is why Retain is sometimes deliberately chosen for genuinely critical data, trading automatic cleanup for a manual, safer deletion process.

Done when you can

I understand why dynamic provisioning via a StorageClass is preferable to manually pre-creating PersistentVolumes.
I can create a StorageClass and a PVC that references it, and confirm a PersistentVolume is created automatically.
I know to check which StorageClass is the cluster's default, since an unspecified PVC will silently use it.