Ta zgodba govori o tem, kako uporabljamo vsebnike v proizvodnem okolju, natančneje Kubernetes. Članek je posvečen zbiranju metrik in dnevnikov iz vsebnikov ter gradnji slik.

Smo iz fintech podjetja Exness, ki razvija storitve za spletno trgovanje in fintech produkte za B2B in B2C. Naše raziskave in razvoj imajo veliko različnih ekip, razvojni oddelek ima več kot 100 zaposlenih.

Predstavljamo ekipo, ki je odgovorna za platformo za naše razvijalce za zbiranje in izvajanje kode. Zlasti smo odgovorni za zbiranje, shranjevanje in poročanje meritev, dnevnikov in dogodkov iz aplikacij. Trenutno upravljamo približno tri tisoč vsebnikov Docker v produkcijskem okolju, vzdržujemo 50 TB prostora za shranjevanje velikih podatkov in zagotavljamo arhitekturne rešitve, ki so zgrajene okoli naše infrastrukture: Kubernetes, Rancher in različni ponudniki javnih oblakov. 

Naša motivacija

Kaj gori? Nihče ne more odgovoriti. Kje je ognjišče? Težko je razumeti. Kdaj je zagorelo? Lahko ugotovite, vendar ne takoj. 

Zakaj nekateri zabojniki stojijo, drugi pa so padli? Kateri zabojnik je bil kriv? Navsezadnje so posode navzven enake, znotraj pa ima vsaka svojega Neo.

Naši razvijalci so kompetentni fantje. Delajo dobre storitve, ki prinašajo dobiček podjetju. Vendar pa pride do napak, ko vsebniki z aplikacijami zaidejo. En vsebnik porablja preveč CPU-ja, drugi porablja omrežje, tretji porablja V/I operacije, četrti pa je povsem nejasno, kaj počne s socketi. Vse pade in ladja se potopi. 

Agenti

Da bi razumeli, kaj se dogaja v notranjosti, smo se odločili, da sredstva postavimo neposredno v zabojnike.

Ti agenti so zadrževalni programi, ki ohranjajo posode v takšnem stanju, da se med seboj ne zlomijo. Agenti so standardizirani, kar omogoča standardiziran pristop k servisiranju kontejnerjev. 

V našem primeru morajo agenti zagotoviti dnevnike v standardnem formatu, označene in dušene. Prav tako bi nam morali zagotoviti standardizirane meritve, ki so razširljive z vidika poslovne aplikacije.

Agenti pomenijo tudi pripomočke za delovanje in vzdrževanje, ki lahko delujejo v različnih orkestracijskih sistemih, ki podpirajo različne slike (Debian, Alpine, Centos itd.).

Končno morajo agenti podpirati preprost CI/CD, ki vključuje datoteke Docker. V nasprotnem primeru bo ladja razpadla, ker se bodo kontejnerji začeli dostavljati po "krivih" tirnicah.

Postopek gradnje in ciljna slikovna naprava

Da bi bilo vse standardizirano in obvladljivo, je treba slediti nekemu standardnemu procesu gradnje. Zato smo se odločili zbirati kontejnerje po kontejnerjih - to je rekurzija.

Tukaj so posode predstavljene s polnimi obrisi. Hkrati so se odločili, da bodo vanje vstavili distribucijske komplete, da »življenje ne bo videti kot maline«. Zakaj je bilo to storjeno, bomo razložili v nadaljevanju.
 
Rezultat je orodje za gradnjo – vsebnik, specifičen za različico, ki se sklicuje na specifične različice distribucije in specifične različice skripta.

Kako ga uporabljamo? Imamo Docker Hub, ki vsebuje vsebnik. Zrcalimo ga znotraj našega sistema, da se znebimo zunanjih odvisnosti. Rezultat je rumeno označena posoda. Ustvarimo predlogo za namestitev vseh distribucij in skriptov, ki jih potrebujemo v vsebnik. Po tem sestavimo sliko, pripravljeno za uporabo: razvijalci vanjo vstavijo kodo in nekaj svojih posebnih odvisnosti. 

Kaj je dobrega pri tem pristopu? 

• Prvič, popoln nadzor nad različicami orodij za gradnjo – vsebnik za gradnjo, skript in različice distribucije. 
• Drugič, dosegli smo standardizacijo: na enak način ustvarjamo predloge, vmesno in za uporabo pripravljeno sliko. 
• Tretjič, kontejnerji nam omogočajo prenosljivost. Danes uporabljamo Gitlab, jutri pa bomo prešli na TeamCity ali Jenkins in bomo lahko poganjali svoje kontejnerje na enak način. 
• Četrtič, zmanjševanje odvisnosti. Ni bilo naključje, da smo distribucijske komplete postavili v zabojnik, saj se tako izognemo vsakokratnemu nalaganju le-teh s spleta. 
• Petič, hitrost gradnje se je povečala - prisotnost lokalnih kopij slik vam omogoča, da se izognete izgubi časa pri prenosu, saj obstaja lokalna slika. 

Z drugimi besedami, dosegli smo nadzorovan in fleksibilen proces montaže. Uporabljamo ista orodja za izdelavo vseh vsebnikov s polno različico. 

Kako deluje naš postopek gradnje

Sestav zaženemo z enim ukazom, proces se izvede na sliki (označeno rdeče). Razvijalec ima datoteko Docker (označeno rumeno), mi jo upodabljamo in spremenljivke zamenjamo z vrednostmi. In ob tem dodajamo glave in noge - to so naši agenti. 

Glava doda distribucije iz ustreznih slik. Noga pa namesti naše storitve v notranjost, konfigurira zagon delovne obremenitve, beleženje in druge agente, nadomesti vstopno točko itd. 

Dolgo smo razmišljali, ali bi namestili nadzornika. Na koncu smo se odločili, da ga potrebujemo. Izbrali smo S6. Nadzornik zagotavlja upravljanje vsebnika: omogoča povezavo z njim, če se glavni proces zruši, in zagotavlja ročno upravljanje vsebnika, ne da bi ga znova ustvarili. Dnevniki in metrike so procesi, ki tečejo znotraj vsebnika. Nekako jih je treba tudi nadzorovati in to počnemo s pomočjo supervizorja. Nazadnje S6 skrbi za gospodinjstvo, obdelavo signalov in druge naloge.

Ker uporabljamo različne sisteme orkestracije, mora vsebnik po izgradnji in delovanju razumeti, v kakšnem okolju je, in delovati v skladu s situacijo. Na primer:
To nam omogoča, da zgradimo eno sliko in jo izvajamo v različnih orkestracijskih sistemih, zagnati pa se bo ob upoštevanju posebnosti tega orkestracijskega sistema.

 

Za isti vsebnik dobimo različna procesna drevesa v Dockerju in Kubernetesu:

Obremenitev se izvaja pod nadzorom S6. Bodite pozorni na zbiralnike in dogodke - to so naši agenti, odgovorni za dnevnike in metrike. Kubernetes jih nima, Docker pa jih ima. Zakaj? 

Če pogledamo specifikacijo “poda” (v nadaljevanju – Kubernetes pod), bomo videli, da se vsebnik dogodkov izvaja v podu, ki ima ločen zbiralni vsebnik, ki opravlja funkcijo zbiranja metrik in dnevnikov. Uporabimo lahko zmožnosti Kubernetesa: poganjanje vsebnikov v enem sklopu, v enem procesu in/ali omrežnem prostoru. Pravzaprav predstavite svoje agente in opravite nekatere funkcije. In če se isti vsebnik zažene v Dockerju, bo prejel vse enake zmogljivosti kot izhod, kar pomeni, da bo lahko dostavil dnevnike in metrike, saj bodo agenti zagnani interno. 

Metrike in dnevniki

Dostava metrik in dnevnikov je zapletena naloga. Njena odločitev je več vidikov.
Infrastruktura je ustvarjena za izvajanje tovora in ne za množično dostavo hlodovine. To pomeni, da mora biti ta postopek izveden z minimalnimi zahtevami glede virov vsebnika. Prizadevamo si pomagati našim razvijalcem: "Pridobite vsebnik Docker Hub, zaženite ga in lahko dostavimo dnevnike." 

Drugi vidik je omejitev količine hlodov. Če pride do povečanja količine dnevnikov v več vsebnikih (aplikacija v zanki izpiše sled sklada), se poveča obremenitev CPE-ja, komunikacijskih kanalov in sistema za obdelavo dnevnikov, kar vpliva na delovanje gostitelja kot cele in drugih vsebnikov na gostitelju, potem včasih to privede do "padca" gostitelja. 

Tretji vidik je, da je treba čim več načinov zbiranja metrik podpirati takoj. Od branja datotek in anketiranja končne točke Prometheus do uporabe protokolov, specifičnih za aplikacijo.

In zadnji vidik je zmanjšanje porabe virov.

Izbrali smo odprtokodno rešitev Go z imenom Telegraf. To je univerzalni konektor, ki podpira več kot 140 vrst vhodnih kanalov (vhodni vtičniki) in 30 vrst izhodnih kanalov (izhodni vtičniki). Dokončali smo ga in zdaj vam bomo povedali, kako ga uporabljamo na primeru Kubernetesa. 

Recimo, da razvijalec razmesti delovno obremenitev in Kubernetes prejme zahtevo za ustvarjanje poda. Na tej točki se samodejno ustvari vsebnik z imenom Collector za vsak pod (uporabljamo webhook mutacije). Zbiralec je naš agent. Na začetku se ta vsebnik konfigurira za delo s Prometheusom in sistemom za zbiranje dnevnikov.

• Za to uporablja opombe podov in glede na svojo vsebino ustvari, recimo, končno točko Prometheus; 
• Na podlagi specifikacije stroka in posebnih nastavitev vsebnika se odloči, kako dostaviti dnevnike.

Dnevnike zbiramo prek API-ja Docker: razvijalci jih morajo le vnesti v stdout ali stderr in Collector jih bo uredil. Dnevniki se zbirajo v kosih z nekaj zamika, da se prepreči morebitna preobremenitev gostitelja. 

Meritve se zbirajo med primerki delovne obremenitve (procesi) v vsebnikih. Vse je označeno: imenski prostor, pod in tako naprej, nato pa pretvorjeno v format Prometheus - in postane na voljo za zbiranje (razen dnevnikov). Pošiljamo tudi dnevnike, metrike in dogodke Kafki in naprej:

• Dnevniki so na voljo v Graylogu (za vizualno analizo);
• Dnevniki, meritve, dogodki se pošljejo v Clickhouse za dolgoročno shranjevanje.

V AWS deluje vse popolnoma enako, le Graylog zamenjamo s Kafko z Cloudwatchom. Tja pošljemo dnevnike in vse se izkaže za zelo priročno: takoj je jasno, kateremu grozdu in vsebniku pripadajo. Enako velja za Google Stackdriver. To pomeni, da naša shema deluje tako na mestu uporabe s Kafko kot v oblaku. 

Če nimamo Kubernetesa s podi, je shema malo bolj zapletena, vendar deluje po enakih principih.

Isti procesi se izvajajo znotraj vsebnika, orkestrirani so z uporabo S6. V istem vsebniku tečejo vsi isti procesi.

Kot rezultat,

Ustvarili smo celovito rešitev za izdelavo in zagon slik z možnostmi zbiranja in dostave dnevnikov in meritev:

• Razvili smo standardiziran pristop k sestavljanju slik in na njegovi osnovi razvili CI predloge;
• Agenti za zbiranje podatkov so naše razširitve Telegrafa. Dobro smo jih preizkusili v proizvodnji;
• Za implementacijo vsebnikov z agenti v podih uporabljamo webhook mutacije; 
• Integriran v ekosistem Kubernetes/Rancher;
• Iste vsebnike lahko izvajamo v različnih sistemih orkestracije in dobimo rezultat, ki ga pričakujemo;
• Ustvaril popolnoma dinamično konfiguracijo upravljanja vsebnika. 

Soavtor: Ilja Prudnikov

Vir: www.habr.com