Tento příběh je o tom, jak používáme kontejnery v produkčním prostředí, konkrétně Kubernetes. Článek je věnován shromažďování metrik a protokolů z kontejnerů a také obrázkům budov.

Jsme z fintech společnosti Exness, která vyvíjí služby pro online obchodování a fintech produkty pro B2B a B2C. Náš výzkum a vývoj má mnoho různých týmů, vývojové oddělení má 100+ zaměstnanců.

Zastupujeme tým, který je zodpovědný za platformu pro naše vývojáře ke shromažďování a spouštění kódu. Zejména jsme zodpovědní za shromažďování, ukládání a vykazování metrik, protokolů a událostí z aplikací. V současné době provozujeme přibližně tři tisíce kontejnerů Docker v produkčním prostředí, udržujeme naše úložiště velkých dat o velikosti 50 TB a poskytujeme architektonická řešení, která jsou postavena na naší infrastruktuře: Kubernetes, Rancher a různí poskytovatelé veřejného cloudu. 

Naše motivace

Co hoří? Nikdo nemůže odpovědět. Kde je to ohniště? Je těžké to pochopit. Kdy to začalo hořet? Můžete to zjistit, ale ne hned. 

Proč některé kontejnery stojí, zatímco jiné spadly? Který kontejner byl na vině? Koneckonců, vnější strany kontejnerů jsou stejné, ale uvnitř má každý své vlastní Neo.

Naši vývojáři jsou kompetentní kluci. Poskytují dobré služby, které přinášejí společnosti zisk. Ale dochází k selháním, když se kontejnery s aplikacemi ztratí. Jeden kontejner spotřebovává příliš mnoho CPU, další spotřebovává síť, třetí spotřebovává I/O operace a čtvrtý je zcela nejasný, co dělá se sockety. Všechno to spadne a loď se potopí. 

Agenti

Abychom pochopili, co se děje uvnitř, rozhodli jsme se umístit agenty přímo do kontejnerů.

Tito agenti jsou omezovací programy, které udržují kontejnery v takovém stavu, aby se navzájem nerozbily. Agenti jsou standardizováni, což umožňuje standardizovaný přístup k obsluze kontejnerů. 

V našem případě musí agenti poskytovat protokoly ve standardním formátu, označené a omezené. Měli by nám také poskytnout standardizované metriky, které jsou rozšiřitelné z pohledu podnikových aplikací.

Agenti také znamenají nástroje pro provoz a údržbu, které mohou pracovat v různých orchestračních systémech, které podporují různé obrazy (Debian, Alpine, Centos atd.).

Konečně, agenti musí podporovat jednoduché CI/CD, které obsahuje soubory Docker. V opačném případě se loď rozpadne, protože kontejnery začnou být dodávány po „křivých“ kolejích.

Sestavte procesní a cílové obrazové zařízení

Aby bylo vše standardizované a spravovatelné, je třeba dodržovat nějaký standardní proces sestavování. Proto jsme se rozhodli sbírat kontejnery po kontejnerech - to je rekurze.

Zde jsou nádoby znázorněny plnými obrysy. Zároveň se do nich rozhodli umístit distribuční sady, aby se „život nezdál jako maliny“. Proč to bylo provedeno, vysvětlíme níže.
 
Výsledkem je nástroj pro sestavení – kontejner pro konkrétní verzi, který odkazuje na konkrétní distribuční verze a konkrétní verze skriptů.

Jak to používáme? Máme Docker Hub, který obsahuje kontejner. Zrcadlíme to uvnitř našeho systému, abychom se zbavili externích závislostí. Výsledkem je kontejner označený žlutě. Vytvoříme šablonu pro instalaci všech distribucí a skriptů, které potřebujeme do kontejneru. Poté sestavíme obraz připravený k použití: vývojáři do něj vloží kód a některé své vlastní speciální závislosti. 

Co je na tomto přístupu dobrého? 

• Za prvé, plná kontrola verzí nástrojů pro sestavení – kontejner sestavení, verze skriptu a distribuce. 
• Za druhé, dosáhli jsme standardizace: stejným způsobem vytváříme šablony, přechodný obrázek a obrázek připravený k použití. 
• Za třetí, kontejnery nám umožňují přenositelnost. Dnes používáme Gitlab a zítra přejdeme na TeamCity nebo Jenkins a budeme moci provozovat naše kontejnery stejným způsobem. 
• Za čtvrté, minimalizace závislostí. Nebyla to náhoda, že jsme do kontejneru vložili distribuční sady, protože nám to umožňuje vyhnout se pokaždé jejich stahování z internetu. 
• Za páté, rychlost sestavení se zvýšila - přítomnost místních kopií obrázků vám umožňuje vyhnout se plýtvání časem na stahování, protože existuje místní obrázek. 

Jinými slovy, dosáhli jsme kontrolovaného a flexibilního procesu montáže. Stejné nástroje používáme k vytváření jakýchkoli plně verzovaných kontejnerů. 

Jak funguje náš postup sestavení

Sestavení se spustí jedním příkazem, proces se provede na obrázku (zvýrazněno červeně). Vývojář má soubor Docker (zvýrazněný žlutě), vykreslíme jej a proměnné nahradíme hodnotami. A po cestě přidáváme záhlaví a zápatí – to jsou naši agenti. 

Header přidává distribuce z odpovídajících obrázků. A zápatí nainstaluje naše služby dovnitř, nakonfiguruje spouštění úloh, protokolování a další agenty, nahradí vstupní bod atd. 

Dlouho jsme přemýšleli, zda nainstalovat supervizor. Nakonec jsme se rozhodli, že ho potřebujeme. Vybrali jsme S6. Supervizor zajišťuje správu kontejneru: umožňuje vám se k němu připojit, pokud dojde k selhání hlavního procesu, a poskytuje ruční správu kontejneru bez jeho opětovného vytváření. Protokoly a metriky jsou procesy běžící uvnitř kontejneru. Také je třeba je nějak ovládat a to děláme s pomocí supervizora. Nakonec se S6 postará o úklid, zpracování signálu a další úkoly.

Protože používáme různé orchestrační systémy, po sestavení a spuštění musí kontejner pochopit, v jakém prostředí se nachází, a jednat podle situace. Například:
To nám umožňuje vytvořit jeden obraz a spustit jej v různých orchestračních systémech a bude spuštěn s ohledem na specifika tohoto orchestračního systému.

 

Pro stejný kontejner získáváme různé stromy procesů v Dockeru a Kubernetes:

Užitná zátěž se provádí pod dohledem S6. Věnujte pozornost sběratelům a událostem - to jsou naši agenti zodpovědní za protokoly a metriky. Kubernetes je nemá, ale Docker ano. Proč? 

Pokud se podíváme na specifikaci „podu“ (dále – Kubernetes pod), uvidíme, že kontejner událostí se spouští v podu, který má samostatný kolektorový kontejner, který plní funkci shromažďování metrik a protokolů. Můžeme využít schopnosti Kubernetes: spouštění kontejnerů v jednom podu, v jediném procesu a/nebo síťovém prostoru. Představte své agenty a proveďte některé funkce. A pokud je stejný kontejner spuštěn v Dockeru, získá všechny stejné možnosti jako výstup, to znamená, že bude schopen doručovat protokoly a metriky, protože agenti budou spuštěni interně. 

Metriky a protokoly

Poskytování metrik a protokolů je složitý úkol. Její rozhodnutí má několik aspektů.
Infrastruktura je vytvořena pro provádění užitečného zatížení, nikoli pro hromadné doručování protokolů. To znamená, že tento proces musí být proveden s minimálními požadavky na prostředky kontejneru. Snažíme se pomáhat našim vývojářům: „Získejte kontejner Docker Hub, spusťte jej a my můžeme doručit protokoly.“ 

Druhým aspektem je omezení objemu protokolů. Pokud dojde k prudkému nárůstu objemu protokolů v několika kontejnerech (aplikace vydává trasování zásobníku ve smyčce), zvýší se zatížení CPU, komunikačních kanálů a systému zpracování protokolů, což ovlivní provoz hostitele jako celé a další kontejnery na hostiteli, pak to někdy vede k "pádu" hostitele. 

Třetím aspektem je, že je nutné ihned po vybalení podporovat co nejvíce metod sběru metrik. Od čtení souborů a dotazování koncového bodu Prometheus po používání protokolů specifických pro aplikaci.

A posledním aspektem je minimalizace spotřeby zdrojů.

Zvolili jsme open-source Go řešení s názvem Telegraf. Jedná se o univerzální konektor, který podporuje více než 140 typů vstupních kanálů (input plugins) a 30 typů výstupních kanálů (output plugins). Dokončili jsme jej a nyní vám řekneme, jak jej používáme na příkladu Kubernetes. 

Řekněme, že vývojář nasadí pracovní zátěž a Kubernetes obdrží požadavek na vytvoření pod. V tomto okamžiku se pro každý pod automaticky vytvoří kontejner s názvem Collector (používáme mutační webhook). Collector je náš agent. Na začátku se tento kontejner nakonfiguruje pro práci s Prometheus a systémem sběru protokolů.

• K tomu používá anotace pod a v závislosti na svém obsahu vytvoří řekněme koncový bod Prometheus; 
• Na základě specifikace podu a konkrétního nastavení kontejneru rozhodne, jak doručit protokoly.

Protokoly shromažďujeme prostřednictvím rozhraní Docker API: vývojáři je stačí vložit do stdout nebo stderr a Collector to vyřeší. Protokoly se shromažďují po částech s určitým zpožděním, aby se zabránilo možnému přetížení hostitele. 

Metriky se shromažďují napříč instancemi zátěže (procesy) v kontejnerech. Vše je označeno: jmenný prostor, pod atd. a poté převedeno do formátu Prometheus – a bude k dispozici pro sběr (kromě protokolů). Zasíláme také protokoly, metriky a události společnosti Kafka a dále:

• Protokoly jsou dostupné v Graylogu (pro vizuální analýzu);
• Protokoly, metriky a události jsou odesílány do Clickhouse k dlouhodobému uložení.

V AWS vše funguje úplně stejně, jen Graylog s Kafkou nahradíme Cloudwatch. Pošleme tam protokoly a vše se ukáže velmi pohodlně: je okamžitě jasné, ke kterému clusteru a kontejneru patří. Totéž platí pro Google Stackdriver. To znamená, že naše schéma funguje jak on-premise s Kafkou, tak v cloudu. 

Pokud nemáme Kubernetes s pody, je schéma trochu složitější, ale funguje na stejných principech.

Stejné procesy jsou prováděny uvnitř kontejneru, jsou organizovány pomocí S6. Všechny stejné procesy běží ve stejném kontejneru.

V důsledku toho,

Vytvořili jsme kompletní řešení pro vytváření a spouštění obrázků s možnostmi shromažďování a doručování protokolů a metrik:

• Vyvinuli jsme standardizovaný přístup k sestavování obrázků a na jeho základě jsme vyvinuli šablony CI;
• Agenti pro sběr dat jsou naše rozšíření Telegraf. Ve výrobě jsme je dobře otestovali;
• Mutační webhook používáme k implementaci kontejnerů s agenty v podech; 
• Integrováno do ekosystému Kubernetes/Rancher;
• Můžeme spustit stejné kontejnery v různých orchestračních systémech a získat výsledek, který očekáváme;
• Vytvořena zcela dynamická konfigurace správy kontejnerů. 

Spoluautor: Ilja Prudnikov

Zdroj: www.habr.com