Obs. övers.: att anpassa Kubernetes i GitLab anses vara en av tvĂ„ huvudfaktorer som bidrar till företagets tillvĂ€xt. ĂndĂ„ har infrastrukturen för onlinetjĂ€nsten GitLab.com fram till nyligen byggts pĂ„ virtuella maskiner, och det var först för ett Ă„r sedan som migrationen till K8s började, och den pĂ„gĂ„r fortfarande. Vi Ă€r glada att presentera en översĂ€ttning av en nyligen publicerad artikel av SRE-ingenjören pĂ„ GitLab om hur detta görs och vilka slutsatser ingenjörerna som deltar i projektet gör.
Sedan ungefÀr ett Är tillbaka har vÄr infrastrukturavdelning arbetat med att migrera alla tjÀnster som körs pÄ GitLab.com till Kubernetes. Under denna tid har vi stött pÄ problem relaterade inte bara till flytt av tjÀnster till Kubernetes, utan ocksÄ med att hantera en hybriddeployment under övergÄngen. Det Àr vÀrdefulla lÀrdomar som vi har fÄtt som vi kommer att diskutera i denna artikel.
FrĂ„n början har GitLab.coms servrar fungerat i molnet pĂ„ virtuella maskiner. Dessa virtuella maskiner hanteras av Chef, och deras installation sker via vĂ„r . i hĂ€ndelse av att applikationen behöver uppdateras, bestĂ„r av en enkel uppdatering av serverparken pĂ„ ett koordinerat och sekventiellt sĂ€tt med hjĂ€lp av en CI-pipeline. Denna metod â Ă€ven om den Ă€r lĂ„ngsam och lite (self-managed) GitLab-installationer, som anvĂ€nder vĂ„ra Linux-paket för detta. Vi anvĂ€nder denna metod eftersom det Ă€r av yttersta vikt att uppleva alla sorg och glĂ€dje som vanliga medlemmar i samhĂ€llet upplever nĂ€r de installerar och konfigurerar sina kopior av GitLab. Denna metod har fungerat bra under en tid, men nĂ€r antalet projekt pĂ„ GitLab passerade 10 miljoner insĂ„g vi att den inte lĂ€ngre tillgodose vĂ„ra behov pĂ„ skalning och distribution.
De första stegen mot Kubernetes och cloud-native GitLab
Ă r 2017 startades projektet
GitLab Charts för att förbereda GitLab för distribution i molnet, samt för att ge anvÀndarna möjlighet att installera GitLab i Kubernetes-kluster. DÄ visste vi att flytten av GitLab till Kubernetes skulle öka skalbarheten för SaaS-plattformen, förenkla distributioner och förbÀttra resursanvÀndningen. Samtidigt var mÄnga funktioner i vÄr applikation beroende av monterade NFS-partitioner, vilket fördröjde övergÄngen frÄn virtuella maskiner.
StrÀvan efter cloud native och Kubernetes har gjort det möjligt för vÄra ingenjörer att planera en gradvis övergÄng, dÀr vi har avbrutit vissa beroenden av applikationen till 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 avlÀgsnats, och processen för att flytta GitLab.com till Kubernetes Àr nu i full gÄng!
Funktioner för GitLab.com i Kubernetes
För GitLab.com anvÀnder vi en enda regional GKE-kluster som hanterar all trafik till applikationen. För att minimera komplexiteten (som redan Àr svÄr) i migreringen, fokuserar vi pÄ tjÀnster som inte Àr beroende av lokal lagring eller NFS. GitLab.com anvÀnder huvudsakligen en monolitisk kodbas pÄ Rails, och vi dirigerar trafiken beroende av arbetsbelastningens egenskaper till olika slutpunkter som isoleras i sina egna nodpooler.
NÀr det gÀller frontenden delas dessa typer upp i förfrÄgningar till webben, API, Git SSH/HTTPS och Registry. För backend delar vi upp jobben i köer baserat pÄ olika egenskaper beroende pÄ , vilket gör att vi kan sÀtta mÄl för servicenivÄ (Service-Level Objectives, SLOs) för olika belastningar.
Alla dessa tjÀnster pÄ GitLab.com Àr konfigurerade med den oförÀndrade Helm-diagrammet för GitLab. Konfigurationen görs i subdiagram som kan vÀljas att inkluderas allt eftersom vi gradvis flyttar tjÀnster till klustret. Trots att det beslutades att inte inkludera vissa av vÄra stateful-tjÀnster i migreringen, som Redis, Postgres, GitLab Pages och Gitaly, gör Kubernetes det möjligt att radikalt minska antalet VM som för nÀrvarande hanteras av Chef.
Transparens och hantering av Kubernetes-konfiguration
Alla instÀllningar hanteras av GitLab sjÀlv. Tre konfigurationsprojekt baserade pÄ Terraform och Helm anvÀnds för detta. Vi försöker anvÀnda GitLab sÄ mycket som möjligt för att starta GitLab, men för driftsuppgifter har vi en separat installation av GitLab. Den behövs för att inte vara beroende av tillgÀngligheten av GitLab.com vid utrullningar och uppdateringar av GitLab.com.
Ăven om vĂ„ra pipelines för Kubernetes-klustret körs pĂ„ en separat installation av GitLab, har kodförvaren speglar som Ă€r offentligt tillgĂ€ngliga pĂ„ följande adresser:
- â konfigurationsbindning för GitLab.com för Helm-diagrammet GitLab;
- â innehĂ„ller konfigurationer för tjĂ€nster som inte Ă€r direkt relaterade till applikationen GitLab. Dessa inkluderar konfigurationer för logghantering och övervakning av klustret, samt för integrerade verktyg som PlantUML;
- â Terraform-konfiguration för Kubernetes och den Ă€ldre (legacy) VM-infrastrukturen. HĂ€r konfigureras alla resurser som behövs för att starta klustret, inklusive sjĂ€lva klustret, nodpooler, tjĂ€nstekonton och reservering av IP-adresser.
NÀr Àndringar görs visas en offentlig med en lÀnk till en detaljerad diff som SRE analyserar innan Àndringar införs i klustret.
För SRE leder lÀnken till en detaljerad diff i den installation av GitLab som anvÀnds för drift och som har begrÀnsad Ätkomst. Detta gör att anstÀllda och samhÀllet utan Ätkomst till driftsprojektet (som endast Àr öppet för SRE) kan granska föreslagna Àndringar i konfigurationen. Genom att kombinera en offentlig GitLab-instans för kod med en privat instans för CI-pipelines behÄller vi en enhetlig arbetsprocess, samtidigt som vi garanterar oberoende frÄn GitLab.com vid konfigurationsuppdateringar.
Vad vi har lÀrt oss under migreringen
Under flytten har erfarenhet samlats som vi tillÀmpar pÄ nya migrationer och distributioner i Kubernetes.
1. Ăkade kostnader pĂ„ grund av trafik mellan tillgĂ€nglighetszoner
Daglig egress-statistik (byte per dag) för parken av Git-förvar pÄ GitLab.com
Google delar sitt nÀtverk i regioner. Dessa delas i sin tur upp i tillgÀnglighetszoner (AZ). Git-hosting Àr kopplad till stora datamÀngder, sÄ det Àr viktigt för oss att kontrollera nÀtverksutgÄende trafik. Inom intern trafik Àr utgÄende trafik gratis endast om den stannar inom en och samma tillgÀnglighetszon. Vid tiden för denna artikel överför vi cirka 100 TB data en vanlig arbetsdag (och detta gÀller endast för Git-repositorier). TjÀnster som i vÄr gamla VM-baserade topologi lÄg pÄ samma virtuella maskiner fungerar nu i olika poddar i Kubernetes. Det innebÀr att en del av trafiken som tidigare var lokal för VM potentiellt kan gÄ utanför tillgÀnglighetszonerna.
Regionala GKE-kluster gör det möjligt att tÀcka flera tillgÀnglighetszoner för redundans. Vi övervÀger att för tjÀnster som genererar stora mÀngder trafik. Detta skulle minska kostnaderna för utgÄende trafik samtidigt som redundansen pÄ klusternivÄ bibehÄlls.
2. ResursbegrÀnsningar, resursförfrÄgningar och skalning
Antalet repliker som hanterar produktionstrafik pÄ registry.gitlab.com. Trafiken nÄr sin topp runt 15:00 UTC.
VĂ„r migrationshistoria började i augusti 2019 nĂ€r vi flyttade den första tjĂ€nsten â GitLab Container Registry â till Kubernetes. Denna kritiskt viktiga tjĂ€nst med hög trafik passade bra för den första migreringen eftersom den Ă€r en stateless-applikation med fĂ„ externa beroenden. Det första problemet vi stötte pĂ„ var ett stort antal borttagna poddar pĂ„ grund av brist pĂ„ minne pĂ„ noderna. Detta tvingade oss att Ă€ndra resursförfrĂ„gningar och begrĂ€nsningar.
Det upptÀcktes att för applikationer vars minnesanvÀndning vÀxer över tid, lÄga vÀrden för resursförfrÄgningar (som reserverar minne för varje pod) i kombination med en "generös" hÄrd begrÀnsning pÄ anvÀndning ledde till mÀttnad (saturation) av noder och en hög nivÄ av borttagningar. För att hantera detta problem beslutades det att . Detta minskade trycket pÄ noderna och sÀkerstÀllde en livscykel för poddar som inte utövade för stort tryck pÄ noden. Nu pÄbörjar vi migrationer med generösa (och nÀstan identiska) vÀrden för begÀrningar och begrÀnsningar, som vi justerar vid behov.
3. Metrik och loggar
Infrastrukturavdelningen fokuserar pÄ latens, felprocent och mÀttnad med faststÀllda (SLO) kopplade till .
Under det gÄngna Äret har en av de viktigaste hÀndelserna inom infrastrukturavdelningen varit förbÀttringar inom övervakning och arbete med SLO. SLO har tillÄtit oss att sÀtta mÄl för specifika tjÀnster, som vi noggrant övervakade under migrationen. Men Àven med sÄdan förbÀttrad övervakning Àr det inte alltid lÀtt att genast se problem med hjÀlp av metrik och aviseringar. Till exempel, genom att fokusera pÄ latens och felprocent tÀcker vi inte fullt ut alla anvÀndningssituationer för tjÀnsten som genomgÄr migration.
Ù۰ۧ problemet upptĂ€cktes nĂ€stan omedelbart efter att en del av arbetsbelastningen flyttades till klustret. Det blev sĂ€rskilt pĂ„tagligt nĂ€r vi behövde kontrollera funktioner med ett lĂ„gt antal förfrĂ„gningar, men som har mycket specifika konfigurationsberoenden. En av de viktigaste lĂ€rdomarna frĂ„n migrationen blev att vi inte bara ska ta hĂ€nsyn till metrik, utan Ă€ven loggar och 'lĂ„ngsvansen' (det handlar om pĂ„ grafen â anm. övers. av fel. Nu inkluderar vi en detaljerad lista över loggförfrĂ„gningar (log queries) och planerar tydliga Ă„terstĂ€llningsprocedurer som vid problem kan överföras frĂ„n ett skift till ett annat.
Parallell drift av samma förfrĂ„gningar pĂ„ den gamla VM-infrastrukturen och den nya, baserad pĂ„ Kubernetes, utgjorde en unik utmaning. Till skillnad frĂ„n en lift-and-shift-migration (snabb överföring av applikationer 'som de Ă€r' till en ny infrastruktur; mer kan lĂ€sas om detta, till exempel, â anm. red.), parallellt arbete pĂ„ "gamla" VM och Kubernetes krĂ€ver att verktygen för övervakning Ă€r kompatibla med bĂ„da miljöerna och kan kombinera mĂ€tvĂ€rden i en enhetlig vy. Det Ă€r viktigt att vi anvĂ€nder samma dashboards och loggförrfrĂ„gningar för att uppnĂ„ en konsekvent övervakning under övergĂ„ngsperioden.
4. VĂ€xling av trafik till den nya klustret
För GitLab.com avsÀtts en del servrar för . Kanariefarkosten betjÀnar vÄra interna projekt samt kan . Men i första hand Àr den avsedd för att testa förÀndringar som görs i infrastrukturen och applikationen. Den första flyttade tjÀnsten började med att ta emot en begrÀnsad mÀngd intern trafik, och vi fortsÀtter att anvÀnda denna metod för att sÀkerstÀlla att SLO följs innan vi dirigerar all trafik till klustret.
Vid migrering innebÀr detta att förfrÄgningar till interna projekt först riktas till Kubernetes, och sedan gradvis vÀxlar vi den andra trafiken till klustret genom att Àndra vikten för backend via HAProxy. Under övergÄngen frÄn VM till Kubernetes blev det tydligt att det Àr mycket fördelaktigt att ha en enkel metod för att omdirigera trafik mellan den gamla och den nya infrastrukturen och dÀrmed hÄlla den gamla infrastrukturen redo för ÄtergÄng under de första dagarna efter migreringen.
5. Reservkapacitet för poddar och deras anvÀndning
NÀstan omedelbart identifierades följande problem: poddar för tjÀnsten Registry startade snabbt, men uppstarten av poddar för Sidekiq tog upp till . Den lÄngvariga uppstarten av poddar för Sidekiq blev ett problem nÀr vi började migrera arbetsbelastningar för arbetare till Kubernetes, som behöver snabbt bearbeta jobb och snabbt kunna skala.
LÀrdomen hÀr var att, Àven om Horizontal Pod Autoscaler (HPA) i Kubernetes hanterar trafikökningar vÀl, Àr det viktigt att ta hÀnsyn till egenskaperna hos arbetsbelastningar och avsÀtta reservkapacitet för poddar (sÀrskilt under obalanserad efterfrÄgan). I vÄrt fall observerades en plötslig ökning av jobb som krÀvde snabb skalning, vilket ledde till att CPU-resurserna mÀttades innan vi kunde skala nodpoolen.
Det finns alltid en frestelse att maximera vad man kan "fÄ ut" av klustret, men vi, som initialt stötte pÄ prestandaproblem, börjar nu med en generös podbudget och minskar den senare, samtidigt som vi noggrant övervakar SLO. Lanseringen av poddar för Sidekiq-tjÀnsten har betydligt pÄskyndats och tar nu i genomsnitt cirka 40 sekunder. har bÄde GitLab.com och vÄra anvÀndare av sjÀlvhanterade installationer, som arbetar med GitLabs officiella Helm-diagram, dragit nytta av detta.
Slutsats
Efter flytten av varje tjÀnst har vi glÀdjats Ät fördelarna med att anvÀnda Kubernetes i produktion: snabbare och sÀkrare applikationsdeployer, skalbarhet och mer effektiv resursfördelning. Fördelarna med migreringen strÀcker sig dessutom bortom GitLab.com-tjÀnsten. Varje förbÀttring av det officiella Helm-diagrammet gynnar dess anvÀndare.
Jag hoppas att ni gillade berÀttelsen om vÄra Àventyr med migreringen till Kubernetes. Vi fortsÀtter att flytta allt fler tjÀnster till klustret. Mer information kan hÀmtas frÄn följande publikationer:
- «»;
- «»;
- .
P.S. frÄn översÀttaren
LÀs Àven i vÄr blogg:
- «»;
- «»;
- «»;
- «».
KĂ€lla: habr.com
