Lokales Kubernetes – Size Matters!

In einem unserer internen Projekte haben wir lokale Kubernetes-Cluster eingeführt, damit wir lokale Änderungen in einem Production-artigen Setup ausprobieren können. Der Grund dafür ist, dass die Software als Open Source möglichst von jedem schnell ausprobiert und selbst gehostet werden können soll.

Lokales Kubernetes

Unsere Anforderungen waren relativ einfach: die Software soll auf allen Laptops im Dev-Team laufen und möglichst einfach aufzusetzen sein. Bonus: Installation über den Nix-Package-Manager, mit dem wir das notwendige Tooling für unser Projekt verwalten

Unter den berücksichtigten Alternativen konnten wir zwei direkt aussieben:

• Docker Desktop: Unterstützt nicht alle Linux-Distributionen, die wir im Team haben. Außerdem war es uns nicht leichtgewichtig genug.
• k3s: Läuft nativ nicht auf MacOS.

Es blieben übrig:

• Minikube (mit Docker als Runtime)
• Kind
• k3d

Wir haben einfach mal mit Minikube gestartet und waren anfangs sehr erfreut, wie schnell und einfach erste Schritte gingen. Vor allem out-of-the-box mit einem Befehl ( minikube dashboard  ) eine grafische Übersicht zu bekommen, hat den Einstieg vor allem für Kollegen erleichtert, die das erste mal mit Kubernetes arbeiten. 

Eine weitere Möglichkeit – die wir aber nicht berücksichtigt haben – ist Microk8s. Microk8s ist schon länger eine Option für lokale Kubernetes-Cluster. Es kam für uns leider nicht in Frage, da es nicht containerisiert läuft und nicht für den Nix-Package-Manager gepackaged ist. 

Warum dauert das so lange, bis ich endlich loslegen kann?

Bei Kollegen, die im Home-Office keine Glasfaser haben, ist dann schnell aufgefallen, dass Minikube ein sehr großes Docker-Image für seinen Cluster herunterlädt. Daraufhin haben wir die Größe der Installationen verglichen. Die Binaries sind alle im zweistelligen MB-Bereich, aber die Container-Images für den Cluster unterscheiden sich erheblich:

Warum ist mir das wichtig?

Für einen Frontend-Dev, der mal schnell lokal ein Production-artige Umgebung haben möchte, oder einen Backend-Dev, der gerade mal überprüfen will, wie sein Code funktioniert, wenn 10 Pods parallel auf die Datenbank zugreifen, macht es kaum einen Unterschied, welches lokale Kubernetes die Ressourcen ausführt. Es soll halt gehen. Da wir als Deployment-Tool Skaffold benutzen, sieht man beim Entwicklen auch wenig davon.

Ob allerdings erstmal ein Gigabyte an Docker-Image heruntergeladen wird oder 220 MB, fällt beim ersten Aufsetzen schon auf. Vor allem auch, wenn jemand von außerhalb vom Team eigentlich nur schnell drei Kommandos ausführen will, um in einer eigenen, lokalen Instanz unsere Software auszuprobieren und damit herumzuspielen.

Für Devs, die am Kubernetes-Setup arbeiten, spielen andere Argumente sicherlich eine größere Rolle. Aber aus meiner Sicht ist der beste lokale Cluster der, der vom ganzen Team akzeptiert wird – bei Bedarf können Teammitglieder ja auch problemlos einen anderen verwenden.