Shënim. përkth.: Miratimi i Kubernetes në GitLab konsiderohet si një nga dy faktorët kryesorë që kontribuojnë në rritjen e kompanisë. Megjithatë, deri vonë, infrastruktura e shërbimit online GitLab.com ishte ndërtuar në makina virtuale dhe vetëm rreth një vit më parë filloi migrimi i saj në K8, i cili ende nuk është përfunduar. Kemi kënaqësinë të paraqesim një përkthim të një artikulli të fundit nga një inxhinier i GitLab SRE për mënyrën se si ndodh kjo dhe çfarë përfundimesh bëjnë inxhinierët pjesëmarrës në projekt.
Prej rreth një viti, divizioni ynë i infrastrukturës ka migruar të gjitha shërbimet që funksionojnë në GitLab.com në Kubernetes. Gjatë kësaj kohe, ne hasëm sfida që lidhen jo vetëm me lëvizjen e shërbimeve në Kubernetes, por edhe me menaxhimin e vendosjes hibride gjatë tranzicionit. Mësimet e vlefshme që mësuam do të diskutohen në këtë artikull.
Që nga fillimi i GitLab.com, serverët e tij funksionuan në cloud në makinat virtuale. Këto makina virtuale menaxhohen nga Chef dhe instalohen duke përdorur tonën . në rast se aplikacioni duhet të përditësohet, konsiston thjesht në përditësimin e flotës së serverëve në një mënyrë të koordinuar dhe sekuenciale duke përdorur një tubacion CI. Kjo metodë - megjithëse e ngadaltë dhe pak - siguron që GitLab.com përdor të njëjtat praktika instalimi dhe konfigurimi si përdoruesit jashtë linje (vetë-menaxhuar) Instalimet e GitLab duke përdorur paketat tona Linux për këtë.
Ne e përdorim këtë metodë sepse është jashtëzakonisht e rëndësishme të përjetojmë të gjitha dhimbjet dhe gëzimet që përjetojnë anëtarët e zakonshëm të komunitetit kur instalojnë dhe konfigurojnë kopjet e tyre të GitLab. Kjo qasje funksionoi mirë për ca kohë, por kur numri i projekteve në GitLab kaloi 10 milionë, ne kuptuam se nuk i plotësonte më nevojat tona për shkallëzim dhe vendosje.
Hapat e parë drejt Kubernetes dhe GitLab vendas në cloud
Projekti është krijuar në vitin 2017 për të përgatitur GitLab për vendosjen e cloud dhe për t'u mundësuar përdoruesve të instalojnë GitLab në grupimet Kubernetes. Ne e dinim atëherë se zhvendosja e GitLab në Kubernetes do të rriste shkallëzueshmërinë e platformës SaaS, do të thjeshtonte vendosjen dhe do të përmirësonte efikasitetin e burimeve kompjuterike. Në të njëjtën kohë, shumë nga funksionet e aplikacionit tonë vareshin nga ndarjet e montuara NFS, të cilat ngadalësuan kalimin nga makinat virtuale.
Shtytja drejt cloud vendas dhe Kubernetes i lejoi inxhinierët tanë të planifikonin një tranzicion gradual, gjatë të cilit ne braktisëm disa nga varësitë e aplikacionit nga ruajtja e rrjetit duke vazhduar të zhvillonim veçori të reja. Që kur filluam planifikimin e migrimit në verën e vitit 2019, shumë nga këto kufizime janë zgjidhur dhe procesi i migrimit të GitLab.com në Kubernetes tani është duke u zhvilluar mirë!
Karakteristikat e GitLab.com në Kubernetes
Për GitLab.com, ne përdorim një grup të vetëm rajonal GKE që trajton të gjithë trafikun e aplikacioneve. Për të minimizuar kompleksitetin e migrimit (tashmë të ndërlikuar), ne fokusohemi në shërbimet që nuk mbështeten në ruajtjen lokale ose NFS. GitLab.com përdor një bazë kodi kryesisht monolit Rails dhe ne e drejtojmë trafikun bazuar në karakteristikat e ngarkesës së punës në pika të ndryshme fundore që janë të izoluara në grupet e tyre të nyjeve.
Në rastin e frontendit, këto lloje ndahen në kërkesa për ueb, API, Git SSH/HTTPS dhe Regjistr. Në rastin e backend-it, ne i ndajmë punët në radhë sipas karakteristikave të ndryshme në varësi të , të cilat na lejojnë të vendosim Objektiva të Nivelit të Shërbimit (SLO) për ngarkesa të ndryshme pune.
Të gjitha këto shërbime GitLab.com janë konfiguruar duke përdorur një grafik GitLab Helm të pandryshuar. Konfigurimi kryhet në nëngrafikë, të cilat mund të aktivizohen në mënyrë selektive ndërsa ne gradualisht migrojmë shërbimet në grup. Edhe pse vendosëm të mos përfshijmë disa nga shërbimet tona shtetërore në migrim, si Redis, Postgres, GitLab Pages dhe Gitaly, përdorimi i Kubernetes na lejon të reduktojmë rrënjësisht numrin e VM-ve që Chef menaxhon aktualisht.
Dukshmëria dhe menaxhimi i konfigurimit të Kubernetes
Të gjitha cilësimet menaxhohen nga vetë GitLab. Për këtë, përdoren tre projekte konfigurimi të bazuara në Terraform dhe Helm. Ne përpiqemi të përdorim vetë GitLab sa herë që është e mundur për të ekzekutuar GitLab, por për detyrat operative kemi një instalim të veçantë GitLab. Kjo është e nevojshme për t'u siguruar që nuk jeni të varur nga disponueshmëria e GitLab.com kur kryeni vendosjet dhe përditësimet e GitLab.com.
Megjithëse tubacionet tona për grupin Kubernetes funksionojnë në një instalim të veçantë GitLab, ka pasqyra të depove të kodit që janë të disponueshme publikisht në adresat e mëposhtme:
- — Korniza e konfigurimit të GitLab.com për grafikun GitLab Helm;
- - Përmban konfigurime për shërbime që nuk lidhen drejtpërdrejt me aplikacionin GitLab. Këto përfshijnë konfigurime për regjistrimin dhe monitorimin e grupimeve, si dhe mjete të integruara si PlantUML;
- — Konfigurimi Terraform për Kubernetes dhe infrastrukturën e vjetër të VM. Këtu ju konfiguroni të gjitha burimet e nevojshme për të ekzekutuar grupin, duke përfshirë vetë grupimin, grupet e nyjeve, llogaritë e shërbimit dhe rezervimet e adresave IP.
Pamja publike shfaqet kur bëhen ndryshime. me një lidhje me ndryshimin e detajuar që analizon SRE përpara se të bëjë ndryshime në grup.
Për SRE, lidhja çon në një ndryshim të detajuar në instalimin GitLab, i cili përdoret për prodhim dhe aksesi në të cilin është i kufizuar. Kjo i lejon punonjësit dhe komunitetin, pa akses në projektin operacional (i cili është i hapur vetëm për SRE-të), të shikojnë ndryshimet e propozuara të konfigurimit. Duke kombinuar një shembull publik GitLab për kodin me një shembull privat për tubacionet CI, ne mbajmë një rrjedhë të vetme pune duke siguruar pavarësinë nga GitLab.com për përditësimet e konfigurimit.
Çfarë zbuluam gjatë migrimit
Gjatë lëvizjes, u fitua përvoja që ne e aplikojmë për migrimet dhe vendosjet e reja në Kubernetes.
1. Rritja e kostove për shkak të trafikut ndërmjet zonave të disponueshmërisë
Statistikat e daljes ditore (bajt në ditë) për flotën e depove Git në GitLab.com
Google e ndan rrjetin e saj në rajone. Ato, nga ana tjetër, ndahen në zona të aksesueshmërisë (Z). Pritja e Git është e lidhur me sasi të mëdha të dhënash, kështu që është e rëndësishme për ne të kontrollojmë daljen e rrjetit. Për trafikun e brendshëm, dalja është falas vetëm nëse qëndron brenda së njëjtës zonë disponueshmërie. Deri në momentin e shkrimit, ne po shërbejmë afërsisht 100 TB të dhëna në një ditë të zakonshme pune (dhe kjo është vetëm për depot e Git). Shërbimet që banonin në të njëjtat makina virtuale në topologjinë tonë të vjetër të bazuar në VM tani funksionojnë në pods të ndryshëm Kubernetes. Kjo do të thotë që një pjesë e trafikut që më parë ishte lokal në VM mund të udhëtonte jashtë zonave të disponueshmërisë.
Grupet rajonale GKE ju lejojnë të përfshini zona të shumta të disponueshmërisë për tepricë. Ne jemi duke shqyrtuar mundësinë për shërbimet që gjenerojnë vëllime të mëdha trafiku. Kjo do të reduktojë kostot e daljes duke ruajtur tepricën në nivel grupi.
2. Limitet, kërkesat për burime dhe shkallëzimi
Numri i trafikut të prodhimit të përpunimit të kopjeve në registry.gitlab.com. Piku i trafikut në orën ~15:00 UTC.
Historia jonë e migrimit filloi në gusht 2019, kur migruam shërbimin tonë të parë, Regjistrin e kontejnerëve GitLab, në Kubernetes. Ky shërbim kritik për misionin, me trafik të lartë ishte një zgjedhje e mirë për migrimin e parë, sepse është një aplikacion pa shtetësi me pak varësi nga jashtë. Problemi i parë që hasëm ishte një numër i madh pods të dëbuar për shkak të mungesës së memories në nyje. Për shkak të kësaj, na u desh të ndryshonim kërkesat dhe kufijtë.
U zbulua se në rastin e një aplikacioni ku konsumi i kujtesës rritet me kalimin e kohës, vlerat e ulëta për kërkesat (rezervimi i memories për çdo pod) të shoqëruara me një kufi të fortë "bujar" në përdorim çuan në ngopje. (ngopje) nyjet dhe niveli i lartë i dëbimeve. Për t'u marrë me këtë problem, ishte . Kjo e largoi presionin nga nyjet dhe siguroi që podat të kishin një cikël jete që nuk ushtronte shumë presion mbi nyjen. Tani fillojmë migrimet me kërkesa bujare (dhe pothuajse identike) me vlera kufitare, duke i rregulluar ato sipas nevojës.
3. Metrikat dhe regjistrat
Divizioni i infrastrukturës fokusohet në vonesën, shkallën e gabimit dhe ngopjen me të instaluar (SLO) i lidhur me .
Gjatë vitit të kaluar, një nga ngjarjet kryesore në sektorin e infrastrukturës ka qenë përmirësimet në monitorimin dhe punën me SLO. SLO-të na lejuan të vendosnim synime për shërbime individuale që i monitoruam nga afër gjatë migrimit. Por edhe me këtë vëzhgim të përmirësuar, nuk është gjithmonë e mundur që të shihen menjëherë problemet duke përdorur metrikat dhe sinjalizimet. Për shembull, duke u fokusuar në vonesat dhe normat e gabimit, ne nuk i mbulojmë plotësisht të gjitha rastet e përdorimit për një shërbim që i nënshtrohet migrimit.
Ky problem u zbulua pothuajse menjëherë pas migrimit të disa ngarkesave të punës në grup. Ajo u bë veçanërisht e mprehtë kur na u desh të kontrollonim funksionet për të cilat numri i kërkesave ishte i vogël, por që kishin varësi konfigurimi shumë specifike. Një nga mësimet kryesore nga migrimi ishte nevoja për të marrë parasysh jo vetëm metrikat gjatë monitorimit, por edhe shkrimet dhe "bishtin e gjatë". (Bëhet fjalë për në grafik - përafërsisht. përkth.) gabimet. Tani për çdo migrim ne përfshijmë një listë të detajuar të pyetjeve të regjistrit (pyetjet e regjistrit) dhe planifikoni procedura të qarta rikthimi që mund të transferohen nga një ndërrim në tjetrin nëse shfaqen probleme.
Shërbimi i të njëjtave kërkesa paralelisht në infrastrukturën e vjetër VM dhe infrastrukturën e re të bazuar në Kubernetes paraqiti një sfidë unike. Ndryshe nga migrimi me ngritje dhe zhvendosje (transferimi i shpejtë i aplikacioneve "siç është" në një infrastrukturë të re; më shumë detaje mund të lexohen, për shembull, - përafërsisht. përkth.), puna paralele në VM "të vjetra" dhe Kubernetes kërkon që mjetet e monitorimit të jenë të pajtueshme me të dy mjediset dhe të jenë në gjendje të kombinojnë metrikat në një pamje. Është e rëndësishme që ne të përdorim të njëjtat panele kontrolli dhe pyetje të regjistrave për të arritur vëzhgueshmëri të qëndrueshme gjatë periudhës së tranzicionit.
4. Kalimi i trafikut në një grup të ri
Për GitLab.com, një pjesë e serverëve i dedikohet . Canary Park shërben për projektet tona të brendshme dhe gjithashtu mund . Por është krijuar kryesisht për të testuar ndryshimet e bëra në infrastrukturë dhe aplikacion. Shërbimi i parë i migruar filloi duke pranuar një sasi të kufizuar trafiku të brendshëm dhe ne vazhdojmë ta përdorim këtë metodë për të siguruar përmbushjen e SLO-ve përpara se të dërgojmë të gjithë trafikun në grup.
Në rastin e migrimit, kjo do të thotë që kërkesat për projektet e brendshme dërgohen fillimisht në Kubernetes dhe më pas kalojmë gradualisht pjesën tjetër të trafikut në grup duke ndryshuar peshën për backend-in përmes HAProxy. Gjatë migrimit nga VM në Kubernetes, u bë e qartë se ishte shumë e dobishme të kishim një mënyrë të lehtë për të ridrejtuar trafikun midis infrastrukturës së vjetër dhe asaj të re dhe, në përputhje me rrethanat, për të mbajtur gati infrastrukturën e vjetër për rikthim në ditët e para pas migrimit.
5. Kapacitetet rezervë të bishtajave dhe përdorimi i tyre
Pothuajse menjëherë u identifikua problemi i mëposhtëm: pods për shërbimin e Regjistrit filluan shpejt, por nisja e pods për Sidekiq zgjati deri në . Koha e gjatë e fillimit për pods Sidekiq u bë një problem kur filluam të migronim ngarkesat e punës në Kubernetes për punëtorët që duhej të përpunonin shpejt punët dhe të shkallëzoheshin shpejt.
Në këtë rast, mësimi ishte se ndërsa Kubernetes Horizontal Pod Autoscaler (HPA) trajton mirë rritjen e trafikut, është e rëndësishme të merren parasysh karakteristikat e ngarkesave të punës dhe të shpërndahet kapaciteti rezervë për pods (veçanërisht kur kërkesa shpërndahet në mënyrë të pabarabartë). Në rastin tonë, pati një rritje të papritur në punë, duke çuar në shkallëzim të shpejtë, gjë që çoi në ngopjen e burimeve të CPU-së përpara se të kishim kohë për të shkallëzuar grupin e nyjeve.
Ekziston gjithmonë një tundim për të shtrydhur sa më shumë që të jetë e mundur nga një grup, megjithatë, pasi kemi hasur fillimisht probleme të performancës, tani po fillojmë me një buxhet bujar të pod dhe po e zvogëlojmë atë më vonë, duke i mbajtur një sy me vëmendje SLO-të. Lëshimi i pods për shërbimin Sidekiq është përshpejtuar ndjeshëm dhe tani zgjat mesatarisht rreth 40 sekonda. fitoi si GitLab.com ashtu edhe përdoruesit tanë të instalimeve të vetë-menaxhuara që punojnë me grafikun zyrtar të GitLab Helm.
Përfundim
Pas migrimit të secilit shërbim, ne u gëzuam për përfitimet e përdorimit të Kubernetes në prodhim: vendosje më të shpejtë dhe më të sigurt të aplikacionit, shkallëzim dhe shpërndarje më efikase të burimeve. Për më tepër, avantazhet e migrimit shkojnë përtej shërbimit GitLab.com. Çdo përmirësim në grafikun zyrtar të Helm-it përfiton përdoruesit e tij.
Shpresoj se ju ka pëlqyer historia e aventurave tona të migrimit të Kubernetes. Ne vazhdojmë të migrojmë të gjitha shërbimet e reja në grup. Informacione shtesë mund të gjenden në botimet e mëposhtme:
- «"?
- «"?
- .
PS nga përkthyesi
Lexoni edhe në blogun tonë:
- «"?
- «"?
- «"?
- «'.
Burimi: www.habr.com