Block volume support for OpenEBS volume

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

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.

  • Creating a new raw block PVC

Here the user creates one block raw volume and other formatted filesystem based volume which dynamically creates PersistentVolumes(PV) respectively.

  1. Raw Block volume:
kind: PersistentVolumeClaim                  
apiVersion: v1                                               
      name: demo-block-pvc                        
    volumeMode: Block                                
    storageClassName: openebs-default 
        - ReadWriteOnce                                  
             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                                         

  • Using a raw block PVC in POD

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                                                       
      name: my-db                                          
      - name: my-db-data                              
              claimName: demo-block-pvc     
      - name: my-nginx-data                        
             claimName: demo-vol-pvc           
     - name: mysql                                            
        image: mysql                                           
         - name: my-db-data                              
            devicePath: /var/lib/mysql/data 
     - name: nginx                                              
        image: nginx                                            
     - containerPort: 80                                    
     - mountPath: /usr/share/nginx/html
        name: my-nginx-data                           
readOnly: false                                                


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:

  • Block devices that are actually SCSI disks support sending SCSI commands to the device using Linux ioctls.
  • Faster I/O without UNIX file system overhead, and more synchronous I/O without UNIX file system buffering etc.

Thanks to karthik satchitanand

This article was first published on Mar 27, 2019 on OpenEBS's Medium Account


Utkarsh Mani Tripathi
Utkarsh is a maintainer of jiva project and has contributed in building both control and data plane of OpenEBS. He loves to learn about file-system, distributed systems and networking. Currently, he is mainly focusing on enhancing jiva and maya-exporter In his free time, he loves to write poems and make lip smacking dishes
Chuck Piercey
Chuck Piercey is a Silicon Valley product manager with experience shipping more than 15 products in several different market segments representing a total of $2.5Bn revenue under both commercial and open source business models. Most recently he has been working for MayaData, Inc. focused on software-defined storage, network, and compute for Kubernetes environments. Chuck occasionally writes articles about the technology industry.
Sagar Kumar
Sagar is a software engineer at Mayadata who loves coding and solving real-world problems. He has been playing with Kubernetes for the last couple of years. Currently, he is focused on building OpenEBS Director as the go-to solution for OpenEBS users. In his free time, he loves playing cricket and traveling.