Ova priča govori o tome kako koristimo kontejnere u proizvodnom okruženju, posebno Kubernetes. Članak je posvećen prikupljanju metrika i dnevnika iz kontejnera, kao i izgradnji slika.

Mi smo iz fintech kompanije Exness, koja razvija usluge za online trgovanje i fintech proizvode za B2B i B2C. Naš R&D ima mnogo različitih timova, razvojni odjel ima 100+ zaposlenih.

Predstavljamo tim koji je odgovoran za platformu za prikupljanje i pokretanje koda naših programera. Posebno smo odgovorni za prikupljanje, pohranjivanje i izvještavanje o metrikama, zapisnicima i događajima iz aplikacija. Trenutno upravljamo s oko tri hiljade Docker kontejnera u proizvodnom okruženju, održavamo našu pohranu velikih podataka od 50 TB i pružamo arhitektonska rješenja koja su izgrađena oko naše infrastrukture: Kubernetes, Rancher i razni javni cloud provajderi. 

Naša motivacija

Šta gori? Niko ne može da odgovori. Gdje je ognjište? Teško je to razumjeti. Kada se zapalio? Možete saznati, ali ne odmah. 

Zašto neki kontejneri stoje dok su drugi pali? Koji je kontejner bio kriv? Na kraju krajeva, vanjski dijelovi kontejnera su isti, ali unutar svaki ima svoj Neo.

Naši programeri su kompetentni momci. Oni prave dobre usluge koje donose profit kompaniji. Ali postoje kvarovi kada kontejneri s aplikacijama zalutaju. Jedan kontejner troši previše CPU-a, drugi troši mrežu, treći I/O operacije, a četvrti je potpuno nejasno šta radi sa utičnicama. Sve pada i brod tone. 

Agenti

Da bismo razumjeli šta se dešava unutra, odlučili smo da agente smjestimo direktno u kontejnere.

Ovi agenti su ograničavajući programi koji drže kontejnere u takvom stanju da se međusobno ne razbijaju. Agenti su standardizovani, a to omogućava standardizovan pristup servisiranju kontejnera. 

U našem slučaju, agenti moraju dati dnevnike u standardnom formatu, označene i ograničene. Oni bi takođe trebali da nam pruže standardizovane metrike koje su proširive iz perspektive poslovne aplikacije.

Agenti također znače pomoćne programe za rad i održavanje koji mogu raditi u različitim orkestracijskim sustavima koji podržavaju različite slike (Debian, Alpine, Centos, itd.).

Konačno, agenti moraju podržavati jednostavan CI/CD koji uključuje Docker datoteke. U suprotnom, brod će se raspasti, jer će kontejneri početi da se isporučuju po "krivim" šinama.

Izgradite proces i odredite uređaj slike

Da bi sve ostalo standardizovano i kojim se moglo upravljati, potrebno je slijediti neku vrstu standardnog procesa izgradnje. Stoga smo odlučili sakupljati kontejnere po kontejnerima - ovo je rekurzija.

Ovdje su kontejneri predstavljeni čvrstim obrisima. Istovremeno, odlučili su da u njih stave distribucijske komplete kako “život ne bi izgledao kao maline”. Zašto je to učinjeno, objasnit ćemo u nastavku.
 
Rezultat je alat za pravljenje—kontejner specifičan za verziju koji referencira specifične verzije distribucije i specifične verzije skripte.

Kako ga koristimo? Imamo Docker Hub koji sadrži kontejner. Preslikavamo ga unutar našeg sistema da bismo se riješili vanjskih ovisnosti. Rezultat je kontejner označen žutom bojom. Kreiramo predložak za instaliranje svih distribucija i skripti koje su nam potrebne u kontejner. Nakon toga sastavljamo sliku spremnu za korištenje: programeri u nju stavljaju kod i neke od svojih posebnih ovisnosti. 

Šta je dobro u ovom pristupu? 

• Prvo, puna kontrola verzija alata za pravljenje - verzija kontejnera za izgradnju, skripte i distribucije. 
• Drugo, postigli smo standardizaciju: na isti način kreiramo šablone, srednju i sliku spremnu za upotrebu. 
• Treće, kontejneri nam daju prenosivost. Danas koristimo Gitlab, a sutra prelazimo na TeamCity ili Jenkins i moći ćemo na isti način pokretati naše kontejnere. 
• Četvrto, minimiziranje zavisnosti. Nije bilo slučajno što smo distribucijske komplete stavili u kontejner, jer nam to omogućava da izbjegnemo svaki put da ih preuzimamo s interneta. 
• Peto, brzina izrade je povećana - prisutnost lokalnih kopija slika omogućava vam da izbjegnete gubljenje vremena na preuzimanje, jer postoji lokalna slika. 

Drugim riječima, postigli smo kontroliran i fleksibilan proces montaže. Koristimo iste alate za izgradnju bilo kojeg potpuno verzionisanog kontejnera. 

Kako funkcioniše naš postupak izgradnje

Sklop se pokreće jednom komandom, proces se izvršava na slici (označeno crvenom bojom). Programer ima Docker datoteku (označena žutom bojom), mi je renderiramo, zamjenjujući varijable vrijednostima. I usput dodajemo zaglavlja i podnožja - to su naši agenti. 

Zaglavlje dodaje distribucije sa odgovarajućih slika. I podnožje instalira naše usluge unutra, konfigurira pokretanje radnog opterećenja, evidentiranje i druge agente, zamjenjuje ulaznu tačku itd. 

Dugo smo razmišljali da li da instaliramo supervizor. Na kraju smo odlučili da nam je potreban. Izabrali smo S6. Supervizor pruža upravljanje kontejnerom: omogućava vam da se povežete na njega ako se glavni proces sruši i pruža ručno upravljanje kontejnerom bez ponovnog kreiranja. Dnevnici i metrika su procesi koji se izvode unutar kontejnera. I njih treba nekako kontrolisati, a mi to radimo uz pomoć supervizora. Konačno, S6 brine o održavanju domaćinstva, obradi signala i drugim zadacima.

Budući da koristimo različite sisteme orkestracije, nakon izgradnje i rada, kontejner mora razumjeti u kakvom se okruženju nalazi i djelovati u skladu sa situacijom. Na primjer:
To nam omogućava da napravimo jednu sliku i pokrenemo je u različitim orkestracijskim sistemima, a ona će biti pokrenuta uzimajući u obzir specifičnosti ovog orkestralnog sistema.

 

Za isti kontejner dobijamo različita stabla procesa u Dockeru i Kubernetesu:

Korisno opterećenje se izvršava pod nadzorom S6. Obratite pažnju na sakupljače i događaje - to su naši agenti odgovorni za dnevnike i metriku. Kubernetes ih nema, ali Docker ima. Zašto? 

Ako pogledamo specifikaciju “pod” (u daljem tekstu – Kubernetes pod), vidjet ćemo da se kontejner događaja izvršava u pod-u koji ima poseban kolektorski kontejner koji obavlja funkciju prikupljanja metrika i logova. Možemo koristiti mogućnosti Kubernetesa: pokretanje kontejnera u jednom podu, u jednom procesu i/ili mrežnom prostoru. Zapravo predstavite svoje agente i obavite neke funkcije. A ako se isti kontejner pokrene u Dockeru, on će dobiti sve iste mogućnosti kao i izlaz, odnosno moći će da isporučuje evidencije i metrike, budući da će agenti biti pokrenuti interno. 

metrika i dnevnici

Isporuka metrike i dnevnika je složen zadatak. Postoji nekoliko aspekata njene odluke.
Infrastruktura je stvorena za izvršavanje tereta, a ne za masovnu isporuku trupaca. To jest, ovaj proces se mora izvesti s minimalnim zahtjevima za resursima kontejnera. Nastojimo pomoći našim programerima: “Nabavite Docker Hub kontejner, pokrenite ga i možemo isporučiti zapise.” 

Drugi aspekt je ograničavanje volumena trupaca. Ako dođe do porasta količine dnevnika u nekoliko kontejnera (aplikacija emituje stack-trace u petlji), povećava se opterećenje CPU-a, komunikacionih kanala i sistema za obradu dnevnika, a to utiče na rad hosta kao cijeli i drugi kontejneri na hostu, onda to ponekad dovodi do "pada" hosta. 

Treći aspekt je da je neophodno podržati što više metoda prikupljanja metrike iz kutije. Od čitanja datoteka i prozivanja Prometheus-krajnje točke do korištenja protokola specifičnih za aplikaciju.

I posljednji aspekt je minimiziranje potrošnje resursa.

Odabrali smo Go rješenje otvorenog koda pod nazivom Telegraf. Ovo je univerzalni konektor koji podržava više od 140 tipova ulaznih kanala (ulaznih dodataka) i 30 tipova izlaznih kanala (izlaznih dodataka). Završili smo ga i sada ćemo vam reći kako ga koristimo koristeći Kubernetes kao primjer. 

Recimo da programer implementira radno opterećenje, a Kubernetes primi zahtjev za kreiranje pod. U ovom trenutku, kontejner pod nazivom Collector se automatski kreira za svaki pod (koristimo mutacijski webhook). Kolekcionar je naš agent. Na početku, ovaj kontejner se konfiguriše da radi sa Prometheusom i sistemom prikupljanja dnevnika.

• Da bi to uradio, koristi pod napomene, i u zavisnosti od svog sadržaja, kreira, recimo, Prometheus krajnju tačku; 
• Na osnovu specifikacije pod i specifičnih postavki kontejnera, odlučuje kako će isporučiti dnevnike.

Prikupljamo zapisnike preko Docker API-ja: programeri ih samo trebaju staviti u stdout ili stderr, a Collector će to riješiti. Dnevnici se prikupljaju u komadima s određenim zakašnjenjem kako bi se spriječilo moguće preopterećenje hosta. 

Metrike se prikupljaju kroz instance radnog opterećenja (procese) u kontejnerima. Sve je označeno: imenski prostor, ispod i tako dalje, a zatim se konvertuje u Prometheus format - i postaje dostupno za prikupljanje (osim za dnevnike). Također šaljemo dnevnike, metriku i događaje Kafki i dalje:

• Dnevnici su dostupni u Graylogu (za vizuelnu analizu);
• Dnevnici, metrika, događaji se šalju u Clickhouse za dugotrajno skladištenje.

Sve radi potpuno isto u AWS-u, samo što Graylog zamjenjujemo Kafkom sa Cloudwatchom. Tamo šaljemo dnevnike i sve se ispostavilo vrlo zgodno: odmah je jasno kojem klasteru i kontejneru pripadaju. Isto važi i za Google Stackdriver. Odnosno, naša šema radi i lokalno sa Kafkom i u oblaku. 

Ako nemamo Kubernetes sa podovima, shema je malo složenija, ali radi na istim principima.

Isti procesi se izvode unutar kontejnera, oni su orkestrirani pomoću S6. Svi isti procesi se pokreću unutar istog kontejnera.

Kao rezultat toga,

Stvorili smo kompletno rješenje za izgradnju i pokretanje slika, s opcijama za prikupljanje i isporuku dnevnika i metrike:

• Razvili smo standardizovani pristup sastavljanju slika i na osnovu njega razvili CI šablone;
• Agenti za prikupljanje podataka su naša ekstenzija Telegrafa. Dobro smo ih testirali u proizvodnji;
• Koristimo mutacijski webhook za implementaciju kontejnera sa agentima u podovima; 
• Integrisan u Kubernetes/Rancher ekosistem;
• Možemo izvršiti iste kontejnere u različitim sistemima orkestracije i dobiti rezultat koji očekujemo;
• Napravljena je potpuno dinamička konfiguracija upravljanja kontejnerima. 

Koautor: Ilya Prudnikov

izvor: www.habr.com