How does a Kubernetes PersistentVolumeClaim end up bound to a PersistentVolume, and what do the PersistentVolume phases Available, Bound, Released and Failed mean?

## Two objects, one match A **PersistentVolume (PV)** is a cluster-scoped object describing a piece of real storage: its capacity, access modes, volume mode, storage class name, reclaim policy, node affinity and the driver-specific handle. A **PersistentVolumeClaim (PVC)** is a namespaced request: how much, which access mode, which class, optionally a label selector. The PersistentVolume controller in kube-controller-manager continuously reconciles the two. For each unbound PVC it evaluates candidate PVs on: - **storageClassName** — must be equal, including the "both empty" case. - **accessModes** — the PV must support every mode the claim asks for. - **volumeMode** — `Filesystem` versus `Block` must match. - **capacity** — the PV must be at least the requested size (it may be larger; the claim gets the whole volume, not a slice). - **selector** — if the claim carries `spec.selector`, the PV's labels must satisfy it. - **node affinity / topology** — evaluated by the scheduler when binding is delayed. Among matches it prefers the smallest sufficient volume, to avoid wasting a 1Ti PV on a 5Gi request. Binding is recorded on both sides: `pv.spec.claimRef` names the claim (namespace, name, UID) and `pvc.spec.volumeName` names the PV. It is **exclusive** — one PV, one PVC — and it is **permanent**: a PV is never re-matched to a different claim on its own. ## Static versus dynamic, in one paragraph *Static provisioning* means an administrator has created PV objects in advance, and binding is pure matchmaking against that pool. *Dynamic provisioning* means the claim names a StorageClass with a real provisioner, and when nothing in the pool matches, a volume and its PV are manufactured on demand. The two coexist: the controller always tries to match an existing PV first, and only falls through to provisioning. This is why a claim with `storageClassName: ""` can consume a hand-made PV — no provisioner is ever consulted. ## PV phases - **Available** — the PV exists, has no `claimRef`, and can be matched. Typically only seen with static provisioning; dynamically provisioned PVs are born pre-bound. - **Bound** — matched to a claim. The steady state. - **Released** — the PVC was deleted, so the PV no longer serves anyone, but reclamation has not finished (or, under `Retain`, will never happen automatically). The data is generally still on the volume. Crucially, a Released PV is **not** returned to the Available pool: it still carries the stale `claimRef`, so it will not bind to a new claim even one with the same name. Recovering it means editing out `claimRef` (making it Available) or deleting the PV object and re-creating it pointing at the same backend volume. - **Failed** — automatic reclamation failed, for example the driver could not delete the backing volume. Needs manual investigation; the underlying resource may still exist and still be billed. PVC phases are simpler: **Pending** (unmatched/unprovisioned, or waiting for a first consumer under delayed binding), **Bound**, and **Lost** (its PV disappeared from under it). ## Why a PVC sits Pending The honest checklist, in the order it pays to check: 1. `kubectl describe pvc` — events name the cause more often than not. 2. Class mismatch: the claim's class does not exist, or is `""` while every PV has a class (or vice versa). 3. No PV large enough, or with the required access mode / volume mode. 4. A `selector` on the claim that no PV's labels satisfy. 5. The candidate PV is `Released`, carrying a stale `claimRef` from a deleted claim — the single most common "but there is clearly a free volume right there" case. 6. Delayed binding: the class waits for a consuming Pod, which is normal and resolves when a Pod is scheduled. 7. Provisioning failure from the driver: quota exhausted, bad parameters, missing credentials. ## Protection finalizers Two finalizers guard the objects. `kubernetes.io/pvc-protection` keeps a PVC that is in use by a Pod from actually disappearing — it shows `Terminating` until the last consuming Pod is gone. `kubernetes.io/pv-protection` does the same for a PV bound to an existing claim. This is deliberate: it prevents yanking storage out from under a running workload, and it is the reason a `kubectl delete pvc` sometimes appears to hang. ## Interview-ready summary Binding is exclusive, attribute-based matchmaking performed by a controller; the PV's phase tells you where it is in that lifecycle; and `Released` is the phase people misread, because it looks free and behaves as if it were not.