Persistenter Speicher ist die größte Herausforderung in Kubernetes-Umgebungen. Stateful Workloads wie Datenbanken, Blob-Storage und CMS brauchen Volumes, die unabhängig vom Pod-Lebenszyklus existieren und im Clusterausfallfall verfügbar bleiben. Longhorn und Rook-Ceph sind die zwei meistgenutzten Open-Source-Lösungen für diesen Anwendungsfall.

Was ist Longhorn?

Longhorn ist ein verteiltes Block-Storage-System für Kubernetes, entwickelt von Rancher (SUSE). Es ist seit 2022 ein CNCF Incubating Project und wurde für Einfachheit und Kubernetes-native Integration entwickelt.

Longhorn erstellt pro PVC ein dediziertes Volume-Objekt mit konfigurierbaren Replikaten auf verschiedenen Nodes. Das Volume wird über iSCSI oder NVMe-TCP an den Pod gemountet.

Stärken von Longhorn

  • Einfaches Setup: kubectl apply -f longhorn.yaml reicht für eine funktionierende Installation
  • Web-UI: Eingebautes Dashboard für Volume-Management, Snapshot-Browser und Backup-Status
  • Snapshot und Backup: Native Backup zu S3-kompatiblen Objektspeichern (MinIO, AWS S3)
  • Volume Expansion: Online-Resize ohne Downtime möglich
  • Node-Level Scheduling: Volumes werden auf Nodes mit freiem Speicherplatz verteilt
  • RWO und RWX: ReadWriteOnce und ReadWriteMany (über NFS-basiertes Longhorn Share Manager)

Schwächen von Longhorn

  • Performance: Höhere Latenz als Ceph durch iSCSI-Overhead, nicht für latenzsensiive Workloads (Hochperformanz-Datenbanken) optimal
  • Kein Object/Block Storage: Nur Block-Volumes (PVCs), kein S3-Interface
  • Memory-Overhead: Jedes Volume hat einen eigenen Longhorn-Engine-Prozess

Was ist Rook-Ceph?

Rook ist ein Cloud-Native Operator für Storage-Backends. Rook-Ceph orchestriert Ceph — das leistungsstärkste Open-Source-Distributed-Storage-System — als Kubernetes-Operator.

Ceph bietet drei Storage-Typen über eine Plattform: Block Storage (RBD), Object Storage (S3-kompatibel via RADOS Gateway) und Shared Filesystem (CephFS).

Stärken von Rook-Ceph

  • Storage-Typen: Block (RBD), Object (S3), Filesystem (CephFS) aus einer Plattform
  • S3-kompatibles Interface: CephFS Rados Gateway ersetzt MinIO in vielen Self-Hosting-Setups
  • Performance: Ceph RBD hat niedrigere Latenz und höheren Throughput als Longhorn für I/O-intensive Workloads
  • Skalierbarkeit: Ceph wurde für Exabyte-Scale designed — kein Limit für reale Self-Hosting-Szenarien
  • OSDs auf Raw Devices: Direkte Nutzung von Disks ohne Filesystem-Overhead
  • Erasure Coding: Effizientere Speichernutzung als Replikation bei großen Datenmengen

Schwächen von Rook-Ceph

  • Komplexität: Rook-Ceph-Cluster brauchen tiefes Verständnis von Ceph-Internals für Troubleshooting
  • Mindest-Hardware: Empfohlen sind 3+ Nodes mit dedizierten Disks; Testinstallation auf 1 Node möglich aber nicht produktionsreif
  • Setup-Zeit: Eine stabile Ceph-Installation dauert deutlich länger als Longhorn
  • Ressourcenverbrauch: MON, MGR, OSD-Pods verbrauchen deutlich mehr RAM als Longhorn (~2-4GB für minimales Ceph-Cluster)

Direktvergleich: Longhorn vs Rook-Ceph

Kriterium Longhorn Rook-Ceph
Setup-Aufwand Minimal (1 Kommando) Hoch (Stunden)
Block Storage ✅ iSCSI/NVMe-TCP ✅ Ceph RBD
Object Storage (S3) ❌ ✅ RADOS Gateway
Shared Filesystem ✅ (via Share Manager) ✅ CephFS
Web-UI ✅ Built-in ✅ Ceph Dashboard
Snapshot-Backup ✅ S3-kompatibel ✅
CNCF-Status Incubating Graduated (Rook)
Min. Nodes (Prod) 1 (3 empfohlen) 3
RAM (Min-Setup) ~200MB ~2-4GB
Performance Mittel Hoch
Lizenz Apache 2.0 Apache 2.0

Performance-Vergleich in der Praxis

Für datenbankintensive Workloads (PostgreSQL, MySQL) zeigt Rook-Ceph RBD mit dedizierten SSDs typischerweise 20-40% niedrigere Latenz und 30-50% höheren IOPS als Longhorn. Der Unterschied kommt durch:

  • Direkter OSD-Zugriff auf Block-Devices (kein Dateisystem-Overhead)
  • Optimierter RBD-Kernel-Treiber
  • Besseres I/O-Scheduling in Ceph

Für typische Web-Applikationen (WordPress, Strapi, Nextcloud) ist der Unterschied in der Praxis kaum messbar.

Mein Setup: Longhorn auf K3s

Auf meinem K3s-Cluster für typoniels.dev nutze ich Longhorn wegen seiner einfachen Wartbarkeit:

# Longhorn Installation
kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.7.0/deploy/longhorn.yaml

# StorageClass überprüfen
kubectl get storageclass
# NAME                 PROVISIONER               RECLAIMPOLICY   VOLUMEBINDINGMODE
# longhorn (default)   driver.longhorn.io        Delete          Immediate

Backups laufen nächtlich zu MinIO. Für meine Workloads (Strapi, Grafana) reicht Longhorn völlig aus.

Wann welches Tool?

Longhorn ist richtig wenn…

  • Du mit Kubernetes anfängst und schnell persistenten Speicher brauchst
  • Dein Cluster 1-5 Nodes hat und kein dediziertes Storage-Team existiert
  • Einfache Backups zu S3/MinIO reichen
  • Du Rancher/K3s nutzt (Longhorn ist Rancher-nativ)
  • Latenz unter 1ms kein Anforderung ist

Rook-Ceph ist richtig wenn…

  • Du S3-Object-Storage selbst hosten willst (als MinIO-Ersatz)
  • Hochperformante Datenbanken auf SSDs laufen
  • Du 3+ bare-metal Nodes mit dedizierten Disks hast
  • Das Team Ceph-Erfahrung hat oder aufbauen will
  • Skalierung auf mehrere hundert TB geplant ist

Alternative: Local Path Provisioner für einfache Fälle

Für sehr einfache Setups oder Single-Node-Cluster ist der K3s Local Path Provisioner oft ausreichend: Er erstellt hostPath-Volumes direkt auf dem Node. Kein HA, kein Backup — aber null Overhead und sofort nutzbar. Für Produktionsworkloads mit Verfügbarkeitsanforderungen nicht geeignet.

Fazit

Longhorn für den Einstieg und kleine bis mittlere Cluster — Setup in Minuten, Web-UI inklusive, S3-Backup out of the box. Rook-Ceph für große Cluster und Enterprise-Anforderungen — wenn S3-Object-Storage, CephFS oder maximale Performance gefragt sind.

Der häufigste Migrationspfad: Mit Longhorn starten, bei wachsenden Anforderungen zu Rook-Ceph migrieren. Rook bietet Dokumentation für Volume-Migration.