MÅ«su atklÄjumi gada laikÄ, kad GitLab.com tika migrÄts uz Kubernetes
PiezÄ«me. tulk.: Kubernetes ievieÅ”ana GitLab tiek uzskatÄ«ta par vienu no diviem galvenajiem faktoriem, kas veicina uzÅÄmuma izaugsmi. TomÄr vÄl nesen GitLab.com tieÅ”saistes servisa infrastruktÅ«ra tika veidota uz virtuÄlajÄm maŔīnÄm, un tikai aptuveni pirms gada sÄkÄs tÄ migrÄcija uz K8s, kas joprojÄm nav pabeigta. MÄs esam priecÄ«gi iepazÄ«stinÄt ar tulkojumu nesenam GitLab SRE inženiera rakstam par to, kÄ tas notiek un kÄdus secinÄjumus izdara projektÄ iesaistÄ«tie inženieri.
Jau aptuveni gadu mÅ«su infrastruktÅ«ras nodaļa ir migrÄjusi visus pakalpojumus, kas darbojas vietnÄ GitLab.com, uz Kubernetes. Å ajÄ laikÄ mÄs saskÄrÄmies ar problÄmÄm, kas saistÄ«tas ne tikai ar pakalpojumu pÄrvietoÅ”anu uz Kubernetes, bet arÄ« ar hibrÄ«da izvietoÅ”anas pÄrvaldÄ«bu pÄrejas laikÄ. VÄrtÄ«gÄs atziÅas, ko guvÄm, tiks apspriestas Å”ajÄ rakstÄ.
Jau no GitLab.com pirmsÄkumiem tÄ serveri darbojÄs mÄkonÄ« virtuÄlajÄs maŔīnÄs. Å Ä«s virtuÄlÄs maŔīnas pÄrvalda Å”efpavÄrs un instalÄ, izmantojot mÅ«su oficiÄlÄ Linux pakotne. IzvÄrÅ”anas stratÄÄ£ija GadÄ«jumÄ, ja lietojumprogramma ir jÄatjaunina, ir vienkÄrÅ”i saskaÅoti, secÄ«gi atjauninÄt serveru parku, izmantojot CI konveijeru. Å Ä« metode - lai arÄ« lÄna un nedaudz garlaicÄ«gi - nodroÅ”ina, ka GitLab.com izmanto tÄdu paÅ”u instalÄÅ”anas un konfigurÄÅ”anas praksi kÄ bezsaistes lietotÄji (paÅ”pÄrvaldÄ«ts) GitLab instalÄcijas, izmantojot mÅ«su Linux pakotnes Å”im nolÅ«kam.
MÄs izmantojam Å”o metodi, jo ir ÄrkÄrtÄ«gi svarÄ«gi piedzÄ«vot visas bÄdas un priekus, ko piedzÄ«vo parastie kopienas locekļi, instalÄjot un konfigurÄjot savas GitLab kopijas. Å Ä« pieeja kÄdu laiku darbojÄs labi, taÄu, kad GitLab projektu skaits pÄrsniedza 10 miljonus, mÄs sapratÄm, ka tÄ vairs neatbilst mÅ«su mÄrogoÅ”anas un izvietoÅ”anas vajadzÄ«bÄm.
Pirmie soļi uz Kubernetes un mÄkoÅdatoÅ”anas GitLab
Projekts tika izveidots 2017 GitLab diagrammas lai sagatavotu GitLab mÄkoÅa izvietoÅ”anai un ļautu lietotÄjiem instalÄt GitLab Kubernetes klasteros. MÄs zinÄjÄm, ka GitLab pÄrvietoÅ”ana uz Kubernetes palielinÄs SaaS platformas mÄrogojamÄ«bu, vienkÄrÅ”os izvietoÅ”anu un uzlabos skaitļoÅ”anas resursu efektivitÄti. TajÄ paÅ”Ä laikÄ daudzas mÅ«su lietojumprogrammas funkcijas bija atkarÄ«gas no uzstÄdÄ«tajiem NFS nodalÄ«jumiem, kas palÄninÄja pÄreju no virtuÄlajÄm maŔīnÄm.
VirzÄ«ba uz mÄkoÅa native un Kubernetes ļÄva mÅ«su inženieriem plÄnot pakÄpenisku pÄreju, kuras laikÄ mÄs atteicÄmies no dažÄm lietojumprogrammu atkarÄ«bÄm no tÄ«kla krÄtuves, vienlaikus turpinot izstrÄdÄt jaunas funkcijas. KopÅ” mÄs sÄkÄm plÄnot migrÄciju 2019. gada vasarÄ, daudzi no Å”iem ierobežojumiem ir novÄrsti, un GitLab.com migrÄcijas process uz Kubernetes tagad ir labi noritÄjis!
GitLab.com funkcijas Kubernetes
Vietnei GitLab.com mÄs izmantojam vienu reÄ£ionÄlo GKE kopu, kas apstrÄdÄ visu lietojumprogrammu trafiku. Lai samazinÄtu (jau sarežģītÄs) migrÄcijas sarežģītÄ«bu, mÄs koncentrÄjamies uz pakalpojumiem, kas nav atkarÄ«gi no vietÄjÄs krÄtuves vai NFS. VietnÄ GitLab.com galvenokÄrt tiek izmantota monolÄ«tÄ Rails koda bÄze, un mÄs novirzÄm trafiku, pamatojoties uz darba slodzes Ä«paŔībÄm, uz dažÄdiem galapunktiem, kas ir izolÄti savos mezglu pÅ«los.
PriekÅ”gala gadÄ«jumÄ Å”ie veidi ir sadalÄ«ti tÄ«mekļa, API, Git SSH/HTTPS un reÄ£istra pieprasÄ«jumos. AizmugursistÄmas gadÄ«jumÄ mÄs sadalÄm darbus rindÄ atbilstoÅ”i dažÄdiem raksturlielumiem atkarÄ«bÄ no iepriekÅ” noteiktas resursu robežas, kas ļauj mums iestatÄ«t pakalpojumu lÄ«meÅa mÄrÄ·us (SLO) dažÄdÄm darba slodzÄm.
Visi Å”ie GitLab.com pakalpojumi ir konfigurÄti, izmantojot nemodificÄtu GitLab Helm diagrammu. KonfigurÄcija tiek veikta apakÅ”diagrammÄs, kuras var selektÄ«vi iespÄjot, pakÄpeniski migrÄjot pakalpojumus uz klasteru. Lai gan mÄs nolÄmÄm migrÄÅ”anÄ neiekļaut dažus mÅ«su statusa pakalpojumus, piemÄram, Redis, Postgres, GitLab Pages un Gitaly, Kubernetes izmantoÅ”ana ļauj radikÄli samazinÄt Chef paÅ”laik pÄrvaldÄ«to virtuÄlo maŔīnu skaitu.
Kubernetes konfigurÄcijas redzamÄ«ba un pÄrvaldÄ«ba
Visus iestatÄ«jumus pÄrvalda pati GitLab. Å im nolÅ«kam tiek izmantoti trÄ«s konfigurÄcijas projekti, kuru pamatÄ ir Terraform un Helm. MÄs cenÅ”amies izmantot paÅ”u GitLab, kad vien iespÄjams, lai palaistu GitLab, taÄu operatÄ«vajiem uzdevumiem mums ir atseviŔķa GitLab instalÄcija. Tas ir nepiecieÅ”ams, lai nodroÅ”inÄtu, ka, veicot GitLab.com izvietoÅ”anu un atjauninÄÅ”anu, neesat atkarÄ«gs no GitLab.com pieejamÄ«bas.
Lai gan mÅ«su cauruļvadi Kubernetes klasterim darbojas atseviÅ”Ä·Ä GitLab instalÄcijÄ, ir koda krÄtuvju spoguļi, kas ir publiski pieejami Å”ÄdÄs adresÄs:
k8s-workloads/gitlab-helmfiles - Ietver konfigurÄcijas pakalpojumiem, kas nav tieÅ”i saistÄ«ti ar GitLab lietojumprogrammu. Tie ietver konfigurÄcijas reÄ£istrÄÅ”anai un klasteru uzraudzÄ«bai, kÄ arÄ« integrÄtus rÄ«kus, piemÄram, PlantUML;
Gitlab-com-infrastruktÅ«ra ā Terraform konfigurÄcija Kubernetes un mantotajai VM infrastruktÅ«rai. Å eit jÅ«s konfigurÄjat visus resursus, kas nepiecieÅ”ami klastera palaiÅ”anai, tostarp paÅ”u klasteru, mezglu kopas, pakalpojumu kontus un IP adreÅ”u rezervÄcijas.
Kad tiek veiktas izmaiÅas, tiek parÄdÄ«ts publiskais skats. Ä«ss kopsavilkums ar saiti uz detalizÄtu atŔķirÄ«bu, ko SRE analizÄ pirms izmaiÅu veikÅ”anas klasterÄ«.
SRE saite ved uz detalizÄtu atŔķirÄ«bu GitLab instalÄcijÄ, kas tiek izmantota ražoÅ”anai un kurai piekļuve ir ierobežota. Tas ļauj darbiniekiem un kopienai bez piekļuves darbÄ«bas projektam (kas ir pieejams tikai SRE) skatÄ«t ierosinÄtÄs konfigurÄcijas izmaiÅas. Apvienojot publisku GitLab instanci kodam ar privÄtu instanci CI konveijeriem, mÄs uzturam vienu darbplÅ«smu, vienlaikus nodroÅ”inot konfigurÄcijas atjauninÄjumu neatkarÄ«bu no GitLab.com.
Ko mÄs uzzinÄjÄm migrÄcijas laikÄ
PÄrvietoÅ”anÄs laikÄ tika iegÅ«ta pieredze, ko izmantojam jaunÄm migrÄcijÄm un izvietoÅ”anÄm Kubernetes.
1. PaaugstinÄtas izmaksas satiksmes dÄļ starp pieejamÄ«bas zonÄm
Ikdienas izejas statistika (baiti dienÄ) Git repozitorija flotei vietnÄ GitLab.com
Google sadala savu tÄ«klu reÄ£ionos. TÄs savukÄrt ir sadalÄ«tas pieejamÄ«bas zonÄs (AZ). Git hostings ir saistÄ«ts ar lielu datu apjomu, tÄpÄc mums ir svarÄ«gi kontrolÄt tÄ«kla izeju. IekÅ”Äjai satiksmei izeja ir bezmaksas tikai tad, ja tÄ atrodas tajÄ paÅ”Ä pieejamÄ«bas zonÄ. RakstÄ«Å”anas laikÄ mÄs apkalpojam aptuveni 100 TB datu parastajÄ darba dienÄ (un tas attiecas tikai uz Git krÄtuvÄm). Pakalpojumi, kas atradÄs tajÄs paÅ”Äs virtuÄlajÄs maŔīnÄs mÅ«su vecajÄ virtuÄlajÄ datorÄ balstÄ«tajÄ topoloÄ£ijÄ, tagad darbojas dažÄdos Kubernetes podiÅos. Tas nozÄ«mÄ, ka daļa datplÅ«smas, kas iepriekÅ” bija vietÄja virtuÄlajÄ maŔīnÄ, potenciÄli varÄtu pÄrvietoties Ärpus pieejamÄ«bas zonÄm.
ReÄ£ionÄlÄs GKE kopas ļauj aptvert vairÄkas pieejamÄ«bas zonas atlaiÅ”anai. MÄs apsveram iespÄju sadalÄ«t reÄ£ionÄlo GKE klasteru vienas zonas klasteros pakalpojumiem, kas rada lielu trafika apjomu. Tas samazinÄs izejas izmaksas, vienlaikus saglabÄjot klastera lÄ«meÅa dublÄÅ”anos.
2. Ierobežojumi, resursu pieprasÄ«jumi un mÄrogoÅ”ana
To repliku skaits, kas apstrÄdÄ ražoÅ”anas trafiku vietnÄ registry.gitlab.com. Satiksmes maksimums ~15:00 UTC.
MÅ«su migrÄcijas stÄsts sÄkÄs 2019. gada augustÄ, kad mÄs migrÄjÄm savu pirmo pakalpojumu ā GitLab konteineru reÄ£istru ā uz Kubernetes. Å is ļoti svarÄ«gais, augstas datplÅ«smas pakalpojums bija laba izvÄle pirmajai migrÄcijai, jo tÄ ir bezvalstnieku lietojumprogramma ar nelielÄm ÄrÄjÄm atkarÄ«bÄm. PirmÄ problÄma, ar ko mÄs saskÄrÄmies, bija liels skaits izlikto podiÅu, jo mezglos trÅ«ka atmiÅas. Å Ä« iemesla dÄļ mums bija jÄmaina pieprasÄ«jumi un ierobežojumi.
Tika atklÄts, ka lietojumprogrammas gadÄ«jumÄ, kurÄ atmiÅas patÄriÅÅ” laika gaitÄ palielinÄs, zemas pieprasÄ«jumu vÄrtÄ«bas (atmiÅas rezervÄÅ”ana katram podam) kopÄ ar "dÄsnu" stingru lietojuma ierobežojumu izraisÄ«ja piesÄtinÄjumu. (piesÄtinÄjums) mezgli un augsts izlikÅ”anas lÄ«menis. Lai tiktu galÄ ar Å”o problÄmu, tÄ bija tika nolemts palielinÄt pieprasÄ«jumus un samazinÄt limitus. Tas noÅÄma spiedienu uz mezgliem un nodroÅ”inÄja, ka pÄkstÄ«m ir dzÄ«ves cikls, kas nerada pÄrÄk lielu spiedienu uz mezglu. Tagad mÄs sÄkam migrÄciju ar dÄsnÄm (un gandrÄ«z identiskÄm) pieprasÄ«juma un robežvÄrtÄ«bÄm, pielÄgojot tÄs pÄc vajadzÄ«bas.
PÄdÄjÄ gada laikÄ viens no galvenajiem infrastruktÅ«ras nodaļas notikumiem ir uzlabojumi uzraudzÄ«bÄ un darbÄ ar SLO. SLO ļÄva mums noteikt mÄrÄ·us atseviŔķiem pakalpojumiem, kurus rÅ«pÄ«gi uzraudzÄ«jÄm migrÄcijas laikÄ. Bet pat ar Å”o uzlaboto novÄrojamÄ«bu ne vienmÄr ir iespÄjams uzreiz redzÄt problÄmas, izmantojot metriku un brÄ«dinÄjumus. PiemÄram, koncentrÄjoties uz latentumu un kļūdu biežumu, mÄs pilnÄ«bÄ neaptveram visus pakalpojuma, kas tiek migrÄts, lietoÅ”anas gadÄ«jumus.
Å Ä« problÄma tika atklÄta gandrÄ«z uzreiz pÄc dažu darba slodžu migrÄÅ”anas uz kopu. ÄŖpaÅ”i aktuÄli tas kļuva, kad bija jÄpÄrbauda funkcijas, kurÄm pieprasÄ«jumu skaits bija neliels, bet kurÄm bija ļoti specifiskas konfigurÄcijas atkarÄ«bas. Viena no galvenajÄm mÄcÄ«bÄm no migrÄcijas bija nepiecieÅ”amÄ«ba pÄrraudzÄ«bÄ Åemt vÄrÄ ne tikai rÄdÄ«tÄjus, bet arÄ« žurnÄlus un āgaro astiā. (tas ir apmÄram tÄds to sadalÄ«jums diagrammÄ - apm. tulk.) kļūdas. Tagad katrai migrÄcijai mÄs iekļaujam detalizÄtu žurnÄla vaicÄjumu sarakstu (reÄ£istrÄt vaicÄjumus) un plÄnojiet skaidras atcelÅ”anas procedÅ«ras, kuras var pÄrcelt no vienas maiÅas uz nÄkamo, ja rodas problÄmas.
Vienu un to paÅ”u pieprasÄ«jumu paralÄla apkalpoÅ”ana vecajÄ virtuÄlÄs maŔīnas infrastruktÅ«rÄ un jaunajÄ Kubernetes infrastruktÅ«rÄ radÄ«ja unikÄlu izaicinÄjumu. AtŔķirÄ«bÄ no pacelÅ”anas un maiÅas migrÄcijas (Ätra lietojumprogrammu pÄrsÅ«tÄ«Å”ana ātÄdas, kÄdas irā uz jaunu infrastruktÅ«ru; sÄ«kÄku informÄciju var lasÄ«t, piemÄram, Å”eit ā apm. tulk.), paralÄlam darbam ar āvecajÄmā virtuÄlajÄm maŔīnÄm un Kubernetes ir nepiecieÅ”ams, lai uzraudzÄ«bas rÄ«ki bÅ«tu saderÄ«gi ar abÄm vidÄm un spÄtu apvienot metriku vienÄ skatÄ. Ir svarÄ«gi, lai mÄs izmantotu tos paÅ”us informÄcijas paneļus un žurnÄla vaicÄjumus, lai nodroÅ”inÄtu konsekventu novÄrojamÄ«bu pÄrejas periodÄ.
4. Trafika pÄrslÄgÅ”ana uz jaunu klasteru
VietnÄ GitLab.com daļa serveru ir paredzÄta KanÄriju posms. Canary Park apkalpo mÅ«su iekÅ”Äjos projektus un arÄ« var iespÄjojuÅ”i lietotÄji. Bet tas galvenokÄrt ir paredzÄts, lai pÄrbaudÄ«tu izmaiÅas, kas veiktas infrastruktÅ«rÄ un lietojumprogrammÄ. Pirmais migrÄtais pakalpojums sÄkÄs, pieÅemot ierobežotu iekÅ”ÄjÄs datplÅ«smas apjomu, un mÄs turpinÄm izmantot Å”o metodi, lai nodroÅ”inÄtu SLO atbilstÄ«bu pirms visas trafika nosÅ«tÄ«Å”anas uz kopu.
MigrÄcijas gadÄ«jumÄ tas nozÄ«mÄ, ka iekÅ”Äjiem projektiem pieprasÄ«jumi vispirms tiek nosÅ«tÄ«ti uz Kubernetes, un pÄc tam mÄs pakÄpeniski pÄrslÄdzam pÄrÄjo trafiku uz klasteri, mainot aizmugursistÄmas svaru, izmantojot HAProxy. MigrÄcijas laikÄ no VM uz Kubernetes kļuva skaidrs, ka ir ļoti izdevÄ«gi viegli pÄradresÄt trafiku starp veco un jauno infrastruktÅ«ru un attiecÄ«gi saglabÄt veco infrastruktÅ«ru gatavÄ«bÄ atcelÅ”anai pirmajÄs dienÄs pÄc migrÄcijas.
5. PÄkÅ”u rezerves jaudas un to izmantoÅ”ana
GandrÄ«z uzreiz tika konstatÄta Å”Äda problÄma: reÄ£istra pakalpojuma aplikÄcijas tika sÄktas Ätri, bet Sidekiq komplektu palaiÅ”ana aizÅÄma divas minÅ«tes. Sidekiq podziÅu ilgstoÅ”ais palaiÅ”anas laiks kļuva par problÄmu, kad sÄkÄm migrÄt darba slodzes uz Kubernetes darbiniekiem, kuriem bija Ätri jÄapstrÄdÄ darbi un Ätri jÄmÄro.
Å ajÄ gadÄ«jumÄ mÄcÄ«ba bija tÄda, ka, lai gan Kubernetes Horizontal Pod Autoscaler (HPA) labi pÄrvalda trafika pieaugumu, ir svarÄ«gi Åemt vÄrÄ darba slodzes Ä«paŔības un pieŔķirt podiem rezerves jaudu (Ä«paÅ”i, ja pieprasÄ«jums ir nevienmÄrÄ«gi sadalÄ«ts). MÅ«su gadÄ«jumÄ bija pÄkÅ”Ås darba vietu pieaugums, kas izraisÄ«ja strauju mÄrogoÅ”anu, kas izraisÄ«ja CPU resursu piesÄtinÄjumu, pirms mums bija laiks mÄrogot mezglu kopu.
VienmÄr ir kÄrdinÄjums izspiest pÄc iespÄjas vairÄk no klastera, tomÄr, sÄkotnÄji saskÄroties ar veiktspÄjas problÄmÄm, tagad sÄkam ar dÄsnu pod budžetu un vÄlÄk to samazinÄm, rÅ«pÄ«gi sekojot lÄ«dzi SLO. Sidekiq pakalpojuma podiÅu palaiÅ”ana ir ievÄrojami paÄtrinÄjusies, un tagad tas aizÅem vidÄji 40 sekundes. No pÄkstu palaiÅ”anas laika samazinÄÅ”anas uzvarÄja gan GitLab.com, gan mÅ«su paÅ”pÄrvaldÄ«to instalÄciju lietotÄji, kas strÄdÄ ar oficiÄlo GitLab Helm diagrammu.
SecinÄjums
PÄc katra pakalpojuma migrÄÅ”anas mÄs priecÄjÄmies par priekÅ”rocÄ«bÄm, ko sniedz Kubernetes izmantoÅ”ana ražoÅ”anÄ: ÄtrÄka un droÅ”Äka lietojumprogrammu izvietoÅ”ana, mÄrogoÅ”ana un efektÄ«vÄka resursu pieŔķirÅ”ana. TurklÄt migrÄcijas priekÅ”rocÄ«bas pÄrsniedz pakalpojumu GitLab.com. Katrs oficiÄlÄs Helm diagrammas uzlabojums sniedz labumu tÄs lietotÄjiem.
Ceru, ka jums patika stÄsts par mÅ«su Kubernetes migrÄcijas piedzÄ«vojumiem. MÄs turpinÄm migrÄt visus jaunos pakalpojumus uz kopu. Papildu informÄciju var atrast Å”ÄdÄs publikÄcijÄs: