Persistente Workloads im Cluster sauber betreiben lassen? WZ-IT plant, baut und betreibt Kubernetes-Cluster inklusive Storage und Backup - auf Proxmox, Bare Metal und europäischer Infrastruktur, mit klarem Betriebs-Scope. Managed Kubernetes ansehen
Sobald Datenbanken oder zustandsbehaftete Anwendungen in Kubernetes laufen, braucht der Cluster persistenten Speicher. Zwei Lösungen dominieren die Diskussion um selbst betriebenes Storage: Longhorn und Rook-Ceph. Sie stehen für zwei Philosophien - schlankes Block-Storage gegen einen vollwertigen Storage-Orchestrator. Dieser Vergleich ordnet beide ein und beantwortet die eigentliche Frage: welche Lösung zu welchem Cluster passt. Stand Juli 2026.
Inhaltsverzeichnis
- Zwei Philosophien für Cluster-Storage
- Longhorn: schlankes Block-Storage
- Rook-Ceph: der Storage-Orchestrator
- Die beiden im Vergleich
- Und OpenEBS?
- Welche Lösung für welchen Cluster
Zwei Philosophien für Cluster-Storage
Der Unterschied beginnt beim Anspruch. Longhorn will genau eine Sache gut können: verteiltes Block-Storage für persistente Volumes, einfach zu betreiben. Rook-Ceph bringt mit Ceph ein vollwertiges Storage-System in den Cluster, das Block-, Datei- und Objekt-Storage zugleich liefert - mächtiger, aber auch schwerer.
Die Wahl ist damit weniger eine Feature-Frage als eine Abwägung zwischen Einfachheit und Mächtigkeit. Wer nur zuverlässige Volumes braucht, zahlt bei Ceph für Fähigkeiten, die er nicht nutzt. Wer mehrere Storage-Arten oder große Skalierung braucht, stößt bei reinem Block-Storage an Grenzen.
Longhorn: schlankes Block-Storage
Longhorn ist ein leichtgewichtiges, verteiltes Block-Storage-System, das von Rancher gestartet wurde und heute ein CNCF-Incubating-Projekt ist (seit November 2021). Es installiert sich als Kubernetes-Anwendung und legt für jedes Volume einen eigenen Controller an, mit synchroner Replikation über mehrere Knoten (Longhorn-Dokumentation).
Die wichtigsten Eigenschaften:
- Kein Single Point of Failure durch die verteilte Architektur.
- Inkrementelle Snapshots mit effizienter Änderungserkennung.
- Backups nach NFS oder S3-kompatiblen Speicher als getrennter Pfad.
- Web-Oberfläche für Verwaltung und Überblick.
- Keine dedizierten Storage-Knoten nötig - Longhorn nutzt die Volumes der vorhandenen Nodes.
Damit ist Longhorn der pragmatische Standard für die meisten selbst betriebenen Cluster: schnell aufgesetzt, überschaubar im Betrieb, robust genug für produktive Datenbanken. Wichtig bleibt die Abgrenzung: Replikation schützt vor Knoten-Ausfall, ist aber kein Backup - der Backup-Pfad gehört immer dazu.
Rook-Ceph: der Storage-Orchestrator
Rook ist ein CNCF-graduiertes Projekt und orchestriert Ceph in Kubernetes - ein ausgereiftes, im Petabyte-Bereich bewährtes verteiltes Storage-System. Rook automatisiert dabei Deployment, Konfiguration, Skalierung und Heilung des Ceph-Clusters, sodass er sich weitgehend selbst verwaltet.
Der entscheidende Vorteil: Ceph liefert drei Storage-Arten in einem System:
- Block (RBD) - für persistente Volumes wie bei Longhorn.
- Dateisystem (CephFS) - geteilter Zugriff mehrerer Pods auf dieselben Daten.
- Objekt (RGW) - eine S3-kompatible Schnittstelle direkt im Cluster.
Der Preis dafür ist Komplexität und Ressourcenbedarf. Ceph besteht aus Monitors, OSDs und Managern, die deutlich mehr RAM als Longhorn brauchen, dedizierte Datenträger pro Storage-Knoten voraussetzen und Tuning-Erfahrung verlangen. Rook nimmt viel Betriebsarbeit ab, aber das Fundament bleibt ein anspruchsvolles Storage-System - das sich erst ab einer gewissen Größe und Anforderung auszahlt.
Die beiden im Vergleich
| Dimension | Longhorn | Rook-Ceph |
|---|---|---|
| Storage-Arten | Block | Block, Dateisystem, Objekt (S3) |
| Betriebsaufwand | Gering, Web-UI | Höher, trotz Automatisierung durch Rook |
| Ressourcenbedarf | Schlank | Hoch (Monitors, OSDs, Manager) |
| Dedizierte Storage-Knoten | Nicht nötig | Empfohlen |
| Skalierung | Kleine bis mittlere Cluster | Bis Petabyte-Bereich |
| Reifegrad | CNCF Incubating | Rook CNCF graduiert, Ceph langjährig bewährt |
| Sweet Spot | Zuverlässige Volumes, schneller Betrieb | Mehrere Storage-Arten, große Skalierung |
Und OpenEBS?
Als dritte Option taucht häufig OpenEBS auf. Es verfolgt einen modularen Ansatz mit mehreren Storage-Engines und ist besonders dort interessant, wo lokale, latenzarme Volumes im Vordergrund stehen. Für die Grundsatzentscheidung gilt aber dieselbe Logik: Die meisten Cluster brauchen zuverlässiges Block-Storage mit guten Backups - und dafür ist der Weg über Longhorn der kürzeste. Rook-Ceph und OpenEBS lohnen sich, wenn konkrete Anforderungen (Objekt-Storage, geteiltes Dateisystem, spezielle Performance-Profile) darüber hinausgehen.
Welche Lösung für welchen Cluster
Die ehrliche Kurzfassung: Im Zweifel mit Longhorn starten. Die meisten Cluster, die glauben, Ceph zu brauchen, brauchen eigentlich verlässliches Block-Storage mit guten Backups - und das liefert Longhorn mit einem Bruchteil der Betriebsfläche.
- Longhorn, wenn Sie persistente Volumes für Datenbanken und Anwendungen brauchen, den Betrieb schlank halten wollen und keine dedizierten Storage-Knoten stellen möchten.
- Rook-Ceph, wenn Sie zusätzlich geteiltes Dateisystem oder S3-Objekt-Storage im Cluster brauchen, in den zweistelligen Knoten-Bereich skalieren oder Ceph-Erfahrung im Team haben.
Unabhängig von der Wahl gehört ein getrennter, getesteter Backup-Pfad dazu - welche Ebenen dabei separat geschützt werden müssen, zeigt der Leitfaden zu Kubernetes-Backups. Und wie die Distribution darunter das Betriebsmodell prägt, ordnet k3s vs. RKE2 vs. Talos ein.
