Ripoti hiyo imejitolea kwa masuala ya vitendo ya kuendeleza operator katika Kubernetes, kubuni usanifu wake na kanuni za msingi za uendeshaji.
Katika sehemu ya kwanza ya ripoti, tutazingatia:
- ni nini operator katika Kubernetes na kwa nini inahitajika;
- jinsi opereta hurahisisha usimamizi wa mifumo ngumu;
- nini operator anaweza na nini operator hawezi.
Ifuatayo, tunageuka kwenye mjadala wa muundo wa ndani wa operator. Fikiria usanifu na uendeshaji wa operator hatua kwa hatua. Hebu tuchambue kwa undani:
- mwingiliano kati ya operator na Kubernetes;
- Opereta huchukua kazi gani na ni wajumbe gani kwa Kubernetes.
Zingatia kudhibiti shards na nakala za hifadhidata katika Kubernetes.
Ifuatayo, tutajadili masuala ya kuhifadhi data:
- jinsi ya kufanya kazi na Hifadhi ya Kudumu kutoka kwa mtazamo wa waendeshaji;
- mitego ya kutumia Hifadhi ya Ndani.
Katika sehemu ya mwisho ya ripoti, tutazingatia mifano ya vitendo ya matumizi na Amazon au Google Cloud Service. Ripoti hiyo inategemea mfano wa maendeleo na uzoefu wa uendeshaji wa operator kwa ClickHouse.
Video:
Jina langu ni Vladislav Klimenko. Leo nilitaka kuzungumza juu ya uzoefu wetu katika kukuza na kuendesha opereta, na huyu ni mwendeshaji maalum wa kusimamia vikundi vya hifadhidata. Kwa mfano ili kudhibiti nguzo ya ClickHouse.
Kwa nini tunayo fursa ya kuzungumza juu ya operator na ClickHouse?
- Tunaunga mkono na kukuza ClickHouse.
- Kwa sasa, tunajaribu kutoa mchango wetu polepole katika maendeleo ya ClickHouse. Na sisi ni wa pili baada ya Yandex kwa suala la kiasi cha mabadiliko yaliyofanywa katika ClickHouse.
- Tunajaribu kutengeneza miradi ya ziada ya mfumo ikolojia wa ClickHouse.
Ningependa kuzungumzia mojawapo ya miradi hii. Hii ni kuhusu ClickHouse-operator kwa Kubernetes.
Katika ripoti yangu, ningependa kugusia mada mbili:
- Mada ya kwanza ni jinsi opereta wetu wa hifadhidata ya ClickHouse anavyofanya kazi katika Kubernetes.
- Mada ya pili ni jinsi mwendeshaji yeyote anafanya kazi, i.e. jinsi inavyoingiliana na Kubernetes.
Walakini, maswali haya mawili yataingiliana katika ripoti yangu yote.
Nani angependa kusikia ninachojaribu kusema?
- Kuvutia zaidi watakuwa wale wanaotumia waendeshaji.
- Au kwa wale wanaotaka kujitengenezea ili kuelewa jinsi inavyofanya kazi ndani, jinsi mwendeshaji anavyoingiliana na Kubernetes, na ni mitego gani inaweza kuonekana.
Ili kuelewa vyema zaidi kile tutachojadili leo, itakuwa vyema kujua jinsi Kubernetes inavyofanya kazi na kuwa na usuli wa kimsingi katika kompyuta ya wingu.
ClickHouse ni nini? Hii ni hifadhidata ya safu wima iliyo na maalum katika uchakataji mtandaoni wa maswali ya uchanganuzi. Na ni chanzo wazi kabisa.
Na tunahitaji kujua mambo mawili tu. Unahitaji kujua kuwa hii ni hifadhidata, kwa hivyo kile nitakuambia kitatumika kwa karibu hifadhidata yoyote. Na ukweli kwamba mizani ya ClickHouse DBMS vizuri sana inatoa scalability karibu linear. Na kwa hiyo, hali ya nguzo ni hali ya asili kwa ClickHouse. Na tunavutiwa zaidi kujadili jinsi ya kutumikia nguzo ya ClickHouse huko Kubernetes.
Kwa nini anahitajika huko? Kwa nini hatuwezi kuendelea kuiendesha sisi wenyewe? Na majibu ni sehemu ya kiufundi na kwa sehemu ya shirika.
- Katika mazoezi, mara nyingi zaidi na zaidi tunakutana na hali hiyo wakati katika makampuni makubwa karibu vipengele vyote tayari viko Kubernetes. Baki hifadhidata nje.
- Na mara nyingi zaidi na zaidi swali linaulizwa: "Je, inaweza kuwekwa ndani?". Kwa hiyo, makampuni makubwa yanajaribu kuzalisha umoja wa juu wa usimamizi ili kuwa na uwezo wa haraka wa kusimamia maghala yao ya data.
- Na hii inasaidia haswa ikiwa unahitaji nafasi ya juu ya kurudia kitu kile kile mahali mpya, ambayo ni, uwezo wa juu.
Je, ni rahisi au ngumu kiasi gani? Hii, bila shaka, inaweza kufanyika kwa mkono. Lakini hii si rahisi sana, kwa sababu tunaongeza ugumu wa kusimamia Kubernetes yenyewe, lakini wakati huo huo maalum ya ClickHouse imewekwa. Na inageuka kuwa mkusanyiko kama huo.
Na wote kwa pamoja, hii inatoa seti kubwa ya teknolojia, ambayo tayari inakuwa ngumu kudhibiti, kwa sababu Kubernetes huleta masuala yake ya kila siku kufanya kazi, na ClickHouse huleta masuala yake kwa uendeshaji wa kila siku. Hasa ikiwa tuna ClickHouses kadhaa, na tunahitaji daima kufanya kitu nao.
ClickHouse iliyo na usanidi unaobadilika ina idadi kubwa ya maswala ambayo huunda mzigo wa mara kwa mara kwenye DevOps:
- Tunapotaka kubadilisha kitu katika ClickHouse, kwa mfano, ongeza replica, shard, basi tunahitaji kusimamia usanidi.
- Kisha ubadilishe mpango wa data, kwa sababu ClickHouse ina njia maalum ya kugawa. Huko ni muhimu kuweka mpango wa data, kuweka mipangilio.
- Unahitaji kusanidi ufuatiliaji.
- Mkusanyiko wa kumbukumbu za shards mpya, kwa nakala mpya.
- Jihadharini na kupona.
- Na uanze upya.
Hizi ni kazi za kawaida ambazo ningependa sana kuwezesha katika utendaji.
Kubernetes yenyewe husaidia sana katika uendeshaji, lakini kwa mambo ya msingi ya mfumo.
Kubernetes ni mzuri katika kuwezesha na kuendesha vitu kiotomatiki kama vile:
- Kupona.
- Anzisha tena.
- Usimamizi wa hifadhi.
Hiyo ni nzuri, huo ni mwelekeo sahihi, lakini hajawasiliana kabisa na jinsi ya kuendesha kikundi cha hifadhidata.
Ninataka zaidi, ninataka hifadhidata nzima itufanyie kazi katika Kubernetes.
Ningependa kupata kitu kama kitufe kikubwa chekundu ambacho unabofya na utakuwa na kikundi kilichowekwa na kudumishwa katika kipindi chote cha maisha na kazi za kila siku zinazohitaji kutatuliwa. Kundi la ClickHouse huko Kubernetes.
Na tulijaribu kufanya suluhisho ambalo litasaidia kurahisisha kazi. Hii ni kiendeshaji cha ClickHouse cha Kubernetes kutoka Altinity.
Opereta ni programu ambayo kazi yake kuu ni kusimamia programu zingine, ambayo ni, ni meneja.
Na ina mifumo ya tabia. Unaweza kuiita maarifa yaliyoratibiwa kuhusu eneo la somo.
Na kazi yake kuu ni kurahisisha maisha kwa DevOps na kupunguza usimamizi mdogo ili yeye (DevOps) tayari anafikiria kwa hali ya juu, ambayo ni, ili yeye (DevOps) asisimamie kidogo, ili asisanidi mwenyewe kwa mikono. maelezo.
Na mwendeshaji tu ndiye msaidizi wa roboti ambaye anajitahidi na microtasks na husaidia DevOps.
Kwa nini operator inahitajika? Anafanya vyema katika maeneo mawili:
- Wakati mtaalam wa ClickHouse hana uzoefu wa kutosha, lakini tayari ni muhimu kufanya kazi kwa ClickHouse, opereta kuwezesha operesheni na hukuruhusu kuendesha nguzo ya ClickHouse na usanidi ngumu zaidi, huku usiingie kwa undani zaidi juu ya jinsi yote inavyofanya kazi ndani. . Unampa tu kazi za hali ya juu, na inafanya kazi.
- Na kazi ya pili ambayo inajionyesha vizuri zaidi ni wakati ni muhimu kugeuza idadi kubwa ya kazi za kawaida. Huondoa majukumu madogo kutoka kwa sysadmins.
Hii inahitajika zaidi ama na wale ambao wanaanza safari yao, au kwa wale wanaohitaji kufanya otomatiki nyingi.
Kuna tofauti gani kati ya mbinu inayotegemea opereta na mifumo mingine? Kuna pia Helm. Pia husaidia kusakinisha ClickHouse, unaweza kuchora chati za usukani, ambazo zitasakinisha hata nguzo nzima ya ClickHouse. Ni nini basi tofauti kati ya operator na kutoka sawa, kwa mfano, Helm?
Tofauti kuu ya kimsingi ni kwamba Helm inahusu usimamizi wa kifurushi, na mwendeshaji huenda hatua zaidi. Huu ni msaada wa mzunguko mzima wa maisha. Huu sio usakinishaji tu, haya ni kazi za kila siku ambazo ni pamoja na kuongeza, kugawanyika, i.e. kila kitu kinachohitajika kufanywa wakati wa mzunguko wa maisha (ikiwa ni lazima, kuondolewa pia) - hii yote imeamuliwa na mwendeshaji. Inajaribu kubinafsisha na kutumikia mzunguko mzima wa maisha ya programu. Hii ndio tofauti yake ya kimsingi kutoka kwa suluhisho zingine zinazowasilishwa.
Hiyo ilikuwa sehemu ya utangulizi, tuendelee.
Je, tunajengaje mwendeshaji wetu? Tunajaribu kushughulikia suala hili ili kudhibiti nguzo ya ClickHouse kama nyenzo moja.
Hapa tunayo data ya pembejeo upande wa kushoto wa picha. Hii ni YAML iliyo na vipimo vya nguzo, ambayo kimsingi hupitishwa kupitia kubectl hadi Kubernetes. Huko, mwendeshaji wetu anaichukua, hufanya uchawi wake. Na matokeo yake, tunapata mpango kama huo. Huu ni utekelezaji wa ClickHouse huko Kubernetes.
Na kisha tutaangalia polepole jinsi operator anavyofanya kazi, ni kazi gani za kawaida zinaweza kutatuliwa. Tutazingatia kazi za kawaida tu, kwa sababu tuna muda mdogo. Na haitaambiwa juu ya kila kitu ambacho operator anaweza kuamua.
Wacha tuanze kutoka kwa mazoezi. Mradi wetu ni chanzo wazi kabisa, kwa hivyo unaweza kuona jinsi inavyofanya kazi kwenye GitHub. Na unaweza kuendelea kutoka kwa mazingatio, ikiwa unataka tu kuanza, basi unaweza kuanza na Mwongozo wa Kuanza Haraka.
Ikiwa unataka kuelewa kwa undani, basi tunajaribu kudumisha nyaraka kwa fomu zaidi au chini ya heshima.
Wacha tuanze na shida ya vitendo. Kazi ya kwanza ambayo sote tunataka kuanza nayo ni kutekeleza mfano wa kwanza kwa njia fulani. Jinsi ya kuzindua ClickHouse kwa msaada wa operator, bila hata kujua jinsi inavyofanya kazi? Tunaandika ilani, kwa sababu mawasiliano yote na k8s ni mawasiliano kupitia maonyesho.
Hii hapa ilani tata kama hii. Kile ambacho tumeangazia kwa rangi nyekundu ndicho tunachohitaji kuzingatia. Tunaomba opereta kuunda kundi linaloitwa onyesho.
Kwa sasa, hii ni mifano ya msingi. Hifadhi bado haijaelezewa, lakini tutarudi kwenye hifadhi baadaye kidogo. Kwa sasa, tutaona maendeleo ya nguzo katika mienendo.
Tumeunda ilani hii. Tunalisha kwa operator wetu. Alifanya kazi, alifanya uchawi.
Tunaangalia console. Vipengele vitatu ni vya kupendeza - hivi ni Pod, Service-a mbili, StatefulSet.
Opereta amefanya kazi, na tunaweza kuona ni nini hasa alichounda.
Anaunda kitu kama hiki. Tuna StatefulSet, Pod, ConfigMap kwa kila nakala, ConfigMap kwa nguzo nzima. Huduma za lazima kama sehemu za kuingilia kwenye nguzo.
Huduma ni Huduma kuu ya Mizani ya Mizigo na inawezekana kwa kila nakala, kwa kila shard.
Hapa kuna nguzo yetu ya msingi inaonekana kama hii. Yeye ni kutoka nodi moja.
Wacha tuende zaidi, tutachanganya. Unahitaji kugawanya nguzo.
Kazi zetu zinakua, mienendo inaanza. Tunataka kuongeza kipande. Tunafuata maendeleo. Tunabadilisha vipimo vyetu. Tunaonyesha kwamba tunataka vipande viwili.
Hii ni faili sawa ambayo sisi kuendeleza dynamically na ukuaji wa mfumo. Hakuna uhifadhi, uhifadhi utajadiliwa zaidi, hili ni suala tofauti.
Tunalisha opereta ya YAML na kuona kitakachotokea.
Opereta alifikiria na kutengeneza vyombo vifuatavyo. Tayari tuna Podi mbili, Huduma tatu na, ghafla, 2 StatefulSets. Kwa nini 2 StatefulSets?
Ilikuwa kama hii kwenye mchoro - hii ni hali yetu ya awali, wakati tulikuwa na ganda moja.
Ikawa hivi. Hadi sasa, kila kitu ni rahisi, imekuwa duplicated.
Na kwa nini StatefulSet ikawa mbili? Hapa tunahitaji kujiondoa na kujadili swali la jinsi Pods zinasimamiwa katika Kubernetes.
Kuna kitu kama hicho kinachoitwa StatefulSet, ambacho hukuruhusu kutengeneza seti ya Pods kutoka kwa kiolezo. Jambo kuu hapa ni Kiolezo. Na unaweza kuendesha Pods nyingi katika StatefulSet moja kulingana na kiolezo kimoja. Na maneno muhimu hapa ni "template moja Pods nyingi".
Na kulikuwa na jaribu kubwa la kutengeneza nguzo nzima, kuipakia kwenye StatefulSet moja. Itafanya kazi, hakuna shida ndani yake. Lakini kuna tahadhari moja. Ikiwa tunataka kukusanya nguzo tofauti, i.e. kutoka kwa matoleo kadhaa ya ClickHouse, basi maswali yetu huanza. Ndiyo, StatefulSet inaweza kusasisha, lakini hapo unaweza kutoa toleo jipya, eleza kwamba unahitaji kujaribu si zaidi ya nodi nyingi kwa wakati mmoja.
Lakini ikiwa tutaongeza kazi hiyo na kusema kwamba tunataka kutengeneza nguzo isiyo ya kawaida kabisa na hatutaki kubadilisha kutoka toleo la zamani hadi jipya kwa kutumia sasisho la kusonga, lakini tunataka tu kuunda nguzo tofauti kwa suala la matoleo tofauti. ya ClickHouse na kwa suala la uhifadhi tofauti. Tunataka, kwa mfano, kutengeneza nakala zingine kwenye diski tofauti, kwa polepole, kwa ujumla, kujenga nguzo nyingi tofauti. Na kwa sababu ya ukweli kwamba StatefulSet hufanya suluhisho sanifu kutoka kwa kiolezo kimoja, kwa hivyo hakuna njia ya kufanya hivi.
Baada ya kufikiria kidogo, iliamuliwa tufanye hivi. Tuna kila nakala katika StatefulSet yake. Kuna baadhi ya vikwazo kwa ufumbuzi huu, lakini katika mazoezi ni wote kabisa encapsulates operator. Na kuna faida nyingi. Tunaweza kujenga nguzo kama vile tunataka, kwa mfano, moja tofauti kabisa. Kwa hivyo, katika kundi ambalo tuna shards mbili zilizo na nakala moja, tutakuwa na StatefulSets 2 na Pods 2 kwa usahihi kwa sababu tulichagua mbinu hii kutokana na sababu zilizo hapo juu za uwezo wa kuunda nguzo tofauti.
Wacha turudi kwenye kazi za vitendo. Katika kikundi chetu, tunahitaji kusanidi watumiaji, i.e. unahitaji kufanya usanidi fulani wa ClickHouse huko Kubernetes. Opereta hutoa uwezekano wote kwa hili.
Tunaweza kuandika tunachotaka moja kwa moja katika YAML. Chaguzi zote za usanidi zimechorwa moja kwa moja kutoka kwa YAML hii hadi kwa usanidi wa ClickHouse, ambao huwekwa kwenye nguzo nzima.
Unaweza pia kuandika kama hii. Hii ni kwa mfano. Nenosiri linaweza kusimbwa. Chaguo zote za usanidi wa ClickHouse zinatumika. Hapa kuna mfano tu.
Usanidi wa nguzo unasambazwa kama ConfigMap. Kwa mazoezi, sasisho la ConfigMap halifanyiki mara moja, kwa hivyo ikiwa kuna nguzo kubwa, basi mchakato wa kusukuma usanidi huchukua muda. Lakini hii yote ni rahisi sana kutumia.
Tunachanganya kazi. Nguzo hiyo inaendelea. Tunataka kunakili data. Hiyo ni, tayari tuna shards mbili, replica moja kila, watumiaji wameundwa. Tunakua na tunataka kuiga.
Tunahitaji nini kwa kurudia?
Tunahitaji ZooKeeper. Katika ClickHouse, urudufishaji hujengwa kwa kutumia ZooKeeper. ZooKeeper inahitajika ili nakala tofauti za ClickHouse ziwe na makubaliano ambayo vizuizi vya data viko kwenye ClickHouse.
ZooKeeper inaweza kutumika na mtu yeyote. Ikiwa biashara ina ZooKeeper ya nje, basi inaweza kutumika. Ikiwa sivyo, basi unaweza kusanikisha kutoka kwa hazina yetu. Kuna kisakinishi ambacho hurahisisha jambo hili lote.
Na mpango wa mwingiliano wa mfumo mzima unageuka kama hii. Tuna Kubernetes kama jukwaa. Inatekeleza opereta ya ClickHouse. ZooKeeper niliyempiga picha hapa. Na mwendeshaji huingiliana na ClickHouse na ZooKeeper. Hiyo ni, mwingiliano hupatikana.
Na hii yote ni muhimu kwa ClickHouse kuiga data kwa k8s.
Hebu sasa tuangalie kazi yenyewe, jinsi onyesho la urudufishaji litakavyoonekana.
Tunaongeza sehemu mbili kwenye dhihirisho letu. Ya kwanza ni mahali pa kupata ZooKeeper, ambayo inaweza kuwa ndani ya Kubernetes au nje. Haya ni maelezo tu. Na tunaagiza nakala. Wale. tunataka replicas mbili. Kwa jumla, tunapaswa kuwa na maganda 4 kwenye pato. Tunakumbuka juu ya uhifadhi, itarudi kidogo zaidi. Hifadhi ni wimbo tofauti.
Ilikuwa hivi.
Inakuwa hivi. Nakala zinaongezwa. Ya 4 haikufaa, tunaamini kwamba kunaweza kuwa na wengi wao. Na ZooKeeper imeongezwa kwa upande. Miundo inazidi kuwa ngumu.
Na ni wakati wa kuongeza kazi inayofuata. Tutaongeza Hifadhi ya Kudumu.
Kwa Hifadhi ya Kudumu, tuna chaguo mbalimbali.
Ikiwa tunaendesha katika mtoa huduma wa wingu, kwa mfano, kwa kutumia Amazon, Google, basi kuna jaribu kubwa la kutumia hifadhi ya wingu. Inafaa sana, ni nzuri.
Na kuna chaguo la pili. Hii ni kwa hifadhi ya ndani, wakati tuna diski za ndani kwenye kila nodi. Chaguo hili ni ngumu zaidi kutekeleza, lakini wakati huo huo lina tija zaidi.
Wacha tuone kile tulicho nacho kuhusu uhifadhi wa wingu.
Kuna sifa. Ni rahisi sana kusanidi. Tunaagiza tu kutoka kwa mtoa huduma wa wingu ambaye tafadhali atupe hifadhi ya uwezo kama huo na wa aina hiyo. Madarasa yamechorwa na watoa huduma kwa kujitegemea.
Na kuna drawback. Kwa wengine, hii ni kasoro isiyo muhimu. Bila shaka, kutakuwa na nyongeza za utendaji. Ni rahisi sana kutumia, ya kuaminika, lakini kuna mapungufu kadhaa katika utendaji.
Na tangu ClickHouse inazingatia utendaji, unaweza hata kusema kwamba inapunguza kila kitu kinachowezekana, kwa hivyo wateja wengi hujaribu kufinya utendaji wa juu.
Na ili kunufaika zaidi nayo, tunahitaji hifadhi ya ndani.
Kubernetes hutoa vifupisho vitatu vya kutumia hifadhi ya ndani katika Kubernetes. Hii:
- EmptyDir
- HostPath.
- Mitaa
Fikiria jinsi wanavyotofautiana, jinsi wanavyofanana.
Kwanza, katika njia zote tatu, tuna uhifadhi - hizi ni diski za ndani ambazo ziko kwenye nodi sawa ya k8s. Lakini wana tofauti fulani.
Wacha tuanze na rahisi zaidi, i.e. emptyDir. Ni nini katika mazoezi? Ni sisi ambao tunauliza mfumo wa uwekaji vyombo (mara nyingi Docker) kutoka kwa vipimo vyetu ili kutupa ufikiaji wa folda kwenye diski ya ndani.
Kwa mazoezi, docker huunda folda ya muda mahali fulani katika njia zake mwenyewe, huiita hashi ndefu. Na hutoa kiolesura cha kuipata.
Je, itafanyaje katika suala la utendaji? Hii itaendesha kwa kasi ya disk ya ndani, i.e. huu ni ufikiaji kamili wa skrubu yako.
Lakini kesi hii ina drawback yake. Kuendelea katika kesi hii ni badala ya shaka. Katika harakati ya kwanza ya docker na vyombo, Kudumu hupotea. Ikiwa Kubernetes inataka kuhamisha Pod hii kwa diski nyingine kwa sababu fulani, basi data itapotea.
Njia hii ni nzuri kwa vipimo, kwa sababu tayari inaonyesha kasi ya kawaida, lakini chaguo hili haifai kwa kitu kikubwa.
Kwa hiyo, kuna njia ya pili. Hii ni hostPath. Ukiangalia slaidi iliyotangulia na hii, unaweza kuona tofauti moja tu. Folda yetu iliacha docker moja kwa moja kwenye nodi ya Kubernetes. Ni kasi kidogo hapa. Tunaandika moja kwa moja njia kwenye mfumo wa faili wa ndani ambapo tungependa kuhifadhi data zetu.
Njia hii ina faida. Hii tayari ni ya Kudumu, na ya kawaida. Kwenye diski yetu, data itaandikwa kwa anwani fulani.
Pia kuna hasara. Huu ndio utata wa usimamizi. Kubernetes wetu wanaweza kutaka kuhamisha Pod hadi nodi nyingine halisi. Hapa ndipo DevOps inapoanza kutumika. Ni lazima ielezee kwa usahihi mfumo mzima kwamba unaweza tu kuhamisha maganda haya kwenye nodi hizo ambazo una kitu kilichowekwa kwenye njia hizi, na si zaidi ya nodi moja kwa wakati mmoja. Ni vigumu kutosha.
Hasa kwa madhumuni haya, tumetengeneza templates katika operator wetu ili kuficha utata huu wote. Na unaweza kusema tu: "Nataka kuwa na mfano mmoja wa ClickHouse kwa nodi ya kimwili na kando ya njia kama hiyo."
Lakini hitaji hili sio kwa ajili yetu tu, hivyo waungwana kutoka Kubernetes yenyewe pia wanaelewa kwamba watu wanataka kupata disks za kimwili, hivyo hutoa ngazi ya tatu.
Inaitwa mtaa. Kwa kweli hakuna tofauti kutoka kwa slaidi iliyopita. Mapema tu ilikuwa ni lazima kutekeleza kwa mkono kwamba hatuwezi kuhamisha maganda haya kutoka kwa nodi hadi nodi, kwa sababu lazima ziunganishwe kando ya njia hiyo na vile kwenye diski ya kimwili ya ndani, na sasa ujuzi huu wote umeingizwa katika Kubernetes yenyewe. Na inageuka kuwa rahisi zaidi kusanidi.
Wacha turudi kwenye kazi yetu ya vitendo. Hebu turudi kwenye kiolezo cha YAML. Hapa tuna hifadhi halisi. Tumerudi kwenye hili. Tunaweka kiolezo cha kawaida cha VolumeClaim kama katika k8s. Na tunaelezea ni aina gani ya hifadhi tunayotaka.
Baada ya hapo, k8s itaomba hifadhi. Igawe kwetu katika StatefulSet. Na mwishowe, itatokea kwa ClickHouse.
Tulikuwa na mpango kama huo. Hifadhi Yetu ya Kudumu ilikuwa nyekundu, ambayo ilionekana kudokeza kwamba inapaswa kufanywa.
Na inageuka kijani. Sasa ClickHouse kwenye mpango wa nguzo ya k8s imekamilika kikamilifu. Tuna shards, replicas, ZooKeeper, tuna Persistent halisi, ambayo inatekelezwa kwa njia moja au nyingine. Mpango huo tayari unafanya kazi kikamilifu.
Tunaendelea kuishi. Nguzo yetu inakua. Na Aleksey anajaribu na kutoa toleo jipya la ClickHouse.
Kazi ya vitendo inatokea - kujaribu toleo jipya la ClickHouse kwenye nguzo yetu. Na, bila shaka, sitaki kuifungua yote, nataka kuweka toleo jipya mahali fulani kwenye kona ya mbali katika replica moja, au labda sio toleo jipya, lakini mbili mara moja, kwa sababu hutoka mara nyingi.
Tunaweza kusema nini kuhusu hili?
Hapa tunayo fursa kama hiyo. Hizi ni violezo vya pod. Unaweza kuchora, mwendeshaji wetu hukuruhusu kabisa kujenga nguzo tofauti. Wale. sanidi, kuanzia nakala zote kwenye rundo, na kuishia na kila nakala ya kibinafsi, ni toleo gani tunataka ClickHouse, toleo gani tunataka kuhifadhi. Tunaweza kusanidi nguzo kikamilifu katika usanidi kama tunahitaji.
Hebu tuingie ndani zaidi kidogo. Kabla ya hapo, tulizungumzia jinsi ClickHouse-operator inavyofanya kazi kuhusiana na maalum ya ClickHouse.
Sasa ningependa kusema maneno machache kuhusu jinsi operator yeyote anavyofanya kazi kwa ujumla, pamoja na jinsi inavyoingiliana na K8s.
Fikiria mwingiliano na K8 kwa kuanzia. Nini kinatokea tunapofanya kubectl kuomba? Kupitia API, vitu vyetu vinaonekana katika etcd.
Kwa mfano, vitu vya msingi vya Kubernetes: pod, StatefulSet, huduma, na kadhalika kupitia orodha.
Walakini, hakuna kitu cha kimwili kinachotokea bado. Vitu hivi lazima viwekwe katika nguzo.
Hapa ndipo mtawala huingia. Kidhibiti ni sehemu maalum ya k8 inayoweza kutekeleza maelezo haya. Anajua jinsi na nini cha kufanya kimwili. Anajua jinsi ya kuendesha vyombo, ni nini kinachohitaji kusanidiwa hapo ili seva ifanye kazi.
Na inabadilisha vitu vyetu katika K8s.
Lakini tunataka kufanya kazi sio tu na maganda, StatefulSets, tunataka kuunda ClickHouseInstallation, yaani, kitu cha aina ya ClickHouse, ili kufanya kazi nayo kwa ujumla. Hadi sasa, hakuna uwezekano huo.
Lakini K8s ina jambo lingine nzuri. Tunataka tuwe na huluki changamano kama hii mahali fulani, ambamo nguzo yetu ingekusanywa kutoka kwa maganda na StatefulSet.
Na nini kifanyike kwa hili? Kwanza, Ufafanuzi wa Rasilimali Maalum huingia kwenye tukio. Ni nini? Haya ni maelezo ya K8s kwamba utakuwa na aina nyingine ya data ambayo tunataka kuongeza kwenye pod, StatefulSet, rasilimali maalum ambayo itakuwa ngumu ndani. Haya ni maelezo ya muundo wa data.
Pia tunatuma huko kupitia kubectl apply. Kubernetes aliipokea kwa furaha.
Na sasa katika uhifadhi wetu, kitu katika etcd kina fursa ya kuandika rasilimali maalum inayoitwa ClickHouseInstallation.
Lakini kwa sasa, hakuna kitu kingine kitakachotokea. Hiyo ni, ikiwa sasa tutaunda faili ya YAML ambayo tulizingatia kwa maelezo ya shard, replicas na kusema "kubectl apply", basi Kubernetes ataikubali, kuiweka etcd na kusema: "Nzuri, lakini sijui. nini cha kufanya nayo. Sijui jinsi ya kudumisha Usakinishaji wa ClickHouse."
Kwa hivyo, tunahitaji mtu wa kusaidia Kubernetes kuhudumia aina mpya ya data. Upande wa kushoto, tuna kidhibiti cha hisa cha Kubernetes kinachofanya kazi na aina za data ya hisa. Na upande wa kulia, tunapaswa kuwa na kidhibiti maalum ambacho kinaweza kufanya kazi na aina maalum za data.
Na kwa njia nyingine inaitwa operator. Niliitoa hapa kwa Kubernetes, kwa sababu inaweza pia kutekelezwa nje ya K8s. Mara nyingi, kwa kweli, taarifa zote zinatekelezwa katika Kubernetes, lakini hakuna kinachozuia kusimama nje, kwa hivyo hapa hutolewa haswa.
Na tayari, kwa upande wake, kidhibiti maalum, pia kinachojulikana kama mwendeshaji, huingiliana na Kubernetes kupitia API. Tayari anajua jinsi ya kuingiliana na API. Na tayari anajua jinsi ya kuunda mpango tata ambao tunataka kutengeneza kutoka kwa rasilimali maalum. Hivi ndivyo opereta hufanya.
Opereta hufanyaje kazi? Hebu tuangalie upande wa kulia tuone jinsi anavyofanya. Tutajua jinsi opereta anavyofanya haya yote na jinsi mwingiliano zaidi na K8 unafanyika.
Opereta ni programu. Ana mwelekeo wa tukio. Opereta hujisajili kwa matukio kwa kutumia Kubernetes API. API ya Kubernetes ina sehemu za kuingilia ambapo unaweza kujiandikisha kwa matukio. Na ikiwa kitu kinabadilika katika K8s, basi Kubernetes hutuma matukio kwa kila mtu, i.e. waliojiandikisha kwenye sehemu hii ya API watapokea arifa.
Opereta anajiandikisha kwa matukio, na lazima afanye aina fulani ya majibu. Kazi yake ni kujibu matukio yanayojitokeza.
Matukio yanatolewa na baadhi ya masasisho. Faili yetu ya YAML inafika ikiwa na maelezo ya ClickHouseInstallation. Alienda etcd kupitia kubectl apply. Tukio lilifanya kazi huko, kwa sababu hiyo, tukio hili lilikuja kwa ClickHouse-operator. Opereta alipokea maelezo haya. Na lazima afanye kitu. Ikiwa sasisho lilikuja kwa kitu cha ClickHouseInstallation, basi unahitaji kusasisha nguzo. Na kazi ya mwendeshaji ni kusasisha nguzo.
Anafanya nini? Kwanza, tunahitaji kuandaa mpango wa utekelezaji wa kile tutakachofanya na sasisho hili. Sasisho zinaweza kuwa ndogo sana, yaani. ndogo katika utekelezaji wa YAML, lakini inaweza kusababisha mabadiliko makubwa sana kwenye nguzo. Kwa hiyo, operator huunda mpango, na kisha anazingatia.
Anaanza, kulingana na mpango huu, kuchemsha muundo huu ndani ili kutengeneza maganda, huduma, i.e. kufanya kazi yake kuu ni nini. Ni kama kujenga nguzo ya ClickHouse huko Kubernetes.
Sasa hebu tuguse jambo la kuvutia kama hilo. Huu ni mgawanyiko wa wajibu kati ya Kubernetes na operator, i.e. Kubernetes hufanya nini, mwendeshaji hufanya nini, na jinsi wanavyoingiliana.
Kubernetes ni wajibu wa mambo ya mfumo, i.e. kwa seti ya msingi ya vitu ambavyo vinaweza kufasiriwa kama wigo wa mfumo. Kubernetes anajua jinsi ya kuanza maganda, jinsi ya kuanzisha upya vyombo, jinsi ya kufanya kiasi cha mlima, jinsi ya kufanya kazi na ConfigMap, i.e. chochote kinachoweza kuitwa mfumo.
Waendeshaji hufanya kazi katika maeneo ya somo. Kila operator hufanywa kwa eneo lake la somo. Tulitengeneza kwa ClickHouse.
Na opereta huingiliana kwa usahihi kulingana na eneo la somo, kama vile kuongeza nakala, kutengeneza mpango, kuweka ufuatiliaji. Kuna mgawanyiko kama huo.
Hebu tuangalie mfano wa vitendo wa jinsi utengano huu wa wasiwasi hutokea tunapofanya kitendo cha kuongeza nakala.
Kazi inakuja kwa operator - kuongeza replica. Opereta anafanya nini? Opereta atahesabu kuwa ni muhimu kutengeneza StatefulSet mpya, ambayo ni muhimu kuelezea vile na vile violezo, madai ya kiasi.
Aliitayarisha yote na kuipitisha kwa K8s. Anasema kwamba anahitaji ConfigMap, StatefulSet, Volume. Kubernetes anafanya kazi. Anafanya vitengo vya msingi ambavyo anafanya kazi.
Na kisha ClickHouse-operator inakuja kucheza tena. Tayari ana ganda la kimwili ambalo unaweza tayari kufanya kitu. Na ClickHouse-operator tena inafanya kazi kwa suala la eneo la somo. Wale. Hasa, ClickHouse, ili kujumuisha nakala kwenye nguzo, lazima, kwanza, usanidi mpango wa data uliopo kwenye nguzo hii. Na, pili, maoni haya lazima yajumuishwe katika ufuatiliaji ili iweze kufuatiliwa wazi. Opereta tayari ameiweka.
Na tu baada ya hiyo ClickHouse yenyewe inakuja kucheza, i.e. chombo kingine cha juu. Tayari ni hifadhidata. Ina mfano wake mwenyewe, replica inayofuata iliyosanidiwa, ambayo iko tayari kujiunga na nguzo.
Inageuka mlolongo wa utekelezaji na mgawanyo wa uwajibikaji wakati kuongeza nakala ni ya kutosha.
Tunaendelea na kazi zetu za vitendo. Ikiwa nguzo tayari ipo, basi unaweza kuhamisha usanidi.
Tuliifanya ili iwezekanavyo kupita kwenye xml iliyopo, ambayo ClickHouse inaelewa.
Unaweza kurekebisha ClickHouse vizuri. Usambazaji wa kanda tu ndio nilizungumza wakati wa kuelezea hostPath, uhifadhi wa ndani. Hivi ndivyo jinsi ya kufanya uwekaji wa kanda kwa usahihi.
Kazi inayofuata ya vitendo ni ufuatiliaji.
Ikiwa nguzo yetu itabadilika, basi tunahitaji kusanidi ufuatiliaji mara kwa mara.
Hebu tuangalie mchoro. Tayari tumezingatia mishale ya kijani hapa. Sasa hebu tuangalie mishale nyekundu. Hivi ndivyo tunavyotaka kufuatilia nguzo yetu. Jinsi metriki kutoka kwa nguzo ya ClickHouse huingia kwenye Prometheus, na kisha hadi Grafana.
Je, ufuatiliaji una tatizo gani? Kwa nini hii inaonyeshwa kama aina fulani ya mafanikio? Ugumu upo katika mienendo. Tunapokuwa na nguzo moja na imetulia, basi unaweza kuweka ufuatiliaji mara moja na usijisumbue tena.
Lakini ikiwa tuna makundi mengi, au kitu kinabadilika mara kwa mara, basi mchakato ni wa nguvu. Na ufuatiliaji mara kwa mara ni kupoteza rasilimali na wakati; hata mvivu tu. Hii inahitaji kujiendesha. Ugumu ni katika mienendo ya mchakato. Na mwendeshaji anaendesha hii vizuri sana.
Nguzo yetu ilikuaje? Hapo mwanzo alikuwa hivi.
Kisha akawa hivi.
Mwishowe, akawa hivi.
Na ufuatiliaji unafanywa moja kwa moja na operator. Sehemu moja ya kuingia.
Na tunaangalia tu njia ya kutoka kwenye dashibodi ya Grafana, jinsi maisha ya kikundi chetu yanavyoendelea ndani.
Kwa njia, dashibodi ya Grafana pia inasambazwa na opereta wetu moja kwa moja kwenye msimbo wa chanzo. Unaweza kuunganisha na kutumia. Picha hii ya skrini nilipewa na DevOps yetu.
Je, tungependa kwenda wapi tena? Hii:
- Tengeneza otomatiki ya jaribio. Kazi kuu ni majaribio ya kiotomatiki ya matoleo mapya.
- Pia tunataka kugeuza ujumuishaji kiotomatiki na ZooKeeper. Na mipango ya kuunganishwa na ZooKeeper-operator. Wale. opereta imeandikwa kwa ZooKeeper, na ni busara kwamba waendeshaji wawili wanaanza kuunganishwa ili kujenga suluhisho rahisi zaidi.
- Tunataka kufanya ukaguzi changamano zaidi wa maisha.
- Niliangazia kwa kijani kibichi kuwa tunayo urithi wa Violezo njiani - NIMEMALIZA, yaani, baada ya toleo lijalo la mwendeshaji, tayari tutakuwa na urithi wa violezo. Hii ni zana yenye nguvu ambayo hukuruhusu kuunda usanidi ngumu kutoka kwa vipande.
- Na tunataka kufanya kazi ngumu kiotomatiki. Jambo kuu ni kushiriki tena.
Wacha tufanye matokeo ya kati.
Je, tunapata nini kama matokeo? Na ni thamani yake au la? Je! ninahitaji hata kujaribu kuburuta hifadhidata kwenye Kubernetes na kuomba opereta kwa ujumla na mwendeshaji wa Alitnity haswa.
Kwenye pato tunapata:
- Rahisisha sana na ubadilishe usanidi, uwekaji na matengenezo otomatiki.
- Ufuatiliaji uliojengwa mara moja.
- Na violezo vilivyoratibiwa vilivyo tayari kutumia kwa hali ngumu. Tayari hatua ya aina ya kuongeza replica haihitaji kufanywa kwa mkono. Hii inafanywa na operator.
Swali la mwisho pekee linabaki. Tayari tuna hifadhidata katika Kubernetes, uboreshaji. Vipi kuhusu utendaji wa suluhisho kama hilo, haswa kwani ClickHouse imeboreshwa kwa utendaji?
Jibu ni kwamba kila kitu kiko sawa! Sitaelezea kwa undani, hii ni mada ya ripoti tofauti.
Lakini kuna mradi kama TSBS. Kazi yake kuu ni nini? Huu ni mtihani wa utendaji wa hifadhidata. Hili ni jaribio la kulinganisha joto na joto, laini na laini.
Anafanyaje kazi? Seti moja ya data inazalishwa. Kisha data hii iliyowekwa kwenye seti sawa ya jaribio inaendeshwa kwenye hifadhidata tofauti. Na kila hifadhidata inasuluhisha shida moja jinsi inavyoweza. Na kisha unaweza kulinganisha matokeo.
Tayari inasaidia rundo kubwa la hifadhidata. Nimebainisha tatu kuu. Hii:
- timescaledb.
- InfluxDB.
- clickhouse.
Ulinganisho pia ulifanywa na suluhisho lingine kama hilo. Kulinganisha na RedShift. Ulinganisho ulifanywa kwenye Amazon. ClickHouse pia iko mbele ya kila mtu katika suala hili.
Ni hitimisho gani linaweza kutolewa kutokana na nilichosema?
- DB katika Kubernetes inawezekana. Pengine, unaweza kufanya chochote, lakini kwa ujumla inaonekana kuwa unaweza. ClickHouse katika Kubernetes ni dhahiri inawezekana kwa msaada wa operator wetu.
- Opereta husaidia kubinafsisha michakato na hurahisisha maisha.
- Utendaji ni wa kawaida.
- Na, inaonekana kwetu kwamba inaweza na inapaswa kutumika.
Chanzo wazi - jiunge nasi!
Kama nilivyosema, opereta ni bidhaa ya chanzo wazi kabisa, kwa hivyo itakuwa nzuri sana ikiwa idadi ya juu ya watu itaitumia. Jiunge sasa! Tunakungoja nyote!
Asante kwa wote!
maswali
Asante kwa ripoti! Jina langu ni Anton. Ninatoka SEMrush. Ninajiuliza kuna nini na ukataji miti. Tunasikia juu ya ufuatiliaji, lakini hakuna chochote juu ya ukataji miti, ikiwa tunazungumza juu ya nguzo nzima. Kwa mfano, tuna nguzo kwenye vifaa. Na tunatumia ukataji miti wa kati, tunaikusanya katika lundo la kawaida kwa njia za kawaida. Na kisha kutoka huko tunapata data ambayo inatuvutia.
Swali zuri, i.e. kuingia kwenye orodha ya todo. Opereta wetu hafanyi hii kiotomatiki bado. Bado inaendelea, mradi bado ni mchanga. Tunaelewa hitaji la ukataji miti. Hii pia ni mada muhimu sana. Na labda sio muhimu zaidi kuliko ufuatiliaji. Lakini kwanza kwenye orodha ya utekelezaji ilikuwa ufuatiliaji. Kutakuwa na ukataji miti. Kwa kawaida, tunajaribu kurekebisha vipengele vyote vya maisha ya nguzo. Kwa hiyo, jibu ni kwamba kwa sasa operator, kwa bahati mbaya, hajui jinsi ya kufanya hivyo, lakini ni katika mipango, tutafanya hivyo. Ikiwa unataka kujiunga, basi vuta ombi, tafadhali.
Habari! Asante kwa ripoti! Nina swali la kawaida linalohusiana na Kiasi cha Kudumu. Tunapounda usanidi na opereta huyu, mwendeshaji huamuaje ni nodi gani tunayo diski au folda fulani? Lazima kwanza tumweleze kwamba, tafadhali, weka ClickHouse yetu haswa kwenye nodi hizi ambazo zina diski?
Kwa kadiri ninavyoelewa, swali hili ni mwendelezo wa uhifadhi wa ndani, haswa sehemu yake ya hostPath. Ni kama kuelezea mfumo mzima kwamba ni muhimu kwa ganda kuzinduliwa haswa kwenye nodi kama hiyo na vile, ambayo tunayo diski iliyounganishwa ya mwili, ambayo imewekwa kwenye njia kama hiyo na kama hiyo. Hii ni sehemu nzima ambayo niliigusa juu juu sana, kwa sababu jibu hapo ni kubwa kabisa.
Kwa kifupi, inaonekana kama hii. Bila shaka, tunahitaji kufanya utoaji wa juzuu hizi. Kwa sasa, hakuna utoaji wa nguvu katika uhifadhi wa ndani, kwa hivyo DevOps lazima ikate diski zenyewe, hapa kuna viwango hivi. Na lazima waeleze utoaji wa Kubernetes, kwamba utakuwa na kiasi cha Kudumu cha darasa kama hilo na kama hilo, ambalo liko kwenye nodi kama hizo. Kisha itakuwa muhimu kuelezea Kubernetes kwamba maganda ambayo yanahitaji vile na vile darasa la hifadhi ya ndani yanahitajika kupangwa kulingana na maandiko tu kwa vile na vile vile. Kwa madhumuni haya, opereta ana uwezo wa kukabidhi aina fulani ya lebo na moja kwa kila tukio la mwenyeji. Na inageuka kuwa maganda yataelekezwa na Kubernetes kukimbia tu kwenye nodes zinazokidhi mahitaji, maandiko, kwa maneno rahisi. Wasimamizi wanapeana lebo, fanya utoaji wa diski kwa mkono. Na kisha mizani.
Na chaguo la tatu tu la ndani husaidia kuifanya iwe rahisi kidogo. Kama nilivyosisitiza tayari, hii ni kazi ya uchungu ya kurekebisha, ambayo mwishowe husaidia kupata utendaji wa hali ya juu.
Nina swali la pili kuhusiana na hili. Kubernetes iliundwa kwa njia ambayo haijalishi kwetu ikiwa tunapoteza nodi au la. Tunapaswa kufanya nini katika kesi hii ikiwa tumepoteza node ambapo tuna shard?
Ndio, Kubernetes hapo awali iliwekwa kuwa uhusiano wetu na maganda yetu ni kama ng'ombe, lakini hapa kila diski inakuwa kitu kama kipenzi. Kuna shida ambayo hatuwezi kuitupa tu. Na maendeleo ya Kubernetes yanaenda katika mwelekeo ambao hauwezekani kutibu kabisa kifalsafa, kama rasilimali iliyotupwa kabisa.
Sasa swali la vitendo. Nini cha kufanya ikiwa umepoteza node ambayo diski ilikuwa? Hapa tatizo linatatuliwa kwa kiwango cha juu. Katika kesi ya ClickHouse, tuna replicas kwamba kazi katika ngazi ya juu, i.e. kwa kiwango cha ClickHouse.
Je, ni tabia gani? DevOps inawajibika kuhakikisha kuwa data haipotei. Ni lazima itengeneze urudufu na lazima ihakikishe kuwa urudufishaji unaendelea. Katika replica katika ngazi ya ClickHouse, data lazima irudiwe. Hii sio kazi ambayo operator hutatua. Na sio kazi ambayo Kubernetes yenyewe hutatua. Hii ni katika kiwango cha ClickHouse.
Nini cha kufanya ikiwa nodi yako ya chuma imeanguka? Na inageuka kuwa itakuwa muhimu kuweka pili, kusonga vizuri disk juu yake, kutumia maandiko. Na baada ya hapo, itakidhi mahitaji ambayo Kubernetes juu yake inaweza kuendesha mfano wa ganda. Kubernetes itazindua. Idadi yako ya maganda haitoshi kwa iliyoainishwa. Itapitia mzunguko ambao nilionyesha. Na kwa kiwango cha juu, ClickHouse itaelewa kuwa tuna replica iliyoingizwa, bado haina tupu na tunahitaji kuanza kuhamisha data kwake. Wale. mchakato huu bado ni wa kiotomatiki duni.
Asante kwa ripoti! Kila aina ya mambo maovu yanapotokea, opereta huanguka na kuwasha tena, na wakati huo matukio yanafika, je, unachakata hili kwa namna fulani?
Ni nini hufanyika ikiwa opereta ataanguka na kuwasha tena, ndio?
Ndiyo. Na wakati huo matukio yalikuja.
Kazi ya nini cha kufanya katika kesi hii imegawanywa kwa sehemu kati ya operator na Kubernetes. Kubernetes ina uwezo wa kucheza tena tukio ambalo limetokea. Anacheza tena. Na kazi ya opereta ni kuhakikisha kuwa wakati logi ya tukio ilichezwa tena juu yake, matukio haya hayana nguvu. Na ili kutokea tena kwa tukio lile lile kusivunje mfumo wetu kwetu. Na mwendeshaji wetu anashughulikia kazi hii.
Habari! Asante kwa ripoti! Dmitry Zavialov, kampuni Smedov. Imepangwa kuongeza chaguzi za ubinafsishaji na haproxy kwa mwendeshaji? Usawazishaji mwingine unavutia kando na ile ya kawaida, kwa hivyo ni nzuri na inaelewa kuwa ClickHouse ni halisi hapo.
Unazungumzia Ingress?
Ndio, badilisha Ingress na haproxy. Katika haproksi, unaweza kubainisha topolojia ya nguzo ambapo ina nakala.
Kufikia sasa, hatujafikiria juu yake. Ikiwa unahitaji na unaweza kueleza kwa nini inahitajika, basi itawezekana kutekeleza, hasa ikiwa unataka kushiriki. Tutafurahi kuzingatia chaguo. Jibu fupi ni hapana, kwa sasa hatuna utendakazi huo. Asante kwa kidokezo, tutaangalia hili. Na ikiwa pia unaelezea kesi ya matumizi na kwa nini ni muhimu katika mazoezi, kwa mfano, kuunda masuala kwenye GitHub, basi itakuwa nzuri.
Tayari.
Sawa. Tuko wazi kwa mapendekezo yoyote. Na haproxy imewekwa kwenye orodha ya todo. Orodha ya todo inakua, haijapungua bado. Lakini hii ni nzuri, ina maana kwamba bidhaa ni katika mahitaji.
Chanzo: mapenzi.com