OpenEBS und Longhorn bieten Container-Attached Storage für Kubernetes — aber mit verschiedenen Ansätzen. Welcher passt besser zu deinem Cluster?

OpenEBS vs Longhorn: Container-Attached Storage für Kubernetes im Vergleich 2026

Persistenter Storage ist eines der komplexesten Themen bei Kubernetes-Betrieb. Während Cloud-Provider fertige StorageClasses für Managed Volumes liefern, brauchen On-Premises-Cluster und Homelab-Setups eine eigene Lösung. OpenEBS und Longhorn sind die bekanntesten Open-Source-Optionen für Container-Attached Storage (CAS) — beide mit völlig unterschiedlicher Architektur.

Was ist Container-Attached Storage?

Beim CAS-Ansatz läuft die Storage-Engine selbst als Container im Kubernetes-Cluster. Statt einem externen SAN oder NAS nutzen die Pods den lokalen Disk-Space der Kubernetes-Nodes — verwaltet, repliziert und abstrahiert durch eine eigene Storage-Plane.

Vorteile:

Keine externe Storage-Abhängigkeit
Automatische Replikation über Nodes hinweg
Kubernetes-native Verwaltung (StorageClasses, PVCs)
Günstiger (kein teures SAN nötig)

Nachteile gegenüber Cloud-Storage:

Mehr Operationsaufwand
Performance hängt von lokaler Disk-Hardware ab
Netzwerk-Overhead durch Replikation

Longhorn: Bewährter Einstieg von Rancher

Longhorn wurde von Rancher entwickelt (jetzt CNCF incubating) und gilt als der zugänglichste Einstieg in On-Premises-Storage für Kubernetes. Es nutzt iSCSI und NFS unter der Haube, abstrahiert das aber vollständig hinter einer einfachen UI und Kubernetes-StorageClass.

Installation

# Voraussetzungen prüfen
curl -sSfL https://raw.githubusercontent.com/longhorn/longhorn/master/scripts/environment_check.sh | bash

# Helm-Installation
helm repo add longhorn https://charts.longhorn.io
helm repo update
helm install longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --create-namespace \
  --set defaultSettings.defaultReplicaCount=3

StorageClass erstellen

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: longhorn-3-replicas
provisioner: driver.longhorn.io
allowVolumeExpansion: true
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "2880"
  fsType: ext4

PVC anlegen

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-database-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn-3-replicas
  resources:
    requests:
      storage: 20Gi

Longhorn repliziert Volumes automatisch über die konfigurierten Replica-Nodes. Im Dashboard lässt sich der Status jeder Replica grafisch verfolgen.

Backup und Snapshots

Longhorn bietet eingebaute Snapshot- und Backup-Funktionalität — sowohl in ein S3-kompatibles Ziel als auch in NFS:

# Backup-Target für MinIO
kubectl -n longhorn-system edit setting backup-target
# Wert: s3://my-longhorn-backup@us-east-1/
# Backup-Target-Credentials als Secret angeben

OpenEBS: Modulare Storage-Engine

OpenEBS ist ein CNCF-Projekt von DataStax/MayaData mit einem modularen Architektur-Ansatz. Es bietet mehrere Storage-Engines für verschiedene Anwendungsfälle:

Mayastor (jetzt OpenEBS Replicated PV): Hochperformante Engine auf Basis von NVMe-oF und io_uring — für latenzempfindliche Workloads
Hostpath / Local PV: Einfachster Modus — lokales Verzeichnis ohne Replikation
ZFS Local PV: Nutzt ZFS-Features (Snapshots, Komprimierung) auf dem Node
Jiva: Ältere replizierte Engine, jetzt durch Mayastor ersetzt

Installation (nur Mayastor-Engine)

# Prerequisites: HugePages für Mayastor (auf jedem Node)
echo vm.nr_hugepages = 1024 | sudo tee -a /etc/sysctl.d/99-hugepages.conf
sysctl -w vm.nr_hugepages=1024

# Helm-Installation
helm repo add openebs https://openebs.github.io/openebs
helm repo update
helm install openebs openebs/openebs \
  --namespace openebs \
  --create-namespace \
  --set engines.replicated.mayastor.enabled=true

DiskPool und StorageClass

apiVersion: openebs.io/v1beta2
kind: DiskPool
metadata:
  name: pool-node1
  namespace: openebs
spec:
  node: k8s-node1
  disks:
  - /dev/sdb

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: mayastor-3-replicas
parameters:
  ioTimeout: "30"
  protocol: nvmf
  repl: "3"
provisioner: io.openebs.csi-mayastor

Mayastor nutzt User-Space I/O (kein Kernel-Treiber) und ist auf sehr geringe Latenz optimiert — ideal für Datenbanken wie PostgreSQL oder etcd.

Direkter Vergleich

Merkmal	Longhorn	OpenEBS (Mayastor)
Installation	Sehr einfach	Mittel (HugePages, dedicated Disks)
UI / Dashboard	Eingebaut ✓	Keins (CLI-only)
Performance	Gut (iSCSI/NFS)	Exzellent (NVMe-oF / io_uring)
Replikation	Automatisch, konfigurierbar	Automatisch, 1–3 Replicas
Snapshots	Eingebaut ✓	Via CSI ✓
Backup	S3/NFS eingebaut ✓	Extern (Velero empfohlen)
Latenz	~1–2 ms	< 0,1 ms (NVMe-of)
Homelab-tauglich	Sehr gut	Weniger (HugePages, dedicated Disks)
CNCF Status	Incubating	Incubating
Reifegrad	Sehr hoch, produktionserprobt	Mayastor seit 2023 stabil
Hardware-Anforderungen	Niedrig	Hoch (NVMe empfohlen)

Wann welches Tool wählen?

Longhorn ist die bessere Wahl für:

Homelab und kleine bis mittlere On-Premises-Cluster
Teams ohne dedizierte Storage-Expertise
Setups mit Standard-SATA-SSDs oder -HDDs
Schnelle Einrichtung mit grafischem Dashboard
Backup-Integration direkt in Longhorn (kein extra Tool)

OpenEBS mit Mayastor empfiehlt sich für:

Produktionscluster mit latenzempfindlichen Workloads (Datenbanken, etcd)
Setups mit NVMe-SSDs und dedizierten Disk-Pools
Teams, die maximale I/O-Performance brauchen
Enterprise-Umgebungen mit SLA-Anforderungen unter 1 ms

Storage für Homelab: Praktische Empfehlung

Für einen typischen Homelab-Cluster (3–5 Nodes, SATA-SSD, k3s oder RKE2) ist Longhorn die klar bessere Wahl: schnelle Installation, übersichtliches Dashboard, eingebaute Backups. Die Performance reicht für Datenbanken, Monitoring-Stacks und Self-Hosting-Anwendungen problemlos aus.

Für Produktions-Kubernetes-Cluster mit Datenbank-Workloads, bei denen Storage-Latenz kritisch ist, lohnt der Mehraufwand von OpenEBS/Mayastor — vor allem wenn NVMe-Hardware vorhanden ist.

Integration mit Backup-Tools

Longhorn hat eingebaute Backup-Integration (S3/NFS). Für OpenEBS empfiehlt sich Velero:

# Velero Backup für OpenEBS Volumes
apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: daily-backup
spec:
  schedule: "0 2 * * *"
  template:
    includedNamespaces:
    - production
    storageLocation: default
    volumeSnapshotLocations:
    - default

Fazit

OpenEBS und Longhorn ergänzen sich eher als dass sie konkurrieren: Longhorn ist der Allrounder für Homelab und mittelgroße Cluster, OpenEBS/Mayastor ist die Hochleistungslösung für Produktionsumgebungen mit NVMe-Hardware. Beide sind CNCF-Projekte mit aktiver Entwicklung und breiter Community-Unterstützung.