Zum Inhalt

Recherche: Kubernetes vs. Docker Compose im Homelab – Grundlage für ADR

Arbeitsstand der Recherche

Dieser Bericht ist eine Belegsammlung aus der D1-Session (27./28.10.2026). Er enthält Einschätzungen, die später anders entschieden wurden. Verbindlich ist das D1-Design.

Stand: 27.10.2026 · Recherche über Exa (Primärquellen bevorzugt) · Alle Datumsangaben beziehen sich auf die Quelle.

Kennzeichnung: - [B] = belegt durch die angegebene Quelle - [E] = eigene Einschätzung / Schlussfolgerung aus mehreren Quellen - „o. D." = Quelle ohne erkennbares Veröffentlichungsdatum

1. State of the Art 2025/2026: Kubernetes vs. Docker Compose für Single-Operator

Befunde

Rückkehrer zu Compose (Kubernetes → Compose): - [B] Karan Sharma („State of My Homelab 2025", 04.10.2025): nach k3s- und Nomad-Iterationen auf Git-basiertes Compose standardisiert; „operational overhead proved unnecessary for my use case". https://mrkaran.dev/posts/state-homelab-2025/ - [B] Ben Prisby („Homelab Tour 2025", 02.09.2025): k3s auf 4 Pis und Swarm ausprobiert, zurück zu Compose „to reduce deployment complexity". https://benprisby.com/blog/homelab-tour-2025/ - [B] Pete Keen (o. D.): „Kubernetes is Too Hard. I built a system that I didn't actually know how to maintain"; alles Wichtige zurück auf Compose. https://www.petekeen.net/homelab-resolved/ - [B] sakthisaran.in (o. D., MicroK8s): wiederholte dqlite-Korruption; „am I running a homelab, or is the homelab running me?" – Rückkehr zu Compose mit festen Hosts; benennt ehrlich, was verloren geht (kein Self-Healing, keine Migration). https://blog.sakthisaran.in/why-i-m-ditching-kubernetes-for-my-home-lab-and-what-s-replacing-it - [B] techWithNeer (Medium, 14.08.2025): Single-Node, gemessene Mehrkosten K8s vs. Compose: Basis-RAM 2,1 → 4,8 GB, Config-Zeilen 45 → 312. Achtung: Single-Node, Erfahrungswerte eines Einzelnen. https://medium.com/@neerupujari5/why-i-rewrote-my-entire-home-lab-in-kubernetes-and-immediately-regretted-it-b24fd97e68e2

Migrierte, die bleiben (Compose → Kubernetes): - [B] Stanislas (20.04.2025, Single-Node k3s + Flux + Renovate): Grund war fehlendes GitOps bei Compose; App-Updates „from 20 minutes down to 10 seconds" (Renovate-PR mergen). https://stanislas.blog/2025/04/moving-to-k8s/ - [B] Yoga Novaindra (22.07.2026, 60+ Apps): erster Monat „fighting the platform", danach „almost entirely hands-off"; Fazit: für Plex+Nextcloud auf einem NUC nicht lohnend, ab vielen Apps ja. https://ygnv.my.id/replacing-docker-compose-with-k8s-was-it-actually-worth-it/ - [B] Brandon Lee / VirtualizationHowto (03.04.2026): Talos + Omni, Talos/K8s-Upgrade „ein Button"; aber „don't think you will ever choose Kubernetes because it makes everything easier". https://www.virtualizationhowto.com/2026/04/i-replaced-docker-with-kubernetes-in-my-home-lab-and-it-wasnt-what-i-expected/ - [B] RazeLighter777/iaas (GitHub, 2025): Compose wurde bei wachsender Integration „fragile"; K8s „a good decision, but only once it became necessary"; ~9 Monate ohne größere Ausfälle. https://github.com/RazeLighter777/iaas - [B] Rajesh Medampudi (26.08.2026, Talos-Feldbericht, 5 Monate): Upgrade-Modell „the safest I have used"; Schmerz: kein Shell-Debugging, großer Konfigurationsraum, Bare-Metal-NIC/Disk-Fragen bleiben beim Betreiber. https://rajesh.medampudi.com/blog/talos-linux-production-field-report/

Abwägende Gesamtdarstellung: - [B] Thomas Byern (13.08.2026): „For many homelabs, Docker Compose remains the more maintainable answer." Legitime Gründe für K8s: gezieltes Lernen, Workload-Form (viele verbundene Dienste, gemeinsame Ingress-/Secret-/Health-Konventionen), kontrolliertes Experimentieren. Nicht tragfähig: „Ich habe mehrere Maschinen", „HA" (wenn Switch/NAS/USV Single Points bleiben), „professioneller als Compose". https://byern.dev/does-kubernetes-still-make-sense-in-a-homelab-k3s-and-talos-as-two-minimal-but-serious-options/

Typische Betriebsschmerzen (belegt): - Upgrades: Talos/K8s-Versionskopplung – falsch gepinntes talosctl führte zu nicht mehr upgradebarem Cluster, Neuinstallation nötig (Ian Preston, 23.03.2025). https://blog.ianpreston.ca/posts/2025-03-23-talhelper.html · Boot-Loop beim Talos-1.8-Upgrade wegen fehlender Image-Factory-Treiber (Jerome Ng, 09.11.2024). https://www.jerome-ng.com/articles/2024-11-09-homelab-setup - etcd/Quorum: dqlite-Korruption bei MicroK8s (sakthisaran, o. D.); Kaltstart-Deadlocks (siehe Frage 2). - Storage: siehe Frage 4 (Longhorn-Leaks, Performance-Einbußen, SQLite auf NFS). - Debugging ohne Shell auf Talos (Medampudi, 26.08.2026). - Extensions können beim Boot still scheitern (Tailscale-Extension, curtis.engineer, o. D., Ereignis 28.02.2026). https://curtis.engineer/homelab/build-talos-cluster/

Belastbare Zahlen zu „weniger Verwaltungsaufwand": - [B] Es gibt keine systematische Erhebung für Homelabs. Vorhanden sind Einzelberichte (Stanislas: 20 min → 10 s pro App-Update; Novaindra: „hands-off" nach ~1 Monat Aufbau). - [B] Einzige quantifizierte Renovate-Toil-Studie ist aus dem Enterprise-Umfeld: GitLab Infra (Epic, abgeschlossen 14.05.2025) – 1.300 Renovate-MRs/Monat, 850 menschlich bearbeitet, >4.600 min/Monat; der Großteil entfällt auf Kubernetes-MRs (260/Monat, 3.500 min). https://gitlab.com/groups/gitlab-com/gl-infra/-/work_items/1533 - [E] Daraus folgt: K8s verschiebt Aufwand von „manuell updaten" zu „PR-Review + Plattformpflege (Talos, K8s, Cilium, Longhorn, Operatoren)". Die Plattformschicht selbst erzeugt laufend eigene Renovate-PRs, die bei Compose gar nicht existieren.

Fazit Frage 1

  • [B] 2025/2026 gibt es Bewegungen in beide Richtungen; das Muster ist konsistent: Rückkehrer nennen Komplexität ohne konkreten Bedarf, Bleibende nennen GitOps/Renovate-Automation und Reproduzierbarkeit – meist nach 1–3 Monaten Aufbauphase.
  • [E] Für einen Kubestronaut ist die Lernkurve kein Argument; das Gegenargument ist der dauerhafte Plattform-Pflegeanteil (Talos, K8s-Minor alle ~4 Monate, Cilium, Longhorn, Operatoren). „Weniger Schmerz" ist nur zu erwarten, wenn der Cluster echte Compose-Glue ersetzt (viele Dienste, einheitliche Konventionen) – nicht, wenn er zusätzlich neben dem NUC betrieben wird. Bei einem Hybrid steigen die Betriebsflächen zunächst (zwei Welten).

2. Hybrid-Muster: Cluster für zustandslose Apps, Hostgebundenes außerhalb

Befunde

  • [B] bykaj/home-ops (Doku, o. D.): Kubernetes-Cluster plus Docker-Compose auf TrueNAS, verwaltet mit doco-cd. Begründung wörtlich: „Some must keep working when the cluster is down or being rebuilt (the registry mirror, S3 for database recovery, PXE boot). Others are simply NAS-local (BGP, hardware exporters)." Webhook für doco-cd läuft über den Cluster (Cloudflare Tunnel → Envoy Gateway), Fallback ist stündliches Polling. DNS-Einträge für Compose-Dienste schreibt ein Label-Watcher („dexd") in die UniFi-UDM. https://docs.bykaj.com/docker/
  • [B] fma965/f9-homelab (GitHub, o. D.): Flux für K8s + doco-cd für Docker auf TrueNAS; Docker hostet GPU-AI-Workloads und ser2net für den Zigbee-Adapter. https://github.com/fma965/f9-homelab
  • [B] Ethan Bailey (16.09.2026): Flux für K8s, doco-cd für Compose-Experimente, ein Repo. https://ebai.dev/entries/2026/09-16-over-engineering-my-homelab/
  • [B] Nicolo Lüscher (14.03.2026): k3s für die meisten Dienste; Home Assistant in eigener VM („needs direct access to things like USB devices and mDNS that don't play well with Kubernetes"); Pi-hole in LXC, „because it needs to be up before anything else boots". https://nicolo.swiss/blog/homelab
  • [B] Nasr Aldin (Doku, o. D.): Platzierung „by failure domain"; Regel: „if Kubernetes dies, you must still reach Git and backups". DNS (AdGuard/Technitium), Infisical, Object Storage außerhalb des Clusters. https://nasraldin.github.io/homelab/architecture/service-placement

Kaltstart-Abhängigkeiten (konkrete Vorfälle): - [B] Sean Patterson (14.06.2026): Pi-hole als Pod, Nodes nutzten Pi-hole als DNS (via Tailscale-Override) → Kaltstart-Deadlock: Pods brauchen DNS für Image-Pull, DNS ist ein Pod. Lief 3 Monate gut, weil das Image zufällig gecacht war. Fix: Nodes accept-dns=false und fester Upstream. https://seanpatterson.me/blog/dns-that-needed-dns - [B] vin-ediezca/homelab-k8s-pihole-dns (GitHub, o. D.): Designregel „cluster nodes do NOT use Pi-hole"; Notausgang: DHCP-DNS am Router auf „Auto" zurückstellen. https://github.com/vin-ediezca/homelab-k8s-pihole-dns - [B] dev.to „DNS first" (22.12.2025): „Running DNS inside Kubernetes first: bootstrap deadlock, cluster depends on itself, guaranteed pain." https://dev.to/hkhelil/building-a-kubernetes-homelab-the-hard-way-dns-first-or-everything-else-lies-to-you-3ng1 - [B] k3s-iac-public (o. D.): CoreDNS leitete an Node-resolv.conf weiter, LAN-Namen lösten im Cluster nicht auf; CoreDNS-Upstream fest auf internen Resolver gepinnt. https://github.com/ludorl82/k3s-iac-public

DNS-/Ingress-Brücke zwischen beiden Welten (gängige Bausteine): - [B] onedr0p/cluster-template enthält k8s_gateway + external-dns + envoy-gateway (README, Stand 2026) – typisches Muster: LAN-DNS leitet die Cluster-Zone an k8s_gateway weiter (Split-DNS), external-dns pflegt öffentliche/LAN-Records. https://github.com/onedr0p/cluster-template - [B] Cilium-LoadBalancer-IPs per BGP an UniFi (Talos-Cluster cl01tl, Doku o. D.; Stonegarden, 19.11.2025). https://docs.alexlebens.dev/Infrastructure/Configuration/bgp-routing/ · https://blog.stonegarden.dev/articles/2025/11/bgp-cilium-unifi/ - [E] Für Robins Setup naheliegend: Pi-hole/Unbound bleibt auf dem NUC (bzw. später auf einem kleinen dedizierten Host) und bekommt eine Conditional-Forward-Zone für die Cluster-Domain (k8s_gateway-LB-IP) oder external-dns schreibt per Pi-hole-/UniFi-Provider. Traefik auf dem NUC und Gateway im Cluster bleiben getrennte Ingress-Punkte; wer „eine URL-Welt" will, lässt Traefik bei Bedarf auf die BGP-LB-IP des Cluster-Gateways weiterleiten. Cluster-Nodes dürfen nicht auf Pi-hole als einzigen Resolver zeigen (UDM/Unbound direkt oder zweiter Resolver).

Was passiert beim Cluster-Ausfall? - [B] Laufende Pods bleiben bei Control-Plane-Ausfall am Leben, „nothing can be deployed/scaled/rescheduled" (k3s-iac-public, o. D.); bei Pi-hole-auf-K8s: „Control-plane down → Pi-hole keeps serving" (vin-ediezca, o. D.). - [E] Im Hybrid fallen nur die Cluster-Apps aus; HA, Zigbee, DNS, USV laufen weiter, solange (a) NUC-Dienste keine Laufzeitabhängigkeit in den Cluster haben (z. B. Monitoring, Auth, Secrets-Abruf beim Start), (b) doco-cd-Webhooks nicht ausschließlich über den Cluster laufen (bykaj hat deshalb Polling-Fallback). Kritisch prüfen: Wo liegt Infisical? Liegt es im Cluster, können weder Compose-Deploys (doco-cd zieht Secrets beim Deploy) noch ESO-Syncs nach einem Totalausfall laufen → Infisical gehört nach außen (VPS oder NUC), wie bei Nasr Aldin.

Fazit Frage 2

  • [B] Das Hybrid-Muster ist in der home-operations-Szene etabliert und dokumentiert (bykaj, fma965, Bailey, Lüscher): Hostgebundenes/Bootstrap-Kritisches (DNS, Registry-Mirror, Backups/S3, Hardware-Dienste) bleibt in Compose außerhalb, oft mit doco-cd verwaltet.
  • [B] Der häufigste reale Fehler ist die DNS-Kaltstart-Schleife; Gegenmittel: DNS außerhalb, Nodes mit eigenem Resolver.
  • [E] Für Robin passt Hybrid gut zu ADR-001 als Präzisierung statt Umkehr: „Compose bleibt Plattform für Haus-Infrastruktur; Cluster für Agentenfabrik + zustandslose/leicht-zustandsbehaftete Apps". Ausfall-Domänen müssen explizit dokumentiert werden (welcher Dienst darf vom Cluster abhängen).

3. Home Assistant, Zigbee2MQTT, Pi-hole auf Kubernetes

Befunde

Home Assistant: - [B] Offiziell nicht unterstützt für K8s; läuft aber als Container (QuadMeUp, 07.04.2025: privileged, nodeSelector auf Dongle-Node). https://blog.quadmeup.com/2025/04/07/how-to-run-home-assistant-in-kubernetes/ - [B] mDNS/SSDP/HomeKit erreichen das Pod-Netz nicht; Cilium leitet Multicast aus dem LAN nicht ins Overlay. Lösung entweder hostNetwork: true + dnsPolicy: ClusterFirstWithHostNet (HA-Community-Beitrag Matter/Thread mit externem OTBR auf Talos/Cilium, o. D.) oder Multus + macvlan als zweites Interface. https://community.home-assistant.io/t/running-matter-thread-with-an-external-otbr-alongside-home-assistant-on-kubernetes/1027093 - [B] Multus-Variante wird in home-ops-Repos genutzt (bjw-s Doku o. D.; buroa/home-ops DeepWiki 17.08.2026; joryirving/home-ops). Stolpersteine: Multicast-Route 224.0.0.0/4 nötig, kein Gateway in der Attachment-Definition (sonst bricht Cluster-DNS), sbr-Plugin für Source-Based-Routing, HomeKit-Bridge muss die LAN-IP explizit annoncieren – „at every one of them the broken state looked like success" (Udo Müller, o. D.). https://cs-ol.de/docs/kubernetes/pod-on-the-lan-macvlan/ · https://bjw-s.github.io/home-ops/notes-ramblings/howto/pod-multihome.html · https://deepwiki.com/buroa/home-ops/5.4-multus-cni-and-iot-network-attachment - [B] Matter-over-Thread benötigt zusätzlich IPv6-RA/Route-Information vom OTBR, die im Pod-Netz nicht ankommen (HA-Community, o. D.).

Zigbee2MQTT / USB: - [B] squat/generic-device-plugin: Issue #63 (07.03.2024) – nach Reboot „UnexpectedAdmissionError … no healthy devices", erst nach Neustart des Plugin-Pods behoben. https://github.com/squat/generic-device-plugin/issues/63 - [B] Akri: letzte Release November 2024, Gerät wird nach Pod-Ende verzögert freigegeben → Startfehler; Wechsel zu generic-device-plugin (rpi-homelab, 15.08.2026). https://codefloe.com/rpi-homelab/kubernetes-manifests/issues/8 - [B] Ausweg ohne USB: Ethernet-Koordinator (z. B. SLZB-06, serial.port: tcp://IP:6638 oder mdns://slzb-06) – Zigbee2MQTT wird dadurch ein normaler Pod. https://www.zigbee2mqtt.io/guide/configuration/adapter-settings.html · ser2net als Alternative; Z2M warnt ausdrücklich vor Serial-over-IP über WLAN/WAN/VPN (o. D.). https://www.zigbee2mqtt.io/advanced/remote-adapter/connect_to_a_remote_adapter.html

Pi-hole: - [B] Benötigt LoadBalancer-IP (MetalLB/Cilium-LB) für Port 53, externalTrafficPolicy: Local für echte Client-IPs, Recreate-Strategie (SQLite/FTL), keine echte Clusterfähigkeit – HA nur über zwei Instanzen + nebula-sync/orbital-sync (anakinfoxe, 22.05.2025; vin-ediezca o. D.; Jorge Lima 25.01.2026 für AdGuard). https://anakinfoxe.com/blog/high-availability-pihole-on-kubernetes/ · https://meshlaneous.dev/blog/dns-the-hard-way - [B] CoreDNS-Schleife: zeigt Node-resolv.conf auf Pi-hole, fluten Pod-Anfragen Pi-hole (accidentalcomplexity, o. D.). https://accidentalcomplexity.hashnode.dev/k3scluster-part-4

USV (NUT): - [B] Talos hat eine offizielle nut-client-Extension; NUT-Server bleibt am Host mit USB-USV (z. B. Compose instantlinux/nut-upsd), Talos-Nodes fahren als secondary herunter (siderolabs/extensions; Alex Lebens Doku o. D. mit gestaffeltem Shutdown). https://github.com/siderolabs/extensions/blob/main/power/nut-client/README.md · https://docs.alexlebens.dev/Hardware/eaton-ups/

Fazit Frage 3

  • [B] Machbar und in der home-ops-Szene verbreitet (HA mit Multus, Z2M mit Netzwerk-Koordinator) – aber jeder Baustein hat dokumentierte stille Fehlermodi (Multicast-Routen, Device-Plugin nach Reboot, DNS-Schleifen).
  • [E] Empfehlung für Robin: HA, Z2M, Mosquitto, NUT-Server, Pi-hole/Unbound, Tailscale-Subnet-Router bleiben auf Compose (Haus-kritisch, Partnerakzeptanz, Kaltstart). Talos-Nodes bekommen nut-client gegen den NUC-NUT-Server. Falls Z2M später doch in den Cluster soll: zuerst auf einen Ethernet-Koordinator umsteigen – das entkoppelt Z2M von Hardware unabhängig von der Plattformfrage.

4. Storage auf 3-Node-Mini-PC-Clustern (16 GB)

Befunde (Overhead)

  • [B] Onidel (26.09.2025), Basisinstallation 3 Nodes: Longhorn 200–400 MB/Node, OpenEBS 150–600 MB/Node, Rook-Ceph 1–2 GB/Node. https://onidel.com/blog/longhorn-vs-openebs-rook-ceph-2025
  • [B] KubeDojo (o. D.): local-path ~10 MB, TopoLVM/OpenEBS LVM ~50 MB, OpenEBS ZFS ~100 MB, Longhorn ~500 MB RAM/Node. https://kube-dojo.github.io/on-premises/storage/module-4.3-local-storage/
  • [B] Pim Widdershoven (19.05.2026, exakt Robins Profil: 3 Nodes, 16 GB, eine 500-GB-NVMe geteilt mit OS): Ceph bräuchte 6–8 GB/Node (osd_memory_target 4 GiB, Ceph rät von <2 GB ab) → 40–50 % des RAM; Longhorn „2–3 GB per node at modest scale" (Prozesse pro Volume); LINSTOR-Controller ~512 MB, Satellite ~256 MB, Replikation im Kernel (DRBD), <1 GB/Node unabhängig von der Volume-Zahl. Wahl: LINSTOR/Piraeus. Nachteil: kleiner Expertenkreis, Kernelmodul, DRBD-Wissen bei Recovery. https://www.pimwiddershoven.nl/entry/storage-on-talos-linux-with-linstor-and-drbd/
  • [B] Josh Dow (18.09.2025): Rook-Ceph auf 4 Nodes real ~22 GB RAM Allokation; Wechsel von Longhorn wegen Performance und „split-brain"-Problemen bei Netzpartitionen. https://blog.joshdow.ca/homelab-part-4/

Longhorn – Stand und Risiken: - [B] Versionen: v1.11 (Jan. 2026, V2-Engine Technical Preview, paralleles Rebuild), v1.12 (Mai 2026, V2-Engine GA), v1.12.1 (14.08.2026; Doku nennt Mindest-Kubernetes v1.34). https://github.com/longhorn/longhorn/wiki/Release-History · https://github.com/longhorn/longhorn/releases/tag/v1.12.1 - [B] V2/SPDK-Engine: ein Betreiber kehrte am 12.06.2026 zu V1 zurück – unterbrochene Rebuilds „permanently poison replica metadata", V2-Reaktoren verbrannten 4–5 Kerne/Node im Leerlauf (mitchross/talos-argocd-proxmox, Kommentar in values.yaml). https://github.com/mitchross/talos-argocd-proxmox/blob/fedcc608/infrastructure/storage/longhorn/values.yaml - [B] Longhorn v1.9.2 share-manager (RWX) wuchs auf 47 GB RAM bei 187-MB-Volume (Paperless-Daten, Talos 1.11, 3× NUC; Issue #11938, Okt. 2025). https://github.com/longhorn/longhorn/issues/11938 - [B] Performance-Overhead V1 vs. local-path (Talos 1.9.2, Longhorn 1.8.0, kbench): −80 bis −98 % IOPS/Bandbreite, Latenz ×12–×34 (Discussion #10306, 31.01.2025). https://github.com/longhorn/longhorn/discussions/10306 - [B] onedr0p/cluster-template empfiehlt: Enterprise-SSDs, Consumer-SSDs „carry risks such as latency spikes, corruption and fsync delays"; replizierter Storage „should always use dedicated disks separate from control plane and etcd nodes". https://github.com/onedr0p/cluster-template/blob/main/README.md - [B] Longhorn auf Talos: Extensions iscsi-tools + util-linux-tools, UserVolumeConfig ab Talos 1.10, Namespace privileged (Longhorn-Doku 1.12; Sidero-Doku). https://longhorn.io/docs/1.12.0/advanced-resources/os-distro-specific/talos-linux-support/

Datenbanken / CloudNativePG: - [B] CNPG-Doku: Storage-Replikation zusätzlich zur Postgres-Replikation erzeugt Write-Amplification; empfohlen: Longhorn-Replikas = 1 + strict-local oder lokale PVs, Pod-Anti-Affinity. https://github.com/cloudnative-pg/cloudnative-pg/blob/main/docs/src/storage.md - [B] Default Longhorn 3 × CNPG 3 = 9 Kopien (Andrei Vasiliu, 24.02.2026). https://andreivasiliu.com/the-database-dilemma-mastering-postgresql-on-kubernetes-with-cloudnativepg/

NFS (UNAS): - [B] SQLite auf NFS → Korruption/„database is locked" (Sonarr-Issue #2797; Funky Penguin Cookbook o. D.; woitzik.dev 10.09.2026: Garage-S3-Metadaten durch NFS korrumpiert, alle .db-Apps auf local-path verlegt). https://woitzik.dev/blog/nfs-vs-local-path-sqlite-trap/ · https://github.com/Sonarr/Sonarr/issues/2797 - [B] Robins eigene Erfahrung (Memory, #270): VictoriaMetrics/-Logs zwei Tage tot nach NFS-„stale handle". [E] NFS v3 ohne verlässliches Locking ist für App-Konfigurationen und DBs im Cluster ungeeignet; für Medien/Dokumente/Backups gut.

Fazit Frage 4

  • [E] Empfehlung 2026 für 3 × 16 GB, eine NVMe pro Node: Kein Rook-Ceph (rechnet sich erst ab ~64 GB/Node + dedizierte Disks + 10 GbE, so auch Widdershoven). Zwei Klassen statt einer: (1) lokaler Storage (local-path oder OpenEBS LocalPV-LVM/TopoLVM auf der zweiten NVMe) für CNPG (Replikation durch Postgres) und Single-Replica-Apps mit eigenem Backup (VolSync/Kopia → UNAS/S3); (2) NFS-CSI auf UNAS nur für Medien/Bulk/Backups, nie für SQLite. Replizierten Block-Storage (Longhorn V1 oder Piraeus/LINSTOR) nur dort, wo eine App ohne eigene Replikation Node-Ausfälle überleben muss – und auf der zweiten, dedizierten NVMe, nicht auf der Talos-Systemplatte.
  • [E] Longhorn V1 ist die bequemere, besser dokumentierte Wahl; LINSTOR die RAM-sparsamere. Für die Agentenfabrik (Jobs = weitgehend ephemer) reicht in Phase 1 local-path + NFS; replizierter Storage kann warten, bis ein konkreter zustandsbehafteter Dienst ihn braucht.

5. Talos Linux im Homelab 2026

Befunde

Versionen: - [B] Talos v1.12.0 (22.12.2025, K8s 1.35.0, Linux 6.18.1); v1.12.11 (05.08.2026). https://github.com/siderolabs/talos/releases/tag/v1.12.0 - [B] Talos v1.14.0 (03.09.2026): Kubernetes 1.37.0, Linux 6.18.48, etcd 3.7.1, containerd 2.3.4. Installer-Image wird nicht mehr veröffentlicht, nur noch Image Factory. https://github.com/siderolabs/talos/releases/tag/v1.14.0 · https://docs.siderolabs.com/talos/v1.14/getting-started/what's-new-in-talos - [B] Aktuell stabil: v1.14.5 (26.10.2026), Linux 6.18.58, etcd 3.7.3; v1.15.0-alpha.2 (27.10.2026) mit Talos-Hypervisor-Alpha. https://github.com/siderolabs/talos/releases - [E] Takt: ~ein Minor-Release alle 4 Monate (1.12 Dez. 2025 → 1.14 Sep. 2026), Patches etwa wöchentlich bis zweiwöchentlich.

Upgrade: - [B] Talos-Minors müssen sequenziell durchlaufen werden; Überspringen nicht unterstützt (tuppr-Doku, Stand Okt. 2026). https://tuppr.home-operations.com/versioning/ - [B] Ab 1.8 ist --preserve beim Upgrade Standard (Longhorn-Issue #11015). https://github.com/longhorn/longhorn/issues/11015 - [B] Neue Konfigurationsdokumente in 1.12 (Netzwerk-Multi-Doc, alte machine.network-Felder deprecated); Konfigurationsschema versioniert – alte Anleitungen gegen neues Talos „a reliable way to waste an afternoon" (Medampudi, 26.08.2026). - [B] Talos 1.13+ baut Kernel mit Clang/LLD – auf alter Apple-Firmware nicht bootfähig (Ali Aljaffer, 15.08.2026). [E] Für HP ProDesk 600 G6 (UEFI, Intel 10. Gen) nicht relevant, zeigt aber: Firmware-Eigenheiten fallen auf den Betreiber.

Grundlast RAM pro Node (16 GB): - [B] Offizielle Mindestwerte: Control Plane 2 GiB/2 Kerne, empfohlen 4 GiB/4 Kerne; Worker 1/2 GiB (Talos-Doku v1.13). https://docs.siderolabs.com/talos/v1.13/getting-started/system-requirements - [B] onedr0p/cluster-template: Minimum je Control/Worker-Node 4 Kerne, 16 GB, 256-GB-SSD. https://github.com/onedr0p/cluster-template - [B] Cilium: Messung 3-Node-Cluster (KubernetesLab, 04.08.2026): Cilium mit Kube-Proxy-Replacement ~1.705 MiB Working Set clusterweit im Leerlauf (≈ 570 MiB/Node), Hubble +22 MiB. https://kuberneteslab.dev/en/blog/cni-standing-cost/ - [B] API-Server kann bis ~2 GiB belegen (codefloe-Doku, Talos 1.13.10, 3,7-GiB-Nodes). https://www.codefloe.com/codefloe/kubernetes/src/branch/fix/longhorn-backup-store/docs/control-plane-memory.md - [B] GitOps-Controller: Argo CD ~600 MB–1 GB idle, Flux ~150–350 MB (bigiron, 24.05.2026). https://www.bigiron.cc/guides/argocd-vs-flux-vs-just-a-cron-pulling-git-for-the-homelab - [E] Überschlag je Node (alle 3 Nodes Control Plane + Worker): Talos/kubelet/containerd ~0,5 GB, etcd + API-Server + Controller ~1,5–2,5 GB, Cilium ~0,6 GB, Longhorn V1 0,4–2 GB (je nach Volume-Zahl), Monitoring-Agents/VictoriaMetrics-Anteil ~0,5–1 GB, Argo CD anteilig ~0,3 GB, cert-manager/ESO/ARC/Gateway ~0,3–0,5 GB → ≈ 4–7 GB Plattform pro Node, also 9–12 GB für Apps. Mit N-1-Reserve (ein Node in Wartung, Workloads müssen auf zwei passen) bleiben clusterweit realistisch ~18–24 GB für Workloads. Das reicht für zustandslose Apps + einige Agent-Jobs, aber nicht für eine nennenswerte Entlastung des NUC und parallele KI-Agenten. Aufrüsten auf 32 GB/Node ist die billigste Stellschraube (Option mit Trigger, nicht sofort).

Typische Stolpersteine (belegt): - talosctl-Version nicht gepinnt → K8s/Talos-Skew (Preston, 23.03.2025). - Image-Factory-Schematic ohne nötige Extensions → Boot-Loop (Ng, 09.11.2024); cluster-template rät: „bare-minimum system extensions". - Installer schreibt auf USB statt NVMe; Disk-Reihenfolge (curtis.engineer, Ereignis 29.03.2026). - gVisor: offizielle Extension siderolabs/gvisor, benötigt user.max_user_namespaces > 0 – das schwächt die KSPP-Härtung für den ganzen Node; empfohlen: gVisor nur auf dedizierten, getainteten Sandbox-Nodes, RuntimeClass per ValidatingAdmissionPolicy erzwingen (h2security, 24.09.2026). https://github.com/siderolabs/extensions/blob/main/container-runtime/gvisor/README.md · https://h2security.io/secure/gvisor-untrusted-workloads-kubernetes/

Alternativen: - [B] Omni Hobby (bis 10 Nodes, 2 Nutzer) ist seit TalosCon (Pressemitteilung 23.10.2026) kostenlos; Sidero Labs gehört inzwischen zu Yardi; Talos bleibt MPL-2.0. Self-hosted Omni für Homelab ohne Lizenz erlaubt (Sidero-Doku). https://www.prnewswire.com/news-releases/sidero-labs-demonstrates-talos-hypervisor-and-talos-director-live-at-taloscon-2026-302917599.html · https://docs.siderolabs.com/omni/self-hosted/options-for-running-omni - [B] k3s: klassischer Linux-Host + Single-Binary; behält SSH/apt/Drift (Byern, 13.08.2026; Simeon Ivanov, 18.01.2026: Wechsel k3s→Talos wegen Drift). https://simeonivanov.org/posts/migrating-k3s-to-talos-linux/ - [B] Kairos: CNCF-Sandbox seit 04/2024, immutable Meta-Distribution (bootc/OCI), k3s/k0s als Provider; „still a young project" (vincentvdk, 06.09.2026). https://vincentvdk.tech/blog/2026-09-06-kairos-part-1/

Fazit Frage 5

  • [B] Aktuell Talos 1.14.5 / Kubernetes 1.37; Upgrade-Mechanik gilt als die sicherste unter Betreibern, verlangt aber sequenzielle Minors und striktes Versions-Pinning; Debugging ohne Shell ist der meistgenannte Schmerz.
  • [E] Talos ist für einen Kubestronaut die richtige Wahl gegenüber k3s (kein Host-Drift, deckungsgleich mit Robins Philosophie „file-based state"). Omni Hobby (jetzt kostenlos) senkt den Upgrade-Aufwand weiter, ist aber SaaS-Abhängigkeit – für die Cloud-vs-lokal-Grenze unkritisch, solange keine Vault-Daten über den Cluster laufen. RAM ist der Engpass: 16 GB/Node geht, ist aber knapp; gVisor-Nodes sollten logisch getrennt werden – bei nur 3 Nodes ein echter Zielkonflikt (Härtung vs. Kapazität).

6. Update-Automatisierung: Renovate + Argo/Flux vs. Renovate + Compose-GitOps

Befunde

Kubernetes-Seite: - [B] tuppr (home-operations, Doku Stand Okt. 2026): Controller für Talos- und K8s-Upgrades per CRD (TalosUpgrade, KubernetesUpgrade), health-gated, drain → upgrade → reboot → verify, Renovate bumpt Versionen über # renovate:-Kommentare; erzwingt keine sicheren Upgrade-Pfade (separateMinorPatch in Renovate nutzen). https://tuppr.home-operations.com/ - [B] Omni: Talos-/K8s-Upgrade per Klick (VirtualizationHowto, 03.04.2026). - [B] Abgestuftes Automerge-Modell (woitzik.dev, 24.09.2026): Patch/Minor/Digest zustandsloser Apps mit 3 Tagen Soak automatisch; DBs, Auth, Storage, Apps mit Migrationen (Paperless, Immich) immer PR + Review; Majors immer manuell. https://woitzik.dev/blog/operating-model-auto-update-human/ - [B] Flux vs. Argo CD: Argo CD Minor alle 3 Monate, Support nur für die 3 letzten Minors; seit 3.3 Upgrade nur per Server-Side-Apply; Flux erlaubt Upgrade von jeder 2.x auf jede 2.x (revisit.tech, 07.10.2026). https://revisit.tech/blog/argo-cd-and-flux-revisit-your-gitops-controller-before-you-scale-or-migrate/ · RAM: Argo ~600 MB–1 GB, Flux ~150–350 MB (bigiron, 24.05.2026). Die home-ops-Templates nutzen fast durchgängig Flux (cluster-template).

Compose-Seite: - [B] doco-cd: Webhook/Polling, Auto-Discovery von Stack-Verzeichnissen, SOPS, externe Secret-Provider inkl. Infisical, Sync-Windows, Pre/Post-Skripte, Prometheus-Metriken, Selbst-Update mit Rollback (Doku/README, Stand 2026). https://github.com/kimdre/doco-cd · https://github.com/kimdre/doco-cd/blob/main/wiki/docs/External-Secrets/Infisical.md - [B] Grenzen laut Review: Pre-1.0, ein Code-Owner, kein UI (cloudzy, o. D.). https://cloudzy.com/blog/doco-cd-review/ - [B] Fallstricke aus dem Betrieb (bykaj, o. D.): Umbenennen eines Stack-Verzeichnisses löscht den alten Stack (Projektname = Verzeichnisname, benannte Volumes bekommen neues Präfix → leer); webhook_filter: ^refs/heads/main$ nötig, sonst deployen Renovate-Branches vor dem Merge. - [B] Komodo: GitOps erfordert je Stack eine TOML-Definition (doppelte Pflege), braucht MongoDB/FerretDB (Veerendra K, 02.05.2026; DietPi-Diskussion 05.03.2026). Dockhand: UI, SQLite, Auto-Update mit CVE-Scan vor Anwendung, aber (Stand Test) keine externen Secret-Provider. https://veerendra2.github.io/gitops-for-homeservers-part2/

OS-Updates außerhalb K8s: - [E] Bei Compose bleiben Ubuntu-Updates (unattended-upgrades, needrestart, Kernel-Reboots, Release-Upgrades – siehe Frage 8) manuelle Pflege. Bei Talos werden OS + K8s durch tuppr/Omni zu Renovate-PRs. Das ist der größte strukturelle Automatisierungsgewinn des Clusters – aber er wiegt nur die zusätzlichen Plattformkomponenten auf, die überhaupt erst Updates erzeugen.

Fazit Frage 6

  • [B] Beide Wege erreichen „Renovate-PR mergen = Deploy". Auf K8s ist der Weg reifer (Flux/Argo, Health-Checks, tuppr für OS-Upgrades); auf Compose ist doco-cd 2026 der Werkzeugstandard der home-ops-Hybride, aber pre-1.0 und Ein-Personen-Projekt.
  • [E] Für realen Pflegeaufwand entscheidet weniger das Werkzeug als die Automerge-Politik (woitzik-Tiering) und die Zahl der Plattformkomponenten. Renovate + doco-cd auf dem NUC reduziert den Pflegeaufwand für die ~60 bestehenden Container sofort und ohne Migration; der Cluster bringt zusätzlich automatisierbare OS-Upgrades, aber auch 10–20 neue Plattform-Abhängigkeiten mit eigenem Update-Strom. Flux statt Argo CD würde RAM sparen und den Upgrade-Rhythmus entschärfen; Argo CD bleibt sinnvoll, wenn die UI für die Agentenfabrik (Sichtbarkeit der Jobs/Apps) gewünscht ist.

7. Referenz-Setups / Templates

Befunde

  • [B] onedr0p/cluster-template (aktiv 2026, seit 2021): Talos + Flux, makejinja rendert aus einer cluster.toml (Pydantic/CUE-validiert); Komponenten: Cilium, cert-manager, spegel, reloader, CoreDNS, metrics-server, k8s_gateway, envoy-gateway, external-dns, cloudflared; SOPS für Secrets; mise/just als Task-Runner; Git-Provider wählbar (GitHub, GitLab, Gitea, Forgejo …). Voraussetzungen: Domain, Cloudflare-Account nur für öffentliche Apps, Minimum 4 Kerne/16 GB/256 GB pro Node, Bare Metal empfohlen, Enterprise-SSDs bevorzugt; Bootstrap „10+ minutes is normal". https://github.com/onedr0p/cluster-template
  • [B] home-operations-Ökosystem: tuppr (Talos-Upgrades), app-template (bjw-s), viele öffentliche home-ops-Repos (buroa, joryirving, bjw-s, bykaj) mit Multus für HA, VolSync-Backups, Flux. (Quellen s. o.)
  • [B] Alternative Argo-CD-Referenzen: mitchross/talos-argocd-proxmox (Longhorn-Erfahrungen dokumentiert, s. Frage 4); dlford.io „How to Home Lab Season 2" (13.03.2026, Talos + Argo CD, empfiehlt 16 GB CP / 32 GB Worker). https://www.dlford.io/how-to-home-lab-kubernetes/
  • [B] khuedoan/homelab und budimanjojo/home-cluster: in dieser Recherche nicht mit aktuellem Stand 2026 verifiziert (keine belastbaren Treffer mit Datum) – vor Nutzung Commit-Aktivität prüfen.

Fazit Frage 7

  • [B] cluster-template ist die reifste, aktiv gepflegte Vorlage und setzt Flux + SOPS + Cloudflare-Muster voraus; sie geht davon aus, dass der Cluster die Hauptplattform ist (alle Nodes schedulbar, Ingress/DNS im Cluster).
  • [E] Für Robins geplanten Stack (Argo CD, ESO + Infisical, Cilium-BGP, Longhorn, Hybrid) passt das Template nur teilweise – Flux→Argo und SOPS→ESO wären Umbauten gegen die Vorlage, die deren Hauptvorteil (Renovate-gepflegte Upstream-Konventionen) aufzehren. Optionen: (a) Template weitgehend übernehmen (Flux, SOPS für Bootstrap, ESO zusätzlich), (b) nur talhelper/Talos-Teil übernehmen und den Rest selbst bauen. (a) minimiert Pflege, (b) maximiert Passung.

8. Ubuntu-Upgrade-Pfad 22.04 → 26.04 LTS (NUC als Docker-Host)

Befunde

Pfad und Zeitpunkt: - [B] Offizielle Release Notes 26.04 (23.04.2026): „If you're currently using … Ubuntu 22.04 LTS … you must first upgrade to either Ubuntu 24.04 LTS or 25.10 before you can proceed to 26.04 LTS." https://documentation.ubuntu.com/release-notes/26.04/ - [B] LTS→LTS-Upgrades werden erst mit dem ersten Point-Release angeboten (Ubuntu-Desktop-Doku 26.04). https://ubuntu.com/desktop/docs/en/26.04/how-to/upgrade-ubuntu-desktop/ - [B] 26.04.1 erschien am 27.08.2026; laut SSD Nodes (27.10.2026) listet meta-release-lts 26.04.1 mit Supported: 1, do-release-upgrade bietet es auf 24.04 normal an; die Öffnung wartete auf Backports einer rust-coreutils-Regression. Der 26.04-Upgrader akzeptiert nur noble, oracular, plucky, questing als Quelle – jammy wird abgelehnt. https://www.ssdnodes.com/learn/upgrade-ubuntu-22-04-to-26-04 - [B] Früherer Bericht (atpeaz, 18.08.2026): -d war noch nötig; Provider-Mirror wurde vom Upgrader still deaktiviert → irreführender Fehler ubuntu-minimal was not downloadable. https://www.atpeaz.com/ubuntu-22-04-to-26-04-lts-upgrade/ - [B] Support-Ende 22.04: Standard-Support Mai 2027 (ubuntu.com/about/release-cycle) bzw. „April 2027" (22.04-Release-Notes). https://ubuntu.com/about/release-cycle

Bekannte Probleme beim Sprung (Docker-Host-relevant): - [B] cgroup v1 entfernt (systemd 259); Docker ≥ 20.10 mit cgroup v2 unproblematisch, Test auf frischem 26.04 ohne Befund (trendboxgeek, o. D.; XDA, 20.04.2026). [E] 22.04 nutzt standardmäßig bereits cgroup v2 → für Robins NUC voraussichtlich kein Thema; Gegenprobe stat -fc %T /sys/fs/cgroup/ → cgroup2fs. - [B] Docker-CE-Repo nach do-release-upgrade auf Enabled: no, muss auf resolute umgestellt werden; Testupgrade 3 min 32 s, 15 s Portausfall (prodevs, 10.10.2026). Docker CE unterstützt 26.04 offiziell (docs.docker.com, Stand 2026). https://prodevs.in/tutorials/ubuntu-24-04-to-26-04-docker-host/ · https://docs.docker.com/engine/install/ubuntu - [B] /etc/sysctl.conf wird beim Upgrade gelöscht (procps remove-on-upgrade), auch bei „keep current version" – eigene Kernelparameter fallen auf Default zurück (z. B. fs.inotify.max_user_instances 8192 → 128, IPv6-Forwarding 1 → 0). Fix: Parameter nach /etc/sysctl.d/. Zudem Netzwerkinterface-Namen-Drift (enp1s0 → enp2s0) nach Upgrade (e-whisper, 4 N100-Nodes, 10.10.2026). https://e-whisper.com/posts/32664/ · https://bbs.csdn.net/weixin_33806859/article/details/100550345 - [B] dracut ersetzt initramfs-tools (eigene Hooks migrieren; dracut -f statt update-initramfs); das dracut-networkd-Modul kann zusätzlich per DHCP eine zweite IP ziehen (AskUbuntu, o. D.). https://askubuntu.com/questions/1567304/ubuntu-26-04-dracut-network-configuration - [B] netplan: gateway4 deprecated, in netplan 1.2 nur Warnung (e-whisper, 10.10.2026); ein Bericht eines übersprungenen 22.04→26.04-Upgrades meldet Parse-Fehler wegen gateway4 plus 750 unkonfigurierte Pakete inkl. sudo/openssh/netplan → nur Konsole half (brainosi, 13.08.2026). https://blog.brainosi.com/en/2026-08-13-ubuntu-2204-to-2604-upgrade-recovery/ - [B] sudo-rs und rust-coreutils als Standard; in 26.04 bleiben cp, mv, rm, df, true noch GNU (Ubuntu-Server-Doku; Discourse 22.04.2026). https://discourse.ubuntu.com/t/an-update-on-rust-coreutils/80773 - [B] APT 3.x: apt-key entfernt; Fremdquellen müssen auf signed-by umgestellt sein (ubuntu.fan, o. D.). - [B] Kernel 7.0 (GA) statt 6.8 (prodevs, 10.10.2026). - [B] Intel QSV/Tiger Lake (i5-1135G7): Jellyfin-Doku führt TGL als voll unterstützt (OneVPL ab Gen 12); keine 26.04-spezifischen Bruchmeldungen gefunden. https://jellyfin.org/docs/general/post-install/transcoding/hardware-acceleration/intel/ [E] Risiko gering, da Jellyfin seinen eigenen Treiberstack im Container mitbringt; nach Upgrade /dev/dri/renderD128-Rechte/Gruppen-ID prüfen.

Fazit Frage 8

  • [B] Muss über 24.04; 26.04 wird seit Ende August/Oktober 2026 regulär angeboten. 22.04 läuft im Mai 2027 aus dem Standard-Support.
  • [E] Empfehlung für den NUC: Neuinstallation 26.04 statt zweifachem In-place-Sprung. Gründe: zwei Hops mit je eigenen Fallen (sysctl.conf-Löschung, dracut, Interface-Drift, deaktivierte Docker-Quelle, apt-key), kein Snapshot-Rollback auf Bare Metal, und der NUC wird ohnehin durch doco-cd/Git deklarativ – genau das macht eine Neuinstallation reproduzierbar (Compose-Repo + Volumes/Bind-Mounts zurückspielen). Voraussetzung: Volumes/Daten auf separater Partition/Disk oder vollständig gesichert, Konsolenzugang, Testlauf der Restore-Prozedur. Wer in-place geht: vorher sysctl.conf nach /etc/sysctl.d/ umziehen, netplan auf routes: umstellen, Interface-Namen notieren, Docker-Quelle auf deb822/signed-by, nach jedem Hop docker info/QSV prüfen.
  • [E] Reihenfolge-Abhängigkeit: Ein NUC-Neuaufbau ist der natürliche Moment, Dienste auf den Cluster zu verlagern oder bewusst auf Compose zu belassen – die ADR sollte vorher entschieden sein, damit nicht doppelt migriert wird.

Die drei überraschendsten Befunde

  1. Omni Hobby ist seit 23.10.2026 kostenlos (bis 10 Nodes, 2 Nutzer); Sidero Labs gehört inzwischen zu Yardi, Talos bleibt MPL-2.0. Damit gibt es Ein-Klick-Upgrades für Talos/K8s ohne Kosten – aber als SaaS-Abhängigkeit. [B]
  2. do-release-upgrade auf 26.04 löscht /etc/sysctl.conf kommentarlos, auch bei „keep current version" – auf einem Docker-Host mit eigenen Kernelparametern ein stiller Funktionsverlust (Muster passt zu Robins bisherigen „still-kaputt"-Gotchas). [B]
  3. Exakt Robins Hardwareprofil (3 × 16 GB, eine geteilte 500-GB-NVMe) ist öffentlich durchdekliniert: Ceph würde 40–50 % des RAM fressen, Longhorn wächst mit der Volume-Zahl auf 2–3 GB/Node, LINSTOR bleibt <1 GB/Node. Zusätzlich: Longhorns V2-Engine (GA seit 1.12) wurde von einem Betreiber wegen Metadatenkorruption bei Rebuilds wieder verworfen. [B]

Offene Punkte (nicht belegt / nicht gefunden)

  • Keine belastbaren Messungen für die Gesamt-RAM-Grundlast „Talos + Cilium + Longhorn + Monitoring" pro Node in genau dieser Kombination; der Überschlag in Frage 5 ist eine Schätzung aus Einzelmessungen.
  • Chipsatz des HP-Flex-IO-2,5-GbE-Moduls und dessen Talos-Treiberunterstützung nicht verifiziert – vor Kauf prüfen (Intel I225/I226 → igc im Mainline-Kernel; Realtek RTL8125 → r8169, ggf. Firmware-Extension).
  • Aktueller Pflegestand von khuedoan/homelab und budimanjojo/home-cluster nicht verifiziert.