Skip to main content
This lesson explains StorageClasses in Kubernetes: what they are, how they differ from static provisioning, and how to use them to enable dynamic provisioning of persistent storage. Overview
  • Static provisioning: you create cloud disks ahead of time, then create the matching PersistentVolume (PV) objects and PersistentVolumeClaims (PVCs).
  • Dynamic provisioning (StorageClass): Kubernetes creates the backing storage (cloud disk) automatically when a PVC requests a StorageClass; the PV is created and bound automatically.

Static provisioning

With static provisioning you manually create the backing disk in your cloud provider, then create a PV that references that disk, and finally create a PVC which binds to the PV. This process works but requires manual steps and coordination between cloud resources and Kubernetes manifests. Example: a manually-provisioned PV, a PVC that claims it, and a Pod that mounts the PVC:
Before creating the PV manifest above you typically create the disk on Google Cloud (example using gcloud):
This manual process is called static provisioning. It works, but you must provision storage ahead of time and ensure PV definitions stay synchronized with the cloud disks.

Dynamic provisioning with StorageClass

StorageClasses enable dynamic provisioning: when a PVC is created that references a StorageClass, Kubernetes uses the provisioner defined in that StorageClass to create backing storage on the cloud provider. The provisioner creates the disk, a PV object is created automatically, and the PVC binds to that PV. A minimal example StorageClass for Google Compute Engine using the legacy in-tree provisioner:
Once a StorageClass exists you no longer need to create PVs manually. Instead, reference the StorageClass in your PVC with storageClassName:
When you apply the PVC above, the StorageClass’s provisioner will create the disk in Google Cloud, create the corresponding PV, and bind the PVC to it. The PV still exists — it is just created automatically instead of by you. Quick comparison: static vs dynamic provisioning

Note about provisioners and parameters

Different provisioners support different parameters and settings. For the legacy in-tree Google Persistent Disk provisioner you can choose disk type and replication mode, for example: Example StorageClass using parameters for the in-tree GCE provisioner:
You can create multiple StorageClasses to represent different service levels (e.g., silver/gold/platinum), each using different disk types or replication settings:
Next time you create a PVC, specify the desired class in storageClassName and Kubernetes will dynamically provision the appropriate storage for you.
Consider modern clusters may use CSI drivers rather than the in-tree provisioners. For GKE, for example, the CSI provisioner name is pd.csi.storage.gke.io. Check your cluster documentation and use the appropriate provisioner for production clusters.
Links and references

Watch Video

Practice Lab