Hands-on Lab·Certified Kubernetes Administrator
Expanding a PersistentVolumeClaim
Growing a volume under a running Pod. This reads the two size fields that matter, acts on the condition the cluster raises, and shows what a class that cannot expand does instead.
Storage Guide 69 of 103 Intermediate
- Kubernetes1.36.4
- Cluster4 nodes
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- TimeAbout 16 min
Driver behaviour varies: some finish a filesystem resize online. This one asks for a Pod restart, which is the case worth planning for.
| 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-NODE01 | 192.168.0.176 | Ubuntu 26.04 LTS | Worker 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 |
| CKA1001-NODE03 | 192.168.0.178 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when a volume has run out of space underneath a running Pod. This matters because expansion is a StorageClass capability rather than a property of the claim, and the volume grows before the filesystem does - which is why the resize waits.
- starting from a claim that is bound, mounted and genuinely in use
- checking
allowVolumeExpansionon the class, which is where the capability actually lives - patching the request larger and reading the two numbers that now disagree
- restarting the Pod, which is exactly what the pending condition asked for
- trying the same patch against a non-expandable class and being refused outright
Before you start
-
A claim, bound and in use
-
Can this class even grow
-
Ask for more, and read the two numbers
-
Restart the Pod, which is what the condition asked for
-
The claim that cannot grow at all