Pozn. prekl.: adaptácia Kubernetes v GitLab je považovaná za jeden z dvoch hlavných faktorov prispievajúcich k rastu spoločnosti. Napriek tomu bola do nedávna infraštruktúra online služby GitLab.com postavená na virtuálnych strojoch a len pred približne rokom sa začala jej migrácia do K8s, ktorá stále nie je dokončená. S radosťou predstavujeme preklad nedávneho článku SRE inžiniera GitLab o tom, ako sa to deje a aké závery robia inžinieri zapojení do projektu.
Naše infraštruktúrne oddelenie sa už približne rok zaoberá migráciou všetkých služieb bežiacich na GitLab.com do Kubernetes. Počas tejto doby sme sa stretli s problémami súvisiacimi nielen s presunom služieb do Kubernetes, ale aj s riadením hybridného deploymentu počas prechodu. O cenných lekciách, ktoré sme sa naučili, bude reč v tomto článku.
Od samého začiatku GitLab.com jeho servery fungovali v cloude na virtuálnych strojoch. Tieto virtuálne stroje spravuje Chef a ich inštalácia prebieha pomocou nášho . v prípade, že je potrebné aktualizovať aplikáciu, spočíva v jednoduchom aktualizovaní parku serverov koordinovaným sekvenčným spôsobom prostredníctvom CI pipeline. Táto metóda — aj keď je pomalá a trochu — zaručuje, že GitLab.com aplikuje tie isté metódy inštalácie a konfigurácie, aké používajú užívatelia samostatných (self-managed) inštalácií GitLab, ktorí na to využívajú naše Linux balíky.
Túto metódu používame, pretože je nesmierne dôležité zažiť na vlastnej koži všetky trápenia a radosti, ktoré bežní členovia komunity zažívajú pri inštalácii a nastavení svojich kópií GitLab. Tento prístup fungoval dobre počas určitého času, avšak keď počet projektov na GitLab prekročil 10 miliónov, uvedomili sme si, že už nespĺňa naše potreby v oblasti škálovania a nasadenia.
Prvé kroky k Kubernetes a cloud-native GitLab
V roku 2017 bol založený projekt na prípravu GitLab na nasadenie v cloude a tiež na to, aby sme používateľom umožnili inštalovať GitLab do klastrov Kubernetes. Vtedy sme vedeli, že presun GitLab do Kubernetes zvýši možnosti škálovania SaaS platforiem, zjednoduší nasadenia a zvýši efektivitu využívania výpočtových zdrojov. Zároveň mnohé funkcie našej aplikácie záviseli od pripojených NFS oddielov, čo spomaľovalo prechod z virtuálnych strojov.
Túžba po cloud native a Kubernetes umožnila našim inžinierom plánovať postupný prechod, počas ktorého sme sa vzdali niektorých závislostí aplikácie od sieťových úložísk, pričom sme pokračovali v vývoji nových funkcií. Od začiatku plánovania migrácie v lete 2019 mnohé z týchto obmedzení boli odstránené a proces prevodu GitLab.com na Kubernetes teraz prebieha naplno!
Charakteristiky fungovania GitLab.com v Kubernetes
Pre GitLab.com používame jediný regionálny klaster GKE, ktorý spracováva celý prenos aplikácie. Aby sme minimalizovali zložitosti (už aj tak zložitým) migrácie, sústreďujeme sa na služby, ktoré nezávisia od lokálneho úložiska alebo NFS. GitLab.com prevažne používa monolitný kódový základ na Rails a smerujeme prenos v závislosti od charakteristík pracovnej záťaže na rôzne endpointy, izolované vo vlastných pooloch uzlov.
V prípade frontendu sa tieto typy delia na požiadavky na web, API, Git SSH/HTTPS a Registry. V prípade backendu rozdeľujeme joby v radách podľa rôznych charakteristík v závislosti od , ktoré nám umožňujú nastaviť ciele úrovne služieb (Service-Level Objectives, SLOs) pre rôzne záťaže.
Všetky tieto služby GitLab.com sú nastavené pomocou nemodifikovaného Helm chartu GitLab. Konfigurácia sa vykonáva v subchirtoch, ktoré môžu byť výberovo zahrnuté, keď postupne prenášame služby do klastera. Aj keď bolo rozhodnuté nezahŕňať do migrácie niektoré z našich stateful služieb, ako Redis, Postgres, GitLab Pages a Gitaly, použitie Kubernetes umožňuje radikálne znížiť počet VM, ktoré momentálne spravuje Chef.
Priehľadnosť a správa konfigurácie Kubernetes
Všetky nastavenia spravuje samotný GitLab. Na tento účel sa používajú tri konfiguračné projekty založené na Terraform a Helm. Snažíme sa všade, kde je to možné, využívať samotný GitLab na nasadenie GitLab, avšak pre prevádzkové úlohy máme fungujúcu samostatnú inštaláciu GitLab. Je potrebná na to, aby sme neboli závislí od dostupnosti GitLab.com pri vykonávaní nasadení a aktualizácií GitLab.com.
Aj keď naše pipeline pre klaster Kubernetes fungujú na samostatnej inštalácii GitLab, kódové repozitáre majú zrkadlá, ktoré sú verejne dostupné na nasledujúcich adresách:
- — konfiguračná väzba GitLab.com pre Helm chart GitLab;
- — obsahuje konfigurácie pre služby, ktoré nie sú priamo spojené s aplikáciou GitLab. Patrí sem konfigurácia pre správu logov a monitorovanie klastra, ako aj pre integrované nástroje ako PlantUML;
- — konfigurácia Terraform pre Kubernetes a starú (legacy) VM-infrastruktúru. Tu sa nastavujú všetky zdroje potrebné na spustenie klastra, vrátane samotného klastra, poolov uzlov, služobných účtov a rezervácie IP adries.
Pri vykonávaní zmien sa zobrazuje verejný s odkazom na podrobný diff, ktorý SRE analyzuje pred vykonaním zmien v klastri.
Pre SRE odkaz vedie na podrobný diff v inštalácii GitLab, ktorá sa používa na prevádzku a k ktorej je prístup obmedzený. To umožňuje zamestnancom a spoločnosti bez prístupu k prevádzkovému projektu (ten je otvorený len pre SRE) prezerať navrhované zmeny v konfigurácii. Spájaním verejného exemplára GitLab pre kód s uzavretým exemplárom pre CI pipeline zachovávame jednotný pracovný tok, pričom zaručujeme nezávislosť od GitLab.com pri aktualizáciách konfigurácie.
Čo sme zistili počas migrácie
Počas presunu sme získali skúsenosti, ktoré aplikujeme na nové migrácie a nasadenia v Kubernetes.
1. Rast nákladov kvôli prevádzke medzi zónami dostupnosti
Denná egress štatistika (bytov za deň) pre park Git úložísk na GitLab.com
Google rozdeľuje svoju sieť na regióny. Tieto sa následne delia na zóny dostupnosti (AZ). Git hosting súvisí s veľkým objemom dát, preto je pre nás dôležité kontrolovať sieťový egress. V prípade vnútorného prenosu je egress bezplatný len vtedy, ak zostáva v rámci jednej zóny dostupnosti. K zmomentu písania tohto článku prenášame približne 100 TB dát v bežný pracovný deň (a to len pre Git repozitáre). Služby, ktoré v našej starej topológii na báze VM boli na tých istých virtuálnych strojoch, teraz fungujú v rôznych podoch Kubernetes. To znamená, že určitá časť prenosu, ktorá bola predtým miestna pre VM, môže potenciálne prekročiť hranice zón dostupnosti.
Regionálne klastre GKE umožňujú pokrytie viacerých zón dostupnosti pre rezervácie. Zvažujeme pre služby, ktoré generujú veľké objemy prenosu. To pomôže znížiť náklady na egress pri zachovaní rezervácie na úrovni klastra.
2. Limity, požiadavky na zdroje a škálovanie
Počet replik spracovávajúcich produkčný prenos na registry.gitlab.com. Prenos dosahuje svoj vrchol okolo 15:00 UTC.
Naša história s migráciou sa začala v auguste 2019, keď sme presunuli prvú službu – registrovanie kontajnerov GitLab (GitLab Container Registry) – do Kubernetes. Táto kritická služba s vysokým prenosom sa dobre hodila na prvú migráciu, pretože ide o stateless aplikáciu s malým počtom vonkajších závislostí. Prvým problémom, s ktorým sme sa stretli, bolo veľké množstvo vytlačených podov z dôvodu nedostatku pamäte na uzloch. Z tohto dôvodu sme museli zmeniť požiadavky a limity.
Bolo zistené, že v prípade aplikácie, ktorej spotreba pamäte rastie s časom, nízke hodnoty pre požiadavky (vyčlenené na pamäť pre každý pod) spolu so "štědrým" tvrdým limitom na použitie vedli k saturácii (saturation) uzlov a k vysokému počtu vytlačení. Aby sme sa s týmto problémom vyrovnali, bolo . Toto znížilo tlak na uzly a zabezpečilo životný cyklus podov, ktorý nezvyšoval tlak na uzol. Teraz začíname migrácie s veľkorysými (a takmer rovnakými) hodnotami požiadaviek a limitov, ktoré podľa potreby upravujeme.
3. Metrix a logy
Infrastruktúrne oddelenie sa zameriava na oneskorenia, percento chýb a saturáciu s nastavenými (SLO), viazanými na .
V uplynulom roku sa jedným z kľúčových udalostí v infraštruktúrnom oddelení stali vylepšenia v monitorovaní a práci so SLO. SLO nám umožnili nastavovať ciele pre jednotlivé služby, ktoré sme starostlivo sledovali počas migrácie. Ale aj s takto vylepšenou viditeľnosťou nie vždy môžeme okamžite odhaliť problémy, používajúc metriky a upozornenia. Napríklad, zameraním sa na oneskorenia a percento chýb, úplne nezachytávame všetky scenáre používania služby, ktorá prechádza migráciou.
Tento problém bol objavený takmer okamžite po presune časti pracovných záťaží do clusteru. Najviac sa prejavil, keď bolo potrebné kontrolovať funkcie, počet požiadaviek na ktoré nie je vysoký, ale majú veľmi špecifické konfiguračné závislosti. Jedným z kľúčových ponaučení z migrácie bola potreba zohľadniť pri monitorovaní nielen metriky, ale aj logy a „dlhý chvost“ (týka sa to na grafe — pozn. prekl.) chýb. Teraz pre každú migráciu zahŕňame podrobný zoznam požiadaviek na logy (log queries) a plánujeme jasné postupy na vrátenie, ktoré môžeme v prípade problémov prenášať z jednej zmeny na druhú.
Paralelné spracovanie rovnakých požiadaviek na starej VM-infrastruktúre a novej, založenej na Kubernetes, predstavovalo jedinečnú úlohu. Na rozdiel od migrácie typu lift-and-shift (rýchly presun aplikácií „tak, ako sú“ do novej infraštruktúry; viac informácií si môžete prečítať napríklad, — pozn. prekl.), paralelné fungovanie na „starých“ VM a Kubernetes vyžaduje, aby nástroje na monitorovanie boli kompatibilné s oboma prostrediami a vedeli spojiť metriky do jedného zobrazenia. Je dôležité, že používame tie isté dashboardy a dopyty na logy, aby sme dosiahli konzistentnú observabilitu počas prechodného obdobia.
4. Prepnutie prevádzky na nový klaster
Pre GitLab.com je časť serverov vyčlenená na . Kanárkový park obsluhuje naše vnútorné projekty a môže sa . Predovšetkým je určený na testovanie zmien v infraštruktúre a aplikácii. Prvá prenesená služba začala s prijímaním obmedzeného objemu vnútorného prevádzky a naďalej používame túto metódu, aby sme sa uistili, že sa dodržiava SLO, predtým než nasmerujeme celú prevádzku do klastru.
V prípade migrácie to znamená, že najprv sú do Kubernetes smerované dopyty na vnútorné projekty a potom postupne prepíname na klaster zvyšok prevádzky zmenou váhy pre backend cez HAProxy. Počas prechodu z VM na Kubernetes sa ukázalo, že je veľmi výhodné mať po ruke jednoduchý spôsob presmerovania prevádzky medzi starou a novou infraštruktúrou a tým pádom udržiavať starú infraštruktúru pripravenú na návrat naspäť v priebehu prvých niekoľkých dní po migrácii.
5. Záložné kapacity podov a ich využitie
Takmer okamžite sa objavil nasledujúci problém: pod pre službu Registry sa spúšťali rýchlo, avšak spustenie podov pre Sidekiq trvalo až . Dlhé spúšťanie podov pre Sidekiq sa stalo problémom, keď sme začali migráciu pracovných zaťažení pre pracovníkov v Kubernetes, ktorí potrebujú rýchlo spracovávať joby a rýchlo sa škálovať.
V tomto prípade sa ponaučenie ukázalo tak, že hoci Horizontal Pod Autoscaler (HPA) v Kubernetes dobre zvláda rast prevádzky, je dôležité zohľadniť charakteristiky pracovných zaťažení a vyčleniť záložné kapacity podov (najmä v podmienkach nerovnomerného rozdelenia dopytu). V našom prípade došlo k náhlemu nárastu jobov, čo viedlo k rýchlemu škálovaniu, čo spôsobilo saturáciu CPU pred tým, než sme mali čas na škálovanie skupiny uzlov.
Vždy existuje pokušenie vyťažiť z klastru maximálne, avšak my, keď sme sa spočiatku stretli s problémami s výkonom, teraz začíname so štedrým rozpočtom pod a následne ho zmenšujeme, starostlivo sledujúc SLO. Spustenie podov pre službu Sidekiq sa výrazne zrýchlilo a teraz zvyčajne trvá okolo 40 sekúnd. tým profitovali ako GitLab.com, tak aj naši používatelia inštalácií self-managed, ktorí pracujú s oficiálnym Helm chartom GitLab.
Záver
Po presune každej služby sme sa tešili z výhod používania Kubernetes v produkcii: rýchlejšiemu a bezpečnejšiemu nasadeniu aplikácie, škálovaniu a efektívnejšiemu rozdeleniu zdrojov. Navyše sú výhody migrácie nad rámec služby GitLab.com. Z každého zlepšenia oficiálneho Helm chartu profitujú aj jeho používatelia.
Dúfam, že sa vám páčila naša história o našich dobrodružstvách s migráciou do Kubernetes. Pokračujeme v prenose nových služieb do klastru. Ďalšie informácie získate z nasledujúcich publikácií:
- «»;
- «»;
- .
P.S. od prekladateľa
Prečítajte si tiež na našom blogu:
- «»;
- «»;
- «»;
- «».
Zdroj: habr.com
