Resizing Persistent Volumes in Thalassa Cloud Kubernetes

Checking Current Volume Size

Before resizing, check the current size of your persistent volume. This helps you determine how much to increase the size and verify that the resize operation was successful.

List PVCs to see their current sizes:

kubectl get pvc

This shows all PVCs with their requested sizes, actual sizes, and status. The output includes columns for requested storage and the actual capacity.

Get detailed information about a specific PVC:

kubectl get pvc my-volume -o yaml

This shows the full PVC definition, including the current storage request and the actual volume capacity. Look for the status.capacity.storage field to see the actual size.

You can also check the size from within a pod that’s using the volume:

kubectl exec -it <pod-name> -- df -h /path/to/mount

This shows the filesystem size and usage from inside the pod, which helps you understand how much space is available and how much is being used.

Resizing a Persistent Volume

To resize a persistent volume, you need to edit the PVC to request a larger size. The process is straightforward, but there are a few considerations to keep in mind.

First, identify the PVC you want to resize. Get its current configuration:

kubectl get pvc my-volume -o yaml > pvc-backup.yaml

This creates a backup of the current PVC configuration, which is useful if you need to reference the original settings.

Edit the PVC to increase the storage request. You can do this by editing the PVC directly:

kubectl edit pvc my-volume

In the editor, find the spec.resources.requests.storage field and increase the value. For example, to increase from 10Gi to 20Gi:

spec:
  resources:
    requests:
      storage: 20Gi

Save and close the editor. Kubernetes will immediately start the resize process.

Alternatively, you can use a patch command:

kubectl patch pvc my-volume -p '{"spec":{"resources":{"requests":{"storage":"20Gi"}}}}'

This updates the PVC without opening an editor, which is useful for automation or when you know exactly what size you want.

Monitoring the Resize Process

After updating the PVC, monitor the resize process to ensure it completes successfully. The resize happens in stages, and you can track progress through the PVC status.

Check the PVC status:

kubectl get pvc my-volume

The status shows whether the resize is in progress or complete. Look for conditions that indicate the resize status:

kubectl describe pvc my-volume

The describe output shows detailed information about the PVC, including any conditions related to resizing. You might see conditions like Resizing or FileSystemResizePending that indicate the current stage of the resize operation.

Watch the PVC to see status changes in real-time:

kubectl get pvc my-volume -w

This watches the PVC and shows updates as they occur, making it easy to see when the resize completes.

Expanding the Filesystem

After resizing the volume, the filesystem often expands automatically. If it doesn’t expand on its own, try restarting the pods or run a manual filesystem expansion command.

For ext4 or xfs filesystems, you can expand the filesystem from within a pod:

kubectl exec -it <pod-name> -- resize2fs /dev/<device>

Or for xfs:

kubectl exec -it <pod-name> -- xfs_growfs /path/to/mount

The exact command depends on your filesystem type and how the volume is presented to the pod.

Verifying the Resize

After the resize completes, verify that the volume has been resized successfully. Check the PVC status to confirm the new size:

kubectl get pvc my-volume

The output should show the new size in the capacity column. Compare this with the requested size to ensure they match.

Check the actual filesystem size from within a pod:

kubectl exec -it <pod-name> -- df -h /path/to/mount

This shows the filesystem size and confirms that the filesystem has been expanded to use the new volume capacity.

You can also check the underlying PersistentVolume:

kubectl get pv
kubectl describe pv <volume-name>

The PersistentVolume should show the updated capacity, confirming that the resize was applied at the storage level.