Auch, wenn der Blog-Post zu Docker Swarm noch keinen Monat her ist, ist Swarm jetzt seit November bei mir im Einsatz. Ich möchte hier einmal ein Zwischenfazit geben.

Wie das Setup aussieht

Ich habe pro physischem Host eine Swarm-VM, die drei VMs sind auch alle als mögliche Master-Nodes konfiguriert. Damit findet die Auswahl eines neuen Masters statt, sobald der bisherige Master nicht mehr erreichbar sein sollte. Storage ist über NFS abgebildet, das basiert auf zwei VMs (plus eine Witness-Node) mit Pacemaker, Corosync und DRBD. Das läuft soweit auch stabil, auch wenn die Performance etwas besser sein könnte. Vor allem bei Random Access merkt man doch deutlich den Unterschied zu lokalem Storage. Fairerweise muss ich dazu aber auch sagen, dass das wahrscheinlich primär an der verwendeten Hardware liegt, die Kombination aus Thin Client und günstiger SSD ist da sicherlich nicht hilfreich. Ich muss leider auch die Verzeichnisse auf dem NFS-Server händisch anlegen, damit ich diese in Volumes referenzieren kann. Das geht besser, bin ich von Kubernetes mit dem NFS-Provisioner auch anders gewohnt. Alternative Storage-Lösungen wie Ceph oder ähnliche sind mir fürs Homelab allerdings auch zu komplex. Mit dem Punkt kann ich aber generell gut leben.

Zum Management nutze ich Portainer CE. Das ist eins der wenigen Tools, die auch mit Swarm umgehen können, wobei wohl bei Komodo in einer zukünftigen Version Swarm auch unterstützt werden soll. Zwecks Monitoring läuft auf den Nodes jeweils der Node-Exporter und ein Docker-Exporter. Der Docker-Exporter kann zwar nicht nativ mit Swarm umgehen, erfasst aber trotzdem dann pro Node die laufenden Container inkl. der benötigten Ressourcen. Das reicht mir.

Was mir im Betrieb aufgefallen ist

Der Scheduler ist sehr grundlegend. Nach dem, was ich im Internet finden konnte, wird aus den Nodes, die die Constraints und die Ressourcen-Requirements erfüllen, die Node mit den wenigsten Containern ausgewählt und der Task dort gestartet. Wirklich gut steuern lässt sich das auch nicht, es gibt nur harte Constraints und keine weichen. Das kann Kubernetes sehr viel besser. By Design werden Service auch nach dem Joinen einer neuen Node (oder eine bestehende Node war z.B. wegen Wartungsarbeiten offline) nicht neu verteilt, das machen andere Lösungen wie Kubernetes aber auch nicht anders. Um das auszugleichen bin ich aktuell dabei, einen Rebalancer zu entwickeln, der diesen Zustand erkennt und gezielt Services neu startet, um ein Rescheduling zu erzwingen. Das ist aber noch nicht fertig.

Wie es weitergeht

Ich bin weiterhin dabei, Services zum Swarm-Cluster zu migrieren, insgesamt bin ich mit der Lösung soweit glücklich. Storage wird von der Performance her irgendwann wahrscheinlich zum Flaschenhals, aber darum mache ich mir dann Gedanken, wenn es soweit ist.

Ich trauere tatsächlich noch ein wenig Kubernetes hinterher, vor allem weil ich es beruflich gewohnt bin. Für Zuhause ist es allerdings meiner Meinung nach komplett overkill.