Ziņojums ir veltīts praktiskiem jautājumiem par operatora attīstību Kubernetes, tā arhitektūras projektēšanu un darbības pamatprincipiem.
Pārskata pirmajā daļā mēs apsvērsim:
- kas ir operators Kubernetes un kāpēc tas ir vajadzīgs;
- kā tieši operators vienkāršo sarežģītu sistēmu pārvaldību;
- ko operators var un ko nevar darīt.
Tālāk pāriesim pie operatora iekšējās struktūras apspriešanas. Apskatīsim operatora arhitektūru un darbību soli pa solim. Apskatīsim to sīkāk:
- mijiedarbība starp operatoru un Kubernetes;
- kādas funkcijas operators uzņemas un kādas funkcijas tas deleģē Kubernetes.
Apskatīsim šķembu un datu bāzes kopiju pārvaldību programmā Kubernetes.
Tālāk mēs apspriedīsim datu uzglabāšanas problēmas:
- kā strādāt ar Persistent Storage no operatora viedokļa;
- Vietējās krātuves izmantošanas nepilnības.
Ziņojuma beigu daļā aplūkosim praktiskus pielietojuma piemērus ar Amazon vai Google Cloud Service. Ziņojuma pamatā ir ClickHouse operatora attīstības un darbības pieredzes piemērs.
Video:
Mani sauc Vladislavs Kļimenko. Šodien es gribēju runāt par mūsu pieredzi operatora izstrādē un darbībā, un šis ir specializēts operators datu bāzu klasteru pārvaldīšanai. Piemēram lai pārvaldītu ClickHouse klasteru.
Kāpēc mums ir iespēja runāt par operatoru un ClickHouse?
- Mēs atbalstām un attīstām ClickHouse.
- Šobrīd mēs cenšamies lēnām dot savu ieguldījumu ClickHouse attīstībā. Un mēs esam otrie pēc Yandex ClickHouse veikto izmaiņu apjoma ziņā.
- Mēs cenšamies veikt papildu projektus ClickHouse ekosistēmai.
Es vēlētos jums pastāstīt par vienu no šiem projektiem. Tas ir par ClickHouse operatoru Kubernetes.
Savā ziņojumā es vēlētos pieskarties divām tēmām:
- Pirmā tēma ir par to, kā mūsu ClickHouse datu bāzes pārvaldības operators darbojas Kubernetes.
- Otra tēma ir par to, kā darbojas jebkurš operators, t.i., kā tas mijiedarbojas ar Kubernetes.
Tomēr šie divi jautājumi krustosies visā manā ziņojumā.
Kuram gan būtu interesanti klausīties, ko es cenšos pastāstīt?
- Visvairāk tas interesēs tos, kas apkalpo operatorus.
- Vai arī tiem, kas vēlas izveidot savu, lai saprastu, kā tas darbojas iekšēji, kā operators mijiedarbojas ar Kubernetes un kādas nepilnības var parādīties.
Lai vislabāk saprastu, ko mēs šodien apspriedīsim, ir ieteicams zināt, kā darbojas Kubernetes, un veikt dažus pamata mākoņdatošanas apmācību.
Kas ir ClickHouse? Šī ir kolonnu datubāze ar īpašām funkcijām analītisko vaicājumu tiešsaistes apstrādei. Un tas ir pilnībā atvērts avots.
Un mums ir svarīgi zināt tikai divas lietas. Jums jāzina, ka šī ir datu bāze, tāpēc tas, ko es jums pateikšu, būs piemērojams gandrīz jebkurai datu bāzei. Un tas, ka ClickHouse DBVS ir ļoti labi mērogojams, nodrošina gandrīz lineāru mērogojamību. Tāpēc klastera stāvoklis ir ClickHouse dabisks stāvoklis. Un mēs esam visvairāk ieinteresēti apspriest, kā apkalpot ClickHouse klasteru Kubernetes.
Kāpēc viņš tur vajadzīgs? Kāpēc mēs paši nevarētu turpināt to ekspluatēt? Un atbildes ir daļēji tehniskas un daļēji organizatoriskas.
- Praksē arvien biežāk sastopamies ar situāciju, ka lielajos uzņēmumos gandrīz visas sastāvdaļas jau ir Kubernetes. Datu bāzes paliek ārpusē.
- Un arvien biežāk tiek uzdots jautājums: "Vai to var ievietot iekšā?" Tāpēc lielie uzņēmumi cenšas panākt maksimālu vadības unifikāciju, lai ātri varētu pārvaldīt savas datu noliktavas.
- Un tas ir īpaši noderīgi, ja jums ir nepieciešama maksimāla iespēja atkārtot to pašu jaunā vietā, t.i., maksimāla pārnesamība.
Cik viegli vai grūti tas ir? To, protams, var izdarīt ar rokām. Bet tas nav tik vienkārši, jo mums ir papildu sarežģītība paša Kubernetes pārvaldībā, taču tajā pašā laikā ClickHouse specifika tiek uzklāta. Un rodas šāds apkopojums.
Un tas viss kopā dod diezgan lielu tehnoloģiju kopumu, kas kļūst diezgan grūti pārvaldāms, jo Kubernetes savā darbībā ienes savas ikdienas problēmas, bet ClickHouse – savas ikdienas darbībās. It īpaši, ja mums ir vairākas ClickHouse, un mums pastāvīgi ar tiem kaut kas jādara.
Ar dinamisku konfigurāciju ClickHouse ir diezgan daudz problēmu, kas rada pastāvīgu DevOps slodzi:
- Ja mēs vēlamies kaut ko mainīt pakalpojumā ClickHouse, piemēram, pievienot kopiju vai fragmentu, mums ir jāpārvalda konfigurācija.
- Pēc tam mainiet datu shēmu, jo ClickHouse ir īpaša sadalīšanas metode. Tur jāizkārto datu diagramma, jāizkārto konfigurācijas.
- Jums ir jāiestata uzraudzība.
- Žurnālu vākšana jaunām lauskas, jaunām replikām.
- Rūpēties par atjaunošanu.
- Un restartējiet.
Tie ir rutīnas uzdevumi, kurus es ļoti vēlētos atvieglot.
Pats Kubernetes labi palīdz darbībā, bet uz pamata sistēmas lietām.
Kubernetes labi atvieglo un automatizē tādas lietas kā:
- Atgūšana.
- Restartēt.
- Uzglabāšanas sistēmas vadība.
Tas ir labi, tas ir pareizais virziens, taču viņam nav pilnīgas izpratnes par datu bāzes klastera darbību.
Mēs vēlamies vairāk, mēs vēlamies, lai visa datubāze darbotos Kubernetes.
Es vēlētos iegūt kaut ko līdzīgu lielai sarkanai burvju pogai, kuru nospiežat, un kopu ar ikdienas uzdevumiem, kas jāatrisina, tiek izvietots un uzturēts visā tā dzīves ciklā. ClickHouse klasteris Kubernetes.
Un mēs centāmies radīt risinājumu, kas palīdzētu atvieglot darbu. Šis ir ClickHouse operators Kubernetes no Altinity.
Operators ir programma, kuras galvenais uzdevums ir pārvaldīt citas programmas, t.i., tas ir vadītājs.
Un tas satur uzvedības modeļus. Jūs varat to saukt par kodificētām zināšanām par priekšmetu.
Un viņa galvenais uzdevums ir atvieglot DevOps dzīvi un samazināt mikropārvaldību, lai viņš (DevOps) jau domā augstā līmenī, t.i., lai viņš (DevOps) nenodarbojas ar mikropārvaldību, lai viņš nekonfigurē. visas detaļas manuāli.
Un tikai operators ir robotu palīgs, kas nodarbojas ar mikrouzdevumiem un palīdz DevOps.
Kāpēc jums ir nepieciešams operators? Viņš īpaši labi darbojas divās jomās:
- Kad speciālistam, kurš nodarbojas ar ClickHouse, nav pietiekamas pieredzes, bet jau ir jādarbojas ClickHouse, operators atvieglo darbību un ļauj vadīt ClickHouse klasteru ar diezgan sarežģītu konfigurāciju, pārāk neiedziļinoties, kā tas viss darbojas. iekšā. Jūs vienkārši dodat viņam augsta līmeņa uzdevumus, un tas darbojas.
- Un otrs uzdevums, kurā tas darbojas vislabāk, ir tad, kad ir nepieciešams automatizēt lielu skaitu tipisku uzdevumu. Noņem sistēmas administratoru mikrouzdevumus.
Tas ir visvairāk nepieciešams vai nu tiem, kuri tikai sāk savu ceļojumu, vai tiem, kam jāveic liela automatizācija.
Kā uz operatoru balstītā pieeja atšķiras no citām sistēmām? Ir Helma. Tas palīdz arī instalēt ClickHouse; varat zīmēt stūres diagrammas, kas pat instalēs visu ClickHouse klasteru. Kāda tad ir atšķirība starp operatoru un to pašu, piemēram, Helmu?
Galvenā būtiskā atšķirība ir tā, ka Helm ir pakotņu pārvaldība, un operators iet soli tālāk. Tas ir atbalsts visam dzīves ciklam. Šī nav tikai instalēšana, tie ir ikdienas darbi, kas ietver mērogošanu, sadalīšanu, t.i., visu, kas ir jādara dzīves cikla laikā (ja nepieciešams, tad arī dzēšanu) - to visu izlemj operators. Tas mēģina automatizēt un uzturēt visu programmatūras dzīves ciklu. Tā ir tā būtiskā atšķirība no citiem piedāvātajiem risinājumiem.
Tā bija ievaddaļa, ejam tālāk.
Kā mēs veidojam savu operatoru? Mēs cenšamies risināt problēmu, lai pārvaldītu ClickHouse klasteru kā vienu resursu.
Šeit mums ir ievades dati attēla kreisajā pusē. Šī ir YAML ar klastera specifikāciju, kas tiek nodota Kubernetes klasiskā veidā, izmantojot kubectl. Tur mūsu operators to paņem un dara savu maģiju. Un izejā mēs iegūstam šādu shēmu. Šī ir ClickHouse ieviešana Kubernetes.
Un tad lēnām skatīsimies, kā tieši operators strādā, kādus tipiskus uzdevumus var atrisināt. Mēs apsvērsim tikai tipiskus uzdevumus, jo mums ir ierobežots laiks. Un ne viss, ko operators var izlemt, tiks apspriests.
Sāksim no prakses. Mūsu projekts ir pilnībā atvērts avots, tāpēc jūs varat redzēt, kā tas darbojas vietnē GitHub. Un jūs varat turpināt apsvērumus, ka, ja vēlaties to vienkārši palaist, varat sākt ar īso lietošanas pamācību.
Ja vēlaties saprast sīkāk, tad cenšamies uzturēt dokumentāciju vairāk vai mazāk pieklājīgā formā.
Sāksim ar praktisku problēmu. Pirmais uzdevums, ar kuru mēs visi vēlamies sākt, ir kaut kā palaist pirmo piemēru. Kā es varu palaist ClickHouse, izmantojot operatoru, pat ja es īsti nezinu, kā tas darbojas? Rakstām manifestu, jo... Visa komunikācija ar k8s ir komunikācija caur manifestiem.
Tas ir tik sarežģīts manifests. Tas, ko esam iezīmējuši sarkanā krāsā, ir tas, uz ko mums jākoncentrējas. Mēs lūdzam operatoru izveidot klasteru ar nosaukumu demonstrācija.
Šie šobrīd ir pamata piemēri. Uzglabāšana vēl nav aprakstīta, bet mēs atgriezīsimies pie uzglabāšanas nedaudz vēlāk. Pagaidām vērosim klastera attīstības dinamiku.
Mēs izveidojām šo manifestu. Mēs to padodam savam operatoram. Viņš strādāja, radīja maģiju.
Mēs skatāmies uz konsoli. Interesanti ir trīs komponenti: Pod, divi pakalpojumi un StatefulSet.
Operators ir strādājis, un mēs varam redzēt, ko tieši viņš radīja.
Viņš rada kaut ko līdzīgu šim. Mums ir StatefulSet, Pod, ConfigMap katrai replikai un ConfigMap visam klasterim. Pakalpojumi ir nepieciešami kā ieejas punkti klasterī.
Pakalpojumi ir centrālais Load Balancer pakalpojums, un tos var izmantot arī katrai kopijai, katrai shardam.
Mūsu pamata klasteris izskatās apmēram šādi. Tas ir no viena mezgla.
Ejam tālāk un sarežģīsim lietas. Mums ir jāsadala klasteris.
Mūsu uzdevumi aug, sākas dinamika. Mēs vēlamies pievienot šķembu. Mēs sekojam attīstībai. Mēs mainām savu specifikāciju. Mēs norādām, ka vēlamies divas lauskas.
Šis ir tas pats fails, kas dinamiski attīstās līdz ar sistēmas izaugsmi. Uzglabāšana nē, par glabāšanu tiks runāts tālāk, šī ir atsevišķa tēma.
Mēs pabarojam YAML operatoru un skatāmies, kas notiek.
Operators domāja un izveidoja šādas entītijas. Mums jau ir divi podi, trīs pakalpojumi un pēkšņi 2 StatefulSets. Kāpēc 2 StatefulSets?
Diagrammā tas bija šādi - tāds ir mūsu sākotnējais stāvoklis, kad mums bija viens pods.
Tas kļuva šāds. Līdz šim viss ir vienkārši, tas ir dublēts.
Un kāpēc radās divi StatefulSets? Šeit mums ir jāatkāpjas un jāapspriež jautājums par to, kā Pods tiek pārvaldīts Kubernetes.
Ir objekts ar nosaukumu StatefulSet, kas ļauj izveidot Pods komplektu no veidnes. Galvenais faktors šeit ir veidne. Un jūs varat palaist daudzus Pods, izmantojot vienu veidni vienā StatefulSet. Un galvenā frāze šeit ir “daudzi podi vienai veidnei”.
Un bija liels kārdinājums izveidot visu kopu, iesaiņojot to vienā StatefulSet. Tas darbosies, ar to nav nekādu problēmu. Bet ir viens brīdinājums. Ja mēs vēlamies apkopot neviendabīgu klasteru, tas ir, no vairākām ClickHouse versijām, tad sāk rasties jautājumi. Jā, StatefulSet var veikt slīdošo atjauninājumu, un tur jūs varat izlaist jaunu versiju, paskaidrojot, ka jums ir jāizmēģina ne vairāk kā tik daudz mezglu vienlaikus.
Bet, ja mēs ekstrapolējam uzdevumu un sakām, ka mēs vēlamies izveidot pilnīgi neviendabīgu klasteri un mēs nevēlamies pāriet no vecās versijas uz jaunu, izmantojot slīdošo atjauninājumu, bet mēs vienkārši vēlamies izveidot neviendabīgu klasteru abos terminos. dažādu ClickHouse versiju un dažādu krātuves ziņā. Mēs vēlamies, piemēram, izveidot dažas kopijas uz atsevišķiem diskiem, uz lēniem, vispār, lai pilnībā izveidotu neviendabīgu klasteru. Un tā kā StatefulSet izveido standartizētu risinājumu no vienas veidnes, to nevar izdarīt.
Nedaudz pārdomājot, tika nolemts, ka mēs to darīsim šādi. Katrai kopijai ir sava StatefulSet. Šim risinājumam ir daži trūkumi, taču praksē to visu pilnībā iekapsulē operators. Un ir daudz priekšrocību. Mēs varam izveidot tieši tādu kopu, kādu vēlamies, piemēram, absolūti neviendabīgu. Tāpēc klasterī, kurā mums ir divas shards ar vienu kopiju, mums būs 2 StatefulSets un 2 Pods tieši tāpēc, ka mēs izvēlējāmies šo pieeju iepriekš minēto iemeslu dēļ, lai varētu izveidot neviendabīgu klasteri.
Atgriezīsimies pie praktiskām problēmām. Mūsu klasterī mums ir jākonfigurē lietotāji, t.i. jums ir jāveic kāda ClickHouse konfigurācija Kubernetes. Operators tam nodrošina visas iespējas.
Mēs varam rakstīt to, ko vēlamies tieši YAML. Visas konfigurācijas opcijas tiek kartētas tieši no šī YAML ClickHouse konfigurācijās, kuras pēc tam tiek izplatītas visā klasterī.
Jūs varat to uzrakstīt šādi. Tas ir piemēram. Paroli var šifrēt. Pilnīgi visas ClickHouse konfigurācijas opcijas tiek atbalstītas. Šeit ir tikai piemērs.
Klastera konfigurācija tiek izplatīta kā ConfigMap. Praksē ConfigMap atjauninājums nenotiek uzreiz, tāpēc, ja klasteris ir liels, konfigurācijas nosūtīšanas process aizņem kādu laiku. Bet tas viss ir ļoti ērti lietojams.
Sarežģīsim uzdevumu. Klasteris attīstās. Mēs vēlamies replicēt datus. Tas ir, mums jau ir divas shards, katra viena kopija, un lietotāji ir konfigurēti. Mēs augam un vēlamies veikt replikāciju.
Kas mums vajadzīgs replikācijai?
Mums ir nepieciešams ZooKeeper. Programmā ClickHouse replikācija tiek veidota, izmantojot ZooKeeper. ZooKeeper ir nepieciešams, lai dažādām ClickHouse replikām būtu vienprātība par to, kuri datu bloki atrodas uz kuriem ClickHouse.
ZooKeeper var izmantot ikviens. Ja uzņēmumam ir ārējs ZooKeeper, tad to var izmantot. Ja nē, varat to instalēt no mūsu krātuves. Ir instalētājs, kas šo visu padara vienkāršāku.
Un visas sistēmas mijiedarbības diagramma izrādās šāda. Mums ir Kubernetes kā platforma. Tas izpilda ClickHouse operatoru. Es bildēju ZooKeeper šeit. Un operators mijiedarbojas gan ar ClickHouse, gan ar ZooKeeper. Tas ir, mijiedarbības rezultāti.
Un tas viss ir nepieciešams, lai ClickHouse veiksmīgi replicētu datus k8s.
Tagad apskatīsim pašu uzdevumu, kā izskatīsies replikācijas manifests.
Mēs savam manifestam pievienojam divas sadaļas. Pirmais ir tas, kur iegūt ZooKeeper, kas var būt gan Kubernetes iekšienē, gan ārpusē. Šis ir tikai apraksts. Un mēs pasūtām kopijas. Tie. mēs vēlamies divas kopijas. Kopumā mums vajadzētu būt 4 pākstīm pie izejas. Mēs atceramies par uzglabāšanu, tas atgriezīsies nedaudz vēlāk. Uzglabāšana ir atsevišķs stāsts.
Tas bija šādi.
Tas kļūst šāds. Tiek pievienotas kopijas. 4.nederēja, ticam, ka tur varētu būt daudz. Un blakus ir pievienots ZooKeeper. Shēmas kļūst sarežģītākas.
Un ir pienācis laiks pievienot nākamo uzdevumu. Mēs pievienosim pastāvīgo krātuvi.
Pastāvīgai glabāšanai mums ir dažādas iespējas.
Ja darbojamies mākoņpakalpojumā, piemēram, izmantojot Amazon, Google, tad ir liels kārdinājums izmantot mākoņkrātuvi. Tas ir ļoti ērti, tas ir labi.
Un ir otrs variants. Tas ir paredzēts vietējai krātuvei, kad katrā mezglā ir vietējie diski. Šo iespēju ir daudz grūtāk īstenot, bet tajā pašā laikā tā ir produktīvāka.
Apskatīsim, kas mums ir attiecībā uz mākoņkrātuvi.
Ir priekšrocības. To ir ļoti viegli konfigurēt. Mēs vienkārši pasūtām no mākoņa pakalpojumu sniedzēja, lūdzu, iedodiet mums tādas un tādas ietilpības, tādas un tādas klases krātuvi. Nodarbības pakalpojumu sniedzēji plāno neatkarīgi.
Un ir trūkums. Dažiem tas ir nenozīmīgs trūkums. Protams, būs dažas darbības problēmas. Tas ir ļoti ērti lietojams un uzticams, taču ir daži iespējamie veiktspējas trūkumi.
Un tāpēc ClickHouse koncentrējas tieši uz produktivitāti, varētu pat teikt, ka tas izspiež visu, ko var, tāpēc daudzi klienti cenšas izspiest maksimālu produktivitāti.
Un, lai no tā gūtu maksimālu labumu, mums ir nepieciešama vietējā krātuve.
Kubernetes nodrošina trīs abstrakcijas vietējās krātuves izmantošanai Kubernetes. Šis:
- EmptyDir
- HostPath.
- Uz vietas
Apskatīsim, kā tie atšķiras un kā tie ir līdzīgi.
Pirmkārt, visās trīs pieejās mums ir krātuve - tie ir lokālie diski, kas atrodas tajā pašā fiziskajā k8s mezglā. Bet viņiem ir dažas atšķirības.
Sāksim ar vienkāršāko, t.i., tukšuDir. Kas tas ir praksē? Mūsu specifikācijā mēs lūdzam konteinerizācijas sistēmu (visbiežāk Docker) nodrošināt mums piekļuvi mapei vietējā diskā.
Praksē Docker izveido pagaidu mapi kaut kur pa saviem ceļiem un sauc to par garu hash. Un nodrošina saskarni, lai tai piekļūtu.
Kā tas darbosies snieguma ziņā? Tas darbosies vietējā diska ātrumā, t.i. Šī ir pilnīga piekļuve jūsu skrūvei.
Bet šim gadījumam ir savs trūkums. Persistents šajā jautājumā ir diezgan apšaubāms. Pirmo reizi Docker pārvietojoties ar konteineriem, Persistent tiek zaudēts. Ja Kubernetes kādu iemeslu dēļ vēlas pārvietot šo Pod uz citu disku, dati tiks zaudēti.
Šī pieeja ir laba testiem, jo tā jau rāda normālu ātrumu, bet kaut kam nopietnam šī opcija nav piemērota.
Tāpēc ir otra pieeja. Šis ir hostPath. Ja paskatās uz iepriekšējo un šo slaidu, jūs varat redzēt tikai vienu atšķirību. Mūsu mape tika pārvietota no Docker tieši uz Kubernetes mezglu. Šeit ir nedaudz vienkāršāk. Mēs tieši norādām ceļu lokālajā failu sistēmā, kur vēlamies glabāt savus datus.
Šai metodei ir priekšrocības. Šis jau ir īsts Persistents, turklāt klasisks. Dati mums būs ierakstīti diskā kādā adresē.
Ir arī trūkumi. Tā ir vadības sarežģītība. Mūsu Kubernetes var vēlēties pārvietot Pod uz citu fizisku mezglu. Un šeit tiek izmantots DevOps. Viņam ir pareizi jāpaskaidro visai sistēmai, ka šos mezglus var pārvietot tikai uz tiem mezgliem, uz kuriem jums ir kaut kas uzstādīts pa šiem ceļiem, un ne vairāk kā vienu mezglu vienlaikus. Tas ir diezgan grūti.
Īpaši šiem nolūkiem mēs savā operatorā izveidojām veidnes, lai paslēptu visu šo sarežģītību. Un jūs varētu vienkārši pateikt: "Es vēlos, lai katram fiziskajam mezglam būtu viens ClickHouse gadījums un pa šādu un tādu ceļu."
Taču šī vajadzība nav mums vienīgajiem, tāpēc arī paši Kubernetes kungi saprot, ka cilvēki vēlas piekļūt fiziskajiem diskiem, tāpēc nodrošina trešo slāni.
To sauc par vietējo. Praktiski nav nekādas atšķirības no iepriekšējā slaida. Tikai iepriekš bija manuāli jāapliecina, ka šos podiņus nevaram pārnest no mezgla uz mezglu, jo tie ir jāpievieno pa kādu ceļu uz lokālo fizisko disku, bet tagad visas šīs zināšanas ir iekapsulētas pašā Kubernetes. Un izrādās, ka to ir daudz vieglāk konfigurēt.
Atgriezīsimies pie mūsu praktiskās problēmas. Atgriezīsimies pie YAML veidnes. Šeit mums ir īsta krātuve. Mēs esam atpakaļ pie tā. Mēs iestatījām klasisko VolumeClaim veidni tāpat kā k8s. Un mēs aprakstām, kāda veida krātuvi mēs vēlamies.
Pēc tam k8s pieprasīs krātuvi. Piešķirs to mums StatefulSet. Un galu galā tas nonāks ClickHouse rīcībā.
Mums bija šāda shēma. Mūsu pastāvīgā krātuve bija sarkanā krāsā, kas, šķiet, norādīja, ka tas ir jādara.
Un tas kļūst zaļš. Tagad ClickHouse uz k8s klastera shēma ir pilnībā pabeigta. Mums ir shards, replikas, ZooKeeper, mums ir īsts Persistents, kas tiek realizēts tā vai citādi. Shēma jau pilnībā darbojas.
Mēs turpinām dzīvot tālāk. Mūsu klasteris attīstās. Un Aleksejs mēģina un izlaiž jaunu ClickHouse versiju.
Rodas praktisks uzdevums - pārbaudīt ClickHouse jauno versiju mūsu klasterī. Un, protams, jūs nevēlaties to visu izlaist; jūs vēlaties ievietot jaunu versiju vienā replikā kaut kur tālākajā stūrī un varbūt nevis vienu jaunu versiju, bet divas uzreiz, jo tās iznāk bieži.
Ko mēs varam teikt par šo?
Šeit mums ir tieši tāda iespēja. Šīs ir pod veidnes. Varat rakstīt, ka mūsu operators pilnībā ļauj izveidot neviendabīgu klasteru. Tie. konfigurēt, sākot no visām kopijām kopā, beidzot ar katru personīgo repliku, kuru ClickHouse versiju mēs vēlamies, kuru versiju mēs vēlamies saglabāt. Mēs varam pilnībā konfigurēt klasteru ar mums nepieciešamo konfigurāciju.
Ieiesim mazliet dziļāk iekšā. Pirms tam mēs runājām par ClickHouse-operatora darbību saistībā ar ClickHouse specifiku.
Tagad es gribētu pateikt dažus vārdus par to, kā vispār darbojas jebkurš operators, kā arī par to, kā tas mijiedarbojas ar K8.
Vispirms apskatīsim mijiedarbību ar K8. Kas notiek, kad mēs piesakāmies kubectl? Mūsu objekti tiek parādīti uttd, izmantojot API.
Piemēram, pamata Kubernetes objekti: pod, StatefulSet, pakalpojums un tā tālāk sarakstā.
Tajā pašā laikā nekas fizisks vēl nenotiek. Šie objekti ir jāmaterializē klasterī.
Šim nolūkam tiek parādīts kontrolieris. Kontrolieris ir īpašs k8s komponents, kas var realizēt šos aprakstus. Viņš zina, kā un ko darīt fiziski. Viņš zina, kā palaist konteinerus, kas tur ir jākonfigurē, lai serveris strādātu.
Un tas materializē mūsu objektus K8s.
Bet mēs vēlamies darboties ne tikai ar podiem un StatefulSets, mēs vēlamies izveidot ClickHouseInstallation, t.i., ClickHouse tipa objektu, lai darbotos ar to kā vienotu veselumu. Pagaidām tādas iespējas nav.
Bet K8s ir šāda jauka lieta. Mēs vēlamies, lai mums būtu kaut kas līdzīgs šai sarežģītajai vienībai, kurā mūsu klasteris tiktu apkopots no podiem un StatefulSet.
Un kas šim nolūkam ir jādara? Pirmkārt, tiek parādīta pielāgotā resursa definīcija. Kas tas ir? Šis ir K8s apraksts, ka jums būs vēl viens datu tips, ka mēs vēlamies podam pievienot pielāgotu resursu StatefulSet, kas iekšpusē būs sarežģīts. Šis ir datu struktūras apraksts.
Mēs to arī nosūtām tur, izmantojot kubectl apply. Kubernetes ar prieku to paņēma.
Un tagad mūsu krātuvē objektam etcd ir iespēja ierakstīt pielāgotu resursu ar nosaukumu ClickHouseInstallation.
Bet pagaidām nekas tālāk nenotiks. Tas ir, ja mēs tagad izveidosim YAML failu, kuru apskatījām, aprakstot fragmentus un kopijas, un sakām “kubectl apply”, tad Kubernetes to pieņems, ievietos etcd un teiks: “Lieliski, bet es nezinu, ko darīt. ar to. Es nezinu, kā uzturēt ClickHouseInstallation.
Attiecīgi mums ir nepieciešams kāds, kas palīdzētu Kubernetes apkalpot jauno datu tipu. Kreisajā pusē ir vietējais Kubernetes kontrolieris, kas darbojas ar vietējiem datu tipiem. Un labajā pusē mums vajadzētu būt pielāgotam kontrollerim, kas var strādāt ar pielāgotiem datu tipiem.
Un citā veidā to sauc par operatoru. Es to speciāli iekļāvu šeit kā Kubernetes, jo to var izpildīt arī ārpus K8s. Visbiežāk, protams, visi operatori tiek izpildīti Kubernetes, bet nekas neliedz tam stāvēt ārā, tāpēc šeit tas tiek speciāli pārvietots ārā.
Savukārt pielāgotais kontrolieris, kas pazīstams arī kā operators, mijiedarbojas ar Kubernetes, izmantojot API. Tā jau zina, kā mijiedarboties ar API. Un viņš jau zina, kā materializēt sarežģīto shēmu, kuru mēs vēlamies izveidot no pielāgota resursa. Tieši to dara operators.
Kā strādā operators? Apskatīsim labo pusi, lai redzētu, kā viņš to dara. Noskaidrosim, kā operators to visu materializē un kā notiek tālāka mijiedarbība ar K8s.
Operators ir programma. Viņa ir orientēta uz pasākumiem. Operators abonē pasākumus, izmantojot Kubernetes API. Kubernetes API ir ieejas punkti, kur varat abonēt pasākumus. Un ja kaut kas mainās K8s, tad Kubernetes sūta pasākumus visiem, t.i. ikviens, kurš ir abonējis šo API punktu, saņems paziņojumus.
Operators abonē notikumus un viņam ir jāreaģē. Tās uzdevums ir reaģēt uz jauniem notikumiem.
Notikumus ģenerē noteikti atjauninājumi. Pienāk mūsu YAML fails ar ClickHouseInstallation aprakstu. Viņš devās uz etcd caur kubectl pieteikties. Tur tika aktivizēts notikums, un rezultātā šis notikums nonāca ClickHouse operatoram. Operators saņēma šo aprakstu. Un viņam kaut kas jādara. Ja ClickHouseInstallation objektam ir pienācis atjauninājums, jums ir jāatjaunina klasteris. Un operatora uzdevums ir atjaunināt klasteru.
Ko viņš dara? Pirmkārt, mums ir jāizstrādā rīcības plāns, ko mēs darīsim ar šo atjauninājumu. Atjauninājumi var būt ļoti nelieli, t.i. mazs YAML izpildē, bet var radīt ļoti lielas izmaiņas klasterī. Tāpēc operators izveido plānu, un pēc tam pie tā pieturas.
Pēc šī plāna viņš sāk gatavot šo struktūru iekšā, lai materializētu pākstis, servisus, t.i. darīt to, kas ir viņa galvenais uzdevums. Šādi var izveidot ClickHouse klasteru Kubernetes.
Tagad pieskarsimies tik interesantai lietai. Tā ir atbildības sadale starp Kubernetes un operatoru, t.i. ko dara Kubernetes, ko dara operators un kā viņi mijiedarbojas savā starpā.
Kubernetes atbild par sistēmas lietām, t.i. objektu pamata kopai, ko var interpretēt kā sistēmas darbības jomu. Kubernetes zina, kā palaist podus, kā restartēt konteinerus, kā montēt apjomus, kā strādāt ar ConfigMap, t.i. viss, ko var saukt par sistēmu.
Operatori darbojas domēnos. Katrs operators ir izveidots savai tēmai. Mēs to izdarījām ClickHouse.
Un operators precīzi mijiedarbojas attiecībā uz priekšmetu jomu, piemēram, pievieno repliku, izveido diagrammu, iestata uzraudzību. Tā rezultātā notiek sadalīšana.
Apskatīsim praktisku piemēru, kā šī atbildības sadale notiek, veicot replikas pievienošanas darbību.
Operators saņem uzdevumu - pievienot repliku. Ko dara operators? Operators aprēķinās, ka ir jāizveido jauns StatefulSet, kurā jāapraksta tādas un tādas veidnes, apjoma pretenzija.
Viņš to visu sagatavoja un nodod tālāk K8s. Viņš saka, ka viņam ir nepieciešama ConfigMap, StatefulSet, Volume. Kubernetes strādā. Viņš materializē pamatvienības, ar kurām darbojas.
Un tad ClickHouse-operators atkal stājas spēlē. Viņam jau ir fiziska pāksts, uz kuras viņš jau var kaut ko darīt. Un ClickHouse-operators atkal darbojas domēna terminos. Tie. Konkrēti ClickHouse, lai iekļautu kopu klasterī, vispirms ir jākonfigurē šajā klasterī esošā datu shēma. Un, otrkārt, šī replika ir jāiekļauj uzraudzībā, lai to varētu skaidri izsekot. Operators to jau ir konfigurējis.
Un tikai pēc tam spēlē pats ClickHouse, t.i. cita augstāka līmeņa vienība. Šī jau ir datu bāze. Tam ir savs gadījums, cita konfigurēta kopija, kas ir gatava pievienoties klasterim.
Izrādās, ka izpildes ķēde un atbildības sadale, pievienojot repliku, ir diezgan gara.
Turpinām savus praktiskos uzdevumus. Ja jums jau ir klasteris, varat migrēt konfigurāciju.
Mēs to izveidojām tā, lai jūs varētu tieši ielīmēt esošajā xml, ko ClickHouse saprot.
Varat precīzi noregulēt ClickHouse. Vienkārši zonēta izvietošana ir tas, par ko es runāju, skaidrojot hostPath, vietējo krātuvi. Lūk, kā pareizi veikt zonētu izvietošanu.
Nākamais praktiskais uzdevums ir monitorings.
Ja mūsu klasteris mainās, mums periodiski jākonfigurē uzraudzība.
Apskatīsim diagrammu. Mēs šeit jau apskatījām zaļās bultiņas. Tagad apskatīsim sarkanās bultiņas. Tādā veidā mēs vēlamies pārraudzīt savu kopu. Kā ClickHouse klastera metrika nonāk Prometheus un pēc tam Grafana.
Kādas ir uzraudzības grūtības? Kāpēc tas tiek pasniegts kā sava veida sasniegums? Grūtības slēpjas dinamikā. Kad mums ir viens klasteris un tas ir statisks, mēs varam vienreiz iestatīt uzraudzību un vairs netraucēt.
Bet, ja mums ir daudz kopu vai kaut kas nemitīgi mainās, tad process ir dinamisks. Un nepārtraukta monitoringa pārkonfigurēšana ir resursu un laika tērēšana, t.i. pat vienkārši slinkums. Tas ir jāautomatizē. Grūtības slēpjas procesa dinamikā. Un operators to ļoti labi automatizē.
Kā attīstījās mūsu klasteris? Sākumā viņš bija tāds.
Tad viņš bija šāds.
Galu galā viņš kļuva par šādu.
Un uzraudzību operators veic automātiski. Vienots ieejas punkts.
Un tieši pie izejas mēs skatāmies uz Grafana informācijas paneli, lai redzētu, kā mūsu klastera dzīve vārās iekšā.
Starp citu, Grafana informācijas panelis tiek izplatīts arī ar mūsu operatoru tieši avota kodā. Jūs varat izveidot savienojumu un izmantot. Mūsu DevOps man iedeva šo ekrānuzņēmumu.
Kur mēs vēlētos doties tālāk? Šis:
- Izstrādāt testēšanas automatizāciju. Galvenais uzdevums ir jaunu versiju automatizēta testēšana.
- Mēs arī ļoti vēlamies automatizēt integrāciju ar ZooKeeper. Un ir plāni integrēties ar ZooKeeper operatoru. Tie. ZooKeeper ir uzrakstīts operators, un ir loģiski, ka abi operatori sāk integrēties, lai izveidotu ērtāku risinājumu.
- Mēs vēlamies veikt sarežģītākas dzīvības pazīmes.
- Es iezīmēju zaļā krāsā, ka mēs tuvojas veidņu pārmantošanai - DONE, t.i., ar nākamo operatora izlaidumu mums jau būs veidņu mantošana. Šis ir spēcīgs rīks, kas ļauj izveidot sarežģītas konfigurācijas no gabaliem.
- Un mēs vēlamies automatizēt sarežģītus uzdevumus. Galvenais no tiem ir atkārtota sadalīšana.
Ņemsim dažus starprezultātus.
Ko mēs iegūstam rezultātā? Un vai ir vērts to darīt vai nē? Vai vispār ir jāmēģina ievilkt datubāzi Kubernetes un izmantot operatoru kopumā un Alitnity operatoru konkrēti?
Izvadā mēs iegūstam:
- Ievērojama konfigurācijas, izvietošanas un apkopes vienkāršošana un automatizācija.
- Uzreiz iebūvēta uzraudzība.
- Un lietošanai gatavas kodētas veidnes sarežģītām situācijām. Tāda darbība kā replikas pievienošana nav jāveic manuāli. To dara operators.
Atlicis tikai viens pēdējais jautājums. Mums jau ir Kubernetes datubāze, virtualizācija. Kā ir ar šāda risinājuma veiktspēju, jo īpaši tāpēc, ka ClickHouse ir optimizēta veiktspējai?
Atbilde ir tāda, ka viss ir kārtībā! Es neiedziļināšos sīkāk, tā ir atsevišķa ziņojuma tēma.
Bet ir tāds projekts kā TSBS. Kāds ir tā galvenais uzdevums? Šis ir datu bāzes veiktspējas tests. Šis ir mēģinājums salīdzināt siltu ar siltu, mīkstu ar mīkstu.
Kā viņš strādā? Tiek ģenerēta viena datu kopa. Pēc tam šo datu kopu palaiž dažādās datu bāzēs, izmantojot vienu un to pašu testu kopu. Un katra datu bāze atrisina vienu problēmu tā, kā tā zina, kā. Un tad jūs varat salīdzināt rezultātus.
Tas jau atbalsta lielu skaitu datu bāzu. Esmu noteicis trīs galvenos. Šis:
- TimescaleDB.
- InfluxDB.
- ClickHouse.
Tika veikts arī salīdzinājums ar citu līdzīgu risinājumu. Salīdzinājums ar RedShift. Salīdzinājums tika veikts vietnē Amazon. ClickHouse arī šajā jautājumā ir krietni priekšā visiem.
Kādus secinājumus var izdarīt no manis teiktā?
- DB Kubernetes ir iespējama. Iespējams, ka viss ir iespējams, bet kopumā šķiet, ka tas ir iespējams. ClickHouse in Kubernetes noteikti ir iespējams ar mūsu operatora palīdzību.
- Operators palīdz automatizēt procesus un patiešām atvieglo dzīvi.
- Veiktspēja ir normāla.
- Un mums šķiet, ka to var un vajag izmantot.
Atvērtais avots - pievienojies mums!
Kā jau teicu, operators ir pilnībā atvērtā koda produkts, tāpēc būtu ļoti labi, ja to izmantotu maksimālais cilvēku skaits. Pievienojies mums! Gaidām jūs visus!
Paldies visiem!
jautājumi
Paldies par ziņojumu! Mani sauc Antons. Es esmu no SEMrush. Es domāju, kas notiek ar mežizstrādi. Mēs dzirdam par monitoringu, bet neko par mežizstrādi, ja runājam par visu klasteru. Piemēram, mēs esam izveidojuši aparatūras kopu. Un mēs izmantojam centralizētu mežizstrādi, savācot tos kopējā kaudzē, izmantojot standarta līdzekļus. Un tad no turienes mēs iegūstam datus, kas mūs interesē.
Labs jautājums, t.i., piesakāties uzdevumu sarakstā. Mūsu operators to vēl neautomatizē. Tas joprojām attīstās, projekts vēl ir diezgan jauns. Mēs saprotam mežizstrādes nepieciešamību. Arī šī ir ļoti svarīga tēma. Un tas droši vien ir ne mazāk svarīgi kā uzraudzība. Bet pirmais īstenošanas sarakstā bija uzraudzība. Būs mežizstrāde. Protams, mēs cenšamies automatizēt visus klastera dzīves aspektus. Tāpēc atbilde ir tāda, ka šobrīd operators diemžēl nezina, kā to izdarīt, bet tas ir plānos, mēs to darīsim. Ja vēlaties pievienoties, lūdzu, izvelciet pieprasījumu.
Sveiki! Paldies par ziņojumu! Man ir standarta jautājums saistībā ar Pastāvīgiem sējumiem. Kad mēs izveidojam konfigurāciju ar šo operatoru, kā operators nosaka, kuram mezglam ir pievienots konkrēts disks vai mape? Vispirms mums viņam jāpaskaidro, ka, lūdzu, novietojiet mūsu ClickHouse uz šiem mezgliem, kuriem ir disks?
Cik es saprotu, šis jautājums ir lokālās krātuves turpinājums, it īpaši tā hostPath daļa. Tas ir kā paskaidrot visai sistēmai, ka pods ir jāpalaiž uz tāda un tāda mezgla, kuram mums ir fiziski pieslēgts disks, kas ir uzstādīts pa tādu un tādu ceļu. Šī ir vesela sadaļa, kurai es pieskāros ļoti virspusēji, jo atbilde tur ir diezgan liela.
Īsumā tas izskatās šādi. Protams, mums ir jānodrošina šie apjomi. Šobrīd lokālajā krātuvē nav dinamiska nodrošinājuma, tāpēc DevOps ir jāizgriež paši diski, šie sējumi. Un viņiem ir jāpaskaidro Kubernetes nodrošinājums, ka jums būs tādas un tādas klases pastāvīgie sējumi, kas atrodas šādos un šādos mezglos. Tad vajadzēs paskaidrot Kubernetes, ka podi, kuriem nepieciešama tāda un tāda lokāla krātuves klase, ir jānovirza tikai uz tādiem un tādiem mezgliem, izmantojot etiķetes. Šiem nolūkiem operators var piešķirt sava veida etiķeti un vienu katrai resursdatora instancei. Un izrādās, ka podus Kubernetes maršrutēs, lai tie darbotos tikai tajos mezglos, kas atbilst prasībām, etiķetēm, vienkāršā izteiksmē. Administratori piešķir etiķetes un nodrošinājuma diskus manuāli. Un tad tas mērogojas.
Un tā ir trešā iespēja, vietējā, kas palīdz to nedaudz atvieglot. Kā jau esmu uzsvēris, šis ir rūpīgs darbs pie regulēšanas, kas galu galā palīdz sasniegt maksimālu veiktspēju.
Man ir otrs jautājums saistībā ar šo. Kubernetes tika izstrādāts tā, ka mums nav svarīgi, vai mēs zaudējam mezglu vai nē. Kā rīkoties šajā gadījumā, ja esam pazaudējuši mezglu, kurā karājas mūsu skaidiņa?
Jā, Kubernetes sākotnēji bija pozicionēts, ka mūsu attiecības ar pākstīm ir kā liellopiem, bet šeit katrs disks kļūst par kaut ko līdzīgu mājdzīvniekam. Ir tāda problēma, ka mēs nevaram tos vienkārši izmest. Un Kubernetes attīstība iet tajā virzienā, ka to nav iespējams pilnībā filozofiski traktēt, it kā tas būtu pilnīgi izmests resurss.
Tagad par praktisku jautājumu. Ko darīt, ja pazaudējāt mezglu, kurā atradās disks? Šeit problēma tiek risināta augstākā līmenī. ClickHouse gadījumā mums ir kopijas, kas darbojas augstākā līmenī, t.i. ClickHouse līmenī.
Kāds ir iegūtais izvietojums? DevOps ir atbildīgs par datu nezaudēšanu. Viņam ir pareizi jāiestata replikācija un jānodrošina, ka replikācija darbojas. Replikā ClickHouse līmenī jābūt dublētiem datiem. Tā nav problēma, ko operators atrisina. Un nevis problēma, ko pati Kubernetes atrisina. Tas ir ClickHouse līmenī.
Ko darīt, ja nokrīt dzelzs mezgls? Un izrādās, ka jums būs jāinstalē otrs, pareizi jānodrošina tajā esošais disks un jāpieliek etiķetes. Un pēc tam tas atbildīs prasībām, lai Kubernetes tajā varētu palaist instanču podi. Kubernetes to palaidīs. Jūsu pākstu skaits nav pietiekams, lai sasniegtu norādīto skaitu. Tas iet cauri ciklam, ko es parādīju. Un visaugstākajā līmenī ClickHouse sapratīs, ka esam ievadījuši repliku, tā joprojām ir tukša un mums jāsāk uz to pārsūtīt datus. Tie. Šis process vēl nav labi automatizēts.
Paldies par ziņojumu! Kad notiek visādas nepatīkamas lietas, operators avarē un restartējas, un tajā brīdī pienāk notikumi, vai jūs kaut kā ar to tiekat galā?
Kas notiek, ja operators avarēja un restartējas, vai ne?
Jā. Un tajā brīdī pienāca notikumi.
Uzdevumu, ko darīt šajā gadījumā, daļēji dala operators un Kubernetes. Kubernetes ir iespēja atkārtoti atskaņot notikušu notikumu. Viņš atkārto. Un operatora uzdevums ir pārliecināties, ka tad, kad viņam tiek atskaņots notikumu žurnāls, šie notikumi ir idempotenti. Un tā, lai viena un tā paša notikuma atkārtošanās neizjauktu mūsu sistēmu. Un mūsu operators tiek galā ar šo uzdevumu.
Sveiki! Paldies par ziņojumu! Dmitrijs Zavjalovs, uzņēmums Smedova. Vai ir plānots pievienot operatoram iespēju konfigurēt ar haproxy? Mani interesētu kāds cits balansētājs bez standarta, lai ir gudrs un saprot, ka ClickHouse tiešām ir.
Vai tu runā par Ingress?
Jā, aizstājiet Ingress ar haproxy. Haproxy varat norādīt klastera topoloģiju, kur tam ir kopijas.
Mēs vēl neesam par to domājuši. Ja vajadzēs un varēsi paskaidrot, kāpēc tas ir vajadzīgs, tad to varēs īstenot, īpaši, ja vēlēsies piedalīties. Mēs ar prieku izskatīsim iespēju. Īsā atbilde ir nē, mums pašlaik nav šādas funkcionalitātes. Paldies par padomu, mēs izskatīsim šo lietu. Un, ja jūs arī izskaidrojat lietošanas gadījumu un kāpēc tas ir nepieciešams praksē, piemēram, izveidojat problēmas vietnē GitHub, tas būs lieliski.
Jau ir.
Labi. Esam atvērti jebkuriem ieteikumiem. Un haproxy ir pievienots uzdevumu sarakstam. Todo saraksts aug, bet vēl nesamazinās. Bet tas ir labi, tas nozīmē, ka produkts ir pieprasīts.
Avots: www.habr.com