Poznámka. preklad.: Prijatie Kubernetes v GitLab sa považuje za jeden z dvoch hlavných faktorov, ktoré prispievajú k rastu spoločnosti. Infraštruktúra online služby GitLab.com bola však donedávna postavená na virtuálnych strojoch a len približne pred rokom sa začala jej migrácia na K8s, ktorá stále nie je dokončená. S potešením vám predstavujeme preklad nedávneho článku inžiniera GitLab SRE o tom, ako sa to deje a aké závery robia inžinieri zúčastňujúci sa na projekte.
Naša divízia infraštruktúry už približne rok migruje všetky služby bežiace na GitLab.com na Kubernetes. Počas tohto obdobia sme sa stretli s výzvami súvisiacimi nielen s presunom služieb do Kubernetes, ale aj so správou hybridného nasadenia počas prechodu. O hodnotných lekciách, ktoré sme sa naučili, sa bude diskutovať v tomto článku.
Od samého začiatku GitLab.com bežali jeho servery v cloude na virtuálnych strojoch. Tieto virtuálne stroje sú spravované šéfkuchárom a inštalované pomocou nášho . v prípade, že je potrebné aplikáciu aktualizovať, pozostáva z jednoduchej aktualizácie serverovej flotily koordinovaným a sekvenčným spôsobom pomocou CI potrubia. Táto metóda - aj keď pomalá a trochu - zabezpečuje, že GitLab.com používa rovnaké postupy inštalácie a konfigurácie ako offline používatelia (samoriadené) Inštalácie GitLab pomocou našich balíkov pre Linux.
Túto metódu používame, pretože je mimoriadne dôležité zažiť všetky strasti a radosti, ktoré zažívajú bežní členovia komunity pri inštalácii a konfigurácii svojich kópií GitLabu. Tento prístup istý čas fungoval dobre, ale keď počet projektov na GitLab prekročil 10 miliónov, uvedomili sme si, že už nevyhovuje našim potrebám škálovania a nasadenia.
Prvé kroky ku Kubernetes a cloudovému GitLabu
Projekt vznikol v roku 2017 pripraviť GitLab na cloudové nasadenie a umožniť používateľom inštalovať GitLab na klastroch Kubernetes. Vtedy sme vedeli, že presun GitLabu na Kubernetes zvýši škálovateľnosť platformy SaaS, zjednoduší nasadenia a zlepší efektivitu výpočtových zdrojov. Zároveň mnohé funkcie našej aplikácie záviseli od pripojených oddielov NFS, čo spomaľovalo prechod z virtuálnych strojov.
Posun smerom k natívnemu cloudu a Kubernetes umožnil našim inžinierom naplánovať postupný prechod, počas ktorého sme opustili niektoré závislosti aplikácie od sieťového úložiska a zároveň pokračovali vo vývoji nových funkcií. Odkedy sme začali plánovať migráciu v lete 2019, mnohé z týchto obmedzení boli vyriešené a proces migrácie GitLab.com na Kubernetes je teraz v plnom prúde!
Funkcie GitLab.com v Kubernetes
Pre GitLab.com používame jeden regionálny klaster GKE, ktorý spracováva všetku prevádzku aplikácií. Aby sme minimalizovali zložitosť (už aj tak zložitej) migrácie, zameriavame sa na služby, ktoré sa nespoliehajú na lokálne úložisko alebo NFS. GitLab.com používa prevažne monolitickú kódovú základňu Rails a prevádzku smerujeme na základe charakteristík pracovného zaťaženia do rôznych koncových bodov, ktoré sú izolované do vlastných oblastí 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 úlohy vo fronte podľa rôznych charakteristík v závislosti od , ktoré nám umožňujú nastaviť ciele na úrovni služieb (SLO) pre rôzne pracovné zaťaženia.
Všetky tieto služby GitLab.com sú nakonfigurované pomocou neupraveného grafu GitLab Helm. Konfigurácia sa vykonáva v podkartách, ktoré je možné selektívne povoliť pri postupnej migrácii služieb do klastra. Aj keď sme sa rozhodli nezahrnúť do migrácie niektoré z našich stavových služieb, ako sú Redis, Postgres, GitLab Pages a Gitaly, používanie Kubernetes nám umožňuje radikálne znížiť počet VM, ktoré Chef v súčasnosti spravuje.
Viditeľnosť 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. Na spustenie GitLabu sa snažíme používať samotný GitLab vždy, keď je to možné, ale pre prevádzkové úlohy máme samostatnú inštaláciu GitLab. Je to potrebné, aby ste sa uistili, že nie ste závislí od dostupnosti GitLab.com pri vykonávaní nasadení a aktualizácií GitLab.com.
Hoci naše kanály pre klaster Kubernetes bežia na samostatnej inštalácii GitLab, existujú zrkadlá úložísk kódu, ktoré sú verejne dostupné na nasledujúcich adresách:
- — Konfiguračný rámec GitLab.com pre graf GitLab Helm;
- - Obsahuje konfigurácie pre služby, ktoré nie sú priamo spojené s aplikáciou GitLab. Patria sem konfigurácie pre protokolovanie a monitorovanie klastrov, ako aj integrované nástroje ako PlantUML;
- — Konfigurácia Terraform pre Kubernetes a starú infraštruktúru virtuálnych počítačov. Tu nakonfigurujete všetky prostriedky potrebné na spustenie klastra vrátane samotného klastra, oblastí uzlov, servisných účtov a rezervácií adries IP.
Po vykonaní zmien sa zobrazí verejné zobrazenie. s odkazom na podrobný rozdiel, ktorý SRE analyzuje pred vykonaním zmien v klastri.
V prípade SRE vedie odkaz na podrobný rozdiel v inštalácii GitLab, ktorý sa používa na produkciu a prístup ku ktorému je obmedzený. To umožňuje zamestnancom a komunite bez prístupu k prevádzkovému projektu (ktorý je otvorený len pre SRE) zobraziť navrhované zmeny konfigurácie. Kombináciou verejnej inštancie GitLab pre kód so súkromnou inštanciou pre kanály CI udržiavame jednotný pracovný postup a zároveň zabezpečujeme nezávislosť od GitLab.com pre aktualizácie konfigurácie.
Čo sme zistili počas migrácie
Počas sťahovania sa získali skúsenosti, ktoré aplikujeme na nové migrácie a nasadenia v Kubernetes.
1. Zvýšené náklady v dôsledku dopravy medzi zónami dostupnosti
Denná štatistika výstupov (bajty za deň) pre flotilu úložiska Git na GitLab.com
Google rozdeľuje svoju sieť na regióny. Tie sú zase rozdelené do zón dostupnosti (AZ). Git hosting je spojený s veľkým množstvom dát, preto je pre nás dôležité kontrolovať výstup siete. Pre internú premávku je výstup voľný len vtedy, ak zostane v rovnakej zóne dostupnosti. V čase písania tohto článku poskytujeme približne 100 TB údajov za typický pracovný deň (a to len pre úložiská Git). Služby, ktoré sa nachádzali na rovnakých virtuálnych počítačoch v našej starej topológii založenej na VM, teraz bežia v rôznych moduloch Kubernetes. To znamená, že časť prevádzky, ktorá bola predtým lokálna pre VM, mohla potenciálne cestovať mimo zón dostupnosti.
Regionálne klastre GKE vám umožňujú pokryť viacero zón dostupnosti kvôli redundancii. Zvažujeme možnosť pre služby, ktoré generujú veľké objemy prevádzky. Tým sa znížia náklady na výstup pri zachovaní redundancie na úrovni klastra.
2. Limity, požiadavky na zdroje a škálovanie
Počet replík spracúvajúcich produkčnú prevádzku na stránke registry.gitlab.com. Premávka vrcholí o ~15:00 UTC.
Náš príbeh o migrácii sa začal v auguste 2019, keď sme migrovali našu prvú službu, register kontajnerov GitLab, do Kubernetes. Táto kritická služba s vysokou prevádzkou bola dobrou voľbou pre prvú migráciu, pretože ide o bezstavovú aplikáciu s niekoľkými externými závislosťami. Prvým problémom, na ktorý sme narazili, bol veľký počet vysťahovaných modulov z dôvodu nedostatku pamäte na uzloch. Z tohto dôvodu sme museli zmeniť požiadavky a limity.
Zistilo sa, že v prípade aplikácie, kde sa spotreba pamäte v priebehu času zvyšuje, nízke hodnoty požiadaviek (rezervácia pamäte pre každý modul) spolu so „štedrým“ pevným limitom využitia viedli k saturácii. (sýtosť) uzly a vysoký stupeň vysťahovania. Na zvládnutie tohto problému to bolo . Tým sa znížil tlak na uzly a zabezpečilo sa, že moduly mali životný cyklus, ktorý nevyvíjal na uzol príliš veľký tlak. Teraz začneme migrácie s veľkorysými (a takmer identickými) požiadavkami a limitnými hodnotami a upravíme ich podľa potreby.
3. Metriky a protokoly
Divízia infraštruktúry sa zameriava na latenciu, chybovosť a saturáciu nainštalovanou (SLO) prepojené s .
Za posledný rok bolo jednou z kľúčových udalostí v divízii infraštruktúry zlepšenie monitorovania a práce s SLO. SLO nám umožnili nastaviť ciele pre jednotlivé služby, ktoré sme počas migrácie pozorne sledovali. Ale aj s touto vylepšenou pozorovateľnosťou nie je vždy možné okamžite vidieť problémy pomocou metrík a upozornení. Napríklad tým, že sa zameriame na latenciu a chybovosť, nepokryjeme úplne všetky prípady použitia služby, ktorá prechádza migráciou.
Tento problém bol objavený takmer okamžite po migrácii niektorých pracovných zaťažení do klastra. Obzvlášť akútne sa to stalo, keď sme museli kontrolovať funkcie, pre ktoré bol počet požiadaviek malý, ale ktoré mali veľmi špecifické konfiguračné závislosti. Jedným z kľúčových ponaučení z migrácie bola potreba brať pri monitorovaní do úvahy nielen metriky, ale aj protokoly a „long tail“ (ide o na grafe - cca. preklad.) chyby. Teraz pre každú migráciu uvádzame podrobný zoznam dotazov na protokol (dotazy denníka) a naplánovať jasné postupy vrátenia, ktoré možno preniesť z jednej zmeny na ďalšiu, ak sa vyskytnú problémy.
Podávanie rovnakých požiadaviek paralelne na starej infraštruktúre VM a novej infraštruktúre založenej na Kubernetes predstavovalo jedinečnú výzvu. Na rozdiel od migrácie typu lift-and-shift (rýchly prenos aplikácií „tak, ako sú“ do novej infraštruktúry; viac podrobností si môžete prečítať napr. - približne. preklad.), paralelná práca na „starých“ VM a Kubernetes vyžaduje, aby monitorovacie nástroje boli kompatibilné s oboma prostrediami a aby boli schopné kombinovať metriky do jedného zobrazenia. Je dôležité, aby sme počas prechodného obdobia používali rovnaké informačné panely a protokolové dotazy, aby sme dosiahli konzistentnú pozorovateľnosť.
4. Prepnutie prevádzky do nového klastra
Pre GitLab.com je časť serverov vyhradená . Canary Park slúži našim interným projektom a môže tiež . Primárne je však určený na testovanie zmien vykonaných v infraštruktúre a aplikácii. Prvá migrovaná služba začala prijatím obmedzeného množstva internej prevádzky a naďalej používame túto metódu, aby sme zabezpečili splnenie SLO pred odoslaním všetkej návštevnosti do klastra.
V prípade migrácie to znamená, že požiadavky na interné projekty sa posielajú najskôr do Kubernetes a potom postupne prepíname zvyšok prevádzky do klastra zmenou váhy pre backend cez HAProxy. Počas migrácie z VM na Kubernetes sa ukázalo, že je veľmi výhodné mať jednoduchý spôsob presmerovania prevádzky medzi starou a novou infraštruktúrou, a teda udržiavať starú infraštruktúru pripravenú na rollback v prvých dňoch po migrácii.
5. Rezervné kapacity strukov a ich využitie
Takmer okamžite bol identifikovaný nasledujúci problém: moduly pre službu Registry sa spustili rýchlo, ale spúšťanie modulov pre Sidekiq trvalo . Dlhý čas spustenia modulov Sidekiq sa stal problémom, keď sme začali migrovať pracovné zaťaženie na Kubernetes pre pracovníkov, ktorí potrebovali rýchlo spracovať úlohy a rýchlo sa škálovať.
V tomto prípade z toho bolo ponaučenie, že aj keď Horizontal Pod Autoscaler (HPA) od Kubernetes zvláda rast návštevnosti dobre, je dôležité zvážiť charakteristiky pracovného zaťaženia a prideliť voľnú kapacitu modulom (najmä keď je dopyt nerovnomerne rozdelený). V našom prípade došlo k náhlemu nárastu úloh, čo viedlo k rýchlemu škálovaniu, čo viedlo k nasýteniu zdrojov CPU skôr, ako sme stihli škálovať fond uzlov.
Vždy existuje pokušenie vyžmýkať z klastra čo najviac, ale keďže sme na začiatku narazili na problémy s výkonom, začíname s veľkorysým rozpočtom na moduly a neskôr ho znižujeme, pričom pozorne sledujeme SLO. Spustenie modulov pre službu Sidekiq sa výrazne zrýchlilo a teraz trvá v priemere asi 40 sekúnd. vyhral GitLab.com aj našich používateľov samoriadených inštalácií pracujúcich s oficiálnym grafom GitLab Helm.
Záver
Po migrácii každej služby sme sa tešili z výhod používania Kubernetes v produkcii: rýchlejšie a bezpečnejšie nasadenie aplikácií, škálovanie a efektívnejšie prideľovanie zdrojov. Výhody migrácie navyše presahujú rámec služby GitLab.com. Každé vylepšenie oficiálneho rebríčka Helm prináša výhody jeho používateľom.
Dúfam, že sa vám páčil príbeh našich dobrodružstiev v oblasti migrácie Kubernetes. Pokračujeme v migrácii všetkých nových služieb do klastra. Ďalšie informácie možno nájsť v nasledujúcich publikáciách:
- «»;
- «»;
- .
PS od prekladateľa
Prečítajte si aj na našom blogu:
- «»;
- «»;
- «»;
- «".
Zdroj: hab.com