Txostena Kubernetes-en operadore bat garatzeko, bere arkitektura eta oinarrizko funtzionamendu-printzipioak diseinatzeko gai praktikoei zuzenduta dago.
Txostenaren lehen zatian kontuan hartuko dugu:
- zer den Kubernetes-en operadore bat eta zergatik behar den;
- operadoreak sistema konplexuen kudeaketa nola errazten duen zehazki;
- operadoreak egin dezakeena eta ezin duena.
Jarraian, mugi gaitezen operadorearen barne egiturari buruz eztabaidatzera. Ikus ditzagun pausoz pauso operadorearen arkitektura eta funtzionamendua. Ikus dezagun zehatz-mehatz:
- operadorearen eta Kubernetesen arteko elkarrekintza;
- operadoreak zer funtzio hartzen dituen eta zer funtzio delegatzen dizkion Kubernetes-i.
Ikus dezagun Kubernetesen zatiak eta datu-baseen erreplikak kudeatzea.
Ondoren, datuak biltegiratzeko gaiak eztabaidatuko ditugu:
- nola lan egin Biltegiratze Iraunkorra operadorearen ikuspuntutik;
- Biltegiratze lokala erabiltzearen akatsak.
Txostenaren azken zatian, aplikazioaren adibide praktikoak hartuko ditugu kontuan Amazon edo Google Cloud Service-rekin. Txostena ClickHouse-rako operadore baten garapen eta ustiapen esperientziaren adibidean oinarritzen da.
Video:
Nire izena Vladislav Klimenko da. Gaur operadore bat garatzen eta ustiatzean dugun esperientziaz hitz egin nahi izan dut, eta hau datu-baseen klusterrak kudeatzeko operadore espezializatua da. Adibidez ClickHouse klusterra kudeatzeko.
Zergatik dugu aukera operadoreaz eta ClickHousez hitz egiteko?
- ClickHouse onartzen eta garatzen dugu.
- Momentuz, poliki-poliki ClickHouse-ren garapenean gure ekarpena egiten saiatzen ari gara. Eta Yandex-en atzetik bigarren gaude ClickHouse-n egindako aldaketen bolumenari dagokionez.
- ClickHouse ekosistemarako proiektu gehigarriak egiten saiatzen ari gara.
Proiektu hauetako baten berri eman nahiko nuke. Hau Kubernetes-eko ClickHouse-operadoreari buruzkoa da.
Nire txostenean bi gai ukitu nahiko nituzke:
- Lehenengo gaia gure ClickHouse datu-baseen kudeaketa-operadoreak Kubernetes-en nola funtzionatzen duen da.
- Bigarren gaia edozein operadore nola funtzionatzen duen da, hau da, Kubernetesekin nola elkarreragiten duen.
Hala ere, bi galdera hauek gurutzatuko dira nire txostenean zehar.
Nori interesatuko zaio kontatzen saiatzen ari naizena entzutea?
- Operadoreak lantzen dituztenentzat izango da interes handiena.
- Edo berea egin nahi dutenentzat, barnean nola funtzionatzen duen ulertzeko, operadoreak Kubernetesekin nola elkarreragiten duen eta zer hutsune ager daitezkeen ulertzeko.
Gaur eztabaidatuko duguna ondoen ulertzeko, komeni da Kubernetes-ek nola funtzionatzen duen jakitea eta hodeiko oinarrizko prestakuntzaren bat edukitzea.
Zer da ClickHouse? Kontsulta analitikoak linean prozesatzeko ezaugarri zehatzak dituen zutabe datu-base bat da. Eta guztiz kode irekia da.
Eta garrantzitsua da guretzat bi gauza baino ez jakitea. Hau datu-base bat dela jakin behar duzu, beraz, esango dizudana ia edozein datu basetan aplikagarria izango da. Eta ClickHouse DBMS oso ondo eskalatzen denak, eskalagarritasun ia lineala ematen du. Eta, beraz, kluster egoera ClickHouseren egoera naturala da. Eta Kubernetesen ClickHouse klusterra nola zerbitzatu eztabaidatzea interesatzen zaigu gehien.
Zergatik behar da han? Zergatik ezin dugu guk geuk ustiatzen jarraitu? Eta erantzunak neurri batean teknikoak eta hein batean antolakuntzakoak dira.
- Praktikan, gero eta gehiago aurkitzen gara enpresa handietan ia osagai guztiak dagoeneko Kubernetesen dauden egoera batekin. Datu-baseak kanpoan geratzen dira.
- Eta galdera gero eta gehiago egiten da: βBarruan jar daiteke hau?β. Hori dela eta, enpresa handiak kudeaketaren batasun handiena lortzen saiatzen ari dira, beren datu biltegiak azkar kudeatu ahal izateko.
- Eta horrek bereziki laguntzen du leku berri batean gauza bera errepikatzeko aukerarik handiena behar baduzu, hau da, eramangarritasun handiena.
Zein da erraza edo zaila? Hori, noski, eskuz egin daiteke. Baina ez da hain erraza, Kubernetes bera kudeatzeko konplexutasun gehigarria dugulako, baina, aldi berean, ClickHouseren berezitasunak gainjartzen dira. Eta halako batuketa baten ondorioz.
Eta horrek guztiak batera, teknologia multzo handi samarra ematen du, eta hori nahiko zaila da kudeatzea, Kubernetes-ek bere eguneroko arazoak ekartzen dituelako funtzionamendura, eta ClickHousek bere arazoak ekartzen dituelako eguneroko funtzionamendura. Batez ere hainbat ClickHouses baditugu, eta haiekin etengabe zerbait egin behar badugu.
Konfigurazio dinamiko batekin, ClickHouse-k DevOps-en etengabeko karga sortzen duten arazo kopuru nahiko handia du:
- ClickHousen zerbait aldatu nahi dugunean, adibidez, erreplika edo zati bat gehitu, orduan konfigurazioa kudeatu behar dugu.
- Ondoren, aldatu datuen eskema, ClickHousek zatiketa metodo zehatz bat duelako. Bertan datu-diagrama jarri behar duzu, konfigurazioak ezarri.
- Jarraipena ezarri behar duzu.
- Zati berrietarako erregistroak biltzea, erreplika berrietarako.
- Zaindu zaharberritzea.
- Eta berrabiarazi.
Oso errazago erabiltzea nahiko nukeen ohiko zereginak dira.
Kubernetesek berak ondo laguntzen du funtzionamenduan, baina sistemaren oinarrizko gauzetan.
Kubernetes ona da gauzak errazten eta automatizatzen:
- Errekuperazioa.
- Berriro hasi.
- Biltegiratze sistemaren kudeaketa.
Hori ona da, hori da norabide egokia, baina datu-baseen kluster bat nola funtzionatu behar duen ez du guztiz argi.
Gehiago nahi dugu, datu-base osoak Kubernetesen lan egitea nahi dugu.
Sakatzen duzun botoi gorri magiko handi baten moduko zerbait lortu nahiko nuke eta konpondu beharreko eguneroko zereginak dituen kluster bat zabaldu eta mantentzen da bere bizitza-ziklo osoan zehar. ClickHouse cluster Kubernetes-en.
Eta lana errazten lagunduko zuen irtenbide bat ematen saiatu ginen. Hau Altinity-ko Kubernetes-en ClickHouse-ko operadorea da.
Operadore bat beste programa batzuk kudeatzea duen zeregin nagusia den programa da, hau da, kudeatzailea da.
Eta portaera ereduak ditu. Irakasgaiari buruzko ezagutza kodetu horri dei diezaiokezu.
Eta bere zeregin nagusia DevOps-en bizitza erraztea eta mikrokudeaketa murriztea da, hark (DevOps) dagoeneko goi-mailako terminoetan pentsa dezan, hau da, berak (DevOps) mikrokudeaketan parte hartu ez dezan, konfiguratu ez dadin. xehetasun guztiak eskuz.
Eta operadorea mikrozereginez arduratzen den eta DevOps laguntzen duen robot laguntzailea da.
Zergatik behar duzu operadore bat? Bereziki ondo jokatzen du bi arlotan:
- ClickHouse-rekin aritzen den espezialistak behar adina esperientzia ez duenean, baina dagoeneko ClickHouse ustiatu behar duenean, operadoreak eragiketa errazten du eta ClickHouse kluster bat konfigurazio konplexu samarrean jarduteko aukera ematen du, dena nola funtzionatzen duen xehetasun gehiegi sartu gabe. barruan. Maila handiko zereginak besterik ez diozu ematen, eta funtzionatzen du.
- Eta ondoen egiten duen bigarren zeregina ohiko zeregin ugari automatizatzea beharrezkoa denean da. Sistema-administratzaileei mikrozereginak kentzen dizkie.
Hau da bidaia hasi berri dutenek edo automatizazio asko egin behar dutenek behar dute gehien.
Zertan desberdintzen da operadoreetan oinarritutako ikuspegia beste sistemetatik? Helm dago. ClickHouse instalatzen ere laguntzen du; lema-diagramak marraztu ditzakezu, eta horrek ClickHouse kluster osoa instalatuko du. Zein da, orduan, operadorearen eta beraren arteko aldea, adibidez, Helm?
Oinarrizko desberdintasun nagusia Helm paketeen kudeaketa dela eta Operator pauso bat haratago doala da. Bizitza-ziklo osorako laguntza da. Hau ez da instalazioa bakarrik, eguneroko zereginak dira eskalatzea, zatikatzea, hau da, bizitza-zikloan egin behar den guztia (beharrezkoa bada, gero ezabatzea ere) - hori guztia operadoreak erabakitzen du. Softwarearen bizi-ziklo osoa automatizatzen eta mantentzen saiatzen da. Hau da aurkezten diren beste soluzioekiko duen funtsezko aldea.
Hori izan zen sarrera zatia, goazen.
Nola eraikitzen dugu gure operadorea? ClickHouse klusterra baliabide bakar gisa kudeatzeko gaiari heltzen saiatzen ari gara.
Hemen irudiaren ezkerreko aldean sarrerako datuak ditugu. Hau kluster zehaztapen batekin YAML da, Kubernetesera modu klasikoan kubectl bidez pasatzen dena. Bertan gure operadoreak jaso eta bere magia egiten du. Eta irteeran hurrengo eskema lortuko dugu. Hau ClickHouse-ren inplementazioa da Kubernetes-en.
Eta gero, poliki-poliki, operadoreak nola funtzionatzen duen aztertuko dugu, zein ohiko zeregin konpon daitezkeen. Zeregin arruntak bakarrik hartuko ditugu kontuan, denbora mugatua dugulako. Eta operadoreak erabaki dezakeen guztia ez da eztabaidatuko.
Has gaitezen praktikatik. Gure proiektua guztiz irekia da, beraz, GitHub-en nola funtzionatzen duen ikus dezakezu. Eta abiarazi nahi baduzu, Abisu Bizkorreko Gidarekin has zaitezkeela kontuan hartu dezakezu.
Xehetasunez ulertu nahi baduzu, dokumentazioa gutxi-asko duin batean mantentzen saiatzen gara.
Has gaitezen arazo praktiko batekin. Lehenengo zeregina, denok hasi nahi dugun tokian, lehen adibidea nolabait exekutatu da. Nola abiarazi dezaket ClickHouse operadorea erabiliz, nola funtzionatzen duen benetan ez badakidan arren? Manifestu bat idazten ari gara, zeren... K8s-ekin komunikazio guztia manifestuen bidezko komunikazioa da.
Hain da manifestu konplexua. Gorriz nabarmendu duguna da arreta jarri behar duguna. Operadoreari demo izeneko kluster bat sortzeko eskatzen diogu.
Oinarrizko adibideak dira oraingoz. Biltegiratzea oraindik ez da deskribatu, baina pixka bat geroago itzuliko gara biltegiratzera. Oraingoz, klusterraren garapenaren dinamika behatuko dugu.
Manifestu hau sortu dugu. Gure operadoreari elikatzen diogu. Lan egin zuen, magia egiten zuen.
Kontsolara begiratzen dugu. Hiru osagai interesgarriak dira: Pod bat, bi Zerbitzu eta StatefulSet.
Operadoreak lan egin du, eta ikus dezakegu zer sortu duen zehazki.
Horrelako zerbait sortzen du. StatefulSet, Pod, ConfigMap bat dugu erreplika bakoitzeko, ConfigMap kluster osorako. Zerbitzuak beharrezkoak dira klusterrean sartzeko puntu gisa.
Zerbitzuak Load Balancer Zerbitzu zentrala dira eta erreplika bakoitzerako ere erabil daitezke, zati bakoitzeko.
Gure oinarrizko klusterrak horrelako zerbait du. Nodo bakarrekoa da.
Goazen harago eta zaildu gaitezen. Klusterra zatitu behar dugu.
Gure zereginak hazten ari dira, dinamikak hasten dira. Zati bat gehitu nahi dugu. Garapena jarraitzen dugu. Gure zehaztapena aldatzen ari gara. Bi zati nahi ditugula adierazten dugu.
Sistemaren hazkundearekin dinamikoki garatzen den fitxategi bera da. Biltegiratzea ez, biltegiratzea gehiago eztabaidatuko da, hau aparteko gaia da.
YAML operadorea elikatzen dugu eta zer gertatzen den ikusten dugu.
Operadoreak honako entitate hauek pentsatu eta egin zituen. Dagoeneko baditugu bi Pod, hiru Zerbitzu eta, bat-batean, 2 Stateful Set. Zergatik 2 StatefulSets?
Diagraman honela zegoen: hau da gure hasierako egoera, pod bat genuenean.
Horrela bihurtu zen. Orain arte dena sinplea da, bikoiztu egin da.
Eta zergatik bihurtu ziren bi StatefulSet? Hemen Kubernetesen Pods-ek nola kudeatzen diren aztertu behar dugu.
StatefulSet izeneko objektu bat dago, txantiloi batetik Pods multzo bat sortzeko aukera ematen duena. Hemen gakoa txantiloia da. Eta Pod asko abiarazi ditzakezu StatefulSet batean txantiloi bat erabiliz. Eta hemen esaldi gakoa "txantiloi bakarreko Pods asko" da.
Eta kluster osoa egiteko tentazio handia zegoen, StatefulSet batean bilduz. Funtzionatuko du, ez dago arazorik. Baina bada ohar bat. Cluster heterogeneo bat muntatu nahi badugu, hau da, ClickHouseren hainbat bertsiotatik, orduan galderak sortzen dira. Bai, StatefulSet-ek etengabeko eguneratze bat egin dezake, eta bertan bertsio berri bat atera dezakezu, azaldu behar duzula hainbeste nodo baino gehiago aldi berean probatu behar duzula.
Baina zeregina estrapolatu eta kluster guztiz heterogeneoa egin nahi dugula esaten badugu eta ez dugula bertsio zaharretik berrira aldatu nahi eguneraketa iraunkorra erabiliz, baizik eta kluster heterogeneo bat sortu nahi dugu bai terminoetan. ClickHouse-ren bertsio ezberdinen eta biltegiratze desberdinei dagokienez. Esaterako, erreplika batzuk egin nahi ditugu disko bereizietan, moteletan, orokorrean, kluster heterogeneo bat guztiz eraikitzeko. Eta StatefulSet-ek txantiloi batetik irtenbide estandarizatu bat egiten duelako, ez dago hori egiteko modurik.
Pentsatu ondoren, horrela egingo genuela erabaki zen. Erreplika bakoitza bere StatefulSet-ean dugu. Irtenbide honek eragozpen batzuk ditu, baina praktikan operadoreak guztiz kapsulatzen du dena. Eta abantaila asko daude. Nahi dugun kluster zehatza eraiki dezakegu, adibidez, guztiz heterogeneoa. Hori dela eta, erreplika bakarra duten bi zati ditugun kluster batean, 2 StatefulSet eta 2 Pod izango ditugu, hain zuzen, ikuspegi hau aukeratu dugulako goian adierazitako arrazoiengatik kluster heterogeneo bat eraiki ahal izateko.
Itzuli gaitezen arazo praktikoetara. Gure klusterrean erabiltzaileak konfiguratu behar ditugu, hau da. ClickHouse-ren konfigurazio bat egin behar duzu Kubernetes-en. Operadoreak horretarako aukera guztiak eskaintzen ditu.
Nahi duguna zuzenean idatzi dezakegu YAML-n. Konfigurazio-aukera guztiak YAML honetatik zuzenean mapatzen dira ClickHouse konfigurazioetara, gero kluster osoan banatzen direnak.
Honela idatz dezakezu. Hau da adibidez. Pasahitza zifratu daiteke. Erabat ClickHouse konfigurazio aukera guztiak onartzen dira. Hona hemen adibide bat.
Kluster konfigurazioa ConfigMap gisa banatzen da. Praktikan, ConfigMap eguneratzea ez da berehala gertatzen, beraz, kluster handia bada, konfigurazioa bultzatzeko prozesuak denbora pixka bat behar du. Baina hori guztia erabiltzeko oso erosoa da.
Zaildu dezagun zeregina. Klusterra garatzen ari da. Datuak errepikatu nahi ditugu. Hau da, dagoeneko baditugu bi zati, erreplika bana, eta erabiltzaileak konfiguratuta daude. Hazten ari gara eta errepikapena egin nahi dugu.
Zer behar dugu errepikatzeko?
ZooKeeper behar dugu. ClickHousen, erreplikazioa ZooKeeper erabiliz eraikitzen da. ZooKeeper behar da, ClickHouse-ren erreplika ezberdinek adostasuna izan dezaten zein datu-blokeetan dauden ClickHouse-n.
ZooKeeper edonork erabil dezake. Enpresak kanpoko ZooKeeper bat badu, erabil daiteke. Hala ez bada, gure biltegitik instala dezakezu. Badago hau guztia errazten duen instalatzaile bat.
Eta sistema osoaren interakzio-diagrama honela geratzen da. Kubernetes dugu plataforma gisa. ClickHouse operadorea exekutatzen du. ZooKeeper irudikatu nuen hemen. Eta operadoreak ClickHouse eta ZooKeeper-ekin elkarreragiten du. Hau da, interakzioaren emaitzak.
Eta hori guztia beharrezkoa da ClickHouse-k k8s-en datuak ongi errepikatzeko.
Ikus dezagun orain zeregina bera, erreplikatzeko manifestua nolakoa izango den.
Gure manifestuari bi atal gehitzen ari gara. Lehenengoa da non eskuratu ZooKeeper, Kubernetesen barruan edo kanpoan egon daitekeena. Hau deskribapen bat besterik ez da. Eta erreplikak eskatzen ditugu. Horiek. bi erreplika nahi ditugu. Guztira, 4 pod izan beharko genituzke irteeran. Biltegiratzeaz gogoan dugu, pixka bat geroago itzuliko da. Biltegiratzea aparteko istorio bat da.
Horrela izan zen.
Horrela bihurtzen da. Erreplikak gehitzen dira. 4.a ez zen kabitu, uste dugu han asko egon daitezkeela. Eta ZooKeeper gehitzen da alboan. Eskemak gero eta konplexuagoak dira.
Eta hurrengo zeregina gehitzeko garaia da. Biltegiratze iraunkorra gehituko dugu.
Biltegiratze iraunkorrerako hainbat aukera ditugu.
Hodeiko hornitzaile batean exekutatzen ari bagara, adibidez, Amazon, Google erabiliz, orduan tentazio handia dago hodeiko biltegiratzea erabiltzeko. Oso erosoa da, ona da.
Eta bigarren aukera bat dago. Hau biltegiratze lokalerako da, nodo bakoitzean disko lokalak ditugunean. Aukera hau ezartzea askoz zailagoa da, baina, aldi berean, produktiboagoa da.
Ikus dezagun zer daukagun hodeiko biltegiratzeari buruz.
Abantailak daude. Oso erraza da konfiguratzea. Besterik gabe, hodeiko hornitzaileari eskatzen diogu, mesedez, halako eta halako edukieraren, halako klaseen biltegiratzea. Klaseak hornitzaileek modu independentean antolatzen dituzte.
Eta eragozpen bat dago. Batzuentzat, hori ez-kritikoa da eragozpen bat. Jakina, errendimendu arazo batzuk egongo dira. Erabiltzeko oso erosoa eta fidagarria da, baina errendimendu-eragozpen potentzial batzuk daude.
Eta zeren ClickHouse produktibitatean zentratzen da bereziki, ahal duen guztia estutzen duela esan liteke, horregatik bezero asko saiatzen dira produktibitate maximoa ateratzen.
Eta etekinik handiena ateratzeko, tokiko biltegiratzea behar dugu.
Kubernetes-ek hiru abstrakzio eskaintzen ditu Kubernetes-en biltegiratze lokala erabiltzeko. Hau:
- EmptyDir
- HostPath.
- Tokiko
Ikus dezagun nola desberdinak diren eta nola antzekoak diren.
Lehenik eta behin, hiru planteamenduetan biltegiratzea dugu: k8s nodo fisiko berean kokatutako disko lokalak dira. Baina badituzte desberdintasun batzuk.
Has gaitezen sinpleenetik, hau da, emptyDir. Zer da hau praktikan? Gure zehaztapenean, edukiontzien sistemari (gehienetan Docker) eskatzen diogu disko lokaleko karpeta baterako sarbidea emateko.
Praktikan, Docker-ek aldi baterako karpeta bat sortzen du nonbait bere bideetatik eta hash luzea deitzen dio. Eta bertara sartzeko interfaze bat eskaintzen du.
Nola funtzionatuko du honek errendimendu aldetik? Honek disko lokaleko abiaduran funtzionatuko du, hau da. Hau zure torlojurako sarbide osoa da.
Baina kasu honek badu bere eragozpena. Iraunkorra nahiko zalantzazkoa da gai honetan. Docker edukiontziekin mugitzen den lehen aldian, Persistent galtzen da. Kubernetes-ek Pod hau beste disko batera eraman nahi badu arrazoiren batengatik, datuak galduko dira.
Planteamendu hau ona da probetarako, dagoeneko abiadura normala erakusten duelako, baina zerbait seriorako aukera hau ez da egokia.
Beraz, bigarren planteamendu bat dago. Hau hostPath da. Aurreko diapositiba eta hau begiratuz gero, desberdintasun bakarra ikusiko duzu. Gure karpeta Docker-etik zuzenean Kubernetes nodora eraman da. Hemen pixka bat sinpleagoa da. Zuzenean zehazten dugu gure datuak gorde nahi ditugun fitxategi sistema lokalean.
Metodo honek abantailak ditu. Hau jada benetako Persistent bat da, eta klasikoa, gainera. Helbideren batean diskoan grabatutako datuak izango ditugu.
Desabantailak ere badaude. Hau da kudeaketaren konplexutasuna. Baliteke gure Kubernetes-ek Pod-a beste nodo fisiko batera eraman nahi izatea. Eta hemen sartzen da DevOps jokoa. Ondo azaldu behar dio sistema osoari leka hauek bide horietan zerbait muntatuta duzun nodoetara bakarrik eraman daitezkeela, eta nodo bat baino gehiago aldi berean. Nahiko zaila da.
Helburu horietarako bereziki, gure operadorean txantiloiak egin ditugu konplexutasun hori guztia ezkutatzeko. Eta besterik gabe esan dezakezu: "ClickHouse-ren instantzia bat izan nahi dut nodo fisiko bakoitzeko eta halako bide batean".
Baina ez gara behar hori behar dugun bakarrak, beraz, Kuberneteseko jaunak berak ere ulertzen dute jendeak disko fisikoetarako sarbidea izan nahi duela, beraz, hirugarren geruza bat ematen dute.
Bertakoa deitzen da. Ez dago ia ezberdintasunik aurreko diapositibarekiko. Lehen bakarrik beharrezkoa zen eskuz berretsi ezin ditugula pod horiek nodo batetik bestera transferitu, tokiko disko fisiko batera bideren batean lotuta egon behar dutelako, baina orain ezagutza hori guztia Kubernetes-en bertan biltzen da. Eta konfiguratzeko askoz errazagoa da.
Itzuli gaitezen gure arazo praktikora. Itzuli gaitezen YAML txantiloira. Hemen benetako biltegiratzea dugu. Berriro gaude. VolumeClaim txantiloi klasikoa k8s-en bezala ezarri dugu. Eta nolako biltegiratzea nahi dugun deskribatzen dugu.
Horren ondoren, k8s-ek biltegiratzea eskatuko du. StatefulSet-en esleituko digu. Eta azkenean ClickHouseren esku egongo da.
Eskema hau genuen. Gure Biltegiratze Iraunkorra gorria zen, eta horrek egin behar zuela aditzera ematen zuen.
Eta berde bihurtzen da. Orain ClickHouse on k8s kluster eskema guztiz amaituta dago. Zatiak ditugu, erreplikak, ZooKeeper, benetako Persistent bat dugu, era batera edo bestera inplementatzen dena. Eskema guztiz martxan dago jada.
Bizitzen jarraitzen dugu. Gure klusterra garatzen ari da. Eta Alexey saiatzen da, eta ClickHouse-ren bertsio berri bat kaleratzen du.
Zeregin praktiko bat sortzen da: ClickHouse-ren bertsio berria gure klusterrean probatzea. Eta, jakina, ez duzu dena zabaldu nahi; bertsio berri bat erreplika batean jarri nahi duzu urruneko txokoan, eta agian ez bertsio berri bat, bi aldi berean baizik, askotan ateratzen direlako.
Zer esan dezakegu honetaz?
Hemen dugu horrelako aukera bat. Hauek pod txantiloiak dira. Idatzi dezakezu gure operadoreak kluster heterogeneo bat eraikitzeko aukera ematen duela. Horiek. konfiguratu, sorta batean erreplika guztietatik hasita, erreplika pertsonal bakoitzarekin amaituz, zein bertsio nahi dugun ClickHouse, zein bertsio nahi dugun biltegiratzea. Klusterra guztiz konfiguratu dezakegu behar dugun konfigurazioarekin.
Sar gaitezen pixka bat barrura. Horren aurretik, ClickHouse-operadoreak nola funtzionatzen duen hitz egin dugu ClickHouse-ren berezitasunekin.
Orain, edozein operadore orokorrean nola funtzionatzen duen buruz hitz batzuk esan nahi nituzke, baita K8ekin nola elkarreragiten duen ere.
Ikus dezagun lehenik K8-ekin elkarreraginean. Zer gertatzen da kubectl aplikatzen dugunean? Gure objektuak etcd-n agertzen dira APIaren bidez.
Adibidez, oinarrizko Kubernetes objektuak: pod, StatefulSet, zerbitzua eta abar zerrendan.
Aldi berean, oraindik ez da ezer fisikorik gertatzen. Objektu hauek klusterrean materializatu behar dira.
Horretarako, kontroladore bat agertzen da. Kontroladorea k8s osagai berezi bat da, deskribapen horiek gauzatu ditzakeena. Badaki nola eta zer egin fisikoki. Badaki edukiontziak exekutatzen, zer konfiguratu behar den bertan zerbitzariak funtziona dezan.
Eta gure objektuak K8etan gauzatzen ditu.
Baina pods eta StatefulSets-ekin ez ezik, ClickHouseInstallation bat sortu nahi dugu, hau da, ClickHouse motako objektu bat, osotasun bakar gisa funtzionatzeko. Orain arte ez dago horrelako aukerarik.
Baina K8s-ek honako gauza polita du. Entitate konplexu honen antzeko nonbait edukitzea nahi dugu, non gure klusterra leketatik eta StatefulSet-etatik bilduko litzatekeen.
Eta zer egin behar da horretarako? Lehenik eta behin, Baliabideen Definizioa pertsonalizatua agertzen da. Zer da hau? Hau K8s-en deskribapen bat da, datu-mota bat gehiago izango duzuela, baliabide pertsonalizatu bat gehitu nahi diogula podari, StatefulSet, barrutik konplexua izango dena. Hau datu-egituraren deskribapena da.
Kubectl apply bidez ere bidaltzen dugu. Kubernetes pozik hartu zuen.
Eta orain gure biltegian, etcd-ko objektuak ClickHouseInstallation izeneko baliabide pertsonalizatua grabatzeko aukera du.
Baina oraingoz ez da ezer gehiago gertatuko. Hau da, orain zatiak eta erreplikak deskribatzen aztertu genuen YAML fitxategia sortzen badugu eta "kubectl aplikatzen" esaten badugu, orduan Kubernetes-ek onartuko du, etcd-en jarriko du eta esango du: "Oso, baina ez dakit zer egin horrekin. Ez dakit nola mantendu ClickHouseInstallation".
Horren arabera, norbait behar dugu Kubernetes-ek datu-mota berria zerbitzatzen laguntzeko. Ezkerrean jatorrizko datu motekin lan egiten duen Kubernetes kontrolagailu natibo bat dugu. Eta eskuinaldean datu-mot pertsonalizatuekin lan egin dezakeen kontroladore pertsonalizatu bat izan beharko genuke.
Eta beste modu batera operadore deitzen zaio. Zehazki sartu dut hemen Kubernetes gisa, K8etatik kanpo ere exekutatu daitekeelako. Gehienetan, noski, operadore guztiak Kubernetesen exekutatzen dira, baina ezerk ez du kanpoan gelditzea eragozten, beraz, hemen bereziki kanpora eramaten da.
Eta, aldi berean, kontroladore pertsonalizatuak, operadorea bezala ere ezagutzen dena, Kubernetesekin elkarreragin egiten du APIaren bidez. Dagoeneko badaki nola interaktuatzen APIarekin. Eta dagoeneko badaki nola gauzatzen den baliabide pertsonalizatu batetik egin nahi dugun zirkuitu konplexua. Hauxe da operadoreak egiten duena.
Nola funtzionatzen du operadoreak? Ikus dezagun eskuineko aldean nola egiten duen ikusteko. Ikus dezagun nola gauzatzen duen operadoreak hori guztia eta nola gertatzen den K8ekin elkarrekintza gehiago.
Operadore bat programa bat da. Ekitaldietara zuzenduta dago. Operadoreak ekitaldietara harpidetzen du Kubernetes APIa erabiliz. Kubernetes APIak ekitaldietara harpidetzeko sarrera puntuak ditu. Eta K8etan zerbait aldatzen bada, Kubernetes-ek denei ekitaldiak bidaltzen dizkie, hau da. API puntu honetara harpidetuta dagoenak jakinarazpenak jasoko ditu.
Operadoreak ekitaldietara harpidetzen du eta nolabaiteko erreakzio bat egin behar du. Bere zeregina sortzen ari diren gertaerei erantzutea da.
Eguneratze jakin batzuek sortzen dituzte gertaerak. Gure YAML fitxategia ClickHouseInstallation-en deskribapenarekin iristen da. Etcd-ra joan zen kubectl apply bidez. Gertaera bat piztu zen bertan, eta, ondorioz, gertaera hau ClickHouse-operadoreari heldu zitzaion. Operadoreak deskribapen hau jaso du. Eta zerbait egin behar du. ClickHouseInstallation objekturako eguneratze bat iritsi bada, kluster eguneratu behar duzu. Eta operadorearen zeregina kluster eguneratzea da.
Zertan ari da? Lehenik eta behin, eguneraketa honekin zer egingo dugun ekintza-plan bat egin behar dugu. Eguneraketak oso txikiak izan daitezke, hau da. txikia YAML exekuzioan, baina aldaketa oso handiak ekar ditzake klusterrean. Hori dela eta, operadoreak plan bat sortzen du, eta, ondoren, horri eusten dio.
Plan horren arabera, egitura hori barnean egosten hasten da, lekak, zerbitzuak, alegia. bere zeregin nagusia zein den egin. Hau da nola eraiki ClickHouse kluster bat Kubernetes-en.
Orain uki dezagun hain gauza interesgarri bat. Hau Kubernetes eta operadorearen arteko ardura banatzea da, hau da. zer egiten duen Kubernetes-ek, zer egiten duen operadoreak eta nola elkarreragiten duten.
Kubernetes sistemaren gauzen arduraduna da, hau da. sistema-esparru gisa interpretatu daitekeen oinarrizko objektu multzo baterako. Kubernetes-ek badaki pod-ak abiarazten, edukiontziak nola berrabiarazi, bolumenak nola muntatu, ConfigMap-ekin nola lan egin, hau da. sistema deitu daitekeen guztia.
Operadoreek domeinuetan jarduten dute. Eragile bakoitza bere gai-arlorako egina dago. ClickHouserako egin dugu.
Eta operadoreak zehatz-mehatz elkarreragin egiten du gai-arloari dagokionez, hala nola, erreplika bat gehitzea, diagrama bat egitea, monitorizazioa konfiguratzea. Horrek zatiketa sortzen du.
Ikus dezagun adibide praktiko bat gehitzeko erreplika ekintza egiten dugunean erantzukizun-banaketa hori nola gertatzen den.
Operadoreak zeregin bat jasotzen du - erreplika bat gehitzeko. Zer egiten du operadoreak? Operadoreak StatefulSet berri bat sortu behar dela kalkulatuko du, eta bertan halako txantiloiak, bolumen-erreklamazioa, deskribatu behar dira.
Dena prestatu zuen eta K8ei pasatzen die. ConfigMap, StatefulSet, Volume behar dituela dio. Kubernetes lanean ari da. Lan egiten duen oinarrizko unitateak gauzatzen ditu.
Eta gero ClickHouse-operadorea jokoan sartzen da berriro. Dagoeneko badu leka fisiko bat eta bertan zerbait egin dezake. Eta ClickHouse-operadoreak berriro domeinu terminoetan funtzionatzen du. Horiek. Zehazki, ClickHouse, kluster batean erreplika bat sartzeko, lehenik eta behin, kluster honetan dagoen datu-eskema konfiguratu behar duzu. Eta, bigarrenik, erreplika hori jarraipenean sartu behar da, argi eta garbi trazatu ahal izateko. Operadoreak dagoeneko konfiguratzen du hau.
Eta horren ondoren bakarrik ClickHouse bera jokoan sartzen da, hau da. goi mailako beste entitate bat. Hau datu-base bat da dagoeneko. Bere instantzia du, konfiguratutako beste erreplika bat, klusterra sartzeko prest dagoena.
Ematen du erreplika bat gehitzean exekuzio-katea eta erantzukizun-banaketa nahiko luzea dela.
Gure zeregin praktikoekin jarraitzen dugu. Dagoeneko kluster bat baduzu, konfigurazioa migra dezakezu.
Lehendik dagoen xml-era zuzenean itsatsi ahal izateko egin dugu, ClickHouse-k ulertzen duena.
ClickHouse doi dezakezu. Zoned inplementazioa besterik ez da hostPath, tokiko biltegiratzea azaltzean hitz egin dudana. Hau da nola egin behar den zonakako hedapena.
Hurrengo zeregin praktikoa jarraipena da.
Gure kluster aldatzen bada, aldian-aldian monitorizazioa konfiguratu behar dugu.
Ikus dezagun diagrama. Dagoeneko ikusi ditugu hemen gezi berdeak. Ikus ditzagun orain gezi gorriak. Honela gure kluster jarraipena egin nahi dugu. ClickHouse klusterreko neurketak nola sartzen diren Prometheus-en, eta gero Grafana-ra.
Zein zailtasun ditu monitorizazioak? Zergatik aurkezten da hau lorpen moduko bat? Zailtasuna dinamikan dago. Kluster bat dugunean eta estatikoa denean, monitorizazioa behin konfigura dezakegu eta ez dugu gehiago trabarik izan.
Baina kluster asko baditugu, edo zerbait etengabe aldatzen ari bada, orduan prozesua dinamikoa da. Eta monitorizazioa etengabe birkonfiguratzea baliabide eta denbora galtzea da, hau da. nahiz eta alferkeria besterik ez. Hau automatizatu egin behar da. Zailtasuna prozesuaren dinamikan dago. Eta operadoreak hau oso ondo automatizatzen du.
Nola garatu zen gure klusterra? Hasieran horrela zen.
Orduan honela zegoen.
Azkenean, horrela bihurtu zen.
Eta monitorizazioa automatikoki egiten du operadoreak. Sarrera puntu bakarra.
Eta irteeran, Grafanako aginte-panelari begiratzen diogu, gure klusterraren bizitza barnean nola irakiten ari den ikusteko.
Bide batez, Grafana panela ere gure operadorearekin zuzenean iturburu kodean banatzen da. Konektatu eta erabil dezakezu. Gure DevOps-ek pantaila-argazki hau eman dit.
Nora joan nahiko genuke hurrengoan? Hau:
- Testen automatizazioa garatzea. Zeregin nagusia bertsio berrien proba automatizatua da.
- ZooKeeper-en integrazioa ere automatizatu nahi dugu. Eta ZooKeeper-operadorearekin integratzeko planak daude. Horiek. ZooKeeperrentzat operadore bat idatzi da eta logikoa da bi operadoreak integratzen hastea soluzio erosoagoa eraikitzeko.
- Bizi-seinale konplexuagoak egin nahi ditugu.
- Berdez nabarmendu dut Txantiloien herentziara hurbiltzen ari garela - EGITASUNA, hau da, operadorearen hurrengo bertsioarekin jada izango dugu txantiloien herentzia. Piezetatik konfigurazio konplexuak eraikitzeko aukera ematen duen tresna indartsua da hau.
- Eta zeregin konplexuen automatizazioa nahi dugu. Nagusia Re-sharding da.
Har ditzagun tarteko emaitza batzuk.
Zer lortzen dugu ondorioz? Eta egiteak merezi du ala ez? Beharrezkoa al da datu-basea Kubernetesera arrastatu eta operadorea orokorrean eta bereziki Alitnity operadorea erabiltzea?
Irteeran lortuko dugu:
- Konfigurazio, hedapen eta mantentze-lanen sinplifikazio eta automatizazio nabarmena.
- Berehala integratutako monitorizazioa.
- Eta egoera konplexuetarako erabiltzeko prest dauden txantiloi kodifikatuak. Erreplika bat gehitzea bezalako ekintza bat ez da eskuz egin behar. Operadoreak hau egiten du.
Azken galdera bakarra geratzen da. Dagoeneko Kubernetesen datu-base bat dugu, birtualizazioa. Zer gertatzen da irtenbide horren errendimenduaz, batez ere ClickHouse errendimendurako optimizatuta dagoelako?
Erantzuna dena ondo dago! Ez naiz xehetasunetan sartuko; hau da aparteko txosten baten gaia.
Baina bada TSBS bezalako proiektu bat. Zein da bere zeregin nagusia? Hau datu-basearen errendimendu-proba bat da. Hau beroa epela, biguna eta biguna alderatzeko saiakera bat da.
Nola egiten du lan? Datu multzo bat sortzen da. Ondoren, datu-multzo hau datu-base desberdinetan exekutatzen da proba-multzo bera erabiliz. Eta datu-base bakoitzak arazo bat konpontzen du dakien moduan. Eta gero emaitzak alderatu ditzakezu.
Dagoeneko datu-base ugari onartzen ditu. Hiru nagusi identifikatu ditut. Hau:
- Denbora-eskalaDB.
- InfluxDB.
- ClickHouse.
Antzeko beste irtenbide batekin ere konparaketa bat egin zen. RedShift-ekin alderatzea. Amazonen egin zen konparazioa. ClickHouse ere oso aurretik dago gai honetan.
Zer ondorio atera daitezke esandakotik?
- Kubernetes-en DB posible da. Ziurrenik edozein da posible, baina orokorrean posible dela dirudi. Kubernetes-en ClickHouse posible da, zalantzarik gabe, gure operadorearen laguntzarekin.
- Operadoreak prozesuak automatizatzen laguntzen du eta bizitza benetan errazten du.
- Errendimendua normala da.
- Eta hori erabili daitekeela eta erabili behar dela iruditzen zaigu.
Kode irekia - bat egin gurekin!
Esan dudan bezala, operadorea guztiz irekiko produktua da, beraz, oso ona litzateke gehieneko jende kopuruak erabiltzea. Batu zaitez! Zuen guztien zain gaude!
Eskerrik asko guztioi!
Zure galderak
Eskerrik asko erreportajeagatik! Nire izena Anton da. SEMrushekoa naiz. Zer gertatzen den erregistroarekin galdetzen ari naiz. Monitorizazioari buruz entzuten dugu, baina erregistroari buruz ezer, kluster osoari buruz hitz egiten badugu. Adibidez, hardwareari buruzko kluster bat planteatu dugu. Eta erregistro zentralizatua erabiltzen dugu, pila komun batean bilduz bitarteko estandarrak erabiliz. Eta hortik ateratzen zaizkigu interesatzen zaizkigun datuak.
Galdera ona, hau da, zereginen zerrendan saioa hastea. Gure operadoreak ez du hau automatizatu oraindik. Oraindik garatzen ari da, proiektua nahiko gaztea da oraindik. Erregistratzeko beharra ulertzen dugu. Hau ere oso gai garrantzitsua da. Eta ziurrenik monitorizazioa baino garrantzitsuagoa ez da. Baina ezartzeko zerrendan lehena monitorizazioa izan zen. Erregistroa egongo da. Jakina, klusterraren bizitzako alderdi guztiak automatizatzen saiatzen gara. Horregatik, erantzuna da momentuz operadoreak, zoritxarrez, ez dakiela nola egin, baina planoetan dago, egingo dugu. Sartu nahi baduzu, tira eskaera, mesedez.
Kaixo! Eskerrik asko erreportajeagatik! Persistent Volumes-ekin lotutako galdera estandar bat daukat. Operadore honekin konfigurazio bat sortzen dugunean, nola zehazten du operadoreak zein nodotan dugun disko edo karpeta jakin bat erantsita? Lehenik eta behin azaldu behar diogu, mesedez jarri gure ClickHouse disko bat duten nodo hauetan?
Ulertzen dudanez, galdera hau biltegiratze lokalaren jarraipena da, batez ere hostPath zatia. Hau sistema osoari azaltzea bezalakoa da poda halako nodo batean abiarazi behar dela, zeinari fisikoki konektatutako disko bat daukagula, halako bide batean muntatuta dagoena. Oso azaletik ukitu dudan atal oso bat da, han erantzuna nahiko handia delako.
Laburbilduz, honelakoa dirudi. Jakina, bolumen horiek hornitu behar ditugu. Momentuz, ez dago tokiko biltegiratze dinamikorik, beraz, DevOps-ek diskoak berak moztu behar ditu, bolumen horiek. Eta Kubernetes hornitzea azaldu behar dute halako eta halako klaseko bolumen iraunkorrak izango dituzula, halako eta halako nodoetan kokatzen direnak. Ondoren, Kubernetesi azaldu beharko diozu halako eta halako biltegiratze klase lokal bat behar duten pod-ak etiketak erabiliz halako eta halako nodoetara soilik zuzendu behar direla. Helburu horietarako, operadoreak etiketa motaren bat eta ostalari instantzia bakoitzeko bat esleitzeko gaitasuna du. Eta bilakatzen da Kubernetes-ek lekak bideratuko dituela baldintzak, etiketak, termino sinpleetan betetzen dituzten nodoetan soilik exekutatzeko. Administratzaileek eskuz esleitzen dituzte etiketak eta hornitzen dituzten diskoak. Eta gero eskalatzen da.
Eta hirugarren aukera da, tokikoa, hori pixka bat errazten laguntzen duena. Dagoeneko azpimarratu dudanez, afinazioan lan neketsua da, azken finean errendimendurik handiena lortzen laguntzen duena.
Bigarren galdera bat daukat honekin lotuta. Kubernetes honela diseinatu zen, ez zaigun axola nodo bat galtzen dugun ala ez. Zer egin beharko genuke kasu honetan gure zatia zintzilik dagoen nodoa galdu badugu?
Bai, Kubernetes-ek hasiera batean kokatu zuen gure lekekin dugun harremana ganadua bezalakoa dela, baina hemen gurekin disko bakoitza maskota baten antzeko zerbait bihurtzen da. Arazo bat dago, non ezin ditugula bakarrik bota. Eta Kubernetesen garapena filosofia guztiz tratatzea ezinezkoa den norabidean doa, guztiz baztertutako baliabide bat balitz bezala.
Orain galdera praktiko bat. Zer egin diskoa zegoen nodoa galduz gero? Hemen arazoa maila altuago batean konpontzen ari da. ClickHouseren kasuan, maila altuagoan lan egiten duten erreplikak ditugu, hau da. ClickHouse mailan.
Zein da ondoriozko xedapena? DevOps da datuak galtzen ez direla ziurtatzearen ardura. Erreplikazioa behar bezala konfiguratu behar du eta erreplikazioa martxan dagoela ziurtatu behar du. ClickHouse mailako erreplikak bikoiztutako datuak izan behar ditu. Hau ez da operadoreak konpontzen duen zeregina. Eta ez Kubernetesek berak konpontzen duen arazoa. Hau ClickHouse mailan dago.
Zer egin zure burdinazko nodoa erortzen bada? Eta bigarren bat instalatu beharko duzu, diskoa behar bezala hornitu eta etiketak jarri beharko dituzula. Eta horren ostean, Kubernetes-ek bertan instantzia-pod bat abiarazteko eskakizunak beteko ditu. Kubernetes-ek abiaraziko du. Zure ontzi kopurua ez da nahikoa zehaztutako kopurua betetzeko. Erakutsi dudan zikloan zehar joango da. Eta maila gorenean, ClickHousek ulertuko du erreplika bat sartu dugula, oraindik hutsik dagoela eta hari datuak transferitzen hasi behar dugula. Horiek. Prozesu hau oraindik ez dago ondo automatizatuta.
Eskerrik asko erreportajeagatik! Mota guztietako gauza gaiztoak gertatzen direnean, operadorea huts egiten du eta berrabiarazi egiten da, eta une horretan gertaerak iristen dira, nolabait kudeatzen al duzu hau?
Zer gertatzen da operadorea huts egin eta berrabiarazten bada, ezta?
Bai. Eta momentu horretan gertaerak heldu ziren.
Kasu honetan zer egin behar den egitekoa, neurri batean, operadorearen eta Kubernetesen artean partekatzen da. Kubernetes-ek gertatutako gertaera bat errepikatzeko gaitasuna du. Erreproduzitzen du. Eta operadorearen zeregina gertaera-erregistroa berarekin errepikatzen denean gertaera horiek idempotenteak direla ziurtatzea da. Eta gertaera bera errepikatzeak gure sistema hautsi ez dezan. Eta gure operadoreak zeregin horri aurre egiten dio.
Kaixo! Eskerrik asko erreportajeagatik! Dmitry Zavyalov, konpainia Smedova. Ba al dago operadoreari haproxy-rekin konfiguratzeko gaitasuna gehitzeko asmorik? Estandarraz gain beste orekatzaileren bat interesatuko litzaidake, adimentsua izan dadin eta ClickHouse benetan hor dagoela uler dezan.
Ingress buruz ari al zara?
Bai, ordezkatu Ingress haproxy-rekin. Haproxy-n erreplikak dituen klusterraren topologia zehaztu dezakezu.
Oraindik ez dugu pentsatu. Behar izanez gero eta zergatik behar den azaltzen baduzu, orduan gauzatzeko aukera izango da, batez ere parte hartu nahi baduzu. Aukera hausnartuko dugu pozik. Erantzun laburra ezetz da, gaur egun ez dugu horrelako funtzionaltasunik. Eskerrik asko aholkuagatik, gai hau aztertuko dugu. Eta erabilera kasua eta praktikan zergatik behar den ere azaltzen baduzu, adibidez, sortu arazoak GitHub-en, orduan bikaina izango da.
Dagoeneko.
Ederki. Edozein iradokizunetara zabalik gaude. Eta haproxy zereginen zerrendara gehitzen da. Zerrenda hazten ari da, oraindik ez da txikitzen. Baina hau ona da, produktua eskatzen dela esan nahi du.
Iturria: www.habr.com