v1.0
Managed Kubernetes
K8s Basics
PMK Onboarding
Networking / Ingress
Data Services
Automating PMK
Troubleshooting

How to Deploy an OpenEBS Backend for your Kubernetes Cluster

Overview

In this tutorial, we will walk through the step by step process to install and configure OpenEBS as a storage backend for your Kubernetes cluster.

OpenEBS is one of the leading open-source projects for cloud-native storage for Kubernetes. OpenEBS adopts the Container Attached Storage (CAS) standard, where each workload is provided with a dedicated storage controller.

OpenEBS provides granular policies per stateful workload, high availability, native HCI on Kubernetes, and several other benefits. Since it’s open-source and built completely in userspace, it is highly portable to run across any operating system / platform and positions itself well as a cloud-native technology that allows you to build a stack that is cloud-vendor agnostic. It is also completely intent-driven, inheriting the same principles that drive the ease of use with Kubernetes.

We will be using a Platform9 Managed Kubernetes Free Tier Kubernetes cluster for this tutorial, however you can use this tutorial to configure OpenEBS on any other Kubernetes cluster of your choice.

Prerequisites

  • A valid Kubernetes cluster. You can create one quickly for free using Platform9 Managed Kubernetes. Signup for a Free PMK Account Here and create your Kubernetes cluster using PMK. You can also use this guide on any other Kubernetes cluster you may have.
  • A Kubectl installation with your Kubernetes cluster from the step above configured as the primary cluster.
  • The helm 3 package manager client installed on your local machine. Follow our tutorial here to install Helm CLI on your machine.
  • Ensure that you have cluster admin-context before proceeding to Installation steps.
  • The cluster should be configured to run the containers in Privileged mode. For a PMK cluster, this is done by clicking on the Privileged checkbox during cluster creation.

Step 1 - Install iSCSI

Before installing OpenEBS, you first need to installiscsirelated packages on all the Kubernetes cluster nodes. For Ubuntu 18+ nodes, here are the steps:

Bash
Copy

To ensure that iscsi services are functioning correctly, check the output of the following commands:

Bash
Copy

For CentOS/RedHat based nodes, here are the steps to install iscsi packages:

Bash
Copy

To ensure that iscsi services are functioning correctly, check the output of the following commands –

Bash
Copy

For any other operating systems, follow the steps mentioned here for each of the operating systems/cloud providers.

Step 2 - Install OpenEBS

You can either choose to deploy OpenEBS components in the default namespace on your Kubernetes cluster, or in a custom namespace created specifically for OpenEBS related pods. The latter is the recommended option, and is what we will do in this guide.

Bash
Copy

Next we will add the OpenEBS repository to our Helm 3 package manager and then deploy the associated Helm chart, all using the Helm CLI client.

Bash
Copy

This would install the OpenEBS pods with the default settings, you can modify the helm chart values by referring to the Custom Installation Mode Section

Step 3 - Verify Installation

Ensure that all the pods in the openebs namespace are in a Running state

Bash
Copy

Output

Bash
Copy

Ensure that default storage classes have been created.

Bash
Copy

NDM daemon set creates a Kubernetes block device custom resource for each block device that is discovered on your Kubernetes cluster node with two exceptions

  1. The disks that match the exclusions in ‘vendor-filter’ and ‘path-filter’
  2. The disks that are already mounted in the node

Following command lists the custom resource blockdevice

Bash
Copy

Step 4 - Deploy cStor Pools & Storage Class

cStor is the recommended option to get additional workload resiliency via OpenEBS. It provides enterprise-ready features such as synchronous data replication, snapshots, clones, thin provisioning of data, high resiliency of data, data consistency and on-demand increase of capacity or performance

The core function of cStor is to provide iSCSI block storage using the locally attached disks/cloud volumes.

Additional details can be found here.

We have to provide the list of blockdevices that we acquired in the output above for creating a cStor storage pool.

A sample yaml file is already present in the ./openEBS/yaml folder of the OpenEBS repo. Please clone the repo for using it. You will have to edit the yaml file and add the blockdevices as seen in the command below:

Bash
Copy

After updating the cstor.yaml with the relevant blockdevices observed in your environment, run the following command:

Bash
Copy

PoolType selected is striped in this case. The available options are striped, mirrored, raidz and raidz2.

For further information on the type of Storage Pools, please refer to the link here.

There’s an example yaml available for deploying a cStor backed storage class so you can deploy PVs/PVCs associated with it.

The replicaCount in it is set to 1 currently, but you can tweak it as per your needs. If the application handles replication itself, then its recommended to keep the replicaCount to 1.

Run the following command to deploy the StorageClass:

Bash
Copy

Once deployed you can use the new cStor storageClass to provision Kubernetes Persistent Volumes (PVs) and the associated Persistent Volume Claims (PVCs) for deploying your application workloads.

References

https://docs.openebs.io/docs/next/features.html

  Last updated