Jedes Lab braucht ein Stück Blech, auf dem es steht. Bei mir ist das ein Turing Pi -Board — ein Mini-ITX-Träger für vier Compute-Module, den ich seinerzeit in der Kickstarter-Kampagne mitfinanziert habe. Die Idee, einen kleinen, lautlosen und stromsparenden Cluster aus austauschbaren Knoten in einem einzigen Gehäuse zu betreiben, hat mich sofort überzeugt. Diese Geschichte handelt davon, wie aus der ersten, etwas naiven Bestückung über ein paar Umwege die heutige Basis von hydra wurde.
Das Board
Das Herzstück ist die Baseboard-Platine: vier Slots für Compute-Module, ein gemeinsamer Gigabit-Switch, zwei SATA-Ports und — für mich entscheidend — ein
Baseboard Management Controller
(BMC). Über den BMC und sein tpi-CLI lassen sich die Knoten einzeln ein- und ausschalten, flashen und ihre serielle Konsole abgreifen, ganz ohne Monitor oder Tastatur:
tpi power on --node 1
tpi uart --node 1 get
tpi flash --local --image-path /mnt/sdcard/talos.raw --node 1
Genau dieses Out-of-Band-Management ist der Grund, warum so ein Board einem Stapel einzelner SBCs haushoch überlegen ist: Ein hängender Knoten ist einen tpi power off entfernt, nicht einen Gang in den Keller.
Erster Aufbau: Vier Raspberry Pi und zwei SSDs
Gestartet bin ich mit dem, was naheliegend und verfügbar war: vier Raspberry-Pi-Compute-Module in den vier Slots, dazu zwei SATA-SSDs, die ich im Software-RAID1 gespiegelt habe, um wenigstens eine gewisse Redundanz für den persistenten Speicher zu haben.
Auf dem Papier ein hübscher kleiner Cluster. In der Praxis stieß ich aber schnell an die Grenzen der Plattform:
- Die Compute-Module hängen jeweils nur an einer einzigen PCIe-Lane, und das Routing der NVMe-Slots auf dem Board bedient auf dieser Modulgeneration nur einen Teil der Knoten. Schneller, lokaler Flash-Speicher pro Knoten war damit schlicht nicht drin.
- Der gemeinsame SATA-RAID1-Verbund wurde zum Flaschenhals. Für ein verteiltes Dateisystem über vier Knoten ist „zwei Platten an einem Knoten“ das genaue Gegenteil dessen, was man möchte.
- RAM und CPU der Module waren für einen Kubernetes-Cluster mit Ceph, Monitoring und einer Handvoll Workloads dauerhaft zu knapp bemessen.
Der Wechsel auf die RK1-Module
Die Lösung kam von Turing selbst: die RK1 -Module auf Basis des Rockchip RK3588. Acht Kerne, bis zu 32 GB RAM und — der eigentliche Grund für den Umstieg — ein NVMe-Slot pro Knoten. Damit kippte die ganze Speicher-Architektur ins Erfreuliche: Statt eines gespiegelten SATA-Verbunds an einem Knoten bekam jeder Knoten seine eigene NVMe, und Rook-Ceph verteilt den Speicher seitdem sauber über alle vier Knoten.
Heute besteht hydra aus einer Turing-Pi-Baseboard mit vier RK1-Modulen — ein Controller und drei Worker:
Die NIC der Module spricht über den rk_gmac-dwmac-Treiber, es gibt kein TPM, und die Architektur ist durchgängig ARM64 — drei Details, die später bei der Wahl von Betriebssystem und Images noch eine Rolle spielen.
Warum Talos Linux
Auf den ersten Iterationen lief noch ein klassisches Distro-Linux auf den Knoten. Irgendwann wurde mir das händische Pflegen von Paketständen, SSH-Zugängen und kleinen Konfig-Drifts über vier Knoten aber zu mühsam — das ist genau die Art Arbeit, die ein Homelab eigentlich abschaffen soll. Die Antwort war Talos Linux .
Talos ist ein immutables, API-getriebenes Betriebssystem speziell für Kubernetes. Es gibt keine Shell und kein SSH; der gesamte Zustand eines Knotens ergibt sich aus einer deklarativen Maschinen-Konfiguration, die man über die talosctl-API ausrollt. Das passt perfekt zur GitOps-Philosophie des restlichen Labs: Die Knoten sind keine Schmuckstücke, die man pflegt, sondern austauschbare Bausteine, die man bei Bedarf einfach neu flasht.
Das passende Image für die RK1-Module baue ich über die Talos Image Factory . Der entscheidende Teil ist das Rockchip-Overlay plus ein, zwei System-Extensions:
overlay:
image: siderolabs/sbc-rockchip
name: turingrk1
customization:
systemExtensions:
officialExtensions:
- siderolabs/binfmt-misc
- siderolabs/util-linux-tools
Aus dem so erzeugten Schematic ziehe ich das metal-arm64.raw-Image, lege es per scp auf die SD-Karte des BMC und flashe damit alle Knoten in einer kleinen Schleife:
TALOS_VERSION="v1.13.2"
for node in $(seq 1 4); do
tpi power off --node "$node"
tpi flash --local --image-path "/mnt/sdcard/talos-${TALOS_VERSION}.raw" --node "$node"
tpi power on --node "$node"
done
picocom /dev/ttyS2 -b 115200, um den UART des jeweiligen Slots mitzulesen — unbezahlbar, wenn ein Image mal nicht durchstartet.Fazit
Aus dem Kickstarter-Board mit vier Raspberry-Pi-Modulen und einem gespiegelten SATA-Pärchen ist über den Umweg der Erkenntnis ein RK1-Cluster mit NVMe pro Knoten geworden, auf dem ein immutables Talos läuft. Die Hardware ist dabei bewusst unspektakulär und ersetzbar — genau so, wie es sein soll. Alles, was diesen Cluster interessant macht, lebt eine Schicht höher: in einem Git-Repository, das den Soll- und den Ist-Zustand beschreibt. Davon handelt der nächste Beitrag.