Ein kurzer Exkurs auf den Inhalt einer nächsten Folge:

Um das Konzept meines Clusters zu verstehen, müssen wir die drei Evolutionsstufen der Server-Architektur sauber trennen. Viele werfen Docker und Kubernetes in einen Topf. Das ist aber nur halb richtig.

1. Virtualisierung (Das Hochhaus): Das ist der klassische Weg ("Old School"). Man hat einen riesigen Server mit Proxmox, KVM oder ähnlich und teilt ihn in viele virtuelle Maschinen (VMs) auf. Jede VM ist wie ein komplett eigenständiges Haus mit dicken Wänden, eigenem Heizsystem und eigener Verwaltung (volles Betriebssystem mit Kernel). Das ist sicher, isoliert alles perfekt, ist aber schwerfällig. Man verschwendet Unmengen an Ressourcen nur dafür, das Haus am Laufen zu halten, bevor man überhaupt Möbel reinstellt.
2. Docker (Die WG-Zimmer): Hier wird es effizienter. Docker-Container teilen sich das Fundament (den Kernel des Host-Betriebssystems) – wie Bewohner in einer WG, die sich Küche und Bad teilen. Jeder hat sein eigenes Zimmer (die Applikation), aber man braucht nicht für jeden Bewohner ein eigenes Haus bauen. Das Problem: Docker ist ein Solist. Wenn ich Docker auf einem Raspberry Pi starte, läuft der Container auf genau diesem Pi. Fällt der Pi aus, ist der Container tot. Wenn ich 6 Pis habe, muss ich mich manuell um 6 einzelne Docker-Instanzen kümmern. Ich bin der Hausmeister für jedes einzelne Zimmer.
3. Kubernetes (Die Hotel-Management-Software): Hier kommt der entscheidende Sprung. Kubernetes (K8s/K3s) ist keine Konkurrenz zu Docker, sondern der Chef. In meinem Cluster rede ich nicht mehr mit "Pi Nummer 1" oder "Pi Nummer 4". Ich rede mit dem Cluster. Ich sage: "Starte diese Anwendung 3 mal." Kubernetes entscheidet dann selbstständig: "Okay, Pi 2 hat gerade Langeweile, da packe ich eine Instanz hin. Pi 5 hat noch Platz, da kommt die zweite hin." Der Clou: Wenn ich das Kabel von Pi 2 ziehe und er ausfällt, merkt Kubernetes das sofort: "Mist, eine Instanz fehlt." Und startet sie vollautomatisch auf Pi 6 neu.

Das bedeutet für das Verständnis: Die "Päckchen", die meine Software enthalten, sind weiterhin Docker-Container. Wir nutzen Docker (oder kompatible Formate), um die Software zu verpacken. Aber Kubernetes ist der intelligente Logistik-Manager, der entscheidet, auf welchem LKW (Server) das Päckchen transportiert wird. Docker ist der Standard für das Was, Kubernetes ist die Intelligenz für das Wo und Wie.

Oder: Warum meine Pis glauben, sie hätten eine gemeinsame Festplatte

NFS ist im Grunde der einer der besten und und häufigst kopierten Tricks der Linux -/Unix-Welt:
„Tu einfach so, als würdest du lokal speichern. Aber in Wahrheit liegt alles auf einem Server, der hoffentlich nicht abraucht.“

Mehr ist es nicht. Und genau deshalb liebe ich es.

Was NFS wirklich macht

• Der Server sagt: „Hier, dieses Verzeichnis darfst du benutzen.“
• Der Client sagt: „Cool, ich mounte das. Ab jetzt so tun, als wäre es mein eigenes.“
• Und ab diesem Moment schreibt der Client fröhlich auf etwas, das physisch ganz woanders liegt.

Es ist die Illusion des lokalen Speichers. Nur ohne SD-Karten, Dateimord und sonstige Heimlab-Desaster.

Warum das in meinem Cluster unverzichtbar ist

Kubernetes braucht irgendwo Persistenz, also einen Ort, an dem Daten über den Tod eines Pods hinaus existieren dürfen.
Aber:
Meine Raspberry Pis sind kleine, flüchtige Digital-Nomaden. Sie kommen, gehen und sterben, wenn ich ein Kabel ziehe.

Deshalb:

• Die Pis tun so, als hätten sie eine lokale Platte.
• In Wahrheit landen alle Daten sauber auf dem ZimaBlade.
• Der ZimaBlade nutzt ZFS und Snapshot-Magie, um den ganzen Kram abzusichern.

Das ist Storage as a Service, nur ohne Cloud-Consumption-Rechnung am Monatsende.

Der eigentliche Charme

NFS ist herrlich unspektakulär.
Es ist kein „Next-Gen Distributed Hyper-Meta-Filesystem“.
Es ist kein akademischer Alptraum, schnell umsetzbar.
Es ist das Unix-Pendant zu: „Lass mich einfach arbeiten.“

Und genau deshalb eignet es sich perfekt für mein Cluster:

• simpel
• stabil
• von Kubernetes gut verstanden
• und vor allem: es funktioniert

Fällt ein Pi aus? Egal. Die Daten liegen auf dem Storage-Node und warten geduldig, bis der nächste Worker sie braucht.

Kurz gesagt

NFS ist die logistische Versorgungsleitung meines Schwarms.
Ohne NFS würden meine Compute-Nodes isolierte Inseln sein.
Mit NFS sind sie vernetzte Individuen mit gemeinsamen Gedächtnis.

Und das ist genau das, was man in einem echten Cluster braucht.

ZFS ist kein normales Dateisystem.
ZFS ist das Dateisystem, das entstand, als die Ingenieure bei Sun Microsystems beschlossen, ein Schweizer Taschenmesser zu bauen.

Während traditionelle Dateisysteme versuchen, einfach nur Dateien irgendwohin zu schreiben, verfolgt ZFS einen anderen Ansatz:
„Ich speichere deine Daten. Aber nur ordentlich, und nur, wenn ich sicher bin, dass sie auch wirklich stimmen.“

Warum ZFS anders ist

🔹 Dateisystem, Volume-Manager und RAID in einem
Andere Systeme brauchen drei Tools: eines zum Formatieren, eines zum Partitionieren, eines zum RAID-Bauen.
ZFS sagt: „Nö. Ich mach das alles selbst.“
Das spart Fehler, Komplexität und graue Haare.

🔹 Datenintegrität first, alles andere später
Jeder einzelne Block wird mit einer Prüfsumme versehen.
Beim Lesen wird geprüft, ob der Inhalt noch korrekt ist.

Wenn nicht?
ZFS repariert still und leise aus der Redundanz.

Kein anderer Mainstream-Stack macht das so konsequent.

🔹 128-Bit-Architektur
Heißt auf Deutsch:
Du wirst das Limit deiner Lebenszeit nicht erreichen, bevor ZFS an seine Kapazitätsgrenzen stößt. (Erinnert ihr euch noch an das Chaos der alten FAT-Versionen? Kurze Namen, dann improvisierte Exxtensions ...)

🔹 Kompression ohne Denken
Einfach einschalten.
ZFS komprimiert alles automatisch, intelligent und transparent.
Oft gewinnst man so tatsächlich 20–50 % Speicherplatz, ohne dass man merkst, dass etwas passiert.

🔹 Snapshots, die schneller sind als der Fehler
Ein ZFS-Snapshot:

• ist praktisch instant
• braucht fast keinen Platz
• ist unveränderlich (perfekt gegen Ransomware & Benutzerfehler)
• kann repliziert werden wie ein Git-Commit

Für Backups ist das Gold wert.
Für Kubernetes: ebenfalls.

🔹 Speicherpools statt Partitionen
ZFS wirft alle Platten in einen Pool und verwaltet sie wie einen großen See statt viele kleine Tümpel.
Der Vorteil: maximale Flexibilität, minimale mentale Belastung.

Warum ich ZFS im Rebel-Cluster nutze

• Weil meine Daten nicht verrotten sollen (Bitrot ist real, und kommt selten allein).
• Weil Snapshots und Replikation kinderleicht sind.
• Weil Kubernetes eine stabile Storage-Grundlage braucht.
• Weil ich keine Lust auf Dateisystem-Drama habe.

ZFS macht den ZimaBlade nicht nur zu einem Speichergerät, sondern zu einem Gedächtnis, das sich selbst überwacht, selbst repariert und sich im Zweifel auf einen früheren Zustand zurückwuppst.

Kurz gesagt:

ZFS gibt mir Ruhe.
Alles andere gibt mir Bauchschmerzen.

„Dataset? Ach so, ein Ordner. Oder vielleicht sowas wie eine Partition unter Windows.“

Nein.
Das ist ungefähr so, als würde man einen Airbus A380 mit einem Klappfahrrad vergleichen, weil beides irgendwie Räder und sowas wie einen Rahmen hat.

Was ein Dataset wirklich ist

Ein Dataset ist ein eigenständiges, miniaturisiertes Dateisystem innerhalb deines ZFS-Pools – aber ohne den ganzen Partitionierungs-Wahnsinn, den Windows einem abverlangt. Denk freier.

Du kannst für jedes Dataset eigene Regeln definieren:

• Kompression
• Quotas
• Reservierungen
• Recordsize
• Snapshothäufigkeit
• Zugriffsrechte
• Deduplizierung
• Caching-Verhalten

Es verhält sich wie ein kleiner, intelligenter Speicherbereich, der weiß, was er werden will.

Der Unterschied zu Windows-Partitionen

Unter Windows musst du:

• Platten partitionieren
• Volumes formatieren
• Buchstaben zuweisen (C:, D:, E:, J:, Z:, was auch immer)
• Und wenn du falsch geplant hast. Formatieren, fluchen, neu anfangen.

Eine Partition ist starr. Wie ein Betonblock. Einmal gegossen, kaum flexibel.

Ein Dataset dagegen:

• braucht keine Partition
• wächst dynamisch im Pool
• lässt sich jederzeit konfigurieren
• kann für jeden Zweck anders optimiert werden
• erzeugt Snapshots in Sekunden
• ist völlig unabhängig von der physischen Struktur der Platten

ZFS-Pool = der ganze Teich
Dataset = ein sauber abgegrenzter Bereich darin

Der Unterschied zu einem Verzeichnis

Ein Verzeichnis ist ein Namensschild.
Ein Dataset ist ein Konfigurationsobjekt.

Ein normaler Ordner hat:

• keine eigene Kompression
• keine eigenen Quotas
• keine eigenen Snapshots
• kein eigenes Caching
• keine eigene Blockgröße
• keine eigene Replikationslogik
• keine eigene Deduplizierung

Ein Dataset dagegen ist ein Mini-Dateisystem mit eigener Persönlichkeit.

Beste Analogie:

• Ein Ordner ist ein Karton.
• Ein Dataset ist ein ganzer Raum, den du individuell einrichten kannst.

In Kubernetes-Umgebungen bedeutet das:

• /tank/k3s-nfs kann schnelle, große Blöcke haben
• /tank/backups kann ultra-komprimiert laufen
• /tank/logs kann hart begrenzt werden (Quota!), damit nichts aus dem Ruder läuft

Ein Verzeichnis könnte all das nicht.

Warum das im Rebel-Cluster entscheidend ist

Weil ich unterschiedliche Workloads habe, die unterschiedliche Anforderungen haben:

• Kubernetes-Volumes → Performance + Konsistenz
• Backups → Kompression + viele Snapshots
• Medien → großer Blocksize + Kompression
• Logs → kleine Blöcke, begrenzter Platz

Datasets erlauben mir, jede Art von Daten exakt so zu behandeln, wie sie es braucht.

Ohne Datasets würdest ich also:

• Performance verlieren
• Chaos riskieren
• Fehlkonfigurationen multiplizieren
• Snapshots unkontrolliert wachsen lassen

Datasets geben Ordnung, Kontrolle und Flexibilität.