{"id":94977,"date":"2020-09-24T07:43:00","date_gmt":"2020-09-24T05:43:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes"},"modified":"2020-09-24T07:43:00","modified_gmt":"2020-09-24T05:43:00","slug":"nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes","title":{"rendered":"Unsere Erkenntnisse nach einem Jahr Migration von GitLab.com auf Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Anmerkung des \u00dcbersetzers.<\/b>: Die Anpassung von Kubernetes in GitLab wird als einer der beiden Hauptfaktoren angesehen, die das Wachstum des Unternehmens f\u00f6rdern. Bis vor Kurzem beruhte jedoch die Infrastruktur des Online-Dienstes GitLab.com auf virtuellen Maschinen, und erst vor etwa einem Jahr begann die Migration zu K8s, die bis heute noch nicht abgeschlossen ist. Wir freuen uns, die \u00dcbersetzung eines k\u00fcrzlich ver\u00f6ffentlichten Artikels eines SRE-Ingenieurs von GitLab vorzustellen, der beschreibt, wie dies geschieht und welche Schl\u00fcsse die am Projekt Beteiligten ziehen.<\/i><\/p>\n

\"Unsere
\n
\nSeit etwa einem Jahr besch\u00e4ftigt sich unsere Infrastrukturabteilung mit der Migration aller Dienste, die auf GitLab.com laufen, nach Kubernetes. W\u00e4hrend dieser Zeit sind wir auf Probleme gesto\u00dfen, die nicht nur mit der Verschiebung der Dienste nach Kubernetes, sondern auch mit der Verwaltung des hybriden Deployments w\u00e4hrend des \u00dcbergangs verbunden sind. In diesem Artikel geht es um die wertvollen Lektionen, die wir dabei gelernt haben.<\/a><\/noindex><\/p>\n

Von Anfang an arbeiteten die Server von GitLab.com in der Cloud auf virtuellen Maschinen. Diese virtuellen Maschinen werden von Chef verwaltet, und ihre Installation erfolgt \u00fcber unser offizielles Linux-Paket<\/a><\/noindex>. Die Deploymentsstrategie<\/a><\/noindex> f\u00fcr den Fall eines App-Updates besteht darin, die Serverlandschaft koordiniert und sequentiell mithilfe eines CI-Pipelines zu aktualisieren. Diese Methode \u2014 auch wenn sie langsam und ein wenig langweilig<\/a><\/noindex> ist \u2014 garantiert, dass GitLab.com dieselben Installations- und Konfigurationsmethoden anwendet wie die Nutzer von (self-managed)<\/i> Installationen von GitLab, die daf\u00fcr unsere Linux-Pakete verwenden.<\/p>\n

Wir verwenden diese Methode, weil es von gr\u00f6\u00dfter Bedeutung ist, die Freuden und Sorgen, die die Mitglieder der Community bei der Installation und Konfiguration ihrer GitLab-Kopien erleben, selbst zu sp\u00fcren. Dieser Ansatz hat einige Zeit gut funktioniert, aber als die Anzahl der Projekte auf GitLab \u00fcber 10 Millionen stieg, stellten wir fest, dass er unseren Anforderungen an Skalierung und Deployment nicht mehr gerecht wurde.<\/p>\n

Die ersten Schritte zu Kubernetes und einem cloud-nativen GitLab<\/h2>\n

\nIm Jahr 2017 wurde das Projekt GitLab Charts<\/a><\/noindex> Um GitLab f\u00fcr die Bereitstellung in der Cloud vorzubereiten und den Benutzern zu erm\u00f6glichen, GitLab in Kubernetes-Clustern zu installieren. Zu diesem Zeitpunkt waren wir uns bewusst, dass der Umzug von GitLab nach Kubernetes die Skalierbarkeit der SaaS-Plattform erh\u00f6hen, die Bereitstellung vereinfachen und die Effizienz der Ressourcennutzung steigern w\u00fcrde. Gleichzeitig hingen viele Funktionen unserer Anwendung von gemounteten NFS-Partitionen ab, was den \u00dcbergang von virtuellen Maschinen verlangsamte.<\/p>\n

Der Drang nach Cloud-Native und Kubernetes erm\u00f6glichte es unseren Ingenieuren, einen schrittweisen \u00dcbergang zu planen, bei dem wir einige Abh\u00e4ngigkeiten der Anwendung von Netzspeichern aufgegeben haben, w\u00e4hrend wir gleichzeitig neue Funktionen weiterentwickelten. Seit wir im Sommer 2019 mit der Planung der Migration begonnen haben, wurden viele dieser Einschr\u00e4nkungen beseitigt, und der Prozess der \u00dcbertragung von GitLab.com nach Kubernetes l\u00e4uft jetzt auf Hochtouren!<\/p>\n

Funktionsweise von GitLab.com in Kubernetes<\/h2>\n

\nF\u00fcr GitLab.com verwenden wir einen einheitlichen regionalen GKE-Cluster, der den gesamten Anwendungsverkehr verarbeitet. Um die (bereits komplexe) Migration zu vereinfachen, konzentrieren wir uns auf Dienste, die nicht von lokalem Speicher oder NFS abh\u00e4ngen. GitLab.com verwendet haupts\u00e4chlich eine monolithische Codebasis auf Rails, und wir leiten den Verkehr je nach Arbeitslastmerkmalen zu verschiedenen Endpunkten, die in ihren eigenen Knotengruppen isoliert sind.<\/p>\n

Im Falle des Frontends werden diese Typen in Webanfragen, API, Git SSH\/HTTPS und Registry unterteilt. Im Backend teilen wir Jobs in der Warteschlange nach verschiedenen Merkmalen auf, abh\u00e4ngig von vordefinierten Ressourcenlimits<\/a><\/noindex>, die es uns erm\u00f6glichen, Zielvorgaben f\u00fcr die Dienstleistungsstufen (Service-Level Objectives, SLOs) f\u00fcr verschiedene Lasten festzulegen.<\/p>\n

Alle diese Dienste von GitLab.com sind mit dem unver\u00e4nderten Helm-Chart von GitLab konfiguriert. Die Konfiguration erfolgt in Subcharts, die nach Bedarf aktiviert werden k\u00f6nnen, w\u00e4hrend wir schrittweise Dienste in den Cluster \u00fcbertragen. Selbst wenn beschlossen wurde, einige unserer stateful Dienste wie Redis, Postgres, GitLab Pages und Gitaly nicht in die Migration einzubeziehen, erm\u00f6glicht Kubernetes eine drastische Reduzierung der Anzahl der VMs, die derzeit von Chef verwaltet werden.<\/p>\n

Transparenz und Konfigurationsmanagement von Kubernetes<\/h2>\n

\nAlle Konfigurationen werden von GitLab selbst verwaltet. Dazu verwenden wir drei Konfigurationsprojekte, die auf Terraform und Helm basieren. Wo immer m\u00f6glich, versuchen wir, GitLab selbst zu verwenden, um GitLab zu betreiben, aber f\u00fcr betriebliche Aufgaben haben wir eine separate GitLab-Instanz. Diese ist notwendig, um bei Deployments und Updates von GitLab.com nicht von der Verf\u00fcgbarkeit von GitLab.com abh\u00e4ngig zu sein.<\/p>\n

Obwohl unsere Pipelines f\u00fcr den Kubernetes-Cluster auf einer separaten Installation von GitLab laufen, gibt es f\u00fcr die Code-Repositories \u00f6ffentliche Spiegel unter den folgenden Adressen:<\/p>\n