Project reference ↗

Databases and other stateful applications need their files to survive replacement of an application pod. OpenEBS supplies Kubernetes storage engines that create and manage persistent volumes, with options for local disks and for replication across machines. The engine you choose determines where data lives, how it is protected and what happens when a worker fails. Treat those as separate storage designs: an OpenEBS volume is not automatically replicated simply because the project offers a replicated engine.

Current guidance

Current OpenEBS documentation distinguishes local volumes from replicated volumes. The project’s 2024 deprecation announcement moved legacy engines including Jiva and cStor into openebs-archive, while identifying HostPath, LVM, ZFS and Mayastor as the continuing core. This is not retirement of OpenEBS as a whole.

Identify the actual StorageClass provisioner and engine behind every volume before an upgrade. A local volume remains tied to one node, whereas replicated storage has a different data path and hardware requirements. The old generic iSCSI prerequisite should not be applied to every current engine; current replicated storage documentation describes NVMe over TCP.

Check migration guidance for the specific source and target engine and preserve an independent application-consistent backup. Changing a StorageClass name does not copy existing volume data or convert its format. Test restoration, node loss and scheduling constraints with representative stateful workloads, including the application’s own replication behavior. The project announcement says legacy deployments can continue running, but they are excluded from the new installer. This review does not promise an in-place conversion or certify durability for an untested topology.

Historical upstream link check · 2026-10-09

The recorded upstream address redirects to https://openebs.io/ and returned HTTP 200 on 2026-10-09. Link availability does not certify the historical installation instructions or current security support.

Source for this check ↗

Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.

The original record

Historical Kubedex content

Original publication: 2018-09-15T14:55:01+00:00. Preserved for context. Commands, versions, prices and results below reflect the original research.

OpenEBS is an open source storage platform that provides persistent and containerized block storage for DevOps and container environments.

OpenEBS can be deployed on any Kubernetes cluster – either in the cloud, on-premise or developer laptop (minikube). OpenEBS itself is deployed as just another container on your cluster and enables storage services that can be designated on a per pod, application, cluster or container level.
You can say:

  • OpenEBS is the most active Cloud Native Containerized Storage project
  • OpenEBS enables your DevOps teams to have their own storage policies for workloads
  • OpenEBS is not Yet Another Scale-out Storage System (!YASSS)
  • OpenEBS is tightly integrated with Kubernetes and is a part of Kubernetes-Incubator project

Prerequisites

  • Kubernetes 1.7.5+ with RBAC enabled
  • iSCSI PV support in the underlying infrastructure

Features:

Containerized Storage for Containers

Your storage controller is a container that follows around your workloads, very different than Yet Another Scale-out Storage System (“!YASSS”)

Prometheus metrics and Grafana graphs

Granular monitoring through Prometheus and Grafana

Improves EBS & other cloud storage

Runs on top of EBS to improve resiliency, to limit lock-in, and for better integration with Kubernetes

Granular Control

Each workload and hence, each team working on dynamic container based workloads has their own storage, instead of being managed by the central storage

Written in GO

OpenEBS is the only broadly adopted open source block storage written mostly in Go

Avoid cloud lock-in

When you write your data to OpenEBS you write to an open source, highly flexible data management layer that allows you to manage your exposure to each cloud or data center

What does it allow?

OpenEBS enables the use of containers for mission-critical, persistent workloads. OpenEBS is containerized storage and related storage services.

OpenEBS allows you to treat your persistent workload containers, such as DBs on containers, just like other containers. OpenEBS itself is deployed as just another container on your host and enables storage services that can be designated on a per pod, application, cluster or container level, including:

  • Data persistence across nodes, dramatically reducing time spent rebuilding Cassandra rings for example.
  • Synchronization of data across availability zones and cloud providers.
  • Use of commodity hardware plus a container engine to deliver so called container attached block storage.
  • Integration with Kubernetes, so developer and application intent flows into OpenEBS configurations automatically.
  • Management of tiering to and from S3 and other targets.

Why OpenEBS Scales

OpenEBS can scale to include an arbitrarily large number of containerized storage controllers. Thanks in part to some advancements in the metadata management which remove a common bottleneck to scaling out storage performance.

Why would you use OpenEBS on EBS?

There are at least four common reasons given for running OpenEBS on Amazon EBS:

  • Attach / detach: The attach / detach process can slow the operation of environments dependent upon EBS.
  • No volume management needed: OpenEBS removes the need for volume management, enabling the combination of multiple underlying EBS volumes without the user needing to run LVM or other volume manager. This saves time and reduces operational complexity.
  • Expansion and inclusion of NVMe: OpenEBS allows users to add additional capacity without experiencing downtime. This online addition of capacity can include NVMe and SSD instances from cloud providers or deployed in physical servers. This means that as performance requirements increase, or decrease, Kubernetes can be used via storage policies to instruct OpenEBS to change capacity accordingly.
  • Other enterprise capabilities: OpenEBS adds other capabilities such as extremely efficient snapshots and clones as well as forthcoming capabilities such as encryption. Snapshots and clones facilitate much more efficient CI/CD workflows because zero space copies of databases and other stateful workloads can be used in these and other workflows, improving these workflows without incurring additional storage space or administrative effort. The snapshot capabilities can also be used for replication. As of February 2018 these replication capabilities are under development.

The post OpenEBS appeared first on kubedex.com.

Sources & further reading

  1. Current OpenEBS local and replicated architecture
  2. Maintainer legacy-engine deprecation announcement
  3. Recovered historical source

Spotted something that needs another look?

Help improve this page →