Ova priča govori o tome kako koristimo spremnike u proizvodnom okruženju, posebno Kubernetes. Članak je posvećen prikupljanju metrika i zapisa iz spremnika, kao i izradi slika.

Mi smo iz fintech tvrtke Exness koja razvija usluge za online trgovanje i fintech proizvode za B2B i B2C. Naše istraživanje i razvoj ima mnogo različitih timova, razvojni odjel ima 100+ zaposlenika.

Predstavljamo tim koji je odgovoran za platformu za naše programere za prikupljanje i pokretanje koda. Konkretno, odgovorni smo za prikupljanje, pohranjivanje i izvješćivanje o mjernim podacima, zapisnicima i događajima iz aplikacija. Trenutačno upravljamo s približno tri tisuće Docker spremnika u proizvodnom okruženju, održavamo svoju pohranu velikih podataka od 50 TB i pružamo arhitektonska rješenja koja su izgrađena oko naše infrastrukture: Kubernetes, Rancher i razni pružatelji javnih oblaka. 

Naša motivacija

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

Zašto neki kontejneri stoje, a drugi su pali? Koji kontejner je bio kriv? Uostalom, spremnici su izvana isti, ali unutra svaki ima svoj Neo.

Naši programeri su kompetentni ljudi. Oni pružaju dobre usluge koje donose profit tvrtki. Ali postoje kvarovi kada spremnici s aplikacijama zalutaju. Jedan spremnik troši previše CPU-a, drugi troši mrežu, treći I/O operacije, a četvrti je potpuno nejasno što radi sa socketima. Sve padne i brod tone. 

Agenti

Kako bismo razumjeli što se događa unutra, odlučili smo staviti sredstva izravno u kontejnere.

Ovi agenti su obuzdavajući programi koji drže spremnike u takvom stanju da se međusobno ne lome. Agenti su standardizirani, a to omogućuje standardiziran pristup servisiranju kontejnera. 

U našem slučaju, agenti moraju dati zapisnike u standardnom formatu, označene i prigušene. Oni bi nam također trebali pružiti standardizirane 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 sustavima orkestracije koji podržavaju različite slike (Debian, Alpine, Centos, itd.).

Konačno, agenti moraju podržavati jednostavan CI/CD koji uključuje Docker datoteke. Inače će se brod raspasti, jer će se kontejneri početi isporučivati ​​po "krivim" tračnicama.

Proces izrade i ciljni slikovni uređaj

Kako bi sve ostalo standardizirano i upravljivo, potrebno je slijediti neku vrstu standardnog procesa izrade. Stoga smo odlučili sakupljati kontejnere po kontejnere - to je rekurzija.

Ovdje su spremnici predstavljeni čvrstim obrisima. Ujedno su odlučili u njih staviti distribucijske komplete kako "život ne bi izgledao kao maline". Zašto je to učinjeno, objasnit ćemo u nastavku.
 
Rezultat je alat za izradu—spremnik specifičan za verziju koji upućuje na specifične verzije distribucije i određene verzije skripte.

Kako ga koristimo? Imamo Docker Hub koji sadrži spremnik. Zrcalimo ga unutar našeg sustava kako bismo se riješili vanjskih ovisnosti. Rezultat je spremnik označen žutom bojom. Izrađujemo predložak za instaliranje svih distribucija i skripti koje su nam potrebne u spremnik. Nakon toga sastavljamo sliku spremnu za korištenje: programeri u nju stavljaju kod i neke svoje posebne ovisnosti. 

Što je dobro u ovom pristupu? 

• Prvo, puna kontrola verzije alata za izradu - spremnik za izgradnju, skripta i verzije distribucije. 
• Drugo, postigli smo standardizaciju: na isti način stvaramo predloške, srednju i sliku spremnu za korištenje. 
• Treće, kontejneri nam daju prenosivost. Danas koristimo Gitlab, a sutra ćemo se prebaciti na TeamCity ili Jenkins i moći ćemo pokretati naše kontejnere na isti način. 
• Četvrto, smanjivanje ovisnosti. Nismo slučajno stavili distribucijske pakete u spremnik, jer nam to omogućuje da ih svaki put izbjegnemo skidanjem s interneta. 
• Peto, povećala se brzina izrade - prisutnost lokalnih kopija slika omogućuje vam da izbjegnete gubljenje vremena na preuzimanje, budući da postoji lokalna slika. 

Drugim riječima, postigli smo kontroliran i fleksibilan proces montaže. Koristimo iste alate za izradu svih spremnika s potpunom verzijom. 

Kako funkcionira naš postupak izrade

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

Zaglavlje dodaje distribucije iz odgovarajućih slika. A podnožje instalira naše usluge unutra, konfigurira pokretanje radnog opterećenja, zapisivanja i drugih agenata, zamjenjuje ulaznu točku itd. 

Dugo smo razmišljali hoćemo li instalirati supervizora. Na kraju smo zaključili da nam on treba. Odabrali smo S6. Nadzornik osigurava upravljanje spremnikom: omogućuje vam da se povežete s njim ako se glavni proces sruši i omogućuje ručno upravljanje spremnikom bez ponovnog stvaranja. Dnevnici i metrika su procesi koji se izvode unutar spremnika. I njih treba nekako kontrolirati, a to radimo uz pomoć supervizora. Konačno, S6 se brine za održavanje, obradu signala i druge zadatke.

Budući da koristimo različite sustave 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ćuje da izgradimo jednu sliku i pokrenemo je u različitim sustavima orkestracije, a bit će pokrenuta uzimajući u obzir specifičnosti ovog sustava orkestracije.

 

Za isti spremnik dobivamo različita stabla procesa u Dockeru i Kubernetesu:

Korisni teret se izvršava pod nadzorom S6. Obratite pozornost na kolektore i događaje - to su naši agenti odgovorni za zapise i metriku. Kubernetes ih nema, ali Docker ih ima. Zašto? 

Ako pogledamo specifikaciju “poda” (u daljnjem tekstu – Kubernetes pod), vidjet ćemo da se spremnik događaja izvršava u podu, koji ima zaseban spremnik kolektora koji obavlja funkciju prikupljanja metrike i dnevnika. Možemo koristiti mogućnosti Kubernetesa: pokretanje spremnika u jednom podu, u jednom procesu i/ili mrežnom prostoru. Zapravo predstavite svoje agente i obavljajte neke funkcije. A ako se isti spremnik pokrene u Dockeru, dobit će sve iste mogućnosti kao izlaz, to jest, moći će isporučiti zapisnike i metriku, budući da će se agenti pokretati interno. 

Mjerni podaci i dnevnici

Isporuka metrike i zapisa složen je zadatak. Nekoliko je aspekata njezine odluke.
Infrastruktura je stvorena za izvršenje nosivosti, a ne za masovnu isporuku trupaca. To jest, ovaj se proces mora izvesti s minimalnim zahtjevima za resursima spremnika. Nastojimo pomoći našim razvojnim programerima: "Nabavite Docker Hub spremnik, pokrenite ga i možemo isporučiti zapise." 

Drugi aspekt je ograničavanje volumena trupaca. Ako dođe do porasta količine zapisa u nekoliko spremnika (aplikacija ispisuje stack-trace u petlji), povećava se opterećenje CPU-a, komunikacijskih kanala i sustava za obradu zapisa, a to utječe na rad hosta kao cijele i druge posude na hostu, ponekad to dovodi do "pada" hosta. 

Treći aspekt je da je potrebno podržati što je moguće više metoda prikupljanja metrika izvan okvira. Od čitanja datoteka i anketiranja krajnje točke Prometheusa do korištenja protokola specifičnih za aplikaciju.

I zadnji aspekt je minimiziranje potrošnje resursa.

Odabrali smo open-source Go rješenje pod nazivom Telegraf. Ovo je univerzalni priključak koji podržava više od 140 vrsta ulaznih kanala (ulazni dodaci) i 30 vrsta izlaznih kanala (izlazni dodaci). Dovršili smo ga i sada ćemo vam reći kako ga koristimo koristeći Kubernetes kao primjer. 

Recimo da programer implementira radno opterećenje i Kubernetes primi zahtjev za stvaranje pod-a. U ovom trenutku automatski se stvara spremnik pod nazivom Collector za svaki pod (koristimo mutacijski webhook). Kolekcionar je naš agent. Na početku se ovaj spremnik sam konfigurira za rad s Prometheusom i sustavom za prikupljanje dnevnika.

• Da bi to učinio, koristi primjedbe mahuna i, ovisno o sadržaju, stvara, recimo, krajnju točku Prometheusa; 
• Na temelju specifikacije modula i specifičnih postavki spremnika, odlučuje kako isporučiti zapise.

Prikupljamo zapisnike putem Docker API-ja: programeri ih samo trebaju staviti u stdout ili stderr, a Collector će to srediti. Dnevnici se prikupljaju u komadima s određenom odgodom kako bi se spriječilo moguće preopterećenje hosta. 

Mjerni podaci se prikupljaju preko instanci radnog opterećenja (procesa) u spremnicima. Sve je označeno: imenski prostor, ispod i tako dalje, a zatim se pretvara u Prometheus format - i postaje dostupno za prikupljanje (osim za zapisnike). Također šaljemo zapisnike, metriku i događaje Kafki i dalje:

• Dnevnici su dostupni u Graylogu (za vizualnu analizu);
• Dnevnici, metrika, događaji šalju se u Clickhouse za dugoročnu pohranu.

U AWS-u sve radi potpuno isto, samo što Graylog s Kafkom zamijenimo s Cloudwatchom. Tamo šaljemo zapise i sve ispada vrlo zgodno: odmah je jasno kojem klasteru i spremniku pripadaju. Isto vrijedi i za Google Stackdriver. Odnosno, naša shema radi i on-premise s Kafkom i u oblaku. 

Ako nemamo Kubernetes s podovima, shema je malo kompliciranija, ali radi na istim principima.

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

Kao rezultat toga,

Stvorili smo cjelovito rješenje za izradu i pokretanje slika, s opcijama za prikupljanje i isporuku zapisa i metrike:

• Razvili smo standardizirani pristup sastavljanju slika, a na temelju njega razvili smo CI predloške;
• Agenti za prikupljanje podataka naša su proširenja Telegrafa. Dobro smo ih testirali u proizvodnji;
• Koristimo webhook mutacije za implementaciju spremnika s agentima u podovima; 
• Integriran u ekosustav Kubernetes/Rancher;
• Možemo izvršiti iste spremnike u različitim sustavima orkestracije i dobiti rezultat koji očekujemo;
• Stvorena potpuno dinamička konfiguracija upravljanja spremnikom. 

Ko-autor: Ilja Prudnikov

Izvor: www.habr.com