Bemærk. overs.: Kubernetes adoption hos GitLab betragtes som en af de to hovedfaktorer, der bidrager til virksomhedens vækst. Indtil for nylig blev infrastrukturen for GitLab.com online-tjenesten bygget på virtuelle maskiner, og for kun omkring et år siden begyndte dens migrering til K8s, som stadig ikke er afsluttet. Vi er glade for at kunne præsentere en oversættelse af en nylig artikel af en GitLab SRE-ingeniør om, hvordan dette sker, og hvilke konklusioner ingeniørerne, der deltager i projektet, drager.
I omkring et år nu har vores infrastrukturafdeling migreret alle tjenester, der kører på GitLab.com, til Kubernetes. I løbet af denne tid stødte vi på udfordringer, der ikke kun var relateret til at flytte tjenester til Kubernetes, men også til at administrere hybridimplementeringen under overgangen. De værdifulde erfaringer, vi lærte, vil blive diskuteret i denne artikel.
Helt fra begyndelsen af GitLab.com kørte dets servere i skyen på virtuelle maskiner. Disse virtuelle maskiner administreres af Chef og installeres ved hjælp af vores . i tilfælde af, at applikationen skal opdateres, består blot i at opdatere serverflåden på en koordineret, sekventiel måde ved hjælp af en CI-pipeline. Denne metode - omend langsom og lidt - sikrer, at GitLab.com bruger samme installations- og konfigurationspraksis som offlinebrugere (selvstyret) GitLab-installationer ved hjælp af vores Linux-pakker til dette.
Vi bruger denne metode, fordi det er ekstremt vigtigt at opleve alle de sorger og glæder, som almindelige medlemmer af fællesskabet oplever, når de installerer og konfigurerer deres kopier af GitLab. Denne tilgang fungerede godt i nogen tid, men da antallet af projekter på GitLab oversteg 10 millioner, indså vi, at det ikke længere opfyldte vores behov for skalering og implementering.
Første trin til Kubernetes og cloud-native GitLab
Projektet blev oprettet i 2017 at forberede GitLab til cloud-implementering og for at gøre det muligt for brugere at installere GitLab på Kubernetes-klynger. Vi vidste dengang, at flytning af GitLab til Kubernetes ville øge skalerbarheden af SaaS-platformen, forenkle implementeringer og forbedre effektiviteten af computerressourcer. Samtidig var mange af funktionerne i vores applikation afhængige af monterede NFS-partitioner, hvilket bremsede overgangen fra virtuelle maskiner.
Fremstødet mod cloud-native og Kubernetes gjorde det muligt for vores ingeniører at planlægge en gradvis overgang, hvor vi opgav nogle af applikationens afhængighed af netværkslagring, mens vi fortsatte med at udvikle nye funktioner. Siden vi begyndte at planlægge migreringen i sommeren 2019, er mange af disse begrænsninger blevet løst, og processen med at migrere GitLab.com til Kubernetes er nu godt i gang!
Funktioner af GitLab.com i Kubernetes
Til GitLab.com bruger vi en enkelt regional GKE-klynge, der håndterer al applikationstrafik. For at minimere kompleksiteten af den (allerede vanskelige) migrering fokuserer vi på tjenester, der ikke er afhængige af lokal lagring eller NFS. GitLab.com bruger en overvejende monolitisk Rails-kodebase, og vi dirigerer trafik baseret på arbejdsbelastningskarakteristika til forskellige endepunkter, der er isoleret i deres egne nodepuljer.
I tilfælde af frontend er disse typer opdelt i anmodninger til web, API, Git SSH/HTTPS og Registry. I tilfælde af backend opdeler vi jobs i køen efter forskellige karakteristika afhængig af , som giver os mulighed for at indstille Service-Level Objectives (SLO'er) for forskellige arbejdsbelastninger.
Alle disse GitLab.com-tjenester er konfigureret ved hjælp af et umodificeret GitLab Helm-diagram. Konfiguration udføres i underdiagrammer, som selektivt kan aktiveres, efterhånden som vi gradvist migrerer tjenester til klyngen. Selvom vi besluttede ikke at inkludere nogle af vores stateful tjenester i migreringen, såsom Redis, Postgres, GitLab Pages og Gitaly, giver brugen af Kubernetes os mulighed for radikalt at reducere antallet af VM'er, som Chef administrerer i øjeblikket.
Kubernetes-konfigurationssynlighed og -styring
Alle indstillinger administreres af GitLab selv. Til dette bruges tre konfigurationsprojekter baseret på Terraform og Helm. Vi forsøger at bruge selve GitLab når det er muligt til at køre GitLab, men til driftsopgaver har vi en separat GitLab installation. Dette er nødvendigt for at sikre, at du ikke er afhængig af tilgængeligheden af GitLab.com, når du udfører GitLab.com-implementeringer og opdateringer.
Selvom vores pipelines til Kubernetes-klyngen kører på en separat GitLab-installation, er der spejle af kodelagrene, som er offentligt tilgængelige på følgende adresser:
- — GitLab.com konfigurationsramme for GitLab Helm-diagrammet;
- - Indeholder konfigurationer til tjenester, der ikke er direkte forbundet med GitLab-applikationen. Disse omfatter konfigurationer til logning og klyngeovervågning, samt integrerede værktøjer som PlantUML;
- — Terraform-konfiguration til Kubernetes og ældre VM-infrastruktur. Her konfigurerer du alle de nødvendige ressourcer til at køre klyngen, inklusive selve klyngen, nodepuljer, servicekonti og IP-adressereservationer.
Offentlig visning vises, når der foretages ændringer. med et link til den detaljerede diff, som SRE analyserer, inden der foretages ændringer i klyngen.
For SRE fører linket til en detaljeret diff i GitLab-installationen, som bruges til produktion og adgang til hvilken er begrænset. Dette gør det muligt for medarbejdere og samfundet, uden adgang til det operationelle projekt (som kun er åbent for SRE'er), at se foreslåede konfigurationsændringer. Ved at kombinere en offentlig GitLab-instans til kode med en privat instans til CI-pipelines, opretholder vi en enkelt arbejdsgang, samtidig med at vi sikrer uafhængighed fra GitLab.com til konfigurationsopdateringer.
Hvad vi fandt ud af under migrationen
Under flytningen blev der opnået erfaringer med, at vi anvender til nye migreringer og udrulninger i Kubernetes.
1. Øgede omkostninger på grund af trafik mellem tilgængelighedszoner
Daglig egress-statistik (bytes pr. dag) for Git-lagerflåden på GitLab.com
Google opdeler sit netværk i regioner. Disse er til gengæld opdelt i tilgængelighedszoner (AZ). Git-hosting er forbundet med store mængder data, så det er vigtigt for os at kontrollere netværkets udgang. For intern trafik er udgang kun gratis, hvis den forbliver inden for den samme tilgængelighedszone. Når dette skrives, serverer vi cirka 100 TB data på en typisk arbejdsdag (og det er kun for Git-lagre). Tjenester, der lå i de samme virtuelle maskiner i vores gamle VM-baserede topologi, kører nu i forskellige Kubernetes-pods. Dette betyder, at noget trafik, der tidligere var lokalt for VM'en, potentielt kan rejse uden for tilgængelighedszoner.
Regionale GKE-klynger giver dig mulighed for at spænde over flere tilgængelighedszoner for redundans. Vi overvejer muligheden for tjenester, der genererer store mængder trafik. Dette vil reducere egress-omkostninger og samtidig opretholde redundans på klyngeniveau.
2. Grænser, ressourceanmodninger og skalering
Antallet af replikaer, der behandler produktionstrafik på registry.gitlab.com. Trafikken topper ved ~15:00 UTC.
Vores migreringshistorie begyndte i august 2019, da vi migrerede vores første tjeneste, GitLab Container Registry, til Kubernetes. Denne missionskritiske tjeneste med høj trafik var et godt valg til den første migrering, fordi det er en statsløs applikation med få eksterne afhængigheder. Det første problem, vi stødte på, var et stort antal udsatte bælg på grund af manglende hukommelse på noderne. På grund af dette var vi nødt til at ændre anmodninger og grænser.
Det blev opdaget, at i tilfælde af en applikation, hvor hukommelsesforbruget stiger over tid, førte lave værdier for anmodninger (reservering af hukommelse for hver pod) kombineret med en "generøs" hård grænse for brug til mætning (mætning) noder og et højt niveau af fraflytninger. For at håndtere dette problem var det . Dette tog trykket af noderne og sikrede, at pods havde en livscyklus, der ikke lagde for meget pres på noden. Nu starter vi migreringer med generøse (og næsten identiske) anmodninger og grænseværdier, og justerer dem efter behov.
3. Metrikker og logfiler
Infrastrukturdivisionen fokuserer på latency, fejlrater og saturation med installeret (SLO) knyttet til .
I løbet af det seneste år har en af de vigtigste begivenheder i infrastrukturdivisionen været forbedringer af overvågning og arbejde med SLO'er. SLO'er gjorde det muligt for os at sætte mål for individuelle tjenester, som vi nøje overvågede under migreringen. Men selv med denne forbedrede observerbarhed er det ikke altid muligt med det samme at se problemer ved at bruge metrikker og advarsler. For eksempel, ved at fokusere på latenstid og fejlfrekvenser, dækker vi ikke fuldt ud alle use cases for en tjeneste, der er under migrering.
Dette problem blev opdaget næsten umiddelbart efter migrering af nogle arbejdsbelastninger til klyngen. Det blev især akut, da vi skulle tjekke funktioner, hvor antallet af anmodninger var lille, men som havde meget specifikke konfigurationsafhængigheder. En af de vigtigste erfaringer fra migreringen var behovet for ikke kun at tage højde for målinger ved overvågning, men også logfiler og den "lange hale" (det handler om på diagrammet - ca. oversættelse) fejl. For hver migrering inkluderer vi nu en detaljeret liste over logforespørgsler (logforespørgsler) og planlægge klare rollback-procedurer, der kan overføres fra et skift til det næste, hvis der opstår problemer.
At betjene de samme anmodninger parallelt på den gamle VM-infrastruktur og den nye Kubernetes-baserede infrastruktur var en unik udfordring. I modsætning til løft-og-skift migration (hurtig overførsel af applikationer "som de er" til en ny infrastruktur; flere detaljer kan læses f.eks. - ca. oversættelse), kræver parallelt arbejde på "gamle" VM'er og Kubernetes, at overvågningsværktøjer er kompatible med begge miljøer og er i stand til at kombinere metrikker i én visning. Det er vigtigt, at vi bruger de samme dashboards og logforespørgsler for at opnå ensartet observerbarhed i overgangsperioden.
4. Skift trafik til en ny klynge
For GitLab.com er en del af serverne dedikeret til . Canary Park betjener vores interne projekter og kan også . Men det er primært designet til at teste ændringer foretaget i infrastrukturen og applikationen. Den første migrerede tjeneste startede med at acceptere en begrænset mængde intern trafik, og vi fortsætter med at bruge denne metode for at sikre, at SLO'er overholdes, før vi sender al trafik til klyngen.
I tilfælde af migrering betyder det, at anmodninger til interne projekter sendes til Kubernetes først, og derefter skifter vi gradvist resten af trafikken til klyngen ved at ændre vægten for backend gennem HAProxy. Under migreringen fra VM til Kubernetes blev det klart, at det var meget fordelagtigt at have en nem måde at omdirigere trafikken mellem den gamle og den nye infrastruktur og dermed holde den gamle infrastruktur klar til tilbagerulning i de første par dage efter migreringen.
5. Reservekapacitet af bælg og deres anvendelse
Næsten øjeblikkeligt blev følgende problem identificeret: pods til Registry-tjenesten startede hurtigt, men lanceringen af pods til Sidekiq tog op til . Den lange opstartstid for Sidekiq-pods blev et problem, da vi begyndte at migrere arbejdsbelastninger til Kubernetes for medarbejdere, der skulle behandle job hurtigt og skalere hurtigt.
I dette tilfælde var lektionen, at mens Kubernetes' Horizontal Pod Autoscaler (HPA) håndterer trafikvækst godt, er det vigtigt at overveje egenskaberne ved arbejdsbelastningerne og allokere ledig kapacitet til pods (især når efterspørgslen er ujævnt fordelt). I vores tilfælde var der en pludselig stigning i job, hvilket førte til hurtig skalering, hvilket førte til mætning af CPU-ressourcer, før vi nåede at skalere nodepuljen.
Der er altid en fristelse til at presse så meget som muligt ud af en klynge, men efter først at have stødt på præstationsproblemer, starter vi nu med et generøst podbudget og reducerer det senere og holder nøje øje med SLO'er. Lanceringen af pods til Sidekiq-tjenesten er blevet markant fremskyndet og tager nu cirka 40 sekunder i gennemsnit. vandt både GitLab.com og vores brugere af selvadministrerede installationer, der arbejder med det officielle GitLab Helm-diagram.
Konklusion
Efter migreringen af hver tjeneste glædede vi os over fordelene ved at bruge Kubernetes i produktionen: hurtigere og sikrere applikationsimplementering, skalering og mere effektiv ressourceallokering. Desuden går fordelene ved migrering ud over GitLab.com-tjenesten. Enhver forbedring af det officielle Helm-diagram kommer brugerne til gode.
Jeg håber, du nød historien om vores Kubernetes-migreringseventyr. Vi fortsætter med at migrere alle nye tjenester til klyngen. Yderligere information kan findes i følgende publikationer:
- «";
- «";
- .
PS fra oversætteren
Læs også på vores blog:
- «";
- «";
- «";
- «'.
Kilde: www.habr.com