Context
Growing a PersistentVolumeClaim is a request to a storage workflow, not an immediate promise of usable space inside a container. The CSI driver may need to expand the backing volume, and a filesystem may need a separate expansion step. Reading only the requested PVC size can therefore give a misleading picture of completion.
Before starting, identify the PVC, namespace, consuming Pod, StorageClass, CSI driver, and approved backup or recovery procedure. You need read access to claims, volumes, classes, and workload events. Driver-specific expansion support must be checked against the version actually installed.
1. Compare requested and reported capacity
kubectl -n processing get pvc work-data -o yaml
kubectl -n processing describe pvc work-data
kubectl -n processing get pod worker-0 -o yaml
Inspect the request, reported capacity, conditions, and allocation-related status fields available in your cluster version. Read the events in time order. Confirm that the affected Pod uses this claim and that the application checks the expected mount. A similarly named directory in the image is not evidence of the mounted volume's size.
2. Check expansion capability and ownership
Read the bound PV name from the claim, then inspect that specific object and class:
kubectl get pv example-pv -o yaml
kubectl get storageclass example-csi -o yaml
The names are illustrative. Check allowVolumeExpansion and the driver identity, then consult the installed driver's documentation for controller expansion, node expansion, and online filesystem support. The Kubernetes API accepting a larger request does not prove every required driver capability is present.
Do not edit the PV capacity to make the numbers look consistent. Kubernetes documents that manually making PV capacity match a PVC request can prevent the automatic workflow from recognizing the required resize. The PVC request should express the desired growth through the supported procedure.
3. Trace controller and filesystem completion
Correlate PVC events with CSI-controller and CSI-node logs through approved logging access. Determine whether the backend allocation failed, node expansion is waiting, or the mounted filesystem has not completed growth. If an existing container has an appropriate utility, a read-only filesystem capacity check can confirm the mount's current view:
kubectl -n processing exec worker-0 -- df -h /work
For an explicitly illustrative example, the claim requests 40Gi while status still reports its prior capacity. That is different from status reporting 40Gi while the mounted filesystem remains smaller. The first case directs attention toward volume expansion; the second needs filesystem and node-side evidence.
Interpret the status gap
| Observation | Possible stalled stage | Next evidence |
|---|---|---|
| Expansion forbidden by policy | Capability or class setting | StorageClass and driver support |
| Backend allocation error in events | Controller expansion | CSI-controller logs and storage capacity |
| Filesystem resize pending | Node or filesystem step | Driver guidance and Pod mount state |
| Mounted size correct, app still reports full | Application view | Actual path, reserved space and file usage |
Volume growth is not a supported shrink operation. If a request is too large, use the documented recovery behavior for your Kubernetes and driver versions. Avoid deleting the claim or altering binding metadata as a generic repair.
Verify and maintain an expansion procedure
After the reviewed correction, compare requested capacity, status capacity, and the mounted filesystem. Perform a harmless application write through its normal test mechanism and check subsequent CSI events. Schedule any required Pod replacement according to the application's availability and storage rules.
Maintain a per-class expansion SOP with supported driver versions, online/offline expectations, backup prerequisites, evidence to collect, and escalation owners. Monitor repeated resize failures and application free-space trends separately. Record successful completion at every layer so an accepted request is never mistaken for finished application capacity.
Explore Clouvenix containers kubernetes for implementation and operational handover.