Nire izena Viktor Yagofarov da, eta Kubernetes plataforma garatzen ari naiz DomClick-en, Ops (eragiketa) taldeko garapen teknikoko arduradun gisa. Gure Dev <-> Ops prozesuen egituraz, Errusiako k8s kluster handienetako bat ustiatzeko ezaugarriez eta gure taldeak aplikatzen dituen DevOps/SRE praktikez hitz egin nahiko nuke.
Ops taldea
Gaur egun Ops taldeak 15 lagun ditu. Horietako hiru bulegoaz arduratzen dira, bik ordu-eremu ezberdin batean lan egiten dute eta eskuragarri daude, gauez barne. Horrela, Ops-eko norbait beti dago monitorean eta edozein konplexutasuneko gertakari bati erantzuteko prest. Ez dugu gaueko txandarik, eta horrek gure psikea gordetzen du eta denei aukera ematen die nahikoa lo egiteko eta aisialdia ordenagailuan ez ezik.
Pertsona orok konpetentzia desberdinak ditu: sareko arduradunak, DBAak, ELK pilako espezialistak, Kuberneteseko administratzaileak/garatzaileak, monitorizazioa, birtualizazioa, hardware espezialistak, etab. Gauza batek denak batzen ditu - denek gutako edozein ordezkatu dezakete neurri batean: adibidez, k8s klusterrean nodo berriak sartu, PostgreSQL eguneratu, CI/CD + Ansible kanalizazioa idatzi, Python/Bash/Go-n zerbait automatizatu, hardware-ra konektatu. Datu zentroa. Edozein arlotako gaitasun sendoek ez dizute eragozten zure jarduera-norabidea aldatzea eta beste arloren batean hobetzen hastea. Adibidez, enpresa batean sartu nintzen PostgreSQL espezialista gisa, eta orain nire ardura arlo nagusia Kubernetes klusterrak dira. Taldean, edozein altuera ongi etorria da eta palanka zentzua oso garatua dago.
Bide batez, ehizatzen ari gara. Hautagaientzako eskakizunak nahiko estandarrak dira. Niretzat, pertsonalki, garrantzitsua da pertsona bat taldean sartzea, gatazkarik ez izatea, baina baita bere ikuspuntua defendatzen jakitea, garatu nahi duena eta zerbait berria egiteko beldurrik ez izatea, bere ideiak eskaintzen dituena. Era berean, scripting lengoaietan programatzeko trebetasunak, Linux eta ingelesaren oinarrizko ezagutzak behar dira. Ingelesa behar da, besterik gabe, fakap baten kasuan, pertsona batek arazoaren konponbidea Googlen bila dezan 10 segundotan, eta ez 10 minututan. Gaur egun oso zaila da Linux-en ezagutza sakona duten espezialistak aurkitzea: dibertigarria da, baina hiru hautagaitik bik ezin diote erantzun “Zer da Load Average? Zerez egina dago?”, eta “Nola muntatu core dump bat C programa batetik” galdera supergizonen... edo dinosauroen munduko zerbait hartzen da. Honi eutsi behar diogu, normalean jendeak beste gaitasun batzuk oso garatuak baititu, baina Linux irakatsiko dugu. "DevOps ingeniari batek zergatik jakin behar du hau guztia hodeien mundu modernoan" galderari erantzuna artikuluaren esparrutik kanpo utzi beharko da, baina hiru hitzetan: hori guztia beharrezkoa da.
Taldeko tresnak
Tresnak taldeak zeregin garrantzitsua du automatizazioan. Beren zeregin nagusia garatzaileentzako tresna grafiko eta CLI erosoak sortzea da. Esate baterako, gure barne garapena Confer-ek aukera ematen dizu literalki aplikazio bat Kubernetesera zabaltzea saguaren klik gutxi batzuekin, bere baliabideak konfiguratzeko, gangako gakoak, etab. Aurretik, Jenkins + Helm 2 zegoen, baina nire tresna propioa garatu behar izan nuen kopiatu-itsatsi kentzeko eta softwarearen bizi-zikloari uniformetasuna emateko.
Ops taldeak ez du garatzaileentzako kanalizaziorik idazten, baina idatzitako edozein arazori buruzko aholkuak eman ditzake (batzuek Helm 3 dute oraindik).
DevOps
DevOps-i dagokionez, honela ikusten dugu:
Garatzaile-taldeek kodea idazten dute, zabaldu Confer to dev -> qa/stage -> prod. Kodeak moteltzen ez duela eta akatsik ez duela ziurtatzeko erantzukizuna Dev eta Ops taldeen dago. Egunez, Ops taldeko guardiako pertsonak, lehenik eta behin, bere aplikazioarekin gorabehera bati erantzun behar dio, eta arratsaldez eta gauez, guardiako administratzaileak (Ops) guardiako garatzailea esnatu beharko luke badaki. ziur arazoa ez dagoela azpiegituretan. Monitorizazioko neurketa eta alerta guztiak automatikoki edo erdi-automatikoki agertzen dira.
Ops-en ardura-eremua aplikazioa produkziora zabaltzen den unetik hasten da, baina Dev-en erantzukizuna ez da hor amaitzen - gauza bera egiten dugu eta itsasontzi berean gaude.
Garatzaileek administratzaileei aholkatzen diete administratzaileen mikrozerbitzu bat idazteko laguntza behar badute (adibidez, Go backend + HTML5), eta administratzaileek k8s-ekin lotutako azpiegitura-arazoei edo arazoei buruzko aholkuak ematen dizkiete garatzaileei.
Bide batez, ez dugu batere monolitorik, mikrozerbitzuak baizik. Haien kopurua orain arte 900 eta 1000 artean aldatzen da prod k8s multzoan, zenbakiz neurtzen bada. garapen. Leka kopurua 1700 eta 2000 artean aldatzen da. Gaur egun 2000 lek inguru daude prod multzoan.
Ezin dut zenbaki zehatzik eman, beharrezkoak ez diren mikrozerbitzuak kontrolatzen ditugu eta erdi-automatikoki mozten ditugu eta. K8sek beharrezkoak ez diren entitateen jarraipena egiten laguntzen digu , eta horrek baliabide eta diru asko aurrezten ditu.
Baliabideen kudeaketa
jarraipenaren
Jarraipen ondo egituratua eta informatiboa kluster handi baten funtzionamenduan oinarria bihurtzen da. Oraindik ez dugu aurkitu monitorizazio-behar guztien % 100 estaliko lukeen irtenbide unibertsala, beraz, aldian-aldian irtenbide pertsonalizatu desberdinak sortzen ditugu ingurune honetan.
- Zabbix. Jarraipen zaharra ona, batez ere azpiegituren egoera orokorraren jarraipena egiteko xedea duena. Nodo bat noiz hiltzen den esaten digu prozesatzeari, memoriari, diskoei, sareari, etab. Ez dago naturaz gaindiko ezer, baina agenteen DaemonSet bereizi bat ere badugu, zeinaren laguntzarekin, adibidez, klusterrean DNS-en egoera kontrolatzen dugu: coredns pod ergelak bilatzen ditugu, kanpoko ostalarien erabilgarritasuna egiaztatzen dugu. Badirudi zergatik kezkatu honekin, baina trafiko bolumen handiarekin osagai hau hutsegite larria da. Nik dagoeneko , nola borrokatu nintzen DNS errendimenduarekin kluster batean.
- Prometheus operadorea. Esportatzaile ezberdinen multzo batek klusterraren osagai guztien ikuspegi orokorra ematen du. Ondoren, hori guztia Grafanako aginte-panel handietan ikusten dugu, eta alertmanager erabiltzen dugu alertetarako.
Guretzat beste tresna erabilgarria izan zen . Hainbat aldiz idatzi genuen talde batek beste talde baten Sarrera bideak gainjartzen zituen egoera bat topatu genuenean, 50 aldiz akatsak eraginez. Orain, ekoizpenera zabaldu aurretik, garatzaileek inor ez dela kaltetuko egiaztatzen dute, eta nire taldearentzat tresna ona da Ingresses-en arazoen hasierako diagnostikoa egiteko. Dibertigarria da hasieran administratzaileentzat idatzita zegoela eta nahiko “baldarra” zirudien, baina garapen-taldeak tresnarekin maitemindu ondoren, asko aldatu zen eta ez zela “administratzaile batek administratzaileentzako web aurpegia egin zuen. ” Laster utziko dugu tresna hau eta horrelako egoerak balioztatuko dira hoditeria zabaldu baino lehen ere.
Taldeko baliabideak Kuboan
Adibideetan sartu baino lehen, baliabideak nola esleitzen ditugun azaltzea merezi du mikrozerbitzuak.
Zein taldek eta zein kantitatetan erabiltzen duten ulertzeko baliabideak (prozesadorea, memoria, SSD lokala), komando bakoitza berea esleitzen dugu namespace “Kuboan” eta prozesadoreari, memoriari eta diskoari dagokionez dituen ahalmen maximoak mugatu, aurretik taldeen beharrak aztertuta. Horren arabera, komando batek, oro har, ez du kluster osoa blokeatuko inplementatzeko, milaka nukleo eta memoria terabyte esleituz. Izen-espaziorako sarbidea AD bidez ematen da (RBAC erabiltzen dugu). Izen-espazioak eta haien mugak pull-eskaera baten bidez gehitzen dira GIT biltegian, eta gero dena automatikoki zabaltzen da Ansible kanalizazioaren bidez.
Talde bati baliabideak esleitzeko adibide bat:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Eskaerak eta mugak
kuboa" Eskaera erreserbatutako baliabideen kopurua da pod (docker edukiontzi bat edo gehiago) kluster batean. Muga bermatu gabeko gehienezko bat da. Askotan ikus dezakezu grafikoetan nola talde batzuek eskaera gehiegi ezarri dizkion bere aplikazio guztietarako eta ezin duela aplikazioa "Kuboan" zabaldu, bere izen-espazioko eskaera guztiak dagoeneko "agortu" direlako.
Egoera horretatik ateratzeko modu zuzena baliabideen benetako kontsumoa begiratu eta eskatutako kopuruarekin (Eskaera) alderatzea da.
Goiko pantaila-argazkietan ikus dezakezu "Eskatutako" CPUak hari kopuru errealarekin bat egiten dutela eta Mugek CPU hari kopuru erreala gainditu dezakete =)
Orain ikus ditzagun izen-espazio batzuk zehatz-mehatz (izenen espazioa kube-system aukeratu nuen - "Kuboaren" osagaien beraren sistemaren izen-espazioa) eta ikusi benetan erabilitako prozesadorearen denbora eta memoriaren erlazioa eskatutakoarekin:
Bistakoa da benetan erabiltzen dena baino memoria eta PUZ gehiago erreserbatuta daudela sistema zerbitzuetarako. Kube-sistemaren kasuan, hori justifikatuta dago: gertatu zen nginx ingress controller edo nodelocaldns-ek bere gailurrean CPUra jo eta RAM asko kontsumitzen zuela, beraz, hemen justifikatuta dago erreserba hori. Horrez gain, ezin gara azken 3 orduetako diagrametan fidatu: komeni da neurri historikoak denbora-tarte luzean ikustea.
"Gomendioen" sistema garatu zen. Esate baterako, hemen ikus dezakezu zein baliabide legokeen hobe "mugak" (baimendutako goiko barra) igotzea, "garatzea" gerta ez dadin: baliabide batek emandako denbora tartean CPU edo memoria gastatu duen unea eta "desizoztu" arte zain dago:
Eta hona hemen gosea moztu behar duten lekak:
Про itotzea + baliabideen jarraipena, artikulu bat baino gehiago idatz dezakezu, beraz, egin galderak iruzkinetan. Hitz gutxitan esan dezaket neurri horiek automatizatzeko lana oso zaila dela eta denbora asko eta orekatzeko ekintza eskatzen duela "leihoa" funtzioekin eta "CTE" Prometheus / VictoriaMetrics (termino hauek komatxo artean daude, ia baitago). PromQL-n ez dago horrelakorik, eta beldurgarriak diren kontsultak hainbat testu pantailatan banatu eta optimizatu behar dituzu).
Ondorioz, garatzaileek Cubeko izen-espazioak kontrolatzeko tresnak dituzte, eta beraiek aukera dezakete non eta zein ordutan zein aplikazio "moztu" izan ditzaketen baliabideak, eta zein zerbitzari eman diezaiekeen CPU osoa gau osoan.
Metodologiak
Orain dagoen bezala enpresan modan, DevOps-ekin bat egiten dugu eta SRE-praktikantea Enpresa batek 1000 mikrozerbitzu, 350 garatzaile inguru eta azpiegitura osorako 15 administratzaile dituenean, "modan" egon behar duzu: "Baswords" horien guztien atzean dena eta denak automatizatzeko premiazko beharra dago, eta administratzaileek ez lukete botila-lepoa izan behar. prozesuetan.
Ops gisa, zerbitzuen erantzun tasekin eta erroreekin lotutako hainbat neurketa eta panel eskaintzen ditugu garatzaileentzat.
Metodologiak erabiltzen ditugu, besteak beste: , и elkarrekin konbinatuz. Arbel kopurua murrizten saiatzen gara, begirada batean argi egon dadin zein zerbitzu ari den degradatzen (adibidez, erantzun kodeak segundoko, erantzun denbora 99. pertzentilean), etab. Arbel orokorretarako neurri berri batzuk beharrezkoak diren bezain laster, berehala marraztu eta gehitzen ditugu.
Hilabete daramat grafikorik marraztu gabe. Seinale ona da ziurrenik: "nahiak" gehienak dagoeneko gauzatu direla esan nahi du. Gertatu zen astean zehar gutxienez egunean behin grafiko berriren bat marraztuko nuela.
Ondorioz emaitza baliotsua da, orain garatzaileak oso gutxitan joaten direlako administratzaileengana "non begiratu nolabaiteko metrika" galderekin.
Ezarpena Zerbitzu Sarea izkinan dago eta denei bizitza askoz erraztu beharko lieke, Tresnetako lankideek "Pertsona osasuntsu baten Istio" abstraktua ezartzeko gertu daude dagoeneko: HTTP(k) eskaera bakoitzaren bizi-zikloa ikusgai egongo da monitorizazioan, eta Zerbitzuen arteko (eta ez bakarrik) elkarrekintzan zehar "zer fasetan hautsi zen dena" ulertzea beti izango da. Harpidetu DomClick zentroko albisteetara. =)
Kubernetes azpiegitura laguntza
Historikoki, adabakitutako bertsioa erabiltzen dugu Kubespray — Kubernetes hedatzeko, hedatzeko eta eguneratzeko Ansible rola. Noizbait, kubeadm ez ziren instalazioetarako laguntza moztu zen adar nagusitik, eta ez zen kubeadm-ra aldatzeko prozesua proposatu. Ondorioz, Southbridge konpainiak bere sardexka egin zuen (kubeadm laguntzarekin eta arazo larrietarako konponketa azkar batekin).
K8s kluster guztiak eguneratzeko prozesua honelakoa da:
- hartu Kubespray Southbridge-tik, egiaztatu gure hariarekin, Merjim.
- Eguneraketa zabaltzen ari gara Stress- “Kuboa”.
- Eguneraketa nodo bana zabaltzen dugu (Ansible-n hau "seriala: 1" da). dev- “Kuboa”.
- Eguneratzen dugu Prod larunbat arratsaldean nodo bana.
Etorkizunean ordezkatzeko asmoa dago Kubespray zerbait azkarrago eta joan kubeadm.
Guztira hiru "Kubo" ditugu: Stress, Dev eta Prod. Beste bat martxan jartzeko asmoa dugu (egonean beroa) Prod-“Kuboa” bigarren datu-zentroan. Stress и dev "makina birtualetan" bizi (oVirt for Stress eta VMWare cloud for Dev). Prod- "Cube" "metal hutsean" bizi da: 32 CPU hari, 64-128 GB memoria eta 300 GB SSD RAID 10 dituzten nodo berdinak dira - guztira 50 dira. Hiru nodo "mehe" "maisuei" eskainita daude Prod- “Cuba”: 16 GB memoria, 12 CPU hari.
Salmentetarako, nahiago dugu "metal hutsa" erabili eta alferrikako geruzak saihestu OpenStack: ez dugu "bizilagun zaratatsuak" eta CPUrik behar denbora lapurtu. Eta administrazioaren konplexutasuna gutxi gorabehera bikoiztu egiten da etxeko OpenStack-en kasuan.
CI/CD "Cubic" eta beste azpiegitura-osagai batzuetarako GIT zerbitzari bereizi bat erabiltzen dugu, Helm 3 (Helm 2-tik nahiko trantsizio mingarria izan zen, baina oso pozik gaude aukerekin atomikoa), Jenkins, Ansible eta Docker. Ezaugarrien adarrak eta ingurune desberdinetara hedatzea maite ditugu biltegi batetik.
Ondorioa
Hau da, orokorrean, DevOps prozesua DomClick-en nolakoa den eragiketen ingeniari baten ikuspegitik. Artikulua espero nuena baino tekniko txikiagoa izan da: beraz, jarraitu Habré-ko DomClick-eko albisteak: Kubernetes-i buruzko artikulu “hardcore” gehiago eta gehiago egongo dira.
Iturria: www.habr.com