Ataskaita skirta praktiniams Kubernetes operatoriaus kūrimo, jo architektūros projektavimo ir pagrindinių veikimo principų klausimams.
Pirmoje ataskaitos dalyje apžvelgsime:
- kas yra operatorius Kubernetes ir kam jis reikalingas;
- kaip tiksliai operatorius supaprastina sudėtingų sistemų valdymą;
- ką operatorius gali ir ko negali.
Toliau pereikime prie vidinės operatoriaus struktūros aptarimo. Žingsnis po žingsnio pažvelkime į operatoriaus architektūrą ir veikimą. Pažvelkime į tai išsamiai:
- operatoriaus ir Kubernetes sąveika;
- kokias funkcijas operatorius imasi ir kokias funkcijas deleguoja Kubernetes.
Pažvelkime į šukių ir duomenų bazių kopijų tvarkymą „Kubernetes“.
Toliau aptarsime duomenų saugojimo problemas:
- kaip dirbti su nuolatine saugykla operatoriaus požiūriu;
- Vietinės saugyklos naudojimo spąstų.
Paskutinėje ataskaitos dalyje apžvelgsime praktinius taikymo pavyzdžius su „Amazon“ arba „Google Cloud Service“. Ataskaita parengta remiantis ClickHouse operatoriaus kūrimo ir veiklos patirties pavyzdžiu.
Vaizdo įrašas:
Mano vardas Vladislavas Klimenko. Šiandien norėjau pakalbėti apie mūsų patirtį kuriant ir eksploatuojant operatorių – tai specializuotas operatorius, skirtas valdyti duomenų bazių grupes. Pavyzdžiui valdyti ClickHouse klasterį.
Kodėl turime galimybę kalbėti apie operatorių ir ClickHouse?
- Mes palaikome ir vystome ClickHouse.
- Šiuo metu mes stengiamės lėtai prisidėti prie ClickHouse plėtros. Ir mes esame antri po „Yandex“ pagal „ClickHouse“ atliktų pakeitimų apimtį.
- Bandome kurti papildomus ClickHouse ekosistemos projektus.
Norėčiau papasakoti apie vieną iš šių projektų. Tai apie „ClickHouse“ operatorių, skirtą „Kubernetes“.
Savo pranešime norėčiau paliesti dvi temas:
- Pirmoji tema – kaip mūsų ClickHouse duomenų bazės valdymo operatorius veikia Kubernetes.
- Antroji tema – kaip veikia bet kuris operatorius, ty kaip jis sąveikauja su „Kubernetes“.
Tačiau šie du klausimai susikirs mano pranešime.
Kam būtų įdomu klausytis, ką aš bandau pasakyti?
- Tai bus labiausiai įdomu tiems, kurie valdo operatorius.
- Arba tiems, kurie nori sukurti savo, kad suprastų, kaip jis veikia viduje, kaip operatorius sąveikauja su „Kubernetes“ ir kokių spąstų gali atsirasti.
Norint geriau suprasti, ką šiandien aptarsime, pravartu žinoti, kaip veikia Kubernetes, ir turėti pagrindinius mokymus debesyje.
Kas yra ClickHouse? Tai yra stulpelių duomenų bazė su specifinėmis funkcijomis, skirtomis analitinių užklausų apdorojimui internete. Ir tai visiškai atviro kodo.
Ir mums svarbu žinoti tik du dalykus. Turite žinoti, kad tai yra duomenų bazė, todėl tai, ką jums pasakysiu, bus taikoma beveik bet kuriai duomenų bazei. Ir tai, kad ClickHouse DBVS labai gerai keičiasi, suteikia beveik tiesinį mastelį. Todėl klasterio būsena yra natūrali ClickHouse būsena. Mums labiausiai įdomu aptarti, kaip aptarnauti „ClickHouse“ klasterį „Kubernetes“.
Kam jis ten reikalingas? Kodėl mes patys negalime toliau jo eksploatuoti? Ir atsakymai yra iš dalies techniniai ir iš dalies organizaciniai.
- Praktikoje vis dažniau susiduriame su situacija, kai didelėse įmonėse beveik visi komponentai jau yra Kubernetes. Duomenų bazės lieka už jos ribų.
- Ir vis dažniau kyla klausimas: „Ar galima tai įdėti į vidų? Todėl didelės įmonės stengiasi maksimaliai suvienodinti valdymą, kad galėtų greitai valdyti savo duomenų saugyklas.
- O tai ypač padeda, jei reikia maksimalios galimybės pakartoti tą patį naujoje vietoje, t.y. maksimalaus perkeliamumo.
Kaip tai lengva ar sunku? Tai, žinoma, galima padaryti rankomis. Tačiau tai nėra taip paprasta, nes mes turime papildomo sudėtingumo valdyti patį „Kubernetes“, tačiau tuo pat metu „ClickHouse“ specifika yra viena ant kitos. Ir atsiranda toks sumavimas.
Ir visa tai kartu suteikia gana didelį technologijų rinkinį, kurį tampa gana sunku valdyti, nes Kubernetes į savo kasdienes problemas atsineša, o ClickHouse – į kasdienę veiklą. Ypač jei turime kelis ClickHouse, ir su jais reikia nuolat kažką daryti.
Su dinamine konfigūracija „ClickHouse“ turi gana daug problemų, dėl kurių nuolat apkraunama „DevOps“:
- Kai norime ką nors pakeisti „ClickHouse“, pavyzdžiui, pridėti kopiją ar skeveldrą, turime tvarkyti konfigūraciją.
- Tada pakeiskite duomenų schemą, nes ClickHouse turi specifinį dalijimosi metodą. Ten reikia išdėlioti duomenų diagramą, išdėstyti konfigūracijas.
- Turite nustatyti stebėjimą.
- Naujų šukių, naujų kopijų žurnalų rinkimas.
- Rūpinkitės restauravimu.
- Ir paleiskite iš naujo.
Tai įprastos užduotys, kurias labai norėčiau palengvinti.
Pati „Kubernetes“ gerai padeda veikti, tačiau pagrindiniuose sistemos dalykuose.
Kubernetes puikiai palengvina ir automatizuoja tokius dalykus kaip:
- Pasveikimas.
- Perkrauti.
- Saugojimo sistemos valdymas.
Tai gerai, tai teisinga kryptis, bet jis visiškai nesupranta, kaip valdyti duomenų bazių klasterį.
Norime daugiau, norime, kad visa duomenų bazė veiktų Kubernetes.
Norėčiau gauti kažką panašaus į didelį stebuklingą raudoną mygtuką, kurį paspausite, o grupė su kasdienėmis užduotimis, kurias reikia išspręsti, būtų įdiegta ir prižiūrima per visą jos gyvavimo ciklą. „ClickHouse“ klasteris „Kubernetes“.
Ir bandėme rasti sprendimą, kuris palengvintų darbą. Tai „Altinity“ „Kubernetes“ „ClickHouse“ operatorius.
Operatorius yra programa, kurios pagrindinė užduotis yra valdyti kitas programas, t.y. ji yra vadybininkė.
Ir joje yra elgesio modelių. Tai galite vadinti užkoduotomis žiniomis apie dalykinę sritį.
O pagrindinė jo užduotis – palengvinti DevOps gyvenimą ir sumažinti mikrovaldymą, kad jis (DevOps) jau mąstytų aukšto lygio terminais, t.y., kad jis (DevOps) neužsiimtų mikrovaldymu, kad nekonfigūruotų. visos detalės rankiniu būdu.
Ir tik operatorius yra robotas asistentas, kuris užsiima mikro užduotimis ir padeda „DevOps“.
Kam reikalingas operatorius? Jis ypač gerai dirba dviejose srityse:
- Kai specialistas, dirbantis su ClickHouse, neturi pakankamai patirties, bet jau turi valdyti ClickHouse, operatorius palengvina operaciją ir leidžia valdyti gana sudėtingos konfigūracijos ClickHouse klasterį, pernelyg nesigilindamas į tai, kaip visa tai veikia. viduje. Jūs tiesiog duodate jam aukšto lygio užduotis, ir tai veikia.
- Antroji užduotis, kurią ji atlieka geriausiai, yra tada, kai reikia automatizuoti daugybę tipinių užduočių. Pašalina mikroužduotys iš sistemos administratorių.
To labiausiai reikia arba tiems, kurie tik pradeda savo kelionę, arba tiems, kuriems reikia daug automatizuoti.
Kuo operatoriumi pagrįstas požiūris skiriasi nuo kitų sistemų? Yra Helmas. Tai taip pat padeda įdiegti ClickHouse; galite nubrėžti vairo diagramas, kurios net įdiegs visą ClickHouse klasterį. Kuo tada skiriasi operatorius nuo to paties, pavyzdžiui, „Helm“?
Pagrindinis esminis skirtumas yra tas, kad „Helm“ yra paketų valdymas, o operatorius žengia žingsnį toliau. Tai parama visam gyvavimo ciklui. Tai ne tik diegimas, tai kasdienės užduotys, apimančios mastelio keitimą, suskaidymą, t.y. viską, ką reikia padaryti per visą gyvavimo ciklą (jei reikia, tada ir ištrinti) – visa tai sprendžia operatorius. Ji bando automatizuoti ir prižiūrėti visą programinės įrangos gyvavimo ciklą. Tai esminis jos skirtumas nuo kitų pateiktų sprendimų.
Tai buvo įžanginė dalis, eikime toliau.
Kaip mes kuriame savo operatorių? Bandome išspręsti problemą, kad „ClickHouse“ klasterį valdytume kaip vieną išteklius.
Čia mes turime įvesties duomenis kairėje paveikslėlio pusėje. Tai YAML su klasterio specifikacija, kuri klasikiniu būdu per kubectl perduodama Kubernetes. Ten mūsų operatorius jį paima ir atlieka savo magiją. O išvestyje gauname tokią schemą. Tai „ClickHouse“ diegimas „Kubernetes“.
O tada pamažu žiūrėsime, kaip tiksliai dirba operatorius, kokias tipines užduotis galima išspręsti. Apsvarstysime tik įprastas užduotis, nes turime ribotą laiką. Ir ne viskas, ką gali nuspręsti operatorius, bus aptarta.
Pradėkime nuo praktikos. Mūsų projektas yra visiškai atviro kodo, todėl galite pamatyti, kaip jis veikia GitHub. Ir galite vadovautis samprotavimais, kad jei tik norite jį paleisti, galite pradėti nuo Greitos pradžios vadovo.
Jei norite suprasti išsamiai, mes stengiamės, kad dokumentacija būtų daugiau ar mažiau tinkama.
Pradėkime nuo praktinės problemos. Pirma užduotis, nuo kurios mes visi norime pradėti, yra kažkaip paleisti pirmąjį pavyzdį. Kaip galiu paleisti ClickHouse naudojant operatorių, net jei iš tikrųjų nežinau, kaip tai veikia? Rašome manifestą, nes... Visas bendravimas su k8s yra bendravimas per manifestus.
Tai toks sudėtingas manifestas. Tai, ką pabrėžėme raudonai, yra tai, į ką turime sutelkti dėmesį. Mes prašome operatoriaus sukurti klasterį pavadinimu demo.
Šiuo metu tai yra pagrindiniai pavyzdžiai. Sandėliavimas dar neaprašytas, bet prie saugyklos grįšime kiek vėliau. Kol kas stebėsime klasterio vystymosi dinamiką.
Mes sukūrėme šį manifestą. Paduodame jį savo operatoriui. Jis dirbo, kūrė magiją.
Mes žiūrime į konsolę. Domina trys komponentai: „Pod“, dvi paslaugos ir „StatefulSet“.
Operatorius dirbo, ir mes matome, ką tiksliai jis sukūrė.
Jis sukuria kažką panašaus. Turime „StatefulSet“, „Pod“, „ConfigMap“ kiekvienai kopijai ir „ConfigMap“ visam klasteriui. Paslaugos reikalingos kaip įėjimo į klasterį taškai.
Paslaugos yra centrinė apkrovos balansavimo paslauga ir taip pat gali būti naudojamos kiekvienai kopijai, kiekvienai daliai.
Mūsų pagrindinis klasteris atrodo maždaug taip. Jis yra iš vieno mazgo.
Eikime toliau ir komplikuosime dalykus. Turime suskaidyti klasterį.
Mūsų uždaviniai auga, prasideda dinamika. Norime pridėti skeveldrą. Stebime vystymąsi. Keičiame savo specifikaciją. Nurodome, kad norime dviejų šukių.
Tai tas pats failas, kuris dinamiškai vystosi augant sistemai. Sandėliavimas ne, saugojimas bus aptartas toliau, tai atskira tema.
Mes maitiname YAML operatorių ir žiūrime, kas atsitiks.
Operatorius pagalvojo ir sukūrė šiuos objektus. Jau turime du „Pod“, tris paslaugas ir staiga – 2 „StatefulSets“. Kodėl 2 StatefulSets?
Diagramoje buvo taip – tokia mūsų pradinė būsena, kai turėjome vieną ankštį.
Tai tapo taip. Kol kas viskas paprasta, buvo dubliuojama.
Ir kodėl atsirado du „StatefulSets“? Čia turime nukrypti ir aptarti klausimą, kaip „Pods“ valdomi „Kubernetes“.
Yra objektas, vadinamas „StatefulSet“, kuris leidžia sukurti „Pod“ rinkinį iš šablono. Pagrindinis veiksnys čia yra šablonas. Ir jūs galite paleisti daug Pod, naudodami vieną šabloną viename „StatefulSet“. Ir pagrindinė frazė čia yra „daug ankščių vienam šablonui“.
Ir buvo didelė pagunda sukurti visą klasterį, supakuojant jį į vieną „StatefulSet“. Tai veiks, nėra jokių problemų. Tačiau yra vienas įspėjimas. Jei norime surinkti nevienalytę klasterį, tai yra iš kelių ClickHouse versijų, tada pradeda kilti klausimų. Taip, „StatefulSet“ gali atlikti nuolatinį atnaujinimą, o ten galite išleisti naują versiją, paaiškindami, kad reikia išbandyti ne daugiau nei tiek mazgų vienu metu.
Bet jei ekstrapoliuojame užduotį ir sakome, kad norime sukurti visiškai nevienalytę klasterį ir nenorime pakeisti senos versijos į naują naudodami nuolatinį naujinimą, o tiesiog norime sukurti nevienalytę klasterį abiem terminais. skirtingų ClickHouse versijų ir skirtinga saugykla. Pavyzdžiui, norime padaryti kai kurias kopijas atskiruose diskuose, lėtuose, apskritai, kad būtų sukurtas nevienalytis klasteris. Kadangi „StatefulSet“ sukuria standartizuotą sprendimą iš vieno šablono, nėra galimybės to padaryti.
Kiek pagalvojus buvo nuspręsta, kad taip ir darysime. Kiekvieną kopiją turime savo StatefulSet. Šis sprendimas turi tam tikrų trūkumų, tačiau praktiškai visa tai visiškai įtraukia operatorius. Ir yra daug privalumų. Galime sukurti tikslų klasterį, kurio norime, pavyzdžiui, visiškai nevienalytį. Todėl klasteryje, kuriame turime dvi skeveldras su viena kopija, turėsime 2 StatefulSets ir 2 Pods būtent todėl, kad pasirinkome šį metodą dėl pirmiau nurodytų priežasčių, kad galėtume sukurti nevienalytę klasterį.
Grįžkime prie praktinių problemų. Mūsų klasteryje turime sukonfigūruoti vartotojus, t.y. jums reikia atlikti tam tikrą ClickHouse konfigūraciją Kubernetes. Operatorius tam suteikia visas galimybes.
Mes galime rašyti ką norime tiesiogiai YAML. Visos konfigūracijos parinktys yra susietos tiesiogiai iš šio YAML į ClickHouse konfigūracijas, kurios vėliau paskirstomos visame klasteryje.
Galite parašyti taip. Tai pavyzdžiui. Slaptažodis gali būti užšifruotas. Palaikomos absoliučiai visos ClickHouse konfigūracijos parinktys. Čia tik pavyzdys.
Klasterio konfigūracija platinama kaip ConfigMap. Praktiškai ConfigMap atnaujinimas neįvyksta akimirksniu, todėl jei klasteris yra didelis, konfigūracijos stūmimo procesas užtrunka šiek tiek laiko. Tačiau visa tai labai patogu naudoti.
Apsunkinkime užduotį. Klasteris vystosi. Norime pakartoti duomenis. Tai yra, mes jau turime dvi skeveldras, po vieną kopiją, o vartotojai yra sukonfigūruoti. Mes augame ir norime replikuoti.
Ko mums reikia replikacijai?
Mums reikia ZooKeeper. „ClickHouse“ replikacija sukurta naudojant „ZooKeeper“. „ZooKeeper“ reikalingas, kad skirtingos „ClickHouse“ kopijos susitartų, kurie duomenų blokai yra kuriame „ClickHouse“.
„ZooKeeper“ gali naudoti bet kas. Jei įmonė turi išorinį ZooKeeper, tuomet jį galima naudoti. Jei ne, galite jį įdiegti iš mūsų saugyklos. Yra įdiegimo programa, kuri palengvina visa tai.
Ir visos sistemos sąveikos diagrama pasirodo taip. Mes turime Kubernetes kaip platformą. Jis vykdo ClickHouse operatorių. Čia pavaizdavau „ZooKeeper“. O operatorius bendrauja ir su ClickHouse, ir su ZooKeeper. Tai yra, sąveikos rezultatai.
Ir visa tai būtina, kad ClickHouse sėkmingai atkartotų duomenis k8s.
Dabar pažiūrėkime į pačią užduotį, kaip atrodys replikacijos manifestas.
Prie manifesto pridedame du skyrius. Pirma, kur gauti „ZooKeeper“, kuris gali būti „Kubernetes“ viduje arba išorėje. Tai tik aprašymas. Ir užsakome kopijas. Tie. norime dviejų kopijų. Iš viso išėjime turėtume turėti 4 ankštis. Prisimename apie saugyklą, ji grįš šiek tiek vėliau. Sandėliavimas yra atskira istorija.
Tai buvo taip.
Tai tampa taip. Pridedamos kopijos. 4-as netiko, manome, kad ten jų gali būti daug. Ir ZooKeeper pridedamas prie šono. Schemos tampa sudėtingesnės.
Ir laikas pridėti kitą užduotį. Pridėsime nuolatinę saugyklą.
Nuolatiniam saugojimui turime įvairių parinkčių.
Jei dirbame debesų paslaugų teikėju, pvz., „Amazon“, „Google“, tada yra didelė pagunda naudoti saugyklą debesyje. Labai patogu, gera.
Ir yra antras variantas. Tai skirta vietinei saugyklai, kai kiekviename mazge turime vietinius diskus. Ši parinktis yra daug sunkiau įgyvendinama, tačiau tuo pat metu ji yra produktyvesnė.
Pažiūrėkime, ką turime dėl debesies saugyklos.
Yra privalumų. Tai labai lengva sukonfigūruoti. Mes tiesiog užsakome iš debesų tiekėjo, kad suteiktumėte mums tokios ir tokios talpos, tokios ir tokios klasės saugyklą. Užsiėmimus paslaugų teikėjai planuoja savarankiškai.
Ir yra trūkumas. Kai kuriems tai yra nereikšmingas trūkumas. Žinoma, bus tam tikrų našumo problemų. Tai labai patogu naudoti ir patikima, tačiau yra keletas galimų veikimo trūkumų.
Ir todėl ClickHouse orientuojasi būtent į produktyvumą, netgi galima sakyti, kad išspaudžia viską, ką gali, todėl daugelis klientų stengiasi išspausti maksimalų produktyvumą.
Ir norėdami išnaudoti visas galimybes, mums reikia vietinės saugyklos.
„Kubernetes“ teikia tris abstrakcijas vietinei saugyklai naudoti „Kubernetes“. Tai:
- EmptyDir
- HostPath.
- Vietinis
Pažiūrėkime, kuo jie skiriasi ir kuo panašūs.
Pirma, visuose trijuose metoduose turime saugyklą - tai vietiniai diskai, esantys tame pačiame fiziniame k8s mazge. Tačiau jie turi tam tikrų skirtumų.
Pradėkime nuo paprasčiausio, ty tuščioDir. Kas tai yra praktikoje? Savo specifikacijoje mes prašome konteinerių sistemos (dažniausiai Docker) suteikti mums prieigą prie aplanko vietiniame diske.
Praktiškai „Docker“ sukuria laikiną aplanką kur nors savo keliu ir vadina jį ilgu maišu. Ir suteikia sąsają jai pasiekti.
Kaip tai veiks našumo požiūriu? Tai veiks vietinio disko greičiu, t.y. Tai yra visiška prieiga prie jūsų varžto.
Tačiau šis atvejis turi savo trūkumą. Patvarumas šiuo klausimu yra gana abejotinas. Pirmą kartą „Docker“ judant su konteineriais, „Persistent“ prarandama. Jei Kubernetes dėl kokių nors priežasčių norės perkelti šį Pod į kitą diską, duomenys bus prarasti.
Šis metodas yra geras bandymams, nes jis jau rodo normalų greitį, tačiau kažkam rimtam ši parinktis netinka.
Todėl yra antras būdas. Tai yra hostPath. Jei pažvelgsite į ankstesnę ir šią skaidrę, pamatysite tik vieną skirtumą. Mūsų aplankas perkeltas iš „Docker“ tiesiai į „Kubernetes“ mazgą. Čia yra šiek tiek paprasčiau. Vietinėje failų sistemoje tiesiogiai nurodome kelią, kuriame norėtume saugoti savo duomenis.
Šis metodas turi privalumų. Tai jau tikras Persistentas ir tuo pačiu klasikinis. Duomenis, įrašytus į diską, turėsime tam tikru adresu.
Yra ir trūkumų. Tai yra valdymo sudėtingumas. Mūsų „Kubernetes“ gali norėti perkelti „Pod“ į kitą fizinį mazgą. Ir čia atsiranda „DevOps“. Jis turi teisingai paaiškinti visai sistemai, kad šiuos mazgus galima perkelti tik į tuos mazgus, ant kurių turite ką nors sumontuoti išilgai šių takų, ir ne daugiau kaip vieną mazgą vienu metu. Tai gana sunku.
Specialiai šiems tikslams savo operatoriuje sukūrėme šablonus, kad paslėptume visą šį sudėtingumą. Ir jūs galite tiesiog pasakyti: „Noriu turėti vieną ClickHouse egzempliorių kiekvienam fiziniam mazgui ir tokiame bei tokiame kelyje“.
Tačiau šio poreikio reikia ne mums vieniems, todėl ponai iš pačios Kubernetes taip pat supranta, kad žmonės nori turėti prieigą prie fizinių diskų, todėl suteikia trečią sluoksnį.
Jis vadinamas vietiniu. Praktiškai nesiskiria nuo ankstesnės skaidrės. Tik prieš tai reikėjo rankiniu būdu patvirtinti, kad šių podų negalime perkelti iš mazgo į mazgą, nes jie turi būti tam tikru keliu pritvirtinti prie vietinio fizinio disko, tačiau dabar visos šios žinios yra sutalpintos į patį Kubernetes. Ir pasirodo, kad jį daug lengviau sukonfigūruoti.
Grįžkime prie savo praktinės problemos. Grįžkime prie YAML šablono. Čia turime tikrą saugyklą. Mes grįžtame prie to. Nustatėme klasikinį „VolumeClaim“ šabloną kaip ir k8s. Ir aprašome, kokios saugyklos norime.
Po to k8s paprašys saugyklos. Paskirs mums jį StatefulSet. Ir galiausiai jis bus „ClickHouse“ žinioje.
Turėjome tokią schemą. Mūsų nuolatinė saugykla buvo raudona, o tai tarsi rodė, kad tai reikia padaryti.
Ir pasidaro žalia. Dabar ClickHouse k8s klasterio schema yra visiškai baigta. Turime šukių, replikų, ZooKeeper, turime tikrą Persistentą, kuris vienaip ar kitaip įgyvendintas. Schema jau visiškai veikia.
Mes ir toliau gyvename. Mūsų klasteris vystosi. Aleksejus bando ir išleidžia naują ClickHouse versiją.
Iškyla praktinė užduotis – išbandyti naują ClickHouse versiją mūsų klasteryje. Ir, žinoma, nenorite viso to išskleisti; norite įdėti naują versiją į vieną kopiją kur nors tolimesniame kampe ir galbūt ne vieną naują versiją, o dvi iš karto, nes jos pasirodo dažnai.
Ką apie tai galime pasakyti?
Čia kaip tik turime tokią galimybę. Tai yra pod šablonai. Galite parašyti, kad mūsų operatorius visiškai leidžia jums sukurti nevienalytę klasterį. Tie. konfigūruoti, pradedant nuo visų kopijų krūvoje, baigiant kiekviena asmenine kopija, kurią versiją norime ClickHouse, kurią versiją norime saugoti. Galime visiškai sukonfigūruoti klasterį su mums reikalinga konfigūracija.
Eikime šiek tiek giliau į vidų. Prieš tai mes kalbėjome apie tai, kaip veikia ClickHouse-operatorius, atsižvelgiant į ClickHouse specifiką.
Dabar norėčiau pasakyti keletą žodžių apie tai, kaip veikia bet kuris operatorius apskritai, taip pat kaip jis sąveikauja su K8.
Pirmiausia pažiūrėkime, kaip bendrauti su K8. Kas atsitiks, kai taikome kubectl? Mūsų objektai rodomi etcd per API.
Pavyzdžiui, pagrindiniai „Kubernetes“ objektai: „pod“, „StatefulSet“, paslauga ir pan.
Tuo pačiu metu dar nieko fizinio nevyksta. Šie objektai turi būti materializuoti klasteryje.
Šiuo tikslu pasirodo valdiklis. Valdiklis yra specialus k8s komponentas, galintis įgyvendinti šiuos aprašymus. Jis žino, kaip ir ką daryti fiziškai. Jis žino, kaip paleisti konteinerius, ką ten reikia sukonfigūruoti, kad serveris veiktų.
Ir tai materializuoja mūsų objektus K8s.
Tačiau norime veikti ne tik su podais ir StatefulSets, bet ir sukurti ClickHouseInstallation, t.y. ClickHouse tipo objektą, kad galėtume su juo veikti kaip viena visuma. Kol kas tokios galimybės nėra.
Tačiau K8s turi tokį gerą dalyką. Norime, kad turėtume kur nors panašų į šį sudėtingą objektą, kuriame mūsų klasteris būtų surinktas iš ankšties ir „StatefulSet“.
Ir ką dėl to reikia padaryti? Pirma, į paveikslėlį patenka tinkintas išteklių apibrėžimas. Kas tai yra? Tai yra K8s aprašymas, kad turėsite dar vieną duomenų tipą, kad mes norime pridėti pasirinktinį šaltinį prie podelio, StatefulSet, kuris bus sudėtingas viduje. Tai yra duomenų struktūros aprašymas.
Taip pat ten siunčiame per kubectl aplikaciją. Kubernetesas laimingai jį paėmė.
O dabar mūsų saugykloje esantis objektas etcd turi galimybę įrašyti pasirinktinį išteklį pavadinimu ClickHouseInstallation.
Bet kol kas daugiau nieko nebus. Tai yra, jei dabar sukursime YAML failą, kurį peržiūrėjome aprašydami skeveldras ir kopijas, ir pasakysime „kubectl apply“, tada „Kubernetes“ jį priims, įdės į etcd ir pasakys: „Puiku, bet nežinau, ką daryti. su tuo. Aš nežinau, kaip prižiūrėti ClickHouseInstallation.
Atitinkamai, mums reikia žmogaus, kuris padėtų „Kubernetes“ aptarnauti naują duomenų tipą. Kairėje pusėje yra vietinis „Kubernetes“ valdiklis, veikiantis su vietiniais duomenų tipais. Dešinėje turėtume turėti pasirinktinį valdiklį, kuris galėtų dirbti su pasirinktiniais duomenų tipais.
Ir dar kitaip jis vadinamas operatoriumi. Aš specialiai įtraukiau jį čia kaip „Kubernetes“, nes jis taip pat gali būti vykdomas ne K8. Dažniausiai, žinoma, visi operatoriai yra vykdomi Kubernetes, tačiau niekas netrukdo jam stovėti lauke, todėl čia jis specialiai perkeliamas į lauką.
Savo ruožtu pasirinktinis valdiklis, taip pat žinomas kaip operatorius, sąveikauja su „Kubernetes“ per API. Ji jau žino, kaip bendrauti su API. Ir jis jau žino, kaip realizuoti sudėtingą grandinę, kurią norime sukurti iš pasirinktinių išteklių. Būtent tai daro operatorius.
Kaip veikia operatorius? Pažiūrėkime į dešinę pusę, kad pamatytume, kaip jis tai daro. Išsiaiškinkime, kaip operatorius visa tai materializuoja ir kaip vyksta tolimesnė sąveika su K8.
Operatorius yra programa. Ji yra orientuota į įvykius. Operatorius užsiprenumeruoja įvykius naudodamas Kubernetes API. „Kubernetes“ API turi įėjimo taškus, kuriuose galite užsiprenumeruoti įvykius. O jei kas nors pasikeičia K8s, tai Kubernetes siunčia įvykius visiems, t.y. kas užsiprenumeravo šį API tašką, gaus pranešimus.
Operatorius užsiprenumeruoja įvykius ir turi sureaguoti. Jos užduotis – reaguoti į kylančius įvykius.
Įvykiai generuojami naudojant tam tikrus atnaujinimus. Atkeliauja mūsų YAML failas su ClickHouseInstallation aprašymu. Jis nuėjo į etcd per kubectl aplikaciją. Ten buvo suaktyvintas įvykis ir dėl to šis įvykis atkeliavo į ClickHouse operatorių. Operatorius gavo šį aprašymą. Ir jis turi ką nors padaryti. Jei buvo gautas ClickHouseInstallation objekto atnaujinimas, turite atnaujinti klasterį. O operatoriaus užduotis yra atnaujinti klasterį.
Ką jis daro? Pirmiausia turime parengti veiksmų planą, ką darysime su šiuo atnaujinimu. Atnaujinimai gali būti labai maži, t.y. maža YAML vykdymo, bet gali sukelti labai didelių klasterio pakeitimų. Todėl operatorius sukuria planą, o tada jo laikosi.
Pagal šį planą jis pradeda virti šią konstrukciją viduje, kad galėtų materializuotis ankštys, paslaugos, t.y. daryti tai, kas yra jo pagrindinė užduotis. Štai kaip sukurti „ClickHouse“ klasterį „Kubernetes“.
Dabar paliesime tokį įdomų dalyką. Tai yra atsakomybės pasidalijimas tarp Kubernetes ir operatoriaus, t.y. ką veikia „Kubernetes“, ką veikia operatorius ir kaip jie sąveikauja tarpusavyje.
Kubernetes yra atsakingas už sisteminius dalykus, t.y. pagrindiniam objektų rinkiniui, kurį galima interpretuoti kaip sistemos taikymo sritį. Kubernetes žino, kaip paleisti poddus, kaip perkrauti konteinerius, kaip prijungti tomus, kaip dirbti su ConfigMap, t.y. viskas, ką galima pavadinti sistema.
Operatoriai veikia domenuose. Kiekvienas operatorius yra sukurtas pagal savo dalykinę sritį. Mes tai padarėme ClickHouse.
O operatorius sąveikauja tiksliai pagal dalykinę sritį, pavyzdžiui, prideda kopiją, sudaro diagramą, nustato stebėjimą. Dėl to susidaro padalijimas.
Pažvelkime į praktinį pavyzdį, kaip šis atsakomybės pasidalijimas vyksta, kai atliekame replikos pridėjimo veiksmą.
Operatorius gauna užduotį – pridėti kopiją. Ką veikia operatorius? Operatorius apskaičiuos, kad reikia sukurti naują StatefulSet, kuriame turi būti aprašyti tokie ir tokie šablonai, apimties pretenzija.
Jis viską paruošė ir perduoda K8s. Jis sako, kad jam reikia ConfigMap, StatefulSet, Volume. Kubernetes dirba. Jis materializuoja pagrindinius padalinius, su kuriais dirba.
Tada vėl įsijungia „ClickHouse-operator“. Jis jau turi fizinį podą, ant kurio jau gali ką nors padaryti. Ir ClickHouse-operatorius vėl veikia domeno sąlygomis. Tie. Tiksliau, ClickHouse, norėdami įtraukti repliką į klasterį, pirmiausia turite sukonfigūruoti duomenų schemą, esančią šioje klasteryje. Ir, antra, ši kopija turi būti įtraukta į stebėjimą, kad ją būtų galima aiškiai atsekti. Operatorius tai jau sukonfigūruoja.
Ir tik po to įsijungia pats ClickHouse, t.y. kitas aukštesnio lygio subjektas. Tai jau yra duomenų bazė. Jis turi savo egzempliorių, kitą sukonfigūruotą kopiją, kuri yra paruošta prisijungti prie klasterio.
Pasirodo, kad pridedant kopiją vykdymo ir atsakomybės pasidalijimo grandinė yra gana ilga.
Tęsiame praktines užduotis. Jei jau turite grupę, galite perkelti konfigūraciją.
Mes tai padarėme taip, kad galėtumėte įklijuoti esamą xml, kurį „ClickHouse“ supranta.
Galite tiksliai sureguliuoti ClickHouse. Tiesiog zoninis diegimas yra tai, apie ką aš kalbėjau aiškindamas „hostPath“, vietinę saugyklą. Štai kaip teisingai atlikti zoninį diegimą.
Kita praktinė užduotis – stebėjimas.
Jei mūsų klasteris pasikeičia, turime periodiškai konfigūruoti stebėjimą.
Pažiūrėkime į diagramą. Čia jau žiūrėjome į žalias rodykles. Dabar pažvelkime į raudonas rodykles. Taip norime stebėti savo grupę. Kaip „ClickHouse“ klasterio metrika patenka į „Prometheus“, o vėliau į „Grafana“.
Kokie yra stebėjimo sunkumai? Kodėl tai pristatoma kaip kažkoks pasiekimas? Sunkumas slypi dinamikoje. Kai turime vieną klasterį ir jis yra statinis, galime vieną kartą nustatyti stebėjimą ir nebevargti.
Bet jei turime daug klasterių arba kažkas nuolat keičiasi, tada procesas yra dinamiškas. O nuolatinis stebėjimo perkonfigūravimas yra resursų ir laiko švaistymas, t.y. net tik tinginystė. Tai turi būti automatizuota. Sunkumas slypi proceso dinamikoje. Ir operatorius tai labai gerai automatizuoja.
Kaip vystėsi mūsų klasteris? Iš pradžių jis buvo toks.
Tada jis buvo toks.
Galų gale jis tapo tokiu.
O stebėjimą operatorius atlieka automatiškai. Vienintelis įėjimo taškas.
Ir tik prie išėjimo žiūrime į „Grafana“ prietaisų skydelį, kad pamatytume, kaip viduje verda mūsų klasterio gyvenimas.
Beje, „Grafana“ prietaisų skydelis taip pat platinamas su mūsų operatoriumi tiesiogiai šaltinio kode. Galite prisijungti ir naudoti. Mūsų „DevOps“ davė man šią ekrano kopiją.
Kur norėtume nukeliauti toliau? Tai:
- Sukurti testavimo automatizavimą. Pagrindinė užduotis – automatizuotas naujų versijų testavimas.
- Taip pat tikrai norime automatizuoti integraciją su „ZooKeeper“. Ir yra planų integruotis su „ZooKeeper“ operatoriumi. Tie. „ZooKeeper“ buvo parašytas operatorius ir logiška, kad abu operatoriai pradeda integruotis, kad sukurtų patogesnį sprendimą.
- Norime atlikti sudėtingesnius gyvybinius požymius.
- Žalia spalva paryškinau, kad artėjame prie šablonų paveldėjimo – DONE, t.y. su kita operatoriaus versija jau turėsime šablonų paveldėjimą. Tai galingas įrankis, leidžiantis iš dalių sukurti sudėtingas konfigūracijas.
- Ir mes norime automatizuoti sudėtingas užduotis. Pagrindinis yra pakartotinis skilimas.
Paimkime keletą tarpinių rezultatų.
Ką mes gauname dėl to? Ir verta tai daryti ar ne? Ar net reikia bandyti tempti duomenų bazę į Kubernetes ir naudoti operatorių apskritai ir Alitnity operatorių konkrečiai?
Išvestyje gauname:
- Žymus konfigūracijos, diegimo ir priežiūros supaprastinimas ir automatizavimas.
- Iš karto įmontuotas stebėjimas.
- Ir paruošti naudoti kodifikuoti šablonai sudėtingoms situacijoms. Tokio veiksmo, kaip kopijos pridėjimas, nereikia atlikti rankiniu būdu. Operatorius tai daro.
Liko tik vienas paskutinis klausimas. Jau turime Kubernetes duomenų bazę, virtualizaciją. O kaip dėl tokio sprendimo našumo, ypač dėl to, kad ClickHouse yra optimizuotas našumui?
Atsakymas yra viskas gerai! Į detales nesileisiu, tai atskiro pranešimo tema.
Tačiau yra toks projektas kaip TSBS. Kokia jo pagrindinė užduotis? Tai duomenų bazės veikimo testas. Tai bandymas palyginti šiltą su šiltu, minkštą su minkštu.
Kaip jis dirba? Sugeneruojamas vienas duomenų rinkinys. Tada šis duomenų rinkinys paleidžiamas skirtingose duomenų bazėse naudojant tą patį testų rinkinį. Ir kiekviena duomenų bazė išsprendžia vieną problemą taip, kaip išmano. Ir tada jūs galite palyginti rezultatus.
Ji jau palaiko daugybę duomenų bazių. Išskyriau tris pagrindinius. Tai:
- Laiko skalėDB.
- InfluxDB.
- ClickHouse.
Taip pat buvo atliktas palyginimas su kitu panašiu sprendimu. Palyginimas su RedShift. Palyginimas buvo atliktas „Amazon“. „ClickHouse“ šiuo klausimu taip pat gerokai lenkia visus.
Kokias išvadas galima padaryti iš to, ką pasakiau?
- DB Kubernetes yra įmanoma. Tikriausiai viskas įmanoma, bet apskritai atrodo, kad tai įmanoma. ClickHouse Kubernetes tikrai įmanoma su mūsų operatoriaus pagalba.
- Operatorius padeda automatizuoti procesus ir tikrai palengvina gyvenimą.
- Našumas normalus.
- Ir mums atrodo, kad tuo galima ir reikia naudotis.
Atviras kodas – prisijunk prie mūsų!
Kaip jau sakiau, operatorius yra visiškai atviro kodo produktas, todėl būtų labai gerai, jei juo naudotųsi maksimalus žmonių skaičius. Prisijunk prie mūsų! Laukiame Jūsų visų!
Ačiū jums visiems!
Klausimai
Ačiū už pranešimą! Mano vardas Antonas. Aš esu iš SEMrush. Man įdomu, kas yra su miško ruoša. Mes girdime apie stebėjimą, bet nieko apie medienos ruošą, jei kalbame apie visą klasterį. Pavyzdžiui, mes sukūrėme aparatinės įrangos grupę. O mes naudojame centralizuotą kirtimą, standartinėmis priemonėmis surenkame juos į bendrą krūvą. Ir tada iš ten gauname mus dominančius duomenis.
Geras klausimas, t.y. prisijungti prie darbų sąrašo. Mūsų operatorius to dar neautomatizuoja. Jis vis dar kuriamas, projektas dar gana jaunas. Suprantame medienos ruošos poreikį. Tai taip pat labai svarbi tema. Ir tai tikriausiai ne mažiau svarbu nei stebėjimas. Tačiau pirmiausia įgyvendinimo sąraše buvo stebėjimas. Bus kirtimai. Natūralu, kad mes stengiamės automatizuoti visus klasterio gyvenimo aspektus. Todėl atsakoma, kad šiuo metu operatorė, deja, nežino, kaip tai padaryti, bet tai yra planuose, mes tai padarysime. Jei norite prisijungti, traukite prašymą.
Sveiki! Ačiū už pranešimą! Turiu standartinį klausimą, susijusį su nuolatiniais tomais. Kai sukuriame konfigūraciją su šiuo operatoriumi, kaip operatorius nustato, prie kurio mazgo yra prijungtas konkretus diskas ar aplankas? Pirmiausia turime jam paaiškinti, kad įdėkite mūsų ClickHouse į šiuos mazgus, kurie turi diską?
Kiek suprantu, šis klausimas yra vietinės saugyklos, ypač jos hostPath dalies, tęsinys. Tai tarsi paaiškinimas visai sistemai, kad podą reikia paleisti tokiame ir tokiame mazge, prie kurio turime fiziškai prijungtą diską, kuris sumontuotas tokiu ir tokiu keliu. Tai visa dalis, kurią paliečiau labai paviršutiniškai, nes atsakymas ten yra gana didelis.
Trumpai tai atrodo taip. Žinoma, šiuos kiekius turime aprūpinti. Šiuo metu vietinėje saugykloje nėra dinaminės nuostatos, todėl „DevOps“ turi iškirpti pačius diskus, šiuos tomus. Ir jie turi paaiškinti Kubernetes aprūpinimą, kad turėsite nuolatinius tokios ir tokios klasės tomus, kurie yra tokiuose ir tokiuose mazguose. Tada reikės paaiškinti Kubernetes, kad podai, kuriems reikalinga tokia ir tokia vietinė saugojimo klasė, turi būti nukreipti tik į tokius ir tokius mazgus naudojant etiketes. Šiais tikslais operatorius turi galimybę priskirti tam tikrą etiketę ir po vieną kiekvienam pagrindiniam objektui. Ir pasirodo, kad podus Kubernetes nukreips, kad jie veiktų tik tuos mazgus, kurie atitinka reikalavimus, etiketes, paprastai tariant. Administratoriai etiketes ir aprūpinimo diskus priskiria rankiniu būdu. Ir tada jis keičiasi.
Ir tai yra trečioji galimybė, vietinė, kuri padeda tai padaryti šiek tiek lengviau. Kaip jau pabrėžiau, tai kruopštus derinimo darbas, kuris galiausiai padeda pasiekti maksimalų našumą.
Turiu su tuo susijusį antrą klausimą. Kubernetes buvo sukurtas taip, kad mums nesvarbu, ar prarasime mazgą, ar ne. Ką daryti tokiu atveju, jei praradome mazgą, kuriame kabo mūsų skeveldra?
Taip, Kubernetes iš pradžių laikėsi pozicijos, kad mūsų santykiai su ankštimis yra kaip galvijai, bet čia su mumis kiekvienas diskas tampa kažkuo panašaus į augintinį. Yra tokia problema, kad negalime jų tiesiog išmesti. O Kubernetes plėtra eina ta linkme, kad visiškai filosofiškai traktuoti jos neįmanoma, tarsi tai būtų visiškai išmestas išteklius.
Dabar praktinis klausimas. Ką daryti, jei pametėte mazgą, kuriame buvo diskas? Čia problema sprendžiama aukštesniu lygiu. ClickHouse atveju turime kopijų, kurios veikia aukštesniu lygiu, t.y. ClickHouse lygiu.
Koks yra gautas nusiteikimas? „DevOps“ yra atsakinga už tai, kad duomenys nebūtų prarasti. Jis turi teisingai nustatyti replikaciją ir užtikrinti, kad replikacija būtų vykdoma. „ClickHouse“ lygio replikoje turi būti dubliuoti duomenys. Tai nėra užduotis, kurią sprendžia operatorius. Ir ne ta problema, kurią sprendžia pati Kubernetes. Tai yra ClickHouse lygiu.
Ką daryti, jei nukrito geležies mazgas? Ir paaiškėja, kad jums reikės įdiegti antrą, tinkamai įdėti diską ir pritvirtinti etiketes. Ir po to jis atitiks reikalavimus, kad „Kubernetes“ galėtų paleisti egzempliorių rinkinį. „Kubernetes“ jį paleis. Jūsų ankščių skaičiaus nepakanka, kad atitiktų nurodytą skaičių. Jis praeis per ciklą, kurį parodžiau. O aukščiausiu lygiu ClickHouse supras, kad įvedėme repliką, ji vis dar tuščia ir reikia pradėti į ją perkelti duomenis. Tie. Šis procesas dar nėra gerai automatizuotas.
Ačiū už pranešimą! Kai nutinka visokių bjaurių dalykų, operatorius sugenda ir paleidžiamas iš naujo, o tuo metu ateina įvykiai, ar kaip nors su tuo susitvarkote?
Kas atsitiks, jei operatorius sudužo ir paleis iš naujo, tiesa?
Taip. Ir tą akimirką atėjo įvykiai.
Užduotį, ką daryti šiuo atveju, iš dalies dalijasi operatorius ir „Kubernetes“. „Kubernetes“ turi galimybę pakartoti įvykusį įvykį. Jis atkuria. O operatoriaus užduotis yra įsitikinti, kad kai įvykių žurnalas jam atkuriamas, šie įvykiai yra idempotenti. Ir kad pasikartojantis tas pats įvykis nepalaužtų mūsų sistemos. Ir mūsų operatorius susidoroja su šia užduotimi.
Sveiki! Ačiū už pranešimą! Dmitrijus Zavyalovas, įmonė Smedova. Ar planuojama pridėti operatoriaus galimybę konfigūruoti su haproxy? Mane domintų koks nors kitas balansuotojas be standartinio, kad būtų protingas ir suprastų, kad ClickHouse tikrai yra.
Ar tu kalbi apie Ingress?
Taip, pakeiskite Ingress į haproxy. Haproxy galite nurodyti klasterio, kuriame yra kopijų, topologiją.
Mes apie tai dar negalvojome. Jei jums to reikia ir galite paaiškinti, kodėl to reikia, tada bus galima tai įgyvendinti, ypač jei norite dalyvauti. Mes mielai apsvarstysime variantą. Trumpas atsakymas yra ne, šiuo metu tokios funkcijos neturime. Ačiū už patarimą, išnagrinėsime šį reikalą. Ir jei taip pat paaiškinsite naudojimo atvejį ir kodėl to reikia praktiškai, pavyzdžiui, sukursite problemų „GitHub“, tai bus puiku.
Jau.
gerai. Esame atviri bet kokiems pasiūlymams. Ir haproxy įtrauktas į darbų sąrašą. Todo sąrašas auga, kol kas nemažėja. Bet tai yra gerai, tai reiškia, kad produktas yra paklausus.
Šaltinis: www.habr.com