Skip to content
SRE & DevOpsDeep Dive Published Updated 3 min readViews unavailable

Kubernetes PVC Expansion: Growing Persistent Volumes Without Data Loss

Plan Kubernetes volume growth around StorageClass policy, CSI driver support, filesystem expansion, and observable recovery states.

Kubernetes PersistentVolumeClaim (PVC) expansion requests more capacity for an existing backing volume. It is a grow operation, not a way to shrink storage or replace a claim with a new volume. The control plane updates the existing volume through the storage implementation; it does not create a replacement PersistentVolume to satisfy the larger request.

Expansion is supported only when the StorageClass allows it and the provisioner or CSI driver implements the operation. Kubernetes support by itself does not prove that a particular backend, filesystem, access mode, or volume lifecycle supports online growth. Verify the driver documentation and recovery process before raising production capacity.

Confirm the whole resize path first

Identify the PVC, its bound PV, StorageClass, provisioner, volume mode, mount state, and filesystem. Check the StorageClass for allowVolumeExpansion: true. Then confirm the CSI driver’s controller-side and node-side resize capabilities, backend quota, and whether the filesystem can grow while mounted. For filesystem volumes, Kubernetes documents XFS, Ext3, and Ext4 as supported resize filesystems.

Use a backup or storage snapshot consistent with the application before changing a production claim. A block-level snapshot is not automatically application-consistent: databases may need their own checkpoint, flush, or quiesce procedure. Record the current requested size, reported capacity, application free space, and backend allocation so the result can be compared after the operation.

Request a larger size through the PVC

The safe control-plane change is to increase the PVC’s requested storage. This example is intentionally a patch against a named claim; replace the namespace, claim, and size after reviewing the StorageClass and driver support.

kubectl get pvc data-db-0 -n production -o wide
kubectl get pvc data-db-0 -n production -o yaml
kubectl get storageclass fast-csi -o yaml

kubectl patch pvc data-db-0 -n production --type merge \
  -p '{"spec":{"resources":{"requests":{"storage":"200Gi"}}}}'

kubectl describe pvc data-db-0 -n production
kubectl get pvc data-db-0 -n production --watch

Do not manually edit the PersistentVolume’s capacity to make it match the desired PVC. Kubernetes warns that doing this can convince the control plane the resize has already happened, preventing the normal resize workflow. Also avoid deleting and recreating a claim as a routine workaround: reclaim policy and claim protection affect whether the underlying data survives.

Observe controller and filesystem completion

The request can pass through backend volume expansion and filesystem expansion. Watch the PVC’s events, conditions, allocated-resource status, CSI controller logs, and node-side resizer logs. A larger requested value is not proof that the filesystem mounted in the Pod can use the extra blocks. Verify reported capacity inside the workload and through the storage provider, then run application-level reads and writes appropriate to the service.

For an in-use PVC, Kubernetes documents that a Pod does not normally need to be deleted and recreated for expansion; filesystem growth may complete while a supporting filesystem is mounted. Driver limitations or a filesystem that requires mount-time growth can change the operational steps, so follow that driver’s guidance and schedule a controlled remount only when evidence requires it.

If the backend cannot satisfy the requested size, the resize can keep retrying. Do not repeatedly increase the requested size. Determine the backend quota or driver error, preserve the data, and follow Kubernetes’ documented failed-expansion recovery procedure with the storage administrator. Capacity planning should include growth headroom, alert thresholds, and a test of recovery from a request that exceeds available backend capacity.

Acceptance checks

After the resize, confirm the claim remains Bound, the PV reflects the completed backend capacity, filesystem status has settled, and the Pod sees the expected available space. Validate database or application health and ensure monitoring reports the new capacity. Keep the snapshot and change record until the workload has passed its normal integrity checks.

Related:

Sources:

Comments