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

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


Don Williams
Don is the CEO of MayaData and leading the company for last one year. He has an exceptional record of accomplishments leading technology teams for organizations ranging from private equity-backed start-ups to large, global corporations. He has deep experience in engineering, operations, and product development in highly technical and competitive marketplaces. His extensive professional network in several industries, large corporations and government agencies is a significant asset to early stage businesses, often essential to achieve product placement, growth and position for potential exit strategies.
Kiran Mova
Kiran evangelizes open culture and open-source execution models and is a lead maintainer and contributor to the OpenEBS project. Passionate about Kubernetes and Storage Orchestration. Contributor and Maintainer OpenEBS projects. Co-founder and Chief Architect at MayaData Inc.
Murat Karslioglu
VP @OpenEBS & @MayaData_Inc. Murat Karslioglu is a serial entrepreneur, technologist, and startup advisor with over 15 years of experience in storage, distributed systems, and enterprise hardware development. Prior to joining MayaData, Murat worked at Hewlett Packard Enterprise / 3PAR Storage in various advanced development projects including storage file stack performance optimization and the storage management stack for HPE’s Hyper-converged solution. Before joining HPE, Murat led virtualization and OpenStack integration projects within the Nexenta CTO Office. Murat holds a Bachelor’s Degree in Industrial Engineering from the Sakarya University, Turkey, as well as a number of IT certifications. When he is not in his lab, he loves to travel, advise startups, and spend time with his family. Lives to innovate! Opinions my own!