OpenEBS – Container Attached Storage (CAS)

Reading Time: 4 minutes

OpenEBS is the leading open-source project for container-attached and container-native storage on Kubernetes and It adopts Container Attached Storage (CAS) approach, where each workload is provided with a dedicated storage controller.

It implements granular storage policies and isolation that enable users to optimize storage for each specific workload which runs in userspace and does not have any Linux kernel module dependencies.

Types of Storage:

OpenEBS provides three types of storage these are:

1. Jiva 
2. cStor
3. OpenEBS Local PV 

In this blog, we are going to learn OpenEBS local PV only.

OpenEBS Local PV:

local PV represents a mounted local storage device like a disk or a hostpath (subpath) directory.

Local PVs are an extension to hostpath volumes but are more secure.

OpenEBS Dynamic Local PV provisioner will help to provision the Local PVs dynamically by integrating into the features offered by OpenEBS Node Storage Device Manager

This also offers flexibility either select a complete storage device or a host path (or subpath) directory.

OpenEBS create two Storage Classes of Local PVs by default as openebs-hostpath and openebs-device.

Openebs-hostpath

The simplest way to provision an OpenEBS Local PV based on hostpath is to use the default StorageClass which is created as part of the latest 1.0.0 operator YAML.

The default StorageClass name for hostpath configuration is openebs-hostpath. The default hostpath is configured as /var/openebs/local.

When a PVC is invoked using the above storage class, OpenEBS Local PV provisioner uses NDM operator and creates a new sub-directory inside the BasePath and maps it to the PV.

Note: If default Basepath needs to be changed by mentioning different hostpath, then the specified hostpath(directory) must be present of the Node.

The default StorageClass name for hostpath configuration is openebs-hostpath.

The default hostpath (Basepath) is configured as /var/openebs/local.

openebs-device

The simplest way to provision an OpenEBS Local PV based on device is to use the default StorageClass for OpenEBS Local PV based on the device which is created as part of the latest 1.0.0 operator YAML. The default StorageClass name for OpenEBS Local PV based on device configuration is openebs-device.

When a PVC is invoked using the above storage class, OpenEBS Local PV Provisioner uses an NDM operator and reserves a matching disk from the worker node where the application pod is being scheduled. If no FSType is specified, Local PV provisioner will use the default filesystem as ext4 to format the block device.

Backup and Restore

OpenEBS volume can be backed up and restored along with the application using velero plugin. This helps the user to back up the OpenEBS volumes to the third party storage location, then restores the data whenever it is needed.

Quickstart with openEBS:

STEP-1: OpenEBS requires iSCSI client to be configured and iscsid client service running on the host nodes.

I am using ubuntu In this example you can find iSCSI client for other OS here:

 sudo apt-get update
 sudo apt-get install open-iscsi
 sudo service open-iscsi restart

Verify iSCSI services are configured or not?

 sudo cat /etc/iscsi/initiatorname.iscsi
 systemctl status iscsid 

If the service status is showing as an Inactive, you may have to enable and start the iscsid service using the following command.

sudo systemctl enable iscsid && sudo systemctl start iscsid

STEP-2:  

kubectl apply -f https://openebs.github.io/charts/openebs-operator-1.0.0.yaml

Verifying OpenEBS installation

Verify pods:

kubectl get pods -n openebs

In the successful installation of OpenEBS, you should see an example output like below.

openebs-ndm is a daemon set, it should be running on all nodes or on the nodes that are selected through node selector configuration.

The control plane pods openebs-provisioner, maya-apiserver and openebs-snapshot-operator should be running. If you have configured node selectors, check if they are scheduled on the appropriate nodes by listing the pods through kubectl get pods -n openebs -o wide

Verify Storage-classes:

List the storage classes to check if OpenEBS has installed with default StorageClasses.

kubectl get sc

In the successful installation, these StorageClasses are created.

Now, openEBS has been installed successfully. 

EXAMPLE: Nginx Pod with dynamic storage class openebs-hostpath:

Nginx.yaml

kind: Pod
apiVersion: v1
metadata:
  name: nginx-pod
spec:
  volumes:
    - name: openebs-hostpath
      persistentVolumeClaim:
       claimName: openebs-hostpath
  containers:
    - name: nginx
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: openebs-hostpath

---

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: openebs-hostpath
spec:
  storageClassName: openebs-hostpath
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi

kubectl create -f nginx.yaml

Congratulations you have successfully tested our first app using openEBS dynamic local PV.

That’s all for now, I will follow it up with more knowledge on this topic next time.

Thank you for sticking to the end. If you like this blog, please do show your appreciation by giving thumbs-ups and share this blog and give me suggestions on how I can improve my future posts to suit your needs. Follow me to get updates on different technologies