Welcome to OpenEBS Documentation

Welcome to OpenEBS Documentation

Documentation for OpenEBS v2.1.0 is no longer actively maintained. The version you are currently viewing is a static snapshot. Click here for the latest version.

Introduction

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.

See OpenEBS Features & Benefits and OpenEBS Adoption stories.

Quickstart

When using synchronous replication, iSCSI is used to attach storage from OpenEBS to application pods. Hence OpenEBS requires iSCSI client to be configured and iscsid service 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.

(or)
```
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 kubectl command.

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