A county PVC sets storageClassName: fast and stays unbound until a matching volume appears. What normally causes the PersistentVolume to be created automatically?
Select an answer to reveal the explanation.
Short Explanation
Filing a PVC that names StorageClass fast is like submitting a work order to the “fast” shop—the provisioner on that class builds the disk and the PV shows up bound to your claim. The scheduler, DNS, and kube-proxy are not the disk factory.
Full Explanation
When a county PVC sets storageClassName: fast and stays unbound until a matching volume appears, dynamic provisioning is what normally creates the PersistentVolume: the PVC’s reference to StorageClass fast triggers that class’s provisioner to create and bind a PV. Filing the claim is the work order; the provisioner is the shop that builds the disk and completes the lease binding for municipal workloads.
The scheduler creates Pod placements, not PVs for every Pending Pod regardless of PVC fields. CoreDNS does not watch PVCs or allocate block devices via DNS TXT records. kube-proxy invents Service dataplane rules, not PersistentVolumes when it sees a ClusterIP in the namespace.
Exam caveat: if the class is missing, the provisioner is down, or quota/topology blocks creation, the PVC remains Pending—naming fast is necessary but not sufficient. Default StorageClass behavior applies only when storageClassName is omitted, not when fast is explicitly set.
Operational check: confirm StorageClass fast exists with a live provisioner, apply the PVC, watch events for successful provisioning, and verify the Bound PV’s capacity and access modes satisfy the claim. Keep civic change tickets precise: record object names, namespaces, and before/after observations so the next on-call engineer can replay the fix without guesswork.