🥇 Meie järeldused aasta jooksul GitLab.com-i migratsioonist Kubernetes'esse

Märkus tõlke kohta.: Kubernetes'i rakendamine GitLab'is peetakse üheks kahest peamisest tegurist, mis soodustavad ettevõtte kasvu. Siiski, kuni hiljutise ajani oli GitLab.com'i veebiteenuse infrastruktuur rajatud virtuaalmasinatele ning migratsioon K8s-i algas alles umbes aasta tagasi ning pole siiani lõppenud. Oleme rõõmsad, et saame esitleda tõlget GitLabi SRE-inseneri hiljutisest artiklist selle kohta, kuidas see käib ja milliseid järeldusi teevad projekti kaasavad insenerid.

Meie infrastruktuuri osakond on juba umbes aasta tegelenud kõigi GitLab.com'i teenuste migreerimisega Kubernetes'i. Selle aja jooksul oleme silmitsi seisnud probleemidega, mis on seotud mitte ainult teenuste liigutamisega Kubernetes'i, vaid ka hübriidse deployment'i juhtimisega ülemineku ajal. Käesolevas artiklis räägitakse meile saadud väärtuslikest õppetundidest.

Alates GitLab.com'i loomisest töötasid selle serverid pilves virtuaalmasinatel. Nende virtuaalmasinate üle haldab Chef ning nende paigaldamine toimub meie ametliku Linuxi paketi. Installeerimisstrateegia rakenduse uuendamiseks seisneb serverite pargi koordineeritud järjestikku ajakohastamises CI-pipeline'i abil. See meetod — kuigi aeglane ja veidi igav — garanteerib, et GitLab.com rakendab samu paigaldus- ja konfigureerimismeetodeid nagu iseseisvad (self-managed) GitLabi paigaldused, mis kasutavad selleks meie Linuxi pakette.

Kasutame seda meetodit, kuna on äärmiselt oluline tunda omal nahal kogemusi ja rõõme, millega kogukonna tavalised liikmed silmitsi seisavad, kui nad installivad ja seadistavad oma GitLabi koopiad. See lähenemine toimis mõnda aega hästi, kuid kui projektide arv GitLab'is ületas 10 miljoni piiri, mõistsime, et see ei rahulda enam meie vajadusi skaleerimise ja deploy'imise osas.

Esimesed sammud Kubernetes'i ja cloud-native GitLab'i suunas

2017. aastal loodi projekt GitLab Charts GitLabi ettevalmistamiseks pilves kasutamiseks ja selleks, et anda kasutajatele võimalus installida GitLab Kubernetesi klastritesse. Siis teadsime, et GitLabi üleviimine Kubernetesesse suurendab SaaS-platvormi skaleerimisvõimalusi, lihtsustab kasutuselevõtteid ja parandab arvutusressursside efektiivsust. Samal ajal sõltus palju meie rakenduse funktsioone monteeritud NFS-osade kasutamisest, mis aeglustas üleminekut virtuaalmasinatelt.

Püüd cloud native ja Kubernetesi suunas võimaldas meie inseneridel planeerida järkjärgulist üleminekut, mil me loobusime mõnest rakenduse sõltuvusest võrguhoiust, jätkates samal ajal uute funktsioonide arendamist. Alates sellest ajast, kui me hakkasime migratsiooni planeerima 2019. suvel, on paljusid neist piirangutest eradud ja GitLab.com'i üleviimine Kubernetesesse käib nüüd täie hooga!

GitLab.com-i töömudeli eripärad Kuberneteses

GitLab.com-i jaoks kasutame ühtset piirkondlikku GKE klastri, mis töötleb kogu rakenduse liiklust. Et minimeerida migratsiooni keerukust (juba niigi segast), keskendume teenustele, mis ei sõltu kohalikest salvestusruumidest või NFS-ist. GitLab.com kasutab peamiselt monoliitset koodibaasi Railsil ning suuname liikluse töökoormuse omaduste põhjal erinevatele lõpp-punktidele, mis on isolatsioonis oma node'ide basseinides.

Frontend'i puhul jaguneb see liiklus veebiversiooniks, API-ks, Git SSH/HTTPS-ks ja Registry-ks. Backend'i puhul jagame tööülesandeid järjestustesse vastavalt eelnevalt määratud ressursipiirangutele, mis võimaldavad meil seada teenindustaseme eesmärke (Service-Level Objectives, SLOs) erinevate koormuste jaoks.

Kõik need GitLab.com teenused on seadistatud muudetud Helm'i kaardi abil. Konfiguratsioon toimub alakaardil, mis võivad olla valikuliselt aktiveeritud, kui me järk-järgult viime teenused klastrisse. Isegi arvestades, et on otsustatud mitte kaasata mõned meie stateful-teenused, nagu Redis, Postgres, GitLab Pages ja Gitaly, võimaldab Kubernetes radikaalselt vähendada Chef'i haldavat VM-i arvu.

Kubernetes'i läbipaistvus ja konfiguratsiooni haldamine

Kõik seaded hallatakse GitLabi poolt ise. Selleks kasutatakse kolme Terraformi ja Helmi põhist konfiguratsiooniprojekti. Püüame igal võimalusel kasutada GitLabi GitLabi käitamiseks, kuid tootmisülesannete jaoks töötab meil eraldi GitLabi installatsioon. See on vajalik, et mitte sõltuda GitLab.com-i kättesaadavusest GitLab.com-i juurutuste ja uuenduste tegemisel.

Kuigi meie Kubernetes klastrite torujuhtmed töötavad eraldi GitLabi installatsioonil, on koodirepositooriumidel peeglid, mis on avalikult saadaval järgmistel aadressidel:

k8s-workloads/gitlab-com — GitLab.com-i Helmi kaardi konfiguratsiooni ümbritsev konfiguratsioon;
k8s-workloads/gitlab-helmfiles — sisaldab konfigureerimisi teenustele, mis ei ole otseselt seotud GitLab rakendusega. Nende hulka kuuluvad seadistused logimise ja klastrite jälgimise jaoks, samuti integreeritud tööriistad nagu PlantUML;
Gitlab-com-infrastructure — Terraformi konfiguratsioon Kubernetes ja vana (legacy) VM-infrastruktuuri jaoks. Siin seadistatakse kõik vajalikud ressursid, et klastrit käivitada, sealhulgas klaster ise, sõlmede pooled, teenusekontod, IP-aadresside reserveerimine.

Muudatuste tegemisel kuvatakse avalik lühikokkuvõte lingiga detailse diff'i juurde, mida SRE analüüsib enne muudatuste tegemist klastris.

SRE jaoks viib link detailse diff'ini GitLabi installatsioonis, mida kasutatakse tootmiseks ja millele on juurdepääs piiratud. See võimaldab töötajatel ja kogukonnal, kellel ei ole juurdepääsu tootmisprojektile (millele pääsevad juurde ainult SRE), vaadata ettepanekud konfiguratsiooni muudatusteks. Liitmine avaliku GitLabi näidis koodiga ja suletud näidis CI-toru juures säilitab ühtse töövoo, tagades samal ajal sõltumatuse GitLab.com-ist konfiguratsiooni uuendamisel.

Mida oleme välja selgitanu migratsiooni ajal

Rände protsessis on omandatud kogemus, mida rakendame uute migratsioonide ja juurutuste puhul Kuberneteses.

1. Kulude kasv ligikaudses liikluses erinevate kättesaadavuspiirkondade vahel

Igapäevane väljamineku statistika (baiti päevas) meie GitLabi hoidlate kogumi kohaselt GitLab.com-il.

Google jagab oma võrgustiku piirkondadeks. Need jagunevad omakorda kättesaadavuspiirkondadeks (AZ). Git-i hostimine on seotud suure andmemahtudega, seetõttu on meie jaoks oluline kontrollida võrgu egressi. Sisemise liikluse puhul on egress tasuta ainult juhul, kui see jääb ühe kättesaadavuspiirkonna piiridesse. Käesoleva artikli kirjutamise seisuga edastame ligikaudu 100 TB andmeid harilikul tööpäeval (ja see on ainult Git-repositooriumide jaoks). Teenused, mis meie vanas VM-põhises topoloogias asusid ühel ja samal virtuaalsel masinal, töötavad nüüd erinevates Kubernetes'i pod'ides. See tähendab, et osa liiklust, mis varem oli kohaliku VM-i jaoks, võib potentsiaalselt ületada kättesaadavuspiirkondade piire.

Regionaalsed GKE klastrid võimaldavad katta mitmeid kättesaadavuspiirkondi varundamiseks. Me kaalume võimalust jagada regionaalset GKE klastrit ühe kättesaadavuspiirkonna klastriteks teenustele, mis genereerivad suurt liikluse mahtu. See võimaldab vähendada egressi kulusid, säilitades samas klastritasandi varundamise.

2. Limitid, ressursside taotlused ja skaleerimine

Replikate arv, mis töötleb production-liiklust registry.gitlab.com. Liiklus saavutab haripunkti umbes kell 15:00 UTC.

Meie migreerimise lugu algas 2019. aasta augustis, kui me kandsime esimesena üle teenuse — GitLabi konteineriregistri (GitLab Container Registry) — Kubernetesesse. See kriitilise tähtsusega kõrge liiklusega teenus sobis esimeseks migreerimiseks hästi, kuna see on stateless rakendus, millel on vähe väliseid sõltuvusi. Esimese probleemina, millega me silmitsi seisime, oli suur hulk väljutatud pod'e, mis oli põhjustatud mälu puudumisest sõlmedes. Seetõttu pidime muutma taotlusi ja limite.

Leiti, et rakenduse puhul, mille mälu tarbimine kasvab aja jooksul, madalad väärtused taotluste (iga pod'i jaoks mälu reserveerimise) kombineerimisel 'lahke' jäiga limiidiga kasutamisele viisid sõlmede küllastumisele (küllastus) ja kõrgele väljutamise määrale. Selle probleemiga tegelemiseks otsustati suurendada taotlusi ja vähendada limite.. See tõi koormuse sõlmedelt maha ja tagas pod'ide elutsükli, mis ei avaldanud sõlmele liiga suurt survet. Nüüd alustame migreerimist heldete (ja peaaegu ühesuguste) nõudmiste ja limiitidega, kohandades neid vajaduse korral.

3. Näitajad ja logid

Infrastruktuuriüksus keskendub viivitustele, vigade protsendile ja küllastusele paigaldatud teenustaseme eesmärkidele (SLO), mis on seotud meie süsteemi üldise kättesaadavusega.

Viimase aasta jooksul oli infrastruktuuriüksuse jaoks üheks tähtsaks saavutuseks täiustused jälgimises ja SLO-dega töötamises. SLO-d võimaldasid meil seada eesmärke eraldi teenustele, mida me migreerimise ajal tähelepanelikult jälgisime. Kuid isegi sellise täiustatud jälgimisega ei pruugi me probleeme kohe märkida, kasutades näitajaid ja häireid. Näiteks keskendudes viivitustele ja vigade protsendile, ei hõlma me täielikult kõiki teenuse kasutamise stsenaariume, mis migreerivad.

See probleem avastati peaaegu kohe pärast osade töökoormuste üleviimist klastrisse. Erakordselt tõsiselt ilmnes see, kui tuli kontrollida funktsioone, mille arvamised olid väikesed, kuid millel olid väga spetsiifilised konfiguratsioonilised sõltuvused. Üks peamisi õppetunde pärast migreerimist oli vajadus jälgimisel arvesse võtta mitte ainult näitajaid, vaid ka logisid ja 'pikka saba' (räägime sellest nende jaotumisest graafikul — toim. tõl.) vigu. Nüüd sisaldab iga migreerimine üksikasjalikku logiküsimuste loendit (log queries) ja plaanime selged taasteprotseduurid, mida probleemide korral saab ülekanda ühe vahetuse käest teise.

Samaaegne sama päringu teenindamine vana VM-infrastruktuuri ja uue, Kubernetesel põhineva, esindas ainulaadset väljakutset. Erinevalt lift-and-shift tüüpi migreerimisest (rakenduste kiire üleviimine 'nagu on' uude infrastruktuuri; lähemalt saab lugeda näiteks, siin — toimetaja märkus), samaaegne töö „vana“ VM ja Kubernetes nõuab, et jälgimistööriistad oleksid ühilduvad mõlema keskkonnaga ja suudaksid ühendada metrikat ühte vaatesse. Oluline on, et me kasutame samu dashboard’e ja logiküsimusi, et saavutada järjepidev jälgitavus üleminekuperioodil.

4. Liikluse suunamine uuele klastrile

GitLab.com jaoks on osa serveritest eraldatud kanar Stage’i. Kanarapark teenindab meie sisemisi projekte ja võib kasutajate poolt kaasata. Kuid peamiselt on see ette nähtud infrastruktuuri ja rakenduste muudatuste testimiseks. Esimene viidatud teenus hakkas vastu võtma piiratud hulga sisest sissetulevat liiklust ja jätkame selle meetodi kasutamist, et veenduda SLO täitmises enne, kui suuname kogu liikluse klastrisse.

Migratsiooni puhul tähendab see, et kõigepealt suunatakse Kubernetesesse päringud sisemistele projektidele ja seejärel suuname järk-järgult ülejäänud liikluse klastrisse, muutes HAProxy kaudu tagaside kaalu. Üleminekul VM-ilt Kubernetesesse sai selgeks, et on väga mugav omada lihtsat viisi liikluse suunamiseks vana ja uue infrastruktuuri vahel ning hoida vana infrastruktuuri valmis tagasipöördeks esimestel päevadel pärast migratsiooni.

5. Pod’ide varuvõimsus ja nende kasutamine

Peaaegu kohe ilmnes järgmine probleem: Registry teenuse pod’id käivitusid kiiresti, kuid Sidekiqi pod’ide käivitamine võttis kuni kaks minutit. Pikem pod’ide käivitamine Sidekiqi jaoks muutus probleemiks, kui alustasime Kubernetesesse töökoormuste migreerimist töötlusprotsesside jaoks, mis peavad kiiresti töökohtadega toime tulema ja kiiresti skaleeruma.

Selles osas oli õppetund see, et kuigi Kuberneteses toimib Horisontaalne Pod Automaatautomaator (HPA) hästi liikluse kasvuga, on oluline arvesse võtta töökoormuste omadusi ja jaotada pod’ide varuressursse (eriti ebaühtlase nõudluse korral). Meie juhul esines äkiline töökohtade laine, mis nõudis kiiret skaleerimist, mis viis CPU ressursside küllastumiseni enne, kui jõudsime node'ide hulka skaleerida.

Alati on ahvatlev proovida klastrist võimalikult palju "välja pigistada", kuid me alustasime algselt, silmitsi seistes jõudlusprobleemidega, helde pod-eelarvega ja vähendame seda hiljem, jälgides tähelepanelikult SLO-d. Pod-ide käivitamine Sidekiq teenuse jaoks on märkimisväärselt kiireneb ja nüüd kestab keskmiselt umbes 40 sekundit. Pod-ide käivitamise aja lühendamine on kasu toonud nii GitLab.com-ile kui ka meie self-managed instalatsioonide kasutajatele, kes töötavad GitLabi ametliku Helm-chart'i abil.

Kokkuvõte

Iga teenuse migreerimise järel nautisime Kubernetes'e kasutamise eeliseid tootmises: rakenduse kiirem ja turvalisem juurutamine, skaleerimine ja tõhusam ressursijaotus. Samuti ulatuvad migratsiooni eelised kaugemale GitLab.com-ist. Iga ametliku Helm-chart'i täiustamisest saavad kasu ka selle kasutajad.

Loodan, et teile meeldis meie lugu seiklustest Kubernetes'e migreerimisega. Jätkame uute teenuste kolimist klastrisse. Lisainfot leiate järgmistest avaldustest: