Who makes the volume a claim binds to? Usually a StorageClass.
A recipe for volumes
text
learner@shallows:~$ kubectl get storageclass
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE AGE
local-path (default) rancher.io/local-path Delete WaitForFirstConsumer 12d| Column | Means |
|---|---|
PROVISIONER | The program that creates volumes for this class |
RECLAIMPOLICY | What happens to a volume when its claim is deleted: Delete or Retain |
VOLUMEBINDINGMODE | When the volume is created: Immediate or WaitForFirstConsumer |
(default) | The class a claim gets when it names none |
sc is the short name. StorageClasses are cluster-scoped.
Dynamic provisioning
claimstorageClassName: local-path
provisioner creates
PersistentVolume pvc-5b1e…sized to the request
binds
Bound
Nobody wrote the volume. The class's provisioner made it the size the claim asked for, and named it pvc- plus an ID.
When
WaitForFirstConsumer holds the claim Pending until a Pod mounts it, so the volume can be created on the node that Pod is scheduled to. That is why a lone claim on local-path looks stuck and is not. Immediate creates the volume at once.
Your own class
yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast
provisioner: rancher.io/local-path
reclaimPolicy: Retain
volumeBindingMode: ImmediateSame provisioner, different rules: volumes for fast are created at claim time and kept when the claim goes. Clusters offer classes like this for different disks and different promises.