OpenEBS is the leading open-source project for container-attached and container-native storage on Kubernetes. OpenEBS adopts Container Attached Storage (CAS) approach, where each workload is provided with a dedicated storage controller. OpenEBS implements granular storage policies and isolation that enable users to optimize storage for each specific workload. OpenEBS is built completely in userspace making it highly portable to run across any OS/platform.
OpenEBS is a collection Storage Engines, allowing you to pick the right storage solution for your Stateful workloads and the type of Kubernetes platform.
When using synchronous replication, iSCSI is used to attach storage from OpenEBS to application pods. Hence OpenEBS requires iSCSI client to be configured and
iscsidservice running on the worker nodes. Verify if iSCSI service is up and running before starting the installation.
Default installation works in most of the cases. As a Kubernetes cluster-admin, start the default installation using either
helm repo add openebs https://openebs.github.io/charts helm repo update helm install --namespace openebs --name openebs openebs/openebs
More information about OpenEBS installation using different Helm versions can be found here.
kubectl apply -f https://openebs.github.io/charts/openebs-operator.yaml
For advanced installation steps, see Installation section.
Verify if OpenEBS is installed successfully and start provisioning OpenEBS volumes through Kubernetes PVC interface by using
OpenEBS Storage Engines
OpenEBS is a Kubernetes native hyperconverged storage solution. OpenEBS consumes the storage (disks, SSDs, cloud volumes, etc) available on the Kubernetes worker nodes to dynamically provision Kubernetes Persistent Volumes.
OpenEBS can provision different type of Local PV for Stateful Workloads like Cassandra, MongoDB, Elastic, etc that are distributed in nature and have high availiability built into them. Depending on the type of storage attached to your Kubernetes worker nodes, you can select from Dynamic Local PV - Hostpath, Device, ZFS or Rawfile.
OpenEBS can provision Persistent Volumes with features like synchronous replication, snapshots and clones, backup and restore that can be used with Stateful workloads like Percona/MySQL, Jira, GitLab, etc. The replication also can be setup to be across Kubernetes zones resulting in high availability for cross AZ setups. Depending on the type of storage attached to your Kubernetes worker nodes and application performance requirements, you can select from Jiva, cStor or Mayastor.
See the following table for recommendation on which engine is right for you depending on the type of your application requirements and storage available on your Kubernetes nodes.
|Application requirements||Storage||OpenEBS Volumes|
|Protect against node failures, Synchronous replication, Snapshots, Clones, Thin provisioning||Use Disks/SSDs/Cloud Volumes||OpenEBS cStor|
|Protect against node failures, Synchronous replication, Thin provisioning||Use hostpath or external mounted storage||OpenEBS Jiva|
|Low latency, Local PV||Use hostpath or external mounted storage||Dynamic Local PV - Hostpath|
|Low latency, Local PV||Use Disks/SSDs/Cloud Volumes||Dynamic Local PV - Device|
|Low latency, Local PV, Snapshots, Clones||Use Disks/SSDs/Cloud Volumes||OpenEBS Dynamic Local PV - ZFS|