PVC to PV Binding
A PersistentVolumeClaim is a request, not storage, so who hands it a real volume? The binding controller scans the Available volumes, drops the ones too small, of the wrong class or short on access mode, and binds the claim to the smallest one that fits by writing the link on both objects, the volume first. The pairing is exclusive, so with no dynamic provisioner behind the class a second claim like it stays Pending until a matching volume is added.
Play the animation 6 steps, animated, best on a wide screen
PVC to PV Binding, step by step
-
A PersistentVolumeClaim is a request, not storage. It states only what the workload needs: at least 5Gi, ReadWriteOnce access, and the fast StorageClass. Under the default Immediate binding mode, the Pod cannot be scheduled while the claim it references is still unbound.
Play from step 1 -
The binding controller watches every claim in the cluster. This one is new and still unbound, so it reads the three things the claim asks for: capacity, access mode and StorageClass.
Play from step 2 -
The controller checks every Available volume in one sweep. PV a01 is only 2Gi, which is under what the claim asks for, and PV b22 belongs to the slow class rather than fast. Only PV x73a satisfies all three conditions, so it is the candidate. Had several fit, the smallest would win.
Play from step 3 -
Binding is written volume first. PV x73a gets a claimRef pointing at data-claim and turns Bound, so no other claim can take it. Only then does the claim get a volumeName pointing back at PV x73a and turn Bound as well, and each object now names the other.
Play from step 4 -
Only now can the Pod run. It is scheduled onto a Node, Kubelet there resolves the claim to the volume it is bound to and mounts it for the Pod, and the container starts with it at /data. The claim is the handle the Pod holds, and the volume behind it is what actually stores the bytes.
Play from step 5 -
Binding is one to one, and once made it is exclusive. A second claim asking for exactly the same thing cannot have PV x73a, which already carries a claimRef. These volumes were pre-created by an administrator and the class has no dynamic provisioner, so nothing builds a new one. The controller records a ProvisioningFailed event, and the claim stays Pending until a matching volume appears.
Play from step 6