La raporto estas dediĉita al praktikaj aferoj de evoluigado de funkciigisto en Kubernetes, dezajnante ĝian arkitekturon kaj bazajn funkciajn principojn.
En la unua parto de la raporto ni konsideros:
- kio estas operatoro en Kubernetes kaj kial ĝi bezonas;
- kiel precize la funkciigisto simpligas la administradon de kompleksaj sistemoj;
- kion la funkciigisto povas kaj ne povas fari.
Poste, ni daŭrigu pri diskuto pri la interna strukturo de la funkciigisto. Ni rigardu la arkitekturon kaj funkciadon de la funkciigisto paŝon post paŝo. Ni rigardu ĝin detale:
- interago inter la operatoro kaj Kubernetes;
- kiajn funkciojn la funkciigisto prenas kaj kiajn funkciojn ĝi delegas al Kubernetes.
Ni rigardu la administradon de fragmentoj kaj datumbazaj kopioj en Kubernetes.
Poste, ni diskutos problemojn pri konservado de datumoj:
- kiel labori kun Persistenta Stokado de la vidpunkto de funkciigisto;
- malfacilaĵoj de uzado de Loka Stokado.
En la fina parto de la raporto, ni konsideros praktikajn ekzemplojn de apliko kun Amazon aŭ Google Cloud Service. La raporto baziĝas sur la ekzemplo de la evoluo kaj operacia sperto de funkciigisto por ClickHouse.
Video:
Mia nomo estas Vladislav Klimenko. Hodiaŭ mi volis paroli pri nia sperto pri evoluigado kaj funkciigado de funkciigisto, kaj ĉi tiu estas specialigita funkciigisto por administri datumbazajn grapojn. Ekzemple por administri la ClickHouse areton.
Kial ni havas la ŝancon paroli pri la telefonisto kaj ClickHouse?
- Ni subtenas kaj disvolvas ClickHouse.
- Nuntempe, ni provas malrapide fari nian kontribuon al la disvolviĝo de ClickHouse. Kaj ni estas duaj post Yandex koncerne la kvanton de ŝanĝoj faritaj al ClickHouse.
- Ni provas fari pliajn projektojn por la ekosistemo ClickHouse.
Mi ŝatus rakonti al vi pri unu el ĉi tiuj projektoj. Ĉi tio temas pri ClickHouse-funkciigisto por Kubernetes.
En mia raporto mi ŝatus tuŝi du temojn:
- La unua temo estas kiel nia operaciisto de administrado de datumbazoj ClickHouse funkcias en Kubernetes.
- La dua temo estas kiel iu ajn funkciigisto funkcias, t.e. kiel ĝi interagas kun Kubernetes.
Tamen ĉi tiuj du demandoj intersekciĝos tra mia raporto.
Kiu interesus aŭskulti kion mi provas rakonti?
- Ĝi estos de plej granda intereso por tiuj, kiuj funkciigas funkciigistojn.
- Aŭ por tiuj, kiuj volas fari sian propran por kompreni kiel ĝi funkcias interne, kiel la operatoro interagas kun Kubernetes, kaj kiaj malfacilaĵoj povas aperi.
Por plej bone kompreni, kion ni diskutos hodiaŭ, estas bona ideo scii kiel funkcias Kubernetes kaj havi iun bazan trejnadon pri nubo.
Kio estas ClickHouse? Ĉi tio estas kolumna datumbazo kun specifaj funkcioj por interreta prilaborado de analizaj demandoj. Kaj ĝi estas tute malfermita fonto.
Kaj gravas por ni scii nur du aferojn. Vi devas scii, ke ĉi tio estas datumbazo, do tio, kion mi diros al vi, estos aplikebla al preskaŭ ajna datumbazo. Kaj la fakto, ke la ClickHouse DBMS tre bone skalas, donas preskaŭ linearan skaleblon. Kaj tial, la grapolŝtato estas natura stato por ClickHouse. Kaj ni plej interesiĝas pri diskuti kiel servi la ClickHouse-grupon en Kubernetes.
Kial oni bezonas lin tie? Kial ni ne povas daŭrigi funkcii ĝin mem? Kaj la respondoj estas parte teknikaj kaj parte organizaj.
- En la praktiko, ni ĉiam pli renkontas situacion, kie en grandaj kompanioj preskaŭ ĉiuj komponantoj jam estas en Kubernetes. Datumbazoj restas ekstere.
- Kaj la demando ĉiam pli fariĝas: "Ĉu ĉi tio povas esti metita interne?" Sekve, grandaj kompanioj provas atingi maksimuman unuiĝon de administrado por rapide povi administri siajn datumstokejojn.
- Kaj ĉi tio precipe helpas se vi bezonas la maksimuman ŝancon ripeti la samon en nova loko, t.e. maksimuman porteblon.
Kiom facila aŭ malfacila ĝi estas? Ĉi tio, kompreneble, povas esti farita mane. Sed ĝi ne estas tiel simpla, ĉar ni havas la plian kompleksecon administri Kubernetes mem, sed samtempe la specifaĵoj de ClickHouse estas supermetitaj. Kaj tia agregacio rezultas.
Kaj ĉio kune ĉi tio donas sufiĉe grandan aron da teknologioj, kiuj fariĝas sufiĉe malfacile administreblaj, ĉar Kubernetes alportas siajn proprajn ĉiutagajn problemojn al operacio, kaj ClickHouse alportas siajn proprajn problemojn al ĉiutaga funkciado. Precipe se ni havas plurajn ClickHouses, kaj ni devas konstante fari ion kun ili.
Kun dinamika agordo, ClickHouse havas sufiĉe grandan nombron da problemoj, kiuj kreas konstantan ŝarĝon sur DevOps:
- Kiam ni volas ŝanĝi ion en ClickHouse, ekzemple, aldoni kopion aŭ fragmenton, tiam ni devas administri la agordon.
- Poste ŝanĝu la datuman skemon, ĉar ClickHouse havas specifan sharding-metodon. Tie vi devas aranĝi la datumdiagramon, aranĝi la agordojn.
- Vi devas agordi monitoradon.
- Kolektante protokolojn por novaj pecetoj, por novaj kopioj.
- Zorgu pri restarigo.
- Kaj rekomencu.
Ĉi tiuj estas rutinaj taskoj, kiujn mi tre ŝatus plifaciligi.
Kubernetes mem helpas bone en funkciado, sed pri bazaj sistemaj aferoj.
Kubernetes kapablas faciligi kaj aŭtomatigi aferojn kiel:
- Retrovo.
- Rekomenci.
- Administrado de stokadsistemo.
Tio estas bona, tio estas la ĝusta direkto, sed li estas tute senscia pri kiel funkciigi datumbazan areton.
Ni volas pli, ni volas, ke la tuta datumbazo funkciu en Kubernetes.
Mi ŝatus akiri ion kiel grandan magian ruĝan butonon, kiun vi premas, kaj areto kun ĉiutagaj taskoj, kiuj devas esti solvitaj, estas deplojita kaj konservita dum sia tuta vivociklo. ClickHouse-grupo en Kubernetes.
Kaj ni provis fari solvon kiu helpus faciligi la laboron. Ĉi tio estas ClickHouse-funkciigisto por Kubernetes de Altinity.
Operatoro estas programo, kies ĉefa tasko estas administri aliajn programojn, t.e. ĝi estas administranto.
Kaj ĝi enhavas ŝablonojn de konduto. Vi povas nomi ĉi tiun kodigitan scion pri la temo.
Kaj lia ĉefa tasko estas faciligi la vivon de DevOps kaj redukti mikroadministradon, por ke li (DevOps) jam pensu en altnivelaj terminoj, t.e., por ke li (DevOps) ne okupiĝu pri mikroadministrado, por ke li ne agordu. ĉiuj detaloj permane.
Kaj nur la funkciigisto estas robota asistanto, kiu traktas mikrotaskojn kaj helpas DevOps.
Kial vi bezonas telefoniston? Li rezultas precipe bone en du lokoj:
- Kiam la specialisto, kiu traktas ClickHouse, ne havas sufiĉe da sperto, sed jam bezonas funkciigi ClickHouse, la funkciigisto faciligas la operacion kaj ebligas al vi funkciigi ClickHouse-grupon kun sufiĉe kompleksa agordo, sen eniri tro da detaloj pri kiel ĉio funkcias. interne. Vi nur donas al li altnivelajn taskojn, kaj ĝi funkcias.
- Kaj la dua tasko en kiu ĝi plenumas plej bone estas kiam necesas aŭtomatigi grandan nombron da tipaj taskoj. Forigas mikrotaskojn de sistemaj administrantoj.
Ĉi tio estas plej bezonata aŭ de tiuj, kiuj ĵus komencas sian vojaĝon, aŭ de tiuj, kiuj bezonas multan aŭtomatigon.
Kiel la funkciigisto-bazita aliro diferencas de aliaj sistemoj? Estas Helm. Ĝi ankaŭ helpas instali ClickHouse; vi povas desegni stirleterojn, kiuj eĉ instalos tutan ClickHouse-grupon. Kio do estas la diferenco inter la operatoro kaj la sama, ekzemple, Helm?
La ĉefa fundamenta diferenco estas, ke Helm estas pakaĵadministrado kaj Operator iras paŝon plu. Ĉi tio estas subteno por la tuta vivociklo. Ĉi tio ne estas nur instalado, ĉi tiuj estas ĉiutagaj taskoj, kiuj inkluzivas skaladon, sharding, t.e. ĉion, kio devas esti farita dum la vivociklo (se necese, tiam ankaŭ forigo) - ĉio estas decidita de la funkciigisto. Ĝi provas aŭtomatigi kaj konservi la tutan programaran vivociklon. Ĉi tiu estas ĝia fundamenta diferenco de aliaj solvoj kiuj estas prezentitaj.
Tio estis la enkonduka parto, ni pluiru.
Kiel ni konstruas nian funkciigiston? Ni provas alproksimiĝi al la afero por administri la ClickHouse-grupon kiel ununuran rimedon.
Ĉi tie ni havas enigajn datumojn sur la maldekstra flanko de la bildo. Ĉi tio estas YAML kun clusterspecifo, kiu estas transdonita al Kubernetes en la klasika maniero per kubectl. Tie nia funkciigisto prenas ĝin kaj faras sian magion. Kaj ĉe la eligo ni ricevas la sekvan skemon. Ĉi tio estas efektivigo de ClickHouse en Kubernetes.
Kaj tiam ni malrapide rigardos kiel precize funkcias la funkciigisto, kiaj tipaj taskoj povas esti solvitaj. Ni nur konsideros tipajn taskojn ĉar ni havas limigitan tempon. Kaj ne ĉio, kion la funkciigisto povas decidi, estos diskutita.
Ni komencu de praktiko. Nia projekto estas tute malferma fonto, do vi povas vidi kiel ĝi funkcias en GitHub. Kaj vi povas procedi de la konsideroj, ke se vi nur volas lanĉi ĝin, tiam vi povas komenci per la Rapida Komenca Gvidilo.
Se vi volas kompreni detale, tiam ni provas konservi la dokumentaron en pli-malpli deca formo.
Ni komencu kun praktika problemo. La unua tasko, kie ni ĉiuj volas komenci, estas iel ruli la unuan ekzemplon. Kiel mi povas lanĉi ClickHouse uzante la funkciigiston, eĉ se mi ne vere scias kiel ĝi funkcias? Ni skribas manifeston, ĉar... Ĉiu komunikado kun k8s estas komunikado per manifestoj.
Ĉi tio estas tiel kompleksa manifesto. Kion ni emfazis ruĝe, estas pri kio ni devas koncentriĝi. Ni petas la funkciigiston krei areton nomitan demo.
Ĉi tiuj estas bazaj ekzemploj nuntempe. Stokado ankoraŭ ne estis priskribita, sed ni revenos al stokado iom poste. Nuntempe, ni observos la dinamikon de la disvolviĝo de la areto.
Ni kreis ĉi tiun manifeston. Ni nutras ĝin al nia funkciigisto. Li laboris, li faris magion.
Ni rigardas la konzolon. Tri komponantoj interesas: Pod, du Servoj kaj StatefulSet.
La funkciigisto funkciis, kaj ni povas vidi kion ĝuste li kreis.
Li kreas ion tian. Ni havas StatefulSet, Pod, ConfigMap por ĉiu kopio, ConfigMap por la tuta areto. Servoj estas postulataj kiel enirpunktoj en la areton.
Servoj estas la centra Load Balancer Service kaj ankaŭ povas esti uzataj por ĉiu kopio, por ĉiu breĉeto.
Nia baza areto aspektas kiel ĉi tio. Ĝi estas de unu ununura nodo.
Ni iru plu kaj kompliki la aferojn. Ni devas disrompi la areton.
Niaj taskoj kreskas, dinamiko komenciĝas. Ni volas aldoni peceton. Ni sekvas la evoluon. Ni ŝanĝas nian specifon. Ni indikas, ke ni volas du pecetojn.
Ĉi tiu estas la sama dosiero, kiu dinamike evoluas kun la kresko de la sistemo. Stokado ne, stokado estos diskutita plu, ĉi tio estas aparta temo.
Ni nutras la YAML-funkciigiston kaj vidas kio okazas.
La operatoro pensis kaj faris la jenajn entojn. Ni jam havas du Pods, tri Servojn kaj, subite, 2 StatefulSets. Kial 2 StatefulSets?
Sur la diagramo estis tiel - ĉi tiu estas nia komenca stato, kiam ni havis unu balgon.
Ĝi fariĝis tiel. Ĝis nun ĉio estas simpla, ĝi estis duobligita.
Kaj kial fariĝis du StatefulSets? Ĉi tie ni devas devadi kaj diskuti la demandon kiel Pods estas administritaj en Kubernetes.
Estas objekto nomata StatefulSet, kiu ebligas al vi krei aron da Pods el ŝablono. La ŝlosila faktoro ĉi tie estas Ŝablono. Kaj vi povas lanĉi multajn Pods uzante unu ŝablonon en unu StatefulSet. Kaj la ŝlosila frazo ĉi tie estas "multaj Pods por unu ŝablono".
Kaj estis granda tento fari la tutan areton, paki ĝin en unu StatefulSet. Ĝi funkcios, ne estas problemo kun ĝi. Sed estas unu averto. Se ni volas kunveni heterogenan areton, tio estas, de pluraj versioj de ClickHouse, tiam demandoj komencas ekesti. Jes, StatefulSet povas fari ruliĝantan ĝisdatigon, kaj tie vi povas lanĉi novan version, klarigi, ke vi devas provi ne pli ol tiom da nodoj samtempe.
Sed se ni eksterpolas la taskon kaj diras, ke ni volas fari tute heterogenan areton kaj ni ne volas ŝanĝi de la malnova versio al nova uzante ruliĝantan ĝisdatigon, sed ni simple volas krei heterogenan areton ambaŭ en terminoj. de malsamaj versioj de ClickHouse kaj laŭ malsama stokado. Ni volas, ekzemple, fari kelkajn kopiojn sur apartaj diskoj, sur malrapidaj, ĝenerale, por tute konstrui heterogenan areton. Kaj ĉar StatefulSet faras normigitan solvon el unu ŝablono, ne estas maniero fari tion.
Post iom da pripensado, estis decidite, ke ni faros ĝin tiel. Ni havas ĉiun kopion en sia propra StatefulSet. Estas iuj malavantaĝoj al ĉi tiu solvo, sed praktike ĝi estas tute enkapsuligita de la funkciigisto. Kaj estas multaj avantaĝoj. Ni povas konstrui la precizan areton, kiun ni volas, ekzemple absolute heterogenan. Sekve, en areto en kiu ni havas du pecetojn kun unu kopio, ni havos 2 StatefulSets kaj 2 Pods ĝuste ĉar ni elektis ĉi tiun aliron pro la kialoj deklaritaj supre por povi konstrui heterogenan areton.
Ni revenu al praktikaj problemoj. En nia areto ni devas agordi uzantojn, t.e. vi devas fari iun agordon de ClickHouse en Kubernetes. La operatoro disponigas ĉiujn eblecojn por tio.
Ni povas skribi tion, kion ni volas rekte en YAML. Ĉiuj agordaj opcioj estas mapitaj rekte de ĉi tiu YAML en ClickHouse-agordojn, kiuj tiam estas distribuitaj tra la areto.
Vi povas skribi ĝin tiel. Ĉi tio estas ekzemple. La pasvorto povas esti ĉifrita. Absolute ĉiuj agordaj opcioj de ClickHouse estas subtenataj. Jen nur ekzemplo.
La cluster-agordo estas distribuita kiel ConfigMap. En praktiko, la ĝisdatigo de ConfigMap ne okazas tuj, do se la areto estas granda, tiam la procezo de puŝado de la agordo daŭras iom da tempo. Sed ĉio ĉi estas tre oportuna por uzi.
Ni komplikigu la taskon. La areto disvolviĝas. Ni volas reprodukti datumojn. Tio estas, ni jam havas du pecetojn, po unu kopion, kaj uzantoj estas agorditaj. Ni kreskas kaj volas fari reproduktadon.
Kion ni bezonas por reproduktado?
Ni bezonas ZooKeeper. En ClickHouse, reproduktado estas konstruita per ZooKeeper. ZooKeeper estas necesa por ke malsamaj kopioj de ClickHouse havu konsenton pri kiuj datumblokoj estas sur kiu ClickHouse.
ZooKeeper povas esti uzata de iu ajn. Se la entrepreno havas eksteran ZooKeeper, tiam ĝi povas esti uzata. Se ne, vi povas instali ĝin de nia deponejo. Estas instalilo, kiu faciligas ĉi tiun tutan aferon.
Kaj la interaga diagramo de la tuta sistemo rezultas tiel. Ni havas Kubernetes kiel platformon. Ĝi ekzekutas la ClickHouse-funkciigiston. Mi bildigis ZooKeeper ĉi tie. Kaj la funkciigisto interagas kun kaj ClickHouse kaj ZooKeeper. Tio estas, interago rezultoj.
Kaj ĉio ĉi estas necesa por ClickHouse sukcese reprodukti datumojn en k8s.
Ni nun rigardu la taskon mem, kiel aspektos la manifesto por reproduktado.
Ni aldonas du sekciojn al nia manifesto. La unua estas kie akiri ZooKeeper, kiu povas esti aŭ ene de Kubernetes aŭ ekstera. Ĉi tio estas nur priskribo. Kaj ni mendas kopiojn. Tiuj. ni volas du kopiojn. Entute, ni devus havi 4 podojn ĉe la eligo. Ni memoras pri stokado, ĝi revenos iom poste. Stokado estas aparta rakonto.
Estis tiel.
Fariĝas tiel. Replikoj estas aldonitaj. La 4-a ne konvenis, ni kredas, ke tie povus esti multaj el ili. Kaj ZooKeeper estas aldonita al la flanko. La skemoj fariĝas pli kompleksaj.
Kaj estas tempo aldoni la sekvan taskon. Ni aldonos Konstantan Stokadon.
Por Konstanta Stokado ni havas diversajn eblojn.
Se ni funkcias en nuba provizanto, ekzemple, uzante Amazon, Google, tiam estas granda tento uzi nuban stokadon. Ĝi estas tre oportuna, ĝi estas bona.
Kaj ekzistas dua opcio. Ĉi tio estas por loka stokado, kiam ni havas lokajn diskojn sur ĉiu nodo. Ĉi tiu opcio estas multe pli malfacile efektivigi, sed samtempe ĝi estas pli produktiva.
Ni vidu, kion ni havas pri nuba stokado.
Estas avantaĝoj. Ĝi estas tre facile agordi. Ni simple mendas de la nuba provizanto, ke bonvolu doni al ni stokadon de tia kaj tia kapablo, de tia kaj tia klaso. Klasoj estas planitaj de provizantoj sendepende.
Kaj estas malavantaĝo. Por iuj, ĉi tio estas ne-kritika malavantaĝo. Kompreneble, estos iuj agado problemoj. Ĝi estas tre oportuna uzi kaj fidinda, sed ekzistas iuj eblaj agado-malavantaĝoj.
Kaj ĉar ClickHouse temigas specife produktivecon, oni eĉ povus diri, ke ĝi elpremas ĉion, kion ĝi povas, tial multaj klientoj provas elpremi maksimuman produktivecon.
Kaj por profiti ĝin, ni bezonas lokan stokadon.
Kubernetes disponigas tri abstraktaĵojn por uzi lokan stokadon en Kubernetes. Ĉi tio:
- EmptyDir
- HostPath.
- lokaj
Ni rigardu kiel ili malsamas kaj kiel ili estas similaj.
Unue, en ĉiuj tri aliroj ni havas stokadon - ĉi tiuj estas lokaj diskoj, kiuj situas sur la sama fizika k8s-nodo. Sed ili havas kelkajn diferencojn.
Ni komencu per la plej simpla, t.e. emptyDir. Kio estas ĉi tio en la praktiko? En nia specifo, ni petas la kontenerigsistemon (plej ofte Docker) havigi al ni aliron al dosierujo sur la loka disko.
En praktiko, Docker kreas provizoran dosierujon ie laŭ siaj propraj vojoj kaj nomas ĝin longa hash. Kaj provizas interfacon por aliri ĝin.
Kiel ĉi tio funkcios laŭ agado? Ĉi tio funkcios ĉe loka diskrapideco, t.e. Ĉi tio estas plena aliro al via ŝraŭbo.
Sed ĉi tiu kazo havas sian malavantaĝon. Persista estas sufiĉe dubinda en ĉi tiu afero. La unuan fojon Docker moviĝas kun ujoj, Persistent perdiĝas. Se Kubernetes volas movi ĉi tiun Pod al alia disko ial, la datumoj estos perditaj.
Ĉi tiu aliro estas bona por provoj, ĉar ĝi jam montras normalan rapidecon, sed por io serioza ĉi tiu opcio ne taŭgas.
Tial ekzistas dua aliro. Ĉi tio estas hostPath. Se vi rigardas la antaŭan diapozitivon kaj ĉi tiun, vi povas vidi nur unu diferencon. Nia dosierujo translokiĝis de Docker rekte al la nodo Kubernetes. Ĉi tie estas iom pli simpla. Ni rekte specifas la vojon sur la loka dosiersistemo kie ni ŝatus konservi niajn datumojn.
Ĉi tiu metodo havas avantaĝojn. Ĉi tio jam estas vera Persistenta, kaj klasika ĉe tio. Ni havos datumojn registritajn sur la disko ĉe iu adreso.
Estas ankaŭ malavantaĝoj. Ĉi tio estas la komplekseco de administrado. Nia Kubernetes eble volas movi la Pod al alia fizika nodo. Kaj ĉi tie intervenas DevOps. Li devas ĝuste klarigi al la tuta sistemo, ke ĉi tiuj balgoj nur povas esti movitaj al tiuj nodoj, sur kiuj vi havas ion muntitan laŭ ĉi tiuj vojoj, kaj ne pli ol unu nodo samtempe. Estas sufiĉe malfacila.
Precipe por ĉi tiuj celoj, ni faris ŝablonojn en nia operatoro por kaŝi ĉi tiun tutan kompleksecon. Kaj vi povus simple diri: "Mi volas havi unu ekzemplon de ClickHouse por ĉiu fizika nodo kaj laŭ tia kaj tia vojo."
Sed ni ne estas la solaj, kiuj bezonas ĉi tiun bezonon, do la sinjoroj de Kubernetes mem ankaŭ komprenas, ke homoj volas havi aliron al fizikaj diskoj, do ili provizas trian tavolon.
Ĝi nomiĝas loka. Estas preskaŭ neniu diferenco de la antaŭa glitado. Nur antaŭe necesis permane konfirmi, ke ni ne povas translokigi ĉi tiujn podojn de nodo al nodo, ĉar ili devas esti alfiksitaj laŭ iu vojo al loka fizika disko, sed nun ĉi tiu tuta scio estas enkapsuligita en Kubernetes mem. Kaj ĝi rezultas multe pli facile agordi.
Ni revenu al nia praktika problemo. Ni revenu al la ŝablono YAML. Ĉi tie ni havas veran stokadon. Ni revenis al ĝi. Ni starigas la klasikan ŝablonon VolumeClaim kiel en k8s. Kaj ni priskribas kian stokadon ni volas.
Post tio, k8s petos stokadon. Asignos ĝin al ni en la StatefulSet. Kaj finfine ĝi estos je la dispono de ClickHouse.
Ni havis ĉi tiun skemon. Nia Konstanta Stokado estis ruĝa, kio ŝajnis sugesti, ke ĝi devas esti farita.
Kaj ĝi fariĝas verda. Nun la ClickHouse sur k8s-clusterskemo estas tute finpretigita. Ni havas fragmentojn, kopiojn, ZooKeeper, ni havas veran Persistentan, kiu estas efektivigita en unu maniero aŭ alia. La skemo jam estas plene funkcianta.
Ni daŭre vivas. Nia areto disvolviĝas. Kaj Alexey provas, kaj eldonas novan version de ClickHouse.
Ekestas praktika tasko - testi la novan version de ClickHouse sur nia areto. Kaj, kompreneble, vi ne volas ĉion eligi; vi volas meti novan version en unu kopion ie en la malproksima angulo, kaj eble ne unu novan version, sed du samtempe, ĉar ili ofte aperas.
Kion ni povas diri pri ĉi tio?
Ĉi tie ni havas ĝuste tian ŝancon. Ĉi tiuj estas podŝablonoj. Vi povas skribi, ke nia operatoro tute permesas al vi konstrui heterogenan areton. Tiuj. agordi, komencante de ĉiuj kopioj en amaso, finiĝante kun ĉiu persona kopio, kiun version ni volas ClickHouse, kiun version ni volas stokadon. Ni povas plene agordi la areton kun la agordo, kiun ni bezonas.
Ni eniru iom pli profunden. Antaŭ ĉi tio, ni parolis pri kiel ClickHouse-operatoro funkcias rilate al la specifaĵoj de ClickHouse.
Nun mi ŝatus diri kelkajn vortojn pri kiel ajna operatoro ĝenerale funkcias, same kiel kiel ĝi interagas kun K8s.
Ni rigardu unue interagi kun la K8s. Kio okazas kiam ni aplikas kubectl? Niaj objektoj aperas en etcd per la API.
Ekzemple, bazaj Kubernetes-objektoj: pod, StatefulSet, servo, kaj tiel plu laŭ la listo.
En ĉi tiu kazo, nenio fizika ankoraŭ okazas. Ĉi tiuj objektoj devas esti realigitaj en la areto.
Tiucele aperas regilo. La regilo estas speciala k8s-komponento, kiu povas materiigi ĉi tiujn priskribojn. Li scias kiel kaj kion fari fizike. Li scias kiel prizorgi ujojn, kio devas esti agordita tie por ke la servilo funkciu.
Kaj ĝi materiigas niajn objektojn en K8s.
Sed ni volas funkcii ne nur kun podoj kaj StatefulSets, ni volas krei ClickHouseInstallation, t.e. objekton de la tipo ClickHouse, por funkcii kun ĝi kiel ununura tuto. Ĝis nun ne ekzistas tia ebleco.
Sed K8s havas la jenan belan aferon. Ni volas, ke ni havu ie kiel ĉi tiu kompleksa ento, en kiu nia areto estus kunvenita el balgoj kaj StatefulSet.
Kaj kion oni devas fari por tio? Unue, Propra Rimeda Difino venas en la bildon. Kio ĝi estas? Ĉi tio estas priskribo por K8s, ke vi havos plian datumtipo, ke ni volas aldoni kutiman rimedon al la pod, StatefulSet, kiu estos kompleksa ene. Ĉi tio estas priskribo de la datumstrukturo.
Ni ankaŭ sendas ĝin tien per kubectl apply. Kubernetes feliĉe prenis ĝin.
Kaj nun en nia stokado, la objekto en etcd havas la ŝancon registri kutiman rimedon nomitan ClickHouseInstallation.
Sed nuntempe nenio plu okazos. Tio estas, se ni nun kreas la YAML-dosieron, kiun ni rigardis priskribante fragmentojn kaj kopiojn kaj diros "kubectl aplikas", tiam Kubernetes akceptos ĝin, metos ĝin en etcd kaj diros: "Bonege, sed mi ne scias kion fari. kun ĝi. Mi ne scias kiel konservi ClickHouseInstallation."
Sekve, ni bezonas iun por helpi Kubernetes servi la novan datumtipo. Maldekstre ni havas denaskan Kubernetes-regilon, kiu funkcias kun denaskaj datumtipoj. Kaj dekstre ni havu kutiman regilon, kiu povas funkcii kun kutimaj datumtipoj.
Kaj alimaniere ĝi nomiĝas operatoro. Mi specife inkludis ĝin ĉi tie kiel Kubernetes, ĉar ĝi ankaŭ povas esti efektivigita ekster K8s. Plej ofte, kompreneble, ĉiuj funkciigistoj estas ekzekutitaj en Kubernetes, sed nenio malhelpas ĝin stari ekstere, do ĉi tie ĝi estas speciale movita eksteren.
Kaj siavice, la kutima regilo, ankaŭ konata kiel la funkciigisto, interagas kun Kubernetes per la API. Ĝi jam scias kiel interagi kun la API. Kaj li jam scias kiel materiigi la kompleksan cirkviton, kiun ni volas fari el kutima rimedo. Ĝuste ĉi tion faras la funkciigisto.
Kiel funkcias la funkciigisto? Ni rigardu la dekstran flankon por vidi kiel li faras ĝin. Ni eksciu, kiel la operatoro realigas ĉion ĉi kaj kiel okazas plua interago kun K8s.
Operatoro estas programo. Ŝi estas evento-orientita. La funkciigisto abonas eventojn uzante la Kubernetes API. La Kubernetes API havas enirpunktojn, kie vi povas aboni eventojn. Kaj se io ŝanĝiĝas en K8s, tiam Kubernetes sendas eventojn al ĉiuj, t.e. kiu ajn abonis ĉi tiun API-punkton ricevos sciigojn.
La telefonisto abonas eventojn kaj devas fari ian reagon. Ĝia tasko estas respondi al estiĝantaj eventoj.
Eventoj estas generitaj per certaj ĝisdatigoj. Nia YAML-dosiero kun priskribo de ClickHouseInstallation alvenas. Li iris al etcd per kubectl apply. Okazaĵo estis ekigita tie, kaj kiel rezulto ĉi tiu evento venis al la ClickHouse-funkciigisto. La funkciigisto ricevis ĉi tiun priskribon. Kaj li devas fari ion. Se alvenis ĝisdatigo por la objekto ClickHouseInstallation, tiam vi devas ĝisdatigi la areton. Kaj la tasko de la funkciigisto estas ĝisdatigi la areton.
Kion li faras? Unue, ni devas ellabori agadplanon por tio, kion ni faros kun ĉi tiu ĝisdatigo. Ĝisdatigoj povas esti tre malgrandaj, t.e. malgranda en YAML-ekzekuto, sed povas kaŭzi tre grandajn ŝanĝojn sur la areto. Tial, la funkciigisto kreas planon, kaj tiam li algluiĝas al ĝi.
Laŭ tiu ĉi plano, li komencas kuiri ĉi tiun strukturon interne por materiigi guŝojn, servojn, t.e. fari kio estas lia ĉefa tasko. Jen kiel konstrui ClickHouse-grupon en Kubernetes.
Nun ni tuŝu tian interesan aferon. Ĉi tio estas divido de respondeco inter Kubernetes kaj la funkciigisto, t.e. kion Kubernetes faras, kion la funkciigisto faras, kaj kiel ili interagas unu kun la alia.
Kubernetes respondecas pri sistemaj aferoj, t.e. por baza aro de objektoj kiuj povas esti interpretitaj kiel sistem-skopo. Kubernetes scias kiel lanĉi podojn, kiel rekomenci ujojn, kiel munti volumojn, kiel labori kun ConfigMap, t.e. ĉio, kio povas esti nomata sistemo.
Operaciantoj funkcias en domajnoj. Ĉiu funkciigisto estas farita por sia propra temo. Ni faris ĝin por ClickHouse.
Kaj la funkciigisto interagas precize laŭ la temo, kiel aldoni kopion, fari diagramon, agordi monitoradon. Ĉi tio rezultigas dividon.
Ni rigardu praktikan ekzemplon de kiel ĉi tiu divido de respondeco okazas kiam ni faras la aldoni kopian agon.
La funkciigisto ricevas taskon - aldoni kopion. Kion faras la operatoro? La funkciigisto kalkulos, ke nova StatefulSet devas esti kreita, en kiu tiaj kaj tiaj ŝablonoj, volumena aserto, devas esti priskribitaj.
Li preparis ĉion kaj transdonas ĝin al K8s. Li diras, ke li bezonas ConfigMap, StatefulSet, Volume. Kubernetes funkcias. Li materiigas la bazajn unuojn per kiuj li funkcias.
Kaj tiam ClickHouse-funkciigisto denove venas en ludon. Li jam havas fizikan balgon, sur kiu li jam povas fari ion. Kaj ClickHouse-funkciigisto denove funkcias en domajnaj terminoj. Tiuj. Specife ClickHouse, por inkluzivi kopion en areto, vi unue devas agordi la datumskemon kiu ekzistas en ĉi tiu areto. Kaj, due, ĉi tiu kopio devas esti inkluzivita en la monitorado por ke ĝi estu klare spurita. La operatoro jam agordas ĉi tion.
Kaj nur post tio ClickHouse mem ekludas, t.e. alia pli alta nivela ento. Ĉi tio jam estas datumbazo. Ĝi havas sian propran ekzemplon, alian agorditan kopion, kiu pretas aliĝi al la areto.
Rezultas, ke ĉeno de ekzekuto kaj divido de respondeco aldonante kopion estas sufiĉe longa.
Ni daŭrigas niajn praktikajn taskojn. Se vi jam havas areton, vi povas migri la agordon.
Ni faris ĝin por ke vi povu alglui rekte en ekzistantan xml, kiun ClickHouse komprenas.
Vi povas agordi ClickHouse. Nur zonita deplojo estas pri kio mi parolis klarigante hostPath, loka stokado. Jen kiel fari zonitan deplojon ĝuste.
La sekva praktika tasko estas monitorado.
Se nia areto ŝanĝiĝas, tiam ni devas periode agordi monitoradon.
Ni rigardu la diagramon. Ni jam rigardis la verdajn sagojn ĉi tie. Nun ni rigardu la ruĝajn sagojn. Jen kiel ni volas monitori nian areton. Kiel metrikoj de la ClickHouse-areto eniras Prometheus, kaj poste en Grafana.
Kio estas la malfacilaĵo kun monitorado? Kial ĉi tio estas prezentita kiel ia atingo? La malfacilaĵo kuŝas en la dinamiko. Kiam ni havas unu areton kaj ĝi estas senmova, tiam ni povas agordi monitoradon unufoje kaj ne plu ĝeni.
Sed se ni havas multajn aretojn, aŭ io konstante ŝanĝiĝas, tiam la procezo estas dinamika. Kaj konstante reagordi monitoradon estas malŝparo de rimedoj kaj tempo, t.e. eĉ nur maldiligento. Ĉi tio devas esti aŭtomatigita. La malfacilaĵo kuŝas en la dinamiko de la procezo. Kaj la funkciigisto aŭtomatigas ĉi tion tre bone.
Kiel disvolviĝis nia areto? En la komenco li estis tia.
Tiam li estis tia.
Fine, li fariĝis tia.
Kaj monitorado estas farita aŭtomate de la funkciigisto. Ununura punkto de eniro.
Kaj ĝuste ĉe la elirejo ni rigardas la Grafana panelo por vidi kiel la vivo de nia areto bolas interne.
Cetere, Grafana panelo ankaŭ estas distribuita kun nia telefonisto rekte en la fontkodo. Vi povas konekti kaj uzi. Nia DevOps donis al mi ĉi tiun ekrankopion.
Kien ni ŝatus iri poste? Ĉi tio:
- Disvolvu testaŭtomatigon. La ĉefa tasko estas aŭtomata testado de novaj versioj.
- Ni ankaŭ vere volas aŭtomatigi la integriĝon kun ZooKeeper. Kaj estas planoj integriĝi kun ZooKeeper-funkciigisto. Tiuj. Operatoro estis skribita por ZooKeeper kaj estas logike, ke la du telefonistoj komencas integriĝi por konstrui pli oportunan solvon.
- Ni volas fari pli kompleksajn esencajn signojn.
- Mi reliefigis verde, ke ni proksimiĝas al heredo de Ŝablonoj - FARI, t.e. kun la venonta eldono de la operatoro ni jam havos heredon de ŝablonoj. Ĉi tio estas potenca ilo, kiu ebligas al vi konstrui kompleksajn agordojn el pecoj.
- Kaj ni volas aŭtomatigon de kompleksaj taskoj. La ĉefa estas Re-sharding.
Ni prenu kelkajn mezajn rezultojn.
Kion ni ricevas kiel rezulto? Kaj ĉu indas fari aŭ ne? Ĉu eĉ necesas provi treni la datumbazon en Kubernetes kaj uzi la operatoron ĝenerale kaj la operatoron Alitnity precipe?
Ĉe la eligo ni ricevas:
- Signifa simpligo kaj aŭtomatigo de agordo, deplojo kaj prizorgado.
- Tuj enkonstruita monitorado.
- Kaj uzeblaj kodigitaj ŝablonoj por kompleksaj situacioj. Ago kiel aldoni kopion ne bezonas esti farita permane. La operatoro faras ĉi tion.
Restas nur unu lasta demando. Ni jam havas datumbazon en Kubernetes, virtualigo. Kio pri la agado de tia solvo, precipe ĉar ClickHouse estas optimumigita por agado?
La respondo estas ĉio en ordo! Mi ne eniros en detalojn; ĉi tio estas la temo de aparta raporto.
Sed ekzistas tia projekto kiel TSBS. Kio estas ĝia ĉefa tasko? Ĉi tio estas datumbaza agado-testo. Ĉi tio estas provo kompari varma kun varma, mola kun mola.
Kiel li laboras? Unu datumaro estas generita. Tiam ĉi tiu aro de datumoj estas prizorgita sur malsamaj datumbazoj uzante la saman aron de testoj. Kaj ĉiu datumbazo solvas unu problemon laŭ la maniero kiel ĝi scias. Kaj tiam vi povas kompari la rezultojn.
Ĝi jam subtenas grandan aron da datumbazoj. Mi identigis tri ĉefajn. Ĉi tio:
- TimecaleDB.
- InfluxDB.
- KlakuDomo.
Oni faris ankaŭ komparo kun alia simila solvo. Komparo kun RedShift. Komparo estis farita ĉe Amazon. ClickHouse ankaŭ multe antaŭ ĉiuj en ĉi tiu afero.
Kiajn konkludojn oni povas eltiri el tio, kion mi diris?
- DB en Kubernetes eblas. Verŝajne iu ajn eblas, sed ĝenerale ŝajnas, ke ĝi eblas. ClickHouse en Kubernetes estas certe ebla kun la helpo de nia operatoro.
- La funkciigisto helpas aŭtomatigi procezojn kaj vere faciligas la vivon.
- Agado estas normala.
- Kaj ŝajnas al ni, ke ĉi tio povas kaj devas esti uzata.
Malferma fonto - aliĝu al ni!
Kiel mi jam diris, la funkciigisto estas tute malfermkoda produkto, do estus tre bone, se la maksimuma nombro da homoj uzus ĝin. Aliĝu al ni! Ni atendas vin ĉiujn!
Dankon al ĉiuj!
Viaj demandoj
Dankon pro la raporto! Mia nomo estas Antono. Mi estas de SEMrush. Mi scivolas, kio okazas kun arbohakado. Ni aŭdas pri monitorado, sed nenio pri arbohakado, se ni parolas pri la tuta areto. Ekzemple, ni kreis aron pri aparataro. Kaj ni uzas centralizitan registradon, kolektante ilin en komunan amason uzante normajn rimedojn. Kaj tiam de tie ni ricevas la datumojn, kiuj interesas nin.
Bona demando, t.e. ensaluti en liston. Nia funkciigisto ankoraŭ ne aŭtomatigas ĉi tion. Ĝi ankoraŭ disvolviĝas, la projekto estas ankoraŭ sufiĉe juna. Ni komprenas la bezonon de arbohakado. Ĉi tio ankaŭ estas tre grava temo. Kaj ĝi verŝajne ne estas malpli grava ol monitorado. Sed unue en la listo por efektivigo estis monitorado. Estos registriĝo. Nature, ni provas aŭtomatigi ĉiujn aspektojn de la vivo de la areto. Sekve, la respondo estas, ke nuntempe la telefonisto, bedaŭrinde, ne scias kiel fari tion, sed estas en la planoj, ni faros ĝin. Se vi volas aliĝi, tiam tiri peton, bonvolu.
Saluton! Dankon pro la raporto! Mi havas norman demandon rilate al Persistaj Volumoj. Kiam ni kreas agordon kun ĉi tiu operatoro, kiel la operatoro determinas sur kiu nodo ni havas apartan diskon aŭ dosierujon alfiksita? Ni unue devas klarigi al li, ke bonvolu meti nian ClickHouse sur ĉi tiujn nodojn, kiuj havas diskon?
Laŭ mia kompreno, ĉi tiu demando estas daŭrigo de loka stokado, precipe la hostPath-parto de ĝi. Ĉi tio estas kiel klarigi al la tuta sistemo, ke la podo devas esti lanĉita sur tia kaj tia nodo, al kiu ni havas fizike ligitan diskon, kiu estas muntita laŭ tia kaj tia vojo. Ĉi tio estas tuta sekcio, kiun mi tre supraĵe tuŝis, ĉar la respondo tie estas sufiĉe granda.
Mallonge ĝi aspektas tiel. Kompreneble, ni devas provizi ĉi tiujn volumojn. Nuntempe, ne ekzistas dinamika provizo en loka stokado, do DevOps devas tranĉi la diskojn mem, ĉi tiujn volumojn. Kaj ili devas klarigi Kubernetes-provizon, ke vi havos Konstantajn volumojn de tia kaj tia klaso, kiuj troviĝas sur tiaj kaj tiaj nodoj. Tiam vi devos klarigi al Kubernetes, ke podoj, kiuj postulas tian kaj tian lokan stokan klason, devas esti direktitaj nur al tiaj kaj tiaj nodoj uzante etikedojn. Por ĉi tiuj celoj, la funkciigisto havas la kapablon asigni ian etikedon kaj unu per gastiganta okazo. Kaj rezultas, ke kubernetoj sendos podojn por funkcii nur sur nodoj, kiuj plenumas la postulojn, etikedojn, en simplaj terminoj. Administrantoj atribuas etikedojn kaj provizas diskojn permane. Kaj tiam ĝi grimas.
Kaj ĝi estas la tria opcio, loka, kiu helpas fari ĉi tion iomete pli facila. Kiel mi jam emfazis, ĉi tio estas peniga laboro pri agordado, kiu finfine helpas akiri maksimuman rendimenton.
Mi havas duan demandon rilatan al ĉi tio. Kubernetes estis desegnita tiel, ke ne gravas al ni ĉu ni perdas nodon aŭ ne. Kion ni faru ĉi-kaze, se ni perdis la nodon, kie pendas nia breĉeto?
Jes, Kubernetes estis komence poziciigita, ke nia rilato kun niaj balgoj estas kiel brutaro, sed ĉi tie ĉe ni ĉiu disko fariĝas io kiel dorlotbesto. Estas tia problemo, ke ni ne povas simple forĵeti ilin. Kaj la evoluo de Kubernetes iras en la direkto, ke estas neeble tute filozofie trakti ĝin, kvazaŭ ĝi estus tute forĵetita rimedo.
Nun por praktika demando. Kion fari se vi perdis la nodon sur kiu estis la disko? Ĉi tie la problemo estas solvita je pli alta nivelo. En la kazo de ClickHouse, ni havas kopiojn kiuj funkcias je pli alta nivelo, t.e. ĉe la ClickHouse-nivelo.
Kio estas la rezulta dispozicio? DevOps estas respondeca por certigi ke datumoj ne estas perditaj. Li devas agordi reproduktadon ĝuste kaj devas certigi, ke reproduktado funkcias. La kopio ĉe la ClickHouse-nivelo devas havi duobligitajn datumojn. Ĉi tio ne estas la tasko, kiun la operatoro solvas. Kaj ne la problemo, kiun Kubernetes mem solvas. Ĉi tio estas ĉe la nivelo de ClickHouse.
Kion fari se via fera nodo defalas? Kaj montriĝas, ke vi devos instali duan, ĝuste provizi la diskon sur ĝi kaj apliki etikedojn. Kaj post tio, ĝi plenumos la postulojn, ke Kubernetes povas lanĉi ekzemplaron sur ĝi. Kubernetes lanĉos ĝin. Via nombro da balgoj ne sufiĉas por renkonti la specifitan nombron. Ĝi trairos la ciklon, kiun mi montris. Kaj ĉe la plej alta nivelo, ClickHouse komprenos, ke ni eniris kopion, ĝi ankoraŭ estas malplena kaj ni devas komenci transdoni datumojn al ĝi. Tiuj. Ĉi tiu procezo ankoraŭ ne estas bone aŭtomatigita.
Dankon pro la raporto! Kiam okazas ĉiaj malbonaj aferoj, la funkciigisto kraŝas kaj rekomencas, kaj en tiu momento alvenas eventoj, ĉu vi iel pritraktas ĉi tion?
Kio okazas se la funkciigisto kraŝis kaj rekomencis, ĉu ne?
Jes. Kaj en tiu momento la eventoj alvenis.
La tasko de kion fari en ĉi tiu kazo estas parte dividita inter la funkciigisto kaj Kubernetes. Kubernetes havas la kapablon reludi eventon kiu okazis. Li ripetas. Kaj la tasko de la funkciigisto estas certigi, ke kiam la evento-protokolo estas reludata sur li, ĉi tiuj eventoj estas idempotentaj. Kaj por ke la ripeta okazo de la sama evento ne rompu nian sistemon. Kaj nia telefonisto traktas ĉi tiun taskon.
Saluton! Dankon pro la raporto! Dmitrij Zavyalov, kompanio Smedova. Ĉu ekzistas planoj aldoni la kapablon agordi kun haproxy al la funkciigisto? Mi interesus pri iu alia ekvilibristo krom la norma, por ke ĝi estu inteligenta kaj komprenu, ke ClickHouse vere estas tie.
Ĉu vi parolas pri Ingress?
Jes, anstataŭigu Ingress per haproxy. En haproxy vi povas specifi la topologion de la areto kie ĝi havas kopiojn.
Ni ankoraŭ ne pensis pri ĝi. Se vi bezonas ĝin kaj povas klarigi kial ĝi estas bezonata, tiam eblos efektivigi ĝin, precipe se vi volas partopreni. Ni volonte pripensos la opcion. La mallonga respondo estas ne, ni nuntempe ne havas tian funkcion. Dankon pro la konsilo, ni esploros ĉi tiun aferon. Kaj se vi ankaŭ klarigas la uzkazon kaj kial ĝi estas bezonata en la praktiko, ekzemple, kreu problemojn en GitHub, tiam tio estos bonega.
Jam havas.
Bone. Ni estas malfermitaj al ajnaj sugestoj. Kaj haproxy estas aldonita al la listo de aferoj. La listo de laboroj kreskas, ankoraŭ ne ŝrumpas. Sed ĉi tio estas bona, tio signifas, ke la produkto estas postulata.
fonto: www.habr.com