Mae'r adroddiad yn canolbwyntio ar faterion ymarferol datblygu gweithredwr yn Kubernetes, dylunio ei bensaernïaeth a'i egwyddorion gweithredu sylfaenol.
Yn rhan gyntaf yr adroddiad byddwn yn ystyried:
- beth yw gweithredwr yn Kubernetes a pham mae ei angen;
- sut yn union y mae'r gweithredwr yn symleiddio'r broses o reoli systemau cymhleth;
- yr hyn y gall ac na all y gweithredwr ei wneud.
Nesaf, gadewch i ni symud ymlaen i drafod strwythur mewnol y gweithredwr. Gadewch i ni edrych ar bensaernïaeth a gweithrediad y gweithredwr gam wrth gam. Gadewch i ni edrych arno'n fanwl:
- rhyngweithio rhwng y gweithredwr a Kubernetes;
- pa swyddogaethau y mae'r gweithredwr yn eu cyflawni a pha swyddogaethau y mae'n eu dirprwyo i Kubernetes.
Gadewch i ni edrych ar reoli shards a replicas cronfa ddata yn Kubernetes.
Nesaf, byddwn yn trafod materion storio data:
- sut i weithio gyda Storio Parhaus o safbwynt gweithredwr;
- peryglon defnyddio Storio Lleol.
Yn rhan olaf yr adroddiad, byddwn yn ystyried enghreifftiau ymarferol o gymhwyso gydag Amazon neu Google Cloud Service. Mae'r adroddiad yn seiliedig ar yr enghraifft o ddatblygiad a phrofiad gweithredu gweithredwr ar gyfer ClickHouse.
Fideo:
Fy enw i yw Vladislav Klimenko. Heddiw roeddwn i eisiau siarad am ein profiad o ddatblygu a gweithredu gweithredwr, ac mae hwn yn weithredwr arbenigol ar gyfer rheoli clystyrau cronfa ddata. Er enghraifft i reoli clwstwr ClickHouse.
Pam mae gennym ni'r cyfle i siarad am y gweithredwr a ClickHouse?
- Rydym yn cefnogi ac yn datblygu ClickHouse.
- Ar hyn o bryd, rydym yn ceisio gwneud ein cyfraniad yn araf at ddatblygiad ClickHouse. Ac rydym yn ail ar ôl Yandex o ran nifer y newidiadau a wnaed i ClickHouse.
- Rydym yn ceisio creu prosiectau ychwanegol ar gyfer ecosystem ClickHouse.
Hoffwn ddweud wrthych am un o’r prosiectau hyn. Mae hyn yn ymwneud â gweithredwr ClickHouse ar gyfer Kubernetes.
Yn fy adroddiad hoffwn sôn am ddau bwnc:
- Y pwnc cyntaf yw sut mae ein gweithredwr rheoli cronfa ddata ClickHouse yn gweithio yn Kubernetes.
- Yr ail bwnc yw sut mae unrhyw weithredwr yn gweithio, h.y. sut mae'n rhyngweithio â Kubernetes.
Fodd bynnag, bydd y ddau gwestiwn hyn yn croestorri drwy gydol fy adroddiad.
Pwy fyddai â diddordeb mewn gwrando ar yr hyn rydw i'n ceisio'i ddweud?
- Bydd o'r diddordeb mwyaf i'r rhai sy'n gweithredu gweithredwyr.
- Neu i'r rhai sydd am wneud rhai eu hunain er mwyn deall sut mae'n gweithio'n fewnol, sut mae'r gweithredwr yn rhyngweithio â Kubernetes, a pha beryglon a all ymddangos.
Er mwyn deall orau'r hyn y byddwn yn ei drafod heddiw, mae'n syniad da gwybod sut mae Kubernetes yn gweithio a chael rhywfaint o hyfforddiant cwmwl sylfaenol.
Beth yw ClickHouse? Cronfa ddata golofnog yw hon gyda nodweddion penodol ar gyfer prosesu ymholiadau dadansoddol ar-lein. Ac mae'n ffynhonnell gwbl agored.
Ac mae'n bwysig i ni wybod dim ond dau beth. Mae angen i chi wybod mai cronfa ddata yw hon, felly bydd yr hyn a ddywedaf wrthych yn berthnasol i bron unrhyw gronfa ddata. Ac mae'r ffaith bod graddfeydd ClickHouse DBMS yn dda iawn, yn rhoi graddadwyedd llinol bron. Ac felly, mae cyflwr y clwstwr yn gyflwr naturiol i ClickHouse. Ac mae gennym ddiddordeb mawr mewn trafod sut i wasanaethu clwstwr ClickHouse yn Kubernetes.
Pam fod ei angen yno? Pam na allwn ni barhau i'w weithredu ein hunain? Ac mae'r atebion yn rhannol dechnegol ac yn rhannol sefydliadol.
- Yn ymarferol, rydym yn dod ar draws sefyllfa fwyfwy lle mae bron pob cydran eisoes yn Kubernetes mewn cwmnïau mawr. Mae cronfeydd data yn aros y tu allan.
- Ac mae'r cwestiwn yn cael ei ofyn fwyfwy: “A ellir gosod hwn y tu mewn?” Felly, mae cwmnïau mawr yn ceisio sicrhau'r uno rheolaeth mwyaf posibl er mwyn gallu rheoli eu warysau data yn gyflym.
- Ac mae hyn yn arbennig o helpu os oes angen y cyfle mwyaf arnoch i ailadrodd yr un peth mewn lle newydd, h.y. y hygludedd mwyaf.
Pa mor hawdd neu anodd yw hi? Wrth gwrs, gellir gwneud hyn â llaw. Ond nid yw mor syml, oherwydd mae gennym ni'r cymhlethdod ychwanegol o reoli Kubernetes ei hun, ond ar yr un pryd mae manylion ClickHouse wedi'u harosod. Ac mae cydgasgliad o'r fath yn arwain.
Ac at ei gilydd mae hyn yn rhoi set eithaf mawr o dechnolegau, sy'n dod yn eithaf anodd eu rheoli, oherwydd mae Kubernetes yn dod â'i faterion bob dydd ei hun i weithrediad, ac mae ClickHouse yn dod â'i faterion ei hun i weithrediad bob dydd. Yn enwedig os oes gennym ni sawl ClickHouses, a bod angen i ni wneud rhywbeth gyda nhw yn gyson.
Gyda chyfluniad deinamig, mae gan ClickHouse nifer eithaf mawr o faterion sy'n creu llwyth cyson ar DevOps:
- Pan fyddwn ni eisiau newid rhywbeth yn ClickHouse, er enghraifft, ychwanegu replica neu shard, yna mae angen i ni reoli'r ffurfweddiad.
- Yna newidiwch y sgema data, oherwydd mae gan ClickHouse ddull darnio penodol. Yno mae angen i chi osod y diagram data, gosod y ffurfweddiadau.
- Mae angen i chi sefydlu monitro.
- Casglu boncyffion ar gyfer darnau newydd, ar gyfer copïau newydd.
- Cymerwch ofal o adferiad.
- Ac ailgychwyn.
Mae'r rhain yn dasgau arferol yr hoffwn eu gwneud yn haws i'w defnyddio.
Mae Kubernetes ei hun yn helpu'n dda ar waith, ond ar bethau system sylfaenol.
Mae Kubernetes yn dda am hwyluso ac awtomeiddio pethau fel:
- Adferiad.
- Ail-ddechrau.
- Rheoli system storio.
Mae hynny'n dda, dyna'r cyfeiriad cywir, ond mae'n gwbl ddi-glem ynglŷn â sut i weithredu clwstwr cronfa ddata.
Rydyn ni eisiau mwy, rydyn ni am i'r gronfa ddata gyfan weithio yn Kubernetes.
Hoffwn gael rhywbeth fel un botwm coch hud mawr rydych chi'n ei wasgu a chlwstwr gyda thasgau bob dydd y mae angen eu datrys yn cael ei ddefnyddio a'i gynnal trwy gydol ei gylch bywyd cyfan. Clwstwr ClickHouse yn Kubernetes.
Ac fe wnaethon ni geisio gwneud datrysiad a fyddai'n helpu i wneud y gwaith yn haws. Mae hwn yn weithredwr ClickHouse ar gyfer Kubernetes o Altinity.
Mae gweithredwr yn rhaglen a’i phrif dasg yw rheoli rhaglenni eraill, h.y. mae’n rheolwr.
Ac mae'n cynnwys patrymau ymddygiad. Gallwch chi alw hyn yn wybodaeth wedi'i chodeiddio am y maes pwnc.
A'i brif dasg yw gwneud bywyd DevOps yn haws a lleihau microreoli, fel ei fod ef (DevOps) eisoes yn meddwl mewn termau lefel uchel, h.y., fel nad yw ef (DevOps) yn cymryd rhan mewn microreoli, fel nad yw'n ffurfweddu yr holl fanylion â llaw.
A dim ond y gweithredwr yw cynorthwyydd robotig sy'n delio â microdasgau ac yn helpu DevOps.
Pam mae angen gweithredwr arnoch chi? Mae’n perfformio’n arbennig o dda mewn dau faes:
- Pan nad oes gan yr arbenigwr sy'n delio â ClickHouse ddigon o brofiad, ond mae angen iddo weithredu ClickHouse eisoes, mae'r gweithredwr yn hwyluso'r llawdriniaeth ac yn caniatáu ichi weithredu clwstwr ClickHouse gyda chyfluniad eithaf cymhleth, heb fynd i ormod o fanylion am sut mae'r cyfan yn gweithio tu mewn. Rydych chi'n rhoi tasgau lefel uchel iddo, ac mae'n gweithio.
- A'r ail dasg y mae'n perfformio orau ynddi yw pan fydd angen awtomeiddio nifer fawr o dasgau nodweddiadol. Yn dileu microdasgau o weinyddwyr system.
Mae angen hyn fwyaf naill ai gan y rhai sydd newydd ddechrau eu taith, neu gan y rhai sydd angen gwneud llawer o awtomeiddio.
Sut mae'r dull gweithredu sy'n seiliedig ar weithredwyr yn wahanol i systemau eraill? Mae Helm. Mae hefyd yn helpu i osod ClickHouse; gallwch chi dynnu siartiau helm, a fydd hyd yn oed yn gosod clwstwr ClickHouse cyfan. Beth felly yw'r gwahaniaeth rhwng y gweithredwr a'r un peth, er enghraifft, Helm?
Y prif wahaniaeth sylfaenol yw mai Helm yw rheoli pecynnau ac mae Gweithredwr yn mynd gam ymhellach. Mae hyn yn gefnogaeth ar gyfer y cylch bywyd cyfan. Nid gosod yn unig yw hwn, mae'r rhain yn dasgau bob dydd sy'n cynnwys graddio, rhwygo, hy popeth sydd angen ei wneud yn ystod y cylch bywyd (os oes angen, yna dileu hefyd) - mae hyn i gyd yn cael ei benderfynu gan y gweithredwr. Mae'n ceisio awtomeiddio a chynnal y cylch bywyd meddalwedd cyfan. Dyma ei wahaniaeth sylfaenol oddi wrth atebion eraill a gyflwynir.
Dyna oedd y rhan ragarweiniol, gadewch i ni symud ymlaen.
Sut ydyn ni'n adeiladu ein gweithredwr? Rydym yn ceisio mynd at y mater i reoli clwstwr ClickHouse fel un adnodd.
Yma mae gennym ddata mewnbwn ar ochr chwith y llun. Dyma YAML gyda manyleb clwstwr, sy'n cael ei drosglwyddo i Kubernetes yn y ffordd glasurol trwy kubectl. Yno mae ein gweithredwr yn ei godi ac yn gwneud ei hud. Ac wrth yr allbwn cawn y cynllun canlynol. Mae hwn yn weithrediad ClickHouse yn Kubernetes.
Ac yna byddwn yn edrych yn araf ar sut yn union y mae'r gweithredwr yn gweithio, pa dasgau nodweddiadol y gellir eu datrys. Byddwn ond yn ystyried tasgau nodweddiadol oherwydd bod gennym amser cyfyngedig. Ac ni fydd popeth y gall y gweithredwr benderfynu arno yn cael ei drafod.
Gadewch i ni ddechrau o ymarfer. Mae ein prosiect yn ffynhonnell gwbl agored, felly gallwch chi weld sut mae'n gweithio ar GitHub. A gallwch symud ymlaen o'r ystyriaethau, os ydych chi am ei lansio yn unig, yna gallwch chi ddechrau gyda'r Canllaw Cychwyn Cyflym.
Os ydych am ddeall yn fanwl, yna rydym yn ceisio cynnal y ddogfennaeth mewn ffurf fwy neu lai gweddus.
Gadewch i ni ddechrau gyda phroblem ymarferol. Y dasg gyntaf, lle mae pob un ohonom am ddechrau, yw rhedeg yr enghraifft gyntaf rywsut. Sut alla i lansio ClickHouse gan ddefnyddio'r gweithredwr, hyd yn oed os nad wyf yn gwybod mewn gwirionedd sut mae'n gweithio? Rydym yn ysgrifennu maniffesto, oherwydd... Mae pob cyfathrebu â k8s yn gyfathrebu trwy faniffestau.
Mae hwn yn faniffesto mor gymhleth. Yr hyn yr ydym wedi’i amlygu mewn coch yw’r hyn y mae angen inni ganolbwyntio arno. Gofynnwn i'r gweithredwr greu demo o'r enw clwstwr.
Mae'r rhain yn enghreifftiau sylfaenol ar hyn o bryd. Nid yw storio wedi'i ddisgrifio eto, ond byddwn yn dychwelyd i storio ychydig yn ddiweddarach. Am y tro, byddwn yn arsylwi ar ddeinameg datblygiad y clwstwr.
Fe wnaethon ni greu’r maniffesto hwn. Rydyn ni'n ei fwydo i'n gweithredwr. Gweithiodd, gwnaeth hud.
Edrychwn ar y consol. Mae tair cydran o ddiddordeb: Pod, dau Wasanaeth, a Set Wladwriaethol.
Mae'r gweithredwr wedi gweithio, a gallwn weld beth yn union a greodd.
Mae'n creu rhywbeth fel hyn. Mae gennym StatefulSet, Pod, ConfigMap ar gyfer pob replica, ConfigMap ar gyfer y clwstwr cyfan. Mae angen gwasanaethau fel pwyntiau mynediad i'r clwstwr.
Gwasanaethau yw'r Gwasanaeth Cydbwyso Llwyth canolog a gellir eu defnyddio hefyd ar gyfer pob replica, ar gyfer pob darn.
Mae ein clwstwr sylfaenol yn edrych rhywbeth fel hyn. Mae o un nod sengl.
Gadewch i ni fynd ymhellach a chymhlethu pethau. Mae angen inni ddarnio’r clwstwr.
Mae ein tasgau'n tyfu, mae dynameg yn dechrau. Rydyn ni eisiau ychwanegu darn. Rydym yn dilyn y datblygiad. Rydym yn newid ein manyleb. Rydym yn nodi ein bod eisiau dau ddarn.
Dyma'r un ffeil sy'n datblygu'n ddeinamig gyda thwf y system. Nac oes storio, bydd storio yn cael ei drafod ymhellach, mae hwn yn bwnc ar wahân.
Rydyn ni'n bwydo gweithredwr YAML ac yn gweld beth sy'n digwydd.
Meddyliodd y gweithredwr a gwnaeth yr endidau canlynol. Mae gennym eisoes ddau Goden, tri Gwasanaeth ac, yn sydyn, 2 Set Statud. Pam 2 Set Wladwriaethol?
Ar y diagram yr oedd fel hyn - dyma ein cyflwr cychwynnol, pan oedd gennym un cod.
Daeth fel hyn. Hyd yn hyn mae popeth yn syml, mae wedi'i ddyblygu.
A pham y daeth dwy Set Wladwriaethol? Yma mae angen i ni grwydro a thrafod y cwestiwn o sut mae Pods yn cael eu rheoli yn Kubernetes.
Mae yna wrthrych o'r enw StatefulSet sy'n eich galluogi i greu set o Podiau o dempled. Y ffactor allweddol yma yw Templed. A gallwch chi lansio llawer o Pods gan ddefnyddio un templed mewn un StatefulSet. A’r ymadrodd allweddol yma yw “llawer o Godiadau ar gyfer un templed.”
A bu temtasiwn fawr i wneud y clwstwr cyfan, gan ei bacio i mewn i un StatefulSet. Bydd yn gweithio, nid oes problem ag ef. Ond mae un cafeat. Os ydym am gydosod clwstwr heterogenaidd, hynny yw, o sawl fersiwn o ClickHouse, yna mae cwestiynau'n dechrau codi. Oes, gall StatefulSet wneud diweddariad treigl, ac yno gallwch chi gyflwyno fersiwn newydd, eglurwch nad oes angen i chi roi cynnig ar fwy na chymaint o nodau ar yr un pryd.
Ond os ydym yn allosod y dasg ac yn dweud ein bod am wneud clwstwr hollol heterogenaidd ac nad ydym am newid o'r hen fersiwn i un newydd gan ddefnyddio diweddariad treigl, ond yn syml rydym am greu clwstwr heterogenaidd yn nhermau o wahanol fersiynau o ClickHouse ac o ran storio gwahanol. Rydym am, er enghraifft, wneud rhai atgynyrchiadau ar ddisgiau ar wahân, ar rai araf, yn gyffredinol, i adeiladu clwstwr heterogenaidd yn llwyr. Ac oherwydd y ffaith bod StatefulSet yn gwneud datrysiad safonol o un templed, nid oes unrhyw ffordd i wneud hyn.
Wedi peth meddwl, penderfynwyd y byddem yn ei wneud fel hyn. Mae gennym bob copi yn ei Set Wladwriaethol ei hun. Mae yna rai anfanteision i'r datrysiad hwn, ond yn ymarferol mae'r cyfan wedi'i grynhoi'n llwyr gan y gweithredwr. Ac mae yna lawer o fanteision. Gallwn adeiladu’r union glwstwr yr ydym ei eisiau, er enghraifft, un hollol heterogenaidd. Felly, mewn clwstwr lle mae gennym ddau ddarn gydag un atgynhyrchiad, bydd gennym 2 StatefulSets a 2 Pod yn union oherwydd inni ddewis y dull hwn am y rhesymau a nodir uchod i allu adeiladu clwstwr heterogenaidd.
Gadewch i ni ddychwelyd at broblemau ymarferol. Yn ein clwstwr mae angen i ni ffurfweddu defnyddwyr, h.y. mae angen i chi wneud rhywfaint o gyfluniad o ClickHouse yn Kubernetes. Mae'r gweithredwr yn darparu'r holl bosibiliadau ar gyfer hyn.
Gallwn ysgrifennu'r hyn yr ydym ei eisiau yn uniongyrchol yn YAML. Mae'r holl opsiynau cyfluniad yn cael eu mapio'n uniongyrchol o'r YAML hwn i ffurfweddau ClickHouse, sydd wedyn yn cael eu dosbarthu ledled y clwstwr.
Gallwch ei ysgrifennu fel hyn. Mae hyn er enghraifft. Gellir amgryptio'r cyfrinair. Cefnogir holl opsiynau cyfluniad ClickHouse yn llwyr. Dyma enghraifft yn unig.
Mae ffurfweddiad y clwstwr yn cael ei ddosbarthu fel ConfigMap. Yn ymarferol, nid yw'r diweddariad ConfigMap yn digwydd ar unwaith, felly os yw'r clwstwr yn fawr, yna mae'r broses o wthio'r cyfluniad yn cymryd peth amser. Ond mae hyn i gyd yn gyfleus iawn i'w ddefnyddio.
Gadewch i ni gymhlethu'r dasg. Mae’r clwstwr yn datblygu. Rydym am ddyblygu data. Hynny yw, mae gennym ni ddau ddarn yn barod, un atgynhyrchiad yr un, ac mae defnyddwyr wedi'u ffurfweddu. Rydym yn tyfu ac yn awyddus i wneud dyblygu.
Beth sydd ei angen arnom ar gyfer atgynhyrchu?
Mae angen ZooKeeper arnom. Yn ClickHouse, caiff atgynhyrchu ei adeiladu gan ddefnyddio ZooKeeper. Mae angen ZooKeeper fel bod gan wahanol atgynyrchiadau ClickHouse gonsensws ynghylch pa flociau data sydd ar ba ClickHouse.
Gall unrhyw un ddefnyddio ZooKeeper. Os oes gan y fenter ZooKeeper allanol, yna gellir ei ddefnyddio. Os na, gallwch ei osod o'n cadwrfa. Mae yna osodwr sy'n gwneud hyn i gyd yn haws.
Ac mae diagram rhyngweithio'r system gyfan yn troi allan fel hyn. Mae gennym Kubernetes fel platfform. Mae'n gweithredu gweithredwr ClickHouse. Fe wnes i dynnu llun ZooKeeper yma. Ac mae'r gweithredwr yn rhyngweithio â ClickHouse a ZooKeeper. Hynny yw, canlyniadau rhyngweithio.
Ac mae hyn i gyd yn angenrheidiol er mwyn i ClickHouse efelychu data yn k8s yn llwyddiannus.
Edrychwn yn awr ar y dasg ei hun, sut olwg fydd ar y maniffest ar gyfer atgynhyrchu.
Rydym yn ychwanegu dwy adran at ein maniffest. Y cyntaf yw ble i gael ZooKeeper, a all fod naill ai y tu mewn i Kubernetes neu'n allanol. Disgrifiad yn unig yw hwn. Ac rydym yn archebu replicas. Y rhai. rydym eisiau dau atgynhyrchiad. Yn gyfan gwbl, dylem gael 4 pod wrth yr allbwn. Rydyn ni'n cofio am storio, bydd yn dod yn ôl ychydig yn ddiweddarach. Stori ar wahân yw storio.
Yr oedd fel hyn.
Mae'n dod fel hyn. Ychwanegir atgynyrchiadau. Nid oedd y 4ydd un yn ffitio, credwn y gallai fod llawer o honynt yno. Ac mae ZooKeeper yn cael ei ychwanegu at yr ochr. Mae'r cynlluniau'n dod yn fwy cymhleth.
Ac mae'n bryd ychwanegu'r dasg nesaf. Byddwn yn ychwanegu Storio Parhaus.
Ar gyfer Storio Parhaus mae gennym amrywiaeth o opsiynau.
Os ydym yn rhedeg mewn darparwr cwmwl, er enghraifft, gan ddefnyddio Amazon, Google, yna mae yna demtasiwn mawr i ddefnyddio storfa cwmwl. Mae'n gyfleus iawn, mae'n dda.
Ac mae ail opsiwn. Mae hyn ar gyfer storio lleol, pan fydd gennym ddisgiau lleol ar bob nod. Mae'r opsiwn hwn yn llawer anoddach i'w weithredu, ond ar yr un pryd mae'n fwy cynhyrchiol.
Gadewch i ni weld beth sydd gennym o ran storio cwmwl.
Mae yna fanteision. Mae'n hawdd iawn ei ffurfweddu. Yn syml, rydyn ni'n archebu gan y darparwr cwmwl sy'n rhoi storfa o'r fath ac o'r fath i ni, o'r fath ac o'r fath ddosbarth. Trefnir dosbarthiadau yn annibynnol gan ddarparwyr.
Ac mae anfantais. I rai, mae hyn yn anfantais nad yw'n hollbwysig. Wrth gwrs, bydd rhai problemau perfformiad. Mae'n gyfleus iawn i'w ddefnyddio ac yn ddibynadwy, ond mae yna rai anfanteision perfformiad posibl.
Ac oherwydd Mae ClickHouse yn canolbwyntio'n benodol ar gynhyrchiant, efallai y bydd rhywun hyd yn oed yn dweud ei fod yn gwasgu popeth o fewn ei allu, a dyna pam mae llawer o gleientiaid yn ceisio gwasgu'r cynhyrchiant mwyaf allan.
Ac i gael y gorau ohono, mae angen storfa leol.
Mae Kubernetes yn darparu tri thyniad ar gyfer defnyddio storfa leol yn Kubernetes. hwn:
- GwagDir
- Llwybr Gwesteiwr.
- Lleol
Gadewch i ni edrych ar sut maen nhw'n wahanol a sut maen nhw'n debyg.
Yn gyntaf, mae gennym ni storfa ym mhob un o'r tri dull - disgiau lleol yw'r rhain sydd wedi'u lleoli ar yr un nod k8s corfforol. Ond mae ganddyn nhw rai gwahaniaethau.
Gadewch i ni ddechrau gyda'r un symlaf, h.y. emptyDir. Beth yw hyn yn ymarferol? Yn ein manyleb, gofynnwn i'r system cynhwysyddion (Docker amlaf) roi mynediad i ni i ffolder ar y ddisg leol.
Yn ymarferol, mae Docker yn creu ffolder dros dro yn rhywle ar hyd ei lwybrau ei hun ac yn ei alw'n stwnsh hir. Ac yn darparu rhyngwyneb i gael mynediad iddo.
Sut bydd hyn yn gweithio o ran perfformiad? Bydd hyn yn gweithio ar gyflymder disg lleol, h.y. Dyma fynediad llawn i'ch sgriw.
Ond mae gan yr achos hwn ei anfantais. Mae dyfal yn bur amheus yn y mater hwn. Y tro cyntaf i Docker symud gyda chynwysyddion, mae Persistent yn cael ei golli. Os yw Kubernetes eisiau symud y Pod hwn i ddisg arall am ryw reswm, bydd y data'n cael ei golli.
Mae'r dull hwn yn dda ar gyfer profion, oherwydd mae eisoes yn dangos cyflymder arferol, ond ar gyfer rhywbeth difrifol nid yw'r opsiwn hwn yn addas.
Felly mae ail ddull. Dyma hostPath. Os edrychwch ar y sleid flaenorol a'r un hwn, dim ond un gwahaniaeth y gallwch ei weld. Symudodd ein ffolder o Docker yn uniongyrchol i nod Kubernetes. Mae ychydig yn symlach yma. Rydym yn nodi'n uniongyrchol y llwybr ar y system ffeiliau leol lle hoffem storio ein data.
Mae gan y dull hwn fanteision. Mae hwn eisoes yn Barhaol go iawn, ac yn un clasurol ar hynny. Bydd gennym ddata wedi'i gofnodi ar y ddisg mewn rhyw gyfeiriad.
Mae yna anfanteision hefyd. Dyma gymhlethdod y rheolaeth. Efallai y bydd ein Kubernetes eisiau symud y Pod i nod corfforol arall. A dyma lle mae DevOps yn dod i rym. Rhaid iddo egluro'n gywir i'r system gyfan mai dim ond i'r nodau hynny y mae gennych rywbeth wedi'i osod arnynt ar hyd y llwybrau hyn y gellir symud y codennau hyn, a dim mwy nag un nod ar y tro. Mae'n eithaf anodd.
Yn enwedig at y dibenion hyn, gwnaethom dempledi yn ein gweithredwr er mwyn cuddio'r holl gymhlethdod hwn. A gallech ddweud yn syml: “Rwyf am gael un enghraifft o ClickHouse ar gyfer pob nod corfforol ac ar hyd llwybr o'r fath ac o'r fath.”
Ond nid ni yw'r unig rai sydd angen yr angen hwn, felly mae'r dynion o Kubernetes ei hun hefyd yn deall bod pobl eisiau cael mynediad at ddisgiau corfforol, felly maen nhw'n darparu trydydd haen.
Fe'i gelwir yn lleol. Nid oes bron unrhyw wahaniaeth o'r sleid flaenorol. Dim ond cyn bod angen cadarnhau â llaw na allwn drosglwyddo'r codennau hyn o nod i nod, oherwydd mae'n rhaid eu cysylltu ar hyd rhyw lwybr i ddisg gorfforol leol, ond nawr mae'r holl wybodaeth hon wedi'i hamgáu yn Kubernetes ei hun. Ac mae'n troi allan i fod yn llawer haws i'w ffurfweddu.
Gadewch i ni ddychwelyd at ein problem ymarferol. Gadewch i ni ddychwelyd i'r templed YAML. Yma mae gennym storfa go iawn. Rydyn ni'n ôl arno. Rydym yn gosod y templed VolumeClaim clasurol fel yn k8s. Ac rydyn ni'n disgrifio pa fath o storfa rydyn ni ei eisiau.
Ar ôl hyn, bydd k8s yn gofyn am storio. Bydd yn ei ddyrannu i ni yn y StatefulSet. Ac yn y diwedd bydd ar gael i ClickHouse.
Cawsom y cynllun hwn. Roedd ein Storio Parhaus yn goch, a oedd fel pe bai'n awgrymu bod angen ei wneud.
Ac mae'n troi'n wyrdd. Nawr mae cynllun clwstwr ClickHouse on k8s wedi'i gwblhau'n llwyr. Mae gennym ddarnau, atgynyrchiadau, ZooKeeper, mae gennym Barhaus go iawn, sy'n cael ei weithredu mewn un ffordd neu'r llall. Mae'r cynllun eisoes yn gwbl weithredol.
Rydym yn parhau i fyw. Mae ein clwstwr yn datblygu. Ac mae Alexey yn ceisio, ac yn rhyddhau fersiwn newydd o ClickHouse.
Mae tasg ymarferol yn codi - i brofi'r fersiwn newydd o ClickHouse ar ein clwstwr. Ac, yn naturiol, nid ydych chi eisiau cyflwyno'r cyfan; rydych chi am roi fersiwn newydd mewn un replica yn rhywle yn y gornel bellaf, ac efallai nid un fersiwn newydd, ond dwy ar unwaith, oherwydd maen nhw'n dod allan yn aml.
Beth allwn ni ei ddweud am hyn?
Yma mae gennym gyfle o'r fath. Templedi pod yw'r rhain. Gallwch ysgrifennu bod ein gweithredwr yn llwyr yn caniatáu ichi adeiladu clwstwr heterogenaidd. Y rhai. ffurfweddu, gan ddechrau o bob replicas mewn criw, gan orffen gyda phob replica personol, pa fersiwn yr ydym am ClickHouse, pa fersiwn yr ydym am ei storio. Gallwn ffurfweddu'r clwstwr yn llawn gyda'r cyfluniad sydd ei angen arnom.
Gadewch i ni fynd ychydig yn ddyfnach y tu mewn. Cyn hyn, buom yn siarad am sut mae gweithredwr ClickHouse yn gweithio mewn perthynas â manylion ClickHouse.
Nawr hoffwn ddweud ychydig eiriau am sut mae unrhyw weithredwr yn gweithio'n gyffredinol, yn ogystal â sut mae'n rhyngweithio â K8s.
Gadewch i ni edrych ar ryngweithio â'r K8s yn gyntaf. Beth sy'n digwydd pan fyddwn yn gwneud cais kubectl? Mae ein gwrthrychau yn ymddangos mewn ac ati trwy'r API.
Er enghraifft, gwrthrychau Kubernetes sylfaenol: pod, StatefulSet, gwasanaeth, ac yn y blaen i lawr y rhestr.
Ar yr un pryd, nid oes dim byd corfforol yn digwydd eto. Rhaid gwireddu'r gwrthrychau hyn yn y clwstwr.
At y diben hwn, mae rheolydd yn ymddangos. Mae'r rheolydd yn gydran k8s arbennig a all wireddu'r disgrifiadau hyn. Mae'n gwybod sut a beth i'w wneud yn gorfforol. Mae'n gwybod sut i redeg cynwysyddion, beth sydd angen ei ffurfweddu yno er mwyn i'r gweinydd weithio.
Ac mae'n gwireddu ein gwrthrychau yn K8s.
Ond rydym am weithredu nid yn unig gyda chodiau a StatefulSets, rydym am greu ClickHouseInstallation, h.y. gwrthrych o'r math ClickHouse, er mwyn gweithredu ag ef fel un cyfanwaith. Hyd yn hyn nid oes posibilrwydd o'r fath.
Ond mae gan K8s y peth braf canlynol. Rydym am i ni gael rhywle fel yr endid cymhleth hwn lle byddai ein clwstwr yn cael ei ymgynnull o godennau a StatefulSet.
A beth sydd angen ei wneud ar gyfer hyn? Yn gyntaf, mae Diffiniad Adnoddau Personol yn dod i mewn i'r llun. Beth yw e? Mae hwn yn ddisgrifiad ar gyfer K8s, y bydd gennych un math arall o ddata, yr ydym am ychwanegu adnodd wedi'i deilwra i'r pod, StatefulSet, a fydd yn gymhleth y tu mewn. Mae hwn yn ddisgrifiad o'r strwythur data.
Rydym hefyd yn ei anfon yno trwy kubectl apply. Cymerodd Kubernetes ef yn hapus.
Ac yn awr yn ein storfa, mae'r gwrthrych yn ac ati yn cael y cyfle i recordio adnodd arfer o'r enw ClickHouseInstallation.
Ond am y tro ni fydd dim byd pellach yn digwydd. Hynny yw, os ydyn ni nawr yn creu'r ffeil YAML yr edrychon ni arni gan ddisgrifio shards a replicas a dweud “kubectl apply,” yna bydd Kubernetes yn ei dderbyn, yn ei roi i mewn ac ati ac yn dweud: “Gwych, ond dydw i ddim yn gwybod beth i'w wneud gyda e. Nid wyf yn gwybod sut i gynnal ClickHouseInstallation.”
Yn unol â hynny, mae angen rhywun arnom i helpu Kubernetes i wasanaethu'r math data newydd. Ar y chwith mae gennym reolwr Kubernetes brodorol sy'n gweithio gyda mathau o ddata brodorol. Ac ar y dde, dylem gael rheolydd personol a all weithio gyda mathau o ddata arferol.
Ac mewn ffordd arall fe'i gelwir yn weithredwr. Fe'i cynhwysais yn benodol yma fel Kubernetes, oherwydd gellir ei weithredu y tu allan i K8s hefyd. Yn fwyaf aml, wrth gwrs, mae'r holl weithredwyr yn cael eu gweithredu yn Kubernetes, ond nid oes dim yn ei atal rhag sefyll y tu allan, felly dyma ei symud yn arbennig y tu allan.
Ac yn ei dro, mae rheolydd arfer, a elwir hefyd yn weithredwr, yn rhyngweithio â Kubernetes trwy'r API. Mae eisoes yn gwybod sut i ryngweithio â'r API. Ac mae eisoes yn gwybod sut i wireddu'r gylched gymhleth yr ydym am ei gwneud o adnodd wedi'i deilwra. Dyma'n union beth mae'r gweithredwr yn ei wneud.
Sut mae'r gweithredwr yn gweithio? Gadewch i ni edrych ar yr ochr iawn i weld sut mae'n ei wneud. Dewch i ni ddarganfod sut mae'r gweithredwr yn gwireddu hyn i gyd a sut mae rhyngweithio pellach â K8s yn digwydd.
Mae gweithredwr yn rhaglen. Mae hi'n canolbwyntio ar ddigwyddiadau. Mae'r gweithredwr yn tanysgrifio i ddigwyddiadau gan ddefnyddio'r Kubernetes API. Mae gan API Kubernetes bwyntiau mynediad lle gallwch danysgrifio i ddigwyddiadau. Ac os bydd rhywbeth yn newid yn K8s, yna mae Kubernetes yn anfon digwyddiadau at bawb, h.y. bydd pwy bynnag sydd wedi tanysgrifio i'r pwynt API hwn yn derbyn hysbysiadau.
Mae'r gweithredwr yn tanysgrifio i ddigwyddiadau a rhaid iddo wneud rhyw fath o ymateb. Ei dasg yw ymateb i ddigwyddiadau sy'n dod i'r amlwg.
Mae digwyddiadau yn cael eu cynhyrchu gan ddiweddariadau penodol. Mae ein ffeil YAML gyda disgrifiad o ClickHouseInstallation yn cyrraedd. Aeth i etcd trwy kubectl app. Sbardunwyd digwyddiad yno, ac o ganlyniad daeth y digwyddiad hwn i'r ClickHouse-operator. Derbyniodd y gweithredwr y disgrifiad hwn. Ac mae'n rhaid iddo wneud rhywbeth. Os yw diweddariad wedi cyrraedd ar gyfer y gwrthrych ClickHouseInstallation, yna mae angen i chi ddiweddaru'r clwstwr. A thasg y gweithredwr yw diweddaru'r clwstwr.
Beth mae e'n ei wneud? Yn gyntaf, mae angen inni lunio cynllun gweithredu ar gyfer yr hyn y byddwn yn ei wneud gyda’r diweddariad hwn. Gall diweddariadau fod yn fach iawn, h.y. bach o ran cyflawni YAML, ond gall olygu newidiadau mawr iawn ar y clwstwr. Felly, mae'r gweithredwr yn creu cynllun, ac yna mae'n glynu ato.
Yn ôl y cynllun hwn, mae'n dechrau coginio'r strwythur hwn y tu mewn er mwyn gwireddu codennau, gwasanaethau, h.y. gwneud beth yw ei brif dasg. Dyma sut i adeiladu clwstwr ClickHouse yn Kubernetes.
Nawr gadewch i ni gyffwrdd â pheth mor ddiddorol. Rhaniad cyfrifoldeb yw hwn rhwng Kubernetes a’r gweithredwr, h.y. beth mae Kubernetes yn ei wneud, beth mae'r gweithredwr yn ei wneud, a sut maen nhw'n rhyngweithio â'i gilydd.
Kubernetes sy'n gyfrifol am bethau system, h.y. ar gyfer set sylfaenol o wrthrychau y gellir eu dehongli fel cwmpas system. Mae Kubernetes yn gwybod sut i lansio codennau, sut i ailgychwyn cynwysyddion, sut i osod cyfeintiau, sut i weithio gyda ConfigMap, h.y. popeth y gellir ei alw'n system.
Mae gweithredwyr yn gweithredu mewn parthau. Gwneir pob gweithredwr ar gyfer ei faes pwnc ei hun. Fe wnaethon ni hynny ar gyfer ClickHouse.
Ac mae'r gweithredwr yn rhyngweithio'n union o ran y maes pwnc, megis ychwanegu replica, gwneud diagram, sefydlu monitro. Mae hyn yn arwain at raniad.
Edrychwn ar enghraifft ymarferol o sut mae'r rhaniad cyfrifoldeb hwn yn digwydd pan fyddwn yn gwneud y camau gweithredu atgynhyrchiad ychwanegol.
Mae'r gweithredwr yn derbyn tasg - i ychwanegu atgynhyrchiad. Beth mae'r gweithredwr yn ei wneud? Bydd y gweithredwr yn cyfrifo bod angen creu StatefulSet newydd, lle mae'n rhaid disgrifio templedi o'r fath ac o'r fath, hawliad cyfaint.
Mae'n paratoi'r cyfan ac yn ei drosglwyddo i K8s. Dywed fod arno angen ConfigMap, StatefulSet, Volume. Mae Kubernetes yn gweithio. Mae'n gwireddu'r unedau sylfaenol y mae'n gweithredu â nhw.
Ac yna mae gweithredwr ClickHouse yn dod i rym eto. Mae ganddo god corfforol yn barod y mae eisoes yn gallu gwneud rhywbeth arno. Ac mae gweithredwr ClickHouse eto'n gweithio mewn termau parth. Y rhai. Yn benodol ClickHouse, er mwyn cynnwys replica mewn clwstwr, rhaid i chi, yn gyntaf, ffurfweddu'r sgema data sy'n bodoli yn y clwstwr hwn. Ac, yn ail, rhaid cynnwys yr atgynhyrchiad hwn yn y monitro fel y gellir ei olrhain yn glir. Mae'r gweithredwr eisoes yn ffurfweddu hyn.
A dim ond ar ôl hynny mae ClickHouse ei hun yn dod i rym, h.y. endid lefel uwch arall. Mae hwn eisoes yn gronfa ddata. Mae ganddo ei enghraifft ei hun, atgynhyrchiad arall wedi'i ffurfweddu sy'n barod i ymuno â'r clwstwr.
Mae'n ymddangos bod cadwyn gweithredu a rhannu cyfrifoldeb wrth ychwanegu atgynhyrchiad yn eithaf hir.
Rydym yn parhau â'n tasgau ymarferol. Os oes gennych glwstwr eisoes, gallwch symud y ffurfweddiad.
Fe wnaethon ni ei wneud fel y gallwch chi gludo drwodd i'r xml presennol, y mae ClickHouse yn ei ddeall.
Gallwch chi fireinio ClickHouse. Defnydd parth yn unig yw'r hyn y siaradais amdano wrth esbonio hostPath, storfa leol. Dyma sut i wneud gosodiad parth yn gywir.
Y dasg ymarferol nesaf yw monitro.
Os bydd ein clwstwr yn newid, yna mae angen inni ffurfweddu monitro o bryd i'w gilydd.
Gadewch i ni edrych ar y diagram. Rydym eisoes wedi edrych ar y saethau gwyrdd yma. Nawr, gadewch i ni edrych ar y saethau coch. Dyma sut yr ydym am fonitro ein clwstwr. Sut mae metrigau o glwstwr ClickHouse yn cyrraedd Prometheus, ac yna i Grafana.
Beth yw'r anhawster gyda monitro? Pam mae hyn yn cael ei gyflwyno fel rhyw fath o gyflawniad? Mae'r anhawster yn gorwedd yn y ddeinameg. Pan fydd gennym un clwstwr ac mae'n sefydlog, gallwn sefydlu monitro unwaith a pheidio â thrafferthu mwyach.
Ond os oes gennym ni lawer o glystyrau, neu os oes rhywbeth yn newid yn gyson, yna mae'r broses yn ddeinamig. Ac mae ad-drefnu monitro yn gyson yn wastraff adnoddau ac amser, h.y. dim ond diogi hyd yn oed. Mae angen i hyn fod yn awtomataidd. Mae'r anhawster yn gorwedd yn neinameg y broses. Ac mae'r gweithredwr yn awtomeiddio hyn yn dda iawn.
Sut datblygodd ein clwstwr? Yn y dechreuad yr oedd fel yna.
Yna yr oedd fel hyn.
Yn y diwedd, daeth fel hyn.
Ac mae monitro yn cael ei wneud yn awtomatig gan y gweithredwr. Pwynt mynediad sengl.
A dim ond wrth yr allanfa rydyn ni'n edrych ar ddangosfwrdd Grafana i weld sut mae bywyd ein clwstwr yn berwi y tu mewn.
Gyda llaw, mae dangosfwrdd Grafana hefyd yn cael ei ddosbarthu gyda'n gweithredwr yn uniongyrchol yn y cod ffynhonnell. Gallwch chi gysylltu a defnyddio. Rhoddodd ein DevOps y llun hwn i mi.
Ble hoffen ni fynd nesaf? hwn:
- Datblygu awtomeiddio prawf. Y brif dasg yw profi fersiynau newydd yn awtomataidd.
- Rydym hefyd wir eisiau awtomeiddio'r integreiddio â ZooKeeper. Ac mae cynlluniau i integreiddio â gweithredwr ZooKeeper. Y rhai. Mae gweithredwr wedi'i ysgrifennu ar gyfer ZooKeeper ac mae'n rhesymegol bod y ddau weithredwr yn dechrau integreiddio i adeiladu datrysiad mwy cyfleus.
- Rydym am wneud arwyddion hanfodol mwy cymhleth.
- Amlygais mewn gwyrdd ein bod yn agosáu at etifeddu Templedi - WEDI'I WNEUD, h.y. gyda datganiad nesaf y gweithredwr bydd gennym eisoes etifeddiaeth templedi. Mae hwn yn offeryn pwerus sy'n eich galluogi i adeiladu ffurfweddiadau cymhleth o ddarnau.
- Ac rydym eisiau awtomeiddio tasgau cymhleth. Y prif un yw Ail-rannu.
Gadewch i ni gymryd rhai canlyniadau canolradd.
Beth gawn ni o ganlyniad? Ac a yw'n werth ei wneud ai peidio? A yw hyd yn oed yn angenrheidiol ceisio llusgo'r gronfa ddata i Kubernetes a defnyddio'r gweithredwr yn gyffredinol a gweithredwr Alitnity yn benodol?
Yn yr allbwn rydym yn cael:
- Symleiddio ac awtomeiddio sylweddol o ffurfweddu, lleoli a chynnal a chadw.
- Monitro adeiledig ar unwaith.
- A thempledi codedig parod i'w defnyddio ar gyfer sefyllfaoedd cymhleth. Nid oes angen gwneud gweithred fel ychwanegu replica â llaw. Mae'r gweithredwr yn gwneud hyn.
Dim ond un cwestiwn olaf sydd ar ôl. Mae gennym eisoes gronfa ddata yn Kubernetes, rhithwiroli. Beth am berfformiad datrysiad o'r fath, yn enwedig gan fod ClickHouse wedi'i optimeiddio ar gyfer perfformiad?
Yr ateb yw bod popeth yn iawn! Nid af i fanylion; dyma destun adroddiad ar wahân.
Ond mae prosiect o'r fath â TSBS. Beth yw ei brif dasg? Prawf perfformiad cronfa ddata yw hwn. Dyma ymgais i gymharu cynnes gyda chynnes, meddal gyda meddal.
Sut mae e'n gweithio? Cynhyrchir un set ddata. Yna mae'r set hon o ddata yn cael ei rhedeg ar gronfeydd data gwahanol gan ddefnyddio'r un set o brofion. Ac mae pob cronfa ddata yn datrys un broblem yn y ffordd y mae'n gwybod sut. Ac yna gallwch chi gymharu'r canlyniadau.
Mae eisoes yn cefnogi criw mawr o gronfeydd data. Rwyf wedi nodi tri phrif rai. hwn:
- AmserlenDB.
- MewnlifDB.
- CliciwchHouse.
Gwnaethpwyd cymhariaeth hefyd gyda datrysiad tebyg arall. Cymhariaeth â RedShift. Gwnaed cymhariaeth ar Amazon. Mae ClickHouse hefyd ymhell ar y blaen i bawb yn y mater hwn.
Pa gasgliadau y gellir eu tynnu o'r hyn a ddywedais?
- Mae DB yn Kubernetes yn bosibl. Mae'n debyg bod unrhyw un yn bosibl, ond ar y cyfan mae'n edrych fel ei fod yn bosibl. Mae ClickHouse yn Kubernetes yn bendant yn bosibl gyda chymorth ein gweithredwr.
- Mae'r gweithredwr yn helpu i awtomeiddio prosesau ac yn gwneud bywyd yn haws mewn gwirionedd.
- Mae perfformiad yn normal.
- Ac mae'n ymddangos i ni y gellir ac y dylid defnyddio hwn.
Ffynhonnell agored - ymunwch â ni!
Fel y dywedais eisoes, mae'r gweithredwr yn gynnyrch ffynhonnell gwbl agored, felly byddai'n dda iawn pe bai'r nifer uchaf o bobl yn ei ddefnyddio. Ymunwch â ni! Rydyn ni'n aros amdanoch chi i gyd!
Diolch i chi i gyd!
cwestiynau
Diolch am yr adroddiad! Fy enw i yw Anton. Rwy'n dod o SEMrush. Rwy'n pendroni beth sy'n bod gyda logio. Rydym yn clywed am fonitro, ond dim byd am logio, os ydym yn siarad am y clwstwr cyfan. Er enghraifft, rydym wedi codi clwstwr ar galedwedd. Ac rydym yn defnyddio logio canolog, gan eu casglu'n domen gyffredin gan ddefnyddio dulliau safonol. Ac yna oddi yno rydym yn cael y data sydd o ddiddordeb i ni.
Cwestiwn da, h.y. mewngofnodi i restr todo. Nid yw ein gweithredwr yn awtomeiddio hyn eto. Mae'n dal i ddatblygu, mae'r prosiect yn dal yn eithaf ifanc. Rydym yn deall yr angen am logio. Mae hwn hefyd yn bwnc pwysig iawn. Ac mae'n debyg nad yw'n llai pwysig na monitro. Ond y cyntaf ar y rhestr ar gyfer gweithredu oedd monitro. Bydd logio. Yn naturiol, rydym yn ceisio awtomeiddio pob agwedd ar fywyd y clwstwr. Felly, yr ateb yw nad yw’r gweithredwr ar hyn o bryd, yn anffodus, yn gwybod sut i wneud hyn, ond yn y cynlluniau y byddwn yn ei wneud. Os ydych am ymuno, yna tynnwch gais, os gwelwch yn dda.
Helo! Diolch am yr adroddiad! Mae gennyf gwestiwn safonol yn ymwneud â Chyfrolau Parhaus. Pan fyddwn yn creu cyfluniad gyda'r gweithredwr hwn, sut mae'r gweithredwr yn penderfynu ar ba nod y mae gennym ddisg neu ffolder benodol ynghlwm? Rhaid i ni yn gyntaf esbonio iddo os gwelwch yn dda gosod ein ClickHouse ar y nodau hyn sydd â disg?
Cyn belled ag y deallaf, mae'r cwestiwn hwn yn barhad o storio lleol, yn enwedig y rhan hostPath ohono. Mae hyn fel egluro i'r system gyfan bod angen lansio'r pod ar nod o'r fath ac o'r fath, y mae gennym ddisg sy'n gysylltiedig yn gorfforol ag ef, sydd wedi'i osod ar hyd llwybr o'r fath ac o'r fath. Mae hon yn adran gyfan y cyffyrddais â hi yn arwynebol iawn oherwydd mae'r ateb yn eithaf mawr.
Yn fyr mae'n edrych fel hyn. Yn naturiol, mae angen inni ddarparu'r cyfrolau hyn. Ar hyn o bryd, nid oes darpariaeth ddeinamig mewn storio lleol, felly mae'n rhaid i DevOps dorri'r disgiau eu hunain, y cyfrolau hyn. Ac mae'n rhaid iddynt egluro Kubernetes darparu y bydd gennych gyfrolau Parhaus o'r fath ac o'r fath dosbarth, sydd wedi'u lleoli ar nodau o'r fath ac o'r fath. Yna bydd angen i chi esbonio i Kubernetes bod angen cyfeirio codennau sydd angen dosbarth storio lleol o'r fath yn unig at nodau o'r fath gan ddefnyddio labeli. At y dibenion hyn, mae gan y gweithredwr y gallu i neilltuo rhyw fath o label ac un i bob achos gwesteiwr. Ac mae'n ymddangos y bydd y codennau'n cael eu cyfeirio gan Kubernetes i redeg yn unig ar nodau sy'n cwrdd â'r gofynion, labeli, mewn termau syml. Mae gweinyddwyr yn neilltuo labeli a disgiau darpariaeth â llaw. Ac yna mae'n graddfeydd.
A dyma'r trydydd opsiwn, lleol, sy'n helpu i wneud hyn ychydig yn haws. Fel yr wyf eisoes wedi pwysleisio, mae hwn yn waith manwl ar diwnio, sydd yn y pen draw yn helpu i gael y perfformiad gorau posibl.
Mae gennyf ail gwestiwn yn ymwneud â hyn. Dyluniwyd Kubernetes yn y fath fodd fel nad oes ots i ni a ydym yn colli nod ai peidio. Beth ddylem ni ei wneud yn yr achos hwn os ydym wedi colli'r nôd lle mae ein darn mân yn hongian?
Ydy, roedd Kubernetes mewn sefyllfa i ddechrau bod ein perthynas â'n codennau fel gwartheg, ond yma gyda ni mae pob disg yn dod yn rhywbeth fel anifail anwes. Mae cymaint o broblem fel na allwn eu taflu i ffwrdd. Ac mae datblygiad Kubernetes yn mynd i'r cyfeiriad ei bod yn amhosibl ei drin yn athronyddol yn llwyr, fel pe bai'n adnodd sydd wedi'i daflu'n llwyr.
Nawr am gwestiwn ymarferol. Beth i'w wneud os colloch y nod yr oedd y ddisg arno? Yma mae'r broblem yn cael ei datrys ar lefel uwch. Yn achos ClickHouse, mae gennym atgynyrchiadau sy’n gweithio ar lefel uwch, h.y. ar lefel ClickHouse.
Beth yw'r gwarediad canlyniadol? DevOps sy'n gyfrifol am sicrhau nad yw data'n cael ei golli. Rhaid iddo osod atgynhyrchu'n gywir a rhaid iddo sicrhau bod atgynhyrchu'n rhedeg. Rhaid i'r atgynhyrchiad ar lefel ClickHouse fod â data wedi'i ddyblygu. Nid dyma'r broblem y mae'r gweithredwr yn ei datrys. Ac nid y broblem y mae Kubernetes ei hun yn ei datrys. Mae hyn ar lefel ClickHouse.
Beth i'w wneud os bydd eich nod haearn yn cwympo i ffwrdd? Ac mae'n ymddangos y bydd angen i chi osod ail un, darparu'r disg arno'n iawn, a chymhwyso labeli. Ac ar ôl hynny, bydd yn bodloni'r gofynion y gall Kubernetes lansio pod enghraifft arno. Bydd Kubernetes yn ei lansio. Nid yw nifer eich codennau'n ddigon i gwrdd â'r nifer penodedig. Bydd yn mynd trwy'r cylch a ddangosais. Ac ar y lefel uchaf, bydd ClickHouse yn deall ein bod wedi nodi replica, mae'n dal yn wag ac mae angen i ni ddechrau trosglwyddo data iddo. Y rhai. Nid yw'r broses hon wedi'i awtomeiddio'n dda eto.
Diolch am yr adroddiad! Pan fydd pob math o bethau cas yn digwydd, mae'r gweithredwr yn damwain ac yn ailddechrau, ac ar yr eiliad honno mae digwyddiadau'n cyrraedd, a ydych chi'n trin hyn rywsut?
Beth fydd yn digwydd os bydd y gweithredwr yn damwain ac yn ailgychwyn, dde?
Oes. Ac ar y foment honno daeth digwyddiadau.
Mae'r dasg o beth i'w wneud yn yr achos hwn yn cael ei rannu'n rhannol rhwng y gweithredwr a Kubernetes. Mae gan Kubernetes y gallu i ailchwarae digwyddiad sydd wedi digwydd. Mae'n ailchwarae. A thasg y gweithredwr yw sicrhau, pan fydd y log digwyddiad yn cael ei ailchwarae arno, bod y digwyddiadau hyn yn analluog. Ac fel na fydd yr un digwyddiad yn digwydd dro ar ôl tro yn torri ein system. Ac mae ein gweithredwr yn ymdopi â'r dasg hon.
Helo! Diolch am yr adroddiad! Dmitry Zavyalov, cwmni Smedova. A oes cynlluniau i ychwanegu'r gallu i ffurfweddu gyda haproxy i'r gweithredwr? Byddai gennyf ddiddordeb mewn rhyw balancer arall ar wahân i'r un safonol, fel ei fod yn smart ac yn deall bod ClickHouse yno mewn gwirionedd.
Ydych chi'n siarad am Ingress?
Ydy, yn lle Ingress gyda haproxy. Mewn haproxy gallwch nodi topoleg y clwstwr lle mae ganddo gopïau.
Nid ydym wedi meddwl am y peth eto. Os oes ei angen arnoch ac yn gallu esbonio pam fod ei angen, yna bydd yn bosibl ei weithredu, yn enwedig os ydych am gymryd rhan. Byddwn yn hapus i ystyried yr opsiwn. Yr ateb byr yw na, nid oes gennym swyddogaethau o'r fath ar hyn o bryd. Diolch am y cyngor, byddwn yn ymchwilio i'r mater hwn. Ac os ydych chi hefyd yn esbonio'r achos defnydd a pham mae ei angen yn ymarferol, er enghraifft, creu materion ar GitHub, yna bydd hynny'n wych.
Eisoes.
Iawn. Rydym yn agored i unrhyw awgrymiadau. Ac mae haproxy yn cael ei ychwanegu at y rhestr todo. Mae'r rhestr todo yn tyfu, nid yn crebachu eto. Ond mae hyn yn dda, mae'n golygu bod galw am y cynnyrch.
Ffynhonnell: hab.com