Wer kennt es nicht? Das Homelab wächst, immer mehr Docker-Compose-Stacks sammeln sich an, und irgendwann stellt sich die Frage: Wie skaliere ich das Ganze vernünftig, halte es wartbar und hole gleichzeitig das Maximum aus meiner Hardware heraus?
Ich habe mich vor Kurzem entschieden, den großen Schritt zu gehen und meine gesamte Infrastruktur auf ein hybrides, GitOps-gesteuertes K3s-Cluster umzustellen. In diesem Artikel nehme ich dich mit durch meine architektonischen Überlegungen, Hardware-Entscheidungen und den finalen Security- und Management-Stack.
Die Vision: Lokal starten, global expandieren
Das Ziel ist ein Kubernetes-Cluster, das die Stärken meines lokalen Setups mit der Flexibilität der Cloud verbindet. Alles – von der VM-Vorbereitung bis zur Anwendung – soll komplett deklarativ als Infrastructure as Code (IaC) über ein Git-Repository laufen.
Das Namensschema: Struktur von Anfang an
Um im Cluster nicht den Überblick zu verlieren, nutze ich ein striktes, professionelles Namensschema, das vom Großen zum Kleinen sortiert ist:
k3s-c-a001-n001.netguide.io (Service-ClusterID-NodeID.Domain). Das sorgt für eine saubere alphabetische Sortierung im Terminal und erleichtert das Tab-Completion per SSH ungemein.
Warum das Cluster-Gehirn zu Hause bleibt
Eine der wichtigsten Überlegungen war die geografische Verteilung. Macht es Sinn, die Master-Nodes (Control Plane) über die Cloud und das Homelab zu verteilen? Nein. K3s nutzt im HA-Setup etcd, das extrem empfindlich auf Netzwerklatenzen reagiert. Schwankt die Internetleitung zu Hause auch nur kurz, bricht das etcd-Quorum. Meine drei Master-Nodes (n001 bis n003) laufen daher alle lokal auf meinem Hauptserver mit einer internen Latenz von < 1 ms. Die Cloud wird später ausschließlich für reine, zustandslose Worker-Nodes (Agents) genutzt, um Services näher an das öffentliche Netz zu bringen oder Lastspitzen abzufangen.
Hardware-Sizing: Schluss mit CPU-Overprovisioning
Mein Hauptserver läuft mit einem AMD Ryzen 7 PRO 4750G (8 Kerne, 16 Threads). Anfangs dachte ich daran, jeder der drei K3s-VMs einfach 8 Cores zu spendieren. Das wäre allerdings massives Overprovisioning gewesen. Wenn alle drei VMs unter Last stehen, würden sie sich um die echten Threads streiten, was zu Latenzen im etcd-Core führt.
Ich habe mich für einen stabileren „Sweet Spot“ entschieden:
- Specs pro Master-VM: 4 vCPUs (Typ
host), 12 GB RAM, 150 GB lokale SSD. - Mit $3 \times 4\text{ Cores}$ belege ich 12 Threads meines Hosts. Es bleiben also 4 Threads Puffer für den Hypervisor selbst.
Der zweite Server als Proxmox-Erweiterung
Zusätzlich besitze ich einen zweiten Server (aktuell noch Ryzen 1600, geplant ist ein Upgrade auf den effizienteren Ryzen 5 3600 mit 32 GB RAM). Diesen binde ich als zweiten, autarken Proxmox-Server in mein bestehendes Web-UI ein – rein für die zentrale Verwaltung ohne fehleranfälliges Zwei-Knoten-HA. Auf diesem Host wandert eine vierte VM als reiner K3s-Worker (n004), bestückt mit zwei 500 GB SSDs im ZFS-Mirror, um dem Cluster zusätzliche physische Compute-Power und schnellen Speicher zu liefern.
Das Storage-Konzept: Wo liegen die Daten?
Ein riesiger Stolperstein bei Kubernetes im Homelab ist der Speicher. Meine Plex-Filme und Immich-Fotos liegen auf einem großen HDD-Storage auf meinem NAS. Diese binde ich elegant über einen NFS CSI Driver direkt in Kubernetes ein. Der Vorteil: Die Terabytes an Daten müssen nicht migriert werden.
Allerdings gibt es hier zwei eiserne Regeln, die ich beachte:
- Datenbanken gehören auf lokale SSDs: Die PostgreSQL-Datenbanken von Immich oder Forgejo vertragen kein NFS (Gefahr von File-Locking-Problemen und Latenztod). Sie liegen auf den lokalen 150 GB SSDs der VMs.
- Die NAS-SSD als Cache-Beschleuniger: Ich nutze eine zusätzliche 500 GB SSD auf meinem NAS für kleine, lesehungrige Daten wie die unzähligen WebP-Thumbnails von Immich. So bleibt das Scrollen in der Foto-Timeline butterweich, ohne die HDDs zu stressen.
Der Tech-Stack: Automatisierung, GitOps & Sicherheit
Sobald die nackten Ubuntu 26.04 VMs stehen, greift die vollautomatische Pipeline.
1. Das Fundament: NetBird & Ansible
Bevor K3s installiert wird, läuft auf allen Systemen der NetBird-Client. NetBird baut ein verschlüsseltes Full-Mesh-VPN auf WireGuard-Basis auf. Ich pinne im NetBird-Dashboard feste IPs im Bereich 100.64.10.X für meine Server.
Mein Ansible-Playbook übernimmt dann den Rest: Es aktualisiert Ubuntu, installiert die nötigen NFS-Treiber und zwingt K3s über das Flannel-Interface (wt0), ausschließlich über den sicheren NetBird-Tunnel zu kommunizieren.
2. Das KI-Kraftpaket: NVIDIA Passthrough
Eine Besonderheit ist Node 3 (n003): In diese VM habe ich eine NVIDIA RTX 4060 Ti per Proxmox-GPU-Passthrough durchgereicht. Ansible installiert hier automatisch die Headless-Treiber und das NVIDIA Container Toolkit. Über das offizielle Kubernetes-NVIDIA-Plugin wird die GPU als Standard-Ressource (nvidia.com/gpu) im Cluster registriert. Apps wie Ollama (für lokale LLMs) oder Plex (für NVENC-Transcoding) steuere ich im GitOps-Repo einfach über nodeSelector-Labels gezielt auf diesen Node.
3. Warum ArgoCD und nicht Flux?
Für das Continuous Deployment stand ich vor der Wahl: ArgoCD oder FluxCD? Ich habe mich ganz bewusst für ArgoCD entschieden.
Flux ist zwar extrem leichtgewichtig, wird aber fast nur über das Terminal bedient. ArgoCD bietet ein fantastisches Web-UI, das mir visuell genau zeigt, welche Kubernetes-Ressourcen synchronisiert sind und wo es hakt. Gerade im komplexen Hybrid-Betrieb und beim „App-of-Apps“-Pattern, bei dem eine Haupt-App alle anderen Stacks steuert, ist diese Transparenz für mich im Homelab unbezahlbar.
🥚🐓 Das Henne-Ei-Problem gelöst: Mein Forgejo-Git-Server läuft ganz bewusst nicht im K3s-Cluster, sondern auf einem externen VPS. Würde Forgejo im Cluster laufen und das Cluster sich daraus konfigurieren, hätte ich eine zyklische Abhängigkeit gebaut. Schmiert das Cluster ab, kommt ArgoCD nicht mehr an den Code. Der externe VPS ist meine unzerstörbare Source of Truth.
Die drei Säulen der Infrastruktur: NetBox, Wazuh & CrowdSec
Sobald der Cluster läuft, rollt ArgoCD das finale Software-Trio aus:
- NetBox (Die Source of Truth): Hier wird alles dokumentiert. Jede NetBird-IP, jede VM und jede Hardware-Komponente wird in NetBox eingepflegt. Langfristig dient NetBox als dynamisches Inventory für mein Ansible-Setup – die manuelle
inventory.iniwird damit überflüssig. - Wazuh (Das SIEM-Gehirn): Sicherheit wird großgeschrieben. Der Wazuh-Server läuft im Cluster und sammelt über schlanke Agenten auf den Ubuntu-VMs alle Sicherheitsereignisse, scannt nach Schwachstellen und überwacht Dateiänderungen. Da der Wazuh-Indexer massive Schreiblasten erzeugt, liegt sein Speicher exakt auf dem schnellen lokalen ZFS-SSD-Mirror von Server B.
- CrowdSec (Die digitale Haustür): Während Wazuh nach innen schaut, wehrt CrowdSec Angriffe nach außen ab. Als
DaemonSetläuft es auf jedem Node, analysiert Ingress-Logs und blockiert bösartige IPs sofort an der Edge (z. B. direkt im Nginx-Ingress-Controller).
Die perfekte Synergie
Das Geniale daran: CrowdSec schreibt seine lokalen Blocks in ein JSON-Log, welches wiederum vom Wazuh-Agenten ausgelesen wird. Dadurch landen alle weltweiten CrowdSec-Abwehrerfolge visuell aufbereitet in meinem zentralen Wazuh-Dashboard.
Mit dieser Architektur habe ich mir ein Homelab-Fundament gegossen, das absolut zukunftssicher ist. Dank der Kombination aus Ansible für das OS-Level und ArgoCD für die Kubernetes-Ebene fasse ich keine VM mehr manuell an. Wenn ich eine neue App testen oder den Cluster um einen Cloud-Server erweitern will, reicht ein einfacher git push auf meinen externen Forgejo-VPS.