Athugið. þýð.: Innleiðing Kubernetes hjá GitLab er talinn einn af tveimur meginþáttum sem stuðla að vexti fyrirtækisins. Hins vegar, þar til nýlega, voru innviðir GitLab.com netþjónustunnar byggðir á sýndarvélum og aðeins um ári síðan hófst flutningur hennar yfir í K8s, sem er enn ekki lokið. Það er okkur ánægja að kynna þýðingu á nýlegri grein eftir GitLab SRE verkfræðing um hvernig þetta gerist og hvaða ályktanir verkfræðingarnir sem taka þátt í verkefninu gera.
Í um það bil ár hefur innviðadeildin okkar verið að flytja alla þjónustu sem keyrir á GitLab.com til Kubernetes. Á þessum tíma lentum við í áskorunum sem tengdust ekki aðeins því að flytja þjónustu til Kubernetes, heldur einnig við að stjórna blendingunni við umskiptin. Fjallað verður um dýrmæta lexíuna sem við lærðum í þessari grein.
Frá upphafi GitLab.com keyrðu netþjónar þess í skýinu á sýndarvélum. Þessum sýndarvélum er stjórnað af Chef og settar upp með því að nota okkar . ef uppfæra þarf forritið, samanstendur það einfaldlega af því að uppfæra netþjónaflotann á samræmdan hátt í röð með því að nota CI leiðslu. Þessi aðferð - þó hæg og smá - tryggir að GitLab.com noti sömu uppsetningar- og uppsetningaraðferðir og notendur án nettengingar (sjálfstýrt) GitLab uppsetningar með því að nota Linux pakkana okkar fyrir þetta.
Við notum þessa aðferð vegna þess að það er afar mikilvægt að upplifa alla þá sorg og gleði sem venjulegir meðlimir samfélagsins upplifa þegar þeir setja upp og stilla eintök sín af GitLab. Þessi nálgun virkaði vel í nokkurn tíma, en þegar fjöldi verkefna á GitLab fór yfir 10 milljónir, áttuðum við okkur á því að það uppfyllti ekki lengur þarfir okkar fyrir stigstærð og dreifingu.
Fyrstu skrefin til Kubernetes og skýjaættaðs GitLab
Verkefnið var stofnað árið 2017 til að undirbúa GitLab fyrir skýjadreifingu og gera notendum kleift að setja upp GitLab á Kubernetes klösum. Við vissum þá að flutningur GitLab til Kubernetes myndi auka sveigjanleika SaaS vettvangsins, einfalda uppsetningu og bæta skilvirkni tölvuauðlinda. Á sama tíma voru margar aðgerðir forritsins okkar háðar uppsettum NFS skiptingum, sem hægði á umskiptum frá sýndarvélum.
Þrýstingin í átt að skýjum og Kubernetes gerði verkfræðingum okkar kleift að skipuleggja smám saman umskipti, þar sem við yfirgáfum sumt af því sem forritið er háð netgeymslu á meðan við héldum áfram að þróa nýja eiginleika. Frá því að við byrjuðum að skipuleggja flutninginn sumarið 2019 hefur mörgum af þessum takmörkunum verið leyst og ferlið við að flytja GitLab.com til Kubernetes er nú komið vel af stað!
Eiginleikar GitLab.com í Kubernetes
Fyrir GitLab.com notum við einn svæðisbundinn GKE þyrping sem sér um alla umsóknarumferð. Til að lágmarka flókið (nú þegar erfiður) flutningurinn, leggjum við áherslu á þjónustu sem ekki treysta á staðbundna geymslu eða NFS. GitLab.com notar aðallega einhæfan Rails kóðagrunn og við beinum umferð út frá vinnuálagseiginleikum til mismunandi endapunkta sem eru einangraðir í þeirra eigin hnútapott.
Þegar um framenda er að ræða er þessum tegundum skipt í beiðnir til vefs, API, Git SSH/HTTPS og Registry. Þegar um er að ræða bakendann skiptum við störfunum í biðröðinni eftir ýmsum eiginleikum eftir því , sem gera okkur kleift að setja þjónustustigsmarkmið (SLOs) fyrir ýmiss konar vinnuálag.
Allar þessar GitLab.com þjónustur eru stilltar með því að nota óbreytt GitLab Helm töflu. Stillingar eru framkvæmdar í undirtöflum, sem hægt er að virkja með vali þegar við flytjum þjónustu smám saman yfir í klasann. Jafnvel þó við ákváðum að taka ekki hluta af staðbundinni þjónustu okkar inn í flutninginn, eins og Redis, Postgres, GitLab Pages og Gitaly, þá gerir notkun Kubernetes okkur kleift að fækka verulega fjölda VM sem Chef stýrir nú.
Sýnileiki og stjórnun Kubernetes stillingar
Öllum stillingum er stjórnað af GitLab sjálfu. Til þess eru notuð þrjú stillingarverkefni byggð á Terraform og Helm. Við reynum að nota GitLab sjálft þegar mögulegt er til að keyra GitLab, en fyrir rekstrarverkefni höfum við sérstaka GitLab uppsetningu. Þetta er nauðsynlegt til að tryggja að þú sért ekki háður framboði á GitLab.com þegar þú framkvæmir GitLab.com uppfærslur og uppfærslur.
Þrátt fyrir að leiðslur okkar fyrir Kubernetes klasann keyri á sérstakri GitLab uppsetningu, þá eru speglar af kóðageymslunum sem eru almennt aðgengilegar á eftirfarandi heimilisföngum:
- — GitLab.com stillingaramma fyrir GitLab Helm töfluna;
- - Inniheldur stillingar fyrir þjónustu sem eru ekki beint tengdar GitLab forritinu. Þetta felur í sér stillingar fyrir skógarhögg og klasavöktun, auk samþættra verkfæra eins og PlantUML;
- — Terraform stillingar fyrir Kubernetes og eldri VM innviði. Hér stillir þú öll tilföng sem nauðsynleg eru til að keyra klasann, þar á meðal klasann sjálfan, hnútahópa, þjónustureikninga og IP-tölu frátekningar.
Opinber sýn er sýnd þegar breytingar eru gerðar. með tengli á ítarlega mismun sem SRE greinir áður en breytingar eru gerðar á klasanum.
Fyrir SRE leiðir hlekkurinn til ítarlegrar mismunar í GitLab uppsetningunni, sem er notuð til framleiðslu og aðgangur að henni er takmarkaður. Þetta gerir starfsmönnum og samfélaginu kleift, án aðgangs að rekstrarverkefninu (sem er aðeins opið SRE), að skoða fyrirhugaðar breytingar á stillingum. Með því að sameina opinbert GitLab tilvik fyrir kóða með einkatilviki fyrir CI leiðslur, höldum við einu verkflæði á sama tíma og við tryggjum sjálfstæði frá GitLab.com fyrir uppfærsluuppfærslur.
Það sem við komumst að við flutninginn
Við flutninginn fékkst reynsla af því að við sækjum um nýja flutninga og dreifingu í Kubernetes.
1. Aukinn kostnaður vegna umferðar milli framboðssvæða
Dagleg útgöngutölfræði (bæt á dag) fyrir Git geymsluflotan á GitLab.com
Google skiptir neti sínu í svæði. Þeim er aftur á móti skipt í aðgengissvæði (AZ). Git hýsing er tengd miklu magni af gögnum, svo það er mikilvægt fyrir okkur að stjórna útgöngu netsins. Fyrir innri umferð er útgangur aðeins ókeypis ef hún er innan sama framboðssvæðis. Þegar þetta er skrifað erum við að þjóna um það bil 100 TB af gögnum á venjulegum vinnudegi (og það er bara fyrir Git geymslur). Þjónusta sem var í sömu sýndarvélunum í gömlu VM byggða svæðisfræðinni okkar keyrir nú í mismunandi Kubernetes belg. Þetta þýðir að einhver umferð sem áður var staðbundin fyrir VM gæti hugsanlega ferðast utan framboðssvæða.
Svæðisbundnir GKE klasar gera þér kleift að spanna mörg framboðssvæði fyrir offramboð. Við erum að íhuga möguleikann fyrir þjónustu sem skapar mikla umferð. Þetta mun draga úr útgöngukostnaði en viðhalda offramboði á klasastigi.
2. Takmörk, auðlindabeiðnir og mælikvarði
Fjöldi eftirmynda sem vinna framleiðsluumferð á registry.gitlab.com. Umferð nær hámarki klukkan ~15:00 UTC.
Flutningasaga okkar hófst í ágúst 2019, þegar við fluttum fyrstu þjónustu okkar, GitLab Container Registry, til Kubernetes. Þessi mikilvæga þjónusta með mikla umferð var góður kostur fyrir fyrstu flutninginn vegna þess að það er ríkisfangslaust forrit með fáum ytri ósjálfstæði. Fyrsta vandamálið sem við lentum í var mikill fjöldi útskúfaðra fræbelgja vegna skorts á minni á hnútunum. Vegna þessa þurftum við að breyta beiðnum og takmörkunum.
Það kom í ljós að þegar um er að ræða forrit þar sem minnisnotkun eykst með tímanum, leiddu lág gildi fyrir beiðnir (geymir minni fyrir hverja belg) ásamt „örlátum“ harðri notkunartakmörkunum til mettunar (mettun) hnúta og mikið magn af brottrekstri. Til að takast á við þetta vandamál var það . Þetta tók þrýstinginn af hnútunum og tryggði að belgirnir hefðu líftíma sem setti ekki of mikinn þrýsting á hnútinn. Nú hefjum við flutninga með rausnarlegum (og næstum eins) beiðnum og viðmiðunarmörkum og stillum þau eftir þörfum.
3. Mælingar og logs
Innviðasvið leggur áherslu á leynd, villuhlutfall og mettun með uppsettum (SLO) tengdur við .
Síðastliðið ár hefur einn af lykilatburðum innviðasviðs verið endurbætur á eftirliti og vinnu með SLO. SLOs leyfðu okkur að setja markmið fyrir einstaka þjónustu sem við fylgdumst vel með meðan á flutningnum stóð. En jafnvel með þessum bætta athugunarhæfni er ekki alltaf hægt að sjá strax vandamál með því að nota mæligildi og viðvaranir. Til dæmis, með því að einblína á leynd og villuhlutfall, náum við ekki að fullu yfir öll notkunartilvik fyrir þjónustu sem er í flutningi.
Þetta vandamál uppgötvaðist nánast strax eftir að sumt vinnuálag var flutt yfir í þyrpinguna. Það varð sérstaklega bráð þegar við þurftum að athuga aðgerðir þar sem fjöldi beiðna var lítill, en sem höfðu mjög sérstakar stillingarháðar. Einn helsti lærdómurinn af flutningnum var nauðsyn þess að taka ekki aðeins tillit til mælikvarða við vöktun, heldur einnig annála og „langa hala“ (þetta snýst um á töflunni - ca. þýðing.) villur. Nú fyrir hverja flutning erum við með ítarlegan lista yfir annálafyrirspurnir (logga fyrirspurnir) og skipuleggja skýrar verklagsreglur um afturköllun sem hægt er að flytja frá einni vakt yfir á aðra ef vandamál koma upp.
Að þjóna sömu beiðnum samhliða á gamla VM innviðina og nýja Kubernetes byggt innviði var einstakt áskorun. Ólíkt lyftu-og-vaktaflutningi (fljótur flutningur á forritum „eins og er“ yfir í nýjan innviði; nánari upplýsingar má lesa, td. - ca. þýðing.), samhliða vinna á „gömlum“ VM og Kubernetes krefst þess að eftirlitsverkfæri séu samhæf við bæði umhverfi og geti sameinað mælikvarða í eina sýn. Það er mikilvægt að við notum sömu mælaborð og annálafyrirspurnir til að ná stöðugum sýnileika á umbreytingartímabilinu.
4. Skipta umferð yfir í nýjan klasa
Fyrir GitLab.com er hluti netþjónanna tileinkaður . Canary Park þjónar innri verkefnum okkar og getur líka . En það er fyrst og fremst hannað til að prófa breytingar sem gerðar eru á innviðum og notkun. Fyrsta flutta þjónustan byrjaði á því að samþykkja takmarkað magn af innri umferð og við höldum áfram að nota þessa aðferð til að tryggja að SLOs séu uppfyllt áður en öll umferð er send í klasann.
Þegar um er að ræða flutning þýðir þetta að beiðnir um innri verkefni eru sendar til Kubernetes fyrst og síðan skiptum við smám saman restinni af umferðinni yfir í þyrpinguna með því að breyta þyngd bakendans í gegnum HAProxy. Við flutninginn frá VM til Kubernetes kom í ljós að það var mjög hagkvæmt að hafa auðvelda leið til að beina umferð á milli gamla og nýja innviða og, í samræmi við það, halda gömlu innviðunum tilbúnum til afturköllunar fyrstu dagana eftir flutninginn.
5. Varageta fræbelgja og notkun þeirra
Næstum strax kom eftirfarandi vandamál í ljós: belg fyrir Registry þjónustuna fóru fljótt í gang, en ræsing belg fyrir Sidekiq tók allt að . Langur ræsingartími Sidekiq-belgja varð vandamál þegar við byrjuðum að flytja vinnuálag til Kubernetes fyrir starfsmenn sem þurftu að vinna úr verkum hratt og stækka hratt.
Í þessu tilviki var lærdómurinn sá að á meðan Horizontal Pod Autoscaler (HPA) frá Kubernetes höndli vel umferðarvöxt, þá er mikilvægt að huga að eiginleikum vinnuálagsins og úthluta aukagetu til belganna (sérstaklega þegar eftirspurn er ójafnt dreift). Í okkar tilviki varð skyndileg aukning í störfum, sem leiddi til hraðrar mælingar, sem leiddi til mettunar á CPU auðlindum áður en við höfðum tíma til að skala hnútapottinn.
Það er alltaf freisting til að kreista eins mikið og mögulegt er út úr klasa, en eftir að hafa lent í frammistöðuvandamálum í upphafi, erum við nú að byrja með rausnarlegt fjárhagkerfi og draga úr því síðar og fylgjast vel með SLOs. Hraða hefur verið verulega á kynningu á belgjum fyrir Sidekiq þjónustuna og tekur nú um 40 sekúndur að meðaltali. vann bæði GitLab.com og notendur okkar á sjálfstýrðum uppsetningum sem vinna með opinbera GitLab Helm töfluna.
Ályktun
Eftir að hafa flutt hverja þjónustu, fögnuðum við ávinningi þess að nota Kubernetes í framleiðslu: hraðari og öruggari uppsetning forrita, stærðarstærð og skilvirkari auðlindaúthlutun. Þar að auki fara kostir fólksflutninga út fyrir GitLab.com þjónustuna. Sérhver umbót á opinberu Helm töflunni kemur notendum sínum til góða.
Ég vona að þú hafir haft gaman af sögunni um Kubernetes fólksflutningaævintýri okkar. Við höldum áfram að flytja alla nýja þjónustu í klasann. Frekari upplýsingar er að finna í eftirfarandi ritum:
- «»;
- «»;
- .
PS frá þýðanda
Lestu líka á blogginu okkar:
- «»;
- «»;
- «»;
- «'.
Heimild: www.habr.com