Kubernetes storage · Interactive diagram

Static provisioning: the volume exists first

Press Play for the flow, or Next to study one phase at a time. Scroll horizontally inside the diagram to read its labels. This is a configuration/provisioning flow, not the application's read/write data path.

Static provisioning with a no-provisioner StorageClass An administrator creates a local PV ahead of time; a PVC naming the no-provisioner StorageClass is matched and bound to that existing PV, and a Pod uses the PVC. PATH B · STATIC PROVISIONING (AN ADMIN CREATES THE PV FIRST) CREATES FIRST NAMES CLASS SAME CLASS USES CLAIM BINDS 1:1 kubernetes.io/no-provisioner never creates a PV or a disk. The class only gives the PVC a name to match against PVs that an admin already made. POD Pod my-db mounts /var/lib PVC PersistentVolumeClaim db-data · 50Gi class: local-storage SC StorageClass name: local-storage kubernetes.io/no-provisioner ADMIN Administrator kubectl apply pv.yaml PV PersistentVolume local-pv-1 · 50Gi disk on node-1 LEGEND Person / workload Storage request Class that creates nothing Volume made by hand Binding Refers to
←/→ step · Space play/pause · R replay · Home/End jump

  1. 1. Administrator prepares the PV

    An administrator prepares storage and creates a PV before the application uses it. For local storage, the PV also needs node affinity.

  2. 2. Class names must match

    The PV and PVC identify the same StorageClass. kubernetes.io/no-provisioner does not create disks or PVs.

  3. 3. Pod references the claim

    The Pod names the PVC. With WaitForFirstConsumer, scheduling helps select a suitable existing volume.

  4. 4. Claim binds to the existing PV

    Kubernetes matches a suitable available PV to the claim. Capacity, access mode, class and topology must be compatible.