Gitlab.com zog vor einem Jahr von VMs auf das Container-basierte Kubernetes um. Die gesammelten Erfahrungen schildert nun ein Blogpost.

Generell sei der Umzug laut dem Post eine Herausforderung gewesen. Die betrafen nicht nur das Umstellen der Dienste an sich auf Cloud-Native-Dienste. Gitlab habe zudem in der Übergangsphase ein hybrides Deployment betrieben, also die alte und neue Infrastruktur parallel laufen lassen. Die bisherige Infrastruktur lief auf VM-Basis, verwaltet von Chef und wurde bei Updates mit einer CI-Pipeline als Rolling Release aktualisiert. Bereits seit 2017 bereitete Gitlab den Umzug vor, eines der Hindernisse waren Dienste, die von NFS-Mounts abhingen. Weitere Details zur gewählten Architektur des neuen Clusters, der auf Googles Kubernetes Engine (GKE) läuft, liefert der Blogpost.

Traffic-Kosten umdenken

Doch zu den Herausforderungen. Die bestehen unter anderem in veränderten Kosten. Ausgehender Datenverkehr (Egress) ist bei Google nur kostenlos, wenn er in der eigenen Availability Zone (AZ) bleibt. Google unterteilt seine Cloud in Regionen, die wiederum in Availability Zones. Egress betrifft darin auch internen Netzwerk-Traffic, weil nun einige Dienste nicht mehr in VMs auf demselben Rechner laufen, sondern in Pods. Dabei überschreiten Teile des Netzwerk-Traffics durchaus auch mal AZ-Grenzen. Bei den 100 TeraByte, die Gitlab tagtäglich verschifft, kommt da schnell eine Stange Geld zusammen. Eigentlich passt das regionale GKE-Cluster Gitlab aufgrund der Redundanz gut in den Kram, aber nun will die Firma wegen dieser Kosten besonders netzwerkintensive Dienste in Ein-Zonen-Cluster verwandeln.

Ressourcen für Container beschränken

Zuerst Gitlabs Container-Register umzuziehen, entpuppte sich als guter Schritt: Die Anwendung war zustandslos und brachte nur wenige Abhängigkeiten mit. Probleme bereiteten am Anfang vor allem von Kubernetes aussortierte Pods (Evicted Pods). Legen Admins die Ressourcenbeschränkungen für Container in den Pods (Requests und Limits) falsch oder gar nicht fest, beanspruchen die Pods potenziell zu viele Hardware-Ressourcen (CPU und RAM), weshalb ihnen der Clustermanager die rote Karte zeigt. Bei einigen Anwendungen steigt aber der Speicherbedarf mit der Zeit. Diesen anfangs zu wenig Arbeitsspeicher zuzuweisen (Requests) und ein großzügiges hartes Limit, führte zu Ausfällen. Aus dieser Erfahrung heraus beginnt Gitlab nun mit großzügigeren Ressourcen und beschränkt diese dann peu à peu.

Welche Metriken sind wichtig?

Auch beim Verwalten und Überwachen von Service Level Objectives (SLO) lernte Gitlab dazu. Latenz und Fehlerraten zu messen, deckt nicht alle Nutzungsweisen eines Dienstes ab. Das trifft speziell auf weniger genutzte Features zu, die Konfigurationsabhängigkeiten mitbringen. Hier war die Lektion, nicht nur Monitoring-Metriken auszuwerten, sondern auch Logs und längere Fehlermeldungen. Bei Migrationen setzt Gitlab jetzt auf detaillierte Listen mit Loganfragen und plant zudem transparente und klare Rollback-Prozeduren ein. Eine zusätzliche Herausforderung stellte beim Monitoring zudem der gemeinsame Betrieb von VMs und Container-Cluster dar.

Beim Umzug von VMs auf Container erwies es sich zudem als hilfreich, einen einfachen Weg zu finden, um den Datenverkehr Stücke für Stück von der alten in die neue Infrastruktur zu routen. Dabei wurden die alten Dienste nicht abgeschaltet, sondern dienten als Rollback-Lösung, falls mit den Containern in den ersten Tagen etwas schief läuft.

Augenmaß bei Workloads

Eine weitere Lektion aus dem Umzug der Registry: Während die sehr kurze Startzeiten aufwies, brauchte Sidekiq, ein quelloffener Job Scheduler, mehr als zwei Minuten. Auch hier gab es eine Lektion zu lernen. Der Horizontal Pod Autoscaler (HPA) funktioniert bei steigendem Datenverkehr zwar gut, aber es ist auch wichtig, die Workloads im Auge zu behalten und den Pods Kapazitäten für Schwankungen in der Nachfrage einzuräumen. Andernfalls passiert es, dass Nachfrage-Spitzen die CPU plötzlich auslasten, was das Skalieren erschwert. Sidekiq startet inzwischen in rund 40 Sekunden. Hier ist die Lehre also, die Cluster-Ressourcen nicht immer gleich am vermeintlichen Limit zu fahren, sondern Limits eher nachträglich anzupassen.