Opomba. prevod: Sprejetje Kubernetes v GitLabu velja za enega od dveh glavnih dejavnikov, ki prispevata k rasti podjetja. Vendar je bila infrastruktura spletne storitve GitLab.com do nedavnega zgrajena na virtualnih strojih, šele pred kakšnim letom pa se je začela njena migracija na K8s, ki pa še vedno ni zaključena. Z veseljem predstavljamo prevod nedavnega članka inženirja GitLab SRE o tem, kako se to zgodi in kakšne zaključke naredijo inženirji, ki sodelujejo pri projektu.
Naš oddelek za infrastrukturo že približno eno leto seli vse storitve, ki se izvajajo na GitLab.com, v Kubernetes. V tem času smo naleteli na izzive, povezane ne samo s selitvijo storitev v Kubernetes, ampak tudi z upravljanjem hibridne uvedbe med prehodom. V tem članku bomo obravnavali dragocene lekcije, ki smo se jih naučili.
Od samega začetka GitLab.com so njegovi strežniki delovali v oblaku na virtualnih strojih. Te virtualne stroje upravlja Chef in jih namesti z uporabo našega . v primeru, da je treba aplikacijo posodobiti, sestoji iz preprostega posodabljanja flote strežnikov na usklajen, zaporedni način z uporabo cevovoda CI. Ta metoda - čeprav počasi in malo - zagotavlja, da GitLab.com uporablja enake namestitvene in konfiguracijske prakse kot uporabniki brez povezave (samoupravljiv) Namestitve GitLab z uporabo naših paketov Linux za to.
To metodo uporabljamo, ker je izjemno pomembno izkusiti vse žalosti in radosti, ki jih doživljajo običajni člani skupnosti, ko nameščajo in konfigurirajo svoje kopije GitLaba. Ta pristop je nekaj časa dobro deloval, a ko je število projektov v GitLabu preseglo 10 milijonov, smo ugotovili, da ne izpolnjuje več naših potreb po skaliranju in uvajanju.
Prvi koraki do Kubernetesa in GitLaba, ki izvira iz oblaka
Projekt je nastal leta 2017 pripraviti GitLab za uvedbo v oblaku in omogočiti uporabnikom namestitev GitLaba v gruče Kubernetes. Takrat smo vedeli, da bi selitev GitLaba v Kubernetes povečala razširljivost platforme SaaS, poenostavila uvedbe in izboljšala učinkovitost računalniških virov. Hkrati je bilo veliko funkcij naše aplikacije odvisnih od nameščenih particij NFS, kar je upočasnilo prehod z virtualnih strojev.
Premik k izvornemu oblaku in Kubernetesu je našim inženirjem omogočil načrtovanje postopne tranzicije, med katero smo opustili nekatere odvisnosti aplikacije od omrežnega pomnilnika, hkrati pa nadaljevali z razvojem novih funkcij. Odkar smo poleti 2019 začeli načrtovati selitev, je bilo veliko teh omejitev odpravljenih in postopek selitve GitLab.com na Kubernetes že dobro poteka!
Funkcije GitLab.com v Kubernetesu
Za GitLab.com uporabljamo eno regionalno gručo GKE, ki obravnava ves promet aplikacij. Da bi zmanjšali zapletenost (že tako zapletene) migracije, se osredotočamo na storitve, ki se ne zanašajo na lokalno shranjevanje ali NFS. GitLab.com uporablja pretežno monolitno kodno bazo Rails, promet pa usmerjamo na podlagi značilnosti delovne obremenitve do različnih končnih točk, ki so izolirane v lastna področja vozlišč.
V primeru sprednjega dela so te vrste razdeljene na zahteve za splet, API, Git SSH/HTTPS in register. V primeru zaledja razdelimo opravila v čakalni vrsti glede na različne značilnosti, odvisno od , ki nam omogočajo nastavitev ciljev ravni storitev (SLO) za različne delovne obremenitve.
Vse te storitve GitLab.com so konfigurirane z uporabo nespremenjene karte GitLab Helm. Konfiguracija poteka v podgrafih, ki jih lahko selektivno omogočimo, ko postopoma selimo storitve v gručo. Čeprav smo se odločili, da v selitev ne bomo vključili nekaterih naših storitev za spremljanje stanja, kot so Redis, Postgres, GitLab Pages in Gitaly, nam uporaba Kubernetesa omogoča korenito zmanjšanje števila navideznih strojev, ki jih trenutno upravlja Chef.
Vidnost in upravljanje konfiguracije Kubernetes
Vse nastavitve upravlja GitLab sam. Za to se uporabljajo trije konfiguracijski projekti, ki temeljijo na Terraform in Helm. Za zagon GitLaba poskušamo uporabiti sam GitLab, kadar koli je to mogoče, vendar imamo za operativne naloge ločeno namestitev GitLab. To je potrebno za zagotovitev, da niste odvisni od razpoložljivosti GitLab.com pri izvajanju uvajanj in posodobitev GitLab.com.
Čeprav naši cevovodi za gručo Kubernetes tečejo v ločeni namestitvi GitLab, obstajajo zrcala repozitorije kode, ki so javno dostopna na naslednjih naslovih:
- — konfiguracijski okvir GitLab.com za grafikon GitLab Helm;
- - Vsebuje konfiguracije za storitve, ki niso neposredno povezane z aplikacijo GitLab. Ti vključujejo konfiguracije za beleženje in spremljanje gruče ter integrirana orodja, kot je PlantUML;
- — Konfiguracija Terraform za Kubernetes in podedovano infrastrukturo VM. Tukaj konfigurirate vse vire, potrebne za zagon gruče, vključno s samo gručo, nabori vozlišč, storitvenimi računi in rezervacijami naslovov IP.
Javni pogled se prikaže, ko se izvedejo spremembe. s povezavo do podrobne razlike, ki jo SRE analizira, preden spremeni gručo.
Za SRE povezava vodi do podrobne razlike v namestitvi GitLab, ki se uporablja za proizvodnjo in je dostop do nje omejen. To zaposlenim in skupnosti omogoča ogled predlaganih sprememb konfiguracije brez dostopa do operativnega projekta (ki je odprt samo za SRE). S kombiniranjem javne instance GitLab za kodo z zasebno instanco za cevovode CI vzdržujemo en potek dela, hkrati pa zagotavljamo neodvisnost od GitLab.com za posodobitve konfiguracije.
Kaj smo ugotovili med selitvijo
Med selitvijo so bile pridobljene izkušnje, ki jih uporabljamo pri novih migracijah in uvajanjih v Kubernetesu.
1. Povečani stroški zaradi prometa med območji razpoložljivosti
Dnevni izhodni statistični podatki (bajti na dan) za floto repozitorija Git na GitLab.com
Google svoje omrežje deli na regije. Ti pa so razdeljeni na območja dostopnosti (AZ). Git gostovanje je povezano z velikimi količinami podatkov, zato je za nas pomemben nadzor nad izhodom iz omrežja. Za notranji promet je izstop brezplačen le, če ostane znotraj istega območja razpoložljivosti. Od tega pisanja strežemo približno 100 TB podatkov v tipičnem delovnem dnevu (in to samo za repozitorije Git). Storitve, ki so bile v istih virtualnih strojih v naši stari topologiji, ki temelji na VM, se zdaj izvajajo v različnih podih Kubernetes. To pomeni, da bi lahko del prometa, ki je bil prej lokalni za VM, potoval izven območij razpoložljivosti.
Regionalne gruče GKE vam omogočajo, da za redundanco razširite več območij razpoložljivosti. Razmišljamo o možnosti za storitve, ki ustvarjajo velike količine prometa. To bo zmanjšalo izstopne stroške in hkrati ohranilo redundanco na ravni gruče.
2. Omejitve, zahteve po virih in skaliranje
Število replik, ki obdelujejo produkcijski promet na registry.gitlab.com. Največji promet je ob ~15:00 UTC.
Naša zgodba o selitvi se je začela avgusta 2019, ko smo svojo prvo storitev, GitLab Container Registry, preselili v Kubernetes. Ta kritična storitev z velikim prometom je bila dobra izbira za prvo selitev, ker je aplikacija brez stanja in malo zunanjih odvisnosti. Prva težava, na katero smo naleteli, je bilo veliko število izločenih podov zaradi pomanjkanja pomnilnika na vozliščih. Zaradi tega smo morali spremeniti zahteve in limite.
Ugotovljeno je bilo, da so v primeru aplikacije, kjer se poraba pomnilnika sčasoma poveča, nizke vrednosti za zahteve (rezervacija pomnilnika za vsak sklop) skupaj z "velikodušno" trdo omejitvijo porabe povzročile nasičenost (nasičenost) vozlišč in visoko stopnjo izselitev. Za spopadanje s to težavo je bilo . To je razbremenilo vozlišča in zagotovilo, da imajo podi življenjski cikel, ki na vozlišče ne povzroča prevelikega pritiska. Zdaj začnemo selitve z velikodušnimi (in skoraj enakimi) zahtevami in mejnimi vrednostmi ter jih po potrebi prilagodimo.
3. Metrike in dnevniki
Oddelek za infrastrukturo se osredotoča na zakasnitev, stopnje napak in nasičenost z nameščenimi (SLO) povezan z .
V preteklem letu je bil eden ključnih dogodkov v infrastrukturni diviziji izboljšanje spremljanja in dela s ČVN. SLO so nam omogočili določitev ciljev za posamezne storitve, ki smo jih pozorno spremljali med migracijo. Toda tudi s to izboljšano opazljivostjo ni vedno mogoče takoj opaziti težav z uporabo meritev in opozoril. Če se na primer osredotočamo na zakasnitev in stopnje napak, ne pokrivamo v celoti vseh primerov uporabe za storitev, ki je v postopku selitve.
Ta težava je bila odkrita skoraj takoj po selitvi nekaterih delovnih obremenitev v gručo. Posebej pereče je postalo, ko smo morali preverjati funkcije, za katere je bilo malo zahtev, a so imele zelo specifične konfiguracijske odvisnosti. Ena od ključnih lekcij iz selitve je bila potreba po upoštevanju ne le meritev pri spremljanju, temveč tudi dnevnike in "dolgi rep" (gre za na karti - pribl. prev.) napake. Zdaj za vsako selitev vključujemo podroben seznam poizvedb dnevnika (dnevniške poizvedbe) in načrtujte jasne postopke vračanja, ki jih je mogoče prenesti iz ene izmene v drugo, če se pojavijo težave.
Vzporedno streženje istih zahtev na stari infrastrukturi VM in novi infrastrukturi, ki temelji na Kubernetesu, je predstavljalo edinstven izziv. Za razliko od dvižne in prestavne migracije (hiter prenos aplikacij »kot so« na novo infrastrukturo; več podrobnosti si lahko preberete npr. — pribl. prev.), vzporedno delo na "starih" VM in Kubernetes zahteva, da so orodja za spremljanje združljiva z obema okoljema in da lahko združijo meritve v en pogled. Pomembno je, da uporabljamo iste nadzorne plošče in poizvedbe v dnevniku, da dosežemo dosledno opazovanje v prehodnem obdobju.
4. Preklop prometa na novo gručo
Za GitLab.com je del strežnikov namenjen . Canary Park služi našim internim projektom in lahko tudi . Vendar je zasnovan predvsem za preizkušanje sprememb v infrastrukturi in aplikaciji. Prva preseljena storitev se je začela s sprejemanjem omejene količine notranjega prometa in še naprej uporabljamo to metodo, da zagotovimo, da so SLO izpolnjeni, preden pošljemo ves promet v gručo.
V primeru migracije to pomeni, da se zahteve za interne projekte najprej pošljejo v Kubernetes, nato pa postopoma preklopimo preostali promet v gručo s spreminjanjem teže za zaledje prek HAProxy. Med selitvijo iz VM v Kubernetes je postalo jasno, da je zelo koristno imeti enostaven način za preusmerjanje prometa med staro in novo infrastrukturo in v skladu s tem ohraniti staro infrastrukturo pripravljeno za povrnitev v prvih nekaj dneh po selitvi.
5. Rezervne kapacitete podov in njihova uporaba
Skoraj takoj je bila ugotovljena naslednja težava: podi za storitev Registry so se začeli hitro, vendar je zagon podov za Sidekiq trajal do . Dolg zagonski čas za Sidekiq pods je postal težava, ko smo začeli seliti delovne obremenitve v Kubernetes za delavce, ki so morali hitro obdelati opravila in se hitro prilagajati.
V tem primeru je bila lekcija ta, da čeprav Kubernetesov Horizontal Pod Autoscaler (HPA) dobro obvladuje rast prometa, je pomembno upoštevati značilnosti delovnih obremenitev in dodeliti proste zmogljivosti podom (zlasti kadar je povpraševanje neenakomerno porazdeljeno). V našem primeru je prišlo do nenadnega porasta delovnih mest, kar je vodilo do hitrega skaliranja, kar je vodilo do nasičenosti virov CPU, preden smo imeli čas za skaliranje področja vozlišč.
Vedno obstaja skušnjava, da bi iz gruče iztisnili čim več, vendar pa, ko smo na začetku naleteli na težave z zmogljivostjo, zdaj začenjamo z velikodušnim proračunom sklopa in ga kasneje zmanjšujemo, pri čemer pozorno spremljamo SLO. Zagon enot za storitev Sidekiq se je znatno pospešil in zdaj v povprečju traja približno 40 sekund. osvojil tako GitLab.com kot naše uporabnike samoupravljanih namestitev, ki delajo z uradno lestvico GitLab Helm.
Zaključek
Po selitvi vsake storitve smo se veselili prednosti uporabe Kubernetes v proizvodnji: hitrejše in varnejše uvajanje aplikacij, skaliranje in učinkovitejše dodeljevanje virov. Poleg tega prednosti migracije presegajo storitev GitLab.com. Vsaka izboljšava uradne karte Helm koristi njenim uporabnikom.
Upam, da ste uživali v zgodbi o naših migracijskih dogodivščinah Kubernetes. Nadaljujemo s selitvijo vseh novih storitev v gručo. Dodatne informacije najdete v naslednjih publikacijah:
- «»;
- «»;
- .
PS od prevajalca
Preberite tudi na našem blogu:
- «»;
- «»;
- «»;
- «".
Vir: www.habr.com