A one-sentence idea with a lot of machinery behind it.

Dynamic provisioning is the ability of Kubernetes to create storage automatically, on demand, when an application requests it. The application says how much space it needs and what kind of storage it wants. Kubernetes talks to the storage system, such as a cloud disk service, asks it to create a disk of that size, and then attaches the new disk to the application.

The opposite is static provisioning, where an administrator creates disks ahead of time and registers each one in Kubernetes by hand, hoping that the disks match what applications will later ask for.

To appreciate the solution, first feel the pain of the old way.

Containers are temporary. When a container stops, everything it wrote inside itself disappears. That is perfect for web servers that keep no memory of visitors, but disastrous for databases, uploaded photos, message queues and anything else that must survive restarts. Such applications need persistent storage, which is storage that lives on after the container is gone.

Kubernetes represents this with two objects. A PersistentVolume (PV) is a piece of real storage registered in the cluster, such as a cloud disk. A PersistentVolumeClaim (PVC) is an application’s request for storage, saying how much and what kind. A claim is matched to a volume, and then the Pod uses the claim.

The static way and its pains

flowchart LR
    subgraph ST["Static provisioning"]
        direction TB
        A1["Developer asks admin"] --> A2["Admin creates disk in cloud"]
        A2 --> A3["Admin registers PersistentVolume"]
        A3 --> A4["Claim finds a matching volume"]
    end
    subgraph DY["Dynamic provisioning"]
        direction TB
        B1["Developer creates claim"] --> B2["Cluster asks storage system for a disk"]
        B2 --> B3["Volume object created and bound automatically"]
    end
    

The storage vocabulary of Kubernetes, one word at a time.

Access modes

An access mode says how many machines may use the storage at once.

Everything dynamic starts with a StorageClass. Without one, there is no recipe to follow.

A StorageClass is a cluster-wide object that describes one kind of storage you offer. Administrators create a small menu of classes, for example “standard”, “fast” and “shared-files”. Developers pick from the menu by name, without needing to know any cloud details.

Fields of a StorageClass

The default class

One StorageClass can be marked as the cluster’s default, using a special annotation. When a claim does not name any class, Kubernetes assigns the default one. This makes life easy for beginners, since a claim with only a size will just work.

There is a subtle trap here. A claim that sets its class name to an empty text is different from a claim that leaves the field out. An empty class name means “do not use dynamic provisioning; bind me only to an existing volume that has no class”. Leaving the field out means “use the default class, if any”.

Who does what when a disk is created? Here is the cast of characters.

flowchart TB
    DEV["Developer: creates claim"] --> API["API server"]
    API --> PVCTL["Volume controllers inside Kubernetes"]
    API --> PROV["CSI external provisioner sidecar"]
    subgraph CTRL["CSI controller Pod"]
        PROV
        ATT["External attacher sidecar"]
        RES["External resizer sidecar"]
        SNAP["External snapshotter sidecar"]
        DRV["CSI driver: controller service"]
    end
    PROV --> DRV
    ATT --> DRV
    RES --> DRV
    SNAP --> DRV
    DRV --> CLOUD["Storage system: cloud disk service or storage array"]
    subgraph NODE["CSI node Pod on every machine"]
        REG["Node driver registrar"]
        NDRV["CSI driver: node service"]
    end
    KL["Kubelet"] --> NDRV
    NDRV --> DISK["Mounted disk in the Pod"]
    

What is CSI?

CSI stands for Container Storage Interface. It is a standard agreement between Kubernetes and storage vendors about how to create, attach, mount, resize and snapshot disks. Before CSI, storage code lived inside Kubernetes itself, so every new storage system meant changing Kubernetes. With CSI, vendors ship a separate driver, and Kubernetes talks to every driver in the same way.

The moving parts

Let us follow one request through every step, from the moment a developer asks for storage.

sequenceDiagram
    participant D as Developer
    participant A as API server
    participant P as External provisioner
    participant C as CSI driver
    participant S as Storage system
    participant V as PV controller
    D->>A: Create PVC with size and class
    A-->>P: Watch event: new claim needs a volume
    P->>C: CreateVolume request
    C->>S: Create disk of requested size and type
    S-->>C: Disk identifier
    C-->>P: Volume created
    P->>A: Create PV object for that disk
    A-->>V: New PV matches claim
    V->>A: Bind PV and PVC
    A-->>D: Claim status is Bound
    

Step by step

One setting in the StorageClass decides whether your disk lands in the right place. It is one of the most important settings in the whole topic.

flowchart TD
    subgraph IM["Immediate mode"]
        I1["Claim created"] --> I2["Disk created at once in some zone"]
        I2 --> I3["Pod scheduled later"]
        I3 --> I4["Pod may need another zone: stuck Pending"]
    end
    subgraph WF["WaitForFirstConsumer mode"]
        W1["Claim created and waits"] --> W2["Pod is scheduled first, node and zone chosen"]
        W2 --> W3["Disk created in that same zone"]
        W3 --> W4["Pod starts normally"]
    end
    

The zone problem

Many cloud disks live in one specific availability zone, which is a separate building within a region. A Pod can only use a zonal disk if it runs on a machine in that same zone. If the disk is created immediately in zone A, but the Pod is later scheduled onto a machine in zone B because that is where free processor time exists, the Pod is stuck: the disk cannot travel.

The solution: wait for the first consumer

With WaitForFirstConsumer, the claim stays unbound until a Pod that uses it is created. The scheduler first picks a node, considering processor, memory, affinity and also storage zones. Then the provisioner creates the disk in the chosen node’s zone. The disk and the Pod always match.

Creating storage is easy. Deleting it safely is where careers get tested.

The reclaim policy decides what happens to the real disk and its data when the claim is deleted. Dynamically created volumes take the policy from their StorageClass.

The classic accident

A developer deletes the Kubernetes namespace of a test system, or removes the wrong claim. Under the Delete policy, the underlying cloud disks are erased along with it, and the data is gone for good. Many teams have learned this the hard way.

Protective habits

• Use a separate class with the Retain policy for production databases.
• You can change the reclaim policy of an already created volume to Retain before doing risky work.
• Take snapshots or backups before destructive changes.
• Kubernetes protects claims that are in use by Pods: a claim in use is not removed until the Pod finishes with it.

A dynamically provisioned volume passes through recognizable stages, each with its own status.

What happens when a Pod moves?

When a Pod using a block disk is rescheduled to another machine in the same zone, Kubernetes detaches the disk from the old machine and attaches it to the new one before starting the Pod. This takes time: often tens of seconds, and sometimes minutes if the old machine failed and the cloud still thinks the disk is attached there. That delay is a real factor in how quickly a stateful application recovers.

For databases and similar software, Kubernetes can create one claim per replica automatically.

A StatefulSet is a Kubernetes controller for applications that need a stable identity and their own storage, such as database members. Instead of asking for claims one by one, a StatefulSet carries a template for claims, called volumeClaimTemplates. For each replica it creates a claim from the template, giving each replica its own disk.

flowchart LR
    SS["StatefulSet with claim template"] --> R0["Replica 0"]
    SS --> R1["Replica 1"]
    SS --> R2["Replica 2"]
    R0 --> C0["Claim 0"] --> D0["Disk 0"]
    R1 --> C1["Claim 1"] --> D1["Disk 1"]
    R2 --> C2["Claim 2"] --> D2["Disk 2"]
    

Important behaviors

• Claim names follow a pattern based on the template name and the replica number, so replica 1 always gets back its own disk.
• If a replica is deleted and recreated, it reattaches to the same claim, keeping its data.
• By default, scaling down does not delete claims. This is a safety feature, but it also means leftover disks that keep billing. Newer Kubernetes versions let you choose a retention policy that deletes claims on scale-down or on deletion of the StatefulSet.
• Deleting a StatefulSet does not by default delete its claims either.

Provisioning is only the start. Storage also needs to grow, be copied and be backed up.

Expansion rules of thumb

• Expansion must be allowed in the class before it is needed. It is much easier to allow it from the start.
• Only increase the size; the request to decrease is refused.
• Cloud providers may limit how often a disk can be modified, so do not resize in tiny steps repeatedly.
• Not every driver or file system supports online expansion. Check your driver’s notes.

Snapshots are not backups

A snapshot usually lives in the same storage system as the original. If that system fails, or someone deletes the storage account, the snapshots go too. A true backup is stored separately, ideally in another region or account. Use snapshots for speed and backups for safety.

Dynamic provisioning works with many kinds of storage. The right choice depends on what your application needs.

Local development clusters

Small learning clusters, such as minikube and kind, come with a simple built-in provisioner that creates folders on the machine. It is perfect for practice. It offers no replication and no protection against losing the machine, so never treat it as production storage.

Not all disks are equal. The StorageClass is where you decide how fast, and how expensive, a disk will be.

Three numbers that describe disk speed

Designing a small menu of classes

A good platform team offers a few clear classes rather than a dozen confusing ones. Here is a typical menu.

Performance traps

• Size can control speed. On some cloud disk types, larger disks receive more IOPS. A tiny disk may be too slow, even if you need little space.
• Burst credits. Some cheap disk types allow short bursts and then slow down. A test that runs for a minute can look perfect, while a real workload later crawls.
• Per-machine limits. Each virtual machine can attach only a limited number of disks and only so much combined throughput, whatever the disk itself can do.
• Noisy neighbors on shared storage. Network file systems and shared arrays can slow down when other tenants are busy.
• Cross-zone traffic. Mounting network storage across zones adds delay and may add data transfer charges.

Storage is where “cattle not pets” stops being true. Data must survive what Pods do not.

Dynamic provisioning is the normal way to do storage on Kubernetes, but it has costs worth understanding.

The design trade-offs

Freedom versus governance. Letting every team create any size of any class is fast but expensive. Quotas and a short menu of classes keep costs in check, at the price of sometimes saying no.

Delete versus Retain. Delete keeps things tidy and cheap. Retain protects data but leaves manual work and possible orphan bills. Match the policy to how precious the data is.

Immediate versus waiting for the first user. Immediate gives quick “Bound” statuses but can place disks badly. Waiting places disks well but shows Pending until used.

Block versus file storage. Block disks are faster and simpler but usually single-writer and zonal. File systems allow sharing, but are slower and more expensive.

Cloud-managed versus self-run storage. Cloud disks are easy and reliable but tied to a provider. Self-run software-defined storage is portable but demands operations skills.

Disks hold your most valuable asset: data. Protect them at every layer.

A full disk at three in the morning is a classic outage. These signals warn you long before it happens.

Alarms worth setting

• Claim Pending beyond a set time with no waiting-mode explanation.
• Volume usage above 80 percent, and inode usage above 80 percent.
• Rate of growth predicting a full disk within a few days.
• Pods stuck in container creating because of attach or mount errors.
• Provisioner errors or cloud throttling messages.
• Released or unattached volumes older than a set number of days.

When creating disks is this easy, the danger is creating too many. A few guardrails keep the bill under control.

Proven habits and common traps.

Patterns that work

Traps to avoid

A checklist for storage that stays safe, fast and affordable.

Habits that pay off

• Use CSI drivers from your cloud or storage vendor, and keep them updated in step with Kubernetes upgrades.
• Enable expansion and encryption in every class from the start.
• Prefer the waiting binding mode for zonal and local storage.
• Pick the reclaim policy per class and document what each class does on deletion.
• Set quotas and size limits per namespace.
• Monitor usage and growth, including inodes, and alert early.
• Test restores on a schedule. A backup you have never restored is only a hope.
• Use claim templates in StatefulSets rather than hand-made claims.
• Check driver limits such as maximum volumes per node before packing stateful Pods.
• Practice failure: kill a node running a stateful Pod in a test cluster and time the recovery.

Mistakes beginners make

How real teams use dynamic provisioning every day.

Follow the request from the claim to the mount, and the fault reveals itself.

flowchart TD
    S1["Pod stuck or claim Pending"] --> S2{"Claim status?"}
    S2 -->|Pending| S3{"Class exists and driver installed?"}
    S3 -->|No| F1["Fix class name or install driver"]
    S3 -->|Yes| S4{"Waiting binding mode and no Pod yet?"}
    S4 -->|Yes| F2["Normal: create the Pod"]
    S4 -->|No| F3["Read provisioner and driver logs: permissions, quota, cloud limits"]
    S2 -->|Bound| S5{"Pod status?"}
    S5 -->|Pending| F4["Zone mismatch, volume limit per node or affinity conflict"]
    S5 -->|Container creating| F5["Attach or mount error: check events and node driver logs"]
    S5 -->|Running but failing| F6["Permissions, full disk, file system errors"]
    

Short answers to the questions people ask most.

You began with a business center where filing cabinets arrive on request. Now you know how a cluster does the same for disks.