Kubernetes storage · Diagram 1 of 2 · Architecture

How a Pod gets storage

Pods don't ask for disks directly. They point at a PersistentVolumeClaim (a request). The claim is then matched to a PersistentVolume (the actual volume). There are two ways that PV can come into existence.

In Path A the PV is created on demand. The claim names a StorageClass, and the class names a provisioner that creates both the disk and the PV.

Dynamic provisioning: Pod, PVC, StorageClass, CSI, PV A Pod uses a PVC; the PVC names a StorageClass whose CSI provisioner creates a real disk and a matching PV, and the PVC binds one-to-one to that PV. PATH A · DYNAMIC PROVISIONING (STORAGE IS CREATED FOR YOU) KUBERNETES CLUSTER OUTSIDE THE CLUSTER USES CLAIM NAMES CLASS NAMES DRIVER CREATES DISK CREATES PV BINDS 1:1 POINTS TO A PVC is a request for storage. A PV is the volume that fills it. Each PVC binds to exactly one PV. POD Pod my-app mounts /data PVC PersistentVolumeClaim my-data · 10Gi class: fast-ssd SC StorageClass name: fast-ssd provisioner: ebs.csi.aws.com CSI CSI Provisioner external-provisioner + CSI driver DISK Real storage cloud disk / SAN e.g. AWS EBS PV PersistentVolume pvc-3f2a… · 10Gi created automatically LEGEND Your workload Your storage request Cluster config / controller Volume object Outside storage Binding Storage API call Refers to

The simpler path: the PV exists first

Not every StorageClass creates storage. In Path B an administrator writes the PV by hand. Kubernetes only matches a waiting claim to it by class, size and access mode.

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) USES CLAIM NAMES CLASS BINDS 1:1 CREATES FIRST SAME CLASS 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

The four objects, in plain words

  • Pod: your running app. It lists a PVC under volumes and mounts it at a path.
  • PVC: "I need 10Gi of fast-ssd storage." A request that lives in your namespace.
  • StorageClass: a recipe set up by the cluster admin. Its provisioner field says who, if anyone, creates storage for this class.
  • PV: the real volume, represented as a cluster-wide object. One PV binds to one PVC.

Dynamic vs. static

  • Dynamic: the class names a real provisioner, usually a CSI driver like ebs.csi.aws.com. A new PVC triggers creation of a disk and a PV.
  • Static: an admin creates PVs ahead of time. A class using kubernetes.io/no-provisioner never creates PVs. It is commonly used for local PVs (disks attached to one node).
  • If no matching PV exists for a no-provisioner class, the PVC simply stays Pending.

Fidelity note

Simplified for beginners:

  • "CSI Provisioner" merges the external-provisioner sidecar and the CSI driver into one box.
  • The PV controller (in kube-controller-manager) that does the binding is not drawn. "BINDS 1:1" stands for its work.
  • Not shown: default StorageClass, access modes, reclaim policy, PVs with no class (storageClassName: ""), volume attach, nodeAffinity on local PVs.
Kubernetes storage · StorageClass, PV, PVCDiagram 1 · Architecture