Märk. tõlge.: Kubernetes'i kohandamist GitLab'is peetakse üheks kahest peamisest tegurist, mis toetavad ettevõtte kasvu. Siiski oli kuni hiljuti GitLab.com online-teenuse infrastruktuur rajatud virtuaalmasinatele, ning alles umbes aasta tagasi algas selle kolimine K8s-i, mis pole siiani lõpetatud. Meil on hea meel tutvustada tõlget hiljutisest artiklist GitLab'i SRE-insenerilt selle kohta, kuidas see toimub ja milliseid järeldusi teevad projekti kaasatud insenerid.
Juba umbes aasta on meie infrastruktuuri osakond töötanud kõikide GitLab.com teenuste kolimisega Kubernetesesse. Selle aja jooksul oleme silmitsi seisnud probleemidega, mis on seotud mitte ainult teenuste liikumisega Kubernetesesse, vaid ka hübriidsete rakenduste haldamisega ülemineku ajal. Käesolevas artiklis arutame väärtuslikeks õppetunniteks saadud kogemusi.
Alates GitLab.com loomise algusest töötasid selle serverid pilves virtuaalmasinatel. Nende virtuaalmasinate haldamine toimub Chef'i kaudu ning nende paigaldamine toimub meie . juhul, kui rakendust tuleb uuendada, seisneb see serverite pargi lihtsas uuendamises kooskõlastatud järjestikku CI-toru kaudu. See meetod — kuigi aeglane ja natuke — tagab, et GitLab.com rakendab samu installimise ja konfigureerimise meetodeid nagu iseseisvad (iseseisvalt hallatavad) GitLab installatsioonid, kasutades meie Linuxi pakette.
Kasutame seda meetodit, sest on äärmiselt oluline kogeda kõiki nende hädasid ja rõõme, millega kogukonna liikmed seisavad silmitsi oma GitLabi koopiate installimise ja seadistamise ajal. See lähenemine on mõnda aega hästi toiminud, kuid kui GitLabis olevate projektide arv ületas 10 miljonit, mõistsime, et see ei rahulda enam meie skaleerimise ja juurutamise vajadusi.
Esimese sammu tegemine Kubernetesesse ja pilvepõhisesse GitLabi
2017. aastal loodi projekt et GitLabi valmistamiseks pilve juurutamiseks ning kasutajatele GitLabi Kubernetes klastritesse installimise võimaldamiseks. Toona teadsime, et GitLabi viimine Kubernetesesse suurendab SaaS-platvormi skaleeritavust, lihtsustab juurutusi ja parandab arvutusressursside tõhususe kasutamist. Samal ajal sõltusid meie rakenduse paljud funktsioonid mountitud NFS-osadest, mis aeglustas üleminekut virtuaalmasinatelt.
Soov cloud native'i ja Kubernetes'e suunas on võimaldanud meie inseneridel planeerida järkjärgulist üleminekut, mille käigus loobusime mõnest rakenduse sõltuvusest võrgu salvestustest, samal ajal arendades uusi funktsioone. Alates sellest, kui me hakkasime migratsiooni planeerima suvel 2019, on paljud neist piirangutest kõrvaldatud ja GitLab.com üleviimine Kubernetesesse on nüüd täie hooga käimas!
GitLab.com-i töö omadused Kuberneteses
GitLab.com-i jaoks kasutame ühte regioonipõhist GKE-klastrit, mis töötleb kogu rakenduse liiklust. Et vähendada (niigi keerulist) migreerimist, keskendume teenustele, mis ei sõltu kohalikust salvestusest või NFS-ist. GitLab.com kasutab peamiselt monoliitselt Rails'i koodibaasi ning suuname liikluse koormuse omaduste järgi erinevatele lõpp-punktidele, mis on isoleeritud omaenese sõlmpaikade basseinidesse.
Frontendi puhul jaguneb need tüübid veeb, API, Git SSH/HTTPS ja Registry päringuteks. Tagbackend'i puhul jagame töökohti järjekordades erinevate omaduste alusel, sõltuvalt , mis võimaldab meil kehtestada erinevate koormuste teenustaseme eesmärke (Service-Level Objectives, SLO-d).
Kõik need GitLab.com teenused on seadistatud modifitseerimata GitLab Helm-i graafiku abil. Konfiguratsioon toimub alamgraafikutes, mida saab valida järk-järgult teenuste viimiseks klastrisse. Isegi arvestades, et on otsustatud mitte kaasata migreerimisprotsessi mõned meie stateful-teenused, nagu Redis, Postgres, GitLab Pages ja Gitaly, võimaldab Kubernetes radikaalselt vähendada Chefile hallatavate VM-ide arvu.
Kubernetes'i läbipaistvus ja konfiguratsiooni haldamine
Kõik seadistused haldab ise GitLab. Selleks kasutatakse kolme Terraformi ja Helmi põhise konfiguratsiooniprojekti. Püüame kõikjal, kus võimalik, kasutada GitLab'i enda käitamiseks, kuid operatiivsete ülesannete jaoks töötab meil eraldi GitLab'i installatsioon. See on vajalik, et mitte sõltuda GitLab.com kättesaadavusest GitLab.com-i juurutuste ja värskenduste tegemisel.
Kuigi meie Kubernetes'i klastri torujuhtmed töötavad eraldi GitLab'i installatsioonil, on koodirepositoritel peeglid, mis on avalikult kättesaadavad järgmistel aadressidel:
- — GitLab.com Helm graafiku konfiguratsiooni vahekiht;
- — sisaldab konfektsioone teenustele, mis ei ole otseselt seotud GitLab rakendusega. Nende hulka kuuluvad logimise ja klastrite jälgimise konfektsioonid ning integreeritud tööriistade jaoks, nagu PlantUML;
- — Terraform konfigureerimine Kubernetes'e ja vana (legacy) VM-infrastruktuuri jaoks. Siin seadistatakse kõik ressursid, mis on vajalikud klastrite käivitamiseks, sealhulgas ise klaster, sõlmede basseinid, teenusekontod ja IP-aadresside varu.
Muudatuste tegemisel kuvatakse avalik viitega üksikasjalikule diffile, mida SRE analüüsib enne muudatuste tegemist klastris.
SRE jaoks viitavad lingid GitLabi installatsiooni üksikasjalikule diffile, mida kasutatakse kasutamiseks ja millele on juurdepääs piiratud. See võimaldab töötajatel ja kogukonnal, kellel pole juurdepääsu kasutusprojektile (mis on avatud ainult SRE-le), vaadata ettepanekuid konfiguratsiooni muudatusteks. Ühendades avaliku GitLabi koopia koodi jaoks ja suletud koopia CI-pipeline'ide jaoks, säilitame ühtse töövoo, samal ajal tagades sõltumatuse GitLab.com-ist konfiguratsiooni värskenduste puhul.
Mida oleme migratsiooni ajal avastanud
Kolimise käigus on saadud kogemusi, mida rakendame uutes migratsioonides ja Kubernetes'i kohaletoimetamistes.
1. Kulude kasv, mis on tingitud liiklusest erinevate kättesaadavuse tsoonide vahel
Igapäeva egress statistika (baidid päevas) GitLab.com-i Git-repositooriumide pargi kohta
Google jagab oma võrku piirkondadeks. Need jagunevad omakorda kättesaadavuse tsoonideks (AZ). Git-hostimine on seotud suurte andmemahudega, seetõttu on meie jaoks oluline kontrollida võrgu egressi. Sisemise liikluse korral on egress tasuta ainult juhul, kui see jääb ühe kättesaadavuse tsooni piiridesse. Käesoleva artikli kirjutamise hetkel edastame me tavalise tööpäeva jooksul umbes 100 TB andmeid (ja see on ainult Git-reposiitide jaoks). Teenused, mis meie vanas VM-põhises topoloogias asusid ühe ja sama virtuaalse masina peal, töötavad nüüd erinevates Kubernetes pod’ides. See tähendab, et teatud osa liiklusest, mis varem oli VM-ile lokaalne, võib potentsiaalselt ületada kättesaadavuse tsoonide piire.
Piirkondlikud GKE klastrid võimaldavad hõlmata mitmeid kättesaadavuse tsoone varundamiseks. Me arutame võimalust teenuste jaoks, mis genereerivad suuri andmemahte. See vähendab egressi kulusid samal ajal, kui säilitab klastritasemel varundamist.
2. Limit'id, ressursside päringud ja skaleerimine
registry.gitlab.com töötlemise tootmisliikluse repliikide arv. Liiklus saavutab haripunkti umbes 15:00 UTC.
Meie migratsiooni lugu algas 2019. aasta augustis, kui tõime esmakordselt teenuse — GitLabi konteineride registri — Kubernetesesse. See äärmiselt oluline ja suure liiklusega teenus sobis hästi esmaseks migratsiooniks, kuna see on stateless-rakendus, millel on vähe välist sõltuvust. Esimese probleemina koostasime suure hulga pod'e, mis olid välja astunud, kuna sõlmedel oli mälu nappus. Seetõttu pidime muutma request'e ja limit'e.
Leiti, et rakenduse puhul, mille mälu tarbimine kasvab ajas, madalad väärtused request'ides (mis reserveerivad mälu iga pod'i jaoks) koos "lahke" ranged limit'iga toimetamisele viisid küllastuseni (küllastus) sõlmedes ja kõrge väljakutsumise tasemeni. Selle probleemi lahendamiseks oli . See eemaldus koormust sõlmedelt ja tagas pod'ide elutsükli, mis ei avaldanud sõlmele liiga suurt survet. Nüüd alustame migreerimist heldete (ja peaaegu identsed) request'ide ja limit'idega, kohandades neid vastavalt vajadusele.
3. Mõõdikud ja logid
Infrastruktuuriüksus keskendub viivitustele, vigade protsentidele ja küllastusele seatud (SLO), mis on seotud .
Viimase aasta jooksul on infrastruktuuriüksuse üheks põhisündmuseks olnud parendused SLO jälgimisel ja haldamisel. SLO on võimaldanud meil seada eesmärke erinevatele teenustele, mida me jälgisime migratsiooni ajal. Kuid isegi täiustatud jälgimise korral ei ole alati võimalik kohe probleemide avastamine, kasutades mõõdikuid ja hoiatusteateid. Näiteks keskendudes viivitusele ja vigade protsentidele, ei kata me kõiki teenuse kasutamise stsenaariume, mis käivad migratsiooni läbi.
See probleem avastati peaaegu kohe pärast osade koormate üleviimist klastrisse. Eriti teravalt tuli see esile, kui tuli kontrollida funktsioone, mille päringute arv pole suur, kuid millel on väga spetsiifilised konfiguratsioonilised sõltuvused. Üks peamisi järeldusi migratsiooni tulemustest oli vajadus jälgimise käigus arvesse võtta mitte ainult mõõdikuid, vaid ka logisid ja "pikka saba". (rääkides diagrammil — tõlkija märkus.) vigu. Nüüd sisaldame iga migratsiooni jaoks detailset logipäringute loetelu (log queries) ja plaanime selged tagasikerimise protseduurid, mida probleemide korral saame vahetada üksteise vahetusprotsessis.
Sama päringute paralleelne teenindamine vanas VM-infrastruktuuris ja uues, Kubernetesel põhinevas, oli ainulaadne ülesanne. Erinevalt lift-and-shift tüüpi migratsioonist (rakenduste kiire üleviimine "nagu on" uude infrastruktuuri; rohkem teavet leiate näiteks — kt. tõlge), paralleelse töö „vanade” VM-ide ja Kubernetesega nõuab, et jälgimistööriistad oleksid mõlema keskkonnaga ühilduvad ja suudaksid mõõdikud üheks vaateks kokku tuua. Oluline on, et kasutame samu armatuurlauasid ja logiküsimusi, et tagada järjepidev nähtavus üleminekuperioodil.
4. Liiklus suunamine uuele klastrile
GitLab.com jaoks on osa serveritest eraldatud . Kanaripark toetab meie sisemisi projekte ja võib . Kuid esmajoones on see mõeldud infrastruktuurile ja rakendusele tehtud muudatuste testimiseks. Esimene üle viidud teenus hakkas vastu võtma piiratud hulga sisemist liiklust ning jätkame selle meetodi kasutamist, et veenduda SLO täitmises enne, kui suuname kogu liikluse klasstrisse.
Migratsiooni korral tähendab see, et Kubernetes suunab alguses päringud sisesüsteemide poole ja seejärel suuname järk-järgult ülejäänud liikluse klastrisse, muutes HAProxy kaudu tagapaneeli kaalu. VM-ilt Kubernetes'ile ülemineku käigus sai selgeks, et on kasulik omada lihtsat viisi liikluse suunamiseks vana ja uue infrastruktuuri vahel, hoides samas vana infrastruktuuri varuks mõneks päevaks pärast migreerimist.
5. Pod'ide varujõud ja nende kasutamine
Peaaegu kohe ilmus järgmine probleem: Registry teenuse pod'id käivitusid kiiresti, kuid Sidekiq pod'ide käivitamine kestis kuni . Sidekiq pod'ide pikaajaline käivitamine osutus probleemiks, kui hakkasime migreerima Kubernetes'i töökoormusi worker'itele, kes peavad kiiresti tööülesandeid töötlema ja kiiresti skaala muutma.
Sel juhul oli õppetund selles, et kuigi Horizontal Pod Autoscaler (HPA) Kuberneteses suudab hästi hakkama saada liikluseta, on oluline arvestada töökoormuse omadusi ja reserveerida pod'ide jaoks varuvõimsust (eriti nõudluse ebavõrdse jaotuse korral). Meie puhul täheldati äkilist job'ide hüpet, mis põhjustas kiire skaleerimise, viies CPU ressursside küllastuseni enne, kui me jõudsime sõlmede basseinide skaleerimist.
Alati on ahvatlus «välja pigistada» nii palju kui võimalik klastrist, kuid pärast esialgset jõudlusprobleemide kogemist alustame nüüd helde pod-eelarvega ja vähendame seda hiljem, jälgides hoolikalt SLO-d. Sidekiqi teenuse pod'ide käivitamine on märgatavalt kiirenud ja nüüd võtab keskmiselt aega umbes 40 sekundit. kasu on saanud nii GitLab.com kui ka meie iseseisvalt hallatavate paigalduste kasutajad, kes töötavad GitLabi ametliku Helm-chartiga.
Kokkuvõte
Iga teenuse migreerimise järel nautisime Kubernetes'i kasutamise eeliseid tootmises: rakenduste kiiremat ja turvalisemat juurutamist, skaleerimist ja tõhusamat ressursside jaotamist. Samuti ulatuvad migreerimise eelised kaugemale GitLab.com teenusest. Iga ametliku Helm-diagrammi täiustuse kasu saavad ka selle kasutajad.
Loodan, et teile meeldis meie seikluslugu Kubernetes'e migreerimise kohta. Jätkame uute teenuste üleviimist klastrisse. Lisainfot leiate järgmistest publikatsioonidest:
- «»;
- «»;
- .
P.S. tõlkija märkused
Lugege ka meie blogist:
- «»;
- «»;
- «»;
- «».
Allikas: habr.com
