Kubernetes Volume Expansion using PVC and StorageClass

Resizing PVCs Without Downtime

In the past, if your database ran out of disk space, it was a disaster. You had to stop the database, create a new larger disk, copy all data from the old disk to the new one, and then restart. This meant Downtime.

Volume Expansion is a Kubernetes feature that lets you increase the size of a Persistent Volume Claim (PVC) on the fly.

If your 10GB disk is full, you simply edit the PVC configuration to say “20GB”. Kubernetes talks to the cloud provider (like AWS or Google Cloud), expands the physical hard drive, and then expands the file system inside your container all while your application is still running.

Key Characteristics to Remember

• “You can grow a PVC, but you cannot shrink it.”
• “The StorageClass is the gatekeeper; if allowVolumeExpansion is false, you are stuck.”
• “Resizing happens in two steps: Cloud Disk Resize -> File System Resize.”

Feature	Description
Prerequisite	StorageClass must have allowVolumeExpansion: true.
Direction	Grow Only. You can increase size (10GB → 20GB), but you can never shrink (20GB → 10GB).
Online Resizing	Most modern Cloud Providers (AWS EBS, GPD, Azure Disk) allow resizing while the Pod is running.
Offline Resizing	Some older storage types require you to delete the Pod (but not the PVC) to trigger the resize.
File System	The underlying file system (ext4, xfs) must support resizing. (Standard Linux ones do).

Volume Expansion allows users to increase the capacity of a PersistentVolumeClaim (PVC) by simply editing the object. This operation requires coordination between the Kubernetes Control Plane, the Cloud Provider, and the Node OS.

The Workflow:

1. User Action: The user edits the PVC (kubectl edit pvc) and increases .spec.resources.requests.storage.
2. Admission Controller: Kubernetes checks if the associated StorageClass has allowVolumeExpansion: true. If yes, it accepts the change.
3. Controller Expansion (Cloud Side): The Volume Controller talks to the Cloud Provider API (e.g., AWS EC2 API) and requests the EBS volume to be resized.
4. Node Expansion (OS Side): Once the physical disk is bigger, the Kubelet on the node detects the change. It runs a command (like resize2fs for ext4 or xfs_growfs for xfs) to expand the file system to fill the new space.
5. Completion: The PVC status removes the FileSystemResizePending condition and shows the new capacity.

Use Cases

• Database Growth: Your startup grows, user data increases. You start with 10GB, grow to 100GB, then 1TB over time without migration.
• Log Analytics: An unexpected surge in traffic fills your logging volume (Elasticsearch/Splunk). Resize it instantly to prevent log loss.

Benefits

• Zero Downtime: Business continuity is maintained.
• Cost Savings: Start small (cheap) and grow only when needed, rather than provisioning a 1TB disk “just in case” and paying for empty space.

Technical Challenges, Limitations, Common Issues

Issue	Cause	Solution
Resize request denied	allowVolumeExpansion is set to false in StorageClass.	Edit the StorageClass (if possible) or create a new one.
FileSystemResizePending forever	The Pod might be crashing or not running.	The resize often requires the Pod to be running to execute the resize2fs command. Fix the Pod.
“Volume is in use” error	Trying to resize a volume that doesn’t support Online Expansion.	Scale Deployment to 0 replicas, wait for resize, scale back to 1.
Cloud Limit Reached	AWS/Azure has a max volume size (e.g., 16TB).	You cannot resize beyond the cloud provider’s physical limit. You must migrate to a new storage array (RAID/LVM).