DOCSEARCHbyAlgolia
Submit Docs

OpenEBS Documentation

website·Indexed 35 days ago

https://openebs.io/docs

Documentation for OpenEBS container attached storage, covering versions 4.0.x through 4.6.x and main. Includes guides for Replicated PV Mayastor, Local PV LVM, and NFS PVCs, as well as troubleshooting for Persistent Volume Claims (PVC) in Pending state, installation failures, and disk pool management.

Tokens
1.3M
Snippets
5.5K
Records
8.8K
Agent score
54%

What's inside OpenEBS

  1. Overview of OpenEBS Local PV Device volumes

    OpenEBS Local PV Device volumes allow Kubernetes to use block devices available on a node (such as SSDs, NVMe, Hard Disks, Cloud Provider Disks like EBS/GPD, or Virtual Disks like vSAN/VMDK) to persist data. Unlike native Kubernetes Local PVs, OpenEBS provides a dynamic volume provisioner and the Node Disk Manager (NDM) for discovering block device properties, setting device filters, collecting metrics, and detecting device movement across nodes. It utilizes Kubernetes volume topology aware pod scheduling.

  2. Overview of OpenEBS Container Native Storage

    OpenEBS is an open-source storage solution that converts any storage available on Kubernetes worker nodes into Local or Replicated Kubernetes Persistent Volumes. It is designed for stateful workloads requiring fast, durable, and scalable storage, and is particularly optimized for NVMe-based deployments. Because the data engines are implemented in user space, OpenEBS is compatible with any Kubernetes platform and can be managed using standard tools like kubectl, Helm, Prometheus, and Grafana.

  3. Overview of OpenEBS Container Attached Storage

    OpenEBS is a CNCF sandbox project that transforms any storage available on Kubernetes worker nodes into Local or Distributed (Replicated) Persistent Volumes. It is designed for stateful workloads requiring fast, durable, and scalable storage, and is particularly optimized for NVMe-based deployments. Because it is implemented in user space as a set of micro-services orchestrated by Kubernetes, it can be managed using standard tools like kubectl, Helm, Prometheus, and Grafana.

  4. Overview of OpenEBS components and their versions (v3.1.x)

    OpenEBS consists of several data engines, provisioners, and utility components. The following versions are associated with the 3.1.x release cycle:

    • Data Engines: Jiva 3.1.0 (stable), cStor 3.1.0 (stable)
    • CSI Provisioners: cStor 3.1.0 (stable), Local PV ZFS 2.0.0 (stable), Local PV LVM 0.8.3 (stable), Local PV Rawfile 0.6.0 (beta), Jiva 3.1.0 (beta), Mayastor 0.8.1 (beta), Local PV Partitions 0.6.0 (alpha)
    • Out-of-tree Provisioners: Local PV hostpath 3.1.0 (stable), Local PV device 3.1.0 (stable), Dynamic NFS Volume 0.9.0 (beta)
    • Other Components: NDM 1.8.0 (beta), Upgrade and Migration Tools 3.1.0 (beta), CLI 0.5.0 (beta), Dashboard 0.4.10 (beta)

  5. Overview of OpenEBS Container Attached Storage

    OpenEBS is a CNCF sandbox project that turns storage available on Kubernetes worker nodes into Local or Distributed (Replicated) Persistent Volumes. It implements a Container Attached Storage (CAS) model where data engines and the control plane are deployed as Kubernetes micro-services in user space. This allows it to run on any Kubernetes platform and be managed using standard tools like kubectl, Helm, Prometheus, and Grafana.

  6. Overview of RWX shared storage using OpenEBS and NFS

    To provide ReadWriteMany (RWX) shared storage for multiple applications, OpenEBS utilizes the NFS server provisioner (maintained by Kubernetes SIGs). In this architecture, OpenEBS cStor volumes serve as the persistent backend storage for the NFS servers. This setup allows for replicated, highly available data across zones and thin provisioning, where cStor physical pools can grow as storage is consumed.

  7. Overview of Replicated PV Mayastor Interrupt Mode

    Interrupt Mode is an optional reactor operating mode for Replicated PV Mayastor designed to reduce CPU utilization during periods of low or idle I/O activity. By default, io-engine reactors continuously poll for I/O events, which consumes significant CPU. When Interrupt Mode is enabled, reactors transition to an event-driven model, sleeping while waiting for work and waking only when events occur.

    Key Trade-offs:

    • Benefit: Significantly lower CPU consumption during idle periods.
    • Cost: Increased I/O latency and reduced peak throughput.

    Critical Constraints:

    • Experimental: This is an experimental feature; evaluate thoroughly in non-production environments before deploying to production.
    • RDMA Incompatibility: Interrupt Mode has not been validated for RDMA configurations. Use the default polling mode if your deployment uses RDMA.

  8. Overview of OpenEBS Local PV ZFS

    OpenEBS Local PV ZFS uses the ZFS file system to manage persistent volumes. It provisions volumes from ZFS datasets configured on each node, providing high performance and enterprise-grade data services. Key advantages include built-in data integrity checks to prevent silent corruption, support for snapshots and clones for backups/testing, and storage optimization via compression and deduplication. It is particularly suited for databases and critical stateful applications.

  9. Overview of OpenEBS Cloud Native Storage

    OpenEBS is a cloud-native storage solution for stateful applications on Kubernetes. It employs a loosely coupled, micro-services architecture where the storage system itself is deployed as containers on Kubernetes worker nodes and managed by the Kubernetes orchestrator. Key characteristics include:

    • Userspace Implementation: Built completely in userspace for high portability across different operating systems and platforms.
    • Intent-Driven: Follows Kubernetes principles for ease of use and configuration.
    • Flexible Storage Engines: Supports multiple engines to match application needs (e.g., Local Storage for low-latency writes in Cassandra, or Replicated Storage for resilience in MongoDB and PostgreSQL).

  10. Overview of OpenEBS Cloud Native Storage

    OpenEBS is a loosely coupled, cloud-native storage solution for stateful applications on Kubernetes. It is deployed as a set of containers on Kubernetes worker nodes and uses the Kubernetes control plane for orchestration and management. Because it is built completely in userspace, it is portable across different operating systems and platforms.

  11. Overview of OpenEBS Local PV Rawfile

    OpenEBS Local PV Rawfile provisions persistent volumes backed by raw files on the host filesystem. These files are exposed to pods as independent block devices via Linux loop devices. Each volume is formatted with its own filesystem (supporting ext4, btrfs, or xfs), ensuring full isolation from the host's filesystem. This architecture provides near-baremetal disk performance, hard-enforced capacity limits, and real-time volume metrics, overcoming the limitations typically associated with HostPath-based provisioning.

  12. Overview of OpenEBS cStor Architecture

    cStor is a lightweight, feature-rich storage engine for OpenEBS that serves iSCSI block storage using underlying disks or cloud volumes. It provides enterprise features including synchronous data replication, snapshots, clones, thin provisioning, and on-demand capacity increases.

    cStor consists of two primary components:

    1. cStor Pool Pods: Responsible for persisting data to disks. They manage volume replicas, snapshots, and clones. A set of these pods across nodes forms a Storage Pool.
    2. cStor Target Pods: Provisioned per volume to expose an iSCSI LUN on port 3260. The target pod handles synchronous replication and quorum management, passing data from workloads to the respective volume replicas in the cStor Pools.