Resize the system disk of a node when the disk space is insufficient - Container Service for Kubernetes

Expand a node's system or data disk online—no reboot required.

If the node runs ContainerOS, see Resize the system disk of a ContainerOS node online instead.

How it works

Node disk expansion involves two layers:

Increase the disk capacity — resize the Elastic Compute Service (ECS) disk in the ECS console.
Extend the partition and file system — make the new space visible to the node OS.

After both steps, restart kubelet so Kubernetes updates the ephemeral-storage capacity for the node.

The procedure differs slightly between system disks and data disks:

Disk type	Partition extension needed?	File system extension needed?
System disk (for example, `/dev/vda3`)	Yes — run `growpart` first	Yes — run `resize2fs`
Data disk (for example, `/dev/vdb`)	No — the disk has no extra partition	Yes — run `resize2fs` directly

Prerequisites

Ensure the following:

SSH access to the node
Read the disk resize overview for capacity limits and billing. Resizing incurs charges
Confirmed the target disk: system or data disk

Expand the system disk

Check the current disk state

Log on to the node and check current disk usage and partition layout.

Check current file system usage:
```
df -hl
```

List disk partitions:

sudo fdisk -lu

Expected output:

Disk /dev/vda: 20 GiB, 21474836480 bytes, 41943040 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: FD47CD2F-8911-47B3-94A7-76CAE693CF78

Device      Start      End  Sectors  Size Type
/dev/vda1    2048     6143     4096    2M BIOS boot
/dev/vda2    6144   415743   409600  200M EFI System
/dev/vda3  415744 41940991 41525248 19.8G Linux filesystem

You will extend the Linux filesystem partition (/dev/vda3).

Troubleshooting: If /dev/vda is not listed, verify the disk is attached to the node in the ECS console.

Increase the disk capacity in ECS

Log on to the ECS console and resize the system disk.

Use online resizing to avoid a node reboot.

Extend the partition and file system

After the ECS disk resize completes, run these commands on the node.

Extend the partition (/dev/vda, partition 3):
```
sudo LC_ALL=en_US.UTF-8 growpart /dev/vda 3
```
Troubleshooting: If growpart reports the partition is already at maximum size, the ECS resize may not have propagated. Wait a few minutes and retry. If the issue persists, verify the new size in the ECS console.
Extend the file system:
```
sudo resize2fs /dev/vda3
```
Troubleshooting: If resize2fs returns a "bad magic number" or "No such file or directory" error, confirm the partition device (/dev/vda3) matches the fdisk output above.

Verify the new capacity:

df -hl

Expected output (/dev/vda3 should show ~200 GiB in this example):

Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        3.7G     0  3.7G   0% /dev
tmpfs           3.7G     0  3.7G   0% /dev/shm
tmpfs           3.7G   20M  3.7G   1% /run
tmpfs           3.7G     0  3.7G   0% /sys/fs/cgroup
/dev/vda3       197G  4.5G  184G   3% /
...

Restart kubelet to update the node's ephemeral storage capacity:
```
systemctl restart kubelet
```
Important
Restarting kubelet may briefly affect workloads on the node. Schedule this step during off-peak hours.
Confirm Kubernetes reports the new ephemeral storage size (replace cn-qingdao.192.XX.XX.88 with your node name):
```
kubectl get node cn-qingdao.192.XX.XX.88 -o yaml | grep ephemeral-storage
```
The ephemeral-storage value should be ~200 GiB.

Expand the data disk

Check the current disk state

Log on to the node and check the current partition layout.

List disk partitions:

sudo fdisk -lu

Expected output:

Disk /dev/vda: 20 GiB, 21474836480 bytes, 41943040 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: FD47CD2F-8911-47B3-94A7-76CAE693CF78

Device      Start      End  Sectors  Size Type
/dev/vda1    2048     6143     4096    2M BIOS boot
/dev/vda2    6144   415743   409600  200M EFI System
/dev/vda3  415744 41940991 41525248 19.8G Linux filesystem


Disk /dev/vdb: 45 GiB, 48318382080 bytes, 94371840 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

The data disk (/dev/vdb) has no partitions—extend the file system directly, no growpart needed.

Troubleshooting: If /dev/vdb is not listed, verify the data disk is attached to the node in the ECS console.

Increase the disk capacity in ECS

Log on to the ECS console and resize the data disk to the target size (for example, 50 GiB).

Use online resizing to avoid a node reboot.

Extend the file system

After the ECS disk resize completes, run these commands on the node.

Extend the file system:
```
sudo resize2fs /dev/vdb
```
Troubleshooting: If resize2fs returns an error about the file system type, confirm the data disk uses ext4. If it uses a different file system, use the corresponding resize tool.
Restart kubelet to update the node's ephemeral storage capacity:
```
systemctl restart kubelet
```
Important
Restarting kubelet may briefly affect workloads on the node. Schedule this step during off-peak hours.

Verify the new capacity:

df -hl

Expected output (/dev/vdb should show ~50 GiB in this example):

Filesystem     Type      Size  Used Avail Use% Mounted on
devtmpfs       devtmpfs  3.7G     0  3.7G   0% /dev
tmpfs          tmpfs     3.7G     0  3.7G   0% /dev/shm
tmpfs          tmpfs     3.7G   20M  3.7G   1% /run
tmpfs          tmpfs     3.7G     0  3.7G   0% /sys/fs/cgroup
/dev/vda3      ext4      197G  4.5G  184G   3% /
/dev/vda2      vfat      200M  5.8M  195M   3% /boot/efi
/dev/vdb       ext4       49G  2.7G   44G   6% /var/lib/container
...

The /dev/vdb entry now shows ~50 GiB, confirming successful expansion.

Next steps

Extend the partitions and file systems of disks on a Linux instance — detailed guidance including advanced scenarios