Märge. tõlge: Kubernetese kasutuselevõttu GitLabis peetakse üheks kahest peamisest tegurist, mis aitavad kaasa ettevõtte kasvule. Kuid kuni viimase ajani ehitati GitLab.com võrguteenuse infrastruktuur virtuaalsetele masinatele ja alles umbes aasta tagasi algas selle migratsioon K8-dele, mis pole siiani lõppenud. Meil on hea meel esitada GitLabi SRE inseneri hiljutise artikli tõlge selle kohta, kuidas see juhtub ja milliseid järeldusi projektis osalevad insenerid teevad.
Juba umbes aasta on meie infrastruktuuriosakond viinud kõik GitLab.com-is töötavad teenused Kubernetesesse. Selle aja jooksul puutusime kokku väljakutsetega, mis olid seotud mitte ainult teenuste Kubernetesesse viimisega, vaid ka ülemineku ajal hübriidjuurutuse haldamisega. Väärtuslikke õppetunde, mida saime, arutatakse selles artiklis.
GitLab.com-i algusest peale töötasid selle serverid virtuaalsetes masinates pilves. Neid virtuaalmasinaid haldab Chef ja need installitakse meie abil . juhul, kui rakendust on vaja värskendada, seisneb lihtsalt serveripargi koordineeritud ja järjestikuses värskendamises CI konveieri abil. See meetod - kuigi aeglane ja natuke - tagab, et GitLab.com kasutab samu installi- ja konfigureerimisvõtteid nagu võrguühenduseta kasutajad (ise hallatav) GitLabi installid, kasutades selleks meie Linuxi pakette.
Me kasutame seda meetodit, kuna on äärmiselt oluline kogeda kõiki muresid ja rõõme, mida kogukonna tavaliikmed oma GitLabi koopiaid installides ja seadistades kogevad. See lähenemisviis töötas mõnda aega hästi, kuid kui GitLabi projektide arv ületas 10 miljonit, mõistsime, et see ei vasta enam meie skaleerimise ja juurutamise vajadustele.
Esimesed sammud Kubernetese ja pilvepõhise GitLabi poole
Projekt loodi 2017. aastal et valmistada GitLabi ette pilve juurutamiseks ja võimaldada kasutajatel installida GitLabi Kubernetese klastritesse. Teadsime siis, et GitLabi viimine Kubernetesesse suurendab SaaS-i platvormi skaleeritavust, lihtsustab juurutamist ja parandab arvutusressursside tõhusust. Samal ajal sõltusid paljud meie rakenduse funktsioonid ühendatud NFS-sektsioonidest, mis aeglustas üleminekut virtuaalmasinatest.
Tõuge pilvepõhise ja Kubernetese poole võimaldas meie inseneridel kavandada järkjärgulist üleminekut, mille käigus loobusime mõnest rakenduse sõltuvusest võrgusalvestusest, jätkates samal ajal uute funktsioonide väljatöötamist. Alates sellest, kui hakkasime 2019. aasta suvel migratsiooni planeerima, on paljud neist piirangutest lahendatud ja GitLab.com-i Kubernetesesse üleviimise protsess on nüüd hästi edenenud!
GitLab.com funktsioonid Kubernetesis
GitLab.com jaoks kasutame ühte piirkondlikku GKE klastrit, mis haldab kogu rakenduste liiklust. (Juba keerulise) migratsiooni keerukuse minimeerimiseks keskendume teenustele, mis ei sõltu kohalikust salvestusruumist ega NFS-ist. GitLab.com kasutab valdavalt monoliitset Rails-koodibaasi ja me suuname liikluse töökoormuse omaduste alusel erinevatesse lõpp-punktidesse, mis on eraldatud nende enda sõlmekogumitesse.
Esiliidese puhul jagunevad need tüübid päringuteks veebile, API-le, Git SSH/HTTPS-ile ja registrile. Taustaprogrammi puhul jagame järjekorras olevad tööd erinevate tunnuste järgi, olenevalt sellest , mis võimaldavad meil määrata erinevate töökoormuste jaoks teenusetaseme eesmärgid (SLO-d).
Kõik need GitLab.com-i teenused on konfigureeritud muutmata GitLabi Helmi diagrammi abil. Konfigureerimine toimub alamdiagrammides, mida saab valikuliselt lubada, kui viime teenuseid järk-järgult klastrisse. Kuigi otsustasime mõnda meie olekupõhist teenust, nagu Redis, Postgres, GitLab Pages ja Gitaly, migratsiooni mitte kaasata, võimaldab Kubernetese kasutamine radikaalselt vähendada Chefi praegu hallatavate VM-ide arvu.
Kubernetese konfiguratsiooni nähtavus ja haldamine
Kõiki seadeid haldab GitLab ise. Selleks kasutatakse kolme Terraformil ja Helmil põhinevat konfiguratsiooniprojekti. Proovime GitLabi käitamiseks võimalusel kasutada GitLabi ennast, kuid operatiivülesannete jaoks on meil eraldi GitLabi installimine. See on vajalik tagamaks, et te ei sõltu GitLab.com-i juurutamise ja värskenduste tegemisel GitLab.com-i saadavusest.
Kuigi meie Kubernetese klastri torujuhtmed töötavad eraldi GitLabi installiga, on koodihoidlate peeglid, mis on avalikult saadaval järgmistel aadressidel:
- — GitLab.com konfiguratsiooniraamistik GitLabi Helmi diagrammi jaoks;
- - Sisaldab konfiguratsioone teenuste jaoks, mis pole GitLabi rakendusega otseselt seotud. Nende hulka kuuluvad logimise ja klastri jälgimise konfiguratsioonid, samuti integreeritud tööriistad, nagu PlantUML;
- — Kubernetese ja VM-i pärandinfrastruktuuri terraformi konfiguratsioon. Siin saate konfigureerida kõik klastri käitamiseks vajalikud ressursid, sealhulgas klastri enda, sõlmede kogumid, teenusekontod ja IP-aadressi broneeringud.
Avalik vaade kuvatakse muudatuste tegemisel. lingiga üksikasjalikule erinevusele, mida SRE analüüsib enne klastris muudatuste tegemist.
SRE puhul viib link GitLabi installi üksikasjaliku erinevuseni, mida kasutatakse tootmiseks ja millele juurdepääs on piiratud. See võimaldab töötajatel ja kogukonnal ilma juurdepääsuta tööprojektile (mis on avatud ainult SRE-dele) vaadata kavandatud konfiguratsioonimuudatusi. Kombineerides koodi avaliku GitLabi eksemplari CI torujuhtmete privaatse eksemplariga, säilitame ühtse töövoo, tagades samas konfiguratsioonivärskenduste jaoks sõltumatuse GitLab.com-ist.
Mida me rände ajal teada saime
Kolimise käigus saadi kogemused, mida rakendame Kubernetes uutele migratsioonidele ja juurutustele.
1. Kättesaadavustsoonide vahelise liikluse tõttu suurenenud kulud
Git-hoidlapargi igapäevane väljapääsustatistika (baiti päevas) saidil GitLab.com
Google jagab oma võrgu piirkondadeks. Need omakorda on jagatud ligipääsetavuse tsoonideks (AZ). Git-hostimine on seotud suurte andmemahtudega, seega on meie jaoks oluline kontrollida võrgu väljapääsu. Siseliikluse puhul on väljapääs tasuta ainult siis, kui see jääb samasse saadavustsooni. Selle kirjutamise seisuga teenindame tavalise tööpäeva jooksul ligikaudu 100 TB andmeid (ja see on ainult Giti hoidlate jaoks). Teenused, mis asusid meie vanas VM-põhises topoloogias samades virtuaalmasinates, töötavad nüüd erinevates Kubernetese kaustades. See tähendab, et osa liiklusest, mis oli varem VM-i jaoks kohalik, võib potentsiaalselt liikuda saadavuse tsoonidest välja.
Piirkondlikud GKE klastrid võimaldavad koondada mitut saadavustsooni. Kaalume võimalust teenuste jaoks, mis tekitavad suurt liiklust. See vähendab väljumiskulusid, säilitades samal ajal klastri taseme koondamise.
2. Piirangud, ressursinõuded ja skaleerimine
Tootmisliiklust töötlevate koopiate arv saidil registry.gitlab.com. Liiklus tipphetk ~15:00 UTC.
Meie migratsioonilugu sai alguse 2019. aasta augustis, kui viisime oma esimese teenuse, GitLabi konteineriregistri, üle Kubernetesesse. See missioonikriitiline suure liiklusega teenus oli hea valik esimeseks migratsiooniks, kuna see on kodakondsuseta rakendus, millel on vähe väliseid sõltuvusi. Esimene probleem, millega me kokku puutusime, oli suur hulk sõlmede mälu puudumise tõttu välja tõstetud kaunasid. Seetõttu pidime taotlusi ja limiite muutma.
Avastati, et rakenduse puhul, kus mälutarbimine aja jooksul suureneb, viisid päringute madalad väärtused (mälu reserveerimine igale kaustale) koos „helde” range kasutuspiiranguga küllastumiseni. (küllastus) sõlmed ja väljatõstmiste kõrge tase. Selle probleemiga tegelemiseks oli . See võttis sõlmedelt surve maha ja tagas, et kaunadel on elutsükkel, mis ei avaldanud sõlmele liiga palju survet. Nüüd alustame migratsioone heldete (ja peaaegu identsete) taotluste ja piirväärtustega, kohandades neid vastavalt vajadusele.
3. Mõõdikud ja logid
Infrastruktuuri osakond keskendub latentsusele, veamääradele ja installitud küllastumisele (SLO) lingitud .
Viimase aasta jooksul on infrastruktuuri divisjoni üks võtmesündmusi olnud SLO-de järelevalve ja nendega töötamise täiustamine. SLO-d võimaldasid meil seada eesmärke üksikutele teenustele, mida migratsiooni ajal tähelepanelikult jälgisime. Kuid isegi selle parema jälgitavuse korral ei ole alati võimalik mõõdikute ja hoiatuste abil probleeme kohe näha. Näiteks latentsus- ja veamääradele keskendudes ei kata me täielikult kõiki migreeruva teenuse kasutusjuhtumeid.
See probleem avastati peaaegu kohe pärast mõne töökoormuse üleviimist klastrisse. See muutus eriti teravaks, kui pidime kontrollima funktsioone, mille päringute arv oli väike, kuid millel oli väga spetsiifiline konfiguratsioonisõltuvus. Üks migratsiooni põhilisi õppetunde oli vajadus võtta jälgimisel arvesse mitte ainult mõõdikuid, vaid ka logisid ja “pika saba” (see on umbes graafikul - u. tõlge.) vead. Nüüd lisame iga migratsiooni jaoks üksikasjaliku logipäringute loendi (logipäringud) ja kavandage selged tagasivõtmise protseduurid, mida saab probleemide ilmnemisel ühest vahetusest teise üle kanda.
Samade päringute paralleelne esitamine vanal VM-i infrastruktuuril ja uuel Kubernetese-põhisel infrastruktuuril oli ainulaadne väljakutse. Erinevalt lift-and-shift migratsioonist (rakenduste kiire ülekandmine "nagu on" uude infrastruktuuri; rohkem üksikasju saab lugeda näiteks - u. tõlge.), paralleelne töö "vanade" VM-ide ja Kubernetetega nõuab, et seiretööriistad ühilduksid mõlema keskkonnaga ja suudaksid ühendada mõõdikud ühte vaatesse. On oluline, et kasutaksime samu armatuurlaudu ja logipäringuid, et saavutada üleminekuperioodil ühtlane jälgitavus.
4. Liikluse ümberlülitamine uude klastrisse
GitLab.com jaoks on osa serveritest pühendatud . Canary Park teenindab meie siseprojekte ja saab ka . Kuid see on mõeldud peamiselt infrastruktuuri ja rakenduse muudatuste testimiseks. Esimene üleviidud teenus algas piiratud hulga siseliikluse vastuvõtmisega ja me jätkame selle meetodi kasutamist, et tagada SLO-de täitmine enne kogu liikluse klastrisse saatmist.
Migratsiooni puhul tähendab see seda, et siseprojektide päringud saadetakse esmalt Kubernetesile ja seejärel lülitame ülejäänud liikluse järk-järgult klastrisse, muutes HAProxy kaudu taustaprogrammi kaalu. VM-ilt Kubernetesesse migreerumisel sai selgeks, et väga kasulik on omada lihtsat viisi liiklust vana ja uue taristu vahel ümber suunata ning vastavalt sellele hoida vana taristu tagasipööramiseks valmis esimestel päevadel pärast migratsiooni.
5. Kaunade reservvõimsused ja nende kasutamine
Peaaegu kohe tuvastati järgmine probleem: registriteenuse kaustad käivitusid kiiresti, kuid Sidekiqi kaustade käivitamine võttis aega . Sidekiqi kaustade pikk käivitusaeg sai probleemiks, kui alustasime töökoormuste üleviimist Kubernetesse töötajatele, kes pidid töid kiiresti töötlema ja kiiresti skaleerima.
Antud juhul oli õppetund see, et kuigi Kubernetese Horizontal Pod Autoscaler (HPA) saab liikluse kasvuga hästi hakkama, on oluline arvestada töökoormuse iseärasusi ja eraldada kaustadele vaba võimsust (eriti kui nõudlus on ebaühtlaselt jaotunud). Meie puhul tekkis äkiline töökohtade arv, mis tõi kaasa kiire skaleerimise, mis viis protsessori ressursside küllastumiseni enne, kui meil oli aega sõlmede kogumit skaleerida.
Alati on kiusatus klastrist võimalikult palju välja pigistada, kuid kuna algselt on esinenud jõudlusprobleeme, alustame nüüd helde taskueelarvega ja vähendame seda hiljem, jälgides hoolikalt SLO-sid. Sidekiqi teenuse poodide käivitamine on märkimisväärselt kiirenenud ja võtab nüüd keskmiselt umbes 40 sekundit. võitis nii GitLab.com kui ka meie ametliku GitLabi Helmi diagrammiga töötavate isehallatavate installatsioonide kasutajad.
Järeldus
Pärast iga teenuse üleviimist rõõmustasime Kubernetese kasutamise eeliste üle tootmises: rakenduste kiirem ja turvalisem juurutamine, skaleerimine ja tõhusam ressursside jaotamine. Veelgi enam, migratsiooni eelised ulatuvad GitLab.com-i teenusest kaugemale. Iga ametliku Helmi diagrammi täiustus toob kasu selle kasutajatele.
Loodan, et teile meeldis meie Kubernetese rändeseikluste lugu. Jätkame kõigi uute teenuste üleviimist klastrisse. Lisateavet leiate järgmistest väljaannetest:
- «";
- «";
- .
PS tõlkijalt
Loe ka meie blogist:
- «";
- «";
- «";
- «'.
Allikas: www.habr.com