LAB 03 · MEDIUM · 10–15 MIN

The PVC Never Binds

A PersistentVolume exists, has enough capacity, and is explicitly requested by the claim. The claim still sits Pending and the pod cannot start.

Goal: Bind data-pvc to manual-pv and get the writer pod running.

This uses hostPath on purpose. Run it on a disposable single-node Linux cluster; it is a teaching device, not a storage architecture recommendation.

Start the lab

kubectl apply -f broken.yaml
kubectl get pv
kubectl get pvc -n breakfix-03
kubectl get pod -n breakfix-03

View broken.yaml · cleanup.sh

Hint 1

“A PV exists” is not enough. Compare the claim and volume attributes.

Hint 2

Even when a PVC explicitly names a PV, StorageClass matching still applies.

Solution

kubectl get pv
kubectl get pvc -n breakfix-03
kubectl describe pvc data-pvc -n breakfix-03

The claim explicitly requests manual-pv, but the PV advertises storageClassName: manual while the PVC asks for fast. Naming the volume does not override the StorageClass mismatch, so the claim stays Pending.

Delete and recreate the unbound claim with storageClassName: manual, keeping volumeName: manual-pv. Storage-related claim fields are not all casually mutable in place, so recreating the unbound PVC is cleaner than fighting the API.

kubectl delete pvc data-pvc -n breakfix-03
kubectl apply -f fixed-pvc.yaml
kubectl get pv
kubectl get pvc -n breakfix-03
kubectl get pod writer -n breakfix-03
kubectl exec -n breakfix-03 writer -- cat /data/status

Keep this: Capacity alone does not make a PV eligible. Access mode, StorageClass, selectors, explicit volume requests, and binding state all have to line up.

← Back to all free labs · Continue with all 10 labs — $10