So wählen Sie das richtige Storage-Setup für Ihren Kubernetes-Cluster

In unseren modernen Kubernetes-Umgebungen spielt die Auswahl des passenden Speichers eine entscheidende Rolle für die Stabilität und Performance Ihrer Anwendungen. Als Basis für hochverfügbaren Speicher setzen wir bei Tralios IT auf Ceph – ein verteiltes Speichersystem, das Daten redundant auf mehreren Servern vorhält.

Doch innerhalb von Ceph gibt es unterschiedliche Ansätze, und in speziellen Fällen bietet sich der Rückgriff auf lokalen Speicher an – oder auf den Pod-internen Zwischenspeicher emptyDir. In diesem Artikel möchten wir Ihnen die Vor- und Nachteile der vier gängigen Optionen erläutern, damit Sie für Ihr Projekt die richtige Wahl treffen können.

1. Ceph Block Device (RBD) – Die performante Standardlösung

Wenn Sie in Ihrem Kubernetes-Cluster ein Persistent Volume Claim (PVC) mit der StorageClass rook-ceph-block anfordern, wird ein virtuelles Blockgerät erstellt. In der Regel kommt hierbei das bewährte ext4-Dateisystem zum Einsatz.

Empfehlung: Nutzen Sie diesen Modus für fast alle Standardanwendungen und Datenbanken, die keinen gleichzeitigen Zugriff von mehreren Instanzen benötigen.

2. CephFS – Flexibilität für verteilte Workloads

CephFS ist ein verteiltes Netzwerkdateisystem. Es verhält sich ähnlich wie ein klassischer NFS-Share, bei dem mehrere Clients gleichzeitig Zugriff auf denselben Datenbestand haben. Wählen Sie für ein PVC die StorageClass rook-cephfs, falls Sie CephFS nutzen möchten.

Empfehlung: Wählen Sie CephFS nur dann, wenn Sie zwingend den parallelen Schreibzugriff mehrerer Pods benötigen, beispielsweise für Shared Assets in einem Web-Cluster.

3. Lokaler Speicher (Local Storage) – Maximale Geschwindigkeit ohne Netz

Für spezielle Anforderungen kann es sinnvoll sein, den Speicher direkt auf dem physischen Server zu nutzen, auf dem der Pod gerade läuft.

Empfehlung: Lokaler Speicher eignet sich hervorragend für Applikationen, die ihre Datenreplikation selbst auf Softwareebene steuern – wie zum Beispiel ein Galera-Datenbank-Cluster. Ebenso kommt lokaler Speicher immer im Single-Node-Betrieb zum Einsatz, wenn also überhaupt kein verteilter Ceph-Speicher zur Verfügung steht.

4. emptyDir – Temporärer Zwischenspeicher im Pod

Für temporäre Dateien stellt Kubernetes mit emptyDir eine eigene, sehr schlanke Variante bereit. Wichtig: emptyDir ist keine StorageClass und auch kein Persistent Volume Claim (PVC). Das Volume wird direkt in der Pod- bzw. Deployment-Spezifikation definiert und dort eingebunden.

Das Verzeichnis wird beim Start des Pods auf dem Node angelegt und ist zunächst leer. Alle Container desselben Pods können darauf zugreifen – auch über unterschiedliche Mount-Pfade. Überlebt ein Container-Crash den Pod, bleiben die Daten erhalten. Wird der Pod hingegen gelöscht oder von einem Node entfernt, sind die Daten unwiederbringlich verloren.

Optional lässt sich ein RAM-basiertes tmpfs nutzen – sehr schnell, aber der belegte Speicher zählt gegen das Memory-Limit des Containers.

Empfehlung: Nutzen Sie emptyDir bewusst für temporäre Daten – Caches, Zwischenergebnisse oder gemeinsame Arbeitsverzeichnisse innerhalb eines Pods. Persistente Anwendungsdaten gehören weiterhin auf Ceph Block, CephFS oder lokalen Persistent Storage.

Praxis-Tipp: Die „Verzeichnis-Falle“ vermeiden

Unabhängig vom gewählten System ist die Struktur Ihrer Daten entscheidend für die Performance. Ein einzelnes Verzeichnis mit einer Million Dateien überfordert fast jedes Dateisystem. Besonders bei CephFS macht sich das negativ bemerkbar.

Unsere Empfehlung: Strukturieren Sie große Datenmengen in Unterverzeichnisse um. Eine bewährte Methode ist die Verteilung anhand von Hashes, z. B. /storage/ab/ab12fec8201377df3456a5.jpg. Hierbei ist ab12fec8201377df3456a5 der Hash eines Bildes, der als Dateiname verwendet wird. Die ersten beiden Buchstaben des Hashes (ab) werden als Verzeichnisname für einen Unterordner genutzt. Dadurch werden Dateien gleichmäßig auf Unterordner verteilt. Ein einzelnes Verzeichnis sollte nach Möglichkeit nicht mehr als 10.000 Dateien beinhalten. Das beschleunigt Dateioperationen und Abgleich-Prozesse wie rsync dramatisch.

Fazit

Die Wahl der richtigen Speicherlösung hängt maßgeblich davon ab, ob Sie Persistenz und Ausfallsicherheit brauchen, ob mehrere Pods gleichzeitig zugreifen müssen – oder ob es nur um temporäre Arbeitsdaten innerhalb eines Pods geht.

Sollten Sie unsicher sein, welche Konfiguration für Ihren spezifischen Anwendungsfall die optimale ist, sprechen Sie uns gerne an. Wir unterstützen Sie bei der Planung und Optimierung Ihrer Infrastruktur.