ProHoster > Blogs > Administrācija > RažoÅ”anai gatavi attēli k8s

RažoÅ”anai gatavi attēli k8s

Å is stāsts ir par to, kā mēs izmantojam konteinerus ražoÅ”anas vidē, konkrēti Kubernetes. Raksts ir veltÄ«ts metriku un žurnālu apkopoÅ”anai no konteineriem, kā arÄ« attēlu veidoÅ”anai.

RažoÅ”anai gatavi attēli k8s

Mēs esam no fintech uzņēmuma Exness, kas izstrādā pakalpojumus tieÅ”saistes tirdzniecÄ«bai un fintech produktus B2B un B2C. MÅ«su pētniecÄ«bā un attÄ«stÄ«bā ir daudz dažādu komandu, attÄ«stÄ«bas nodaļā ir vairāk nekā 100 darbinieku.

Mēs pārstāvam komandu, kas ir atbildÄ«ga par platformu mÅ«su izstrādātājiem, lai apkopotu un palaistu kodu. Jo Ä«paÅ”i mēs esam atbildÄ«gi par metrikas, žurnālu un notikumu apkopoÅ”anu, uzglabāŔanu un ziņoÅ”anu no lietojumprogrammām. PaÅ”laik mēs izmantojam aptuveni trÄ«s tÅ«kstoÅ”us Docker konteineru ražoÅ”anas vidē, uzturam savu 50 TB lielo datu krātuvi un piedāvājam arhitektÅ«ras risinājumus, kas ir balstÄ«ti uz mÅ«su infrastruktÅ«ru: Kubernetes, Rancher un dažādiem publisko mākoņpakalpojumu sniedzējiem. 

Mūsu motivācija

Kas deg? Neviens nevar atbildēt. Kur ir pavards? GrÅ«ti saprast. Kad tas aizdegās? To var uzzināt, bet ne uzreiz. 

RažoÅ”anai gatavi attēli k8s

Kāpēc daži konteineri stāv, bet citi ir nokrituÅ”i? KurÅ” konteiners bija vainÄ«gs? Galu galā konteineru ārpuse ir vienāda, bet iekÅ”pusē katram ir savs Neo.

RažoÅ”anai gatavi attēli k8s

MÅ«su izstrādātāji ir kompetenti puiÅ”i. Viņi sniedz labus pakalpojumus, kas nes peļņu uzņēmumam. Bet ir kļūmes, kad konteineri ar lietojumprogrammām apmaldās. Viens konteiners patērē pārāk daudz CPU, cits patērē tÄ«klu, treÅ”ais patērē I/O darbÄ«bas, un ceturtais ir pilnÄ«gi neskaidrs, ko tas dara ar ligzdām. Tas viss nokrÄ«t un kuÄ£is nogrimst. 

AÄ£enti

Lai saprastu, kas notiek iekŔā, nolēmām aÄ£entus ievietot tieÅ”i konteineros.

RažoÅ”anai gatavi attēli k8s

Å ie aÄ£enti ir ierobežojoÅ”as programmas, kas notur konteinerus tādā stāvoklÄ«, ka tie nesalauž viens otru. AÄ£enti ir standartizēti, un tas ļauj izmantot standartizētu pieeju konteineru apkalpoÅ”anai. 

MÅ«su gadÄ«jumā aÄ£entiem ir jānodroÅ”ina žurnāli standarta formātā, marķēti un ierobežoti. Viņiem arÄ« jānodroÅ”ina mums standartizēta metrika, kas ir paplaÅ”ināma no biznesa lietojumprogrammu perspektÄ«vas.

AÄ£enti nozÄ«mē arÄ« darbÄ«bas un uzturÄ“Å”anas utilÄ«tus, kas var darboties dažādās orÄ·estrÄ“Å”anas sistēmās, kas atbalsta dažādus attēlus (Debian, Alpine, Centos utt.).

Visbeidzot, aÄ£entiem ir jāatbalsta vienkārÅ”s CI/CD, kas ietver Docker failus. Pretējā gadÄ«jumā kuÄ£is sabruks, jo konteinerus sāks piegādāt pa ā€œgreizāmā€ sliedēm.

Veidojiet procesu un mērķa attēla ierīci

Lai viss bÅ«tu standartizēts un pārvaldāms, ir jāievēro sava veida standarta veidoÅ”anas process. Tāpēc nolēmām vākt konteinerus pa konteineriem ā€“ tā ir rekursija.

RažoÅ”anai gatavi attēli k8s

Å eit konteineri ir attēloti ar cietām kontÅ«rām. Tajā paŔā laikā viņi nolēma tajos ievietot izplatÄ«Å”anas komplektus, lai "dzÄ«ve neŔķistu kā avenes". Kāpēc tas tika darÄ«ts, mēs paskaidrosim tālāk.
 
Rezultāts ir veidoÅ”anas rÄ«ks ā€” versijai specifisks konteiners, kas atsaucas uz konkrētām izplatÄ«Å”anas versijām un konkrētām skriptu versijām.

Kā mēs to izmantojam? Mums ir Docker Hub, kurā ir konteiners. Mēs to atspoguļojam mÅ«su sistēmā, lai atbrÄ«votos no ārējām atkarÄ«bām. Rezultāts ir konteiners, kas apzÄ«mēts ar dzeltenu krāsu. Mēs izveidojam veidni, lai konteinerā instalētu visus nepiecieÅ”amos izplatÄ«jumus un skriptus. Pēc tam mēs apkopojam lietoÅ”anai gatavu attēlu: izstrādātāji tajā ievieto kodu un dažas savas Ä«paŔās atkarÄ«bas. 

Kas Å”ajā pieejā ir labs? 

  • Pirmkārt, pilna versijas kontrole bÅ«vÄ“Å”anas rÄ«kiem ā€“ bÅ«vkonteinera, skripta un izplatÄ«Å”anas versijas. 
  • Otrkārt, esam panākuÅ”i standartizāciju: veidojam veidnes, starpposma un lietoÅ”anai gatavu attēlu vienādi. 
  • TreÅ”kārt, konteineri mums nodroÅ”ina pārnesamÄ«bu. Å odien mēs izmantojam Gitlab, un rÄ«t mēs pārslēgsimies uz TeamCity vai Jenkins un varēsim darbināt savus konteinerus tādā paŔā veidā. 
  • Ceturtkārt, atkarÄ«bu samazināŔana. Nebija nejauŔība, ka konteinerā ievietojām izplatÄ«Å”anas komplektus, jo tas ļauj izvairÄ«ties no to lejupielādes no interneta katru reizi. 
  • Piektkārt, ir palielinājies veidoÅ”anas ātrums - vietējo attēlu kopiju klātbÅ«tne ļauj netērēt laiku lejupielādei, jo ir vietējais attēls. 

Citiem vārdiem sakot, esam panākuÅ”i kontrolētu un elastÄ«gu montāžas procesu. Mēs izmantojam tos paÅ”us rÄ«kus, lai izveidotu pilnÄ«gi versijas konteinerus. 

Kā darbojas mūsu veidoŔanas procedūra

RažoÅ”anai gatavi attēli k8s

Montāža tiek palaista ar vienu komandu, process tiek izpildÄ«ts attēlā (izcelts sarkanā krāsā). Izstrādātājam ir Docker fails (izcelts dzeltenā krāsā), mēs to renderējam, aizstājot mainÄ«gos ar vērtÄ«bām. Pa ceļam mēs pievienojam galvenes un kājenes ā€” tie ir mÅ«su aÄ£enti. 

Galvene pievieno sadalÄ«jumus no atbilstoÅ”ajiem attēliem. Un kājene instalē mÅ«su pakalpojumus iekŔā, konfigurē darba slodzes palaiÅ”anu, reÄ£istrÄ“Å”anu un citus aÄ£entus, aizstāj ieejas punktu utt. 

RažoÅ”anai gatavi attēli k8s

Ilgi domājām, vai uzstādÄ«t uzraugu. Galu galā mēs nolēmām, ka mums viņŔ ir vajadzÄ«gs. Mēs izvēlējāmies S6. Pārraugs nodroÅ”ina konteinera pārvaldÄ«bu: ļauj izveidot savienojumu ar to, ja pamatprocess avarē, un nodroÅ”ina konteinera manuālu pārvaldÄ«bu, to neizveidojot no jauna. Žurnāli un metrika ir procesi, kas darbojas konteinerā. Tās arÄ« kaut kā jākontrolē, un mēs to darām ar uzrauga palÄ«dzÄ«bu. Visbeidzot, S6 rÅ«pējas par mājturÄ«bu, signālu apstrādi un citiem uzdevumiem.

Tā kā mēs izmantojam dažādas orÄ·estrÄ“Å”anas sistēmas, tad pēc uzbÅ«vÄ“Å”anas un palaiÅ”anas konteineram ir jāsaprot, kādā vidē tas atrodas, un jārÄ«kojas atbilstoÅ”i situācijai. Piemēram:
Tas ļauj mums izveidot vienu attēlu un palaist to dažādās orÄ·estrÄ“Å”anas sistēmās, un tas tiks palaists, ņemot vērā Ŕīs orÄ·estrÄ“Å”anas sistēmas specifiku.

 RažoÅ”anai gatavi attēli k8s

Vienam un tam paÅ”am konteineram mēs iegÅ«stam dažādus procesa kokus Docker un Kubernetes:

RažoÅ”anai gatavi attēli k8s

Krava tiek izpildÄ«ta S6 uzraudzÄ«bā. Pievērsiet uzmanÄ«bu kolekcionāram un notikumiem ā€” tie ir mÅ«su aÄ£enti, kas atbild par žurnāliem un metriku. Kubernetes to nav, bet Docker ir. Kāpēc? 

Ja paskatāmies uz ā€œpodaā€ (turpmāk ā€“ Kubernetes pod) specifikāciju, tad redzēsim, ka notikumu konteiners tiek izpildÄ«ts podā, kuram ir atseviŔķs kolektora konteiners, kas pilda metriku un žurnālu savākÅ”anas funkciju. Mēs varam izmantot Kubernetes iespējas: darbināt konteinerus vienā podā, vienā procesā un/vai tÄ«kla telpā. PatiesÄ«bā iepazÄ«stiniet savus aÄ£entus un veiciet dažas funkcijas. Un, ja tas pats konteiners tiks palaists programmā Docker, tas saņems visas tās paÅ”as iespējas kā izvade, tas ir, tas varēs piegādāt žurnālus un metriku, jo aÄ£enti tiks palaisti iekŔēji. 

Metrika un žurnāli

Metrikas un žurnālu nodroÅ”ināŔana ir sarežģīts uzdevums. Viņas lēmumam ir vairāki aspekti.
InfrastruktÅ«ra ir izveidota lietderÄ«gās kravas izpildei, nevis baļķu masveida piegādei. Tas ir, Å”is process jāveic ar minimālām konteinera resursu prasÄ«bām. Mēs cenÅ”amies palÄ«dzēt saviem izstrādātājiem: ā€œIegÅ«stiet Docker Hub konteineru, palaidiet to, un mēs varam piegādāt žurnālus.ā€ 

Otrs aspekts ir apaļkoku apjoma ierobežoÅ”ana. Ja vairākos konteineros notiek žurnālu apjoma pieaugums (lietojumprogramma cilpā izvada steka izsekoÅ”anu), palielinās CPU, sakaru kanālu un žurnālu apstrādes sistēmas slodze, un tas ietekmē resursdatora darbÄ«bu. veseli un citi resursdatora konteineri, tad dažreiz tas noved pie saimniekdatora "kriÅ”anas". 

TreÅ”ais aspekts ir tāds, ka ir jāatbalsta pēc iespējas vairāk metrikas vākÅ”anas metožu. No failu lasÄ«Å”anas un Prometheus galapunkta aptaujas lÄ«dz lietojumprogrammu protokolu izmantoÅ”anai.

Un pēdējais aspekts ir līdz minimumam samazināt resursu patēriņu.

Mēs izvēlējāmies atvērtā koda Go risinājumu ar nosaukumu Telegraf. Å is ir universāls savienotājs, kas atbalsta vairāk nekā 140 veidu ievades kanālus (ievades spraudņus) un 30 veidu izvades kanālus (izejas spraudņus). Mēs esam to pabeiguÅ”i, un tagad mēs jums pastāstÄ«sim, kā mēs to izmantojam, izmantojot Kubernetes piemēru. 

RažoÅ”anai gatavi attēli k8s

Pieņemsim, ka izstrādātājs izvieto darba slodzi un Kubernetes saņem pieprasÄ«jumu izveidot podziņu. Å ajā brÄ«dÄ« katram podam automātiski tiek izveidots konteiners ar nosaukumu Collector (mēs izmantojam mutācijas tÄ«mekļa aizÄ·eri). Kolekcionārs ir mÅ«su aÄ£ents. Sākumā Å”is konteiners konfigurē sevi darbam ar Prometheus un žurnālu savākÅ”anas sistēmu.

  • Lai to izdarÄ«tu, tas izmanto pod anotācijas un atkarÄ«bā no tā satura izveido, teiksim, Prometheus beigu punktu; 
  • Pamatojoties uz apgabala specifikāciju un Ä«paÅ”iem konteinera iestatÄ«jumiem, tas izlemj, kā piegādāt žurnālus.

Mēs apkopojam žurnālus, izmantojot Docker API: izstrādātājiem tie vienkārÅ”i jāievieto stdout vai stderr, un Collector tos sakārtos. Žurnāli tiek savākti gabalos ar zināmu kavÄ“Å”anos, lai novērstu iespējamu resursdatora pārslodzi. 

Metrikas no darba slodzes gadÄ«jumiem (procesiem) tiek apkopotas konteineros. Viss ir atzÄ«mēts: nosaukumvieta, zem un tā tālāk, un pēc tam tiek pārveidots Prometheus formātā - un kļūst pieejams vākÅ”anai (izņemot žurnālus). Mēs arÄ« nosÅ«tām žurnālus, metriku un notikumus Kafka un tālāk:

  • Žurnāli ir pieejami Graylog (vizuālai analÄ«zei);
  • Žurnāli, metrika, notikumi tiek nosÅ«tÄ«ti uz Clickhouse ilgstoÅ”ai glabāŔanai.

AWS viss darbojas tieÅ”i tāpat, tikai mēs Graylog aizstājam ar Kafka ar Cloudwatch. Mēs tur nosÅ«tām žurnālus, un viss izrādās ļoti ērti: uzreiz ir skaidrs, pie kuras kopas un konteinera tie pieder. Tas pats attiecas uz Google Stackdriver. Tas nozÄ«mē, ka mÅ«su shēma darbojas gan uz vietas ar Kafka, gan mākonÄ«. 

Ja mums nav Kubernetes ar pākstÄ«m, shēma ir nedaudz sarežģītāka, taču tā darbojas pēc tiem paÅ”iem principiem.

RažoÅ”anai gatavi attēli k8s

Tie paÅ”i procesi tiek izpildÄ«ti konteinera iekÅ”pusē, tie tiek organizēti, izmantojot S6. Visi tie paÅ”i procesi darbojas vienā konteinerā.

Kā rezultātā,

Mēs esam izveidojuÅ”i pilnÄ«gu risinājumu attēlu veidoÅ”anai un palaiÅ”anai ar iespējām apkopot un piegādāt žurnālus un metriku:

  • Mēs izstrādājām standartizētu pieeju attēlu salikÅ”anai, un, pamatojoties uz to, mēs izstrādājām CI veidnes;
  • Datu vākÅ”anas aÄ£enti ir mÅ«su Telegraf paplaÅ”inājumi. Mēs tos labi pārbaudÄ«jām ražoÅ”anā;
  • Mēs izmantojam mutācijas tÄ«mekļa aizÄ·eri, lai ievietotu konteinerus ar aÄ£entiem pākstÄ«s; 
  • Integrēts Kubernetes/Rancher ekosistēmā;
  • Mēs varam izpildÄ«t vienus un tos paÅ”us konteinerus dažādās orÄ·estrÄ“Å”anas sistēmās un iegÅ«t gaidÄ«to rezultātu;
  • Izveidota pilnÄ«gi dinamiska konteineru pārvaldÄ«bas konfigurācija. 

Līdzautors: Iļja Prudņikovs

Avots: www.habr.com

Pievieno komentāru