Istorio hau ekoizpen-ingurunean edukiontziak nola erabiltzen ditugun aztertzen da, Kubernetes-en zehazki. Artikulua edukiontzietatik neurketak eta erregistroak biltzera bideratzen da, baita irudiak eraikitzera ere.

Exness fintech konpainiakoak gara, eta B2B eta B2Crako lineako merkataritzarako zerbitzuak eta fintech produktuak garatzen ditu. Gure I+G-k hainbat talde ditu, garapen sailak 100 langile baino gehiago ditu.

Gure garatzaileek kodea bildu eta exekutatzeko plataformaz arduratzen den taldea ordezkatzen dugu. Bereziki, aplikazioetako neurketak, erregistroak eta gertaerak biltzeaz, gordetzeaz eta jakinarazteaz arduratzen gara. Gaur egun, gutxi gorabehera hiru mila Docker edukiontzi lantzen ditugu produkzio-ingurune batean, gure 50 TB-ko datu-biltegiratzea mantentzen dugu eta gure azpiegituraren inguruan eraikitako arkitektura-soluzioak eskaintzen ditugu: Kubernetes, Rancher eta hodei publikoko hainbat hornitzaile. 

Gure motibazioa

Zer da erretzen? Inork ezin du erantzun. Non dago sutegia? Zaila da ulertzea. Noiz hartu zuen su? Jakin dezakezu, baina ez berehala. 

Zergatik daude edukiontzi batzuk zutik beste batzuk erori diren bitartean? Zein edukiontzi zuen errua? Azken finean, edukiontzien kanpoaldea berdinak dira, baina barruan bakoitzak bere Neo-a dauka.

Gure garatzaileak mutil konpetenteak dira. Enpresari irabaziak ekartzen dizkioten zerbitzu onak egiten dituzte. Baina hutsegiteak daude aplikazioak dituzten edukiontziak okertzen direnean. Edukiontzi batek CPU gehiegi kontsumitzen du, beste batek sarea kontsumitzen du, hirugarren batek I/O eragiketak kontsumitzen ditu eta laugarrenak erabat ez du argi zer egiten duen socketekin. Dena erori eta ontzia hondoratu egiten da. 

Eragileak

Barruan gertatzen dena ulertzeko, agenteak zuzenean edukiontzietan jartzea erabaki dugu.

Agente hauek edukiontziak elkar apurtzen ez duten egoera batean mantentzen dituzten murrizketa programak dira. Agenteak normalizatuta daude, eta horrek edukiontziak zaintzeko ikuspegi normalizatu bat ahalbidetzen du. 

Gure kasuan, agenteek formatu estandar batean eman behar dituzte erregistroak, etiketatuta eta mugatuta. Negozio-aplikazioaren ikuspegitik hedagarriak diren neurri estandarizatuak ere eman behar dizkigute.

Agenteek irudi desberdinak onartzen dituzten orkestrazio-sistema desberdinetan (Debian, Alpine, Centos, etab.) funtziona dezaketen funtzionamendurako eta mantentzerako utilitateak ere esan nahi dituzte.

Azkenik, agenteek Docker fitxategiak barne hartzen dituzten CI/CD sinpleak onartu behar dituzte. Bestela, ontzia erori egingo da, edukiontziak errail "makur"etatik ateratzen hasiko direlako.

Eraiki prozesua eta helburu irudi gailua

Dena estandarizatua eta kudeagarria izateko, eraikuntza prozesu estandarren bat jarraitu behar da. Hori dela eta, edukiontziak edukiontziz biltzea erabaki genuen - hori errekurtsioa da.

Hemen edukiontziak eskema sendoen bidez irudikatzen dira. Aldi berean, banaketa-kitak jartzea erabaki zuten, "bizitzak mugurdirik ez izan dezan". Zergatik egin zen hau, jarraian azalduko dugu.
 
Emaitza eraikitze-tresna bat da, banaketa-bertsio zehatzak eta script-bertsio zehatzak aipatzen dituen bertsio zehatzeko edukiontzi bat.

Nola erabiltzen dugu? Edukiontzi bat daukan Docker Hub bat dugu. Gure sistemaren barruan ispilu egiten dugu kanpoko mendekotasunak kentzeko. Emaitza horiz markatutako ontzi bat da. Txantiloi bat sortzen dugu edukiontzian behar ditugun banaketa eta script guztiak instalatzeko. Horren ostean, erabiltzeko prest dagoen irudi bat muntatzen dugu: garatzaileek kodea eta beren menpekotasun berezi batzuk jartzen dituzte bertan. 

Zer da ona planteamendu honek? 

• Lehenik eta behin, eraikitzeko tresnen bertsio osoa kontrolatzea: edukiontzi, script eta banaketa bertsioak eraiki. 
• Bigarrenik, estandarizazioa lortu dugu: txantiloiak, bitartekoak eta erabiltzeko prest dauden irudiak era berean sortzen ditugu. 
• Hirugarrenik, edukiontziak eramangarritasuna ematen digu. Gaur Gitlab erabiltzen dugu, eta bihar TeamCity edo Jenkins-era aldatuko gara eta gure edukiontziak era berean exekutatu ahal izango ditugu. 
• Laugarrena, mendekotasunak gutxitzea. Ez da kasualitatea izan banaketa-kitak edukiontzian sartzea, horrek aukera ematen baitu aldi bakoitzean Internetetik deskargatzea. 
• Bosgarrenik, eraikitze-abiadura handitu egin da - irudien kopia lokalak egoteak deskargatzeko denbora galtzea saihesteko aukera ematen du, tokiko irudi bat baitago. 

Hau da, muntaketa prozesu kontrolatu eta malgua lortu dugu. Tresna berberak erabiltzen ditugu guztiz bertsiotutako edukiontzi guztiak eraikitzeko. 

Gure eraikuntza-prozedura nola funtzionatzen duen

Muntaia komando batekin abiarazten da, prozesua irudian exekutatzen da (gorriz nabarmenduta). Garatzaileak Docker fitxategi bat du (horiz nabarmenduta), errendatzen dugu, aldagaiak balioekin ordezkatuz. Eta bidean goiburuak eta oinak gehitzen ditugu - hauek dira gure eragileak. 

Goiburukoak dagozkien irudien banaketak gehitzen ditu. Eta footer-ek gure zerbitzuak barnean instalatzen ditu, lan-karga, erregistroa eta beste agente batzuk abiarazteko konfiguratzen du, sarrera-puntua ordezkatzen du, etab. 

Denbora luzez pentsatu genuen begirale bat instalatu ala ez. Azkenean, hura behar genuela erabaki genuen. S6 aukeratu dugu. Begiraleak edukiontzien kudeaketa eskaintzen du: prozesu nagusiak huts egiten badu bertara konektatzeko aukera ematen du eta edukiontziaren eskuzko kudeaketa eskaintzen du birsortu gabe. Erregistroak eta neurketak edukiontzi barruan exekutatzen diren prozesuak dira. Horiek ere nolabait kontrolatu behar dira, eta hori begirale baten laguntzarekin egiten dugu. Azkenik, S6-k etxeko garbiketaz, seinaleen prozesamenduaz eta beste zereginez arduratzen da.

Orkestrazio sistema desberdinak erabiltzen ditugunez, eraiki eta martxan jarri ondoren, edukiontziak zer ingurunetan dagoen ulertu behar du eta egoeraren arabera jokatu. Adibidez:
Horri esker, irudi bat eraiki eta orkestrazio sistema ezberdinetan exekutatu dezakegu, eta orkestrazio sistema honen berezitasunak kontuan hartuta abiaraziko da.

 

Edukiontzi bererako prozesu zuhaitz desberdinak lortzen ditugu Docker eta Kubernetes-en:

Karga erabilgarria S6-ren gainbegiratuta exekutatzen da. Erreparatu biltzaileei eta gertaerei - hauek dira erregistro eta neurketen arduradunak gure agenteak. Kubernetes-ek ez ditu, baina Docker-ek bai. Zergatik? 

"Pod"-aren (aurrerantzean - Kubernetes pod) zehaztapenari erreparatzen badiogu, gertaeren edukiontzia pod batean exekutatzen dela ikusiko dugu, neurgailuak eta erregistroak biltzeko funtzioa betetzen duen biltzaile-edukiontzi bereizia duena. Kubernetesen gaitasunak erabil ditzakegu: edukiontziak pod batean exekutatu, prozesu eta/edo sareko espazio bakarrean. Egiaz aurkeztu zure agenteak eta egin funtzio batzuk. Eta Docker-en edukiontzi bera abiarazten bada, irteeraren gaitasun berdinak jasoko ditu, hau da, erregistroak eta neurketak entregatu ahal izango ditu, agenteak barnean abiaraziko baitira. 

Metrikoak eta erregistroak

Neurri eta erregistroak ematea lan konplexua da. Bere erabakiak hainbat alderdi ditu.
Azpiegitura karga exekutatzeko sortzen da, eta ez erregistroak masiboki bidaltzeko. Hau da, prozesu hau edukiontzien baliabideen eskakizun minimoekin egin behar da. Gure garatzaileei laguntzen ahalegintzen gara: "Lortu Docker Hub edukiontzi bat, exekutatu eta erregistroak entregatu ditzakegu". 

Bigarren alderdia erregistroen bolumena mugatzea da. Erregistroen bolumenaren gorakada bat gertatzen bada hainbat edukiontzitan (aplikazioak pila-traza bistaratzen du begizta batean), PUZaren, komunikazio-kanalen eta erregistroak prozesatzeko sistemaren karga handitu egiten da, eta horrek ostalariaren funtzionamenduari eragiten dio. ostalariaren gainean edukiontziak osoak eta beste batzuk, eta, batzuetan, horrek ostalariaren "erortzea" dakar. 

Hirugarren alderdia da beharrezkoa dela kutxatik kanpo ahalik eta metrika biltzeko metodo gehien onartzea. Fitxategiak irakurtzetik eta Prometheus-endpoint-en galdeketatik aplikazio espezifikoen protokoloak erabiltzera.

Eta azken alderdia baliabideen kontsumoa gutxitzea da.

Telegraf izeneko kode irekiko Go irtenbide bat aukeratu dugu. Konektore unibertsala da, 140 sarrera-kanal mota baino gehiago (sarrera-pluginak) eta 30 motatako irteera-kanal (irteera-pluginak) onartzen dituena. Amaitu dugu eta orain esango dizugu nola erabiltzen dugun Kubernetes adibide gisa erabiliz. 

Demagun garatzaile batek lan-karga bat zabaltzen duela eta Kubernetes-ek pod bat sortzeko eskaera jasotzen duela. Une honetan, Collector izeneko edukiontzi bat sortzen da automatikoki pod bakoitzeko (mutazio webhook erabiltzen dugu). Bilduma gure agentea da. Hasieran, edukiontzi hau Prometheus-ekin eta erregistroak biltzeko sistemarekin lan egiteko konfiguratzen da.

• Horretarako, pod oharrak erabiltzen ditu, eta bere edukiaren arabera, Prometheus amaiera-puntua sortzen du, esate baterako; 
• Podaren zehaztapenetan eta edukiontzien ezarpen zehatzetan oinarrituta, erregistroak nola entregatu erabakitzen du.

Erregistroak Docker APIaren bidez biltzen ditugu: garatzaileek stdout edo stderr-en jarri besterik ez dute egin behar, eta Collector-ek ordenatuko du. Erregistroak zatika biltzen dira atzerapenarekin ostalariaren gainkarga saihesteko. 

Edukiontzietan lan-karga-instantzia (prozesu) guztietan biltzen dira neurketak. Dena etiketatuta dago: izen-espazioa, azpian, eta abar, eta gero Prometheus formatura bihurtzen da, eta biltzeko erabilgarri egongo da (erregistroak izan ezik). Erregistroak, neurketak eta gertaerak ere bidaltzen ditugu Kafkari eta gehiago:

• Erregistroak eskuragarri daude Graylog-en (ikusmen-analisirako);
• Erregistroak, neurketak eta gertaerak Clickhouse-ra bidaltzen dira epe luzerako biltegiratzeko.

Guztiak berdin funtzionatzen du AWS-en, bakarrik Graylog ordezkatzen dugu Kafka-rekin Cloudwatch-ekin. Erregistroak hara bidaltzen ditugu, eta dena oso erosoa bihurtzen da: berehala argitzen da zein kluster eta edukiontzitakoak diren. Gauza bera gertatzen da Google Stackdriver-ekin. Hau da, gure eskemak Kafkarekin lokalean zein hodeian funtzionatzen du. 

Kubernetes ez badugu podekin, eskema apur bat konplikatuagoa da, baina printzipio berdinekin funtzionatzen du.

Prozesu berdinak edukiontzi barruan exekutatzen dira, S6 erabiliz orkestratzen dira. Prozesu berdinak edukiontzi berean exekutatzen ari dira.

Baten ondorioz,

Irudiak eraikitzeko eta abiarazteko irtenbide oso bat sortu dugu, erregistroak eta neurketak biltzeko eta entregatzeko aukerekin:

• Irudiak muntatzeko ikuspegi estandarizatu bat garatu genuen, eta horretan oinarrituta CI txantiloiak garatu genituen;
• Datuak biltzeko agenteak gure Telegraf luzapenak dira. Ekoizpenean ondo probatu ditugu;
• Mutazio webhook erabiltzen dugu ontzietan agenteekin edukiontziak ezartzeko; 
• Kubernetes/Rancher ekosisteman integratua;
• Edukiontzi berdinak orkestrazio sistema ezberdinetan exekutatu eta espero dugun emaitza lor dezakegu;
• Edukiontzien kudeaketaren konfigurazio guztiz dinamikoa sortu da. 

Egilekidea: Ilya Prudnikov

Iturria: www.habr.com