Tento příběh je o tom, jak používáme kontejnery v produktovém prostředí, zejména pod Kubernetes. Článek se zaměřuje na shromažďování metrik a logů z kontejnerů, stejně jako na vytváření obrazů.

Jsme fintech společnost Exness, která se zabývá vývojem služeb pro online trading a fintech produkty pro B2B a B2C. V našem R&D máme různé týmy, v oddělení vývoje pracuje více než 100 zaměstnanců.

Představujeme tým, který se stará o platformu pro shromažďování a spuštění kódu našich vývojářů. Konkrétně jsme zodpovědní za shromažďování, ukládání a poskytování metrik, logů a událostí z aplikací. V současnosti operujeme s přibližně třemi tisíci Docker kontejnery v produktovém prostředí, udržujeme naše big data úložiště o velikosti 50 TB a poskytujeme architektonická řešení, která se budují kolem naší infrastruktury: Kubernetes, Rancher a různí veřejní cloudoví poskytovatelé. 

Naše motivace

Co hoří? Nikdo nedokáže odpovědět. Kde je ohnisko? Pochopit je obtížné. Kdy to vzplálo? Zjistit lze, ale ne hned. 

Proč některé kontejnery stojí a jiné padly? Který kontejner za to může? Vždyť zvenčí jsou kontejnery stejné, ale uvnitř má každý svůj Neo.

Naši vývojáři jsou schopní kluci. Dělají dobré služby, které společnosti přinášejí zisk. Ale občas dojde k problémům, kdy kontejnery s aplikacemi jdou do chaosu. Jeden kontejner spotřebovává příliš CPU, jiný síť, třetí operace vstupu a výstupu, čtvrtý vůbec není jasné, co dělá se sokety. To všechno se zhroutí a loď potápí. 

Agenti

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

Tito agenti jsou zadržovací programy, které udržují kontejnery ve stavu, aby se navzájem nepoškodily. Agenti jsou standardizovaní, což umožňuje standardizovat přístup k údržbě kontejnerů. 

V našem případě musí agenti poskytovat logy ve standardním formátu, označené a s throttlingem. Také nám musí poskytovat standardizované metriky, které jsou rozšiřitelné z hlediska obchodních aplikací.

Pod agenty se také rozumí nástroje pro provoz a údržbu, schopné pracovat v různých orchestracech, které podporují různé obrazy (Debian, Alpine, Centos atd.).

A konečně, agenti musí podporovat jednoduché CI/CD, které zahrnuje Docker soubory. Jinak se loď rozpadne, protože kontejnery začnou být dodávány po „křivých“ kolejích.

Proces sestavení a příprava cílového image

Aby vše bylo standardizované a řízené, je nutné dodržovat nějaký standardní proces sestavení. Proto jsme se rozhodli sestavovat kontejnery pomocí kontejnerů – taková je rekurze.

Zde jsou kontejnery představovány pevným obrysem. Zároveň jsme se rozhodli do nich umístit distribuce, aby „život nevypadal příliš snadno“. Proč to bylo uděláno, vysvětlíme níže.
 
Výsledkem je nástroj pro sestavení – kontejner určité verze, který odkazuje na určité verze distribucí a určité verze skriptů.

Jak ho používáme? Máme Docker Hub, kde se nachází kontejner. Zrcadlíme ho do našeho systému, abychom se zbavili externích závislostí. Vznikl kontejner označený žlutou barvou. Vytváříme šablonu, aby se do kontejneru nainstalovaly všechny potřebné distribuce a skripty. Poté sestavujeme hotový obraz: vývojáři do něj umisťují kód a své specifické závislosti. 

Jaké výhody tento přístup přináší? 

• Za prvé, úplná verzionace nástrojů pro sestavení – kontejner pro sestavení, verze skriptů a distribucí. 
• Za druhé, dosáhli jsme standardizace: šablony, meziprodukty a hotové exploatovatelné image vytváříme stejným způsobem. 
• Za třetí, kontejnery nám zajišťují přenositelnost. Dnes používáme Gitlab, zítra přejdeme na TeamCity nebo Jenkins a tímto způsobem také budeme moci spouštět naše kontejnery. 
• Za čtvrté, minimalizace závislostí. Ne náhodou jsme umístili do kontejneru distribuce, protože to umožňuje nestahovat je pokaždé z internetu. 
• Za páté, zvýšila se rychlost sestavení – přítomnost místních kopií obrazů šetří čas, protože máme lokální obraz. 

Jinými slovy, dosáhli jsme řízeného a flexibilního procesu sestavení. Používáme stejné nástroje pro sestavení jakýchkoli kontejnerů s plnou verzionací. 

Jak funguje náš proces sestavení

Spuštění sestavy se provádí jedním příkazem, proces probíhá v obraze (vyznačeno červeně). Vývojář má Dockerfile (vyznačeno žlutě), který renderujeme, přičemž nahrazujeme proměnné hodnotami. Zároveň přidáváme header a footer – to jsou naši agenti. 

Header přidává distribuce z odpovídajících obrazů. Footer pak nainstaluje naše služby, nastaví spuštění pracovní zátěže, logování a další agenty, mění entrypoint atd. 

Dlouho jsme přemýšleli, zda nasadit supervizora. Nakonec jsme se rozhodli, že ho potřebujeme. Vybrali jsme S6. Supervizor zajišťuje řízení kontejneru: umožňuje připojení v případě pádu hlavního procesu a zajišťuje ruční řízení kontejneru bez jeho přenastavení. Logy a metriky jsou procesy prováděné uvnitř kontejneru. I tyto je třeba nějak kontrolovat, a to děláme pomocí supervizora. Nakonec S6 přebírá provádění údržby, zpracování signálů a další úkoly.

Protože aplikujeme různé orchestrace, po sestavení a spuštění kontejner musí pochopit, v jakém prostředí se nachází, a jednat podle situace. Například:
To nám umožňuje sestavit jeden obraz a spouštět ho v různých orchestracech, přičemž bude spuštěn s ohledem na specifika této orchestrace.

 

Pro stejný kontejner získáváme různá procesní stromové struktury v Dockeru a Kubernetes:

Užitečná zátěž běží pod supervizorem S6. Všimněte si collectoru a událostí – to jsou naši agenti, kteří se starají o logy a metriky. V Kubernetes je nemáme, ale v Dockeru ano. Proč? 

Pokud se podíváme na specifikaci „podu“ (dále jen Kubernetes pod), uvidíme, že kontejner událostí běží v podu, kde je samostatný kontejner collector, který plní funkci sběru metrik a logů. Můžeme využívat možnosti Kubernetes: spouštět kontejnery v jednom podu, v jedné procesní a/nebo síťové sféře. Fakticky vkládat své agenty a vykonávat určité funkce. A pokud se tento kontejner spustí v Dockeru, dostane stejné možnosti, tedy bude schopen dodávat logy a metriky, protože agenti budou spuštěni uvnitř. 

Metriky a logy

Dodávání metrik a logů je složitý úkol. S jeho řešením je spojeno několik aspektů.
Infrastruktura je vytvářena pro zpracování užitečné zátěže, nikoli pro hromadné doručování logů. To znamená, že tento proces by měl probíhat s minimálními požadavky na zdroje kontejnerů. Snažíme se pomoci našim vývojářům: „Vezměte kontejner z Docker Hub, spusťte ho a my se postaráme o doručení logů.“ 

Druhým aspektem je omezení objemu logů. Pokud v několika kontejnerech dojde k výskytu špičkového objemu logů (aplikace v cyklu vypisuje stack-trace), zvyšuje se zátěž na CPU, komunikační kanály, systém zpracování logů a to ovlivňuje provoz hostitele jako celku a ostatní kontejnery na hostiteli, což někdy vede k „pádu“ hostitele. 

Třetím aspektem je nutnost podporovat co nejvíce metod sběru metrik již v základu. Od čtení souborů a dotazování na Prometheus-endpoint po použití specifických protokolů aplikací.

A posledním aspektem je nezbytnost minimalizovat spotřebu zdrojů.

Vybrali jsme open-source řešení v Go s názvem Telegraf. Je to univerzální konektor, který podporuje více než 140 druhů vstupních kanálů (input plugins) a 30 druhů výstupních (output plugins). Přizpůsobili jsme ho a nyní vám ukážeme, jak je používán u nás na příkladu Kubernetes. 

Představte si, že vývojář nasazuje zátěž a Kubernetes obdrží žádost o vytvoření podu. V tento okamžik se pro každý pod automaticky vytváří kontejner s názvem Collector (používáme mutation webhook). Collector je náš agent. Na začátku tento kontejner nastavuje sám sebe na práci s Prometheus a systémem sběru logů.

• K tomu využívá anotace podu, a v závislosti na jejím obsahu vytváří například cílový bod end-point Prometheus; 
• Na základě specifikace podu a specifických nastavení kontejnerů rozhoduje, jak doručovat logy.

Logy shromažďujeme prostřednictvím Docker API: vývojářům stačí umístit je do stdout nebo stderr, a poté se už Collector postará. Logy jsou shromažďovány po dávkách s určitým zpožděním, aby se předešlo možnému přetížení hostitele. 

Metriky se shromažďují podle instancí pracovní zátěže (procesů) v kontejnerech. Všechno je označeno tagy: namespace, pod a tak dále, a poté se převádí do formátu Prometheus – a stává se dostupným pro sběr (kromě logů). Také, logy, metriky a události odesíláme do Kafka a dále:

• Logy jsou dostupné v Graylogu (pro vizuální analýzu);
• Logy, metriky a události jsou odesílány do Clickhouse pro dlouhodobé uchování.

Stejně to funguje i na AWS, pouze nahrazujeme Graylog s Kafkou Cloudwatch. Odesíláme tam logy a všechno je velmi pohodlné: hned je jasné, ke kterému clusteru a kontejneru patří. Totéž platí pro Google Stackdriver. Naše schéma tedy funguje jak on-premise s Kafkou, tak v cloudu. 

Pokud nemáme Kubernetes s podmi, schéma se trochu komplikuje, ale funguje na stejných principech.

Uvnitř kontejneru se vykonávají stejné procesy, které jsou orchestrací řešeny pomocí S6. Všechny stejné procesy běží uvnitř jednoho kontejneru.

Nakonec

Vytvořili jsme ucelené řešení pro sestavení a spuštění obrazů do provozu, s možnostmi shromažďování a dodávky logů a metrik:

• Vyvinuli jsme standardizovaný přístup ke sestavování obrazů, na jehož základě jsme vytvořili CI šablony;
• Agenti pro sběr dat jsou naše rozšíření Telegraf. Dobře jsme je otestovali v produkci;
• Používáme mutation webhook pro nasazení kontejnerů s agenty do podů; 
• Integrujeme se do ekosystému Kubernetes/Rancher;
• Můžeme spouštět identické kontejnery v různých orchestrátorech a dosahovat očekávaných výsledků;
• Vytvořili jsme zcela dynamickou konfiguraci správy kontejnerů. 

Spoluatorkou: Ilja Prudnikov

Zdroj: habr.com