Poznámka. přel.: Přijetí Kubernetes na GitLab je považováno za jeden ze dvou hlavních faktorů přispívajících k růstu společnosti. Infrastruktura online služby GitLab.com však byla donedávna postavena na virtuálních strojích a teprve zhruba před rokem začala její migrace na K8s, která stále není dokončena. S potěšením představujeme překlad nedávného článku inženýra GitLab SRE o tom, jak se to děje a jaké závěry dělají inženýři účastnící se projektu.
Naše infrastrukturní divize již zhruba rok migruje všechny služby běžící na GitLab.com na Kubernetes. Během této doby jsme se setkali s problémy souvisejícími nejen s přesunem služeb na Kubernetes, ale také se správou hybridního nasazení během přechodu. Cenné lekce, které jsme se naučili, budou popsány v tomto článku.
Od samého počátku GitLab.com běžely jeho servery v cloudu na virtuálních strojích. Tyto virtuální stroje jsou spravovány Chefem a instalovány pomocí našeho . v případě, že je třeba aplikaci aktualizovat, spočívá v prosté aktualizaci serverové flotily koordinovaným a sekvenčním způsobem pomocí kanálu CI. Tato metoda - i když pomalá a trochu - zajišťuje, že GitLab.com používá stejné postupy instalace a konfigurace jako offline uživatelé (samoobslužný) Instalace GitLab pomocí našich linuxových balíčků k tomu.
Tuto metodu používáme, protože je nesmírně důležité zažít všechny strasti a radosti, které prožívají běžní členové komunity při instalaci a konfiguraci svých kopií GitLabu. Tento přístup nějakou dobu dobře fungoval, ale když počet projektů na GitLabu přesáhl 10 milionů, zjistili jsme, že již nevyhovuje našim potřebám škálování a nasazení.
První kroky ke Kubernetes a cloudovému GitLabu
Projekt vznikl v roce 2017 připravit GitLab na cloudové nasazení a umožnit uživatelům instalovat GitLab na clustery Kubernetes. Tehdy jsme věděli, že přesun GitLabu na Kubernetes zvýší škálovatelnost platformy SaaS, zjednoduší nasazení a zlepší efektivitu výpočetních zdrojů. Mnoho funkcí naší aplikace přitom záviselo na připojených NFS oddílech, což zpomalovalo přechod z virtuálních strojů.
Posun směrem k nativní cloudu a Kubernetes umožnil našim inženýrům naplánovat postupný přechod, během kterého jsme opustili některé závislosti aplikace na síťovém úložišti a zároveň pokračovali ve vývoji nových funkcí. Od doby, kdy jsme v létě 2019 začali plánovat migraci, bylo mnoho z těchto omezení vyřešeno a proces migrace GitLab.com na Kubernetes je nyní v plném proudu!
Funkce GitLab.com v Kubernetes
Pro GitLab.com používáme jeden regionální cluster GKE, který zpracovává veškerý provoz aplikací. Abychom minimalizovali složitost (již tak složité) migrace, zaměřujeme se na služby, které nespoléhají na místní úložiště nebo NFS. GitLab.com používá převážně monolitickou kódovou základnu Rails a provoz směrujeme na základě charakteristik pracovního zatížení do různých koncových bodů, které jsou izolovány do vlastních fondů uzlů.
V případě frontendu se tyto typy dělí na požadavky na web, API, Git SSH/HTTPS a Registry. V případě backendu rozdělujeme úlohy ve frontě podle různých charakteristik v závislosti na , které nám umožňují nastavit cíle úrovně služeb (SLO) pro různé pracovní zátěže.
Všechny tyto služby GitLab.com jsou konfigurovány pomocí neupraveného grafu GitLab Helm. Konfigurace se provádí v podgrafech, které lze selektivně povolit, jak postupně migrujeme služby do clusteru. I když jsme se rozhodli do migrace nezahrnout některé naše stavové služby, jako jsou Redis, Postgres, GitLab Pages a Gitaly, používání Kubernetes nám umožňuje radikálně snížit počet virtuálních počítačů, které Chef aktuálně spravuje.
Viditelnost a správa konfigurace Kubernetes
Všechna nastavení spravuje samotný GitLab. K tomu slouží tři konfigurační projekty založené na Terraform a Helm. Snažíme se používat ke spuštění GitLab samotný GitLab, kdykoli je to možné, ale pro provozní úkoly máme samostatnou instalaci GitLabu. To je potřeba, abyste zajistili, že nejste závislí na dostupnosti GitLab.com při provádění nasazení a aktualizací GitLab.com.
Přestože naše kanály pro cluster Kubernetes běží na samostatné instalaci GitLab, existují zrcadla úložišť kódu, která jsou veřejně dostupná na následujících adresách:
- — Konfigurační rámec GitLab.com pro graf GitLab Helm;
- - Obsahuje konfigurace pro služby, které nejsou přímo spojeny s aplikací GitLab. Patří mezi ně konfigurace pro protokolování a monitorování clusteru, stejně jako integrované nástroje jako PlantUML;
- — Konfigurace Terraform pro Kubernetes a starší infrastrukturu virtuálních počítačů. Zde nakonfigurujete všechny prostředky potřebné ke spuštění clusteru, včetně samotného clusteru, fondů uzlů, účtů služeb a rezervací IP adres.
Po provedení změn se zobrazí veřejné zobrazení. s odkazem na podrobný rozdíl, který SRE analyzuje před provedením změn v clusteru.
U SRE vede odkaz na podrobný rozdíl v instalaci GitLab, který se používá pro produkci a přístup k němu je omezený. To umožňuje zaměstnancům a komunitě bez přístupu k provoznímu projektu (který je otevřený pouze pro SRE) prohlížet navrhované změny konfigurace. Kombinací veřejné instance GitLab pro kód se soukromou instancí pro kanály CI udržujeme jeden pracovní postup a zároveň zajišťujeme nezávislost na GitLab.com pro aktualizace konfigurace.
Co jsme zjistili během migrace
Během přesunu byly získány zkušenosti, které aplikujeme na nové migrace a nasazení v Kubernetes.
1. Zvýšené náklady v důsledku dopravy mezi zónami dostupnosti
Denní statistiky odchodů (bajty za den) pro flotilu úložiště Git na GitLab.com
Google rozděluje svou síť na regiony. Ty jsou zase rozděleny do zón přístupnosti (AZ). Git hosting je spojen s velkým množstvím dat, proto je pro nás důležité mít pod kontrolou výstup sítě. Pro interní provoz je odjezd zdarma pouze tehdy, pokud zůstane ve stejné zóně dostupnosti. V době psaní tohoto článku obsluhujeme přibližně 100 TB dat za typický pracovní den (a to platí pouze pro úložiště Git). Služby, které byly umístěny na stejných virtuálních počítačích v naší staré topologii založené na virtuálních počítačích, nyní běží v různých modulech Kubernetes. To znamená, že část provozu, která byla dříve pro virtuální počítač místní, mohla potenciálně cestovat mimo zóny dostupnosti.
Regionální clustery GKE vám umožňují pokrýt více zón dostupnosti pro redundanci. Zvažujeme možnost pro služby, které generují velké objemy provozu. To sníží výstupní náklady při zachování redundance na úrovni clusteru.
2. Limity, požadavky na zdroje a škálování
Počet replik zpracovávajících produkční provoz na registry.gitlab.com. Provoz vrcholí v ~15:00 UTC.
Náš příběh o migraci začal v srpnu 2019, kdy jsme migrovali naši první službu, GitLab Container Registry, do Kubernetes. Tato kritická služba s vysokým provozem byla dobrou volbou pro první migraci, protože se jedná o bezstavovou aplikaci s několika externími závislostmi. První problém, na který jsme narazili, byl velký počet vyřazených modulů kvůli nedostatku paměti na uzlech. Kvůli tomu jsme museli změnit požadavky a limity.
Bylo zjištěno, že v případě aplikace, kde se spotřeba paměti v průběhu času zvyšuje, nízké hodnoty požadavků (rezervace paměti pro každý modul) spolu s „velkorysým“ pevným limitem využití vedly k saturaci. (nasycení) uzly a vysokou míru vystěhování. Vypořádat se s tímto problémem, bylo . To odstranilo tlak z uzlů a zajistilo, že pody měly životní cyklus, který na uzel nevyvíjel příliš velký tlak. Nyní zahájíme migraci s velkorysými (a téměř identickými) požadavky a limitními hodnotami a upravíme je podle potřeby.
3. Metriky a protokoly
Divize infrastruktury se zaměřuje na latenci, chybovost a saturaci instalací (SLO) propojeno s .
Za poslední rok bylo jednou z klíčových událostí v divizi infrastruktury zlepšení v monitorování a práci s SLO. SLO nám umožnily nastavit cíle pro jednotlivé služby, které jsme během migrace bedlivě sledovali. Ale i s touto zlepšenou pozorovatelností není vždy možné okamžitě vidět problémy pomocí metrik a výstrah. Například tím, že se zaměříme na latenci a chybovost, nepokryjeme plně všechny případy použití služby procházející migrací.
Tento problém byl objeven téměř okamžitě po migraci některých úloh do clusteru. Zvláště akutní to bylo, když jsme museli kontrolovat funkce, u kterých byl počet požadavků malý, ale které měly velmi specifické konfigurační závislosti. Jedním z klíčových ponaučení z migrace byla nutnost zohlednit při monitorování nejen metriky, ale také protokoly a „long tail“ (jde o na grafu - cca. překlad.) chyby. Nyní pro každou migraci uvádíme podrobný seznam dotazů na protokol (dotazy do protokolu) a naplánovat jasné postupy vrácení, které lze v případě problémů převést z jedné směny na druhou.
Paralelní poskytování stejných požadavků na staré infrastruktuře virtuálních počítačů a nové infrastruktuře založené na Kubernetes představovalo jedinečnou výzvu. Na rozdíl od migrace typu lift-and-shift (rychlý přenos aplikací „tak jak jsou“ do nové infrastruktury; více podrobností si můžete přečíst např. - Cca. překlad.), paralelní práce na „starých“ virtuálních počítačích a Kubernetes vyžaduje, aby monitorovací nástroje byly kompatibilní s oběma prostředími a byly schopny kombinovat metriky do jednoho pohledu. Je důležité, abychom používali stejné řídicí panely a dotazy protokolu, abychom dosáhli konzistentní sledovatelnosti během přechodného období.
4. Přepnutí provozu na nový cluster
Pro GitLab.com je část serverů vyhrazena . Canary Park slouží našim interním projektům a může také . Primárně je však určen k testování změn provedených v infrastruktuře a aplikaci. První migrovaná služba začala přijetím omezeného množství interního provozu a nadále tuto metodu používáme, abychom zajistili, že budou splněny SLO před odesláním veškerého provozu do clusteru.
V případě migrace to znamená, že se požadavky na interní projekty odesílají nejprve do Kubernetes a poté postupně přepínáme zbytek provozu do clusteru změnou váhy pro backend přes HAProxy. Během migrace z VM na Kubernetes se ukázalo, že je velmi výhodné mít snadný způsob, jak přesměrovat provoz mezi starou a novou infrastrukturou, a tedy udržovat starou infrastrukturu připravenou na rollback v prvních dnech po migraci.
5. Rezervní kapacity lusků a jejich využití
Téměř okamžitě byl identifikován následující problém: moduly pro službu Registry se spustily rychle, ale spouštění modulů pro Sidekiq trvalo . Dlouhá doba spouštění pro moduly Sidekiq se stala problémem, když jsme začali migrovat pracovní zátěže na Kubernetes pro pracovníky, kteří potřebovali rychle zpracovávat úlohy a rychle škálovat.
V tomto případě z toho plyne ponaučení, že zatímco Horizontal Pod Autoscaler (HPA) od Kubernetes zvládá růst provozu dobře, je důležité vzít v úvahu charakteristiky zátěže a alokovat volnou kapacitu podům (zejména při nerovnoměrném rozložení poptávky). V našem případě došlo k náhlému nárůstu úloh, což vedlo k rychlému škálování, což vedlo k nasycení zdrojů CPU, než jsme měli čas škálovat fond uzlů.
Vždy existuje pokušení vymáčknout z clusteru co nejvíce, ale protože jsme zpočátku narazili na problémy s výkonem, nyní začínáme s velkorysým rozpočtem na moduly a později jej snižujeme, přičemž bedlivě sledujeme SLO. Spouštění modulů pro službu Sidekiq se výrazně zrychlilo a nyní trvá v průměru asi 40 sekund. vyhrál jak GitLab.com, tak naše uživatele samoobslužných instalací pracujících s oficiálním grafem GitLab Helm.
Závěr
Po migraci každé služby jsme se radovali z výhod používání Kubernetes v produkci: rychlejší a bezpečnější nasazení aplikací, škálování a efektivnější alokace zdrojů. Výhody migrace navíc jdou nad rámec služby GitLab.com. Každé vylepšení oficiálního žebříčku Helm přináší výhody jeho uživatelům.
Doufám, že se vám příběh o našich migračních dobrodružstvích Kubernetes líbil. Pokračujeme v migraci všech nových služeb do clusteru. Další informace lze nalézt v následujících publikacích:
- «";
- «";
- .
PS od překladatele
Přečtěte si také na našem blogu:
- «";
- «";
- «";
- «".
Zdroj: www.habr.com