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.