By extending the API for PersistentVolumes to specifically request a raw block device, k8s provide an explicit method for volume consumption, whereas previously any request for storage was always fulfilled with a formatted filesystem, even when the underlying storage was block storage.
K8s provide an explicit method for Block Volume Consumption
Kubernetes v1.13 moves raw block volume support to beta, allows persistent volumes to be exposed inside containers as a block device instead of as a mounted file system.
In addition, the ability to use a raw block device without a filesystem will allow Kubernetes better support for high-performance applications that are capable of consuming and manipulating block storage for their needs. Block volumes are critical to applications like databases (MongoDB, Cassandra) that require consistent I/O performance and low latency.
Block Volume Provisioning
In order to create block volume, provisioners need to support volumeMode and then create persistent volume with the desired volumeMode. If the admin selects an external provisioner that is capable of provisioning both filesystem and block volumes, he/she will have to carefully prepare Kubernetes environment for their users because it is necessary for both Kubernetes itself and the external provisioner to support block volume functionality... Support for block volume in Kubernetes was introduced in v1.9 and promoted to beta in Kubernetes 1.13
With the OpenEBS 0.7.0 release, a user can create a block volume via the openebs external-provisioner. With this provisioner, during volume creation, the user requests the PersistentVolumeClaim, which sets volumeMode=”Block” in the PersistentVolumeClaimSpec, binds it with PersistentVolume objects and Block devices are eventually attached to the pods by including them in the volumes array of the podSpec.
Regardless of the volumeMode, provisioner can set FSType into the plugin’s volumeSource but the value will be ignored at the volume plugin side if volumeMode is Block. Leaving volumeMode blank is the same as specifyingvolumeMode = “Filesystem” which results in the traditional behavior.
When using a raw block volume in your Pods, you must specify a VolumeDevice attribute in the Container section of the PodSpec rather than a VolumeMount. VolumeDevices have devicePaths instead of mountPaths, and inside the container, applications will see a device at that path instead of a mounted file system.
How to use block volume
There is a number of use cases where a raw block device will be useful. For example, A user can use a raw block device for database applications such as MySQL to read data from and write the results to a disk that has a formatted filesystem to be displayed via the nginx web server.
The following sections describe some sample volume specifications and steps to dynamically provision a raw block volume and attach it to an application pod.
Here the user creates one block raw volume and other formatted filesystem based volume which dynamically creates PersistentVolumes(PV) respectively.
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: demo-block-pvc
spec:
volumeMode: Block
storageClassName: openebs-default
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5G 2. Filesystem based volume:
kind : PersistentVolumeClaim
apiVersion : v1
metadata :
name : demo-vol-pvc
spec :
storageClassName : openebs-default
accessModes :
- ReadWriteOnce
resources :
requests :
storage : 5G
Here, the user creates an application pod whose containers consume both block & filesystem volumes. We have to choose devicePath for the block device inside the Mysql container rather than the mountPath for the file system.
apiVersion: v1
kind: Pod
metadata:
name: my-db
spec:
volumes:
- name: my-db-data
persistentVolumeClaim:
claimName: demo-block-pvc
- name: my-nginx-data
persistentVolumeClaim:
claimName: demo-vol-pvc
containers
- name: mysql
image: mysql
volumeDevices:
- name: my-db-data
devicePath: /var/lib/mysql/data
- name: nginx
image: nginx
ports:
- containerPort: 80
volumeMounts:
- mountPath: /usr/share/nginx/html
name: my-nginx-data
readOnly: false Conclusion:
A block volume is a volume that will appear as a block device inside the container, and allows low-level access to the storage without intermediate layers, as with file-system volumes. There are advantages of raw disk partitions for example:
Thanks to karthik satchitanand
This article was first published on Mar 27, 2019 on OpenEBS's Medium Account