Rekstraraðili í Kubernetes til að stjórna gagnagrunnsklösum. Vladislav Klimenko (Altinity, 2019)

Skýrslan er helguð hagnýtum atriðum við að þróa rekstraraðila í Kubernetes, hanna arkitektúr hans og grundvallaraðgerðir.

Í fyrsta hluta skýrslunnar munum við fjalla um:

• hvað er rekstraraðili í Kubernetes og hvers vegna er þörf á honum;
• hvernig nákvæmlega rekstraraðilinn einfaldar stjórnun flókinna kerfa;
• hvað rekstraraðili getur og getur ekki gert.

Næst skulum við halda áfram að ræða innri uppbyggingu rekstraraðilans. Við skulum skoða arkitektúr og rekstur rekstraraðila skref fyrir skref. Við skulum skoða það í smáatriðum:

• samskipti milli rekstraraðila og Kubernetes;
• hvaða aðgerðir rekstraraðilinn tekur að sér og hvaða aðgerðir hann felur Kubernetes.

Við skulum skoða stjórnun á brotum og gagnagrunnseftirlíkingum í Kubernetes.
Næst munum við ræða gagnageymslumál:

• hvernig á að vinna með viðvarandi geymslu frá sjónarhóli rekstraraðila;
• gildra þess að nota Local Storage.

Í lokahluta skýrslunnar munum við skoða hagnýt dæmi um notkun smellhús-rekstraraðili með Amazon eða Google Cloud Service. Skýrslan er byggð á dæmi um þróun og rekstrarreynslu rekstraraðila fyrir ClickHouse.

Video:

Ég heiti Vladislav Klimenko. Í dag langaði mig að segja frá reynslu okkar af þróun og rekstri rekstraraðila, en þetta er sérhæfður rekstraraðili til að stjórna gagnagrunnsklösum. Til dæmis ClickHouse-rekstraraðili til að stjórna ClickHouse klasanum.

Hvers vegna höfum við tækifæri til að tala um rekstraraðila og ClickHouse?

• Við styðjum og þróum ClickHouse.
• Í augnablikinu erum við að reyna að leggja okkar af mörkum til þróunar ClickHouse hægt og rólega. Og við erum næst á eftir Yandex hvað varðar magn breytinga sem gerðar eru á ClickHouse.
• Við erum að reyna að búa til viðbótarverkefni fyrir ClickHouse vistkerfið.

Mig langar að segja ykkur frá einu af þessum verkefnum. Þetta snýst um ClickHouse-stjórnanda fyrir Kubernetes.

Í skýrslu minni langar mig að koma inn á tvö efni:

• Fyrsta umræðuefnið er hvernig ClickHouse gagnagrunnsstjórnunarfyrirtækið okkar vinnur í Kubernetes.
• Annað umræðuefnið er hvernig hvaða rekstraraðili virkar, þ.e. hvernig hann hefur samskipti við Kubernetes.

Hins vegar munu þessar tvær spurningar skerast í gegnum skýrslu mína.

Hver hefði áhuga á að hlusta á það sem ég er að reyna að segja?

• Það mun vekja mestan áhuga þeirra sem reka rekstraraðila.
• Eða fyrir þá sem vilja búa til sína eigin til að skilja hvernig það virkar innbyrðis, hvernig símafyrirtækið hefur samskipti við Kubernetes og hvaða gildrur geta birst.

Til að skilja sem best hvað við munum ræða í dag er góð hugmynd að vita hvernig Kubernetes virkar og hafa grunnskýjaþjálfun.

Hvað er ClickHouse? Þetta er dálkagagnagrunnur með sértækum eiginleikum fyrir úrvinnslu greiningarfyrirspurna á netinu. Og það er algjörlega opinn uppspretta.

Og það er mikilvægt fyrir okkur að vita aðeins tvennt. Þú þarft að vita að þetta er gagnagrunnur, svo það sem ég mun segja þér mun eiga við um nánast hvaða gagnagrunn sem er. Og sú staðreynd að ClickHouse DBMS mælist mjög vel, gefur næstum línulegan sveigjanleika. Og þess vegna er klasaástandið náttúrulegt ástand fyrir ClickHouse. Og við höfum mestan áhuga á að ræða hvernig eigi að þjóna ClickHouse klasanum í Kubernetes.

Hvers vegna er hans þörf þar? Af hverju getum við ekki haldið áfram að reka það sjálf? Og svörin eru að hluta til tæknileg og að hluta til skipulagsleg.

• Í reynd erum við í auknum mæli að lenda í aðstæðum þar sem í stórum fyrirtækjum eru næstum allir hlutir nú þegar í Kubernetes. Gagnagrunnar eru áfram fyrir utan.
• Og spurningin er sífellt spurð: "Er hægt að setja þetta inni?" Þess vegna eru stór fyrirtæki að reyna að ná hámarks sameiningu stjórnenda til að geta fljótt stjórnað gagnageymslum sínum.
• Og þetta hjálpar sérstaklega ef þú þarft hámarks tækifæri til að endurtaka það sama á nýjum stað, þ.e. hámarks flytjanleika.

Hversu auðvelt eða erfitt er það? Þetta er auðvitað hægt að gera með höndunum. En það er ekki svo einfalt, vegna þess að við höfum aukið flókið að stjórna Kubernetes sjálfu, en á sama tíma eru sérkenni ClickHouse ofan á. Og slík samsöfnun leiðir af sér.

Og allt saman gefur þetta tiltölulega stórt safn af tækni, sem verður frekar erfitt að stjórna, vegna þess að Kubernetes kemur með sín eigin daglegu málefni í rekstri og ClickHouse kemur með sín eigin vandamál í daglegan rekstur. Sérstaklega ef við erum með nokkur ClickHouse og þurfum stöðugt að gera eitthvað með þau.

Með kraftmikilli uppsetningu er ClickHouse með nokkuð mikinn fjölda mála sem skapa stöðugt álag á DevOps:

• Þegar við viljum breyta einhverju í ClickHouse, til dæmis, bæta við eftirmynd eða shard, þá þurfum við að stjórna uppsetningunni.
• Breyttu síðan gagnaskemanu, vegna þess að ClickHouse hefur ákveðna klippingaraðferð. Þar þarftu að setja upp gagnamyndina, setja upp stillingarnar.
• Þú þarft að setja upp eftirlit.
• Safna annálum fyrir ný brot, fyrir nýjar eftirmyndir.
• Sjá um endurreisn.
• Og endurræstu.

Þetta eru venjubundin verkefni sem ég myndi virkilega vilja gera auðveldari í notkun.

Kubernetes sjálft hjálpar vel í rekstri, en á helstu kerfishlutum.

Kubernetes er góður í að auðvelda og gera hluti eins og:

• Bati.
• Endurræsa.
• Geymslukerfisstjórnun.

Það er gott, það er rétt stefna, en hann er algjörlega hugmyndalaus um hvernig á að reka gagnagrunnsklasa.

Við viljum meira, við viljum að allur gagnagrunnurinn virki í Kubernetes.

Mig langar að fá eitthvað eins og stóran töfrauðan hnapp sem þú ýtir á og þyrping með hversdagslegum verkefnum sem þarf að leysa er dreift og viðhaldið allan lífsferilinn. ClickHouse þyrping í Kubernetes.

Og við reyndum að búa til lausn sem myndi auðvelda verkið. Þetta er ClickHouse-rekstraraðili fyrir Kubernetes frá Altinity.

Rekstraraðili er forrit sem hefur það meginverkefni að stjórna öðrum forritum, þ.e.a.s. það er stjórnandi.

Og það inniheldur hegðunarmynstur. Þú getur kallað þetta kóðaða þekkingu um málaflokkinn.

Og aðalverkefni hans er að gera líf DevOps auðveldara og draga úr örstjórnun, þannig að hann (DevOps) hugsar nú þegar á háu stigi, þ.e.a.s. þannig að hann (DevOps) stundi ekki örstjórnun, þannig að hann stilli ekki upp allar upplýsingar handvirkt.

Og bara stjórnandinn er vélfærafræðiaðstoðarmaður sem fæst við smáverkefni og hjálpar DevOps.

Af hverju þarftu rekstraraðila? Hann stendur sig sérstaklega vel á tveimur sviðum:

• Þegar sérfræðingur sem fæst við ClickHouse hefur ekki næga reynslu, en þarf nú þegar að reka ClickHouse, auðveldar rekstraraðilinn aðgerðina og gerir þér kleift að reka ClickHouse þyrping með frekar flókinni uppsetningu, án þess að fara í smáatriði um hvernig þetta allt virkar inni. Þú gefur honum bara verkefni á háu stigi og það virkar.
• Og annað verkefnið sem það stendur sig best í er þegar það er nauðsynlegt að gera sjálfvirkan fjölda dæmigerðra verkefna. Fjarlægir örverkefni frá kerfisstjórum.

Þessu er mest þörf annað hvort fyrir þá sem eru að hefja ferð sína eða þá sem þurfa að gera mikla sjálfvirkni.

Hvernig er rekstrartengda nálgunin frábrugðin öðrum kerfum? Þar er Hjálmur. Það hjálpar líka að setja upp ClickHouse; þú getur teiknað stýritöflur, sem munu jafnvel setja upp heilan ClickHouse þyrping. Hver er þá munurinn á rekstraraðilanum og hinum sama, til dæmis Helm?

Helsti grundvallarmunurinn er sá að Helm er pakkastjórnun og Operator gengur skrefinu lengra. Þetta er stuðningur fyrir allan lífsferilinn. Þetta er ekki aðeins uppsetning, þetta eru hversdagsleg verkefni sem fela í sér mælingu, klippingu, þ.e.a.s. allt sem þarf að gera á líftímanum (ef nauðsyn krefur, þá eyðing líka) - þetta er allt ákveðið af rekstraraðilanum. Það reynir að gera sjálfvirkan og viðhalda öllum líftíma hugbúnaðarins. Þetta er grundvallarmunur þess frá öðrum lausnum sem kynntar eru.

Það var inngangshlutinn, við skulum halda áfram.

Hvernig byggjum við upp rekstraraðila okkar? Við erum að reyna að nálgast málið til að stjórna ClickHouse klasanum sem eina auðlind.

Hér höfum við inntaksgögn vinstra megin á myndinni. Þetta er YAML með klasaforskrift, sem er send til Kubernetes á klassískan hátt í gegnum kubectl. Þar tekur rekstraraðilinn okkar það upp og gerir sína töfra. Og við framleiðsluna fáum við eftirfarandi kerfi. Þetta er útfærsla á ClickHouse í Kubernetes.

Og svo munum við skoða hægt og rólega hvernig rekstraraðilinn vinnur nákvæmlega, hvaða dæmigerð verkefni er hægt að leysa. Við munum aðeins íhuga dæmigerð verkefni vegna þess að við höfum takmarkaðan tíma. Og ekki verður rætt um allt sem rekstraraðilinn getur ákveðið.

Byrjum á æfingu. Verkefnið okkar er algjörlega opinn uppspretta, svo þú getur séð hvernig það virkar á GitHub. Og þú getur haldið áfram út frá því að ef þú vilt bara ræsa það, þá geturðu byrjað með Quick Start Guide.

Ef þú vilt skilja ítarlega, þá reynum við að viðhalda skjölunum í meira og minna viðeigandi formi.

Við skulum byrja á hagnýtu vandamáli. Fyrsta verkefnið, þar sem við viljum öll byrja, er að keyra fyrsta dæmið einhvern veginn. Hvernig get ég ræst ClickHouse með símafyrirtækinu, jafnvel þó ég viti ekki hvernig það virkar? Við erum að skrifa stefnuskrá vegna þess að... Öll samskipti við k8s eru samskipti í gegnum manifesta.

Þetta er svo flókið stefnumót. Það sem við höfum undirstrikað með rauðu er það sem við þurfum að einbeita okkur að. Við biðjum rekstraraðilann að búa til þyrping sem heitir demo.

Þetta eru grundvallardæmi í bili. Geymslu hefur ekki enn verið lýst, en við munum snúa aftur til geymslu aðeins síðar. Í bili munum við fylgjast með gangverki þróunar klasans.

Við bjuggum til þessa stefnuskrá. Við gefum það til rekstraraðila okkar. Hann vann, hann bjó til galdra.

Við lítum á stjórnborðið. Þrír þættir eru áhugaverðir: Pod, tvær þjónustur og StatefulSet.

Rekstraraðili hefur unnið, og við getum séð hvað nákvæmlega hann skapaði.

Hann býr til eitthvað svona. Við höfum StatefulSet, Pod, ConfigMap fyrir hverja eftirmynd, ConfigMap fyrir allan klasann. Þjónustu er krafist sem aðgangsstaðir inn í klasann.

Þjónusta er miðlæg hleðslujöfnunarþjónusta og einnig er hægt að nota hana fyrir hverja eftirmynd, fyrir hverja brot.

Grunnþyrpingin okkar lítur einhvern veginn svona út. Það er frá einum hnút.

Förum lengra og flækjum málin. Við þurfum að skera niður klasann.

Verkefni okkar eru að stækka, gangverk er að hefjast. Við viljum bæta við broti. Við fylgjumst með þróuninni. Við erum að breyta forskriftinni okkar. Við gefum til kynna að við viljum tvö skarð.

Þetta er sama skráin sem þróast á kraftmikinn hátt með vexti kerfisins. Geymsla nr, geymsla verður nánar rædd, þetta er sérstakt efni.

Við fóðrum YAML rekstraraðilanum og sjáum hvað gerist.

Rekstraraðili hugsaði og gerði eftirfarandi einingar. Við erum nú þegar með tvo pods, þrjár þjónustur og allt í einu 2 StatefulSets. Af hverju 2 StatefulSets?

Á skýringarmyndinni var þetta svona - þetta er upphafsástandið okkar, þegar við áttum einn belg.

Þetta varð svona. Hingað til er allt einfalt, það hefur verið afritað.

Og hvers vegna urðu StatefulSet tvö? Hér þurfum við að víkja og ræða spurninguna um hvernig pods er stjórnað í Kubernetes.

Það er hlutur sem heitir StatefulSet sem gerir þér kleift að búa til sett af Pods úr sniðmáti. Lykilatriðið hér er sniðmát. Og þú getur ræst marga pod með því að nota eitt sniðmát í einu StatefulSet. Og lykilsetningin hér er „margir belg fyrir eitt sniðmát“.

Og það var mikil freisting að búa til allan klasann og pakka honum í eitt StatefulSet. Það mun virka, það er ekkert vandamál með það. En það er einn fyrirvari. Ef við viljum setja saman ólíkan klasa, það er að segja úr nokkrum útgáfum af ClickHouse, þá byrja spurningar að vakna. Já, StatefulSet getur gert rúllandi uppfærslu og þar geturðu sett út nýja útgáfu, útskýrt að þú þurfir ekki að prófa meira en svo marga hnúta á sama tíma.

En ef við framreikna verkefnið og segjum að við viljum búa til algjörlega ólíkan klasa og við viljum ekki breyta úr gömlu útgáfunni í nýja með því að nota rúllandi uppfærslu, heldur viljum við einfaldlega búa til ólíkan klasa bæði hvað varðar af mismunandi útgáfum af ClickHouse og hvað varðar mismunandi geymslu. Við viljum, til dæmis, gera nokkrar eftirlíkingar á aðskildum diskum, á hægum diskum, almennt, til að byggja algjörlega upp ólíkan þyrping. Og vegna þess að StatefulSet gerir staðlaða lausn úr einu sniðmáti, þá er engin leið til að gera þetta.

Eftir nokkra umhugsun var ákveðið að við myndum gera þetta með þessum hætti. Við höfum hverja eftirmynd í sínu StatefulSet. Það eru nokkrir gallar við þessa lausn, en í reynd er þetta allt algjörlega umlukið af rekstraraðilanum. Og það eru margir kostir. Við getum byggt upp nákvæmlega þann þyrping sem við viljum, til dæmis algerlega ólíkan. Þess vegna, í klasa þar sem við erum með tvö brot með einni eftirmynd, munum við hafa 2 StatefulSets og 2 Pods einmitt vegna þess að við völdum þessa nálgun af ástæðum sem tilgreindar eru hér að ofan til að geta byggt upp misleitan klasa.

Snúum okkur aftur að hagnýtum vandamálum. Í klasanum okkar þurfum við að stilla notendur, þ.e. þú þarft að gera smá stillingar á ClickHouse í Kubernetes. Rekstraraðili veitir alla möguleika til þess.

Við getum skrifað það sem við viljum beint í YAML. Allir stillingarvalkostir eru kortlagðir beint frá þessu YAML í ClickHouse stillingar, sem síðan er dreift um þyrpinguna.

Þú getur skrifað þetta svona. Þetta er td. Lykilorðið er hægt að dulkóða. Algerlega allir ClickHouse stillingarvalkostir eru studdir. Hér er bara dæmi.

Klasastillingunni er dreift sem ConfigMap. Í reynd gerist ConfigMap uppfærslan ekki samstundis, þannig að ef þyrpingin er stór, þá tekur ferlið við að ýta á stillinguna nokkurn tíma. En allt þetta er mjög þægilegt í notkun.

Við skulum flækja verkefnið. Klasinn er að þróast. Við viljum endurtaka gögn. Það er, við erum nú þegar með tvö brot, eina eftirmynd hvor, og notendur eru stilltir. Við erum að vaxa og viljum gera afritun.

Hvað þurfum við til afritunar?

Okkur vantar ZooKeeper. Í ClickHouse er afritun byggð með ZooKeeper. ZooKeeper er þörf svo mismunandi ClickHouse eftirlíkingar séu sammála um hvaða gagnablokkir eru á hvaða ClickHouse.

ZooKeeper getur verið notað af öllum. Ef fyrirtækið er með utanaðkomandi ZooKeeper, þá er hægt að nota hann. Ef ekki, geturðu sett það upp úr geymslunni okkar. Það er til uppsetningarforrit sem gerir þetta allt auðveldara.

Og samspilsmyndin af öllu kerfinu kemur svona út. Við höfum Kubernetes sem vettvang. Það keyrir ClickHouse rekstraraðilann. Ég sá fyrir mér ZooKeeper hér. Og rekstraraðilinn hefur samskipti við bæði ClickHouse og ZooKeeper. Það er, niðurstöður samskipta.

Og allt þetta er nauðsynlegt til að ClickHouse geti endurtekið gögn með góðum árangri í k8s.

Við skulum nú líta á verkefnið sjálft, hvernig upplýsingaskrá fyrir afritun mun líta út.

Við erum að bæta tveimur köflum við stefnuskrá okkar. Hið fyrsta er hvar á að fá ZooKeeper, sem getur verið annað hvort innan Kubernetes eða utan. Þetta er bara lýsing. Og við pöntum eftirlíkingar. Þeir. við viljum tvær eftirlíkingar. Alls ættum við að hafa 4 belg við úttakið. Við munum eftir geymslu, hún kemur aftur aðeins seinna. Geymsla er sérstök saga.

Þetta var svona.

Þetta verður svona. Eftirlíkingum er bætt við. Sá 4. passaði ekki, við teljum að þeir gætu verið margir þar. Og ZooKeeper er bætt við hliðina. Áætlanir eru að verða flóknari.

Og það er kominn tími til að bæta við næsta verkefni. Við munum bæta við stöðugri geymslu.

Fyrir viðvarandi geymslu höfum við ýmsa möguleika.

Ef við erum að keyra í skýjaþjónustu, til dæmis með Amazon, Google, þá er mikil freisting að nota skýjageymslu. Það er mjög þægilegt, það er gott.

Og það er annar valkostur. Þetta er fyrir staðbundna geymslu, þegar við erum með staðbundna diska á hverjum hnút. Þessi valkostur er mun erfiðari í framkvæmd, en á sama tíma er hann afkastameiri.

Við skulum sjá hvað við höfum varðandi skýgeymslu.

Það eru kostir. Það er mjög auðvelt að stilla. Við pöntum einfaldlega frá skýjaveitunni sem vinsamlegast veitir okkur geymslu fyrir slíka og slíka getu, af slíkum og slíkum flokki. Námskeið eru skipulögð af veitendum sjálfstætt.

Og það er galli. Fyrir suma er þetta ekki mikilvægur galli. Auðvitað verða nokkur frammistöðuvandamál. Það er mjög þægilegt í notkun og áreiðanlegt, en það eru nokkrir hugsanlegir gallar á frammistöðu.

Og vegna þess ClickHouse einbeitir sér sérstaklega að framleiðni, það gæti jafnvel sagt að það kreisti út allt sem það getur, þess vegna reyna margir viðskiptavinir að kreista út hámarks framleiðni.

Og til að fá sem mest út úr því þurfum við staðbundna geymslu.

Kubernetes veitir þrjár útdrættir til að nota staðbundna geymslu í Kubernetes. Þetta:

• EmptyDir
• HostPath.
• Local

Við skulum skoða hvernig þau eru ólík og hvernig þau eru lík.

Í fyrsta lagi, í öllum þremur aðferðunum höfum við geymslu - þetta eru staðbundnir diskar sem eru staðsettir á sama líkamlega k8s hnútnum. En þeir hafa nokkurn mun.

Byrjum á því einfaldasta, þ.e. tómtDir. Hvað er þetta í reynd? Í forskrift okkar biðjum við gámakerfið (oftast Docker) að veita okkur aðgang að möppu á staðbundnum diski.

Í reynd býr Docker til bráðabirgðamöppu einhvers staðar eftir eigin slóðum og kallar það langan kjötkássa. Og veitir viðmót til að fá aðgang að því.

Hvernig mun þetta virka frammistöðulega séð? Þetta mun virka á staðbundnum diskhraða, þ.e. Þetta er fullur aðgangur að skrúfunni þinni.

En þetta mál hefur sína galla. Viðvarandi er nokkuð vafasamt í þessu máli. Í fyrsta skipti sem Docker hreyfir sig með gáma tapast Persistent. Ef Kubernetes vill færa þennan Pod á annan disk af einhverjum ástæðum munu gögnin glatast.

Þessi aðferð er góð fyrir próf, því hún sýnir nú þegar eðlilegan hraða, en fyrir eitthvað alvarlegt er þessi valkostur ekki hentugur.

Þess vegna er önnur nálgun. Þetta er hostPath. Ef þú skoðar fyrri glæruna og þessa, þá sérðu aðeins einn mun. Mappan okkar flutti frá Docker beint í Kubernetes hnútinn. Þetta er aðeins einfaldara hér. Við tilgreinum beint slóðina á staðbundnu skráarkerfinu þar sem við viljum geyma gögnin okkar.

Þessi aðferð hefur kosti. Þetta er nú þegar alvöru Viðvarandi, og klassískt fyrir það. Við munum hafa gögn skráð á diskinn á einhverju heimilisfangi.

Það eru líka ókostir. Þetta er flókið stjórnun. Kubernetes okkar gætu viljað færa Pod í annan líkamlegan hnút. Og þetta er þar sem DevOps kemur við sögu. Hann verður að útskýra rétt fyrir öllu kerfinu að þessi belg er aðeins hægt að færa á þá hnúta sem þú hefur eitthvað fest á eftir þessum slóðum, og ekki meira en einn hnút í einu. Það er frekar erfitt.

Sérstaklega í þessum tilgangi gerðum við sniðmát í símafyrirtækinu okkar til að fela allt þetta flókið. Og þú gætir einfaldlega sagt: "Ég vil hafa eitt tilvik af ClickHouse fyrir hvern líkamlegan hnút og meðfram slíkri og slíkri leið."

En við erum ekki þau einu sem þurfum á þessari þörf að halda, þannig að herrarnir frá Kubernetes sjálfum skilja líka að fólk vill hafa aðgang að líkamlegum diskum, svo þeir útvega þriðja lag.

Það er kallað staðbundið. Það er nánast enginn munur frá fyrri glærunni. Aðeins áður var nauðsynlegt að staðfesta handvirkt að við getum ekki flutt þessa fræbelg frá hnút til hnút, vegna þess að þeir verða að vera tengdir eftir einhverri leið á staðbundinn líkamlegan disk, en nú er öll þessi þekking hjúpuð í Kubernetes sjálfum. Og það reynist miklu auðveldara að stilla.

Snúum okkur aftur að hagnýtu vandamálinu okkar. Snúum okkur aftur að YAML sniðmátinu. Hér höfum við alvöru geymslu. Við erum komin aftur í það. Við stillum klassíska VolumeClaim sniðmátið eins og í k8s. Og við lýsum hvers konar geymslu við viljum.

Eftir þetta mun k8s biðja um geymslu. Mun úthluta því til okkar í StatefulSet. Og á endanum verður það til ráðstöfunar ClickHouse.

Við vorum með þetta kerfi. Viðvarandi geymslan okkar var rauð, sem virtist gefa í skyn að það þyrfti að gera það.

Og það verður grænt. Nú er ClickHouse á k8s klasakerfinu að fullu lokið. Við erum með brot, eftirmyndir, ZooKeeper, við erum með alvöru Persistent, sem er útfært á einn eða annan hátt. Áætlunin er þegar komin í fullan gang.

Við höldum áfram að lifa. Klasinn okkar er að þróast. Og Alexey reynir og gefur út nýja útgáfu af ClickHouse.

Hagnýtt verkefni kemur upp - að prófa nýju útgáfuna af ClickHouse á klasanum okkar. Og, náttúrulega, þú vilt ekki rúlla þessu öllu út; þú vilt setja nýja útgáfu í einni eftirmynd einhvers staðar í ystu horninu, og kannski ekki eina nýja útgáfu, heldur tvær í einu, því þær koma oft út.

Hvað getum við sagt um þetta?

Hér höfum við einmitt slíkt tækifæri. Þetta eru pod sniðmát. Þú getur skrifað að rekstraraðili okkar leyfir þér algjörlega að byggja upp ólíkan þyrping. Þeir. stilla, frá öllum eftirmyndum í fullt, endar með hverri persónulegri eftirmynd, hvaða útgáfu við viljum ClickHouse, hvaða útgáfu við viljum geymslu. Við getum stillt þyrpinguna að fullu með þeirri stillingu sem við þurfum.

Við skulum fara aðeins dýpra inn í. Áður en þetta, ræddum við um hvernig ClickHouse-rekstraraðili virkar í tengslum við sérstöðu ClickHouse.

Nú langar mig að segja nokkur orð um hvernig rekstraraðili virkar almennt, sem og hvernig hann hefur samskipti við K8.

Við skulum fyrst skoða samskipti við K8. Hvað gerist þegar við gerum kubectl umsókn? Hlutir okkar birtast í etcd í gegnum API.

Til dæmis, helstu Kubernetes hlutir: pod, StatefulSet, þjónusta og svo framvegis neðar á listanum.

Á sama tíma gerist ekkert líkamlegt ennþá. Þessir hlutir verða að vera að veruleika í þyrpingunni.

Í þessu skyni birtist stjórnandi. Stýringin er sérstakur k8s hluti sem getur gert þessar lýsingar að veruleika. Hann veit hvernig og hvað hann á að gera líkamlega. Hann veit hvernig á að keyra gáma, hvað þarf að stilla þar til að þjónninn virki.

Og það gerir hlutina okkar að veruleika í K8s.

En við viljum starfa ekki aðeins með belg og StatefulSets, við viljum búa til ClickHouseInstallation, þ.e. hlut af ClickHouse gerðinni, til að starfa með það sem eina heild. Enn sem komið er er enginn slíkur möguleiki fyrir hendi.

En K8s hefur eftirfarandi ágæta hlut. Við viljum að við höfum einhvers staðar eins og þessa flóknu heild þar sem þyrpingin okkar væri sett saman úr belgjum og StatefulSet.

Og hvað þarf að gera til þess? Fyrst kemur Custom Resource Definition inn í myndina. Hvað það er? Þetta er lýsing fyrir K8s, að þú munt hafa eina gagnategund í viðbót, að við viljum bæta sérsniðnu tilfangi við hólfið, StatefulSet, sem verður flókið að innan. Þetta er lýsing á uppbyggingu gagna.

Við sendum það líka þangað í gegnum kubectl application. Kubernetes tók því fegins hendi.

Og núna í geymslunni okkar hefur hluturinn í etcd tækifæri til að taka upp sérsniðna tilföng sem kallast ClickHouseInstallation.

En í bili mun ekkert meira gerast. Það er að segja, ef við búum til YAML skrána sem við skoðuðum sem lýsir brotum og eftirmyndum og segjum „kubectl gilda,“ þá mun Kubernetes samþykkja hana, setja hana í etcd og segja: „Frábært, en ég veit ekki hvað ég á að gera með því. Ég veit ekki hvernig á að viðhalda ClickHouseInstallation.

Í samræmi við það þurfum við einhvern til að hjálpa Kubernetes að þjóna nýju gagnagerðinni. Vinstra megin höfum við innfæddan Kubernetes stjórnanda sem vinnur með innfæddum gagnategundum. Og hægra megin ættum við að hafa sérsniðna stjórnandi sem getur unnið með sérsniðnar gagnagerðir.

Og á annan hátt er það kallað rekstraraðili. Ég setti það sérstaklega inn hér sem Kubernetes, því það er líka hægt að keyra það utan K8s. Oftast eru auðvitað allir rekstraraðilar framkvæmdir í Kubernetes, en ekkert kemur í veg fyrir að það standi úti, svo hér er það sérstaklega flutt út.

Og aftur á móti hefur sérsniðna stjórnandinn, einnig þekktur sem rekstraraðilinn, samskipti við Kubernetes í gegnum API. Það veit nú þegar hvernig á að hafa samskipti við API. Og hann veit nú þegar hvernig á að veruleika flókna hringrásina sem við viljum búa til úr sérsniðinni auðlind. Þetta er nákvæmlega það sem rekstraraðilinn gerir.

Hvernig virkar rekstraraðilinn? Við skulum líta á hægri hliðina til að sjá hvernig hann gerir það. Við skulum komast að því hvernig rekstraraðilinn gerir allt þetta að veruleika og hvernig frekari samskipti við K8s eiga sér stað.

Rekstraraðili er forrit. Hún er viðburðamiðuð. Rekstraraðili gerist áskrifandi að viðburðum með því að nota Kubernetes API. Kubernetes API hefur aðgangsstaði þar sem þú getur gerst áskrifandi að viðburðum. Og ef eitthvað breytist í K8s, þá sendir Kubernetes viðburði til allra, þ.e. sá sem hefur gerst áskrifandi að þessum API punkti mun fá tilkynningar.

Rekstraraðili er áskrifandi að atburðum og verður að gera einhvers konar viðbrögð. Verkefni þess er að bregðast við uppkomnum atburðum.

Viðburðir eru búnir til með ákveðnum uppfærslum. YAML skráin okkar með lýsingu á ClickHouseInstallation kemur. Hann fór til etcd gegnum kubectl umsókn. Atburður var settur af stað þar og í kjölfarið kom þessi atburður til ClickHouse-rekstraraðilans. Rekstraraðili fékk þessa lýsingu. Og hann verður að gera eitthvað. Ef uppfærsla hefur borist fyrir ClickHouseInstallation hlutinn, þá þarftu að uppfæra klasann. Og verkefni rekstraraðila er að uppfæra þyrpinguna.

Hvað er hann að gera? Fyrst þurfum við að gera aðgerðaáætlun um hvað við munum gera við þessa uppfærslu. Uppfærslur geta verið mjög litlar, þ.e. lítill í YAML framkvæmd, en getur haft í för með sér mjög miklar breytingar á klasanum. Þess vegna býr rekstraraðilinn til áætlun og heldur sig síðan við hana.

Samkvæmt þessari áætlun byrjar hann að elda þetta mannvirki inni til að veruleika belg, þjónustu, þ.e. gera það sem hans aðalverkefni er. Svona á að byggja upp ClickHouse þyrping í Kubernetes.

Nú skulum við snerta svo áhugaverðan hlut. Þetta er ábyrgðarskipting milli Kubernetes og rekstraraðilans, þ.e. hvað Kubernetes gerir, hvað rekstraraðilinn gerir og hvernig þeir hafa samskipti sín á milli.

Kubernetes ber ábyrgð á kerfishlutum, þ.e. fyrir grunnsett af hlutum sem hægt er að túlka sem kerfissvið. Kubernetes veit hvernig á að ræsa pods, hvernig á að endurræsa gáma, hvernig á að setja upp bindi, hvernig á að vinna með ConfigMap, þ.e. allt sem kalla má kerfi.

Rekstraraðilar starfa á lénum. Hver rekstraraðili er gerður fyrir sitt fagsvið. Við gerðum það fyrir ClickHouse.

Og rekstraraðilinn hefur samskipti nákvæmlega hvað varðar viðfangsefnið, eins og að bæta við eftirmynd, gera skýringarmynd, setja upp vöktun. Þetta leiðir til skiptingar.

Við skulum skoða hagnýtt dæmi um hvernig þessi ábyrgðarskipting á sér stað þegar við gerum aðgerðina til að bæta við eftirmynd.

Rekstraraðili fær verkefni - að bæta við eftirmynd. Hvað gerir rekstraraðilinn? Rekstraraðili mun reikna út að búa þurfi til nýtt StatefulSet, þar sem slíkum og slíkum sniðmátum, magnkröfu, verður að lýsa.

Hann undirbjó þetta allt og sendir það áfram til K8s. Hann segir að hann þurfi ConfigMap, StatefulSet, Volume. Kubernetes er að virka. Hann gerir grunneiningarnar sem hann starfar með.

Og þá kemur ClickHouse-rekstraraðili aftur við sögu. Hann er nú þegar með líkamlega belg sem hann getur nú þegar gert eitthvað á. Og ClickHouse-rekstraraðili vinnur aftur í lénsskilmálum. Þeir. Nánar tiltekið ClickHouse, til þess að hafa eftirmynd í klasa, verður þú fyrst að stilla gagnaskemað sem er til í þessum klasa. Og í öðru lagi þarf að taka þessa eftirmynd með í vöktunina svo hægt sé að rekja hana með skýrum hætti. Rekstraraðili stillir þetta nú þegar.

Og fyrst eftir það kemur ClickHouse sjálft til sögunnar, þ.e. önnur eining á hærra stigi. Þetta er nú þegar gagnagrunnur. Það hefur sitt eigið tilvik, aðra stillta eftirmynd sem er tilbúin til að ganga í þyrpinguna.

Það kemur í ljós að keðja framkvæmdar og skiptingu ábyrgðar þegar eftirmynd er bætt við er nokkuð löng.

Við höldum áfram verklegum verkefnum okkar. Ef þú ert nú þegar með þyrping geturðu flutt stillingarnar.

Við gerðum það þannig að þú getur límt beint í gegnum núverandi XML, sem ClickHouse skilur.

Þú getur fínstillt ClickHouse. Bara svæðisbundin dreifing er það sem ég talaði um þegar ég útskýrði hostPath, staðbundna geymslu. Svona á að gera svæðisbundna dreifingu rétt.

Næsta verklega verkefni er eftirlit.

Ef þyrpingin okkar breytist, þá þurfum við að stilla eftirlit reglulega.

Við skulum skoða skýringarmyndina. Við höfum þegar skoðað grænu örvarnar hér. Nú skulum við líta á rauðu örvarnar. Þannig viljum við fylgjast með klasanum okkar. Hvernig mælikvarðar úr ClickHouse klasanum komast inn í Prometheus og síðan í Grafana.

Hver er erfiðleikinn við eftirlit? Af hverju er þetta sett fram sem einhvers konar afrek? Erfiðleikarnir liggja í gangverkinu. Þegar við erum með einn þyrping og hann er kyrrstæður, getum við sett upp vöktun einu sinni og ekki nennt lengur.

En ef við erum með marga klasa, eða eitthvað er stöðugt að breytast, þá er ferlið kraftmikið. Og að endurstilla vöktun stöðugt er sóun á fjármagni og tíma, þ.e. jafnvel bara leti. Þetta þarf að vera sjálfvirkt. Erfiðleikarnir liggja í gangverki ferlisins. Og rekstraraðilinn gerir þetta sjálfvirkt mjög vel.

Hvernig þróaðist klasinn okkar? Í upphafi var hann þannig.

Þá var hann svona.

Á endanum varð hann svona.

Og eftirlit er gert sjálfkrafa af rekstraraðila. Einn aðgangsstaður.

Og bara við útganginn lítum við á Grafana mælaborðið til að sjá hvernig líf klasans okkar sjóðar inni.

Við the vegur, Grafana mælaborði er einnig dreift með símafyrirtækinu okkar beint í frumkóðann. Þú getur tengst og notað. DevOps okkar gaf mér þessa skjáskot.

Hvert viljum við fara næst? Þetta:

• Þróa próf sjálfvirkni. Aðalverkefnið er sjálfvirk prófun á nýjum útgáfum.
• Við viljum líka mjög gera sjálfvirkan samþættingu við ZooKeeper. Og það eru áform um að samþætta við ZooKeeper-rekstraraðila. Þeir. Rekstraraðili hefur verið skrifaður fyrir ZooKeeper og það er rökrétt að rekstraraðilarnir tveir fari að samþættast til að byggja upp þægilegri lausn.
• Við viljum gera flóknari lífsmörk.
• Ég undirstrikaði með grænu að við erum að nálgast arfleifð sniðmáta - LOKIÐ, þ.e.a.s. með næstu útgáfu af rekstraraðilanum munum við nú þegar hafa erft sniðmát. Þetta er öflugt tól sem gerir þér kleift að smíða flóknar stillingar úr hlutum.
• Og við viljum sjálfvirkni í flóknum verkefnum. Sú helsta er Re-sharding.

Tökum nokkrar milliniðurstöður.

Hvað fáum við í kjölfarið? Og er það þess virði að gera það eða ekki? Er jafnvel nauðsynlegt að reyna að draga gagnagrunninn inn í Kubernetes og nota rekstraraðilann almennt og Alitnity rekstraraðilann sérstaklega?

Við úttakið fáum við:

• Veruleg einföldun og sjálfvirkni í uppsetningu, uppsetningu og viðhaldi.
• Strax innbyggt eftirlit.
• Og tilbúið til notkunar kóðað sniðmát fyrir flóknar aðstæður. Aðgerð eins og að bæta við eftirmynd þarf ekki að gera handvirkt. Rekstraraðili gerir þetta.

Það er bara ein síðasta spurning eftir. Við erum nú þegar með gagnagrunn í Kubernetes, sýndarvæðing. Hvað með frammistöðu slíkrar lausnar, sérstaklega þar sem ClickHouse er fínstillt fyrir frammistöðu?

Svarið er allt í lagi! Ég ætla ekki að fara nánar út í það, þetta er efni í sérstakri skýrslu.

En það er svona verkefni eins og TSBS. Hvert er aðalverkefni þess? Þetta er árangurspróf gagnagrunns. Þetta er tilraun til að bera saman hlýtt og hlýtt, mjúkt og mjúkt.

Hvernig virkar hann? Eitt gagnasett er búið til. Síðan er þetta sett af gögnum keyrt á mismunandi gagnagrunnum með því að nota sama sett af prófum. Og hver gagnagrunnur leysir eitt vandamál á þann hátt sem hann veit hvernig. Og svo er hægt að bera saman niðurstöðurnar.

Það styður nú þegar mikið af gagnagrunnum. Ég hef bent á þrjár helstu. Þetta:

• TímakvarðiDB.
• InnstreymiDB.
• ClickHouse.

Einnig var gerður samanburður við aðra svipaða lausn. Samanburður við RedShift. Samanburður var gerður á Amazon. ClickHouse er líka vel á undan öllum í þessu máli.

Hvaða ályktanir er hægt að draga af því sem ég sagði?

• DB í Kubernetes er mögulegt. Sennilega er allt mögulegt, en á heildina litið lítur út fyrir að það sé mögulegt. ClickHouse í Kubernetes er örugglega mögulegt með hjálp rekstraraðila okkar.
• Rekstraraðili hjálpar til við að gera ferla sjálfvirkan og gerir lífið virkilega auðveldara.
• Frammistaða er eðlileg.
• Og okkur sýnist að þetta megi og eigi að nota.

Opinn uppspretta - vertu með!

Eins og ég sagði þegar, rekstraraðili er algjörlega opinn uppspretta vara, svo það væri mjög gott ef hámarksfjöldi fólks notaði það. Gakktu til liðs við okkur! Við bíðum eftir ykkur öllum!

Þakka ykkur öllum!

spurningar

Takk fyrir skýrsluna! Ég heiti Anton. Ég er frá SEMrush. Ég er að velta því fyrir mér hvað er að frétta af skráningu. Við heyrum um vöktun, en ekkert um skógarhögg, ef við tölum um allan klasann. Til dæmis höfum við stofnað klasa á vélbúnaði. Og við notum miðlæga skógarhögg, söfnum þeim í sameiginlega hrúgu með stöðluðum aðferðum. Og þaðan fáum við gögnin sem vekur áhuga okkar.

Góð spurning, t.d. að skrá þig inn á verkefnalista. Símafyrirtækið okkar gerir þetta ekki sjálfvirkt ennþá. Það er enn í þróun, verkefnið er enn frekar ungt. Við skiljum þörfina fyrir skógarhögg. Þetta er líka mjög mikilvægt efni. Og það er líklega ekki síður mikilvægt en eftirlit. En fyrst á listanum fyrir framkvæmd var eftirlit. Það verður skógarhögg. Auðvitað reynum við að gera sjálfvirkan alla þætti í lífi klasans. Því er svarið að í augnablikinu veit rekstraraðilinn því miður ekki hvernig á að gera þetta, en það er í áætlunum, við gerum það. Ef þú vilt vera með, vinsamlegast dragðu beiðnina.

Halló! Takk fyrir skýrsluna! Ég er með staðlaða spurningu sem tengist Persistent Volumes. Þegar við búum til stillingar með þessum rekstraraðila, hvernig ákveður stjórnandinn á hvaða hnút við höfum tiltekinn disk eða möppu tengdan? Við verðum fyrst að útskýra fyrir honum að vinsamlegast setjið ClickHouse okkar á þessum hnútum sem eru með disk?

Eftir því sem ég skil er þessi spurning framhald af staðbundinni geymslu, sérstaklega hostPath hluta hennar. Þetta er eins og að útskýra fyrir öllu kerfinu að það þurfi að ræsa podinn á slíkum og slíkum hnút, sem við erum með líkamlega tengdan disk við, sem er festur eftir slíkum og slíkum slóðum. Þetta er heill kafli sem ég kom inn á mjög yfirborðslega því svarið þar er frekar stórt.

Í stuttu máli lítur þetta svona út. Auðvitað þurfum við að útvega þetta magn. Í augnablikinu er ekkert kraftmikið ákvæði í staðbundinni geymslu, þannig að DevOps verður að klippa diskana sjálfir, þessi bindi. Og þeir verða að útskýra Kubernetes úthlutun að þú munt hafa viðvarandi bindi af slíkum og slíkum flokki, sem eru staðsettir á slíkum og slíkum hnútum. Þá þarftu að útskýra fyrir Kubernetes að belg sem krefjast slíks og slíks staðbundins geymsluflokks þurfi aðeins að beina til slíkra og slíkra hnúta með því að nota merki. Í þessum tilgangi hefur rekstraraðilinn getu til að úthluta einhvers konar merki og eitt fyrir hvert gestgjafatilvik. Og það kemur í ljós að belg verða flutt af Kubernetes til að keyra aðeins á hnútum sem uppfylla kröfurnar, merki, í einföldu máli. Stjórnendur úthluta merkimiðum og úthlutunardiska handvirkt. Og svo skalast það.

Og það er þriðji kosturinn, staðbundinn, sem hjálpar til við að gera þetta aðeins auðveldara. Eins og ég hef þegar lagt áherslu á er þetta vandað vinna við stillingar, sem á endanum hjálpar til við að ná hámarksafköstum.

Ég er með aðra spurningu sem tengist þessu. Kubernetes var hannað á þann hátt að það skiptir okkur engu máli hvort við missum hnút eða ekki. Hvað ættum við að gera í þessu tilfelli ef við höfum misst hnútinn þar sem brotið okkar hangir?

Já, Kubernetes var upphaflega staðhæft að samband okkar við fræbelginn okkar væri eins og nautgripir, en hér hjá okkur verður hver diskur eitthvað eins og gæludýr. Það er svo vandamál að við getum ekki bara hent þeim. Og þróun Kubernetes er að fara í þá átt að það er ómögulegt að meðhöndla það algjörlega heimspekilega, eins og það væri algjörlega fargað auðlind.

Nú að hagnýtri spurningu. Hvað á að gera ef þú misstir hnútinn sem diskurinn var á? Hér er verið að leysa vandann á hærra plani. Í tilfelli ClickHouse erum við með eftirlíkingar sem virka á hærra stigi, þ.e. á ClickHouse stigi.

Hver er ráðstöfunin? DevOps ber ábyrgð á því að gögn glatist ekki. Hann verður að setja upp afritun á réttan hátt og verður að tryggja að afritun sé í gangi. Eftirmyndin á ClickHouse stigi verður að hafa tvöföld gögn. Þetta er ekki vandamálið sem rekstraraðilinn leysir. Og ekki vandamálið sem Kubernetes sjálft leysir. Þetta er á ClickHouse stigi.

Hvað á að gera ef járnhnúturinn þinn dettur af? Og það kemur í ljós að þú þarft að setja upp annan, setja diskinn almennilega á hann og setja á merkimiða. Og eftir það mun það uppfylla kröfurnar um að Kubernetes geti sett af stað tilviksbelg á það. Kubernetes mun ræsa það. Fjöldi fræbelgja þinna er ekki nægur til að mæta tilgreindum fjölda. Það mun fara í gegnum hringrásina sem ég sýndi. Og á hæsta stigi mun ClickHouse skilja að við höfum slegið inn eftirmynd, hún er enn tóm og við þurfum að byrja að flytja gögn yfir á hana. Þeir. Þetta ferli er ekki enn vel sjálfvirkt.

Takk fyrir skýrsluna! Þegar alls kyns viðbjóðslegir hlutir gerast, rekstarstjórinn hrynur og endurræsir sig, og á því augnabliki koma atburðir, höndlarðu þetta einhvern veginn?

Hvað gerist ef stjórnandinn hrundi og endurræsti sig, ekki satt?

Já. Og á þeirri stundu komu atburðir.

Verkefnið um hvað á að gera í þessu tilfelli er að hluta til skipt milli símafyrirtækisins og Kubernetes. Kubernetes hefur getu til að endurspila atburð sem hefur átt sér stað. Hann endurspilar. Og verkefni stjórnandans er að ganga úr skugga um að þegar atburðaskráin er endurspiluð á honum, þá séu þessir atburðir óstyrkir. Og svo að endurtekin viðburður af sama atburði brjóti ekki kerfi okkar. Og rekstraraðili okkar tekst á við þetta verkefni.

Halló! Takk fyrir skýrsluna! Dmitry Zavyalov, fyrirtæki Smedova. Eru áform um að bæta möguleikanum til að stilla með haproxy við rekstraraðilann? Ég hefði áhuga á einhverju öðru jafnvægistæki fyrir utan það venjulega, svo að það sé snjallt og skilji að ClickHouse sé í raun til staðar.

Ertu að tala um Ingress?

Já, skiptu Ingress út fyrir haproxy. Í haproxy er hægt að tilgreina staðfræði klasans þar sem hann hefur eftirmyndir.

Við höfum ekki hugsað út í það ennþá. Ef þú þarfnast þess og getur útskýrt hvers vegna þess er þörf, þá verður hægt að útfæra það, sérstaklega ef þú vilt taka þátt. Við munum vera fús til að íhuga möguleikann. Stutta svarið er nei, við höfum ekki slíka virkni eins og er. Takk fyrir ábendinguna, við skoðum þetta mál. Og ef þú útskýrir líka notkunartilvikið og hvers vegna það er nauðsynlegt í reynd, til dæmis að búa til mál á GitHub, þá verður það frábært.

Hefur þegar.

Fínt. Við erum opin fyrir öllum tillögum. Og haproxy er bætt við verkefnalistann. Verkefnalistinn er að stækka, ekki minnkandi ennþá. En þetta er gott, það þýðir að varan er eftirsótt.

Heimild: www.habr.com