This guide will help you to customize and install OpenEBS.
If this is your first time installing OpenEBS, make sure that your Kubernetes nodes meet the required prerequisites. At a high level OpenEBS requires:
- Verify that you have the admin context. If you do not have admin permissions to your cluster, please check with your Kubernetes cluster administrator to help with installing OpenEBS or if you are the owner of the cluster, check out the steps to create a new admin context and use it for installing OpenEBS.
- You have Kubernetes 1.18 version or higher.
- Each storage engine may have few additional requirements like having:
- iSCSI initiator utils installed for Jiva and cStor volumes
- Depending on the managed Kubernetes platform like Rancher or MicroK8s - set up the right bind mounts
- Decide which of the devices on the nodes should be used by OpenEBS or if you need to create LVM Volume Groups or ZFS Pools
- Join OpenEBS community on Kubernetes slack.
Verify helm is installed and helm repo is updated. You need helm 3.2 or more.
Setup helm repository
OpenEBS provides several options that you can customize during install like:
- specifying the directory where hostpath volume data is stored or
- specifying the nodes on which OpenEBS components should be deployed, and so forth.
The default OpenEBS helm chart will only install Local PV hostpath and Jiva data engines. Please refer to OpenEBS helm chart documentation for full list of customizable options and using cStor and other flavors of OpenEBS data engines by setting the correct helm values.
Install OpenEBS helm chart with default values.
The above commands will install OpenEBS Jiva and Local PV components in
openebs namespace and chart name as
openebs. To install and enable other engines you can modified the above command as follows:
- cStor helm install openebs --namespace openebs openebs/openebs --create-namespace --set cstor.enabled=true
To view the chart
OpenEBS provides a list of YAMLs that will allow you to easily customize and run OpenEBS in your Kubernetes cluster. For custom installation, download the openebs-operator YAML file, update the configurations and use the customized YAML for installation in the below
To continue with default installation mode, use the following command to install OpenEBS. OpenEBS is installed in
The above command installs Jiva and Local PV components. To install and enable other engines you will need to run additional command like:
- cStor kubectl apply -f https://openebs.github.io/charts/cstor-operator.yaml
- Local PV ZFSkubectl apply -f https://openebs.github.io/charts/zfs-operator.yaml
- Local PV LVMkubectl apply -f https://openebs.github.io/charts/lvm-operator.yaml
List the pods in
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 nodeSelector configuration.
The control plane pods
openebs-snapshot-operator should be running. If you have configured nodeSelectors , 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.
In the successful installation, you should have the following StorageClasses are created.
For testing your OpenEBS installation, you can use the below default storage classes
openebs-jiva-defaultfor provisioning Jiva Volume (this uses
defaultpool which means the data replicas are created in the /var/openebs/ directory of the Jiva replica pod)
openebs-hostpathfor provisioning Local PV on hostpath.
You can follow through the below user guides for each of the engines to use storage devices available on the nodes instead of the
/var/openebs directory to save the data.
For installation of OpenEBS, cluster-admin user context is a must. OpenEBS installs service accounts and custom resource definitions that are only allowed for cluster administrators.
kubectl auth can-i commands to verify that you have the cluster-admin context. You can use the following commands to verify if you have access:
If there is no cluster-admin user context already present, create one and use it. Use the following command to create the new context.
Set the existing cluster-admin user context or the newly created context by using the following command.