Notiz. übersetzen: Die Einführung von Kubernetes bei GitLab gilt als einer der beiden Hauptfaktoren, die zum Wachstum des Unternehmens beitragen. Bis vor Kurzem war die Infrastruktur des Online-Dienstes GitLab.com jedoch auf virtuellen Maschinen aufgebaut, und erst vor etwa einem Jahr begann die Migration auf K8s, die noch immer nicht abgeschlossen ist. Wir freuen uns, eine Übersetzung eines aktuellen Artikels eines GitLab SRE-Ingenieurs darüber präsentieren zu können, wie dies geschieht und welche Schlussfolgerungen die am Projekt beteiligten Ingenieure ziehen.
Seit etwa einem Jahr migriert unsere Infrastrukturabteilung alle auf GitLab.com laufenden Dienste auf Kubernetes. Während dieser Zeit stießen wir nicht nur auf Herausforderungen im Zusammenhang mit der Verlagerung von Diensten auf Kubernetes, sondern auch mit der Verwaltung der Hybridbereitstellung während des Übergangs. Die wertvollen Lektionen, die wir gelernt haben, werden in diesem Artikel besprochen.
Von Anfang an liefen die Server von GitLab.com in der Cloud auf virtuellen Maschinen. Diese virtuellen Maschinen werden von Chef verwaltet und mit unserem installiert . Für den Fall, dass die Anwendung aktualisiert werden muss, besteht die einfache Aktualisierung der Serverflotte auf koordinierte, sequentielle Weise mithilfe einer CI-Pipeline. Diese Methode - wenn auch langsam und ein wenig – stellt sicher, dass GitLab.com die gleichen Installations- und Konfigurationspraktiken verwendet wie Offline-Benutzer (selbstverwaltet) GitLab-Installationen unter Verwendung unserer Linux-Pakete hierfür.
Wir verwenden diese Methode, weil es äußerst wichtig ist, all die Sorgen und Freuden zu erleben, die normale Mitglieder der Community bei der Installation und Konfiguration ihrer Kopien von GitLab erleben. Dieser Ansatz funktionierte eine Zeit lang gut, aber als die Anzahl der Projekte auf GitLab 10 Millionen überstieg, stellten wir fest, dass er unseren Anforderungen an Skalierung und Bereitstellung nicht mehr entsprach.
Erste Schritte zu Kubernetes und Cloud-nativem GitLab
Das Projekt entstand im Jahr 2017 um GitLab für die Cloud-Bereitstellung vorzubereiten und Benutzern die Installation von GitLab auf Kubernetes-Clustern zu ermöglichen. Wir wussten damals, dass die Umstellung von GitLab auf Kubernetes die Skalierbarkeit der SaaS-Plattform erhöhen, Bereitstellungen vereinfachen und die Effizienz der Computerressourcen verbessern würde. Gleichzeitig waren viele Funktionen unserer Anwendung von gemounteten NFS-Partitionen abhängig, was den Übergang von virtuellen Maschinen verlangsamte.
Der Vorstoß hin zu Cloud Native und Kubernetes ermöglichte es unseren Ingenieuren, einen schrittweisen Übergang zu planen, bei dem wir einige Abhängigkeiten der Anwendung vom Netzwerkspeicher aufgegeben und gleichzeitig weiterhin neue Funktionen entwickelt haben. Seit wir im Sommer 2019 mit der Planung der Migration begonnen haben, wurden viele dieser Einschränkungen behoben und der Prozess der Migration von GitLab.com zu Kubernetes ist nun in vollem Gange!
Funktionen von GitLab.com in Kubernetes
Für GitLab.com verwenden wir einen einzelnen regionalen GKE-Cluster, der den gesamten Anwendungsverkehr abwickelt. Um die Komplexität der (ohnehin schon kniffligen) Migration zu minimieren, konzentrieren wir uns auf Dienste, die nicht auf lokalen Speicher oder NFS angewiesen sind. GitLab.com verwendet eine überwiegend monolithische Rails-Codebasis und wir leiten den Datenverkehr basierend auf Workload-Merkmalen an verschiedene Endpunkte weiter, die in ihren eigenen Knotenpools isoliert sind.
Im Falle des Frontends werden diese Typen in Anfragen an Web, API, Git SSH/HTTPS und Registry unterteilt. Im Backend teilen wir die Jobs in der Warteschlange nach verschiedenen Merkmalen auf , die es uns ermöglichen, Service-Level-Ziele (SLOs) für verschiedene Workloads festzulegen.
Alle diese GitLab.com-Dienste werden mithilfe eines unveränderten GitLab-Helm-Diagramms konfiguriert. Die Konfiguration erfolgt in Unterdiagrammen, die selektiv aktiviert werden können, wenn wir Dienste schrittweise in den Cluster migrieren. Auch wenn wir uns entschieden haben, einige unserer zustandsbehafteten Dienste wie Redis, Postgres, GitLab Pages und Gitaly nicht in die Migration einzubeziehen, können wir durch den Einsatz von Kubernetes die Anzahl der VMs, die Chef derzeit verwaltet, drastisch reduzieren.
Sichtbarkeit und Verwaltung der Kubernetes-Konfiguration
Alle Einstellungen werden von GitLab selbst verwaltet. Hierzu kommen drei Konfigurationsprojekte auf Basis von Terraform und Helm zum Einsatz. Wir versuchen, wann immer möglich GitLab selbst zum Ausführen von GitLab zu verwenden, aber für betriebliche Aufgaben haben wir eine separate GitLab-Installation. Dies ist erforderlich, um sicherzustellen, dass Sie bei der Durchführung von GitLab.com-Bereitstellungen und -Updates nicht auf die Verfügbarkeit von GitLab.com angewiesen sind.
Obwohl unsere Pipelines für den Kubernetes-Cluster auf einer separaten GitLab-Installation laufen, gibt es Spiegelungen der Code-Repositories, die unter den folgenden Adressen öffentlich verfügbar sind:
- – GitLab.com-Konfigurationsframework für das GitLab-Helm-Diagramm;
- – Enthält Konfigurationen für Dienste, die nicht direkt mit der GitLab-Anwendung verknüpft sind. Dazu gehören Konfigurationen für Protokollierung und Clusterüberwachung sowie integrierte Tools wie PlantUML;
- – Terraform-Konfiguration für Kubernetes und ältere VM-Infrastruktur. Hier konfigurieren Sie alle Ressourcen, die zum Ausführen des Clusters erforderlich sind, einschließlich des Clusters selbst, Knotenpools, Dienstkonten und IP-Adressreservierungen.
Wenn Änderungen vorgenommen werden, wird die öffentliche Ansicht angezeigt. mit einem Link zum detaillierten Diff, das SRE analysiert, bevor Änderungen am Cluster vorgenommen werden.
Für SRE führt der Link zu einem detaillierten Diff in der GitLab-Installation, die für die Produktion verwendet wird und auf die der Zugriff beschränkt ist. Dies ermöglicht Mitarbeitern und der Community, ohne Zugriff auf das Betriebsprojekt (das nur SREs offen steht), vorgeschlagene Konfigurationsänderungen einzusehen. Durch die Kombination einer öffentlichen GitLab-Instanz für Code mit einer privaten Instanz für CI-Pipelines behalten wir einen einzigen Workflow bei und stellen gleichzeitig die Unabhängigkeit von GitLab.com für Konfigurationsaktualisierungen sicher.
Was wir während der Migration herausgefunden haben
Bei dem Umzug konnten Erfahrungen gesammelt werden, die wir bei neuen Migrationen und Deployments in Kubernetes anwenden.
1. Erhöhte Kosten aufgrund des Datenverkehrs zwischen Verfügbarkeitszonen
Tägliche Ausgangsstatistik (Bytes pro Tag) für die Git-Repository-Flotte auf GitLab.com
Google unterteilt sein Netzwerk in Regionen. Diese wiederum sind in Barrierefreiheitszonen (AZ) unterteilt. Git-Hosting ist mit großen Datenmengen verbunden, daher ist es für uns wichtig, den Netzwerkausgang zu kontrollieren. Für internen Datenverkehr ist ausgehender Datenverkehr nur dann kostenlos, wenn er innerhalb derselben Verfügbarkeitszone bleibt. Zum jetzigen Zeitpunkt stellen wir an einem typischen Arbeitstag etwa 100 TB Daten bereit (und das gilt nur für Git-Repositorys). Dienste, die sich in unserer alten VM-basierten Topologie in denselben virtuellen Maschinen befanden, werden jetzt in verschiedenen Kubernetes-Pods ausgeführt. Dies bedeutet, dass ein Teil des Datenverkehrs, der zuvor lokal auf der VM war, möglicherweise außerhalb der Verfügbarkeitszonen übertragen werden könnte.
Mit regionalen GKE-Clustern können Sie aus Redundanzgründen mehrere Availability Zones überspannen. Wir erwägen die Möglichkeit für Dienste, die großes Verkehrsaufkommen erzeugen. Dadurch werden die Ausgangskosten gesenkt und gleichzeitig die Redundanz auf Clusterebene aufrechterhalten.
2. Limits, Ressourcenanforderungen und Skalierung
Die Anzahl der Replikate, die den Produktionsverkehr auf Registry.gitlab.com verarbeiten. Der Verkehr erreicht seinen Höhepunkt um ca. 15:00 UTC.
Unsere Migrationsgeschichte begann im August 2019, als wir unseren ersten Dienst, die GitLab Container Registry, auf Kubernetes migrierten. Dieser geschäftskritische Dienst mit hohem Datenverkehr war eine gute Wahl für die erste Migration, da es sich um eine zustandslose Anwendung mit wenigen externen Abhängigkeiten handelt. Das erste Problem, auf das wir stießen, war eine große Anzahl vertriebener Pods aufgrund von Speichermangel auf den Knoten. Aus diesem Grund mussten wir Wünsche und Limits ändern.
Es wurde festgestellt, dass bei einer Anwendung, bei der der Speicherverbrauch mit der Zeit zunimmt, niedrige Werte für Anforderungen (Reservierung von Speicher für jeden Pod) in Verbindung mit einer „großzügigen“ harten Nutzungsbeschränkung zu einer Sättigung führten (Sättigung) Knoten und ein hohes Maß an Räumungen. Um dieses Problem zu lösen, galt es . Dies entlastete die Knoten und stellte sicher, dass die Pods einen Lebenszyklus hatten, der den Knoten nicht zu stark belastete. Jetzt starten wir Migrationen mit großzügigen (und nahezu identischen) Anforderungs- und Grenzwerten und passen diese bei Bedarf an.
3. Metriken und Protokolle
Die Infrastrukturabteilung konzentriert sich auf Latenz, Fehlerraten und Sättigung mit installierten Geräten (SLO) verknüpft mit .
Eines der wichtigsten Ereignisse im Infrastrukturbereich im vergangenen Jahr waren Verbesserungen bei der Überwachung und Zusammenarbeit mit SLOs. Mithilfe von SLOs konnten wir Ziele für einzelne Dienste festlegen, die wir während der Migration genau überwachten. Aber selbst mit dieser verbesserten Beobachtbarkeit ist es nicht immer möglich, Probleme mithilfe von Metriken und Warnungen sofort zu erkennen. Indem wir uns beispielsweise auf Latenz und Fehlerraten konzentrieren, decken wir nicht alle Anwendungsfälle für einen Dienst ab, der migriert wird.
Dieses Problem wurde fast unmittelbar nach der Migration einiger Arbeitslasten zum Cluster entdeckt. Besonders akut wurde es, wenn wir Funktionen prüfen mussten, bei denen die Anzahl der Anfragen gering war, die aber sehr spezifische Konfigurationsabhängigkeiten hatten. Eine der wichtigsten Lehren aus der Migration war die Notwendigkeit, bei der Überwachung nicht nur Metriken, sondern auch Protokolle und den „Long Tail“ zu berücksichtigen. (es geht um auf der Karte - ca. übersetzt) Fehler. Jetzt fügen wir für jede Migration eine detaillierte Liste der Protokollabfragen hinzu (Protokollabfragen) und planen Sie klare Rollback-Prozeduren, die bei Problemen von einer Schicht auf die nächste übertragen werden können.
Die parallele Bearbeitung derselben Anfragen auf der alten VM-Infrastruktur und der neuen Kubernetes-basierten Infrastruktur stellte eine einzigartige Herausforderung dar. Im Gegensatz zur Lift-and-Shift-Migration (Schnelle Übertragung von Anwendungen „wie sie sind“ auf eine neue Infrastruktur; weitere Details können z. B. nachgelesen werden, - ca. übersetzt)Die parallele Arbeit an „alten“ VMs und Kubernetes erfordert, dass Überwachungstools mit beiden Umgebungen kompatibel sind und Metriken in einer Ansicht kombinieren können. Es ist wichtig, dass wir dieselben Dashboards und Protokollabfragen verwenden, um während der Übergangszeit eine konsistente Beobachtbarkeit zu erreichen.
4. Umleiten des Datenverkehrs auf einen neuen Cluster
Für GitLab.com ist ein Teil der Server dediziert . Canary Park betreut unsere internen Projekte und kann dies auch tun . Es ist jedoch in erster Linie dazu gedacht, Änderungen an der Infrastruktur und Anwendung zu testen. Der erste migrierte Dienst akzeptierte zunächst eine begrenzte Menge an internem Datenverkehr. Wir verwenden diese Methode weiterhin, um sicherzustellen, dass SLOs eingehalten werden, bevor der gesamte Datenverkehr an den Cluster gesendet wird.
Im Falle einer Migration bedeutet dies, dass Anfragen an interne Projekte zunächst an Kubernetes gesendet werden und wir dann nach und nach den restlichen Datenverkehr auf den Cluster umleiten, indem wir die Gewichtung für das Backend über HAProxy ändern. Während der Migration von VM zu Kubernetes wurde deutlich, dass es sehr vorteilhaft war, eine einfache Möglichkeit zu haben, den Verkehr zwischen der alten und der neuen Infrastruktur umzuleiten und dementsprechend die alte Infrastruktur in den ersten Tagen nach der Migration für ein Rollback bereitzuhalten.
5. Reservekapazitäten von Pods und deren Verwendung
Fast sofort wurde das folgende Problem festgestellt: Pods für den Registrierungsdienst starteten schnell, aber das Starten von Pods für Sidekiq dauerte einige Zeit . Die lange Startzeit für Sidekiq-Pods wurde zu einem Problem, als wir mit der Migration von Workloads auf Kubernetes für Mitarbeiter begannen, die Jobs schnell verarbeiten und schnell skalieren mussten.
In diesem Fall war die Lektion, dass der Horizontal Pod Autoscaler (HPA) von Kubernetes zwar das Verkehrswachstum gut bewältigt, es jedoch wichtig ist, die Merkmale der Arbeitslasten zu berücksichtigen und den Pods freie Kapazität zuzuweisen (insbesondere, wenn die Nachfrage ungleichmäßig verteilt ist). In unserem Fall gab es einen plötzlichen Anstieg der Jobs, der zu einer schnellen Skalierung führte, was zu einer Sättigung der CPU-Ressourcen führte, bevor wir Zeit hatten, den Knotenpool zu skalieren.
Es besteht immer die Versuchung, so viel wie möglich aus einem Cluster herauszuholen. Nachdem wir jedoch zunächst auf Leistungsprobleme gestoßen sind, beginnen wir jetzt mit einem großzügigen Pod-Budget und reduzieren es später, wobei wir die SLOs genau im Auge behalten. Das Starten von Pods für den Sidekiq-Dienst hat sich erheblich beschleunigt und dauert nun durchschnittlich etwa 40 Sekunden. gewann sowohl GitLab.com als auch unsere Benutzer selbstverwalteter Installationen, die mit dem offiziellen GitLab-Helm-Chart arbeiten.
Abschluss
Nach der Migration jedes Dienstes freuten wir uns über die Vorteile des Einsatzes von Kubernetes in der Produktion: schnellere und sicherere Anwendungsbereitstellung, Skalierung und effizientere Ressourcenzuweisung. Darüber hinaus gehen die Vorteile der Migration über den GitLab.com-Dienst hinaus. Jede Verbesserung des offiziellen Helm-Diagramms kommt seinen Benutzern zugute.
Ich hoffe, Ihnen hat die Geschichte unserer Kubernetes-Migrationsabenteuer gefallen. Wir migrieren weiterhin alle neuen Dienste zum Cluster. Weitere Informationen finden Sie in folgenden Publikationen:
- «";
- «";
- .
PS vom Übersetzer
Lesen Sie auch auf unserem Blog:
- «";
- «";
- «";
- «".
Source: habr.com