Homelab Rebuild 2026 — vom Homelab zum Mini-Rechenzentrum

🌐 Auch auf: English · Français · Español

Episode 0 — Das Projekt beginnt. Es geht um einen Umbau meines kompletten Homelabs — nicht einfach noch ein Dienst obendrauf, sondern ein neuer Blick darauf, wie die ganze Umgebung aufgebaut und betrieben wird. Mit Kubernetes habe ich tatsächlich schon gearbeitet, in einem ziemlich ähnlichen Setup wie dem, das ich gleich beschreibe. Im März habe ich den ersten Entwurf dieser Idee veröffentlicht. Aus Gründen, die ich bis heute nicht ganz erklären kann, bin ich vom ursprünglichen Plan abgedriftet und habe ihn nie zu Ende gebracht. Der Beitrag ist inzwischen in Rente. Diesmal will ich neu anfangen — nach einem Plan, der dem von damals erstaunlich nahe kommt. Wie üblich ist das schnell eskaliert.

• 3-Node-Proxmox-Cluster
• Windows Server Active Directory
• Windows-11-Clients
• Windows-Dateiserver
• Interne PKI
• GitLab
• RKE2 Kubernetes
• FluxCD GitOps
• Longhorn & MinIO (dazu kommen eigene Beiträge)
• Icinga2-Monitoring
• Proxmox Backup Server

🎯 Ziel

Es geht nicht darum, ein produktives Rechenzentrum zu bauen. Es geht darum zu lernen, wie Enterprise-IT funktioniert — indem ich mir eine zu Hause baue.

🖥️ Hardware

• HP1 — 64 GB RAM, 512 GB OS-SSD, 2 TB SSD
• HP2 — 32 GB RAM, 512 GB OS-SSD, 2 TB SSD
• HP3 — 32 GB RAM, 512 GB OS-SSD, 3×2 TB SSD (Software-RAID5)

Alle Linux-VMs laufen mit Ubuntu Server 26.04 LTS als Basis-OS.

🏛️ Architektur 2026: Nicht alles neu, aber endlich sauber zusammengesetzt

Bevor ich diesen Beitrag geschrieben habe, habe ich ein altes Planungsdokument vom Februar ausgegraben — einen früheren, nie fertiggestellten Anlauf zu genau dieser Idee. Ich hatte mit etwas Veraltetem gerechnet und das meiste davon im Kopf schon weggeworfen, bevor ich es überhaupt nochmal gelesen hatte. Falsch gedacht. Der Entwurf vom Februar war schon überraschend nah an dem, wo ich heute gelandet bin. IP-Plan, Namensschema und die Rollenverteilung zwischen Active Directory, PKI und Monitoring waren weitgehend richtig. Was fehlte, war keine bessere Technik — sondern ein ordentliches Betriebsmodell. Statt also bei null anzufangen, nimmt dieser Neuaufbau den alten Plan als „Version 0.9“, behält, was noch trägt, wirft raus, was nicht trägt, und ergänzt GitOps als fehlendes Puzzleteil, das alles zusammenhält.

Was vom alten Plan übrig geblieben ist

• IP-Bereich und Domain — 192.168.10.x/24 im internen Netz, mit home.arpa als Domain-Suffix. home.arpa ist die offiziell reservierte TLD für Heimnetze — ein kleines Detail, das der alte Plan schon richtig hatte.
• Ein lesbares Namensschema — statt generischer Namen à la VM11/VM12 folgt jede VM dem Muster <host>-<role>-<number>, z. B. HP1-gitlab01 oder HP2-fs01. Schon am Namen sieht man, wo etwas läuft und was es tut. Die Hosts selbst heißen nach dem IP-Bereich, der ihnen gehört: HP1 für die 30er, HP2 für die 40er, HP3 für die 50er.
• Zwei Domain Controller — HP1-dc01 (DNS, FSMO-Rollen, Root-CA) und HP2-dc02 (DNS, Global Catalog), verteilt auf zwei verschiedene Proxmox-Hosts für Redundanz.
• Eine richtige PKI-Hierarchie — Offline-Root-CA → Issuing CA → Server und Clients statt einer einzigen flachen CA. Näher dran an dem, wie eine echte Organisation das betreiben würde.
• Icinga2 für klassisches Infrastruktur-Monitoring (Proxmox, Windows Server, VMs, Netzwerk) — Kubernetes bekommt stattdessen einen eigenen Prometheus/Grafana-Stack, statt ein Tool zu zwingen, beide Welten abzudecken.
• GitLab, befördert von „einfach nur ein Git-Repository“ zur zentralen Plattform für Quellcode, CI/CD, die Container-Registry und das GitOps-Repository, das FluxCD beobachtet.
• Vault (oder OpenBao) für das Secrets-Management — bleibt, ist aber bewusst in Phase 2 verschoben statt Abhängigkeit ab Tag eins, damit das erste Kubernetes/GitOps-Setup nicht daran hängt, dass das Secrets-Management zuerst perfekt sitzt.

Was ich bewusst zurücklasse

Ein Homelab neigt dazu, zu einer Sammlung von „Das wäre auch noch spannend“-Technologien zu werden. Dieser Neuaufbau soll durchdachte Architektur zeigen, keinen Technologie-Stapel — deshalb fliegen ein paar Dinge aus dem alten Plan absichtlich raus:

• Mehrere Dienste auf einer VM bündeln (z. B. GitLab + Pi-hole + Grafana + Nextcloud zusammen). Schwerer zu sichern, schwerer zu warten und weniger realistisch. Eine VM, eine Aufgabe.
• Ein separater NAS-Server. Zwischen Windows-Dateiserver, Proxmox‘ eigenem Storage und Longhorn/MinIO für Kubernetes würde eine vierte Storage-Plattform nur Komplexität hinzufügen, aber keine Fähigkeiten.
• NFS als Storage-Backend für Kubernetes. Longhorn ist genau dafür gebaut und der bessere Weg, Kubernetes-Storage wirklich zu lernen.
• Nextcloud außerhalb von Kubernetes betreiben. Das ist ein richtig guter Lern-Workload — Ingress, Storage, Datenbank, Secrets, Backup — und gehört deshalb in den Cluster, nicht daneben.
• Mehrere sich überschneidende Monitoring-Systeme stapeln (Icinga + Zabbix + Nagios + Prometheus gleichzeitig). Ein Tool pro Ebene reicht: Icinga2 für die klassische Infrastruktur, Prometheus/Grafana für Kubernetes.
• Eine eigene Firewall-Appliance (z. B. eine separate FreeBSD-basierte Firewall-VM). Für sich spannend, aber ein eigenständiges Projekt, das den Fokus dieses hier verwässern würde.

Der konsolidierte VM- & IP-Plan

Die Verteilung der VMs richtet sich nach dem tatsächlich verfügbaren RAM pro Host: HP1 hat den meisten RAM (64 GB) und trägt deshalb den Großteil der allgemeinen und der Control-Plane-Last. HP3 hat weniger RAM, aber den großen RAID5-Storage-Pool — also weniger VMs, dafür das natürliche Zuhause für storage-lastige Kubernetes-Worker. HP2 rundet das Ganze mit dem Dateiserver, dem zweiten Domain Controller und den restlichen Workern ab.

VM	Rolle	IP	RAM	Disk
HP1-dc01	AD / DNS / Root-CA	192.168.10.x	4 GB	60 GB
HP1-gitlab01	GitLab / Container-Registry	192.168.10.x	8 GB	120 GB
HP1-seed01	Dev-VM (Ansible, kubectl, Tooling)	192.168.10.x	4 GB	60 GB
HP1-vault01	Secrets-Management (Phase 2)	192.168.10.x	2 GB	40 GB
HP1-icinga01	Monitoring	192.168.10.x	4 GB	60 GB
HP1-k8s-cp01	RKE2 Control Plane	192.168.10.x	8 GB	80 GB
HP1-k8s-cp02	RKE2 Control Plane	192.168.10.x	8 GB	80 GB
HP2-fs01	Windows-Dateiserver	192.168.10.x	8 GB	200 GB
HP2-dc02	AD / DNS / Global Catalog	192.168.10.x	4 GB	60 GB
HP2-k8s-w03	Worker	192.168.10.x	8 GB	100 GB
HP2-k8s-w04	Worker	192.168.10.x	8 GB	100 GB
HP3-pihole01	DNS-Filter	192.168.10.x	1 GB	20 GB
HP3-k8s-cp03	RKE2 Control Plane	192.168.10.x	8 GB	80 GB
HP3-k8s-w01	Worker	192.168.10.x	8 GB	150 GB
HP3-k8s-w02	Worker	192.168.10.x	8 GB	150 GB

All diese VMs sollen automatisch mit Terraform bereitgestellt werden, statt von Hand in der Proxmox-Oberfläche zusammengeklickt — ein bewusster erster Schritt dahin, das ganze Homelab als Code zu behandeln und nicht nur die Kubernetes-Schicht obendrauf.

Storage, vereinfacht

Proxmox Storage (HP3)
    ZFS RAIDZ1 → VM storage, snapshots

Kubernetes Storage
    Longhorn → Persistent Volumes

Backup
    Proxmox Backup Server → VM backup

Keine zusätzliche NAS-Kiste dazwischen — Proxmox‘ eigener ZFS-Storage und Longhorn decken beide Welten ab.

Die fünf Säulen

                Homelab 2026

        +-----------------------+
        |                       |
   Classic IT              Cloud Native

   Active Directory        RKE2
   Windows                 FluxCD
   SMB                     GitOps
   PKI                     Longhorn

        +-----------------------+

              Proxmox

        +-----------------------+

              Backup (PBS)

Der Sinn dieses Neuaufbaus ist nicht „Ich habe 25 Technologien installiert“. Sondern: Ich baue mir zu Hause eine kleine Plattform im Enterprise-Stil und betreibe sie so, wie moderne Plattform-Teams tatsächlich arbeiten — mit GitOps als Rückgrat, das die klassische Infrastruktur mit der Cloud-native-Seite verbindet.

📐 GitOps zuerst

Alles rund um Kubernetes lebt in GitLab. Git ist die Single Source of Truth, und FluxCD synchronisiert den Cluster laufend. Kein manueller Konfigurations-Drift.

📝 Dokumentation

Alles — Architekturentscheidungen, Konfigurationen, Lessons Learned und Fehler — wird öffentlich dokumentiert unter https://www.github.com/aptupgrademe/rebuild_2026. Ziel ist, anderen zu helfen und mir dabei meine eigene Wissensdatenbank aufzubauen.

🤖 KI als Lernpartner

Anders als bei früheren Kubernetes-Experimenten setzt dieses Projekt stark auf Claude als technischen Sparringspartner: um Konzepte zu verstehen, Konfigurationen zu prüfen, Probleme zu lösen und die Dokumentation zu verbessern. Die KI soll das Lernen beschleunigen — nicht das Verstehen ersetzen.

🗺️ Sechs-Monats-Roadmap

1. Proxmox-Cluster & Netzwerk
2. Active Directory, Windows 11 & Dateidienste
3. GitLab & Developer-Seed-VM
4. RKE2 Kubernetes
5. FluxCD GitOps
6. Anwendungen (WordPress, Nextcloud, …)
7. PKI
8. Monitoring, Backup & Härtung

Jeder Meilenstein bekommt einen eigenen Blogbeitrag. Dieser Beitrag ist bewusst der Überblick aus der Vogelperspektive — der Anfang der Reise.

🔜 Wie geht’s weiter?

Der nächste Beitrag behandelt Hardware, Netzwerk und die erste Installation des Proxmox-Clusters. Willkommen zum Start eines sechsmonatigen Abenteuers.

---

📚 Mehr aus dieser Reihe: Homelab Rebuild 2026 (auf Englisch)

• Homelab Rebuild 2026 — Building the Proxmox Cluster and Provisioning It with Terraform
• Homelab Rebuild 2026 — Active Directory, Pi-hole Laundering, and a Drive Letter That Refuses to Exist
• Homelab Rebuild 2026 — GitLab, a Seed VM, and the Calm Before the Kubernetes Storm
• Homelab Rebuild 2026: Wait and See – A Server Crash, a Dead-End Advisory, and My New Prime Suspect