Dynamic Volume Provisioning: Storage on Demand

WHY IT EXISTS: Manually provisioning storage for every application is slow, error-prone, and doesn't scale. Administrators would have to pre-create dozens of PersistentVolumes (PVs) in their cloud provider or data center, hoping they match the sizes and types developers will need. This creates operational bottlenecks.

THE MENTAL MODEL: Think of it as storage on-demand. Instead of an admin pre-carving a specific disk (a PersistentVolume) and you having to know its exact name, you just submit a request (a PersistentVolumeClaim or PVC) describing what you need: "I need 10Gi of fast storage." Kubernetes finds a provisioner that can satisfy that request and creates the volume for you automatically.

HOW IT WORKS: The process involves three key objects. First, an administrator defines one or more StorageClass resources. A StorageClass names a type of storage (e.g., gce-pd-ssd, aws-ebs-gp3) and points to a driver that knows how to create it. Second, a developer creates a PersistentVolumeClaim (PVC) requesting a certain amount of storage from a specific StorageClass. Third, the Kubernetes control plane sees the PVC, invokes the correct provisioner, and a new PersistentVolume (PV) is created and bound to the PVC, ready for a Pod to use.

WHEN TO USE IT: Use dynamic provisioning whenever you need persistent storage for workloads in a Kubernetes cluster. It's the standard, cloud-native way to manage storage for databases, message queues, or any application that needs to save state beyond a single Pod's lifecycle. It's essential for automated, scalable deployments.

WHEN NOT TO USE IT: You might use static provisioning (manually creating PVs) if you need to connect to an existing, pre-populated storage volume that wasn't created by Kubernetes. It's also sometimes used in on-premise environments with storage systems that lack a compatible driver, forcing manual intervention.

ONE CANONICAL EXAMPLE: A developer needs to deploy a PostgreSQL database. They create a PersistentVolumeClaim asking for "100Gi" of storage from the high-iops-ssd StorageClass. The cluster's dynamic provisioner, seeing this claim, calls the cloud provider's API to create a new 100Gi SSD disk. It then creates a PersistentVolume object representing that disk and binds it to the developer's claim. The PostgreSQL Pod can now mount this volume and use it to store its data.