StorageClass and Dynamic Provisioning ¶

In Kubernetes, dynamic provisioning is a mechanism that automatically creates [[persistent-volume|PersistentVolumes]] (PVs) based on storage requests. This process is driven by StorageClass objects, which define the classes of storage (such as tiers of performance or backend protocols) available to a cluster^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md].

Overview¶

While [[persistent-volume|PersistentVolumes]] can be statically provisioned by an administrator in advance, Dynamic Provisioning allows the cluster to create storage on-demand^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md]. When a user creates a [[persistent-volume-claim|PersistentVolumeClaim]] (PVC) that specifies a storageClassName, Kubernetes attempts to find a matching StorageClass and dynamically provisions a new PV to satisfy the claim^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md].

How It Works¶

The interaction between StorageClasses and PVCs follows a specific logic:

Trigger: A PVC is created that includes a spec.storageClassName^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md].
Provisioning: If the cluster administrator has created and configured the specified StorageClass, the cluster uses the parameters defined in that class to provision a new storage volume^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md].
Binding: The newly created PV is automatically bound to the requesting PVC.

If a PVC does not explicitly specify a storage class, it will use the cluster's default StorageClass^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md]. Explicitly setting the storageClassName to an empty string ("") disables Dynamic Provisioning for that claim^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md].

StorageClass and Access Modes¶

The definition of a StorageClass is intrinsically linked to the Access Modes required by the PVC (e.g., ReadWriteOnce, ReadOnlyMany, ReadWriteMany)^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md].

Different storage backends (provisioners) support different access modes. For example: * Single-node environments: Local storage (like hostpath on Docker Desktop) easily satisfies ReadWriteOnce where only one node exists^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md]. * Multi-node environments: Scenarios involving [[gke|Google GKE]] or [[aws|AWS EKS]] often require shared access across nodes. * To support ReadWriteMany (RWX), provisioners typically rely on cloud-based [[nfs|NFS]] services (e.g., Google FileStore)^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md]. * Standard cloud block storage (e.g., Google Compute Engine Disk) typically supports ReadWriteOnce (RWO)^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md].

Therefore, selecting a StorageClass is often a decision about the trade-off between performance and the need for multi-node concurrency^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md].

Example: Using StorageClass in a PVC¶

Below is an example of a PVC definition that requests Dynamic Provisioning using a StorageClass named hostpath^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md].

# pvc.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc-demo
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: hostpath
  resources:
    requests:
      storage: 1Gi

In this example, if the hostpath StorageClass exists and supports Dynamic Provisioning, the cluster will automatically allocate the underlying storage.

[[PersistentVolume]]
[[PersistentVolumeClaim]]
[[Volume]]
[[StatefulSet]]

Sources¶

^[400-devops__06-Kubernetes__k8s-ithelp__Day20__README.md]

StorageClass and Dynamic Provisioning¶