Tento príbeh je o tom, ako používame kontajnery v produkčnom prostredí, konkrétne Kubernetes. Článok je venovaný zhromažďovaniu metrík a protokolov z kontajnerov, ako aj obrázkov budov.

Sme z fintech spoločnosti Exness, ktorá vyvíja služby pre online obchodovanie a fintech produkty pre B2B a B2C. Náš výskum a vývoj má veľa rôznych tímov, vývojové oddelenie má 100+ zamestnancov.

Zastupujeme tím, ktorý je zodpovedný za platformu pre našich vývojárov na zhromažďovanie a spúšťanie kódu. Sme zodpovední najmä za zhromažďovanie, ukladanie a vykazovanie metrík, protokolov a udalostí z aplikácií. V súčasnosti prevádzkujeme približne tri tisícky kontajnerov Docker v produkčnom prostredí, udržiavame naše 50 TB úložisko veľkých dát a poskytujeme architektonické riešenia, ktoré sú postavené na našej infraštruktúre: Kubernetes, Rancher a rôzni poskytovatelia verejného cloudu. 

Naša motivácia

Čo horí? Nikto nevie odpovedať. Kde je ohnisko? Je to ťažké pochopiť. Kedy sa to vznietilo? Môžete to zistiť, ale nie hneď. 

Prečo niektoré kontajnery stoja, kým iné spadli? Ktorý kontajner bol na vine? Koniec koncov, vonkajšie časti kontajnerov sú rovnaké, ale vo vnútri má každý svoje vlastné Neo.

Naši vývojári sú kompetentní ľudia. Robia dobré služby, ktoré prinášajú spoločnosti zisk. Existujú však zlyhania, keď sa kontajnery s aplikáciami stratia. Jeden kontajner spotrebúva príliš veľa CPU, ďalší spotrebúva sieť, tretí spotrebúva I/O operácie a štvrtý je úplne nejasný, čo robí so soketmi. Všetko padá a loď sa potápa. 

Agenti

Aby sme pochopili, čo sa deje vo vnútri, rozhodli sme sa umiestniť agentov priamo do kontajnerov.

Tieto prostriedky sú obmedzujúce programy, ktoré udržujú kontajnery v takom stave, aby sa navzájom nerozbili. Prostriedky sú štandardizované, čo umožňuje štandardizovaný prístup k údržbe kontajnerov. 

V našom prípade musia agenti poskytovať protokoly v štandardnom formáte, označené a obmedzené. Mali by nám tiež poskytnúť štandardizované metriky, ktoré sú rozšíriteľné z pohľadu podnikových aplikácií.

Agenti tiež znamenajú nástroje na prevádzku a údržbu, ktoré môžu pracovať v rôznych systémoch orchestrácie, ktoré podporujú rôzne obrazy (Debian, Alpine, Centos atď.).

Nakoniec, agenti musia podporovať jednoduché CI/CD, ktoré obsahuje súbory Docker. V opačnom prípade sa loď rozpadne, pretože kontajnery sa začnú dodávať po „krivých“ koľajniciach.

Zostavte procesné a cieľové obrazové zariadenie

Aby bolo všetko štandardizované a spravovateľné, je potrebné dodržiavať nejaký štandardný proces zostavovania. Preto sme sa rozhodli zbierať kontajnery po kontajneroch – to je rekurzia.

Tu sú nádoby znázornené plnými obrysmi. Zároveň sa do nich rozhodli vložiť distribučné súpravy, aby sa „život nezdal ako malina“. Prečo sa to stalo, vysvetlíme nižšie.
 
Výsledkom je nástroj na zostavenie – kontajner špecifický pre verziu, ktorý odkazuje na konkrétne distribučné verzie a špecifické verzie skriptov.

Ako ho používame? Máme Docker Hub, ktorý obsahuje kontajner. Zrkadlíme ho vo vnútri nášho systému, aby sme sa zbavili vonkajších závislostí. Výsledkom je nádoba označená žltou farbou. Vytvoríme šablónu na inštaláciu všetkých distribúcií a skriptov, ktoré potrebujeme do kontajnera. Potom zostavíme obraz pripravený na použitie: vývojári doň vložia kód a niektoré zo svojich špeciálnych závislostí. 

Čo je dobré na tomto prístupe? 

• Po prvé, úplná kontrola verzií nástrojov na zostavenie - kontajner na zostavenie, skript a distribučné verzie. 
• Po druhé, dosiahli sme štandardizáciu: rovnakým spôsobom vytvárame šablóny, prechodný obrázok a obrázok pripravený na použitie. 
• Po tretie, kontajnery nám umožňujú prenosnosť. Dnes používame Gitlab a zajtra prejdeme na TeamCity alebo Jenkins a budeme môcť prevádzkovať naše kontajnery rovnakým spôsobom. 
• Po štvrté, minimalizácia závislostí. Nebola náhoda, že sme distribučné súpravy vložili do kontajnera, pretože nám to umožňuje vyhnúť sa zakaždým ich sťahovaniu z internetu. 
• Po piate, rýchlosť zostavovania sa zvýšila - prítomnosť lokálnych kópií obrázkov vám umožňuje vyhnúť sa strate času pri sťahovaní, pretože existuje lokálny obrázok. 

Inými slovami, dosiahli sme kontrolovaný a flexibilný proces montáže. Rovnaké nástroje používame na vytváranie kontajnerov s plnou verziou. 

Ako funguje náš postup zostavovania

Montáž sa spustí jedným príkazom, proces sa vykoná na obrázku (zvýraznený červenou farbou). Vývojár má súbor Docker (zvýraznený žltou farbou), vykreslíme ho a premenné nahradíme hodnotami. A popri tom pridávame hlavičky a päty – to sú naši agenti. 

Hlavička pridáva distribúcie zo zodpovedajúcich obrázkov. A päta nainštaluje naše služby dovnútra, nakonfiguruje spustenie pracovného zaťaženia, protokolovanie a iných agentov, nahradí vstupný bod atď. 

Dlho sme rozmýšľali, či nainštalovať supervízor. Nakoniec sme sa rozhodli, že ho potrebujeme. Vybrali sme S6. Supervízor poskytuje správu kontajnera: umožňuje vám pripojiť sa k nemu, ak zlyhá hlavný proces, a poskytuje manuálnu správu kontajnera bez jeho opätovného vytvárania. Protokoly a metriky sú procesy bežiace vo vnútri kontajnera. Aj ich treba nejako kontrolovať a to robíme s pomocou supervízora. Nakoniec sa S6 postará o upratovanie, spracovanie signálu a ďalšie úlohy.

Keďže používame rôzne systémy orchestrácie, po zostavení a spustení musí kontajner pochopiť, v akom prostredí sa nachádza a konať podľa situácie. Napríklad:
To nám umožňuje vytvoriť jeden obraz a spustiť ho v rôznych systémoch orchestrácie a spustí sa s prihliadnutím na špecifiká tohto systému orchestrácie.

 

Pre rovnaký kontajner získame rôzne stromy procesov v Docker a Kubernetes:

Užitočné zaťaženie sa vykonáva pod dohľadom S6. Venujte pozornosť zberateľom a udalostiam - to sú naši agenti zodpovední za protokoly a metriky. Kubernetes ich nemá, ale Docker áno. prečo? 

Ak sa pozrieme na špecifikáciu „podu“ (ďalej len Kubernetes pod), uvidíme, že kontajner udalostí sa vykonáva v pod, ktorý má samostatný zberný kontajner, ktorý plní funkciu zhromažďovania metrík a protokolov. Môžeme využiť možnosti Kubernetes: spustenie kontajnerov v jednom pod, v jednom procese a/alebo sieťovom priestore. Predstavte svojich agentov a vykonajte niektoré funkcie. A ak sa rovnaký kontajner spustí v Dockeri, získa všetky rovnaké možnosti ako výstup, to znamená, že bude môcť doručovať protokoly a metriky, pretože agenti budú spustení interne. 

Metriky a denníky

Poskytovanie metrík a protokolov je zložitá úloha. Jej rozhodnutie má viacero aspektov.
Infraštruktúra je vytvorená na vykonávanie užitočného zaťaženia a nie na hromadné doručovanie protokolov. To znamená, že tento proces musí byť vykonaný s minimálnymi požiadavkami na prostriedky kontajnera. Snažíme sa pomáhať našim vývojárom: „Získajte kontajner Docker Hub, spustite ho a my môžeme doručiť protokoly.“ 

Druhým aspektom je obmedzenie objemu guľatiny. Ak dôjde k prudkému nárastu objemu protokolov v niekoľkých kontajneroch (aplikácia odošle stopu zásobníka v slučke), zaťaženie CPU, komunikačných kanálov a systému spracovania protokolov sa zvýši, čo ovplyvní činnosť hostiteľa ako celé a iné kontajnery na hostiteľovi, potom to niekedy vedie k "pádu" hostiteľa. 

Tretím aspektom je, že je potrebné hneď po vybalení podporovať čo najviac metód zberu metrík. Od čítania súborov a dotazovania koncového bodu Prometheus až po používanie protokolov špecifických pre aplikáciu.

A posledným aspektom je minimalizácia spotreby zdrojov.

Vybrali sme open-source Go riešenie s názvom Telegraf. Ide o univerzálny konektor, ktorý podporuje viac ako 140 typov vstupných kanálov (vstupné pluginy) a 30 typov výstupných kanálov (výstupné pluginy). Dokončili sme ho a teraz vám povieme, ako ho používame na príklade Kubernetes. 

Povedzme, že vývojár nasadí pracovné zaťaženie a Kubernetes dostane požiadavku na vytvorenie modulu. V tomto momente sa pre každý pod automaticky vytvorí kontajner s názvom Collector (používame mutačný webhook). Collector je náš agent. Na začiatku sa tento kontajner nakonfiguruje na prácu so systémom Prometheus a systémom zberu protokolov.

• Na tento účel používa anotácie pod a v závislosti od obsahu vytvorí povedzme koncový bod Prometheus; 
• Na základe špecifikácie podu a konkrétnych nastavení kontajnera rozhoduje o spôsobe doručenia denníkov.

Protokoly zhromažďujeme prostredníctvom rozhrania Docker API: vývojári ich musia vložiť do stdout alebo stderr a Collector to vyrieši. Protokoly sa zhromažďujú po častiach s určitým oneskorením, aby sa zabránilo možnému preťaženiu hostiteľa. 

Metriky sa zhromažďujú v rámci inštancií pracovného zaťaženia (procesov) v kontajneroch. Všetko je označené: menný priestor, pod atď. a potom sa skonvertuje do formátu Prometheus – a je k dispozícii na zber (okrem protokolov). Záznamy, metriky a udalosti posielame aj spoločnosti Kafka a ďalej:

• Protokoly sú dostupné v Graylog (pre vizuálnu analýzu);
• Protokoly, metriky a udalosti sa odosielajú do Clickhouse na dlhodobé ukladanie.

V AWS funguje všetko úplne rovnako, len Graylog s Kafkom nahrádzame Cloudwatch. Pošleme tam protokoly a všetko sa ukáže ako veľmi pohodlné: okamžite je jasné, do ktorého klastra a kontajnera patria. To isté platí pre Google Stackdriver. To znamená, že naša schéma funguje ako on-premise s Kafkou, tak aj v cloude. 

Ak nemáme Kubernetes s modulmi, schéma je trochu komplikovanejšia, ale funguje na rovnakých princípoch.

Rovnaké procesy sa vykonávajú vo vnútri kontajnera, sú organizované pomocou S6. Všetky rovnaké procesy bežia v rovnakom kontajneri.

V dôsledku toho,

Vytvorili sme kompletné riešenie na vytváranie a spúšťanie obrázkov s možnosťami zhromažďovania a doručovania protokolov a metrík:

• Vyvinuli sme štandardizovaný prístup k zostavovaniu obrázkov a na jeho základe sme vyvinuli šablóny CI;
• Agenti zberu údajov sú naše rozšírenia Telegraf. Dobre sme ich otestovali vo výrobe;
• Mutačný webhook používame na implementáciu kontajnerov s agentmi v podoch; 
• Integrované do ekosystému Kubernetes/Rancher;
• Môžeme spustiť rovnaké kontajnery v rôznych systémoch orchestrácie a získať výsledok, ktorý očakávame;
• Vytvorila sa úplne dynamická konfigurácia správy kontajnerov. 

Spoluautor: Iľja Prudnikov

Zdroj: hab.com