Operator sa Kubernetes para sa pamamahala ng mga database cluster. Vladislav Klimenko (Altinity, 2019)

Ang ulat ay nakatuon sa mga praktikal na isyu ng pagbuo ng isang operator sa Kubernetes, pagdidisenyo ng arkitektura at mga pangunahing prinsipyo ng pagpapatakbo nito.

Sa unang bahagi ng ulat, isasaalang-alang namin ang:

• ano ang operator sa Kubernetes at bakit ito kailangan;
• kung paano eksaktong pinapasimple ng operator ang pamamahala ng mga kumplikadong sistema;
• kung ano ang magagawa at hindi maaaring gawin ng operator.

Susunod, magpatuloy tayo sa pagtalakay sa panloob na istraktura ng operator. Tingnan natin ang arkitektura at pagpapatakbo ng operator nang sunud-sunod. Tingnan natin ito nang detalyado:

• pakikipag-ugnayan sa pagitan ng operator at Kubernetes;
• kung anong mga function ang ginagawa ng operator at kung ano ang mga function na itinatalaga nito sa Kubernetes.

Tingnan natin ang pamamahala ng mga shards at database replicas sa Kubernetes.
Susunod, tatalakayin natin ang mga isyu sa pag-iimbak ng data:

• kung paano magtrabaho sa Persistent Storage mula sa punto ng view ng operator;
• mga pitfalls ng paggamit ng Local Storage.

Sa huling bahagi ng ulat, isasaalang-alang natin ang mga praktikal na halimbawa ng aplikasyon clickhouse-operator mula sa Amazon o Google Cloud Service. Ang ulat ay batay sa halimbawa ng pagbuo at karanasan sa pagpapatakbo ng isang operator para sa ClickHouse.

Video:

Ang pangalan ko ay Vladislav Klimenko. Ngayon nais kong pag-usapan ang aming karanasan sa pagbuo at pagpapatakbo ng isang operator, at ito ay isang dalubhasang operator para sa pamamahala ng mga kumpol ng database. Halimbawa ClickHouse-operator upang pamahalaan ang ClickHouse cluster.

Bakit tayo may pagkakataon na pag-usapan ang tungkol sa operator at ClickHouse?

• Sinusuportahan at binuo namin ang ClickHouse.
• Sa ngayon, sinusubukan naming dahan-dahang gawin ang aming kontribusyon sa pagpapaunlad ng ClickHouse. At kami ay pangalawa pagkatapos ng Yandex sa mga tuntunin ng dami ng mga pagbabagong ginawa sa ClickHouse.
• Sinusubukan naming lumikha ng mga karagdagang proyekto para sa ClickHouse ecosystem.

Gusto kong sabihin sa iyo ang tungkol sa isa sa mga proyektong ito. Ito ay tungkol sa ClickHouse-operator para sa Kubernetes.

Sa aking ulat, nais kong hawakan ang dalawang paksa:

• Ang unang paksa ay kung paano gumagana ang aming ClickHouse database management operator sa Kubernetes.
• Ang pangalawang paksa ay kung paano gumagana ang anumang operator, ibig sabihin, kung paano ito nakikipag-ugnayan sa Kubernetes.

Gayunpaman, ang dalawang tanong na ito ay magsalubong sa kabuuan ng aking ulat.

Sino ang magiging interesadong makinig sa sinusubukan kong sabihin?

• Ito ay magiging pinaka-interesado sa mga nagpapatakbo ng mga operator.
• O para sa mga gustong gumawa ng sarili nila upang maunawaan kung paano ito gumagana sa loob, kung paano nakikipag-ugnayan ang operator sa Kubernetes, at kung anong mga pitfall ang maaaring lumitaw.

Upang lubos na maunawaan kung ano ang tatalakayin natin ngayon, magandang ideya na malaman kung paano gumagana ang Kubernetes at magkaroon ng ilang pangunahing pagsasanay sa ulap.

Ano ang ClickHouse? Ito ay isang columnar database na may mga partikular na feature para sa online na pagproseso ng mga analytical na query. At ito ay ganap na open source.

At mahalaga para sa atin na malaman lamang ang dalawang bagay. Kailangan mong malaman na ito ay isang database, kaya ang sasabihin ko sa iyo ay magiging naaangkop sa halos anumang database. At ang katotohanan na ang ClickHouse DBMS na mga kaliskis ay napakahusay, ay nagbibigay ng halos linear na scalability. At samakatuwid, ang cluster state ay isang natural na estado para sa ClickHouse. At pinakainteresado kami sa pagtalakay kung paano ihatid ang ClickHouse cluster sa Kubernetes.

Bakit kailangan siya doon? Bakit hindi natin ito maipagpatuloy sa ating sarili? At ang mga sagot ay bahagyang teknikal at bahagyang organisasyon.

• Sa pagsasagawa, lalo tayong nakakaranas ng sitwasyon kung saan sa malalaking kumpanya halos lahat ng bahagi ay nasa Kubernetes na. Ang mga database ay nananatili sa labas.
• At ang tanong ay lalong itinatanong: "Maaari ba itong ilagay sa loob?" Samakatuwid, sinusubukan ng malalaking kumpanya na makamit ang pinakamataas na pag-iisa ng pamamahala upang mabilis na mapangasiwaan ang kanilang mga bodega ng data.
• At nakakatulong ito lalo na kung kailangan mo ng maximum na pagkakataon na ulitin ang parehong bagay sa isang bagong lugar, ibig sabihin, maximum portability.

Gaano kadali o mahirap ito? Siyempre, ito ay maaaring gawin sa pamamagitan ng kamay. Ngunit hindi ito gaanong simple, dahil mayroon kaming karagdagang pagiging kumplikado ng pamamahala sa Kubernetes mismo, ngunit sa parehong oras ang mga detalye ng ClickHouse ay naka-superimpose. At ang gayong pagsasama-sama ay nagreresulta.

At lahat ng ito ay nagbibigay ng isang medyo malaking hanay ng mga teknolohiya, na nagiging medyo mahirap na pamahalaan, dahil ang Kubernetes ay nagdadala ng sarili nitong pang-araw-araw na mga isyu sa pagpapatakbo, at ang ClickHouse ay nagdadala ng sarili nitong mga isyu sa pang-araw-araw na operasyon. Lalo na kung mayroon kaming ilang ClickHouse, at kailangan naming patuloy na gumawa ng isang bagay sa kanila.

Sa isang dynamic na configuration, ang ClickHouse ay may medyo malaking bilang ng mga isyu na lumilikha ng patuloy na pag-load sa DevOps:

• Kapag may gusto kaming baguhin sa ClickHouse, halimbawa, magdagdag ng replica o shard, kailangan naming pamahalaan ang configuration.
• Pagkatapos ay baguhin ang schema ng data, dahil ang ClickHouse ay may partikular na paraan ng sharding. Doon kailangan mong ilatag ang diagram ng data, ilatag ang mga pagsasaayos.
• Kailangan mong i-set up ang pagsubaybay.
• Pagkolekta ng mga log para sa mga bagong shards, para sa mga bagong replika.
• Alagaan ang pagpapanumbalik.
• At i-restart.

Ito ay mga nakagawiang gawain na talagang gusto kong gawing mas madaling gamitin.

Ang Kubernetes mismo ay nakakatulong nang maayos sa pagpapatakbo, ngunit sa mga pangunahing bagay sa system.

Ang Kubernetes ay mahusay sa pagpapadali at pag-automate ng mga bagay tulad ng:

• Paggaling.
• I-restart.
• Pamamahala ng sistema ng imbakan.

Iyan ay mabuti, iyon ang tamang direksyon, ngunit siya ay ganap na walang alam tungkol sa kung paano patakbuhin ang isang database cluster.

Gusto namin ng higit pa, gusto naming gumana ang buong database sa Kubernetes.

Gusto kong makakuha ng isang bagay tulad ng isang malaking magic red button na pinindot mo at isang cluster na may mga pang-araw-araw na gawain na kailangang lutasin ay inilalagay at pinananatili sa buong ikot ng buhay nito. ClickHouse cluster sa Kubernetes.

At sinubukan naming gumawa ng solusyon na makakatulong na mapadali ang gawain. Ito ay isang ClickHouse-operator para sa Kubernetes mula sa Altinity.

Ang operator ay isang programa na ang pangunahing gawain ay upang pamahalaan ang iba pang mga programa, ibig sabihin, ito ay isang tagapamahala.

At naglalaman ito ng mga pattern ng pag-uugali. Maaari mong tawagan itong codified na kaalaman tungkol sa paksang lugar.

At ang pangunahing gawain niya ay gawing mas madali ang buhay ng DevOps at bawasan ang micromanagement, para makapag-isip na siya (DevOps) sa mga high-level terms, i.e., para hindi siya (DevOps) makisali sa micromanagement, para hindi siya mag-configure. manu-mano ang lahat ng mga detalye.

At ang operator lang ay isang robotic assistant na nakikitungo sa mga microtasks at tumutulong sa DevOps.

Bakit kailangan mo ng operator? Siya ay gumaganap nang mahusay sa dalawang lugar:

• Kapag ang espesyalista na nakikitungo sa ClickHouse ay walang sapat na karanasan, ngunit kailangan nang magpatakbo ng ClickHouse, pinapadali ng operator ang operasyon at pinapayagan kang magpatakbo ng isang ClickHouse cluster na may medyo kumplikadong pagsasaayos, nang hindi naglalagay ng masyadong maraming detalye tungkol sa kung paano gumagana ang lahat. sa loob. Bibigyan mo lang siya ng mataas na antas ng mga gawain, at ito ay gumagana.
• At ang pangalawang gawain kung saan ito gumaganap ng pinakamahusay ay kapag ito ay kinakailangan upang i-automate ang isang malaking bilang ng mga tipikal na gawain. Tinatanggal ang mga microtasks mula sa mga administrator ng system.

Ito ay pinaka-kailangan alinman sa mga nagsisimula pa lamang sa kanilang paglalakbay, o ng mga kailangang gumawa ng maraming automation.

Paano naiiba ang diskarteng nakabatay sa operator sa ibang mga sistema? May Helm. Nakakatulong din ang pag-install ng ClickHouse; maaari kang gumuhit ng mga chart ng timon, na mag-i-install pa ng isang buong cluster ng ClickHouse. Ano ang pagkakaiba sa pagitan ng operator at pareho, halimbawa, Helm?

Ang pangunahing pangunahing pagkakaiba ay ang Helm ay pamamahala ng pakete at ang Operator ay nagpapatuloy ng isang hakbang. Ito ay suporta para sa buong ikot ng buhay. Ito ay hindi lamang pag-install, ito ay mga pang-araw-araw na gawain na kinabibilangan ng scaling, sharding, i.e. lahat ng kailangang gawin sa panahon ng ikot ng buhay (kung kinakailangan, pagkatapos ay tanggalin din) - lahat ito ay napagpasyahan ng operator. Sinusubukan nitong i-automate at mapanatili ang buong lifecycle ng software. Ito ang pangunahing pagkakaiba nito mula sa iba pang mga solusyon na ipinakita.

Iyon ang introductory part, let's move on.

Paano namin bubuo ang aming operator? Sinusubukan naming lapitan ang isyu upang pamahalaan ang cluster ng ClickHouse bilang isang mapagkukunan.

Narito mayroon kaming data ng input sa kaliwang bahagi ng larawan. Ito ang YAML na may cluster specification, na ipinapasa sa Kubernetes sa klasikong paraan sa pamamagitan ng kubectl. Doon kinuha ito ng aming operator at ginagawa ang kanyang mahika. At sa output makuha namin ang sumusunod na scheme. Isa itong pagpapatupad ng ClickHouse sa Kubernetes.

At pagkatapos ay dahan-dahan nating titingnan kung paano eksaktong gumagana ang operator, kung anong mga tipikal na gawain ang maaaring malutas. Isasaalang-alang lamang namin ang mga tipikal na gawain dahil mayroon kaming limitadong oras. At hindi lahat ng bagay na mapagpasyahan ng operator ay tatalakayin.

Magsimula tayo sa practice. Ang aming proyekto ay ganap na open source, para makita mo kung paano ito gumagana sa GitHub. At maaari kang magpatuloy mula sa mga pagsasaalang-alang na kung gusto mo lamang itong ilunsad, maaari kang magsimula sa Gabay sa Mabilis na Pagsisimula.

Kung nais mong maunawaan nang detalyado, pagkatapos ay susubukan naming mapanatili ang dokumentasyon sa isang mas o hindi gaanong disenteng anyo.

Magsimula tayo sa isang praktikal na problema. Ang unang gawain, kung saan gusto nating lahat na magsimula, ay patakbuhin ang unang halimbawa kahit papaano. Paano ko ilulunsad ang ClickHouse gamit ang operator, kahit na hindi ko talaga alam kung paano ito gumagana? Nagsusulat kami ng manifesto, dahil... Ang lahat ng komunikasyon sa k8s ay komunikasyon sa pamamagitan ng mga manifest.

Ito ay isang kumplikadong manifesto. Ang na-highlight natin sa pula ay ang kailangan nating pagtuunan ng pansin. Hinihiling namin sa operator na gumawa ng cluster na pinangalanang demo.

Ito ang mga pangunahing halimbawa sa ngayon. Hindi pa inilarawan ang storage, ngunit babalik kami sa storage mamaya. Sa ngayon, obserbahan natin ang dynamics ng pag-unlad ng cluster.

Ginawa namin ang manifesto na ito. Pinapakain namin ito sa aming operator. Nagtrabaho siya, gumawa siya ng magic.

Tumingin kami sa console. Tatlong bahagi ang kinaiinteresan: isang Pod, dalawang Serbisyo, at isang StatefulSet.

Nagtrabaho ang operator, at makikita natin kung ano ang eksaktong nilikha niya.

Gumagawa siya ng ganito. Mayroon kaming StatefulSet, Pod, ConfigMap para sa bawat replica, ConfigMap para sa buong cluster. Kinakailangan ang mga serbisyo bilang mga entry point sa cluster.

Ang mga serbisyo ay ang sentral na Serbisyo ng Load Balancer at maaari ding gamitin para sa bawat replica, para sa bawat shard.

Ang aming pangunahing cluster ay ganito ang hitsura. Ito ay mula sa isang solong node.

Magpatuloy pa tayo at gawing kumplikado ang mga bagay. Kailangan nating hatiin ang kumpol.

Ang aming mga gawain ay lumalaki, ang dinamika ay nagsisimula. Gusto naming magdagdag ng isang shard. Sinusunod namin ang pag-unlad. Binabago namin ang aming pagtutukoy. Ipinapahiwatig namin na gusto namin ng dalawang shards.

Ito ang parehong file na dynamic na nabubuo sa paglaki ng system. Storage no, storage ay tatalakayin pa, ito ay isang hiwalay na paksa.

Pinapakain namin ang operator ng YAML at tingnan kung ano ang mangyayari.

Inisip at ginawa ng operator ang mga sumusunod na entity. Mayroon na kaming dalawang Pod, tatlong Serbisyo at, biglang, 2 StatefulSets. Bakit 2 StatefulSets?

Sa diagram ito ay ganito - ito ang aming paunang estado, kapag mayroon kaming isang pod.

Naging ganito. Sa ngayon ang lahat ay simple, ito ay nadoble.

At bakit nagkaroon ng dalawang StatefulSets? Dito kailangan nating lumihis at talakayin ang tanong kung paano pinamamahalaan ang mga Pod sa Kubernetes.

Mayroong isang bagay na tinatawag na StatefulSet na nagbibigay-daan sa iyong lumikha ng isang set ng Pods mula sa isang template. Ang pangunahing kadahilanan dito ay Template. At maaari kang maglunsad ng maraming Pod gamit ang isang template sa isang StatefulSet. At ang pangunahing parirala dito ay "maraming Pod para sa isang template."

At nagkaroon ng isang mahusay na tukso upang gawin ang buong kumpol, i-pack ito sa isang StatefulSet. Ito ay gagana, walang problema dito. Ngunit mayroong isang caveat. Kung gusto naming mag-ipon ng isang magkakaibang kumpol, iyon ay, mula sa ilang mga bersyon ng ClickHouse, pagkatapos ay magsisimulang lumitaw ang mga tanong. Oo, ang StatefulSet ay maaaring gumawa ng isang rolling update, at doon maaari kang maglunsad ng isang bagong bersyon, ipaliwanag na kailangan mong subukan ang hindi hihigit sa napakaraming mga node sa parehong oras.

Ngunit kung i-extrapolate namin ang gawain at sasabihin na gusto naming gumawa ng isang ganap na magkakaibang cluster at hindi namin nais na baguhin mula sa lumang bersyon sa isang bago gamit ang isang rolling update, ngunit gusto lang naming lumikha ng isang heterogenous cluster pareho sa mga termino ng iba't ibang bersyon ng ClickHouse at sa mga tuntunin ng iba't ibang storage. Nais naming, halimbawa, na gumawa ng ilang mga replika sa magkakahiwalay na mga disk, sa mga mabagal, sa pangkalahatan, upang ganap na bumuo ng isang magkakaibang kumpol. At dahil ang StatefulSet ay gumagawa ng isang standardized na solusyon mula sa isang template, walang paraan upang gawin ito.

Pagkatapos ng ilang pag-iisip, napagpasyahan na gagawin namin ito sa ganitong paraan. Mayroon kaming bawat replica sa sarili nitong StatefulSet. Mayroong ilang mga disbentaha sa solusyon na ito, ngunit sa pagsasagawa ito ay ganap na na-encapsulated ng operator. At mayroong maraming mga pakinabang. Maaari tayong bumuo ng eksaktong cluster na gusto natin, halimbawa, isang ganap na heterogenous. Samakatuwid, sa isang cluster kung saan mayroon kaming dalawang shards na may isang replica, magkakaroon kami ng 2 StatefulSets at 2 Pods dahil pinili namin ang diskarteng ito para sa mga kadahilanang nakasaad sa itaas upang makabuo ng isang heterogenous cluster.

Bumalik tayo sa mga praktikal na problema. Sa aming cluster kailangan naming i-configure ang mga user, i.e. kailangan mong gawin ang ilang configuration ng ClickHouse sa Kubernetes. Ang operator ay nagbibigay ng lahat ng mga posibilidad para dito.

Maaari naming isulat ang gusto namin nang direkta sa YAML. Ang lahat ng mga opsyon sa pagsasaayos ay direktang namamapa mula sa YAML na ito sa mga ClickHouse config, na pagkatapos ay ipinamamahagi sa buong cluster.

Maaari mong isulat ito ng ganito. Ito ay halimbawa. Maaaring i-encrypt ang password. Talagang sinusuportahan ang lahat ng opsyon sa pagsasaayos ng ClickHouse. Narito ang isang halimbawa lamang.

Ang configuration ng cluster ay ipinamamahagi bilang ConfigMap. Sa pagsasagawa, ang pag-update ng ConfigMap ay hindi nangyayari kaagad, kaya kung ang cluster ay malaki, ang proseso ng pagtulak sa configuration ay tumatagal ng ilang oras. Ngunit ang lahat ng ito ay napaka-maginhawang gamitin.

Gawin nating kumplikado ang gawain. Ang kumpol ay umuunlad. Gusto naming kopyahin ang data. Ibig sabihin, mayroon na tayong dalawang shards, tig-iisang replika, at naka-configure ang mga user. Kami ay lumalaki at nais na gumawa ng pagtitiklop.

Ano ang kailangan natin para sa pagtitiklop?

Kailangan namin ng ZooKeeper. Sa ClickHouse, ang pagtitiklop ay binuo gamit ang ZooKeeper. Kinakailangan ang ZooKeeper upang magkaroon ng consensus ang iba't ibang replika ng ClickHouse tungkol sa kung aling mga bloke ng data ang nasa kung saan ang ClickHouse.

Maaaring gamitin ng sinuman ang ZooKeeper. Kung ang enterprise ay may panlabas na ZooKeeper, maaari itong magamit. Kung hindi, maaari mo itong i-install mula sa aming imbakan. Mayroong isang installer na ginagawang mas madali ang buong bagay na ito.

At ang diagram ng pakikipag-ugnayan ng buong sistema ay nagiging ganito. Mayroon kaming Kubernetes bilang isang plataporma. Isinasagawa nito ang ClickHouse operator. Napicturan ko ang ZooKeeper dito. At nakikipag-ugnayan ang operator sa ClickHouse at ZooKeeper. Ibig sabihin, mga resulta ng pakikipag-ugnayan.

At ang lahat ng ito ay kinakailangan para sa ClickHouse upang matagumpay na magtiklop ng data sa k8s.

Tingnan natin ngayon ang gawain mismo, kung ano ang magiging hitsura ng manifest para sa pagtitiklop.

Nagdaragdag kami ng dalawang seksyon sa aming manifest. Ang una ay kung saan makakakuha ng ZooKeeper, na maaaring nasa loob ng Kubernetes o panlabas. Ito ay isang paglalarawan lamang. At nag-order kami ng mga replika. Yung. gusto namin ng dalawang replika. Sa kabuuan, dapat tayong magkaroon ng 4 na pod sa output. Naaalala namin ang tungkol sa imbakan, babalik ito mamaya. Ang imbakan ay isang hiwalay na kuwento.

Ito ay tulad nito.

Nagiging ganito. Ang mga replika ay idinagdag. Hindi kasya ang ika-4, naniniwala kami na maaaring marami sila doon. At ang ZooKeeper ay idinagdag sa gilid. Ang mga scheme ay nagiging mas kumplikado.

At oras na para idagdag ang susunod na gawain. Magdaragdag kami ng Persistent Storage.

Para sa Persistent Storage mayroon kaming iba't ibang mga opsyon.

Kung kami ay tumatakbo sa isang cloud provider, halimbawa, gamit ang Amazon, Google, kung gayon mayroong isang mahusay na tukso na gumamit ng cloud storage. Ito ay napaka maginhawa, ito ay mabuti.

At mayroong pangalawang pagpipilian. Ito ay para sa lokal na imbakan, kapag mayroon kaming mga lokal na disk sa bawat node. Ang pagpipiliang ito ay mas mahirap ipatupad, ngunit sa parehong oras ito ay mas produktibo.

Tingnan natin kung ano ang mayroon tayo tungkol sa cloud storage.

May mga pakinabang. Napakadaling i-configure. Nag-order lang kami mula sa cloud provider na mangyaring bigyan kami ng storage ng ganoon at ganoong kapasidad, ng ganito at ganoong klase. Ang mga klase ay independiyenteng nakaiskedyul ng mga provider.

At may sagabal. Para sa ilan, ito ay isang hindi kritikal na disbentaha. Siyempre, magkakaroon ng ilang mga isyu sa pagganap. Ito ay napaka-maginhawang gamitin at maaasahan, ngunit may ilang mga potensyal na kakulangan sa pagganap.

At dahil Ang ClickHouse ay partikular na nakatutok sa pagiging produktibo, maaaring sabihin ng isa na pinipiga nito ang lahat ng makakaya nito, kaya naman maraming mga kliyente ang sumusubok na pisilin ang pinakamataas na produktibidad.

At para masulit ito, kailangan namin ng lokal na storage.

Nagbibigay ang Kubernetes ng tatlong abstraction para sa paggamit ng lokal na storage sa Kubernetes. ito:

• EmptyDir
• HostPath.
• Lokal

Tingnan natin kung paano sila naiiba at kung paano sila magkatulad.

Una, sa lahat ng tatlong diskarte mayroon kaming imbakan - ito ay mga lokal na disk na matatagpuan sa parehong pisikal na k8s node. Ngunit mayroon silang ilang mga pagkakaiba.

Magsimula tayo sa pinakasimpleng isa, i.e. emptyDir. Ano ito sa pagsasanay? Sa aming detalye, hinihiling namin sa containerization system (kadalasan Docker) na bigyan kami ng access sa isang folder sa lokal na disk.

Sa pagsasagawa, ang Docker ay lumilikha ng isang pansamantalang folder sa isang lugar kasama ang sarili nitong mga landas at tinatawag itong isang mahabang hash. At nagbibigay ng interface para ma-access ito.

Paano ito gagana sa performance-wise? Ito ay gagana sa lokal na bilis ng disk, i.e. Ito ay ganap na access sa iyong turnilyo.

Ngunit ang kasong ito ay may sagabal. Ang persistent ay medyo kahina-hinala sa bagay na ito. Sa unang pagkakataong lumipat si Docker na may mga container, mawawala ang Persistent. Kung gustong ilipat ng Kubernetes ang Pod na ito sa isa pang disk para sa ilang kadahilanan, mawawala ang data.

Ang diskarte na ito ay mabuti para sa mga pagsubok, dahil nagpapakita na ito ng normal na bilis, ngunit para sa isang bagay na seryoso ang pagpipiliang ito ay hindi angkop.

Samakatuwid, mayroong pangalawang diskarte. Ito ang hostPath. Kung titingnan mo ang nakaraang slide at ang isang ito, makikita mo lamang ang isang pagkakaiba. Ang aming folder ay lumipat mula sa Docker nang direkta sa Kubernetes node. Ito ay medyo mas simple dito. Direkta naming tinukoy ang path sa lokal na file system kung saan namin gustong iimbak ang aming data.

Ang pamamaraang ito ay may mga pakinabang. Isa na itong tunay na Persistent, at isang klasiko na. Magkakaroon kami ng data na naitala sa disk sa ilang address.

May mga disadvantages din. Ito ang pagiging kumplikado ng pamamahala. Maaaring gusto ng aming mga Kubernete na ilipat ang Pod sa isa pang pisikal na node. At dito pumapasok ang DevOps. Dapat niyang ipaliwanag nang tama sa buong system na ang mga pod na ito ay maaari lamang ilipat sa mga node kung saan mayroon kang isang bagay na naka-mount sa mga landas na ito, at hindi hihigit sa isang node sa isang pagkakataon. Medyo mahirap.

Lalo na para sa mga layuning ito, gumawa kami ng mga template sa aming operator upang maitago ang lahat ng pagiging kumplikadong ito. At masasabi mo lang: "Gusto kong magkaroon ng isang instance ng ClickHouse para sa bawat pisikal na node at kasama ng ganoon at ganoong landas."

Ngunit hindi lamang kami ang nangangailangan ng pangangailangang ito, kaya naiintindihan din ng mga ginoo mula sa Kubernetes mismo na ang mga tao ay gustong magkaroon ng access sa mga pisikal na disk, kaya nagbibigay sila ng ikatlong layer.

Ito ay tinatawag na lokal. Halos walang pagkakaiba mula sa nakaraang slide. Bago lamang kinakailangan na manu-manong kumpirmahin na hindi namin maililipat ang mga pod na ito mula sa node patungo sa node, dahil dapat na naka-attach ang mga ito sa ilang landas patungo sa isang lokal na pisikal na disk, ngunit ngayon ang lahat ng kaalamang ito ay naka-encapsulated sa Kubernetes mismo. At lumalabas na mas madaling i-configure.

Balik tayo sa ating praktikal na problema. Bumalik tayo sa template ng YAML. Narito mayroon kaming tunay na imbakan. Balik tayo dito. Itinakda namin ang klasikong VolumeClaim na template tulad ng sa k8s. At inilalarawan namin kung anong uri ng storage ang gusto namin.

Pagkatapos nito, hihiling ng storage ang k8s. Ilalaan ito sa amin sa StatefulSet. At sa huli ito ay nasa pagtatapon ng ClickHouse.

Nagkaroon kami ng ganitong scheme. Ang aming Persistent Storage ay pula, na tila nagpapahiwatig na kailangan itong gawin.

At ito ay nagiging berde. Ngayon ang ClickHouse sa k8s cluster scheme ay ganap na natapos. Mayroon kaming mga shards, replicas, ZooKeeper, mayroon kaming isang tunay na Persistent, na ipinatupad sa isang paraan o iba pa. Ang scheme ay ganap na gumagana.

Patuloy tayong nabubuhay. Ang aming cluster ay umuunlad. At sinubukan ni Alexey, at naglabas ng bagong bersyon ng ClickHouse.

Isang praktikal na gawain ang lumitaw - upang subukan ang bagong bersyon ng ClickHouse sa aming cluster. At, natural, hindi mo gustong ilabas ang lahat; gusto mong maglagay ng bagong bersyon sa isang replika sa isang lugar sa dulong sulok, at maaaring hindi isang bagong bersyon, ngunit dalawa nang sabay-sabay, dahil madalas silang lumabas.

Ano ang masasabi natin tungkol dito?

Dito lang tayo may ganitong pagkakataon. Ito ay mga template ng pod. Maaari mong isulat na ganap na pinapayagan ka ng aming operator na bumuo ng isang magkakaibang cluster. Yung. i-configure, simula sa lahat ng mga replika sa isang bungkos, na nagtatapos sa bawat personal na replika, kung aling bersyon ang gusto naming ClickHouse, kung aling bersyon ang gusto naming imbakan. Maaari naming ganap na i-configure ang cluster gamit ang configuration na kailangan namin.

Palalimin pa natin ng kaunti. Bago ito, napag-usapan natin kung paano gumagana ang ClickHouse-operator na may kaugnayan sa mga detalye ng ClickHouse.

Ngayon gusto kong magsabi ng ilang salita tungkol sa kung paano gumagana ang anumang operator sa pangkalahatan, pati na rin kung paano ito nakikipag-ugnayan sa mga K8.

Tingnan muna natin ang pakikipag-ugnayan sa mga K8. Ano ang mangyayari kapag nag-apply kami ng kubectl? Lumilitaw ang aming mga bagay sa etcd sa pamamagitan ng API.

Halimbawa, ang mga pangunahing bagay ng Kubernetes: pod, StatefulSet, serbisyo, at iba pa sa listahan.

At the same time, wala pang pisikal na nangyayari. Ang mga bagay na ito ay dapat ma-materialize sa kumpol.

Para sa layuning ito, lumilitaw ang isang controller. Ang controller ay isang espesyal na bahagi ng k8s na maaaring magkatotoo sa mga paglalarawang ito. Alam niya kung paano at kung ano ang gagawin sa pisikal. Alam niya kung paano magpatakbo ng mga lalagyan, kung ano ang kailangang i-configure doon para gumana ang server.

At ginagawa nito ang aming mga bagay sa K8s.

Ngunit gusto naming gumana hindi lamang sa mga pod at StatefulSets, gusto naming lumikha ng ClickHouseInstallation, ibig sabihin, isang object ng uri ng ClickHouse, upang gumana kasama nito bilang isang solong kabuuan. Sa ngayon ay walang ganoong posibilidad.

Ngunit ang K8s ay may sumusunod na magandang bagay. Gusto naming magkaroon kami ng ganoong kumplikadong entity sa isang lugar, kung saan ang aming cluster ay bubuoin mula sa mga pod at StatefulSet.

At ano ang kailangang gawin para dito? Una, papasok sa larawan ang Custom na Resource Definition. Ano ito? Isa itong paglalarawan para sa mga K8, na magkakaroon ka ng isa pang uri ng data, na gusto naming magdagdag ng custom na mapagkukunan sa pod, StatefulSet, na magiging kumplikado sa loob. Ito ay isang paglalarawan ng istraktura ng data.

Ipinapadala din namin ito doon sa pamamagitan ng kubectl apply. Masayang kinuha ito ng Kubernetes.

At ngayon sa aming imbakan, ang bagay sa etcd ay may pagkakataong mag-record ng custom na mapagkukunan na tinatawag na ClickHouseInstallation.

Pero sa ngayon wala pang mangyayari. Ibig sabihin, kung gagawin natin ngayon ang YAML file na tinitingnan natin na naglalarawan ng mga shards at replicas at sasabihing "kubectl apply," tatanggapin ito ng Kubernetes, ilagay ito sa etcd at sasabihin: "Mahusay, ngunit hindi ko alam kung ano ang gagawin kasama. Hindi ko alam kung paano i-maintain ang ClickHouseInstallation."

Alinsunod dito, kailangan namin ng isang tao na tumulong sa Kubernetes na ihatid ang bagong uri ng data. Sa kaliwa mayroon kaming native na Kubernetes controller na gumagana sa mga native na uri ng data. At sa kanan dapat mayroon tayong custom na controller na maaaring gumana sa mga custom na uri ng data.

At sa ibang paraan ito ay tinatawag na operator. Partikular kong isinama dito bilang Kubernetes, dahil maaari rin itong isagawa sa labas ng mga K8. Kadalasan, siyempre, ang lahat ng mga operator ay isinasagawa sa Kubernetes, ngunit walang pumipigil dito mula sa pagtayo sa labas, kaya dito ito ay espesyal na inilipat sa labas.

At sa turn, ang custom na controller, na kilala rin bilang operator, ay nakikipag-ugnayan sa Kubernetes sa pamamagitan ng API. Alam na nito kung paano makipag-ugnayan sa API. At alam na niya kung paano i-materialize ang kumplikadong circuit na gusto naming gawin mula sa isang custom na mapagkukunan. Ito mismo ang ginagawa ng operator.

Paano gumagana ang operator? Tingnan natin ang kanang bahagi upang makita kung paano niya ito ginagawa. Alamin natin kung paano ginagawa ng operator ang lahat ng ito at kung paano nangyayari ang karagdagang pakikipag-ugnayan sa mga K8.

Ang operator ay isang programa. Event-oriented siya. Nag-subscribe ang operator sa mga kaganapan gamit ang Kubernetes API. Ang Kubernetes API ay may mga entry point kung saan maaari kang mag-subscribe sa mga kaganapan. At kung may magbabago sa mga K8, magpapadala ang Kubernetes ng mga kaganapan sa lahat, i.e. kung sino ang nag-subscribe sa API point na ito ay makakatanggap ng mga notification.

Nag-subscribe ang operator sa mga kaganapan at dapat gumawa ng ilang uri ng reaksyon. Ang gawain nito ay tumugon sa mga umuusbong na kaganapan.

Ang mga kaganapan ay nabuo sa pamamagitan ng ilang mga update. Dumating ang aming YAML file na may paglalarawan ng ClickHouseInstallation. Pumunta siya sa etcd through kubectl apply. Ang isang kaganapan ay na-trigger doon, at bilang isang resulta ang kaganapang ito ay dumating sa ClickHouse-operator. Natanggap ng operator ang paglalarawang ito. At may dapat siyang gawin. Kung may dumating na update para sa ClickHouseInstallation object, kailangan mong i-update ang cluster. At ang gawain ng operator ay i-update ang cluster.

Ano ang ginagawa niya? Una, kailangan naming gumuhit ng plano ng aksyon para sa kung ano ang gagawin namin sa update na ito. Maaaring napakaliit ng mga update, ibig sabihin. maliit sa YAML execution, ngunit maaaring magsama ng napakalaking pagbabago sa cluster. Samakatuwid, ang operator ay lumilikha ng isang plano, at pagkatapos ay nananatili siya dito.

Ayon sa planong ito, sinimulan niyang lutuin ang istrakturang ito sa loob upang maisakatuparan ang mga pod, serbisyo, i.e. gawin kung ano ang kanyang pangunahing gawain. Ito ay kung paano bumuo ng ClickHouse cluster sa Kubernetes.

Ngayon ay hawakan natin ang isang kawili-wiling bagay. Ito ay isang dibisyon ng responsibilidad sa pagitan ng Kubernetes at ng operator, i.e. kung ano ang ginagawa ng Kubernetes, kung ano ang ginagawa ng operator, at kung paano sila nakikipag-ugnayan sa isa't isa.

Ang Kubernetes ay may pananagutan para sa mga bagay ng system, i.e. para sa isang pangunahing hanay ng mga bagay na maaaring bigyang-kahulugan bilang saklaw ng system. Alam ng Kubernetes kung paano maglunsad ng mga pod, kung paano i-restart ang mga container, kung paano mag-mount ng mga volume, kung paano magtrabaho sa ConfigMap, i.e. lahat ng bagay na matatawag na sistema.

Ang mga operator ay nagpapatakbo sa mga domain. Ang bawat operator ay ginawa para sa sarili nitong subject area. Ginawa namin ito para sa ClickHouse.

At tiyak na nakikipag-ugnayan ang operator sa mga tuntunin ng lugar ng paksa, tulad ng pagdaragdag ng replika, paggawa ng diagram, pag-set up ng pagsubaybay. Nagreresulta ito sa isang dibisyon.

Tingnan natin ang isang praktikal na halimbawa kung paano nangyayari ang paghahati ng responsibilidad na ito kapag ginawa natin ang aksyon na magdagdag ng replika.

Ang operator ay tumatanggap ng isang gawain - upang magdagdag ng isang kopya. Ano ang ginagawa ng operator? Kakalkulahin ng operator na kailangang gumawa ng bagong StatefulSet, kung saan dapat ilarawan ang ganito at ganoong mga template, volume claim.

Inihanda niya ang lahat at ipinasa sa K8s. Sinabi niya na kailangan niya ng ConfigMap, StatefulSet, Volume. Gumagana ang Kubernetes. Ginawa niya ang mga pangunahing yunit kung saan siya nagpapatakbo.

At pagkatapos ay muling maglaro ang ClickHouse-operator. Mayroon na siyang pisikal na pod kung saan may magagawa na siya. At gumagana muli ang ClickHouse-operator sa mga termino ng domain. Yung. Sa partikular, ang ClickHouse, upang maisama ang isang replika sa isang kumpol, dapat mo munang i-configure ang schema ng data na umiiral sa cluster na ito. At, pangalawa, ang replica na ito ay dapat isama sa pagsubaybay para malinaw na ma-trace. Kino-configure na ito ng operator.

At pagkatapos lamang na ang ClickHouse mismo ay naglaro, i.e. isa pang mas mataas na antas ng entity. Isa na itong database. Mayroon itong sariling instance, isa pang naka-configure na replica na handang sumali sa cluster.

Lumalabas na medyo mahaba ang chain of execution at division of responsibility kapag nagdadagdag ng replica.

Ipinagpapatuloy namin ang aming mga praktikal na gawain. Kung mayroon ka nang cluster, maaari mong i-migrate ang configuration.

Ginawa namin ito upang mai-paste mo mismo sa umiiral na xml, na naiintindihan ng ClickHouse.

Maaari mong i-fine-tune ang ClickHouse. Ang naka-zone na deployment lang ang napag-usapan ko noong nagpapaliwanag sa hostPath, lokal na imbakan. Ito ay kung paano gawin ang zoned deployment nang tama.

Ang susunod na praktikal na gawain ay pagsubaybay.

Kung nagbabago ang aming cluster, kailangan naming pana-panahong i-configure ang pagsubaybay.

Tingnan natin ang diagram. Napatingin na kami sa mga green arrow dito. Ngayon tingnan natin ang mga pulang arrow. Ito ay kung paano namin gustong subaybayan ang aming cluster. Paano napupunta sa Prometheus ang mga sukatan mula sa cluster ng ClickHouse, at pagkatapos ay sa Grafana.

Ano ang hirap sa pagsubaybay? Bakit ito ipinakita bilang isang uri ng tagumpay? Ang kahirapan ay nasa dynamics. Kapag mayroon kaming isang cluster at ito ay static, pagkatapos ay maaari naming i-set up ang pagsubaybay nang isang beses at hindi na mag-abala.

Ngunit kung mayroon tayong maraming mga kumpol, o isang bagay ay patuloy na nagbabago, kung gayon ang proseso ay pabago-bago. At ang patuloy na pagsasaayos ng pagsubaybay ay isang pag-aaksaya ng mga mapagkukunan at oras, i.e. kahit katamaran lang. Ito ay kailangang awtomatiko. Ang kahirapan ay nakasalalay sa dinamika ng proseso. At ang operator ay nag-automate nito nang napakahusay.

Paano nabuo ang aming cluster? Sa simula ay ganoon siya.

Tapos ganito siya.

Sa huli, naging ganito siya.

At ang pagsubaybay ay awtomatikong ginagawa ng operator. Isang punto ng pagpasok.

At sa labasan pa lang ay tumitingin kami sa dashboard ng Grafana upang makita kung paano kumukulo ang buhay ng aming kumpol sa loob.

Sa pamamagitan ng paraan, ang Grafana dashboard ay ipinamamahagi din sa aming operator nang direkta sa source code. Maaari kang kumonekta at gamitin. Ibinigay sa akin ng aming DevOps ang screenshot na ito.

Saan natin gustong pumunta? ito:

• Bumuo ng pag-automate ng pagsubok. Ang pangunahing gawain ay awtomatikong pagsubok ng mga bagong bersyon.
• Gusto rin naming i-automate ang pagsasama sa ZooKeeper. At may mga planong isama sa ZooKeeper-operator. Yung. Ang isang operator ay isinulat para sa ZooKeeper at ito ay lohikal na ang dalawang operator ay nagsimulang magsama upang bumuo ng isang mas maginhawang solusyon.
• Gusto naming gumawa ng mas kumplikadong vital signs.
• Na-highlight ko sa berde na papalapit na tayo sa pamana ng Mga Template - DONE, ibig sabihin, sa susunod na paglabas ng operator magkakaroon na tayo ng mana ng mga template. Ito ay isang makapangyarihang tool na nagbibigay-daan sa iyong bumuo ng mga kumplikadong configuration mula sa mga piraso.
• At gusto namin ang automation ng mga kumplikadong gawain. Ang pangunahing isa ay Re-sharding.

Kumuha tayo ng ilang intermediate na resulta.

Ano ang makukuha natin bilang resulta? At ito ba ay nagkakahalaga ng paggawa o hindi? Kailangan pa bang subukang i-drag ang database sa Kubernetes at gamitin ang operator sa pangkalahatan at ang Alitnity operator sa partikular?

Sa output nakukuha namin:

• Makabuluhang pagpapasimple at automation ng configuration, deployment, at maintenance.
• Agad na built-in na pagsubaybay.
• At mga naka-codified na template na handa nang gamitin para sa mga kumplikadong sitwasyon. Ang isang aksyon tulad ng pagdaragdag ng isang replika ay hindi kailangang gawin nang manu-mano. Ginagawa ito ng operator.

Isang huling tanong na lang ang natitira. Mayroon na tayong database sa Kubernetes, virtualization. Paano ang tungkol sa pagganap ng naturang solusyon, lalo na dahil ang ClickHouse ay na-optimize para sa pagganap?

Ang sagot ay lahat ay maayos! Hindi ko na idedetalye; ito ang paksa ng isang hiwalay na ulat.

Ngunit mayroong isang proyekto tulad ng TSBS. Ano ang pangunahing gawain nito? Ito ay isang pagsubok sa pagganap ng database. Ito ay isang pagtatangka na ihambing ang mainit sa mainit, malambot at malambot.

Paano siya nagtatrabaho? Isang set ng data ang nabuo. Pagkatapos ang hanay ng data na ito ay tatakbo sa iba't ibang database gamit ang parehong hanay ng mga pagsubok. At ang bawat database ay nalulutas ang isang problema sa paraang alam nito kung paano. At pagkatapos ay maaari mong ihambing ang mga resulta.

Sinusuportahan na nito ang isang malaking grupo ng mga database. Nakilala ko ang tatlong pangunahing mga. ito:

• TimescaleDB.
• InfluxDB.
• ClickHouse.

Ang isang paghahambing ay ginawa din sa isa pang katulad na solusyon. Paghahambing sa RedShift. Ang paghahambing ay ginawa sa Amazon. Nangunguna rin ang ClickHouse sa lahat sa bagay na ito.

Anong mga konklusyon ang maaaring makuha mula sa aking sinabi?

• Posible ang DB sa Kubernetes. Malamang na kahit ano ay posible, ngunit sa pangkalahatan ay mukhang posible ito. Ang ClickHouse sa Kubernetes ay tiyak na posible sa tulong ng aming operator.
• Tumutulong ang operator na i-automate ang mga proseso at talagang ginagawang mas madali ang buhay.
• Normal ang performance.
• At tila sa amin na ito ay maaari at dapat gamitin.

Open source - sumali sa amin!

Tulad ng nasabi ko na, ang operator ay isang ganap na open source na produkto, kaya't magiging napakabuti kung ang maximum na bilang ng mga tao ang gumamit nito. Sumali ka! Hinihintay namin kayong lahat!

Salamat sa lahat!

mga katanungan

Salamat sa ulat! Ang pangalan ko ay Anton. Ako ay mula sa SEMrush. Iniisip ko kung ano ang nangyayari sa pag-log. Naririnig namin ang tungkol sa pagsubaybay, ngunit wala tungkol sa pag-log, kung pag-uusapan natin ang tungkol sa buong kumpol. Halimbawa, nagtaas kami ng cluster sa hardware. At gumagamit kami ng sentralisadong pag-log, kinokolekta ang mga ito sa isang karaniwang bunton gamit ang karaniwang paraan. At mula doon ay nakukuha namin ang data na interesado sa amin.

Magandang tanong, ibig sabihin, pag-log in ng todo list. Hindi pa ito ino-automate ng aming operator. Ito ay umuunlad pa, ang proyekto ay medyo bata pa. Naiintindihan namin ang pangangailangan para sa pag-log. Ito rin ay isang napakahalagang paksa. At marahil ito ay hindi gaanong mahalaga kaysa sa pagsubaybay. Ngunit una sa listahan para sa pagpapatupad ay pagsubaybay. Magkakaroon ng logging. Naturally, sinusubukan naming i-automate ang lahat ng aspeto ng buhay ng cluster. Samakatuwid, ang sagot ay na sa sandaling ang operator, sa kasamaang-palad, ay hindi alam kung paano gawin ito, ngunit ito ay nasa mga plano, gagawin namin ito. Kung gusto mong sumali, pagkatapos ay hilahin ang kahilingan, mangyaring.

Kamusta! Salamat sa ulat! Mayroon akong karaniwang tanong na may kaugnayan sa Persistent Volumes. Kapag gumawa kami ng configuration sa operator na ito, paano tinutukoy ng operator kung aling node ang mayroon kaming partikular na disk o folder na naka-attach? Kailangan muna naming ipaliwanag sa kanya na mangyaring ilagay ang aming ClickHouse sa mga node na ito na may disk?

Sa pagkakaintindi ko, ang tanong na ito ay pagpapatuloy ng lokal na imbakan, lalo na ang bahagi ng hostPath nito. Ito ay tulad ng pagpapaliwanag sa buong system na ang pod ay kailangang ilunsad sa ganoon at ganoong node, kung saan mayroon kaming pisikal na konektadong disk na naka-mount sa ganoon at ganoong landas. This is a whole section that I touched on very superficially dahil medyo malaki ang sagot doon.

Sa madaling sabi, ganito ang hitsura. Natural, kailangan nating ibigay ang mga volume na ito. Sa ngayon, walang dynamic na probisyon sa lokal na imbakan, kaya dapat i-cut mismo ng DevOps ang mga disk, ang mga volume na ito. At dapat nilang ipaliwanag ang pagbibigay ng Kubernetes na magkakaroon ka ng Persistent volume ng ganito at ganoong klase, na matatagpuan sa ganito at ganoong mga node. Pagkatapos ay kakailanganin mong ipaliwanag sa Kubernetes na ang mga pod na nangangailangan ng ganito at ganoong lokal na klase ng imbakan ay kailangang iruta gamit ang mga label lamang sa ganoon at ganoong mga node. Para sa mga layuning ito, ang operator ay may kakayahang magtalaga ng ilang uri ng label at isa sa bawat host instance. At lumalabas na ang mga pod ay iruruta ng Kubernetes upang tumakbo lamang sa mga node na nakakatugon sa mga kinakailangan, mga label, sa mga simpleng termino. Manu-manong nagtatalaga ang mga administrator ng mga label at provision disk. At pagkatapos ay ito ay kaliskis.

At ito ang pangatlong opsyon, lokal, na tumutulong na gawing mas madali ito. Gaya ng binigyang-diin ko na, ito ay maingat na trabaho sa pag-tune, na sa huli ay nakakatulong upang makakuha ng pinakamataas na pagganap.

Mayroon akong pangalawang tanong na may kaugnayan dito. Ang Kubernetes ay idinisenyo sa paraang hindi mahalaga sa amin kung mawalan kami ng isang node o hindi. Ano ang dapat nating gawin sa kasong ito kung nawala natin ang node kung saan nakabitin ang ating shard?

Oo, ang Kubernetes ay unang nakaposisyon na ang aming relasyon sa aming mga pod ay parang baka, ngunit dito sa amin ang bawat disk ay nagiging parang alagang hayop. May ganoong problema na hindi natin basta-basta itatapon. At ang pag-unlad ng Kubernetes ay papunta sa direksyon na imposibleng ganap na gamutin ito nang pilosopiko, na parang ito ay isang ganap na itinapon na mapagkukunan.

Ngayon para sa isang praktikal na tanong. Ano ang gagawin kung nawala mo ang node kung saan ang disk? Dito nireresolba ang problema sa mas mataas na antas. Sa kaso ng ClickHouse, mayroon kaming mga replika na gumagana sa mas mataas na antas, i.e. sa antas ng ClickHouse.

Ano ang resultang disposisyon? Responsable ang DevOps sa pagtiyak na hindi mawawala ang data. Dapat niyang i-set up nang tama ang pagtitiklop at dapat tiyakin na tumatakbo ang pagtitiklop. Ang replica sa antas ng ClickHouse ay dapat na may duplicate na data. Hindi ito ang gawain na nalulutas ng operator. At hindi ang problema na nalulutas mismo ng Kubernetes. Ito ay nasa antas ng ClickHouse.

Ano ang gagawin kung bumagsak ang iyong bakal na node? At lumalabas na kakailanganin mong mag-install ng pangalawa, maayos na ibigay ang disc dito, at maglapat ng mga label. At pagkatapos nito, matutugunan nito ang mga kinakailangan na maaaring maglunsad ang Kubernetes ng isang instance pod dito. Ilulunsad ito ng Kubernetes. Ang iyong bilang ng mga pod ay hindi sapat upang matugunan ang tinukoy na numero. Dadaan ito sa cycle na ipinakita ko. At sa pinakamataas na antas, mauunawaan ng ClickHouse na nagpasok kami ng isang replika, ito ay walang laman at kailangan naming simulan ang paglilipat ng data dito. Yung. Ang prosesong ito ay hindi pa maayos na awtomatiko.

Salamat sa ulat! Kapag nangyari ang lahat ng uri ng masasamang bagay, nag-crash at nagre-restart ang operator, at sa sandaling iyon ay dumating ang mga kaganapan, pinangangasiwaan mo ba ito kahit papaano?

Ano ang mangyayari kung ang operator ay nag-crash at nag-restart, tama ba?

Oo. At sa sandaling iyon ay dumating ang mga pangyayari.

Ang gawain ng kung ano ang gagawin sa kasong ito ay bahagyang ibinabahagi sa pagitan ng operator at Kubernetes. May kakayahan ang Kubernetes na i-replay ang isang kaganapan na naganap. Nire-replay niya. At ang gawain ng operator ay tiyakin na kapag ang log ng kaganapan ay na-replay sa kanya, ang mga kaganapang ito ay idempotent. At upang ang paulit-ulit na paglitaw ng parehong kaganapan ay hindi masira ang aming sistema. At nakayanan ng aming operator ang gawaing ito.

Kamusta! Salamat sa ulat! Dmitry Zavyalov, kumpanya Smedova. May mga plano bang magdagdag ng kakayahang mag-configure gamit ang haproxy sa operator? Magiging interesado ako sa ilang iba pang balancer bukod sa karaniwang isa, upang ito ay matalino at nauunawaan na ang ClickHouse ay talagang naroroon.

Pinag-uusapan mo ba ang Ingress?

Oo, palitan ang Ingress ng haproxy. Sa haproxy maaari mong tukuyin ang topology ng cluster kung saan mayroon itong mga replika.

Hindi pa namin naiisip. Kung kailangan mo ito at maipaliwanag kung bakit ito kailangan, posible na ipatupad ito, lalo na kung gusto mong lumahok. Ikalulugod naming isaalang-alang ang opsyon. Ang maikling sagot ay hindi, sa kasalukuyan ay wala kaming ganoong pag-andar. Salamat sa tip, titingnan namin ang bagay na ito. At kung ipapaliwanag mo rin ang kaso ng paggamit at kung bakit ito kinakailangan sa pagsasanay, halimbawa, lumikha ng mga isyu sa GitHub, kung gayon magiging mahusay iyon.

Mayroon na.

ayos lang. Kami ay bukas sa anumang mga mungkahi. At ang haproxy ay idinagdag sa listahan ng todo. Ang listahan ng todo ay lumalaki, hindi pa lumiliit. Pero maganda ito, ibig sabihin in demand ang produkto.

Pinagmulan: www.habr.com