GitLab-Stack mit Gitaly on Kubernetes konsolidieren

Mit GitLab 18.11 gibt es gute Neuigkeiten für Teams, die GitLab auf Kubernetes betreiben: Gitaly on Kubernetes ist jetzt allgemein verfügbar. Teams, die GitLab auf Kubernetes hosten, standen bislang vor der Herausforderung, ein hybrides Setup zu pflegen – die meisten GitLab-Komponenten in Kubernetes, Gitaly aber auf virtuellen Maschinen. Diese hybride Architektur machte den Betrieb für diese Teams aufwändiger. Das gehört der Vergangenheit an: Gitaly on Kubernetes ist jetzt eine offiziell unterstützte Deployment-Option.

Der Weg zu Kubernetes

Gitaly hat einige grundlegende Anforderungen, die sich nicht ohne Weiteres in eine Kubernetes-Umgebung übertragen lassen.

Git-Operationen können speicherintensiv sein, und ihre Nutzungsmuster sind schwer vorherzusagen. Um den Gitaly-Hauptprozess vor Out-of-Memory-Ereignissen (OOM) zu schützen und Ausfallzeiten zu vermeiden, lässt sich Gitaly so konfigurieren, dass jeder Git-Prozess in einer dedizierten cgroup läuft. In dieser Konfiguration lebt der Gitaly-Prozess in einer eigenen cgroup, getrennt von denen der Git-Prozesse. Überschreitet ein Git-Prozess das Speicherlimit seiner cgroup und wird beendet, bleibt der Gitaly-Hauptprozess davon unberührt.

Um dieses Setup in einem Kubernetes-Pod zum Laufen zu bringen, war zusätzliche Arbeit notwendig. Die meisten Kubernetes-Cluster verwenden containerd als Container-Runtime. Bis vor Kurzem erlaubte containerd Containern nur dann, in cgroupfs zu schreiben, wenn sie im privilegierten Modus liefen. Die Lösung bestand darin, /sys/fs/cgroup über einen Init-Container einzubinden und den Pfad schreibbar zu machen.

Auch Pod-Neustarts erforderten zusätzliche Arbeit. Auf einer virtuellen Maschine kann Omnibus das Gitaly-Binary direkt ersetzen und durch Offenhalten des Sockets während des Prozesswechsels einen graceful Reload durchführen. In Kubernetes hingegen werden Gitaly-Pods bei einem StatefulSet-Austausch – ob durch ein Helm-Upgrade, einen Node Drain oder eine Konfigurationsänderung – gestoppt und neu gestartet. Das ist ein harter Stopp, kein graceful Reload. Bei Gitaly in der Sharded-Konfiguration ohne Hochverfügbarkeit bedeutet das Ausfallzeiten, die für einige Kunden nicht akzeptabel sein können.

Die Lösung war, Client-Retries konfigurierbar zu machen. Durch die Konfiguration von Gitaly-Clients – wie Rails – mit ausreichend langen Retry-Zeiträumen für den Neustart und die Wiederherstellung von Gitaly können Nutzende in diesem kurzen Fenster eine leicht erhöhte Latenz bemerken, aber Anfragen werden letztlich erfolgreich abgeschlossen und Ausfallzeiten werden vermieden.

Um zu bestätigen, dass Client-Retries Ausfallzeiten bei Upgrades effektiv eliminieren, wurde eine Reihe von Benchmarks durchgeführt. Gängige Git-Operationen wurden gegen zwei GitLab-Instanzen ausgeführt – eine mit Gitaly auf VMs und eine auf Kubernetes –, dann wurde mitten im Test ein Upgrade ausgelöst und die Erfolgsquoten der Anfragen erfasst. Die Ergebnisse:

Die Zahlen sind in beiden Umgebungen nahezu identisch. Besonders ermutigend ist dabei die Natur von Kubernetes selbst: Ein Pod-Neustart bedeutet eine abrupte Prozessbeendigung und sofortige Socket-Schließung – und dennoch blieben die Erfolgsquoten so hoch. Vollständige 100 % bei jeder Operation würden die Hochverfügbarkeitslösung Gitaly Cluster (Praefect) erfordern, die Kubernetes noch nicht unterstützt – woran allerdings aktiv gearbeitet wird, mit der allgemeinen Verfügbarkeit in Aussicht.

Was Gitaly on Kubernetes bedeutet

Wer GitLab im hybriden Modus betreibt – mit einigen Komponenten auf Kubernetes und Gitaly auf VMs –, kann die Infrastruktur jetzt konsolidieren, indem Gitaly in den Cluster verlagert wird. Das eliminiert die Notwendigkeit, eine separate VM-Flotte neben den Kubernetes-Knoten zu pflegen und zu überwachen, und bringt den gesamten GitLab-Stack unter eine einzige, Kubernetes-verwaltete Umgebung.

Wer GitLab erstmals einführt und Software bereits auf Kubernetes betreibt, profitiert jetzt von einem vollständig Kubernetes-nativen GitLab-Deployment über das Helm-Chart.

Gitaly on Kubernetes installieren

Der empfohlene Weg, Gitaly auf Kubernetes zu deployen, ist über das GitLab-Helm-Chart. Vor dem Einstieg empfiehlt sich die Lektüre der Gitaly on Kubernetes-Dokumentation, die wichtige Konfigurationshinweise enthält und dabei hilft, häufige Fallstricke zu vermeiden.

Gitaly lässt sich entweder als Teil einer vollständigen GitLab-Installation oder als externe Komponente deployen. Die Gitaly on Kubernetes-Dokumentation deckt beide Szenarien ab.