Kubernetes has been supporting Persistent Volumes Claim (PVC) dynamic expansion since 1.11. AWS EBS, GlusterFS, RBD, etc can modify PVC to increase the size of Persistent storage. However, whether the application is affected depends on the implementation of storage plug-ins. Some storage plug-ins do not need to restart the Pod, and some storage plug-ins support capacity expansion only after the PV is uninstalled from the Node. Today, we’ll take a look at how various storage plug-ins can achieve downtime free capacity expansion.

Network file system

The first storage plug-in is a network File system, such as GlusterFS, Azure File, etc. This type of storage plug-in does not need to expand Node’s local file system, so you only need to change the size of the PVC to expand capacity.

Block storage device

The second type of storage plug-in is block storage devices, such as AWS EBS, Ceph RBD, etc. Because the file system exists, you need to expand the file system after the block device is expanded. In earlier versions of Kubernetes, extensions to the file system required the Pod to be restarted and the PVC to be mounted in ReadWrite mode, which was very inconvenient in practice.

Since 1.15 Kubernetes ExpandInUsePersistentVolumes features of the new on-line modification of PVC increased the size of the file system function, without having to restart the Pod is to mount a piece of equipment in the expansion. So, after open ExpandInUsePersistentVolumes characteristics, you just need to modify the size of the PVC expansion.

Block device storage that can be expanded only after uninstallation

The last type is block device storage that needs to be uninstalled from nodes before capacity expansion, such as Azure Disk. For this type of storage, the PVC cannot be expanded by directly changing the size of the PVC or restarting the Pod. In order to unmount the block device from Node, the Pod needs to be removed for a period of time and then created again after the PVC has been expanded. Can this type of storage be expanded without downtime?

If viewed from the perspective of a single Pod, removing a Pod is bound to cause an outage. However, each application generally contains multiple PODS. The deletion of one Pod does not affect the availability of the entire application. Therefore, the capacity expansion can be implemented without downtime from the perspective of the application.

For example, for a common StatefulSet that typically runs three replicas, you can perform the following steps to expand:

1) Save the StatefulSet configuration for later use kubectl get StatefulSet rabbitmq -o yaml > rabbitmq.yaml Kubectl delete StatefulSet rabbitmq –cascade=false 3) Delete the first Pod and expand the PVC referenced by it:

Kubectl delete pod rabbitmq-0 kubectl edit PVC rabbitmq-0Copy the code

4) Restore StatefulSet kubectl apply -f rabbitmq.yaml. 5) Repeat the above steps for the remaining two copies, expand their PVC and then rebuild them back.

This way, one Pod is always removed during capacity expansion, but the other two copies are still working and the entire application is still running.

In a word, to achieve breakup-free storage capacity expansion, you can consider the storage layer and application layer respectively. Problems that can be solved at the storage layer can be solved at the storage layer, and problems that cannot be solved at the storage layer can be circumnavigated at the application layer.

Welcome to pay attention to chat cloud native public number, learn more cloud native knowledge.