K8s by Example: Persistent Volume Claims
| PersistentVolumeClaims (PVCs) request storage from the cluster. Pods use PVCs to access PVs without knowing storage details. The control plane binds PVCs to suitable PVs based on size, access mode, and storage class. |
| pvc.yaml | |
| PVC specifies storage requirements. | |
| pvc-binding.yaml | |
| PVC binding matches PVCs to PVs. The control plane finds a PV with: enough capacity (PVC requests 5Gi, can bind to 10Gi PV), matching access modes, matching storageClassName. Once bound, the relationship is exclusive. | |
| pod-pvc.yaml | |
| Use PVCs in Pods via volume mounts. Multiple Pods can reference the same PVC if access mode allows (RWX). The PVC must exist before the Pod starts, or Pod stays Pending. | |
| pvc-dynamic.yaml | |
| Dynamic provisioning creates PVs automatically when PVC is created. Control plane sees PVC with storageClassName, calls provisioner, creates cloud volume (e.g., AWS EBS), creates PV, binds PVC to new PV. No need to pre-create PVs. | |
| pvc-expansion.yaml | |
| Volume expansion allows growing PVCs. StorageClass must have | |
| pvc-selector.yaml | |
| Selector binds PVCs to specific PVs using labels. First: PV with labels. Second: PVC with selector matching those labels. Useful when you need a particular PV (pre-provisioned data, specific performance tier). Bypasses normal capacity-based matching. | |
| pvc-clone.yaml | |
| Data sources clone existing PVCs or restore from snapshots. First example: clone from existing PVC. Second example: restore from VolumeSnapshot. Both require CSI driver support. | |
| terminal | |
| Debug PVC issues by checking status, events, and storage class. Pending PVCs usually mean: no matching PV, wrong access mode, storage class doesn’t exist, or provisioner failed. | |