Merk. overs.: Adopsjon av Kubernetes hos GitLab regnes som en av de to hovedfaktorene som bidrar til selskapets vekst. Inntil nylig ble imidlertid infrastrukturen til GitLab.com-netttjenesten bygget på virtuelle maskiner, og for bare et år siden begynte migreringen til K8s, som fortsatt ikke er fullført. Vi er glade for å presentere en oversettelse av en nylig artikkel av en GitLab SRE-ingeniør om hvordan dette skjer og hvilke konklusjoner ingeniørene som deltar i prosjektet trekker.
I omtrent et år nå har infrastrukturavdelingen vår migrert alle tjenester som kjører på GitLab.com til Kubernetes. I løpet av denne tiden møtte vi utfordringer knyttet til ikke bare å flytte tjenester til Kubernetes, men også til å administrere hybrid-distribusjonen under overgangen. De verdifulle leksjonene vi har lært vil bli diskutert i denne artikkelen.
Helt fra begynnelsen av GitLab.com kjørte serverne i skyen på virtuelle maskiner. Disse virtuelle maskinene administreres av Chef og installeres ved hjelp av vår . i tilfelle applikasjonen må oppdateres, består det bare av å oppdatere serverflåten på en koordinert, sekvensiell måte ved hjelp av en CI-pipeline. Denne metoden - om enn treg og litt - sikrer at GitLab.com bruker samme installasjons- og konfigurasjonspraksis som offline-brukere (selvstyrt) GitLab-installasjoner ved å bruke våre Linux-pakker for dette.
Vi bruker denne metoden fordi det er ekstremt viktig å oppleve alle sorgene og gledene som vanlige medlemmer av fellesskapet opplever når de installerer og konfigurerer sine kopier av GitLab. Denne tilnærmingen fungerte bra en stund, men da antallet prosjekter på GitLab oversteg 10 millioner, innså vi at den ikke lenger møtte våre behov for skalering og distribusjon.
De første trinnene til Kubernetes og sky-native GitLab
Prosjektet ble opprettet i 2017 for å forberede GitLab for skydistribusjon, og for å gjøre det mulig for brukere å installere GitLab på Kubernetes-klynger. Vi visste da at å flytte GitLab til Kubernetes ville øke skalerbarheten til SaaS-plattformen, forenkle distribusjoner og forbedre effektiviteten til dataressurser. Samtidig var mange av funksjonene til applikasjonen vår avhengig av monterte NFS-partisjoner, noe som bremset overgangen fra virtuelle maskiner.
Presset mot skybasert og Kubernetes tillot ingeniørene våre å planlegge en gradvis overgang, der vi forlot noen av applikasjonens avhengigheter av nettverkslagring mens vi fortsatte å utvikle nye funksjoner. Siden vi begynte å planlegge migreringen sommeren 2019, har mange av disse begrensningene blitt løst, og prosessen med å migrere GitLab.com til Kubernetes er nå godt i gang!
Funksjoner av GitLab.com i Kubernetes
For GitLab.com bruker vi en enkelt regional GKE-klynge som håndterer all applikasjonstrafikk. For å minimere kompleksiteten til den (allerede vanskelige) migreringen, fokuserer vi på tjenester som ikke er avhengige av lokal lagring eller NFS. GitLab.com bruker en overveiende monolittisk Rails-kodebase, og vi ruter trafikk basert på arbeidsbelastningskarakteristikker til forskjellige endepunkter som er isolert i deres egne nodepooler.
Når det gjelder frontend, er disse typene delt inn i forespørsler til web, API, Git SSH/HTTPS og Registry. Når det gjelder backend deler vi jobbene i køen etter ulike egenskaper avhengig av , som lar oss sette servicenivåmål (SLOer) for ulike arbeidsbelastninger.
Alle disse GitLab.com-tjenestene er konfigurert ved hjelp av et umodifisert GitLab Helm-diagram. Konfigurasjonen utføres i underdiagrammer, som kan aktiveres selektivt etter hvert som vi gradvis migrerer tjenester til klyngen. Selv om vi bestemte oss for å ikke inkludere noen av våre statlige tjenester i migreringen, som Redis, Postgres, GitLab Pages og Gitaly, lar bruk av Kubernetes oss radikalt redusere antallet VM-er som Chef for øyeblikket administrerer.
Kubernetes-konfigurasjonssynlighet og -administrasjon
Alle innstillinger administreres av GitLab selv. Til dette brukes tre konfigurasjonsprosjekter basert på Terraform og Helm. Vi prøver å bruke selve GitLab når det er mulig for å kjøre GitLab, men for driftsoppgaver har vi en egen GitLab-installasjon. Dette er nødvendig for å sikre at du ikke er avhengig av tilgjengeligheten til GitLab.com når du utfører GitLab.com-distribusjoner og oppdateringer.
Selv om rørledningene våre for Kubernetes-klyngen kjører på en separat GitLab-installasjon, er det speil av kodelagrene som er offentlig tilgjengelige på følgende adresser:
- — GitLab.com konfigurasjonsrammeverk for GitLab Helm-diagrammet;
- - Inneholder konfigurasjoner for tjenester som ikke er direkte assosiert med GitLab-applikasjonen. Disse inkluderer konfigurasjoner for logging og klyngeovervåking, samt integrerte verktøy som PlantUML;
- — Terraform-konfigurasjon for Kubernetes og eldre VM-infrastruktur. Her konfigurerer du alle ressursene som er nødvendige for å kjøre klyngen, inkludert selve klyngen, nodepooler, tjenestekontoer og IP-adressereservasjoner.
Offentlig visning vises når endringer gjøres. med en lenke til den detaljerte diff som SRE analyserer før endringer i klyngen.
For SRE fører lenken til en detaljert diff i GitLab-installasjonen, som brukes til produksjon og tilgang til som er begrenset. Dette lar ansatte og samfunnet, uten tilgang til det operative prosjektet (som kun er åpent for SRE), se foreslåtte konfigurasjonsendringer. Ved å kombinere en offentlig GitLab-forekomst for kode med en privat forekomst for CI-rørledninger, opprettholder vi en enkelt arbeidsflyt samtidig som vi sikrer uavhengighet fra GitLab.com for konfigurasjonsoppdateringer.
Hva vi fant ut under migrasjonen
Under flyttingen ble det høstet erfaringer med at vi søker på nye migreringer og utplasseringer i Kubernetes.
1. Økte kostnader på grunn av trafikk mellom tilgjengelighetssoner
Daglig utgangsstatistikk (byte per dag) for Git-lagerflåten på GitLab.com
Google deler nettverket inn i regioner. Disse er på sin side delt inn i tilgjengelighetssoner (AZ). Git-hosting er assosiert med store datamengder, så det er viktig for oss å kontrollere nettverksutgangen. For intern trafikk er utgang kun gratis hvis den holder seg innenfor samme tilgjengelighetssone. Når dette skrives, serverer vi omtrent 100 TB med data på en vanlig arbeidsdag (og det er bare for Git-lagre). Tjenester som lå i de samme virtuelle maskinene i vår gamle VM-baserte topologi, kjøres nå i forskjellige Kubernetes-poder. Dette betyr at noe trafikk som tidligere var lokal for VM-en, potensielt kan reise utenfor tilgjengelighetssoner.
Regionale GKE-klynger lar deg spenne over flere tilgjengelighetssoner for redundans. Vi vurderer muligheten for tjenester som genererer store mengder trafikk. Dette vil redusere utgangskostnader og samtidig opprettholde redundans på klyngenivå.
2. Grenser, ressursforespørsler og skalering
Antall replikaer som behandler produksjonstrafikk på registry.gitlab.com. Trafikken topper seg ved ~15:00 UTC.
Migrasjonshistorien vår begynte i august 2019, da vi migrerte vår første tjeneste, GitLab Container Registry, til Kubernetes. Denne virksomhetskritiske tjenesten med høy trafikk var et godt valg for den første migreringen fordi det er en statsløs applikasjon med få eksterne avhengigheter. Det første problemet vi møtte var et stort antall utkastede pods på grunn av mangel på hukommelse på nodene. På grunn av dette måtte vi endre forespørsler og grenser.
Det ble oppdaget at i tilfellet med en applikasjon der minneforbruket øker over tid, førte lave verdier for forespørsler (reservering av minne for hver pod) kombinert med en "generøs" hard grense for bruk til metning (metning) noder og et høyt nivå av utkastelser. For å håndtere dette problemet, var det . Dette tok trykket av nodene og sikret at podene hadde en livssyklus som ikke la for mye press på noden. Nå starter vi migreringer med sjenerøse (og nesten identiske) forespørsels- og grenseverdier, og justerer dem etter behov.
3. Beregninger og logger
Infrastrukturdivisjonen fokuserer på latens, feilrater og metning med installert (SLO) knyttet til .
I løpet av det siste året har en av de viktigste hendelsene i infrastrukturdivisjonen vært forbedringer i overvåking og arbeid med SLOer. SLOer tillot oss å sette mål for individuelle tjenester som vi overvåket nøye under migreringen. Men selv med denne forbedrede observerbarheten er det ikke alltid mulig å umiddelbart se problemer ved å bruke beregninger og varsler. For eksempel, ved å fokusere på ventetid og feilrater, dekker vi ikke fullt ut alle brukstilfeller for en tjeneste som er under migrering.
Dette problemet ble oppdaget nesten umiddelbart etter migrering av noen arbeidsbelastninger til klyngen. Spesielt akutt ble det da vi skulle sjekke funksjoner der antallet forespørsler var lite, men som hadde svært spesifikke konfigurasjonsavhengigheter. En av de viktigste lærdommene fra migreringen var behovet for å ta hensyn til ikke bare beregninger ved overvåking, men også logger og "long tail" (dette handler om på diagrammet - ca. oversett.) feil. For hver migrering inkluderer vi en detaljert liste over loggspørringer (loggforespørsler) og planlegge klare tilbakerullingsprosedyrer som kan overføres fra ett skift til det neste dersom det oppstår problemer.
Å betjene de samme forespørslene parallelt på den gamle VM-infrastrukturen og den nye Kubernetes-baserte infrastrukturen ga en unik utfordring. I motsetning til lift-and-shift-migrering (rask overføring av applikasjoner "som de er" til en ny infrastruktur; flere detaljer kan leses, f.eks. — ca. oversett.), krever parallelt arbeid med "gamle" VM-er og Kubernetes at overvåkingsverktøyene er kompatible med begge miljøene og kan kombinere beregninger i én visning. Det er viktig at vi bruker de samme dashboardene og loggspørringene for å oppnå konsistent observerbarhet i overgangsperioden.
4. Bytte trafikk til en ny klynge
For GitLab.com er en del av serverne dedikert til . Canary Park betjener våre interne prosjekter og kan også . Men det er først og fremst designet for å teste endringer som er gjort i infrastrukturen og applikasjonen. Den første migrerte tjenesten startet med å akseptere en begrenset mengde intern trafikk, og vi fortsetter å bruke denne metoden for å sikre at SLO-er oppfylles før all trafikk sendes til klyngen.
Ved migrering betyr dette at forespørsler til interne prosjekter sendes til Kubernetes først, og deretter bytter vi gradvis resten av trafikken til klyngen ved å endre vekten for backend gjennom HAProxy. Under migreringen fra VM til Kubernetes ble det klart at det var svært fordelaktig å ha en enkel måte å omdirigere trafikk mellom den gamle og den nye infrastrukturen og følgelig holde den gamle infrastrukturen klar for tilbakerulling de første dagene etter migreringen.
5. Reservekapasiteter til pods og deres bruk
Nesten umiddelbart ble følgende problem identifisert: pods for registertjenesten startet raskt, men lanseringen av pods for Sidekiq tok opp til . Den lange oppstartstiden for Sidekiq-pods ble et problem da vi begynte å migrere arbeidsmengder til Kubernetes for arbeidere som trengte å behandle jobber raskt og skalere raskt.
I dette tilfellet var lærdommen at mens Kubernetes' Horizontal Pod Autoscaler (HPA) håndterer trafikkvekst godt, er det viktig å vurdere egenskapene til arbeidsbelastningene og allokere ledig kapasitet til podene (spesielt når etterspørselen er ujevnt fordelt). I vårt tilfelle var det en plutselig økning i jobber, noe som førte til rask skalering, noe som førte til metning av CPU-ressurser før vi rakk å skalere nodepoolen.
Det er alltid en fristelse til å presse så mye som mulig ut av en klynge, men etter å ha støtt på ytelsesproblemer i utgangspunktet, starter vi nå med et sjenerøst podbudsjett og reduserer det senere, og holder nøye øye med SLOer. Lansering av pods for Sidekiq-tjenesten har akselerert betydelig og tar nå omtrent 40 sekunder i gjennomsnitt. vant både GitLab.com og våre brukere av selvstyrte installasjoner som arbeider med det offisielle GitLab Helm-diagrammet.
Konklusjon
Etter å ha migrert hver tjeneste, gledet vi oss over fordelene ved å bruke Kubernetes i produksjon: raskere og sikrere applikasjonsdistribusjon, skalering og mer effektiv ressursallokering. Dessuten går fordelene med migrering utover GitLab.com-tjenesten. Hver forbedring av det offisielle Helm-diagrammet kommer brukerne til gode.
Jeg håper du likte historien om Kubernetes-migrasjonseventyrene våre. Vi fortsetter å migrere alle nye tjenester til klyngen. Ytterligere informasjon finnes i følgende publikasjoner:
- «";
- «";
- .
PS fra oversetter
Les også på bloggen vår:
- «";
- «";
- «";
- «'.
Kilde: www.habr.com