Vom Kabelsalat ins 10"-Rack: Mein k3s-Umbau mit NAS und Democratic CSI

Eigentlich wollte ich nur zwei praktische Probleme lösen: weniger Netzteile und weniger herumstehende Gehäuse. Am Ende wurde daraus ein kompletter Umbau meines Homelabs: 10″-Rack, zentrale Stromversorgung, dediziertes NAS und Migration von Longhorn auf Democratic CSI.

3 Fujitsu Siemans S920 aufgestellt, darauf ein Switch — 3 Futro S920 nebeneinander

Ein Rack mit 12 Höheneinheiten und 10" Breite. Es sind 4 Rechner eingebaut, ein Einschub für Festplatten, Patchpanel und Stromversorgung — 3 Futro S920 nebeneinander

Ausgangslage: stabil, aber zunehmend unpraktisch

Mein Cluster lief zuverlässig, aber im Alltag hat mich Folgendes immer mehr gestört:

drei Nodes mit drei separaten kleinen Netzteilen
drei einzelne Gehäuse, die Platz und Nerven gekostet haben
viel Verkabelung und wenig Ordnung

Ich wollte daher:

die drei Nodes mit einem großen Netzteil versorgen
alles in ein gemeinsames Gehäuse / Rack integrieren
das Setup einfacher transportierbar machen

Wie ich beim 10″-Rack gelandet bin

Bei der Suche nach einer zentralen Stromversorgung bin ich über eine PDU für 19V-Geräte gestolpert – ausgelegt für ein 10″-Rack.

Daraufhin habe ich weiter nach kompakten Homelab-Racks gesucht und bin über die Sammlung von Jeff Geerling auf die GeekPi-Racks gestoßen, die häufig für Raspberry-Pi-Cluster genutzt werden, sich aber auch für andere kompakte Systeme eignen:

Mein Rack-Build

Ich habe ein GeekPi 12HE T2 aufgebaut mit:

4 Einschüben für Mini-ITX-Boards (Futro S920 passt)
großem 19V-Netzteil
19V-PDU (Power Delivery Unit)
2 Einschüben für je 2x 2,5″-Platten
10″-4-fach-Steckdosenleiste

Ergebnis im Alltag

Der größte praktische Vorteil:
Es gehen nur noch zwei Kabel nach außen — Strom und Netzwerk.

Dazu kommt: Das Rack ist kompakt, ordentlich und einfach zu tragen/transportieren.

Warum ich von Longhorn weg bin

Longhorn war für mein Setup lange okay, aber mit wachsendem Speicherbedarf wurde der Betrieb zunehmend zäh.

Ein zentraler Schmerzpunkt war das Verhalten nach Neustarts:
Nach einem Reboot dauerte es teils über eine Stunde, bis der Cluster wieder vollständig „ready“ war, weil Daten zwischen den Nodes abgeglichen wurden.

Ich habe mich deshalb bewusst für einen Trade-off entschieden:

weniger Storage-Redundanz über mehrere k3s-Nodes
dafür ein ruhigeres, besser planbares System

In meinem Homelab ist verteiltes Storage über mehrere Nodes nicht zwingend nötig.
Die Daten sind weiterhin gespiegelt — jetzt eben auf dem NAS (ZFS-Mirror).
Ein positiver Nebeneffekt: Neustarts sind deutlich schneller.

Das NAS-Setup

Für das NAS nutze ich:

Mini-ITX-Board mit Intel N100
32 GB RAM
6 SATA-Ports
2 SSDs (glücklicherweise noch zu besseren Preisen gekauft)
lüfterlose Mini-PSU (Power Supply Unit), 200W, genügend Ports für SSDs

2 2,5" SSD verbaut in einem Rackeinschub — 2 SSD für das NAS

ein Mini-ITX-Board verbaut in einem Einschub — 2 SSD für das NAS

Betriebssystem ist Ubuntu, Storage mit ZFS:

ZFS-Mirror
verschlüsselte und unverschlüsselte Datasets

Zugriff aus Kubernetes:

NFS
iSCSI

Sicherheitsaspekt: NFS nur im internen Netz

Da NFS im Kern über Netzgrenzen abgesichert wird, sind alle vier Server per WireGuard miteinander verbunden. NFS ist ausschließlich in diesem internen WireGuard-Netz erlaubt.

So bleibt der Zugriff klar begrenzt, ohne unnötig komplex zu werden.

Democratic CSI kurz erklärt

Für die Kubernetes-Anbindung nutze ich jetzt Democratic CSI. Das Projekt implementiert den CSI-Standard und eignet sich besonders gut für ZFS-basierte Backends (z. B. TrueNAS oder ZFS on Linux) mit NFS/iSCSI.

Technisch trennt sich das in zwei Rollen:

Controller-Komponente: verwaltet Volumes am Storage-Backend
Node-Komponente: mountet Volumes auf den k3s-Nodes

Je nach StorageClass kann ich dann gezielt wählen:

NFS für RWX-Workloads
iSCSI für blockbasiertes RWO

Projektquellen:

Beispiel-PVC (NFS, RWX)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data-nfs
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: democratic-csi-zfs-nfs-encrypted
    resources:
      requests:
        storage: 20Gi

Beispiel-PVC (iSCSI, RWO)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data-iscsi
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: democratic-csi-zfs-iscsi-encrypted
    resources:
      requests:
        storage: 20Gi

Lüfterlos bleibt lüfterlos

Ein schönes Detail: Das Setup ist weiterhin komplett lüfterlos.
Spannend wird, wie sich das im Sommer unter Dauerlast verhält — da werde ich sicher noch ein Follow-up mit Temperatur- und Stabilitätswerten machen.

Fazit

Der Umbau war mehr als ein kosmetisches Rack-Projekt.
Ich habe damit drei Dinge gleichzeitig verbessert:

Aufbau und Verkabelung massiv vereinfacht
Storage-Betrieb beruhigt
Neustart- und Recovery-Verhalten deutlich verbessert

Unterm Strich: weniger Bastelchaos, klarere Architektur und ein Setup, das sich im Alltag besser anfühlt.

Vom Kabelsalat ins 10″-Rack: Mein k3s-Umbau mit NAS und Democratic CSI

Ausgangslage: stabil, aber zunehmend unpraktisch

Wie ich beim 10″-Rack gelandet bin