Zum Inhalt

ADR-012: Rolle von Kubernetes — hybrid und gestuft, Compose bleibt für Hostgebundenes

Feld Wert
Status accepted
Datum 2026-10-28
Betrifft homeserver, Cluster (3 × HP ProDesk 600 G6 Mini), Agenten-Fabrik
Schränkt ein ADR-001 (Compose statt Kubernetes)

Kontext

ADR-001 (März 2026) hat Kubernetes für das ganze Homelab verworfen. Die Roadmap 2026 hat das als Leitplanke übernommen: „Docker Compose bleibt, K8s bewusst verworfen (bräuchte ≥ 3 Nodes; bleibt Lern-/Job-Thema)“.

Seit Oktober 2026 hat sich die Lage geändert:

  • Drei Nodes sind da. 3 × HP ProDesk 600 G6 Mini, je i5-10600T, 16 GB RAM (bis 64 GB), 512 GB NVMe, 2,5-GbE-Modul. Der Hardware-Check ist abgeschlossen (homeserver#277). Aufgebaut wird der Cluster im Januar 2027 nach E9 im VLAN „lab“.
  • Die Agenten-Fabrik soll ab 2027 auf einem Talos-Cluster laufen (Konzept ~/repos/agenten-fabrik/konzept-agentenfabrik.md).
  • Robins größte Schmerzpunkte sind Update-Schulden auf allen Ebenen, fehlender Überblick und das Gefühl, dass „alles unaufgeräumt“ ist (Bestandsaufnahme 27.10.2026):
  • drei Ubuntu-Versionen auf drei Hosts
  • 10 offene Renovate-PRs im homeserver-Repo, der älteste vom 27.05.
  • 14 ausstehende Updates in Home Assistant
  • 242 von 1782 HA-Entitäten unavailable

Robin erwartet vom Cluster weniger Verwaltungsschmerz, automatischere Updates, Entlastung des NUC und eine Plattform für AI-Agents und zustandslose Apps.

Die Frage dieser ADR lautet: Welche Rolle spielt Kubernetes langfristig? Nur Lab und Fabrik, ausgewählte Heimdienste oder die Hauptplattform?

Belege: D1-Design sowie die Recherche Kubernetes im Homelab und das Dienste-Inventar.

Was die Daten sagen:

  • Der Speicherengpass des NUC braucht keinen Cluster.
  • Das 90-Tage-Tief von MemAvailable liegt bei 4,2 GiB, der Swap ist voll. Der Speicherdruck ist trotzdem null (Memory-PSI 0).
  • Die größten Posten sind Altlasten oder kaum genutzt: pz-server mit 7–8,7 GiB bei 5 Spielstunden im Monat, der gestoppte NUC-AI-Stack und ein ungenutzter Voice-Stack.
  • Der Pflegeaufwand sinkt mit Kubernetes nicht automatisch, er verlagert sich. Betreiber wechseln 2025/26 in beide Richtungen. Belastbare Messungen zum Pflegeaufwand im Homelab gibt es nicht. Die Plattform selbst erzeugt einen eigenen Update-Strom: Talos-Minor etwa alle 4 Monate, dazu Cilium, Storage und Operatoren.
  • Das Hybrid-Muster ist in der home-operations-Szene etabliert. Was einen Cluster-Ausfall überleben muss, läuft außerhalb, oft mit doco-cd verwaltet. Der häufigste reale Fehler ist DNS im Cluster, das den Kaltstart blockiert.
  • Die Kapazität ist knapp. Die Plattform braucht etwa 4–7 GB pro Node. Mit Reserve für einen Node in Wartung bleiben clusterweit nur ~18–24 GB für Workloads.

Entscheidung

Kubernetes wird hybrid und gestuft eingeführt. Docker Compose bleibt die Plattform für alles Hostgebundene und Hauskritische. ADR-001 wird dadurch eingeschränkt, nicht aufgehoben.

  1. Fehlerdomänen-Regel. Das Haus darf vom Cluster nicht abhängen. Wenn der Cluster ausfällt oder beim Kaltstart hängt, laufen weiter: DNS (Pi-hole/Unbound), Home Assistant, Zigbee2MQTT, Mosquitto, NUT, Tailscale-Subnet-Router, Traefik am NUC, Samba/Scanner, das Backup-Ziel und Monitoring/Alarmierung. Diese Dienste bleiben auf Compose. Die Cluster-Nodes nutzen einen Resolver, der nicht von ihnen selbst abhängt.
  2. Was auf den Cluster darf: grundsätzlich alles, was nicht an einen Host gebunden ist. Gemeint sind zustandslose Helfer, eigene Apps mit Datenbank und das Monitoring des Clusters selbst. Langfristig ist „mehr auf K8s“ ausdrücklich erlaubt, wenn das Review es trägt.
  3. Stufen:
    • Stufe 1a (Januar 2027, erst nach E9): Agenten-Fabrik, Cluster-Monitoring (nur Agents, die an VictoriaMetrics auf dem NUC liefern), pkv-app (Pilot für CloudNativePG; eigener Namespace mit Cilium default-deny gegenüber der Fabrik), speedtest-tracker. 2027 ist kein Cluster-Dienst öffentlich erreichbar.
    • Stufe 1b (nach der NUC-Neuinstallation, frühestens März 2027): *arr-Stack mit gluetun, sonarr, radarr, prowlarr, umlautadaptarr und sabnzbd. Robins Entscheid: erst einmal normal angehen und schauen.
    • Alles Weitere, darunter Immich, Paperless und DNS, nur nach dem Review.
  4. Messphase drei Monate, Review etwa April 2027. Kriterien:
    • Pflegezeit für Plattform und Compose (aus dem Umsetzungs-Log)
    • Update-Rückstand (Alter offener Renovate-PRs, Versionsabstand)
    • Störungen, die der Cluster verursacht oder selbst geheilt hat
    • Robins Bauchgefühl, ausdrücklich als Kriterium, weil Lernen ein echtes Ziel ist
  5. Vorrang bei RAM-Knappheit haben die Heimdienste. Fabrik-Jobs laufen mit niedriger PriorityClass und weichen bzw. warten. Alle Pods bekommen ab dem ersten Tag Requests und Limits. Verdrängte Fabrik-Jobs sind ein ehrliches Ergebnis der Messphase und kein Fehler.
  6. Speicher im Cluster:
    • lokaler Speicher je Node (local-path oder LVM)
    • Datenbanken replizieren selbst (CloudNativePG)
    • NFS von der UNAS für Medien, Dokumente und Backups, nie für Datenbanken oder SQLite
    • kein Longhorn und kein Ceph zum Start
    • Backups: Zum Start reicht ein pg_dump-CronJob → NFS → borg. Ein Object Store kommt erst bei Bedarf, weil die UNAS Pro keinen S3-Server hat. Volumes einzelner Replikas sichert VolSync → UNAS.
  7. Hardware wird nur bei messbarem Engpass ausgebaut (RAM, zweite NVMe oder 2,5″-SATA). Die Auslöser stehen im Design, Abschnitt 12.

  8. Revisionsoptionen mit Auslöser, frühestens beim Review:

    • (a) DNS in den Cluster
    • (b) der NUC als Cluster-Node mit Taints für hostgebundene Dienste

    Bedingung für beide: Das Haus übersteht nachweislich einen Kaltstart des Clusters. Bis dahin bleibt der NUC ein Compose-Host und wird mit Ubuntu 26.04 neu installiert. 9. Compose-Hosts behalten GitOps per doco-cd (E2c/E2d). Der Cluster ersetzt doco-cd nicht. 10. Betrieb: Der Cluster hängt nicht an der USV. Als Lab darf er bei Stromausfall hart ausgehen, im BIOS ist „Power On after power loss“ gesetzt. Secrets kommen aus Infisical mit einer Identität je Vertrauenszone (Cluster-Heimdienste und Fabrik getrennt), damit der Free-Plan reicht.

Beim Aufbau im Januar 2027 offen gelassen sind: Argo CD oder Flux, Omni oder talhelper, und die Wahl der Vorlage (z. B. onedr0p/cluster-template). Dafür gelten zwei Vorgaben. Die Entscheidung muss die Kapazität mitdenken, denn Flux spart gegenüber Argo CD etwa 0,5 GB. Und das Fabrik-Konzept wird auf den Stand dieser ADR gebracht.

Alternativen

Option Ergebnis
Nur Lab + Fabrik, alle Heimdienste bleiben Compose verworfen: Robin will zustandslose Apps und eigene Apps ausdrücklich auf dem Cluster betreiben, auch wegen des Lerneffekts. Die Fehlerdomänen-Regel schützt das Haus ebenso gut
Hybrid, fest (alles Zustandslose sofort, kein Review) verworfen: Die Kapazität ist knapp (18–24 GB), und der Pflegeaufwand der Plattform ist unbelegt. Ohne Messphase wäre die Entscheidung nicht datenbasiert
Hauptplattform (alles außer Hostgebundenem, auch Immich, Paperless, DBs) verworfen für 2027: braucht replizierten Speicher und mehr RAM. Fotos und Dokumente mit dem höchsten Datenwert würden in die jüngste Plattform wandern. Bleibt als mögliche Folge eines positiven Reviews offen
Kein Cluster für Heimdienste, Update-Schmerz nur per doco-cd + Renovate doco-cd kommt ohnehin für alle Compose-Hosts. Der Cluster ergänzt es, statt es zu ersetzen
Home Assistant, Zigbee2MQTT oder Pi-hole im Cluster verworfen: braucht hostNetwork oder Multus, USB-Device-Plugins mit dokumentierten Fehlern nach Reboots, und DNS verursacht Deadlocks beim Kaltstart. Bleibt Compose

Konsequenzen

Positiv:

  • Das Haus bleibt unabhängig vom Lab. Experimente und Upgrades am Cluster schalten Lars weder das Internet noch die Heizung ab.
  • Die Fabrik bekommt Isolation vom Inferenz-Host, und Robin bekommt ein echtes Kubernetes-Lernfeld mit echten Workloads.
  • Für die Dienste im Cluster werden Updates von Betriebssystem und Plattform zu Renovate-PRs (Talos über tuppr oder Omni).
  • Die Entscheidung über mehr Kubernetes fällt auf Basis von Daten (Review April 2027) statt aus dem Bauch.

Negativ:

  • Eine Plattform mehr. Neben Compose auf NUC, aiserver und VPS kommt Talos mit 10–20 Komponenten und eigenem Update-Strom dazu. Zunächst steigt damit der Aufwand für den Überblick.
  • Die Kapazität ist von Anfang an knapp. Stufe 1b mit sabnzbd (Spitze 9,9 GB) und 2–3 Fabrik-Worker (~6 GB je Job) passen zu Spitzenzeiten nicht gleichzeitig. Der RAM-Auslöser kann früh feuern.
  • Replikas, die an einen Node gebunden sind (z. B. *arr mit SQLite auf local-path), überleben einen Node-Ausfall nicht besser als heute unter Compose. Dafür brauchen sie einen eigenen Backup-Weg (VolSync).
  • Der Namespace für *arr muss wegen gluetun privileged sein (NET_ADMIN, /dev/net/tun), getrennt vom gehärteten Fabrik-Namespace.