Opmerking. vert.: De adoptie van Kubernetes bij GitLab wordt beschouwd als een van de twee belangrijkste factoren die bijdragen aan de groei van het bedrijf. Tot voor kort was de infrastructuur van de online service GitLab.com echter gebouwd op virtuele machines, en pas ongeveer een jaar geleden begon de migratie naar K8s, die nog steeds niet is voltooid. Met genoegen presenteren we een vertaling van een recent artikel van een GitLab SRE-ingenieur over hoe dit gebeurt en welke conclusies de ingenieurs die aan het project deelnemen trekken.
Onze infrastructuurdivisie migreert nu al ongeveer een jaar alle diensten die op GitLab.com draaien naar Kubernetes. Gedurende deze tijd kwamen we uitdagingen tegen die niet alleen te maken hadden met het verplaatsen van services naar Kubernetes, maar ook met het beheren van de hybride implementatie tijdens de transitie. De waardevolle lessen die we hebben geleerd, worden in dit artikel besproken.
Vanaf het allereerste begin van GitLab.com draaiden de servers in de cloud op virtuele machines. Deze virtuele machines worden beheerd door Chef en geïnstalleerd met behulp van onze . in het geval dat de applicatie moet worden bijgewerkt, bestaat uit het simpelweg updaten van de servervloot op een gecoördineerde, sequentiële manier met behulp van een CI-pijplijn. Deze methode - zij het langzaam en een beetje - zorgt ervoor dat GitLab.com dezelfde installatie- en configuratiepraktijken gebruikt als offline gebruikers (zelfbeheerd) GitLab-installaties met behulp van onze Linux-pakketten hiervoor.
We gebruiken deze methode omdat het uiterst belangrijk is om al het verdriet en de vreugde te ervaren die gewone leden van de gemeenschap ervaren bij het installeren en configureren van hun exemplaren van GitLab. Deze aanpak werkte een tijdje goed, maar toen het aantal projecten op GitLab de 10 miljoen overschreed, realiseerden we ons dat het niet langer voldeed aan onze behoeften op het gebied van schaalvergroting en implementatie.
Eerste stappen naar Kubernetes en cloud-native GitLab
Het project is in 2017 ontstaan om GitLab voor te bereiden op cloudimplementatie en om gebruikers in staat te stellen GitLab op Kubernetes-clusters te installeren. We wisten toen dat het verplaatsen van GitLab naar Kubernetes de schaalbaarheid van het SaaS-platform zou vergroten, de implementatie zou vereenvoudigen en de efficiëntie van computerbronnen zou verbeteren. Tegelijkertijd waren veel van de functies van onze applicatie afhankelijk van aangekoppelde NFS-partities, wat de overgang van virtuele machines vertraagde.
Dankzij de drang naar cloud-native en Kubernetes konden onze technici een geleidelijke transitie plannen, waarbij we een deel van de afhankelijkheden van de applicatie op netwerkopslag achterwege lieten en tegelijkertijd nieuwe functies bleven ontwikkelen. Sinds we in de zomer van 2019 begonnen met het plannen van de migratie, zijn veel van deze beperkingen opgelost en is het proces van het migreren van GitLab.com naar Kubernetes nu in volle gang!
Kenmerken van GitLab.com in Kubernetes
Voor GitLab.com gebruiken we één regionaal GKE-cluster dat al het applicatieverkeer afhandelt. Om de complexiteit van de (toch toch al lastige) migratie te minimaliseren, richten wij ons op diensten die niet afhankelijk zijn van lokale opslag of NFS. GitLab.com gebruikt een overwegend monolithische Rails-codebase en we routeren verkeer op basis van werklastkenmerken naar verschillende eindpunten die geïsoleerd zijn in hun eigen knooppuntpools.
In het geval van de frontend zijn deze typen onderverdeeld in verzoeken aan web, API, Git SSH/HTTPS en Registry. In het geval van de backend splitsen we de taken in de wachtrij op basis van verschillende kenmerken, afhankelijk van , waarmee we Service Level Objectives (SLO's) kunnen instellen voor verschillende workloads.
Al deze GitLab.com-services worden geconfigureerd met behulp van een ongewijzigd GitLab Helm-diagram. De configuratie wordt uitgevoerd in subdiagrammen, die selectief kunnen worden ingeschakeld terwijl we services geleidelijk naar het cluster migreren. Hoewel we besloten hebben om een aantal van onze stateful services, zoals Redis, Postgres, GitLab Pages en Gitaly, niet mee te nemen in de migratie, stelt het gebruik van Kubernetes ons in staat het aantal VM’s dat Chef momenteel beheert radicaal te verminderen.
Zichtbaarheid en beheer van Kubernetes-configuratie
Alle instellingen worden beheerd door GitLab zelf. Hiervoor worden drie configuratieprojecten op basis van Terraform en Helm gebruikt. We proberen waar mogelijk GitLab zelf te gebruiken om GitLab te draaien, maar voor operationele taken hebben we een aparte GitLab-installatie. Dit is nodig om ervoor te zorgen dat u niet afhankelijk bent van de beschikbaarheid van GitLab.com bij het uitvoeren van GitLab.com-implementaties en updates.
Hoewel onze pijplijnen voor het Kubernetes-cluster op een afzonderlijke GitLab-installatie draaien, zijn er spiegelservers van de codeopslagplaatsen die openbaar beschikbaar zijn op de volgende adressen:
- — GitLab.com-configuratieframework voor het GitLab Helm-diagram;
- - Bevat configuraties voor services die niet direct verband houden met de GitLab-applicatie. Deze omvatten configuraties voor logboekregistratie en clustermonitoring, evenals geïntegreerde tools zoals PlantUML;
- — Terraform-configuratie voor Kubernetes en oudere VM-infrastructuur. Hier configureert u alle bronnen die nodig zijn om het cluster uit te voeren, inclusief het cluster zelf, knooppuntpools, serviceaccounts en IP-adresreserveringen.
Wanneer er wijzigingen worden aangebracht, wordt de openbare weergave getoond. met een link naar de gedetailleerde diff die SRE analyseert voordat er wijzigingen in het cluster worden aangebracht.
Voor SRE leidt de link naar een gedetailleerde diff in de GitLab-installatie, die wordt gebruikt voor productie en waartoe de toegang beperkt is. Hierdoor kunnen werknemers en de gemeenschap, zonder toegang tot het operationele project (dat alleen toegankelijk is voor SRE's), voorgestelde configuratiewijzigingen bekijken. Door een openbare GitLab-instantie voor code te combineren met een privé-instantie voor CI-pijplijnen, behouden we één enkele workflow en garanderen we tegelijkertijd de onafhankelijkheid van GitLab.com voor configuratie-updates.
Wat we ontdekten tijdens de migratie
Tijdens de verhuizing is ervaring opgedaan die wij toepassen bij nieuwe migraties en implementaties in Kubernetes.
1. Hogere kosten als gevolg van verkeer tussen beschikbaarheidszones
Dagelijkse uitgaande statistieken (bytes per dag) voor de Git-repositoryvloot op GitLab.com
Google verdeelt zijn netwerk in regio’s. Deze zijn op hun beurt onderverdeeld in toegankelijkheidszones (AZ). Git-hosting gaat gepaard met grote hoeveelheden gegevens, dus het is belangrijk dat we het netwerkverkeer onder controle houden. Voor intern verkeer is uitgaand verkeer alleen gratis als het binnen dezelfde beschikbaarheidszone blijft. Op het moment van schrijven verwerken we ongeveer 100 TB aan gegevens op een gemiddelde werkdag (en dat geldt alleen voor Git-repository's). Services die zich in dezelfde virtuele machines in onze oude VM-gebaseerde topologie bevonden, draaien nu in verschillende Kubernetes-pods. Dit betekent dat een deel van het verkeer dat voorheen lokaal was voor de VM mogelijk buiten de beschikbaarheidszones kon reizen.
Met regionale GKE-clusters kunt u meerdere beschikbaarheidszones omspannen voor redundantie. Wij overwegen de mogelijkheid voor diensten die grote verkeersvolumes genereren. Hierdoor worden de uitgaande kosten verlaagd, terwijl de redundantie op clusterniveau behouden blijft.
2. Limieten, resourceverzoeken en schaalvergroting
Het aantal replica's dat productieverkeer op register.gitlab.com verwerkt. Verkeerspieken om ~15:00 UTC.
Ons migratieverhaal begon in augustus 2019, toen we onze eerste service, de GitLab Container Registry, naar Kubernetes migreerden. Deze bedrijfskritische service met veel verkeer was een goede keuze voor de eerste migratie, omdat het een staatloze applicatie is met weinig externe afhankelijkheden. Het eerste probleem dat we tegenkwamen was een groot aantal uitgezette pods vanwege een gebrek aan geheugen op de knooppunten. Hierdoor moesten we verzoeken en limieten wijzigen.
Er werd ontdekt dat in het geval van een applicatie waarbij het geheugenverbruik in de loop van de tijd toeneemt, lage waarden voor verzoeken (waarbij geheugen voor elke pod wordt gereserveerd) in combinatie met een “genereuze” harde limiet voor het gebruik tot verzadiging leidden (verzadiging) knooppunten en een hoog aantal uitzettingen. Om dit probleem aan te pakken, dat was het . Dit nam de druk van de knooppunten weg en zorgde ervoor dat de pods een levenscyclus hadden die niet te veel druk op het knooppunt uitoefende. Nu beginnen we migraties met genereuze (en vrijwel identieke) verzoeken en grenswaarden, en passen we deze indien nodig aan.
3. Statistieken en logboeken
De infrastructuurdivisie richt zich op latentie, foutpercentages en verzadiging met geïnstalleerde (SLO) gekoppeld aan .
Het afgelopen jaar was een van de belangrijkste gebeurtenissen in de infrastructuurdivisie de verbetering van het toezicht op en het werken met SLO's. Met SLO's konden we doelen stellen voor individuele services, die we tijdens de migratie nauwlettend in de gaten hielden. Maar zelfs met deze verbeterde waarneembaarheid is het niet altijd mogelijk om problemen onmiddellijk te zien met behulp van statistieken en waarschuwingen. Door ons bijvoorbeeld te concentreren op latentie- en foutpercentages dekken we niet volledig alle gebruiksscenario's voor een dienst die wordt gemigreerd.
Dit probleem werd vrijwel onmiddellijk ontdekt na het migreren van enkele workloads naar het cluster. Het werd vooral acuut toen we functies moesten controleren waarvoor het aantal verzoeken klein was, maar die zeer specifieke configuratie-afhankelijkheden hadden. Een van de belangrijkste lessen uit de migratie was de noodzaak om bij het monitoren niet alleen rekening te houden met statistieken, maar ook met logboeken en de ‘lange staart’ (dit gaat over op de kaart - ca. vert.) fouten. Nu voegen we voor elke migratie een gedetailleerde lijst met logquery's toe (logboekquery's) en plan duidelijke terugdraaiprocedures die van de ene ploeg naar de andere kunnen worden overgedragen als er zich problemen voordoen.
Het parallel afhandelen van dezelfde verzoeken op de oude VM-infrastructuur en de nieuwe op Kubernetes gebaseerde infrastructuur vormde een unieke uitdaging. In tegenstelling tot lift-and-shift-migratie (snelle overdracht van applicaties “as is” naar een nieuwe infrastructuur; meer details zijn bijvoorbeeld te lezen — ca. vert.)Parallelle werkzaamheden aan ‘oude’ VM’s en Kubernetes vereisen dat monitoringtools compatibel zijn met beide omgevingen en statistieken in één weergave kunnen combineren. Het is belangrijk dat we dezelfde dashboards en logquery's gebruiken om consistente observatie tijdens de transitieperiode te bereiken.
4. Verkeer overzetten naar een nieuw cluster
Voor GitLab.com is een deel van de servers dedicated . Canary Park bedient onze interne projecten en kan dat ook . Maar het is vooral bedoeld om wijzigingen in de infrastructuur en applicatie te testen. De eerste gemigreerde service begon met het accepteren van een beperkte hoeveelheid intern verkeer. We blijven deze methode gebruiken om ervoor te zorgen dat aan de servicedoelstellingen wordt voldaan voordat al het verkeer naar het cluster wordt gestuurd.
In het geval van migratie betekent dit dat verzoeken aan interne projecten eerst naar Kubernetes worden gestuurd, en dat we vervolgens de rest van het verkeer geleidelijk naar het cluster doorschakelen door via HAProxy het gewicht voor de backend te wijzigen. Tijdens de migratie van VM naar Kubernetes werd duidelijk dat het zeer nuttig was om een eenvoudige manier te hebben om verkeer om te leiden tussen de oude en nieuwe infrastructuur en dienovereenkomstig de oude infrastructuur gereed te houden voor rollback in de eerste paar dagen na de migratie.
5. Reservecapaciteiten van peulen en hun gebruik
Vrijwel onmiddellijk werd het volgende probleem vastgesteld: pods voor de Registry-service startten snel, maar het lanceren van pods voor Sidekiq duurde ongeveer . De lange opstarttijd voor Sidekiq-pods werd een probleem toen we begonnen met het migreren van workloads naar Kubernetes voor werknemers die taken snel moesten verwerken en snel moesten opschalen.
In dit geval was de les dat, hoewel de Horizontal Pod Autoscaler (HPA) van Kubernetes de verkeersgroei goed aankan, het belangrijk is om rekening te houden met de kenmerken van de werklasten en reservecapaciteit aan de pods toe te wijzen (vooral wanneer de vraag ongelijk verdeeld is). In ons geval was er een plotselinge toename van het aantal taken, wat leidde tot snelle schaalvergroting, wat leidde tot verzadiging van CPU-bronnen voordat we tijd hadden om de knooppuntpool te schalen.
Er is altijd de verleiding om zoveel mogelijk uit een cluster te persen, maar omdat we in eerste instantie prestatieproblemen hebben ondervonden, beginnen we nu met een genereus pod-budget en verlagen dit later, waarbij we de SLO's nauwlettend in de gaten houden. Het lanceren van pods voor de Sidekiq-service is aanzienlijk versneld en duurt nu gemiddeld ongeveer 40 seconden. won zowel GitLab.com als onze gebruikers van zelfbeheerde installaties die werken met het officiële GitLab Helm-diagram.
Conclusie
Nadat we elke service hadden gemigreerd, waren we blij met de voordelen van het gebruik van Kubernetes in de productie: snellere en veiligere applicatie-implementatie, schaalbaarheid en efficiëntere toewijzing van middelen. Bovendien reiken de voordelen van migratie verder dan de GitLab.com-service. Elke verbetering aan de officiële Helm-grafiek komt de gebruikers ten goede.
Ik hoop dat je genoten hebt van het verhaal van onze Kubernetes-migratie-avonturen. We blijven alle nieuwe services naar het cluster migreren. Aanvullende informatie kunt u vinden in de volgende publicaties:
- «";
- «";
- .
PS van vertaler
Lees ook op onze blog:
- «";
- «";
- «";
- «.
Bron: www.habr.com