Notera. transl.: Kubernetes adoption på GitLab anses vara en av de två huvudfaktorerna som bidrar till företagets tillväxt. Men tills nyligen byggdes infrastrukturen för onlinetjänsten GitLab.com på virtuella maskiner, och bara för ungefär ett år sedan började dess migrering till K8s, som fortfarande inte är klar. Vi är glada att kunna presentera en översättning av en färsk artikel av en GitLab SRE-ingenjör om hur detta händer och vilka slutsatser ingenjörerna som deltar i projektet drar.
Sedan ungefär ett år tillbaka har vår infrastrukturavdelning migrerat alla tjänster som körs på GitLab.com till Kubernetes. Under denna tid stötte vi på utmaningar relaterade inte bara till att flytta tjänster till Kubernetes, utan också till att hantera hybriddistributionen under övergången. De värdefulla lärdomarna vi lärde oss kommer att diskuteras i den här artikeln.
Redan från början av GitLab.com körde dess servrar i molnet på virtuella maskiner. Dessa virtuella maskiner hanteras av Chef och installeras med vår . om applikationen behöver uppdateras, består av att helt enkelt uppdatera serverflottan på ett koordinerat, sekventiellt sätt med hjälp av en CI-pipeline. Denna metod - om än långsam och lite - säkerställer att GitLab.com använder samma installations- och konfigurationspraxis som offlineanvändare (självförvaltande) GitLab-installationer med våra Linux-paket för detta.
Vi använder den här metoden eftersom det är oerhört viktigt att uppleva alla de sorger och glädjeämnen som vanliga medlemmar i communityn upplever när de installerar och konfigurerar sina kopior av GitLab. Det här tillvägagångssättet fungerade bra under en tid, men när antalet projekt på GitLab översteg 10 miljoner insåg vi att det inte längre mötte våra behov av skalning och driftsättning.
Första stegen till Kubernetes och molnbaserade GitLab
Projektet skapades 2017 för att förbereda GitLab för molninstallation och för att göra det möjligt för användare att installera GitLab på Kubernetes-kluster. Vi visste då att att flytta GitLab till Kubernetes skulle öka skalbarheten för SaaS-plattformen, förenkla implementeringar och förbättra effektiviteten hos datorresurser. Samtidigt berodde många av funktionerna i vår applikation på monterade NFS-partitioner, vilket saktade ner övergången från virtuella maskiner.
Strävan mot molnbaserad och Kubernetes gjorde det möjligt för våra ingenjörer att planera en gradvis övergång, under vilken vi övergav några av applikationens beroende av nätverkslagring samtidigt som vi fortsatte att utveckla nya funktioner. Sedan vi började planera migreringen sommaren 2019 har många av dessa begränsningar lösts, och processen att migrera GitLab.com till Kubernetes är nu igång!
Funktioner hos GitLab.com i Kubernetes
För GitLab.com använder vi ett enda regionalt GKE-kluster som hanterar all programtrafik. För att minimera komplexiteten i den (redan knepiga) migreringen fokuserar vi på tjänster som inte är beroende av lokal lagring eller NFS. GitLab.com använder en övervägande monolitisk Rails-kodbas, och vi dirigerar trafik baserat på arbetsbelastningsegenskaper till olika slutpunkter som är isolerade i sina egna nodpooler.
När det gäller frontend är dessa typer uppdelade i förfrågningar till webb, API, Git SSH/HTTPS och Registry. När det gäller backend delar vi upp jobben i kön efter olika egenskaper beroende på , som gör att vi kan ställa in servicenivåmål (SLO) för olika arbetsbelastningar.
Alla dessa GitLab.com-tjänster är konfigurerade med ett omodifierat GitLab Helm-diagram. Konfiguration utförs i underdiagram, som selektivt kan aktiveras när vi gradvis migrerar tjänster till klustret. Även om vi beslutade att inte inkludera några av våra statliga tjänster i migreringen, såsom Redis, Postgres, GitLab Pages och Gitaly, tillåter användningen av Kubernetes oss att radikalt minska antalet virtuella datorer som Chef för närvarande hanterar.
Kubernetes konfigurationssynlighet och hantering
Alla inställningar hanteras av GitLab själv. För detta används tre konfigurationsprojekt baserade på Terraform och Helm. Vi försöker använda själva GitLab när det är möjligt för att köra GitLab, men för operativa uppgifter har vi en separat GitLab-installation. Detta behövs för att säkerställa att du inte är beroende av tillgängligheten av GitLab.com när du utför GitLab.com-distributioner och uppdateringar.
Även om våra pipelines för Kubernetes-klustret körs på en separat GitLab-installation, finns det speglar av kodarkiven som är allmänt tillgängliga på följande adresser:
- — GitLab.com konfigurationsramverk för GitLab Helm-diagrammet;
- - Innehåller konfigurationer för tjänster som inte är direkt associerade med GitLab-applikationen. Dessa inkluderar konfigurationer för loggning och klusterövervakning, samt integrerade verktyg som PlantUML;
- — Terraform-konfiguration för Kubernetes och äldre VM-infrastruktur. Här konfigurerar du alla resurser som krävs för att köra klustret, inklusive själva klustret, nodpooler, tjänstekonton och IP-adressreservationer.
Offentlig vy visas när ändringar görs. med en länk till den detaljerade diff som SRE analyserar innan ändringar görs i klustret.
För SRE leder länken till en detaljerad diff i GitLab-installationen, som används för produktion och åtkomst till vilken är begränsad. Detta tillåter anställda och samhället, utan tillgång till det operativa projektet (som endast är öppet för SREs), att se föreslagna konfigurationsändringar. Genom att kombinera en offentlig GitLab-instans för kod med en privat instans för CI-pipelines upprätthåller vi ett enda arbetsflöde samtidigt som vi säkerställer oberoende från GitLab.com för konfigurationsuppdateringar.
Vad vi fick reda på under migrationen
Under flytten fick vi erfarenheter av att vi tillämpar på nya migrationer och implementeringar i Kubernetes.
1. Ökade kostnader på grund av trafik mellan tillgänglighetszoner
Daglig utträdesstatistik (byte per dag) för Git-förrådets flotta på GitLab.com
Google delar upp sitt nätverk i regioner. Dessa är i sin tur indelade i tillgänglighetszoner (AZ). Git-hosting är förknippat med stora datamängder, så det är viktigt för oss att kontrollera nätverkets utgång. För intern trafik är utgående endast gratis om den stannar inom samma tillgänglighetszon. När detta skrivs serverar vi cirka 100 TB data under en vanlig arbetsdag (och det är bara för Git-förråd). Tjänster som fanns i samma virtuella maskiner i vår gamla VM-baserade topologi körs nu i olika Kubernetes-poddar. Detta innebär att viss trafik som tidigare var lokal för den virtuella datorn potentiellt skulle kunna resa utanför tillgänglighetszoner.
Regionala GKE-kluster låter dig spänna över flera tillgänglighetszoner för redundans. Vi överväger möjligheten för tjänster som genererar stora trafikvolymer. Detta kommer att minska utgående kostnader samtidigt som redundansen på klusternivå bibehålls.
2. Gränser, resursbegäranden och skalning
Antalet repliker som bearbetar produktionstrafik på registry.gitlab.com. Trafiken toppar vid ~15:00 UTC.
Vår migreringshistoria började i augusti 2019, när vi migrerade vår första tjänst, GitLab Container Registry, till Kubernetes. Denna verksamhetskritiska tjänst med hög trafik var ett bra val för den första migreringen eftersom det är en tillståndslös applikation med få externa beroenden. Det första problemet vi stötte på var ett stort antal vräkta baljor på grund av brist på minne på noderna. På grund av detta var vi tvungna att ändra förfrågningar och gränser.
Det upptäcktes att i fallet med en applikation där minnesförbrukningen ökar med tiden, ledde låga värden för förfrågningar (reservera minne för varje pod) tillsammans med en "generös" hård gräns för användning till mättnad (mättnad) noder och en hög nivå av vräkningar. För att hantera detta problem var det . Detta tog trycket från noderna och säkerställde att poddarna hade en livscykel som inte satte för mycket press på noden. Nu startar vi migreringar med generösa (och nästan identiska) förfrågningar och gränsvärden, och justerar dem vid behov.
3. Mätvärden och loggar
Infrastrukturdivisionen fokuserar på latens, felfrekvenser och mättnad med installerat (SLO) länkad till .
Under det senaste året har en av nyckelhändelserna inom infrastrukturdivisionen varit förbättringar av övervakning och arbete med SLO:er. SLO:er gjorde det möjligt för oss att sätta upp mål för enskilda tjänster som vi noga övervakade under migreringen. Men även med denna förbättrade observerbarhet är det inte alltid möjligt att omedelbart se problem med hjälp av mätvärden och varningar. Genom att till exempel fokusera på latens och felfrekvens täcker vi inte helt alla användningsfall för en tjänst som genomgår migrering.
Det här problemet upptäcktes nästan omedelbart efter migrering av vissa arbetsbelastningar till klustret. Särskilt akut blev det när vi skulle kontrollera funktioner för vilka antalet förfrågningar var litet, men som hade mycket specifika konfigurationsberoenden. En av de viktigaste lärdomarna från migreringen var behovet av att inte bara ta hänsyn till mätvärden vid övervakning, utan även loggar och "long tail" (det här handlar om på diagrammet - ca. översätt.) fel. Nu för varje migrering inkluderar vi en detaljerad lista med loggfrågor (loggfrågor) och planera tydliga rollback-procedurer som kan överföras från ett skift till nästa om problem uppstår.
Att betjäna samma förfrågningar parallellt på den gamla VM-infrastrukturen och den nya Kubernetes-baserade infrastrukturen var en unik utmaning. Till skillnad från lift-and-shift-migrering (snabb överföring av applikationer "i befintligt skick" till en ny infrastruktur; mer detaljer kan läsas t.ex. - cirka. översätt.), kräver parallellt arbete med "gamla" virtuella datorer och Kubernetes att övervakningsverktyg är kompatibla med båda miljöerna och kan kombinera mätvärden till en vy. Det är viktigt att vi använder samma instrumentpaneler och loggfrågor för att uppnå konsekvent observerbarhet under övergångsperioden.
4. Byta trafik till ett nytt kluster
För GitLab.com är en del av servrarna dedikerade till . Canary Park betjänar våra interna projekt och kan också . Men den är i första hand utformad för att testa ändringar som gjorts i infrastrukturen och applikationen. Den första migrerade tjänsten började med att acceptera en begränsad mängd intern trafik, och vi fortsätter att använda den här metoden för att säkerställa att SLOs uppfylls innan all trafik skickas till klustret.
Vid migrering innebär det att förfrågningar till interna projekt skickas till Kubernetes först, och sedan byter vi successivt resten av trafiken till klustret genom att ändra vikten för backend genom HAProxy. Under migreringen från VM till Kubernetes blev det tydligt att det var mycket fördelaktigt att ha ett enkelt sätt att omdirigera trafik mellan den gamla och nya infrastrukturen och följaktligen hålla den gamla infrastrukturen redo för återställning under de första dagarna efter migreringen.
5. Reservkapacitet för baljor och deras användning
Nästan omedelbart identifierades följande problem: pods för Registry-tjänsten startade snabbt, men lanseringen av pods för Sidekiq tog upp till . Den långa starttiden för Sidekiq-poddar blev ett problem när vi började migrera arbetsbelastningar till Kubernetes för arbetare som behövde bearbeta jobb snabbt och skalas snabbt.
I det här fallet var lärdomen att medan Kubernetes Horizontal Pod Autoscaler (HPA) hanterar trafiktillväxt bra, är det viktigt att ta hänsyn till egenskaperna hos arbetsbelastningarna och allokera reservkapacitet till poddarna (särskilt när efterfrågan är ojämnt fördelad). I vårt fall var det en plötslig ökning av jobb, vilket ledde till snabb skalning, vilket ledde till mättnad av CPU-resurser innan vi hann skala nodpoolen.
Det finns alltid en frestelse att pressa ut så mycket som möjligt ur ett kluster, men efter att ha stött på prestandaproblem från början börjar vi nu med en generös podbudget och minskar den senare, och håller noga koll på SLOs. Lanseringen av poddar för Sidekiq-tjänsten har accelererat avsevärt och tar nu cirka 40 sekunder i genomsnitt. vann både GitLab.com och våra användare av självhanterade installationer som arbetar med det officiella GitLab Helm-diagrammet.
Slutsats
Efter att ha migrerat varje tjänst gläds vi åt fördelarna med att använda Kubernetes i produktionen: snabbare och säkrare applikationsdistribution, skalning och effektivare resursallokering. Dessutom går fördelarna med migrering utöver GitLab.com-tjänsten. Varje förbättring av det officiella Helm-diagrammet gynnar dess användare.
Jag hoppas att du gillade historien om våra Kubernetes-migreringsäventyr. Vi fortsätter att migrera alla nya tjänster till klustret. Ytterligare information finns i följande publikationer:
- «";
- «";
- .
PS från översättaren
Läs även på vår blogg:
- «";
- «";
- «";
- «".
Källa: will.com