{"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 zur einj\u00e4hrigen Migration von GitLab.com auf Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Hinweis.<\/b>: Die Anpassung von Kubernetes in GitLab wird als einer der beiden Hauptfaktoren angesehen, die zum Wachstum des Unternehmens beigetragen haben. 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 zu K8s, die noch nicht abgeschlossen ist. Wir freuen uns, die \u00dcbersetzung eines aktuellen Artikels eines SRE-Ingenieurs von GitLab dar\u00fcber zu pr\u00e4sentieren, wie dieser Prozess verl\u00e4uft und welche Erkenntnisse die Ingenieure, die an dem Projekt beteiligt sind, sammeln.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Unsere Erkenntnisse zur einj\u00e4hrigen Migration von GitLab.com auf Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/58429abf60cd19a49c5ce593051c2fca.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSeit fast einem Jahr besch\u00e4ftigt sich unsere Infrastrukturabteilung mit der Migration aller Dienste von GitLab.com nach Kubernetes. In dieser Zeit sind wir nicht nur mit Herausforderungen beim Umzug der Dienste in Kubernetes, sondern auch mit der Verwaltung eines hybriden Deployments w\u00e4hrend der \u00dcbergangsphase konfrontiert worden. In diesem Artikel werden wir die wertvollen Lektionen, die wir dabei gelernt haben, n\u00e4her betrachten.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Von Anfang an betrieb GitLab.com seine Server in der Cloud auf virtuellen Maschinen. Diese virtuellen Maschinen werden mit Chef verwaltet, und ihre Installation erfolgt \u00fcber unser <noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/install\/#ubuntu\">offizielles Linux-Paket<\/a><\/noindex>. <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-org\/release\/docs\/-\/blob\/master\/general\/deploy\/gitlab-com-deployer.md\">Bereitstellungsstrategie<\/a><\/noindex> Falls ein Update der Anwendung erforderlich ist, erfolgt dies durch ein einfaches, koordiniertes sequenzielles Update des Serverparks mittels eines CI-Pipelines. Diese Methode \u2013 zwar langsam und etwas <noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/handbook\/values\/#boring-solutions\">langweilig<\/a><\/noindex> \u2013 gew\u00e4hrleistet, dass GitLab.com die gleichen Installationstechniken und Konfigurationen anwendet wie die Nutzer von <i>(self-managed)<\/i> Installationen von GitLab, die hierf\u00fcr unsere Linux-Pakete verwenden.<\/p>\n<p>Wir setzen diese Methode ein, da es von entscheidender Bedeutung ist, die Sorgen und Freuden der Community-Mitglieder zu erleben, w\u00e4hrend sie ihre eigenen Kopien von GitLab installieren und konfigurieren. Dieser Ansatz hat eine Zeit lang gut funktioniert, jedoch haben wir, als die Anzahl der Projekte auf GitLab die 10 Millionen-Grenze \u00fcberschritt, erkannt, dass er unseren Anforderungen an Skalierung und Bereitstellung nicht mehr gerecht wird.<\/p>\n<h2>Die ersten Schritte zu Kubernetes und cloud-native GitLab<\/h2>\n<p>\nIm Jahr 2017 wurde das Projekt <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-org\/charts\">GitLab Charts<\/a><\/noindex> zur Vorbereitung von GitLab f\u00fcr die Bereitstellung in der Cloud und um den Benutzern die Installation von GitLab in Kubernetes-Clustern zu erm\u00f6glichen. Zu diesem Zeitpunkt wussten wir, dass die Migration von GitLab zu Kubernetes die Skalierbarkeit der SaaS-Plattform verbessern, die Bereitstellungen vereinfachen und die Effizienz der Nutzung von Compute-Ressourcen steigern w\u00fcrde. Gleichzeitig war jedoch viele Funktionen unserer Anwendung von angebundenen NFS-Volumes abh\u00e4ngig, was den \u00dcbergang von virtuellen Maschinen verlangsamt hat.<\/p>\n<p>Das Streben nach Cloud-Native und Kubernetes hat es unseren Ingenieuren erm\u00f6glicht, einen schrittweisen \u00dcbergang zu planen, bei dem wir einige Abh\u00e4ngigkeiten der Anwendung von Netzwerkspeichern aufgegeben haben, w\u00e4hrend wir weiterhin neue Funktionen entwickelt haben. Seit wir im Sommer 2019 mit der Planung der Migration begonnen haben, wurden viele dieser Einschr\u00e4nkungen beseitigt, und der Prozess der \u00dcberf\u00fchrung von GitLab.com nach Kubernetes schreitet nun in vollem Umfang voran!<\/p>\n<h2>Besonderheiten des Betriebs von GitLab.com in Kubernetes<\/h2>\n<p>\nF\u00fcr GitLab.com verwenden wir ein einheitliches regionales GKE-Cluster, das den gesamten Anwendungsverkehr verarbeitet. Um die ohnehin komplexe Migration zu vereinfachen, konzentrieren wir uns auf Dienste, die nicht von lokalem Speicher oder NFS abh\u00e4ngig sind. GitLab.com nutzt haupts\u00e4chlich eine monolithische Codebasis auf Rails, und wir leiten den Verkehr je nach Arbeitslastmerkmale auf verschiedene Endpunkte, die in eigenen Knotenpools isoliert sind.<\/p>\n<p>Im Frontend unterteilen sich diese Typen in Anfragen an Web, API, Git SSH\/HTTPS und Registry. Im Backend teilen wir Jobs in der Warteschlange nach verschiedenen Merkmalen auf, je nach. <noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/blog\/2020\/06\/24\/scaling-our-use-of-sidekiq\/\">vorgegebenen Ressourcenlimits<\/a><\/noindex>, die es uns erm\u00f6glichen, Zielservicelevel (Service-Level Objectives, SLOs) f\u00fcr unterschiedliche Lasten festzulegen.<\/p>\n<p>Alle diese GitLab.com-Dienste sind mit Hilfe des unver\u00e4nderten Helm-Charts von GitLab konfiguriert. Die Konfiguration erfolgt in Subcharts, die nach und nach aktiviert werden k\u00f6nnen, w\u00e4hrend wir die Dienste schrittweise in das Cluster migrieren. Auch wenn entschieden wurde, bestimmte unserer zustandsbehafteten 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<h2>Transparenz und Konfigurationsmanagement von Kubernetes<\/h2>\n<p>\nAlle Einstellungen werden von GitLab selbst verwaltet. Daf\u00fcr verwenden wir drei Konfigurationsprojekte basierend auf Terraform und Helm. Wo m\u00f6glich, versuchen wir, GitLab selbst zur Ausf\u00fchrung von GitLab zu nutzen, jedoch haben wir f\u00fcr betriebliche Aufgaben eine separate GitLab-Installation. Diese ist notwendig, um bei Deployments und Updates von GitLab.com von der Verf\u00fcgbarkeit von GitLab.com unabh\u00e4ngig zu sein.<\/p>\n<p>Obwohl unsere Pipelines f\u00fcr das Kubernetes-Cluster auf einer separaten Instanz von GitLab arbeiten, gibt es von den Code-Repositories Mirror, die \u00f6ffentlich unter folgenden Adressen verf\u00fcgbar sind:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/gl-infra\/k8s-workloads\/gitlab-com\">k8s-workloads\/gitlab-com<\/a><\/noindex> \u2014 Konfigurationsanpassung von GitLab.com f\u00fcr das Helm-Chart von GitLab;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/gl-infra\/k8s-workloads\/gitlab-helmfiles\/\">k8s-workloads\/gitlab-helmfiles<\/a><\/noindex> \u2014 enth\u00e4lt Konfigurationen f\u00fcr Dienste, die nicht direkt mit der GitLab-Anwendung verbunden sind. Dazu geh\u00f6ren Konfigurationen f\u00fcr das Logging und Monitoring des Clusters sowie f\u00fcr integrierte Tools wie PlantUML;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/gitlab-com-infrastructure\">Gitlab-com-infrastructure<\/a><\/noindex> \u2014 Terraform-Konfiguration f\u00fcr Kubernetes und die alte (Legacy) VM-Infrastruktur. Hier werden alle Ressourcen konfiguriert, die f\u00fcr den Betrieb des Clusters erforderlich sind, einschlie\u00dflich des Clusters selbst, der Node-Pools, der Dienstkonten und der IP-Adressreservierung.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Unsere Erkenntnisse zur einj\u00e4hrigen Migration von GitLab.com auf Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/612125403171d73106a081bf4244a52b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Bei \u00c4nderungen wird eine \u00f6ffentlich zug\u00e4ngliche <\/i><noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/gl-infra\/k8s-workloads\/gitlab-com\/-\/merge_requests\/315#note_390180361\"><i>kurze Zusammenfassung<\/i><\/a><\/noindex><i> mit einem Link zu einem detaillierten Diff angezeigt, das die SRE vor der Durchf\u00fchrung von \u00c4nderungen am Cluster analysiert.<\/i><\/p>\n<p>F\u00fcr SRE f\u00fchrt der Link zu einem detaillierten diff in der GitLab-Installation, die f\u00fcr den Betrieb verwendet wird und deren Zugang eingeschr\u00e4nkt ist. Dadurch k\u00f6nnen Mitarbeiter und die Gemeinschaft ohne Zugriff auf das Betriebsprojekt (das nur f\u00fcr SRE ge\u00f6ffnet ist) vorgeschlagene \u00c4nderungen an der Konfiguration einsehen. Indem wir eine \u00f6ffentliche Instanz von GitLab f\u00fcr den Code mit einer geschlossenen Instanz f\u00fcr CI-Pipelines kombinieren, erhalten wir einen einheitlichen Workflow und gew\u00e4hrleisten gleichzeitig die Unabh\u00e4ngigkeit von GitLab.com bei Konfigurationsupdates.<\/p>\n<h2>Was wir w\u00e4hrend der Migration herausgefunden haben<\/h2>\n<p>\nIm Zuge des Umzugs haben wir Erfahrungen gesammelt, die wir bei neuen Migrationen und Deployments in Kubernetes anwenden.<\/p>\n<h3>1. Steigende Kosten durch den Datenverkehr zwischen Verf\u00fcgbarkeitszonen<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Unsere Erkenntnisse zur einj\u00e4hrigen Migration von GitLab.com auf Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/3dce44b3f803ffcea13e0101e7343d91.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>T\u00e4gliche Egress-Statistiken (Bytes pro Tag) f\u00fcr den Git-Speicherpool auf GitLab.com<\/i><\/p>\n<p>Google unterteilt sein Netzwerk in Regionen. Diese wiederum werden in Verf\u00fcgbarkeitszonen (AZ) unterteilt. Git-Hosting ist mit gro\u00dfen Datenmengen verbunden, daher ist es wichtig, den ausgehenden Netzwerkverkehr zu kontrollieren. Bei internem Verkehr ist der ausgehende Verkehr nur dann kostenlos, wenn er innerhalb einer einzigen Verf\u00fcgbarkeitszone bleibt. Zum Zeitpunkt der Erstellung dieses Artikels geben wir an einem normalen Arbeitstag etwa 100 TB Daten aus (und das nur f\u00fcr Git-Repositories). Dienste, die in unserer alten VM-basierten Topologie auf denselben virtuellen Maschinen liefen, arbeiten jetzt in unterschiedlichen Pods von Kubernetes. Das bedeutet, dass ein Teil des Verkehrs, der zuvor lokal f\u00fcr die VM war, m\u00f6glicherweise \u00fcber die Grenzen der Verf\u00fcgbarkeitszonen hinausgeht.<\/p>\n<p>Regionale GKE-Cluster erm\u00f6glichen es, mehrere Verf\u00fcgbarkeitszonen f\u00fcr die Redundanz abzudecken. Wir ziehen in Betracht, <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/gl-infra\/delivery\/-\/issues\/1175\">den regionalen GKE-Cluster in einzonale Cluster zu<\/a><\/noindex> f\u00fcr Dienste, die gro\u00dfe Datenmengen erzeugen. Dies wird helfen, die Egress-Kosten zu senken und gleichzeitig die Cluster-Redundanz beizubehalten.<\/p>\n<h3>2. Limits, Ressourcenanfragen und Skalierung<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Unsere Erkenntnisse zur einj\u00e4hrigen Migration von GitLab.com auf Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/6e2e1ca4d37666b49358d94cd8660c56.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Die Anzahl der Replikate, die den Produktionsverkehr auf registry.gitlab.com verarbeiten. Der Verkehr erreicht seinen H\u00f6hepunkt um ca. 15:00 UTC.<\/i><\/p>\n<p>Unsere Migrationsgeschichte begann im August 2019, als wir den ersten Dienst - das GitLab Container Registry - nach Kubernetes migrierten. Dieser kritische Hochlastdienst eignete sich gut f\u00fcr die erste Migration, da es sich um eine zustandslose Anwendung mit wenigen externen Abh\u00e4ngigkeiten handelt. Das erste Problem, mit dem wir konfrontiert wurden, war die hohe Anzahl an verdr\u00e4ngten Pods aufgrund von Speichermangel auf den Knoten. Daher mussten wir die Anfragen und Limits anpassen.<\/p>\n<p>Es stellte sich heraus, dass f\u00fcr eine Anwendung, deren Speicherverbrauch im Laufe der Zeit steigt, niedrige Werte f\u00fcr die Anfragen (die den Speicher f\u00fcr jeden Pod reservieren) zusammen mit einem \"gro\u00dfz\u00fcgigen\" harten Limit zur Nutzung zu einer \u00dcberlastung f\u00fchrten. <i>(saturation)<\/i> der Knoten und einem hohen Niveau an Verdr\u00e4ngungen. Um dieses Problem zu l\u00f6sen, wurde <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/gl-infra\/delivery\/-\/issues\/998#note_388983696\">Es wurde entschieden, die Anfragen zu erh\u00f6hen und die Limits zu senken.<\/a><\/noindex>. Dies reduzierte den Druck auf die Knoten und gew\u00e4hrleistete einen Lebenszyklus der Pods, der den Knoten nicht zu stark belastete. Jetzt beginnen wir Migrationen mit gro\u00dfz\u00fcgigen (und nahezu identischen) Werten f\u00fcr Anfragen und Limits und passen diese nach Bedarf an.<\/p>\n<h3>3. Metriken und Protokolle<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Unsere Erkenntnisse zur einj\u00e4hrigen Migration von GitLab.com auf Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/66d1fd47b57d5826f13defa6e6a7fe3c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Die Infrastrukturabteilung konzentriert sich auf Latenzen, Fehlerquoten und die Saturation gem\u00e4\u00df den festgelegten <\/i><noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Service-level_objective\"><i>Zielen f\u00fcr Service Level<\/i><\/a><\/noindex><i> (SLO), die an <\/i><noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/dashboards-gitlab-com\/-\/metrics\/sla-dashboard.yml?environment=1790496&amp;duration_seconds=86400\"><i>die Verf\u00fcgbarkeit unseres Systems<\/i><\/a><\/noindex><i>.<\/i><\/p>\n<p>gebunden sind. Im vergangenen Jahr waren eine der Schl\u00fcsselentwicklungen in der Infrastrukturabteilung Verbesserungen im Monitoring und im Umgang mit SLO. SLO erm\u00f6glichten es uns, Ziele f\u00fcr einzelne Dienste zu setzen, die wir w\u00e4hrend der Migration sorgf\u00e4ltig verfolgt haben. Aber selbst bei dieser verbesserten Sichtbarkeit ist es nicht immer m\u00f6glich, Probleme sofort zu erkennen, wenn man Metriken und Alarme verwendet. Zum Beispiel, indem wir uns auf Latenzen und Fehlerquoten konzentrieren, erfassen wir nicht alle Nutzungsszenarien des Dienstes, der migriert wird.<\/p>\n<p>Dieses Problem wurde nahezu sofort nach der Verlagerung eines Teils der Arbeitslasten in den Cluster festgestellt. Besonders deutlich trat es zutage, als wir Funktionen \u00fcberpr\u00fcfen mussten, bei denen die Anzahl der Anfragen zwar gering ist, jedoch sehr spezifische Konfigurationsabh\u00e4ngigkeiten bestehen. Eine der wichtigsten Lektionen aus der Migration war, dass wir bei der \u00dcberwachung nicht nur Metriken, sondern auch Protokolle und den \"langen Schwanz\" ber\u00fccksichtigen m\u00fcssen. <i>(es handelt sich um <\/i><noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Long_tail\"><i>eine solche Verteilung<\/i><\/a><\/noindex><i> im Diagramm - Anm. des \u00dcbersetzers)<\/i> Fehler. Jetzt f\u00fchren wir f\u00fcr jede Migration eine detaillierte Liste der Protokollanfragen ein <i>(log queries)<\/i> und planen klare Rollback-Verfahren, die im Falle von Problemen von einem Schichtwechsel zur n\u00e4chsten \u00fcbergeben werden k\u00f6nnen.<\/p>\n<p>Die parallele Verarbeitung derselben Anfragen in der alten VM-Infrastruktur und in der neuen, die auf Kubernetes basiert, stellte eine einzigartige Herausforderung dar. Im Gegensatz zu einer Lift-and-Shift-Migration <i>(schnelle \u00dcbertragung von Anwendungen \"wie sie sind\" in die neue Infrastruktur; mehr dazu kann man zum Beispiel lesen, <\/i><noindex><a rel=\"nofollow\" href=\"https:\/\/www.ibm.com\/cloud\/learn\/lift-and-shift\"><i>hier<\/i><\/a><\/noindex><i> \u2014 Anmerkung des \u00dcbersetzers).<\/i>, der parallele Betrieb auf \"alten\" VMs und Kubernetes erfordert, dass die \u00dcberwachungstools mit beiden Umgebungen kompatibel sind und Metriken in einer einheitlichen Ansicht aggregieren k\u00f6nnen. Wichtig ist, dass wir dieselben Dashboards und Log-Abfragen verwenden, um w\u00e4hrend der \u00dcbergangszeit eine konsistente Beobachtbarkeit zu gew\u00e4hrleisten.<\/p>\n<h3>4. Umleitung des Traffics auf den neuen Cluster<\/h3>\n<p>\nF\u00fcr GitLab.com wird ein Teil der Server f\u00fcr die <noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/handbook\/engineering\/#canary-testing\">Canary-Phase<\/a><\/noindex>reserviert. Der Canary-Park bedient unsere internen Projekte und kann <noindex><a rel=\"nofollow\" href=\"https:\/\/next.gitlab.com\/\">von den Benutzern aktiviert werden<\/a><\/noindex>. Zun\u00e4chst dient er jedoch zur \u00dcberpr\u00fcfung von \u00c4nderungen, die an der Infrastruktur und der Anwendung vorgenommen werden. Der erste migrierte Dienst begann mit der Annahme eines begrenzten Volumens an internem Traffic, und wir verwenden weiterhin diese Methode, um die Einhaltung der SLO sicherzustellen, bevor wir den gesamten Traffic in den Cluster leiten.<\/p>\n<p>Bei der Migration bedeutet dies, dass zun\u00e4chst in Kubernetes Anfragen an interne Projekte gesendet werden, w\u00e4hrend wir allm\u00e4hlich den restlichen Datenverkehr \u00fcber HAProxy umleiten, indem wir das Gewicht f\u00fcr das Backend \u00e4ndern. Im Prozess des Wechsels von VMs zu Kubernetes wurde deutlich, dass es sehr vorteilhaft ist, eine einfache Methode zur Umleitung von Datenverkehr zwischen der alten und der neuen Infrastruktur bereit zu haben und die alte Infrastruktur f\u00fcr die ersten Tage nach der Migration bereitzuhalten.<\/p>\n<h3>5. Notfallkapazit\u00e4ten der Pods und deren Nutzung<\/h3>\n<p>\nFast sofort trat das n\u00e4chste Problem auf: Die Pods f\u00fcr den Registry-Service starteten schnell, w\u00e4hrend der Start der Pods f\u00fcr Sidekiq bis zu <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-org\/charts\/gitlab\/-\/issues\/1775\">zwei Minuten<\/a><\/noindex>. Der langwierige Start der Pods f\u00fcr Sidekiq wurde problematisch, als wir begannen, die Arbeitslasten f\u00fcr Worker, die Jobs schnell verarbeiten und schnell skalieren m\u00fcssen, nach Kubernetes zu migrieren.<\/p>\n<p>In diesem Fall bestand die Lektion darin, dass der Horizontal Pod Autoscaler (HPA) in Kubernetes zwar gut mit steigendem Traffic umgehen kann, es jedoch wichtig ist, die Eigenschaften der Workloads zu ber\u00fccksichtigen und Reservespeicher f\u00fcr Pods bereitzustellen (insbesondere unter Bedingungen mit ungleichm\u00e4\u00dfiger Nachfragedistribution). In unserem Fall gab es einen pl\u00f6tzlichen Anstieg von Jobs, was zu einer rasanten Skalierung f\u00fchrte und die CPU-Ressourcen saturierte, bevor wir den Knotenspeicher skalieren konnten.<\/p>\n<p>Es besteht immer die Versuchung, so viel wie m\u00f6glich aus dem Cluster herauszuholen, jedoch beginnen wir, nachdem wir anf\u00e4nglich mit Leistungsproblemen konfrontiert waren, jetzt mit einem gro\u00dfz\u00fcgigen Pod-Budget und reduzieren dieses anschlie\u00dfend, w\u00e4hrend wir die SLO genau \u00fcberwachen. Das Starten von Pods f\u00fcr den Sidekiq-Service hat sich deutlich beschleunigt und dauert jetzt im Durchschnitt etwa 40 Sekunden. <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-org\/charts\/gitlab\/-\/issues\/1775\">Von der Verk\u00fcrzung der Pod-Startzeit<\/a><\/noindex> haben sowohl GitLab.com als auch unsere Nutzer, die mit der offiziellen GitLab-Helm-Chart arbeiten und selbstverwaltete Installationen betreiben, profitiert.<\/p>\n<h2>Fazit<\/h2>\n<p>\nNach der Migration jedes Dienstes haben wir die Vorteile von Kubernetes in der Produktion genossen: schnellere und sicherere Bereitstellung von Anwendungen, Skalierung und effizientere Ressourcennutzung. Dar\u00fcber hinaus gehen die Vorteile der Migration \u00fcber den Dienst GitLab.com hinaus. Jeder Nutzer profitiert von den Verbesserungen des offiziellen Helm-Charts.<\/p>\n<p>Ich hoffe, Ihnen hat die Geschichte \u00fcber unsere Abenteuer mit der Migration zu Kubernetes gefallen. Wir setzen die Migration weiterer Dienste in den Cluster fort. Weitere Informationen finden Sie in den folgenden Ver\u00f6ffentlichungen:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/handbook\/engineering\/infrastructure\/production\/kubernetes\/gitlab-com\/\">Warum migrieren wir zu Kubernetes?<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/handbook\/engineering\/infrastructure\/production\/architecture\/#gitlab-com-on-kubernetes\">GitLab.com auf Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/groups\/gitlab-com\/gl-infra\/-\/epics\/112\">Epic der Migration von GitLab.com zu Kubernetes<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>P.S. vom \u00dcbersetzer<\/h2>\n<p>\nLesen Sie auch in unserem Blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/519962\/\">3 Jahre mit Kubernetes in der Produktion: Das haben wir gelernt<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/504396\/\">10 h\u00e4ufige Fehler bei der Nutzung von Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/335814\/\">Erfolgsgeschichten von Kubernetes in der Produktion. Teil 3: GitHub<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/440278\/\">Der Umstieg von Tinder auf Kubernetes<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/520150\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u0430\u0434\u0430\u043f\u0442\u0430\u0446\u0438\u044e Kubernetes \u0432 GitLab \u0441\u0447\u0438\u0442\u0430\u044e\u0442 \u043e\u0434\u043d\u0438\u043c \u0438\u0437 \u0434\u0432\u0443\u0445 \u0433\u043b\u0430\u0432\u043d\u044b\u0445 \u0444\u0430\u043a\u0442\u043e\u0440\u043e\u0432, \u0441\u043f\u043e\u0441\u043e\u0431\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 \u0440\u043e\u0441\u0442\u0443 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438. \u0422\u0435\u043c \u043d\u0435 \u043c\u0435\u043d\u0435\u0435, \u0434\u043e \u043d\u0435\u0434\u0430\u0432\u043d\u0435\u0433\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0438 \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0430 \u043e\u043d\u043b\u0430\u0439\u043d-\u0441\u0435\u0440\u0432\u0438\u0441\u0430 GitLab.com \u0431\u044b\u043b\u0430 \u043f\u043e\u0441\u0442\u0440\u043e\u0435\u043d\u0430 \u043d\u0430 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u0445 \u043c\u0430\u0448\u0438\u043d\u0430\u0445, \u0438 \u0442\u043e\u043b\u044c\u043a\u043e \u043e\u043a\u043e\u043b\u043e \u0433\u043e\u0434\u0430 \u043d\u0430\u0437\u0430\u0434 \u043d\u0430\u0447\u0430\u043b\u0430\u0441\u044c \u0435\u0451 \u043c\u0438\u0433\u0440\u0430\u0446\u0438\u044f \u0432 K8s, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0434\u043e \u0441\u0438\u0445 \u043f\u043e\u0440 \u043d\u0435 \u0437\u0430\u0432\u0435\u0440\u0448\u0435\u043d\u0430. \u0420\u0430\u0434\u044b \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u043d\u0435\u0434\u0430\u0432\u043d\u0435\u0439 \u0441\u0442\u0430\u0442\u044c\u0438 SRE-\u0438\u043d\u0436\u0435\u043d\u0435\u0440\u0430 GitLab \u043e \u0442\u043e\u043c, \u043a\u0430\u043a [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":94978,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-94977","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.0.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u0430\u0434\u0430\u043f\u0442\u0430\u0446\u0438\u044e Kubernetes \u0432 GitLab \u0441\u0447\u0438\u0442\u0430\u044e\u0442 \u043e\u0434\u043d\u0438\u043c \u0438\u0437 \u0434\u0432\u0443\u0445 \u0433\u043b\u0430\u0432\u043d\u044b\u0445 \u0444\u0430\u043a\u0442\u043e\u0440\u043e\u0432, \u0441\u043f\u043e\u0441\u043e\u0431\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 \u0440\u043e\u0441\u0442\u0443 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.0.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041d\u0430\u0448\u0438 \u0432\u044b\u0432\u043e\u0434\u044b \u0437\u0430 \u0433\u043e\u0434 \u043c\u0438\u0433\u0440\u0430\u0446\u0438\u0438 GitLab.com \u043d\u0430 Kubernetes | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u0430\u0434\u0430\u043f\u0442\u0430\u0446\u0438\u044e Kubernetes \u0432 GitLab \u0441\u0447\u0438\u0442\u0430\u044e\u0442 \u043e\u0434\u043d\u0438\u043c \u0438\u0437 \u0434\u0432\u0443\u0445 \u0433\u043b\u0430\u0432\u043d\u044b\u0445 \u0444\u0430\u043a\u0442\u043e\u0440\u043e\u0432, \u0441\u043f\u043e\u0441\u043e\u0431\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 \u0440\u043e\u0441\u0442\u0443 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-09-24T05:43:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-09-24T05:43:00+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Unsere Erkenntnisse aus einem Jahr Migration von GitLab.com zu Kubernetes | ProHoster","description":"Hinweis: Die Anpassung von Kubernetes in GitLab wird als einer von zwei Hauptfaktoren angesehen, die zum Wachstum des Unternehmens beitragen.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041d\u0430\u0448\u0438 \u0432\u044b\u0432\u043e\u0434\u044b \u0437\u0430 \u0433\u043e\u0434 \u043c\u0438\u0433\u0440\u0430\u0446\u0438\u0438 GitLab.com \u043d\u0430 Kubernetes | ProHoster","og:description":"\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u0430\u0434\u0430\u043f\u0442\u0430\u0446\u0438\u044e Kubernetes \u0432 GitLab \u0441\u0447\u0438\u0442\u0430\u044e\u0442 \u043e\u0434\u043d\u0438\u043c \u0438\u0437 \u0434\u0432\u0443\u0445 \u0433\u043b\u0430\u0432\u043d\u044b\u0445 \u0444\u0430\u043a\u0442\u043e\u0440\u043e\u0432, \u0441\u043f\u043e\u0441\u043e\u0431\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 \u0440\u043e\u0441\u0442\u0443 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-09-24T05:43:00+00:00","article:modified_time":"2020-09-24T05:43:00+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"94977","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 11:14:45","updated":"2022-10-03 07:39:43","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/94977","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=94977"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/94977\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/94978"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=94977"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=94977"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=94977"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}