ADR-001: Docker Compose statt Kubernetes¶
| Feld | Wert |
|---|---|
| Status | accepted |
| Datum | 2026-03-20 |
| Betrifft | alle |
Kontext¶
Das Homelab umfasst ca. 40 Services verteilt auf mehrere Server (Intel NUC, Hetzner vServer, OVH Dedicated Server). Die gesamte Infrastruktur wird von einer einzelnen Person betrieben. Der Betreiber besitzt alle fuenf CNCF Kubernetes-Zertifizierungen (Kubestronaut), die technische Kompetenz fuer Kubernetes ist also vorhanden.
Die zentrale Frage: Rechtfertigt die Komplexitaet eines Kubernetes-Clusters den Mehrwert gegenueber Docker Compose fuer ein Single-Operator-Homelab?
Entscheidung¶
Alle Projekte nutzen Docker Compose als Container-Runtime. Kubernetes wird trotz vorhandener Expertise bewusst nicht eingesetzt.
Docker Compose bietet fuer den Single-Operator-Betrieb die bessere Balance
zwischen Funktionalitaet und Betriebsaufwand. Die docker-compose.yml pro
Projekt ist selbstdokumentierend, einfach zu debuggen und benoetigt keine
zusaetzliche Control-Plane-Infrastruktur.
Alternativen¶
| Option | Ergebnis |
|---|---|
| Kubernetes (K3s/K8s) | Voller Feature-Set (Auto-Scaling, Self-Healing, Rolling Updates), aber massiver Overhead fuer einen einzelnen Operator. Control Plane verbraucht Ressourcen, etcd-Backup noetig, YAML-Komplexitaet deutlich hoeher. |
| Nomad | Leichtgewichtiger als K8s, aber kleineres Oekosystem, weniger Community-Support, zusaetzliches Tool zu lernen ohne klaren Vorteil gegenueber Compose. |
Konsequenzen¶
Positiv:
- Minimaler Betriebsaufwand —
docker compose up -dgenuegt - Kein Control-Plane-Overhead, alle Ressourcen fuer Workloads verfuegbar
- Einfaches Debugging mit Standard-Docker-Tooling
- Schnelle Iteration bei Service-Aenderungen
Negativ:
- Kein automatisches High Availability oder Self-Healing
- Kein automatisches Scaling ueber einzelne Hosts hinaus
- Service-Discovery nur ueber Docker-Netzwerke, kein DNS-basiertes Mesh
- Updates erfordern manuellen Neustart (automatisiert durch Renovate + CI)