PVC Expansion and Volume Snapshots
Patch a PVC from 64Mi to 128Mi and it reports 128Mi requested against 64Mi actual, with FileSystemResizePending. The volume grew; the filesystem has not. Recreate the Pod and both agree - and the other StorageClass on this cluster cannot do it at all.
Storage Guide 23 of 46 Intermediate
- Kubernetes1.36.4
- Cluster4 nodes
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- TimeAbout 17 min
Behaviour depends on the CSI driver. The two-phase resize and the conditions below are part of the Kubernetes contract; whether an online resize needs a remount is up to the driver.
- CSI driverhostpath.csi.k8s.io
- Snapshot APIsnapshot.storage.k8s.io/v1
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA1001 | 192.168.0.175 | Ubuntu 26.04 LTS | Control Plane Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE02 | 192.168.0.177 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when a volume has to grow, or when you need a point-in-time copy of one. This matters because expansion and snapshots are CSI driver features rather than Kubernetes features - the StorageClass decides whether either works at all.
- reading
ALLOWVOLUMEEXPANSIONacross StorageClasses to see which driver can grow a volume - patching a claim from 64Mi to 128Mi and reading the disagreement between requested and actual size
- recognising
FileSystemResizePendingand recreating the Pod to make the two numbers agree - taking a VolumeSnapshot against a snapshot class and a source claim
- confirming the other StorageClass cannot expand, because
allowVolumeExpansionis simply unset
Before you start
- A CSI StorageClass with
allowVolumeExpansion: true, and a VolumeSnapshotClass for the snapshot step. - The PersistentVolumes and StorageClasses guides from the fundamentals track.
-
Two classes, two capability sets
-
Claim it, mount it, write to it
-
Patch it larger, and read the disagreement
-
Recreate the Pod and they agree
-
Snapshot it
-
The other class cannot