liveBook · Manning

Dynamic provisioning

As explained in Kubernetes in Action, Second Edition

Dynamic provisioning is the automatic creation of persistent storage in response to a storage request rather than requiring a precreated volume.

Dynamic provisioning creates persistent storage when an application requests it. Instead of asking an administrator to prepare a volume first, you create a PersistentVolumeClaim (PVC). A provisioner creates the underlying storage and a PersistentVolume (PV) for that claim. Unlike an emptyDir volume, this storage can remain available when the pod is deleted and recreated. section 10.1.2 section 10.2

Listing 10.1 A minimal PVC definition using the default storage class
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: quiz-data
spec:     #1
  resources:             #2
    requests:            #2
      storage: 1Gi       #2
  accessModes:             #3
  - ReadWriteOncePod       #3

This minimal PVC requests 1Gi of storage with ReadWriteOncePod access. With no storageClassName specified, it uses the cluster’s default StorageClass. section 10.2.1

The PVC states what the application needs, including minimum size and access mode. A StorageClass selects the provisioner and supplies its storage parameters; the provisioner creates the matching PV and underlying volume. A cluster administrator installs the CSI driver and makes suitable StorageClasses available. Check available classes with `kubectl get sc`, then inspect a claim with `kubectl get pvc`. If a claim names a nonexistent StorageClass, it stays Pending; `kubectl describe` on the PVC shows ProvisioningFailed events. section 10.1.2 section 10.2.1

Two StorageClass settings affect when and how the volume is created:

  • `volumeBindingMode: Immediate` provisions and binds after PVC creation; `WaitForFirstConsumer` waits until a pod uses the claim. section 10.2.5
  • The class’s provisioner and parameters select the storage implementation. Different classes can use the same provisioner with different parameters. section 10.2.5

A PVC and its PV are not tied to a pod’s lifetime: pods can stop or be replaced without deleting the claim. Deleting the PVC usually deletes a dynamically provisioned PV and its storage, because the reclaim policy is commonly Delete; retention can be configured instead. This differs from static provisioning, where an administrator prepares storage and a PV before a user claims it. section 10.1.2 section 10.3.3

One volume per StatefulSet pod

A StatefulSet can create a PVC for each pod from a claim template. Three pods then receive three separate, dynamically provisioned PVs. Use `kubectl get pvc -l app=quiz` to see the claims and their Bound volumes. section 16.1.4

How Kubernetes in Action, Second Edition covers it

How deep it goes
Explains the claim-to-provisioner workflow, configuration, binding timing, and deletion lifecycle without detailing CSI driver internals.
Examples
Uses a 1Gi quiz-data claim, StorageClass inspection commands, and three StatefulSet claims bound to separate volumes.
What it assumes
Builds on basic pods and ephemeral volumes while defining PersistentVolumes, claims, and their relationship to pods.
What you can do after
Operate/configure it by requesting storage with a PVC, choosing a StorageClass, and checking claim status with kubectl.
How it connects
Connects PersistentVolumeClaims, PersistentVolumes, StorageClasses, CSI drivers, access modes, reclaim policies, and StatefulSets.

Also explained in

Compare how 2 books explain dynamic provisioning →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Kubernetes in Action, Second Edition. The section links point to the parts of the book it draws on.