Skip to content

Latest commit

 

History

History
137 lines (78 loc) · 11.2 KB

openebs.adoc

File metadata and controls

137 lines (78 loc) · 11.2 KB
Raw

OpenEBS CNCF Sandbox Project Proposal

Name of Project: OpenEBS

Description:

OpenEBS is the most widely deployed open source example of a category of storage solutions sometimes called Container Attached Storage; other solutions with a similar architecture to date have been proprietary systems. As such OpenEBS is in some ways analogous to other infrastructure components that have been refactored with the help of Kubernetes, such as Calico or OpenDNS, and is additive to underlying storage whether provided by cloud volumes or traditional storage systems; OpenEBS can also deliver storage services using locally attached disk for example in the case of a bare metal Kubernetes solution running at the edge (a common use case).

At the highest level the idea of OpenEBS and Container Attached Storage is to:

  • Use Kubernetes itself to deliver storage and related data management services to workloads running on Kubernetes. OpenEBS is deployed as a set of containers on Kubernetes worker nodes. Many of the benefits of OpenEBS result from it being built upon Kubernetes. These include of course it being familiar in design and operations to other Kubernetes based solutions; if you know how to run Kubernetes, you already know how to run OpenEBS.

  • Avoid dependencies on the kernel. OpenEBS storage containers completely run in userspace allowing OpenEBS to run on any OS/Platform, across any cloud or on-prem environment.

  • Respond to changing requirements from applications and workloads. Certain applications and their operators now handle features that were traditionally offloaded to storage systems such as high availability; these applications, such as many NoSql or so called NewSQL databases, require the underlying storage to provide only complementary features - like snapshots and clones or underlying device management. In part because OpenEBS is implemented using loosely coupled microservices, it can be optimized for the specific needs and requirements of a given application.

The benefits of OpenEBS include: greater granularity of control for each team running workloads; improved ease of use (for example <10 second deployments are typical); better understanding of behavior thanks to being Kubernetes native as opposed to an external system with other scaling and operational characteristics; and additional freedom from lock-in to underlying cloud or on premises storage and database services thanks to running consistently across any underlying Kubernetes and storage technologies.

Capabilities include:

  • Complete deployment within seconds, allowing existing Kubernetes deployments to be quickly converted into a storage platform

  • A common developer and user experience irrespective of whether Kubernetes is running on IaaS or hosted Kubernetes services or on-premises and whether the underlying storage media is bare metal, storage services, or storage systems such as a SAN

  • Provide RWO Volumes to Stateful workloads using the storage available on the Kubernetes nodes. If needed, RWM Volumes are provided by using NFS on top of OpenEBS.

  • Optional High Availability, snapshots, clones and similar enterprise class storage features. For example the use of OpenEBS under CI/CD tools is common to improve developer productivity on Kubernetes by providing a snapshot of a faulted workload for further investigation. Additionally asynchronous replication or backup can be achieved by using Kubernetes native tools like Velero.

  • Tight integration with Kubernetes, so developer and application intent flows into OpenEBS configurations automatically

The architecture of OpenEBS is container native and horizontally scalable. OpenEBS is a collection of different microservices that can be grouped into 3 major areas (or planes):

Data Engines or the Data Plane

The data engines are the containers responsible for interfacing with the underlying storage devices such as host filesystem, rotational drives, SSDs or NVMe devices and cloud volumes and attached disks. Volume capabilities can be optimized based on the workload they serve. Depending on the capabilities requested, OpenEBS selects different data engines like cStor (CoW based) or Jiva or even Local PVs for a given volume.

If selected, high availability is achieved by abstracting the access to the volume into the target container - which in turn does the synchronous replication to multiple different replica containers. These replica containers save the data to the underlying storage devices or services. If a node serving the application container and the target container fails, the application and target are rescheduled to a new node. The target connects with the other available replicas and provides IO access to the data.

Storage Management or Control Plane:

The Storage Management or Control Plane is responsible for interfacing between Kubernetes (Volume/CSI interface) and managing the Volumes created using the OpenEBS Data Engines. The Storage Management Plane is implemented using a set of containers that are either running at the cluster level or the node level. Some of the storage management options are also provided by containers running as side-cars to the data engine containers.

The storage management containers are responsible for providing APIs for gathering details about the volumes. The APIs can be used by Kubernetes provisioners for managing volumes, snapshots, backups, so forth; used by Prometheus to collect metrics of volumes; used by custom programs such as a CLI or UI to provide insights into the OpenEBS Storage status or management.

Storage Device Management Plane:

While this plane is an integral part of the OpenEBS Storage Management Plane, the containers and custom resources under this plane can be used by other projects that require a Kubernetes native way of managing the Storage Devices (rotational drives, SSDs and NVMe, etc) attached to Kubernetes nodes. This is one motivation for contributing OpenEBS to the CNCF as non MayaData storage projects have expressed interest in using at least this component of OpenEBS for their own solutions. At least one external storage system manufacturer is contributing to this component of OpenEBS.

The Storage Device Management Plane can be viewed as an inventory management tool, that discovers devices and keeps track of their usage via device claims (akin to PV/PVC concept). All the operations like device listing, identifying the topology or details of a specific device can be accessed via kubectl and kubernetes custom resources. SMARTS data on disk drive behavior is made available as well.

Statement on alignment with CNCF mission:

The primary purpose of this submission is to enable broader collaboration thanks to the role of the CNCF as a neutral home for open source projects that add value to the overall cloud native ecosystem. In particular as OpenEBS and OpenEBS components appear to be of interest to multiple otherwise competitive technology and service providers, the independence of governance of the CNCF seems likely to unlock additional innovation and collaboration.

OpenEBS is aligned with our understanding of the CNCF mission.

  • Extensible and open architecture based upon Kubernetes

  • Horizontally scalable with Kubernetes nodes

  • Integrated with other CNCF projects like Kubernetes, Prometheus, etcd, and others

  • Additionally, the OpenEBS community attempts to be extremely inclusive and is one of the more active CNCF related projects in India, actively working with technical universities to introduce interested students to Open Source practices and projects, including OpenEBS, Prometheus, WeaveWorks, Litmus (also sponsored by MayaData for chaos engineering and end to end testing) and other projects.

We hope to continue to broaden OpenSource understanding and adoption and believe that OpenEBS becoming a part of the CNCF will further these objectives.

Sponsors from TOC: Xiang Li, Alexis Richardson

Preferred maturity level: Sandbox

License: Apache License v2.0

Source control and External Dependencies:

OpenEBS Source code is split across multiple repositories, some of which are listed below. The complete details of the repositories and their dependencies can be found in: https://github.com/openebs/openebs/blob/master/contribute/design/README.md

Initial Committers and Founding Maintainers:

  • Kiran Mova @kmova (MayaData) (Since Dec 2016)

  • Amit Kumar Das @AmitKumarDas (MayaData) (Since Dec 2016)

  • Karthik Satchitanand @ksatchit (MayaData) (Since May 2017)

Additional Maintainers:

  • Murat Karslioglu @muratkars (MayaData) (Since Oct 2017)

  • Jeffry Molanus @gila (MayaData) (Since Oct 2017)

  • Vishnu Itta @vishnuitta (MayaData) (Since Oct 2017)

  • Richard Elling @richardelling (Viking Enterprise Solutions a division of Sanmina Corporation) (Since Nov 2018)

Infrastructure requests (CI / CNCF Cluster):

Development needs:

none in the short term. We currently use Travis CI, but we may want to use CNCF resources to deploy Jenkins for node E2E test.

We have also started an E2E and chaos engineering project called Litmus that we intend to continue to use to accelerate the maturity of OpenEBS and that is increasingly used by solution providers and other Kubernetes experts to characterize the behavior of underlying Kubernetes environments under various scenarios. Currently we test every commit to master against a number of platforms and environments in an approach that was inspired by the CNCF test environment and can be found at https://openebs.ci/

Production needs:

none

Communication Channels:

Release methodology and mechanics:

The release happens based on the features and user issues reported on the GitHub. GitHub Milestones and Weekly Contributor Meetings are used to groom the items included in to a release.

OpenEBS uses semantic versioning for releases. The Releases are triggered using GitHub releases. The continuous integration system, currently TravisCI, builds docker images and executes unit/system tests before pushing to docker repositories. The docker images are placed in Quay and DockerHub.

Before every release, we tag several RC releases that are then put through automated and manual testing on various Kubernetes flavors; results are published under openebs.ci

Currently we do feature releases 3-4 times per year (all with minor releases).

Social media accounts:

Existing sponsorship: MayaData

Community size: