OpenEBS — Leading Open Source Container-Attached Storage

What it is

OpenEBS is a CNCF sandbox storage project that delivers container-attached storage (CAS) for Kubernetes. Instead of a monolithic storage appliance, OpenEBS runs storage controllers as microservices alongside your application pods. It supports multiple storage engines -- Local PV for high-performance local disks, Replicated Mayastor for NVMe-optimized replication, cStor for legacy flexibility, and Jiva for simple iSCSI-based replication.

It is designed for platform engineers, DevOps teams, and Kubernetes operators who need persistent storage without vendor lock-in.

How it saves time or tokens

OpenEBS eliminates the need to provision and manage external storage arrays. Storage is declaratively configured via Kubernetes StorageClasses, so developers request volumes the same way they request any other Kubernetes resource. The per-workload engine selection means you do not over-provision: low-latency workloads get Local PV, while stateful apps needing replication get Mayastor or cStor.

How to use

1. Install OpenEBS via Helm chart or kubectl apply on your Kubernetes cluster.
2. Create a StorageClass selecting the desired engine (e.g., openebs-hostpath for Local PV or openebs-cstor for replicated storage).
3. Deploy your application with a PersistentVolumeClaim referencing the StorageClass.

Example

# StorageClass for OpenEBS Local PV hostpath
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: openebs-hostpath
provisioner: openebs.io/local
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
---
# PVC using OpenEBS
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-app-data
spec:
  accessModes: [ReadWriteOnce]
  storageClassName: openebs-hostpath
  resources:
    requests:
      storage: 10Gi

Related on TokRepo

• DevOps AI tools -- More infrastructure and DevOps tooling curated on TokRepo.
• Self-hosted solutions -- Browse self-hosted alternatives for cloud-native stacks.

Common pitfalls

• Choosing Mayastor without NVMe-capable disks results in poor performance. Verify your nodes have NVMe SSDs before selecting this engine.
• Local PV volumes are node-bound. If the node goes down, the data is inaccessible until the node recovers.
• Running multiple OpenEBS engines simultaneously increases control-plane resource usage. Pick one engine per cluster unless you have distinct workload tiers.
• Forgetting to set volumeBindingMode: WaitForFirstConsumer on Local PV StorageClasses causes scheduling conflicts.
• cStor pool configuration requires dedicated block devices; sharing a device with the OS root filesystem will cause data loss.