Shën. përk.: Adaptimi i Kubernetes në GitLab është konsideruar si një nga dy faktorët kryesorë që kontribuojnë në rritjen e kompanisë. Megjithatë, deri para pak kohësh, infrastruktura e shërbimit online GitLab.com ishte ndërtuar mbi makina virtuale, dhe vetëm rreth një viti më parë filloi migrimi i saj në K8s, i cili ende nuk ka përfunduar. Jemi të kënaqur të paraqesim përkthimin e një artikulli të fundit nga inxhinieri SRE i GitLab mbi se si po zhvillohet kjo dhe cilat përfundime po nxjerrin inxhinierët që po marrin pjesë në projekt.
Tani e një vit, departamenti ynë i infrastrukturës ka qenë duke migruar të gjitha shërbimet që punojnë në GitLab.com në Kubernetes. Gjatë kësaj kohe, ne kemi hasur probleme të lidhura jo vetëm me zhvendosjen e shërbimeve në Kubernetes, por edhe me menaxhimin e një deploy-menti hibrid gjatë kalimit. Më shumë mbi mësimet e çmuara që kemi marrë do të diskutohet në këtë artikull.
QĂ« nĂ« fillim, serverat e GitLab.com kanĂ« punuar nĂ« cloud mbi makina virtuale. KĂ«to makina virtuale menaxhohen nga Chef, dhe vendosja e tyre bĂ«het me ndihmĂ«n e paketĂ«s sonĂ« . nĂ« rast se duhet tĂ« pĂ«rmirĂ«sohet aplikacioni, Ă«shtĂ« njĂ« azhurnim i thjeshtĂ« i parkut tĂ« serverĂ«ve, i organizuar nĂ« mĂ«nyrĂ« tĂ« koordinuar nĂ« njĂ« rrjedhĂ« CI. Kjo metodĂ« â megjithĂ«se e ngadaltĂ« dhe pak e mĂ«rzitshme (vetĂ«-menaxhuar) tĂ« GitLab, qĂ« pĂ«rdorin paketat tona pĂ«r Linux pĂ«r kĂ«tĂ«. Ne pĂ«rdorim kĂ«tĂ« metodĂ« sepse Ă«shtĂ« jashtĂ«zakonisht e rĂ«ndĂ«sishme tĂ« pĂ«rjetosh tĂ« gjitha shqetĂ«simet dhe gĂ«zimet qĂ« ndjejnĂ« anĂ«tarĂ«t e zakonshĂ«m tĂ« komunitetit kur instalojnĂ« dhe konfigurĂ«jnĂ« kopjet e tyre tĂ« GitLab. Ky qasje ka funksionuar mirĂ« pĂ«r njĂ« kohĂ«, megjithatĂ«, kur numri i projekteve nĂ« GitLab kaloi 10 milion, kuptuam se nuk pĂ«rmbushte mĂ« nevojat tona pĂ«r shkallĂ«zim dhe implementim.
Hapat e parë drejt Kubernetes dhe GitLab cloud-native
NĂ« vitin 2017, projekti
GitLab Charts për të përgatitur GitLab për implementim në cloud, si dhe për të mundësuar përdoruesve të instalojnë GitLab në klastera Kubernetes. Atëherë ne e dinim se transferimi i GitLab në Kubernetes do të rrisë kapacitetin e përmasimit të platformës SaaS, do të thjeshtonte implementimet dhe do të përmirësonte efikasitetin e përdorimit të burimeve kompjuterike. Në të njëjtën kohë, shumë funksione të aplikacionit tonë varen nga ndarjet NFS të montuara, gjë që ngadalësoi kalimin nga makinat virtuale.
Dëshira për cloud native dhe Kubernetes i dha mundësi inxhinierëve tanë të planifikonin një kalim gradual, gjatë të cilit ne hoqëm dorë nga disa varësi të aplikacionit nga ruajtjet rrjet, duke vazhduar njëkohësisht zhvillimin e funksioneve të reja. Që kur filluam të planifikonim migrimin verën e vitit 2019, shumë nga këto kufizime janë eliminuar, dhe procesi i kalimit të GitLab.com në Kubernetes tani po ecën me ritëm të plotë!
Karakteristikat e funksionimit të GitLab.com në Kubernetes
Për GitLab.com ne përdorim një grup njëregional GKE, i cili trajton të gjithë trafikun e aplikacionit. Për të minimizuar kompleksitetin e migrimit (që është tashmë mjaft i ndërlikuar), ne përqendrohemi në shërbime që nuk varen nga ruajtja lokale ose NFS. GitLab.com përdor kryesisht një bazë kodike monolitike në Rails, dhe ne drejtojmë trafikun në varësi të karakteristikave të ngarkesës në endpoint-e të ndryshëm, të izoluar në grupe të veçanta nodash.
Në rastin e frontend-it, këto lloje ndahen në kërkesa për web, API, Git SSH/HTTPS dhe Registry. Në rastin e backend-it, ne ndajmë punët në radhë sipas karakteristikave të ndryshme në varësi të , të cilat na lejojnë të vendosim standardet e shërbimit (Service-Level Objectives, SLOs) për ngarkesa të ndryshme.
Të gjitha këto shërbime GitLab.com janë konfiguruar me anë të chart-it Helm të papërmirësuar. Konfigurimi realizohet në subchart-e, të cilat mund të aktivizohen selektivisht pasi ne gradualisht i transferojmë shërbimet në klaster. Edhe me vendimin për të mos përfshirë në migrim disa nga shërbimet tona stateful, si Redis, Postgres, GitLab Pages dhe Gitaly, përdorimi i Kubernetes-it lejon një reduktim radical të numrit të VM-ve që aktualisht menaxhohen nga Chef.
Transparenca dhe menaxhimi i konfiguracionit të Kubernetes
Të gjitha konfigurimet menaxhohen nga vetë GitLab. Për këtë, përdoren tre projekte konfigurimi të bazuara në Terraform dhe Helm. Ne përpiqemi në çdo rast të përdorim vetë GitLab për të ekzekutuar GitLab-in, por për detyra operative kemi një instalim të veçantë GitLab. Kjo nevojitet për të evituar varësinë nga disponueshmëria e GitLab.com gjatë zhvillimeve dhe përditësimeve të GitLab.com.
Megjithëse pipeline-t tona për klasterin Kubernetes funksionojnë në një instalim të veçantë GitLab, ka pasqyra për depozitë kodi që janë publikisht të disponueshme në adresat e mëposhtme:
- â mbĂ«shtetje konfigurimi pĂ«r GitLab.com pĂ«r chart-in Helm tĂ« GitLab;
- â pĂ«rmban konfigurime pĂ«r shĂ«rbime qĂ« nuk janĂ« tĂ« lidhura drejtpĂ«rdrejt me aplikacionin GitLab. KĂ«tu pĂ«rfshihen konfigurimet pĂ«r mbajtjen e logeve dhe monitorimin e klasterit, si dhe pĂ«r instrumentet e integruara si PlantUML;
- â konfigurim Terraform pĂ«r Kubernetes dhe infrastrukturĂ«n e vjetĂ«r (legacy) VM. KĂ«tu konfigurohen tĂ« gjitha burimet e nevojshme pĂ«r tĂ« pĂ«rgatitur klasterin, pĂ«rfshirĂ« klasterin vetĂ«, grumbujt e node-ve, llogaritĂ« e shĂ«rbimeve, rezervimin e adreseve IP.
Kur bëhen ndryshime, tregohet publikisht me lidhje në një diferencë të detajuar, e cila analizohet nga SRE përpara se të bëhen ndryshime në klaster.
Për SRE, linku çon në një ndryshim të hollësishëm në instalimin e GitLab, i cili përdoret për operacion dhe akses i cili është i kufizuar. Kjo lejon punonjësit dhe komunitetin pa akses në projektin operativ (i cili është i hapur vetëm për SRE) të shohin ndryshimet e propozuara në konfigurim. Duke kombinuar një ekzemplar publik të GitLab për kodin me një ekzemplar të mbyllur për CI-pajisjet, ne ruajmë një proces të vetëm punimi, duke garantuar njëkohësisht pavarësinë nga GitLab.com gjatë azhurnimeve të konfigurimit.
ĂfarĂ« kemi mĂ«suar gjatĂ« migruarĂ«s
Gjatë procesit të zhvendosjes, u fitua përvoja që e përdorim në migrimet dhe deployment-et e reja në Kubernetes.
1. Rritja e shpenzimeve për shkak të trafikut midis zonave të disponueshmërisë
Statistika e përditshme e egress (byt në ditë) për parkun e Git-repozitoreve në GitLab.com
Google ndan një ndarje të rrjetit të saj në rajone. Këto, nga ana tjetër, ndahen në zona aksesibiliteti (AZ). Git-hosting është i lidhur me volumet e mëdha të të dhënave, prandaj është e rëndësishme për ne të kontrollojmë egress-in e rrjetit. Në rastin e trafikut të brendshëm, egress është falas vetëm nëse mbetet brenda një zone aksesibiliteti. Në momentin kur është shkruar ky artikull, ne po dërgojmë rreth 100 TB të dhënash në një ditë punë të zakonshme (dhe kjo është vetëm për Git-repozitat). Shërbimet, të cilat në topologjinë tonë të vjetër, e cila bazohej në VM, ndodheshin në të njëjtat makina virtuale, tani funksionojnë në pod-e të ndryshme Kubernetes. Kjo do të thotë se disa pjesë të trafikut, të cilat më parë ishin lokale për VM, mund të dalin potencialisht përtej zonave të aksesibilitetit.
Klastrat rajonalë GKE lejojnë mbulimin e disa zonave aksesibiliteti për rezervim. Ne po shqyrtojmë mundësinë për shërbimet që gjenerojnë sasi të mëdha trafiku. Kjo do të ndihmojë në reduktimin e kostove të egress-it ndërsa mbahet rezervimi në nivelin e klastrit.
2. Kufijtë, kërkesat për burime dhe shkallëzim
Numri i replikave, që trajtojnë trafikun production në registry.gitlab.com. Trafiku arrin kulmin e tij rreth orës 15:00 UTC.
Historia jonĂ« me migrimin filloi nĂ« gusht 2019, kur transferuam shĂ«rbimin e parĂ« â regjistri i konteinerĂ«ve GitLab (GitLab Container Registry) â nĂ« Kubernetes. Ky shĂ«rbim kritik me trafik tĂ« lartĂ« ishte njĂ« zgjedhje e mirĂ« pĂ«r migrimin e parĂ«, pasi pĂ«rbĂ«n njĂ« aplikacion stateless me njĂ« numĂ«r tĂ« vogĂ«l varĂ«sish tĂ« jashtme. Problemi i parĂ« me tĂ« cilin u pĂ«rballĂ«m ishte numri i madh i pod-eve qĂ« u dĂ«buan pĂ«r shkak tĂ« mungesĂ«s sĂ« memories nĂ« nyje. PĂ«r kĂ«tĂ« arsye, na duhej tĂ« ndryshonim request-Ă«t dhe limit-Ă«t.
U zbulua se nĂ« rastin e njĂ« aplikacioni, i cili konsumon mĂ« shumĂ« memorie me kalimin e kohĂ«s, vlerat e ulta pĂ«r request-Ă«t (qĂ« rezervonin memorie pĂ«r çdo pod) sĂ« bashku me njĂ« 'kĂ«llĂ«f' tĂ« 'bujshĂ«m' pĂ«r pĂ«rdorim çuan nĂ« saturimin (saturation) e nyjeve dhe njĂ« nivel tĂ« lartĂ« dĂ«bimesh. PĂ«r tĂ« trajtuar kĂ«tĂ« problem, u . Kjo e hoqi presionin nga nyjat dhe siguroi njĂ« cikĂ«l jetese pĂ«r pod'Ă«t qĂ« nuk ushtroi presion tĂ« tepruar mbi nyje. Tani fillojmĂ« migrimet me vlera bujare (dhe pothuajse tĂ« njejta) pĂ«r requestâĂ«t dhe limitâĂ«t, duke i rregulluar ato sipas nevojĂ«s.
3. Metrit dhe regjistrat
Njësia infrastrukturore përqendrohet në vonesat, përqindjen e gabimeve dhe saturimin me objektiva të vendosur (SLO), të lidhura me .
Gjatë vitit të kaluar, një nga ngjarjet kryesore në njësinë infrastrukturore ishin përmirësimet në monitorimin dhe menaxhimin e SLO-ve. SLO-të na lejuan të vendosim objektiva për shërbime të ndara, që ne i ndoqëm me kujdes gjatë migrimit. Por, edhe me këtë përmirësim në observueshmëri, nuk është gjithmonë e mundur të shihni menjëherë problemet, duke përdorur metrikat dhe alarmin. Për shembull, duke u përqendruar në vonesat dhe përqindjen e gabimeve, nuk e mbulojmë plotësisht çdo skenar përdorimi të shërbimit që po migron.
Ky problemi u zbulua pothuajse menjĂ«herĂ« pas transferimit tĂ« pjesĂ«s sĂ« ngarkesave nĂ« klaster. Ai u shfaq veçanĂ«risht ashpĂ«r kur duhej tĂ« kontrolloheshin funksionet, numri i kĂ«rkesave pĂ«r tĂ« cilat nuk Ă«shtĂ« i madh, por qĂ« kanĂ« varĂ«si konfiguruese shumĂ« specifike. NjĂ« nga mĂ«simet kyçe nga migrimi ishte nevoja pĂ«r tĂ« marrĂ« parasysh gjatĂ« monitorimit jo vetĂ«m metrikat, por gjithashtu log-et dhe "bishtin e gjatĂ«". (po flasim pĂ«r nĂ« grafik â shĂ«n. pĂ«rk.) gabimeve. Tani pĂ«r çdo migrim ne pĂ«rfshijmĂ« njĂ« listĂ« tĂ« detajuar tĂ« kĂ«rkesave nĂ« log (log queries) dhe planifikojmĂ« procedura tĂ« qarta rikthimi, tĂ« cilat nĂ« rast se ndodhin probleme, mund tĂ« kalohen nga njĂ« ndĂ«rrim nĂ« tjetrin.
ShĂ«rbimi paralel i tĂ« njĂ«jtave kĂ«rkesa nĂ« infrastrukturĂ«n e vjetĂ«r VM dhe atĂ« tĂ« re, tĂ« bazuar nĂ« Kubernetes, paraqiste njĂ« sfidĂ« unike. Ndryshe nga migrimi i tipit lift-and-shift (transferimi i shpejtĂ« i aplikacioneve "ashtu siç janĂ«" nĂ« infrastrukturĂ«n e re; mund tĂ« lexoni mĂ« shumĂ«, pĂ«r shembull, â shĂ«nim i pĂ«rkthyesit.), puna paralel e punĂ«s nĂ« VM-tĂ« "e vjetra" dhe Kubernetes kĂ«rkon qĂ« mjetet pĂ«r monitorimin tĂ« jenĂ« tĂ« pĂ«rputhshme me tĂ« dyja 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 dashboard-e dhe kĂ«rkesa pĂ«r log-et pĂ«r tĂ« arritur njĂ« vĂ«zhgim tĂ« njĂ«pasnjĂ«shĂ«m gjatĂ« periudhĂ«s kalimtare.
4. Kalimi i trafikut në grumbullin e ri
Për GitLab.com, një pjesë e serverëve i përkushtohet . Parku kanarire shërben për projektet tona të brendshme, si dhe mund . Por në radhë të parë, ai është menduar për të testuar ndryshimet që bëhen në infrastrukturë dhe aplikacion. Shërbimi i parë i transferuar filloi duke pranuar një volum të kufizuar të trafikut të brendshëm, dhe ne vazhdojmë ta përdorim këtë metodë për të siguruar përmbushjen e SLO para se të drejtojmë të gjithë trafikun në grumbull.
Në rastin e migrimit, kjo do të thotë se më parë kërkesat dërgohen në projektet e brendshme në Kubernetes, dhe më pas ne gradualisht kalojmë trafikun e mbetur në klaster duke ndryshuar peshën për backend përmes HAProxy. Gjatë kalimit nga VM në Kubernetes, është bërë e qartë se është shumë e dobishme të kemi një mënyrë të thjeshtë për të ridrejtuar trafikun midis infrastrukturave të vjetra dhe atyre të reja dhe, përkatësisht, të mbajmë infrastrukturën e vjetër gatish për rikthim në ditët e para pas migrimit.
5. Kapacitetet rezervĂ« tĂ« podâave dhe pĂ«rdorimi i tyre
Gati menjĂ«herĂ« Ă«shtĂ« zbuluar problemi nĂ« vijim: podâĂ«t pĂ«r shĂ«rbimin Registry filluan shpejt, megjithatĂ«, nisja e podâave pĂ«r Sidekiq zgjaste deri . Nisja e zgjatur e podâave pĂ«r Sidekiq u bĂ« njĂ« problem kur filluam migrimin e ngarkesave nĂ« Kubernetes pĂ«r punĂ«torĂ«t, tĂ« cilĂ«t duhet tĂ« pĂ«rpunojnĂ« shpejt jobâĂ«t dhe tĂ« shkallĂ«zojnĂ« shpejt.
Në këtë rast, mësimi ishte se, megjithëse Horizontal Pod Autoscaler (HPA) në Kubernetes përballet me rritjen e trafikut, është e rëndësishme të merret parasysh karakteristikat e ngarkesave të punës dhe të alokohen burime rezervë për pod-at (sidomos në kushte të shpërndarjes së pabarabartë të kërkesës). Në rastin tonë, u vërejt një shpërthim i papritur i punëve, i cili çoi në një shkallëzim të shpejtë, duke bërë që burimet e CPU të mbushej para se të kishim mundësi të shkallëzonim grupin e nyjeve.
Gjithmonë ka tundimin për të nxjerrë sa më shumë "shfrytëzim" nga klasteri, megjithatë, pasi fillimisht u përballëm me probleme me performancën, tani fillojmë me një buxhet të bollshëm për pod-at dhe e zvogëlojmë atë më pas, duke e monitoruar me kujdes SLO. Nisja e pod-eve për shërbimin Sidekiq ka përshpejtuar në masë të madhe dhe tani zgjat mesatarisht rreth 40 sekonda. përfituan si GitLab.com ashtu edhe përdoruesit tanë të instalimeve self-managed, duke punuar me Helm-chartin zyrtar të GitLab.
PĂ«rfundimi
Pas transferimit tĂ« çdo shĂ«rbimi, ne u gĂ«zuam pĂ«r pĂ«rfitimet e pĂ«rdorimit tĂ« Kubernetes nĂ« prodhim: njĂ« shpĂ«rndarje mĂ« tĂ« shpejtĂ« dhe mĂ« tĂ« sigurt tĂ« aplikacioneve, shkallĂ«zim dhe njĂ« shpĂ«rndarje mĂ« efikase tĂ« resurseve. PĂ«r mĂ« tepĂ«r, pĂ«rfitimet e migrimit tejkalojnĂ« shĂ«rbimin GitLab.com. Ădo pĂ«rmirĂ«sim i Helm-chart-it zyrtar pĂ«rfitohet edhe nga pĂ«rdoruesit e tij.
Shpresoj që t'ju ketë pëlqyer historia e aventurave tona me migrimin në Kubernetes. Ne vazhdojmë të transferojmë shërbime të reja në grup. Informacione të tjera mund të gjenden në publikimet e mëposhtme:
- «»;
- «»;
- .
P.S. nga përkthyesi
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
