Online Volume Expansion
Bumping a PVC to a bigger size grows nothing on its own, so what makes a Pod see more space? The API accepts the edit only if allowVolumeExpansion is true on the StorageClass, then one or two phases run: the external-resizer grows the disk, and Kubelet grows the filesystem, a step a driver may skip on a raw block volume. Where that filesystem grows online the room appears with no restart. Shrinking is refused: no safe general way exists to shrink a live filesystem.
Play the animation 6 steps, animated, best on a wide screen
Online Volume Expansion, step by step
-
You raise spec.resources.requests.storage on the claim from 5Gi to 20Gi. That single field is the only thing anybody changes by hand in this whole card. The request now says 20Gi and nothing physical has moved: the device and the filesystem are both still 5Gi.
Play from step 1 -
That edit was accepted only because of one field on the StorageClass the claim names: allowVolumeExpansion is true. The check runs at admission, on the API server, so with the flag false or absent the edit itself is rejected and no resizer ever hears about it. The gate is on the way in, not further down.
Play from step 2 -
Phase one runs on the controller side. The external-resizer sees the accepted request and calls ControllerExpandVolume on the driver, which tells the backend to grow the real block device from 5Gi to 20Gi. The device is now bigger and the PV capacity follows it. The filesystem sitting on that device has no idea and is still 5Gi.
Play from step 3 -
Phase two runs on the Node. Kubelet calls NodeExpandVolume, which grows the filesystem on the mounted device until it fills the larger disk. This half runs only on a Node where a Pod uses the claim read-write, so with no such Pod it waits for one to start. A raw block volume has no filesystem to grow, so a driver may skip that work.
Play from step 4 -
Only now does the space reach the workload. The device grew, then the filesystem grew, and because this filesystem grows online the extra room shows up inside the running container with no restart, so df in web-0 finally reads 20Gi. The order is the whole point: a filesystem can never grow past the device underneath it.
Play from step 5 -
Growing works, going back does not. Ask for less than the volume already has and the API refuses the edit, because there is no safe general way to shrink a filesystem with live data on it. Walking a request back down after an expansion failed is a different thing: that retries a smaller grow, still above the current size.
Play from step 6