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:
- 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.
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.
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
kubectl apply -f https://openebs.github.io/charts/openebs-operator-1.0.0.yaml
Verifying OpenEBS installation
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
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
1 thought on “OpenEBS – Container Attached Storage (CAS)6 min read”
Note: iscsi-utils are not required for localpv, it’s only used for cstor and jiva storage engines.
Comments are closed.