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.

Mūsu atklājumi gada laikā, kad GitLab.com tika migrēts uz Kubernetes

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-com ā€” GitLab.com konfigurācijas sistēma GitLab Helm diagrammai;
  • 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.

Mūsu atklājumi gada laikā, kad GitLab.com tika migrēts uz Kubernetes
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

Mūsu atklājumi gada laikā, kad GitLab.com tika migrēts uz Kubernetes
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

Mūsu atklājumi gada laikā, kad GitLab.com tika migrēts uz Kubernetes
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.

3. Metrika un žurnāli

Mūsu atklājumi gada laikā, kad GitLab.com tika migrēts uz Kubernetes
Infrastruktūras nodaļa koncentrējas uz latentumu, kļūdu biežumu un piesātinājumu ar instalēto pakalpojumu līmeņa mērķi (SLO) ir saistīts ar mūsu sistēmas vispārēja pieejamība.

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:

PS no tulka

Lasi arī mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru