When you need to run workloads in the cloud the question about storage and the type of storage is always around. Some workloads won’t care about the storage type while others may have specific requirements. In a recent exploration, I was mislead by the term Volume Mode
thinking that I had used the incorrect storage class for a particular deployment without knowing what the term really meant.
Volume Mode: How the storage is mounted
A volume with
volumeMode: Filesystem
is mounted into Pods into a directory. If the volume is backed by a block device and the device is empty, Kuberneretes creates a filesystem on the device before mounting it for the first time. - Kubernetes Docs
The confusion started when deploying a workload that requires the storage class to be of type Block
but then seeing the volume mode as Filesystem
. Did I did something wrong? Is that a bug in the software that I installed? Will something eventually break? To my surprise, the answer to all these questions was no. Let’s look at an example.
TIL: The Volume Mode specifies how the volume is mounted in the pod not what type of storage is been used.
To see the Volume Mode of a given PVC you need to add -o wide
to the command:
~ oc get pvc -n ibm-common-services -o wide
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE VOLUMEMODE
alertmanager-ibm-monito... Bound pvc-eef17... 20Gi RWO ibmc-block-gold 23d Filesystem
data-logging-elk-data-0 Bound pvc-86066... 30Gi RWO ibmc-block-gold 23d Filesystem
mongodbdir-icp-mongodb-0 Bound pvc-dfbc6... 20Gi RWO ibmc-block-gold 23d Filesystem
prometheus-ibm-monitoring... Bound pvc-9dc71... 20Gi RWO ibmc-block-gold 23d Filesystem
While I validated that all works as expected and the deployment was successful, I have to admit that not knowing the meaning of volume mode left a lot of questions to really be confident of the deployment. The default value of this property is Filesystem
.
Here is the official Kubernetes documentation for reference.
The other volume mode option is Block
. This will mount the volume as raw block storage, which means that since it doesn’t have a filesystem it will be faster. Here is more information if you are interested on how to use it and the supported provisioners.
While we are talking about storage: The default storage class
If in a given deployment you do not specify the storage class, the default is used. This can be an issue if the workload is not compatible with the access mode supported by the storage class, but at the same time, having a default storage class is useful for other scenarios.
Here is how my storge classes look:
~ oc get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
default ibm.io/ibmc-file Delete Immediate false 23d
ibmc-block-gold (default) ibm.io/ibmc-block Delete Immediate true 23d
ibmc-block-retain-gold ibm.io/ibmc-block Retain Immediate true 23d
ibmc-file-gold ibm.io/ibmc-file Delete Immediate false 23d
ibmc-file-gold-gid ibm.io/ibmc-file Delete Immediate false 23d
To change the default we have a two-step process:
-
Remove the default annotation to the current one
~ oc patch storageclass ibmc-block-gold -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}' storageclass.storage.k8s.io/ibmc-block-gold patched
-
Add the annoation to the new one
~ oc patch storageclass ibmc-file-gold -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' storageclass.storage.k8s.io/ibmc-file-gold patched
Validate that you have one and only one and you are good to go.
~ oc get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
default ibm.io/ibmc-file Delete Immediate false 23d
ibmc-block-gold ibm.io/ibmc-block Delete Immediate true 23d
ibmc-block-retain-gold ibm.io/ibmc-block Retain Immediate true 23d
ibmc-file-gold (default) ibm.io/ibmc-file Delete Immediate false 23d
ibmc-file-gold-gid ibm.io/ibmc-file Delete Immediate false 23d
Until the next finding my friends.