2.3.0
EditCreate An Issue

Welcome to OpenEBS Documentation

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 requirementsStorageOpenEBS Volumes
Protect against node failures, Synchronous replication, Snapshots, Clones, Thin provisioningUse Disks/SSDs/Cloud VolumesOpenEBS cStor
Protect against node failures, Synchronous replication, Thin provisioningUse hostpath or external mounted storageOpenEBS Jiva
Low latency, Local PVUse hostpath or external mounted storageDynamic Local PV - Hostpath
Low latency, Local PVUse Disks/SSDs/Cloud VolumesDynamic Local PV - Device
Low latency, Local PV, Snapshots, ClonesUse Disks/SSDs/Cloud VolumesOpenEBS Dynamic Local PV - ZFS

OpenEBS is also developing Mayastor and Dynamic Local PV - Rawfile storage engines available for alpha testing.

Explore documentation



Run stateful applications on OpenEBS







See Also:

Container Attached Storage (CAS)

CNCF CAS Blog

OpenEBS architecture



Feedback

Was this page helpful?

OpenEBS Features and Benefits →