OpenEBS

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.