In Kubernetes, once a Persistent Volume Claim (PVC) has been bound to a Persistent Volume (PV), certain attributes of the PVC become immutable, including the requested storage size. This is a fundamental constraint in the Kubernetes storage model.
Why PVC Size Is Immutable After Binding
When you create a PVC that binds to a PV, Kubernetes establishes a one-to-one relationship between these resources. The binding process involves matching the PVC's requirements (including storage size, access modes, and storage class) with available PVs.
After binding occurs, changing fundamental attributes like size would invalidate the initial binding contract. The underlying storage system may not support dynamic resizing of the actual physical storage without disruption or data migration.
Even though direct modification is rejected, Kubernetes does provide a mechanism for storage expansion in newer versions.
Volume Expansion Feature: If you're using a StorageClass with the allowVolumeExpansion: true parameter and a storage provider that supports online resizing, you can still expand PVCs.
When you truly need to increase storage and can't use the expansion feature:
Create a new, larger PVC
Manually migrate data from the old volume to the new one
Update your workloads to use the new PVC
Delete the old PVC when safe
This approach involves downtime and manual intervention but is sometimes necessary, especially in older Kubernetes environments or with storage providers that don't support expansion.