While the kubernetes storage-sig keeps adding new features in each and every release, we also listen to our user feedback to improve the existing storage interfaces in solving the existing limitations.
Previously, the admin had to do proper capacity planning in order to use persistent Volumes as the microservices or the application pods wanted to save its data for persistence. But, if the initial sizing was wrong, then applications will easily fill this storage and run out of space which would then demand a complete reprovisioning. This is definitely not a desirable situation to be in.
One of the most sought after feature therefore was to add dynamic resizing of the volumes in Kubernetes.
Kubernetes 1.8 release now provides this very functionality. It provides the functionality to resize GlusterFS volume type/plugin.
Now that the feature introduction has been done, let’s now see how this can be achieved with an example below:
As PV resize is in alpha, we need to enable ExpandPersistentVolumes feature gate and also PersistentVolumeClaimResize admission plugin.
Once its enabled,
Let’s create a GlusterFS PV. As a prerequisite, create a secret for heketi authenticaion if heketi auth is enabled in heketi server.
NOTE: If you are using kube >= v1.9, please add
allowVolumeExpansion: true in storageclass field.
Then create a storageclass :
[root@localhost demo]# cat glusterfs-storageclass_fast.yaml apiVersion: storage.k8s.io/v1beta1 kind: StorageClass metadata: name: fast provisioner: kubernetes.io/glusterfs parameters: resturl: “http://127.0.0.1:8081” restuser: “admin” secretNamespace: “default” secretName: “heketi-secret”
Now we proceed to create a PVC:
Check the status of PVC :
So the claim is created and its size is “8Gi” at the moment.
Create a pod and attach this claim to the pod and verify the size of the volume from the pod.
Suppose we now want to increase the size of this PVC to 10Gi from 8Gi, we can do that by editing the PVC object ie
Edit the storage field value to the desired size , for example, let’s make the field of storage to 10Gi and save.
:
# Please edit the object below. Lines beginning with a ‘#’ will be ignored, # and an empty file will abort the edit. If an error occurs while saving this file will be # reopened with the relevant failures. # apiVersion: v1 kind: PersistentVolumeClaim metadata: annotations: pv.kubernetes.io/bind-completed: “yes” pv.kubernetes.io/bound-by-controller: “yes” volume.beta.kubernetes.io/storage-class: fast volume.beta.kubernetes.io/storage-provisioner: kubernetes.io/glusterfs creationTimestamp: 2018-01-09T11:55:52Z finalizers: – kubernetes.io/pvc-protection name: claim11 namespace: default resourceVersion: “367” selfLink: /api/v1/namespaces/default/persistentvolumeclaims/claim11 uid: 0ae02ce5-f534-11e7-bc32-c85b7636c232 spec: accessModes: – ReadWriteMany resources: requests: storage: 8Gi volumeMode: Filesystem volumeName: pvc-0ae02ce5-f534-11e7-bc32-c85b7636c232 status: accessModes: – ReadOnlyMany capacity: storage: 8Gi phase: Bound
persistentvolumeclaim “claim11” edited [root@localhost demo]#
Have a watch on the PVC, without much delay we can see that the new size is reflected under PVC output
Let’s get into the pod which is using this claim and check for the size of the mount point, we can see the new size has reflected in the pod and the application can now make use of the new size.
Demo :
This was a must-have requirement in a cloud infrastructure and GlusterFS leads the way to support this for them.
PS: This feature is only enabled for GlusterFS in Kubernetes 1.8, future versions of kube will bring this capability to more plugins.