Wie die meisten anderen auch habe ich in meinem Homelab einiges an Containern mit Docker in Betrieb. Bisher verwalte ich das in mehreren VMs in Form von Docker-Compose-Stacks händisch - was eher unbequem ist und auch für Ausfallsicherheit und ähnliches nicht förderlich ist. Es ist außerdem aufwändig, Services zwischen den Nodes zu verschieben.

Orchestrierungstools

Das hier ist natürlich keine vollständige Auflistung, es sind nur die Optionen, die ich in Betracht gezogen habe.

Docker Compose Stacks

…also die bisherige Lösung.

Letztendlich einfach nur ein Ordner mit Unterordnern pro Compose-Stack bzw. pro Service.

Vorteile:

• leicht verwaltbar
• Tools wie Watchtower funktionieren problemlos
• viele Softwareprodukte bieten fertige Compose-Files an

Nachteile:

• Keine Redundanz bzw. Failover
• Unübersichtlich, was wo läuft
• Traffic muss von außen an die korrekte VM geleitet werden

Kubernetes

Beruflich hantiere ich täglich mit Kubernetes, ich bin also mit der Funktionsweise und auch den Tools vertraut. Ausprobiert habe ich k3s und Talos, sowohl mit Longhorn als auch mit NFS als Storage. Compose-Stacks lassen sich mit dem Tool Kompose leicht konvertieren. Mich hat hier allerdings der Overhead gestört. Eine Worker-Node ohne jegliche Workload hat ~10 % CPU-Auslastung erzeugt, was vor allem bei den Thin Clients einfach zu viel ist. Auch ist mir die Verwaltung für zuhause eigentlich zu komplex.

Vorteile:

• gängiges Orchestrierungstool
• Helm-Charts für viele gängige Softwareprodukte verfügbar
• gutes Scheduling bzw. Lastmanagement, Scheduling auch sehr gut beeinflussbar
• Kompatibel mit vielen Storage-Lösungen
• hohe Anzahl an Tools (GUIs und andere Lösungen)
• Ingress bzw. Overlay-Netzwerk - Services lassen sich problemlos auf allen Nodes erreichbar schalten, intern wird zur korrekten Node geroutet
• Secret-Management mit vielen Optionen

Nachteile:

• Komplex in der Verwaltung
• Hoher Ressourcenoverhead

Docker Swarm

Docker Swarm ist eine Möglichkeit, mehrere Docker-Daemons miteinander zu vernetzen und zu einer Einheit zu kombinieren. Es ist von der Komplexität her irgendwo zwischen einfachem Docker und Kubernetes, bietet dabei aber auch längst nicht so viele Optionen wie Kubernetes. Der Ressourcenverbrauch ist erfreulich niedrig und die Arbeit mit dem Tool fällt recht leicht, wenn man Compose gewohnt ist. Die Migration von Services ist auch einfach - die Compose-File minimal modifizieren, Storage anlegen und Inhalte übertragen und deployen.

Vorteile:

• Simpel zu nutzen, ähnlich zu Docker Compose
• Compose-Files lassen sich nahezu unverändert einsetzen
• Overlay-Netzwerk - Services sind auf allen Nodes erreichbar, intern wird zur korrekten Node geroutet

Nachteile:

• wenig verbreitet, wenig Tools
• Scheduling ist rudimentär (nur harte Constraints möglich, keine Präferenzen bzw. weiche Constraints)
• Weniger Support f+r verschiedene Storage-Lösungen

Meine Entscheidung

Bisher läuft eigentlich alles mit normalen Compose-Stacks. Ich habe erst Kubernetes mit verschiedene Distributionen evaluiert (Talos und k3s) - und obwohl mir das eigentlich gut gefällt und für mich gewohnte Tools sind, ist mir der CPU-Overhead für meinen Wunsch nach Energieeffizienz einfach zu groß; auch wenn die Vorteile ansonsten überwiegen.

Am Ende fühlt sich Docker Swarm für meinen Einsatzzweck ideal an: leichtgewichtig, bekanntes Compose-Ökosystem, dazu Clustering und Failover. Durch den zentralen NFS-Storage (DRBD-basiert) kann ich Workloads problemlos verschieben, und das Deployment neuer Stacks ist sehr unkompliziert.

Der größte Nachteil ist tatsächlich die Tool-Landschaft. Portainer ist aktuell praktisch das einzige gepflegte GUI-Tool – aber es deckt alles ab, was ich brauche. Früher habe ich Swarmpit genutzt, aber dort passiert im Repo leider kaum noch etwas.

Alles in allem ist Swarm für mein Homelab der beste Kompromiss aus Redundanz, Energieeffizienz und administrativem Aufwand. Ich werde jetzt nach und nach meine Services migrieren, mal schauen, ob ich dabei noch auf Probleme stoße.