|Status||Min K8s Version||Max K8s Version||external-resizer Version|
A storage provider that allows volume expansion after creation, may choose to implement volume expansion either via a control-plane CSI RPC call or via node CSI RPC call or both as a two step process.
To implement volume expansion the CSI driver MUST:
EXPAND_VOLUMEcontroller capability or implement
EXPAND_VOLUMEnode capability or both.
ControllerExpandVolume RPC call can be made when volume is
OFFLINE depending on
- ONLINE : Volume is currently published or available on a node.
- OFFLINE : Volume is currently not published or available on a node.
NodeExpandVolume RPC call on the other hand - always requires volume to be published or staged on a node (and hence
For block storage file systems -
NodeExpandVolume is typically used for expanding the file system on the node, but it can be also
used to perform other volume expansion related housekeeping operations on the node.
For details, see the CSI spec.
The Kubernetes CSI development team maintains external-resizer Kubernetes CSI Sidecar Containers.
This sidecar container implements the logic for watching the Kubernetes API for Persistent Volume claim edits and issuing
ControllerExpandVolume RPC call against a CSI endpoint and updating
PersistentVolume object to reflect new size.
This sidecar is needed even if CSI driver does not have
EXPAND_VOLUME controller capability, in this case it performs a NO-OP expansion and updates
NodeExpandVolume is always called by Kubelet on the node.
For more details, see external-resizer.
To expand a volume if permitted by the storage class, users just need to edit the persistent volume claim object and request more storage.
In Kubernetes 1.14 and 1.15, this feature was in alpha status and required enabling the following feature gate:
Also in Kubernetes 1.14 and 1.15, online expansion had to be enabled explicitly:
external-resizer and kubelet add appropriate events and conditions to persistent volume claim objects indicating progress of volume expansion operations.