Raporti është i dedikuar për pyetjet praktike të zhvillimit të operatorëve në Kubernetes, projektimin e arkitekturës së tij dhe parimet themelore të funksionimit.
Në pjesën e parë të raportit do të shqyrtojmë:
- çfarë është një operator në Kubernetes dhe pse është i nevojshëm;
- si e thjeshton operatori menaxhimin e sistemeve të ndërlikuara;
- çfarë mund të bëjë një operator dhe çfarë nuk mund të bëjë.
Pas kësaj, do të kalojmë në diskutimin e strukturës së brendshme të operatorit. Do të shqyrtojmë arkitekturën dhe funksionimin e operatorit hap pas hapi. Do të thellohemi në:
- ndërveprimin midis operatorit dhe Kubernetes;
- cilat funksione merr mbi vete operatori dhe çfarë delegon në Kubernetes.
Do të shqyrtojmë menaxhimin e shard-eve dhe kopjeve të DB në Kubernetes.
Më pas, do të diskutojmë pyetje mbi ruajtjen e të dhënave:
- si të punojmë me Ruajtjen e Përhershme nga perspektiva e operatorit;
- pikat delikate në përdorimin e Ruajtjes Lokale.
Në pjesën përfundimtare të raportit do të shqyrtojmë shembuj praktikë të aplikimit nga Amazon ose Google Cloud Service. Raporti është ndërtuar mbi shembujt e zhvillimit dhe përvojës së funksionimit të operatorit për ClickHouse.
Video:
Quhem Vladislav Klimenko. Sot do të doja të flas për përvojën tonë në zhvillimin dhe operimin e operatorit, dhe kjo është një operator i specializuar për menaxhimin e klastereve të bazave të dhënash. Në shembullin e për menaxhimin e klasterit ClickHouse.
Pse kemi mundësinë të flasim për operatorin dhe ClickHouse?
- Ne merremi me mbështetje dhe zhvillim të ClickHouse.
- Aktualisht po përpiqemi të japim kontributin tonë të mundshëm në zhvillimin e ClickHouse. Dhe jemi të dyti pas Yandex në volumet e ndryshimeve të bëra në ClickHouse.
- Përpiqemi të bëjmë projekte të tjera për ekosistemin e ClickHouse.
Një nga projektet e tilla do doja të flas për të. Ky është ClickHouse-operator për Kubernetes.
Në raportin tim do të doja të prek dy tema:
- Tema e parĂ« â se si funksionon operatori ynĂ« pĂ«r menaxhimin e bazave tĂ« tĂ« dhĂ«nave ClickHouse nĂ« Kubernetes.
- Tema e dytĂ« â se si funksionon çdo operator, domethĂ«nĂ«, se si ndĂ«rvepron me Kubernetes.
Këto dy pyetje do të ndërthuren gjatë gjithë raportit tim.
Kë është interesante të dëgjojë atë që unë përpiqem të tregoj?
- Më së shumti do të jetë interesante për ata që operojnë operatorë.
- Ose ata që duan të krijojnë një të tillë, për të kuptuar se si funksionon brenda, si ndërvepron operatori me Kubernetes dhe cilat janë pikat delikate që mund të shfaqen.
Për të kuptuar sa më mirë atë që do të diskutojmë sot, do të ishte e dobishme të dihet se si funksionon Kubernetes dhe të këtë një përgatitje bazë mbi teknologjitë e cloud.
ĂfarĂ« Ă«shtĂ« ClickHouse? ĂshtĂ« njĂ« bazĂ« tĂ« dhĂ«nash kolonore e specializuar pĂ«r pĂ«rpunimin nĂ« kohĂ« reale tĂ« pyetjeve analitikĂ«. Dhe Ă«shtĂ« plotĂ«sisht open source.
Dhe na duhet të dimë vetëm dy gjëra. Duhet të dimë se kjo është një bazë të dhënash, prandaj ajo që do të tregoj do të jetë e zbatueshme praktikisht për çdo bazë të dhënash. Dhe se SGBD ClickHouse është shumë e shkallëzueshme, ofron një shkallëzueshmëri praktikisht lineare. Prandaj, gjendja e klasterit është një gjendje natyrore për ClickHouse. Dhe na intereson më së shumti të diskutojmë se si të mbajmë klasterin ClickHouse në Kubernetes.
Pse është e nevojshme atje? Pse nuk mund ta operojmë atë vetë? Dhe përgjigjet janë pjesërisht teknike dhe pjesërisht organizative.
- Në praktikë, ne gjithnjë e më shpesh përballemi me situatën kur në kompanitë e mëdha pothuajse të gjitha komponentët tashmë janë në Kubernetes. Baza të dhënash mbeten jashtë.
- Dhe gjithnjë e më shpesh bëhet pyetja: "A mund ta vendosim brenda?". Prandaj, kompanitë e mëdha përpiqen të prodhojnë maksimale unifikim menaxhimi për të pasur mundësinë për të menaxhuar shpejt ruajtjen e të dhënave.
- Dhe kjo ndihmon veçanërisht nëse kërkohet maksimalja për të riprodhuar të njëjtën gjë në një vend të ri, domethënë, maksimalja e transportueshmërisë.
Sa e lehtë ose e vështirë është? Kjo, sigurisht, mund të bëhet manualisht. Por nuk është aq e lehtë, sepse ne duam të menaxhojmë veten Kubernetes-in, por për më tepër diktohet nga specifikat e ClickHouse. Dhe kështu rezulton një agregatë.
Dhe gjithçka së bashku jep një kompleksitet të mjaftueshëm që e bën menaxhimin mjaft të vështirë, sepse Kubernetes sjell pyetje të saj për funksionimin e përditshëm, dhe ClickHouse sjell pyetje të saj për eksploatimin e përditshëm. Sidomos nëse kemi disa ClickHouse dhe duhet të bëjmë gjithmonë diçka me ta.
Me ClickHouse-in, në konfigurimin dinamik ka një sasi të konsiderueshme pyetjesh që krijojnë një ngarkesë të vazhdueshme mbi DevOps:
- Kur duam të ndryshojmë diçka në ClickHouse, për shembull, të shtojmë një kopje, një shard, duhet të kryejmë menaxhimin e konfigurimit.
- Pastaj duhet të ndryshohet skema e të dhënave, sepse ClickHouse ka një mënyrë specifike të sharding. Duhet të ndajmë skemën e të dhënave, të ndajmë konfigurimet.
- Duhet të konfigurojmë monitorimin.
- Marrja e logëve për shard-at e rinj, për replikat e reja.
- Të mendojmë për rikuperimin.
- Dhe për riparimin.
Këto janë punë rutinë, të cilat do të donim t'i lehtësonim në përdorim.
Kubernetes ndihmon shumë në përdorim, por në sistemet themelore.
Kubernetes lehtëson dhe automatizon punë të tilla si:
- Rikuperimin.
- Riparimin.
- Menaxhimin e sistemit të ruajtjes.
Kjo është mirë, kjo është rruga e duhur, por nuk ka një ide të qartë se si të përdoret klasteri i bazës së të dhënave.
Duam më shumë, duam që të kemi të gjithë bazën e të dhënave në Kubernetes.
Duam të kemi diçka si një buton të madh magjik të kuq, që kur e shtyp, të krijohet dhe të mbështetet një klaster me detyrat e përditshme që duhet të zgjidhen. Klasteri ClickHouse në Kubernetes.
Dhe ne përpiqemi të krijojmë një zgjidhje që do të ndihmonte për të lehtësuar punën. Kjo është ClickHouse-operator për Kubernetes nga kompania Altinity.
Operatori është një program, detyra kryesore e të cilit është të menaxhojë programe të tjera, dmth. është një menaxher.
Dhe ai përmban modele të sjelljes. Mund ta quajmë këtë njohuri të kodifikuar mbi fushën e subjektit.
Dhe detyra kryesore e tij është të lehtësojë jetën e DevOps dhe të reduktojë menaxhimin e mikro detyrave, në mënyrë që ai (DevOps) të mendojë në terma të nivelit të lartë, dmth. që ai (DevOps) të mos merret me mikro menaxhimin, për t'i zgjidhur të gjitha detajet manualisht.
Dhe operatori është një robot asistent, i cili lufton me mikro detyrat dhe ndihmon DevOps.
Përse nevojitet operatori? Ai dëshmohet veçanërisht i dobishëm në dy çështje:
- Kur specialisti, i cili merret me ClickHouse, nuk ka përvojën e mjaftueshme, por duhet të përdorë ClickHouse, operatori ndihmon në lehtësimin e përdorimit dhe lejon përdorimin e klasterit ClickHouse me një konfigurim mjaft të komplikuar, pa u futur shumë në detaje se si funksionon gjithçka brenda. Thjesht i jepni detyra të nivelit të lartë dhe kjo funksionon.
- Dhe detyra e dytë, në të cilën ai e tregon më së miri veten, është kur duhet të automatizoni një numër të madh detyrash standarde. Hiqen mikro detyrat nga administratorët e sistemit.
Kjo i nevojitet më shumë atyre që sapo po fillojnë rrugën e tyre, ose atyre që duan të merren shumë me automatizim.
Cila është pastaj dallimi i qasjes së bazuar në operatorë nga sistemet e tjera? Ka Helm. Ai gjithashtu ndihmon për të instaluar ClickHouse, mund të krijoni helm charts që madje vendosin një klaster të tërë ClickHouse. Cili është pra dallimi midis operatorit dhe, për shembull, Helm?
Dallimi themelor Ă«shtĂ« qĂ« Helm Ă«shtĂ« menaxhim paketash, ndĂ«rsa operatori shkon mĂ« tej. Ai pĂ«rfshin gjithĂ« ciklin e jetĂ«s. Nuk Ă«shtĂ« vetĂ«m instalimi, janĂ« detyra tĂ« pĂ«rditshme, qĂ« pĂ«rfshijnĂ« zgjerimin, sharding, dmth. gjithçka qĂ« duhet tĂ« kryhet nĂ« procesin e ciklit tĂ« jetĂ«s (nĂ«se Ă«shtĂ« e nevojshme, edhe fshirja) â tĂ« gjitha kĂ«to zgjidh operatori. Ai pĂ«rpiqet tĂ« automatizojĂ« dhe mbĂ«shtesĂ« gjithĂ« ciklin e jetĂ«s sĂ« softuerit. Kjo Ă«shtĂ« dallimi i tij themelor nga zgjidhjet e tjera tĂ« disponueshme.
Kjo ishte pjesa hyrëse, le të vazhdojmë.
Si e ndërtojmë operatorin tonë? Ne përpiqemi të qasemi çështjes për të menaxhuar klasterin ClickHouse si një burim.
Ja, në pjesën e majtë të figurës kemi të dhëna inputi. Kjo është YAML me specifikimin e klasterit, i cili në mënyrë të zakonshme kalon në Kubernetes përmes kubectl. Atëherë operatori e merr, bën magjinë e tij. Dhe në fund kemi këtë skemë. Kjo është implementimi i ClickHouse në Kubernetes.
Dhe më pas do të shohim ngadalë se si funksionon operatori, cilat detyra standarde mund të zgjidhen. Do të shqyrtojmë vetëm detyrat standarde, sepse kemi kohë të kufizuar. Dhe nuk do të flasim për gjithçka që mund të zgjidhë operatori.
Le të bazojmë në praktikë. Projekti ynë është plotësisht open source, kështu që mund të shihni në GitHub se si funksionon. Dhe mund të shqyrtojmë nëse doni thjesht ta filloni, atëherë mund të filloni me Udhëzuesin e Shpejtë.
Nëse doni të kuptoni më në detaje, ne përpiqemi të mbajmë dokumentacionin në një gjendje mjaft të pranueshme.
Le të fillojmë me një detyrë praktike. Detyra e parë, nga e cila të gjithë dëshirojmë të fillojmë, është të nisnim shembullin tonë të parë në çfarëdo mënyre. Si ta nisim ClickHouse përmes operatorit, pa e ditur shumë se si funksionon? Shkruajmë manifestin, pasi të gjitha komunikimet me k8s janë përmes manifestëve.
Këtu është një manifest i tillë i ndërlikuar. Ajo që kemi theksuar me të kuqe është ajo mbi të cilën duhet të fokusohemi. Po kërkojmë nga operativi të krijojë një klasër me emrin demo.
Derikët tani, këto janë shembuj bazikë. Storage-in nuk e përmendim ende, por do të kthehemi te storage më vonë. Derikët tani do të 'vëzhgojmë' zhvillimin e klasës në dinamikë.
Kemi krijuar këtë manifest. I japim atij operativit tonë. Ai e përpunoi, bëri magjinë.
Shikojmë në konsolë. Tre komponentë janë interesante - Pod-i, dy Shërbime dhe StatefulSet-i.
Operativi punoi dhe mund të shohim se çfarë krijoi.
Ai krijon një skemë të tillë. Kemi StatefulSet, Pod, ConfigMap për çdo replikë, ConfigMap për të gjithë klasën. Shërbimet si pika hyrjeje në klasën janë të domosdoshme.
Shërbimet - kjo është Shërbimi kryesor Load Balancer dhe gjithashtu për çdo replikë, për çdo shard.
Kështu duket klastri ynë bazë. Ai përbëhet nga një nodë të vetëm.
Le të shkojmë përpara, do ta komplikohemi. Na nevojitet të shardojmë klastrin.
Detyrat tona po rriten, fillon dinamika. Duam të shtojmë një shard. Po ndjekim zhvillimin. Ndryshojmë specifikimin tonë. Po tregojmë se duam dy sharda.
Ky është i njëjti skedar, i cili po zhvillohet dinamikisht me rritjen e sistemit. Storage nuk ka, storage do të shqyrtohet më vonë, është një temë e veçantë.
I japim YAML-operatorit dhe shohim se çfarë rezulton.
Operativi mendojë dhe krijoi entitete të tjera. Tani kemi dy Pod-a, tre Shërbime dhe, papritur, dy StatefulSet-a. Pse dy StatefulSet-a?
Në skemë ishte kështu - ky është gjendja fillestare, kur ishim me një pod.
Tani qëndron kështu. Derikët tani gjithçka është e thjeshtë, është kopjuar.
Dhe pse StatefulSet u bë dy? Këtu duhet të shkëputemi dhe të diskutojmë se si menaxhohen Pod-ët në Kubernetes.
Ka njĂ« objekt tĂ« tillĂ« qĂ« quhet StatefulSet, i cili lejon krijimin e njĂ« grupi Pod-ash nga njĂ« shablon. Faktori kyç kĂ«tu Ă«shtĂ« Template. Dhe mund tĂ« nisni shumĂ« Pod-a nga njĂ« shablon nĂ« njĂ« StatefulSet. FjalĂ« kyçe kĂ«tu Ă«shtĂ« ânga njĂ« shablon shumĂ« Pod-aâ.
Dhe kishte një joshje të madhe për të krijuar të gjithë klasrin duke ambalazhuar në një StatefulSet. Kjo do të funksiononte, nuk ka asnjë problem. Por ka një nuancë. Nëse dëshirojmë të krijojmë një klasër heterogjen, dmth të përbëhet nga disa versione ClickHouse, atëherë lindin pyetje. Po, StatefulSet mund të bëjë rolling update, po atje mund të vendosni një version të ri, duke shpjeguar se duhet të provoni të mos keni më shumë se kaq node njëkohësisht.
Por nëse e ekstrapolojmë detyrën dhe themi se duam të krijojmë një klasër plotësisht heterogjen dhe duam të mos kalojmë nga versioni i vjetër në versionin e ri përmes rolling update, por thjesht duam të krijojmë një klasër heterogjen si në pjesën e versioneve të ndryshme të ClickHouse dhe në pjesën e storage-it të ndryshëm. Duam, për shembull, disa replika të krijohen në disqe të veçanta, në të ngadalta, për ta ndërtuar plotësisht një klasër heterogjen. Dhe për shkak se StatefulSet bën një zgjidhje standardizuese nga një shablon, nuk ka mundësi të bëjmë këtë.
Pas disa mendimeve u mor vendimi që do ta bëjmë kështu. Të gjitha replikat janë në StatefulSet-in e vet. Ka disa disavantazhe të kësaj zgjidhjeje, por në praktikë, është krejtësisht e inkapsuluar nga operativi. Dhe ka shumë përparësi. Mund të ndërtojmë plotësisht një klasër ashtu siç e duam, për shembull krejtësisht heterogjen. Prandaj, në klasrin ku kemi dy sharda me një replikë, do të kemi dy StatefulSet-a dhe dy Pod-a, pikërisht sepse kemi zgjedhur këtë qasje për shkakun e përmendur më lart për mundësinë e ndërtimit të një klasre heterogjene.
Të kthehemi te detyrat praktike. Në klasrin tonë duhet të konfigurojmë përdoruesit, dmth duhet të kryejmë ndonjë konfigurim ClickHouse në Kubernetes. Operativi ofron të gjitha mundësitë për këtë.
Mund të shkruani drejtpërdrejt në YAML atë që duam. Të gjitha mundësitë konfigurimi mapohen drejtpërdrejt nga ky YAML në konfigurimet ClickHouse, të cilat shpërndahen më pas në të gjithë klasrin.
Mund të shkruani edhe kështu. Kjo është për shembull. Fjalëkalimi mund të bëhet i enkriptuar. Përkrahën të gjitha mundësitë konfigurimi të ClickHouse. Këtu është vetëm një shembull.
Konfigurimi në klasër shpërndahet si ConfigMap. Në praktikë, përditësimi i ConfigMap-it nuk ndodh menjëherë, prandaj nëse klastrin është i madh, procesi i shpërndarjes së konfigurimit zgjas disa kohë. Por gjithçka është shumë e lehtë për t'u përdorur.
E komplikojmë detyrën. Klastri po zhvillohet. Ne duam të aplikojmë replikimin e të dhënave. Pra, kemi tashmë dy sharda, secila me nga një replikë, përdoruesit janë të konfiguruar. Ne po rritemi dhe duam të merremi me replikimin.
ĂfarĂ« na nevojitet pĂ«r replikimin?
Na nevojitet ZooKeeper. Në ClickHouse, replikimi është ndërtuar duke përdorur ZooKeeper. ZooKeeper është e nevojshme që replikat e ndryshme të ClickHouse të kenë konsensus mbi cilat blloqe të dhënash ndodhen në cilin ClickHouse.
Mund të përdorim çdo ZooKeeper. Nëse ka një ZooKeeper të jashtëm në ndërmarrje, atëherë mund ta përdorim atë. Nëse jo, allora mund të installojmë nga depoja jonë. Ka një instalues që e lehtëson këtë proces.
Dhe skema e bashkëpunimit të gjithë sistemit duket kështu. Kemi Kubernetes si platformë. Në të ekzekutohet operatori ClickHouse. ZooKeeper e kam paraqitur këtu. Dhe operatori bashkëpunon si me ClickHouse ashtu edhe me ZooKeeper. Pra, ka bashkëpunim.
Dhe gjithçka është e nevojshme për që ClickHouse të arrijë të replikojë me sukses të dhënat në k8s.
Tani le të shohim detyrën vetë, se si do të duket manifesti për replikimin.
Ne e shtojmĂ« dy sekcione nĂ« manifestin tonĂ«. E para â Ă«shtĂ« se ku tĂ« marrim ZooKeeper, i cili mund tĂ« jetĂ« brenda Kubernetes, ose tĂ« jashtme. Ky Ă«shtĂ« thjesht njĂ« pĂ«rshkrim. Dhe kĂ«rkojmĂ« replikat. Pra, ne duam dy replikat. NĂ« total, do tĂ« kemi 4 pod'e. PĂ«r storage-in e kujtojmĂ«, ai do tĂ« rikthehet mĂ« vonĂ«. Storage Ă«shtĂ« njĂ« kĂ«ngĂ« e veçantĂ«.
Ishte kështu.
Bëhet kështu. Shtohen replikat. E katërta nuk po përshtatet, ne besojmë se atje mund të ketë shumë. Dhe në anë shtohet ZooKeeper. Skemat po komplikohen.
Dhe ka ardhur koha të shtojmë një detyrë tjetër. Do të shtojmë Storage të Përhershëm.
Për Storage të Përhershëm kemi disa mundësi të zbatimit.
Në rast se ekzekutojmë në një ofrues cloud, si Amazon, Google, ka një tundim të madh për të shfrytëzuar storage-in cloud. Kjo është shumë e përshtatshme, është e mirë.
Dhe ka një mundësi tjetër. Kjo është për storage-in lokal, kur diskët janë lokalë në çdo nod. Ky opsion është shumë më i vështirë për t'u zbatuar, por është më produktiv.
Le të shohim se çfarë kemi lidhur me storage-in cloud.
Ka pĂ«rfitime. ĂshtĂ« shumĂ« e thjeshtĂ« pĂ«r tu konfiguruar. Ne thjesht kĂ«rkojmĂ« nga ofruesi cloud, qĂ« na jep storage me kĂ«tĂ« kapacitet, kĂ«tĂ« klasĂ«. Klasat janĂ« tĂ« pĂ«rshkruara nga ofruesit vetĂ«.
Dhe ka një disavantazh. Për disa, ky disavantazh nuk është kritik. Në mënyrë të sigurt, aty do të ketë disa probleme me performancën. Kjo është shumë e përshtatshme në punë, e sigurt, por ka disa ulje potenciale në performancë.
Dhe pasi ClickHouse fokusohet pikërisht në performancë, mund të themi madje se nxjerr gjithçka që mund, prandaj shumë klientë përpiqen të nxjerrin maksimumin e performancës.
Dhe për të nxjerrë maksimumin, na nevojitet storage i lokal.
Kubernetes ofron tri abstraksione për përdorimin e storage-it lokal në Kubernetes. Këto janë:
- EmptyDir
- HostPath.
- Local
Le të shohim se si ndryshojnë dhe çfarë kanë të përbashkët.
Së pari, në të tri qasjet, storage-i është diskët lokalë, të cilët ndodhen në të njëjtin nod fizik të k8s. Por ata kanë disa dallime.
Le tĂ« fillojmĂ« me gjĂ«nĂ« mĂ« tĂ« thjeshtĂ«, pra me emptyDir. ĂfarĂ« Ă«shtĂ« kjo praktikisht? Kjo Ă«shtĂ« kur i kĂ«rkojmĂ« specifikacionit tonĂ« qĂ« sistemi i konteinerizimit (mĂ« shpesh Ă«shtĂ« docker) tĂ« na japĂ« qasje nĂ« njĂ« dosje nĂ« diskun lokal.
Në praktikë, docker krijon dikund me rrugët e tij të brendshme një dosje temporale, e quajtur me një hash të gjatë. Dhe ofron një ndërfaqe për qasje në të.
Si do të funksionojë kjo për performancën? Kjo do të funksionojë me shpejtësinë e diskut lokal, pra është qasje e plotë në diskun tuaj.
Por ky qasje ka një disavantazh. Persistance është mjaft dyshuese në këtë rast. Me lëvizjen e parë të dockers me kontejnerët, persistance humbet. Nëse Kubernetes dëshiron për ndonjë arsye ta transferojë këtë Pod në një disk tjetër, të dhënat do të humbasin.
Ky qasje është i mirë për teste, sepse shpejtësinë e tregon tashmë normale, por për ndonjë gjë serioze ky opsion nuk është i përshtatshëm.
Prandaj ka një qasje të dytë. Kjo është hostPath. Nëse shikoni slajdin e mëparshëm dhe këtë, mund të shihni një vetëm dallim. Dosja ka dalë nga docker direkt në nodën e Kubernetes. Këtu është pak më e thjeshtë. Ne e shkruajmë direkt rrugën në sistemin lokal të skedarëve, ku dëshironim të ruanim të dhënat tona.
Përfitimet e këtij mënyre ekzistojnë. Kjo është tashmë një persistance e vërtetë, madje klasike. Të dhënat do të ruhen në një adresë në disk.
Ka janĂ« dhe disavantazhe. Kjo Ă«shtĂ« kompleksiteti i menaxhimit. Kubernetes tonĂ« mund tĂ« dĂ«shirojĂ« tĂ« zhvendosĂ« njĂ« Pod nĂ« njĂ« nodĂ« tjetĂ«r fizike. Dhe kĂ«tu hyn nĂ« lojĂ« DevOps. Ai duhet tĂ« shpjegojĂ« saktĂ«sisht gjithĂ« sistemit se kĂ«to podâi mund tĂ« zhvendosen vetĂ«m nĂ« ato nodĂ«, ku ke diçka tĂ« montuar nĂ« kĂ«to rrugĂ«, dhe jo mĂ« shumĂ« se njĂ« nodĂ« nĂ« tĂ« njĂ«jtĂ«n kohĂ«. Kjo Ă«shtĂ« mjaft e komplikuar.
PikĂ«risht pĂ«r kĂ«to qĂ«llime, ne nĂ« operatorin tonĂ« kemi ndĂ«rtuar ŃĐ°Đ±Đ»ĐŸĐœĐž pĂ«r ta fshehur gjithĂ« kĂ«tĂ« kompleksitet. Dhe do tĂ« ishte e mundur tĂ« thuash thjesht: "UnĂ« dua qĂ« tĂ« kem njĂ« instance ClickHouse pĂ«r çdo nodĂ« fizike dhe nĂ« kĂ«tĂ« rrugĂ« tĂ« caktuar."
Por kjo nevojë nuk është vetëm për ne, prandaj zotërinjtë nga vetë Kubernetes gjithashtu kuptojnë se njerëzit duan akses në diskët fizikë, prandaj ata ofrojnë një nivel të tretë.
Ai quhet local. Nuk ka asnjĂ« ndryshim nga slajdi i mĂ«parshĂ«m. VetĂ«m se mĂ« parĂ« duhej ta bĂ«nim me duar, qĂ« nuk mund tĂ« zhvendosnim kĂ«to podâe nga njĂ« nodĂ« nĂ« tjetrĂ«n, sepse ato duhet tĂ« ishin tĂ« lidhura nĂ« kĂ«tĂ« rrugĂ« me diskun fizik lokal, dhe tani tĂ« gjitha kĂ«to njohuri inkapsulohen nĂ« Kubernetes vetĂ«. Dhe bĂ«het shumĂ« mĂ« e lehtĂ« tĂ« konfigurosh.
Kthehemi te detyra jonë praktike. Kthehemi te YAML template. Këtu kemi një storage të vërtetë. Ne u kthyem te kjo. Ne caktojmë një template të klasit VolumeClaim ashtu siç është në k8s. Dhe përshkruajmë se cilin storage duam.
Pas kësaj, k8s do të kërkojë storage. Do të na alokojë atë në StatefulSet. Dhe në fund, ky do të jetë në dispozicion për ClickHouse.
Kishim një skemë të tillë. Storage ynë Persistent ishte i kuq, që sinonimizon se duhet të bëhej.
Dhe ai bëhet i gjelbër. Tani skema e klustrit ClickHouse në k8s është plotësisht e finalizuar. Kemi shardë, replika, ZooKeeper, kemi një Persistent të vërtetë, i cili është realizuar në një mënyrë ose në një tjetër. Skema është tani plotësisht funksionale.
Ne vazhdojmë të jetojmë. Klustri ynë po zhvillohet. Dhe Aleksei përpiqet dhe nxjerr një version të ri të ClickHouse.
Shpesh lind njĂ« detyrĂ« praktike â tĂ« testojmĂ« versionin e ri tĂ« ClickHouse nĂ« klustĂ«rin tonĂ«. Dhe, natyrisht, nuk dĂ«shirojmĂ« ta instalojmĂ« tĂ« gjithĂ«, duam ta vendosim diku nĂ« njĂ« kĂ«nd tĂ« largĂ«t nĂ« njĂ« replikĂ« tĂ« re, ndoshta jo njĂ« version tĂ« ri, por ndoshta dy, sepse ata dalin shpesh.
ĂfarĂ« mund tĂ« themi pĂ«r kĂ«tĂ«?
KĂ«tu kemi pikĂ«risht njĂ« mundĂ«si tĂ« tillĂ«. KĂ«to janĂ« template tĂ« podâĂ«ve. Mund tĂ« shpjegojmĂ«, operatori ynĂ« plotĂ«sisht lejon ndĂ«rtimin e njĂ« klusteri heterogjen. Pra, konfigurimi, duke filluar nga tĂ« gjitha replikat si njĂ« grumbull, pĂ«rfundon me çdo replikĂ« personale siç dĂ«shirojmĂ« versionin e ClickHouse, versionin e storage. Ne mund tĂ« konfigurim plotĂ«sisht klusterin nĂ« kĂ«tĂ« konfigurim qĂ« na nevojitet.
Pak do të thellohemi brenda. Më parë flitnim për si funksionon ClickHouse-operatori në përputhje me karakteristikat e ClickHouse.
Tani do të doja të thosha disa fjalë për si funksionon çdo operator, si dhe për si ndërvepron me K8s.
Le tĂ« shqyrtojmĂ« ndĂ«rveprimin me K8s pĂ«r fillim. ĂfarĂ« ndodh kur bĂ«jmĂ« kubectl apply? Objektet tona shfaqen nĂ« etcd pĂ«rmes API-sĂ«.
Për shembull, objektet bazë Kubernetes: pod, StatefulSet, shërbim dhe kështu me radhë.
Sidoqoftë, asgjë fizike nuk ndodh ende. Këto objekte duhet të materializohen në kluster.
Për këtë, shfaqet kontroleri. Kontroleri është një komponent i veçantë k8s, i cili di si të materializojë këto përshkrime. Ai di se si dhe çfarë duhet bërë fizikisht. Ai di si të nisë kontejnerët, çfarë duhet të konfigurohet që serveri të funksionojë.
Dhe ai materializon objektet tona në K8s.
Por ne duam të veprojmë jo vetëm me pod'a, StatefulSet'a, ne duam të krijojmë ClickHouseInstallation, pra, një objekt të tipit ClickHouse, për ta operuar atë si një tërësi. Deri tani nuk ekziston një mundësi e tillë.
Por K8s ka njĂ« tjetĂ«r gjĂ« tĂ« kĂ«ndshme. Ne duam qĂ« tĂ« kemi diku njĂ« entitet tĂ« tillĂ« kompleks, nĂ« tĂ« cilin tĂ« jenĂ« tĂ« mbledhura nga podâĂ«t dhe StatefulSet klusteri ynĂ«.
Dhe çfarĂ« duhet tĂ« bĂ«jmĂ« pĂ«r kĂ«tĂ«? SĂ« pari, nĂ« skenĂ« del Custom Resource Definition. ĂfarĂ« Ă«shtĂ« kjo? Ky Ă«shtĂ« njĂ« pĂ«rshkrim pĂ«r K8s, qĂ« do tĂ« kesh njĂ« tip tĂ« ri tĂ« tĂ« dhĂ«nave, qĂ« dĂ«shirojmĂ« tĂ« shtojmĂ« njĂ« burim tĂ« personalizuar, i cili do tĂ« jetĂ« kompleks brenda. Ky Ă«shtĂ« pĂ«rshkrimi i strukturĂ«s sĂ« tĂ« dhĂ«nave.
Ne e dërgojmë atë gjithashtu përmes kubectl apply. Kubernetes e pranon me gëzim.
Dhe tani në ruajtjen tonë, tek objekti në etcd, ndodhet mundësia për të regjistruar një burim të personalizuar me emrin ClickHouseInstallation.
Por tani, nuk do të ndodhi asgjë tjetër. Pra, nëse tani krijojmë një skedar YAML që kemi shqyrtuar me përshkrimin e shard, replikave dhe themi "kubectl apply", Kubernetes do ta pranojë, do ta vendosë në etcd dhe do të thotë: "Shkëlqyer, por nuk di se çfarë të bëj me të. Si të administroj ClickHouseInstallation nuk e di."
Prandaj, na nevojitet dikush që ndihmon Kubernetes-in të administrojë një lloj të ri të të dhënave. Në anën e majtë kemi kontrolluesin standard të Kubernetes-it, i cili punon me llojet standarde të të dhënave. Ndërsa në anën e djathtë duhet të shfaqet një kontrollues i personalizuar që di të punojë me llojet e personalizuara të të dhënave.
Dhe ndryshe quhet operator. E kam nxjerrë qëllimisht jashtë Kubernetes-it, sepse ai mund të ekzekutohet edhe jashtë K8s. Në fakt, shumicën e kohës, të gjithë operatorët ekzekutohen në Kubernetes, por asgjë nuk e ndalon atë të jetë jashtë, prandaj këtu është nxjerrë jashtë.
Dhe tani kontrolluesi i personalizuar, që është operatori, ndërvepron me Kubernetes-in përmes API-t. Ai tashmë di të ndërveprojë me API-n. Dhe ai e di se si nga burimi i personalizuar të materializojë një skemë komplekse që duam të krijojmë. Kështu punon operatori.
Si funksionon operatori? Le të shohim në anën e djathtë për të zbuluar se si e bën këtë. Të zbulojmë se si operatori e materializon gjithçka dhe si vazhdon ndërveprimi me K8s.
Operatori â Ă«shtĂ« njĂ« program. Ai Ă«shtĂ« orientuar ndaj ngjarjeve. Operatorin, pĂ«rmes API-t tĂ« Kubernetes-it, e subscribon pĂ«r ngjarje. NĂ« API-n e Kubernetes-it ka pika hyrjeje ku mund tĂ« abonohesh pĂ«r ngjarje. Dhe nĂ«se diçka ndryshon nĂ« K8s, atĂ«herĂ« Kubernetes-i dĂ«rgon ngjarje pĂ«r tĂ« gjithĂ« tĂ« interesuarit, dmth. kushdo qĂ« Ă«shtĂ« abonuar nĂ« kĂ«tĂ« pikĂ« API do tĂ« marrĂ« njoftime.
Operatori abonon për ngjarje, dhe duhet të reagojë. Detyra e tij është të reagojë ndaj ngjarjeve që shfaqen.
Ngjarjet gjenerohen nga disa përditësime. Vjen skedari ynë YAML me përshkrimin e ClickHouseInstallation. Ai përmes kubectl apply shkon në etcd. Atje ndodhi një ngjarje, dhe në fund kjo ngjarje arriti te ClickHouse-operatori. Operatorin e mori këtë përshkrim. Dhe ai duhet të bëjë diçka. Nëse erdhi një përditësim mbi objektin e ClickHouseInstallation, duhet të përditësojmë klasterin. Dhe detyra e operatorit është të përditësojë klasterin.
ĂfarĂ« bĂ«n ai? SĂ« pari, duhet tĂ« pĂ«rgatisĂ« njĂ« plan veprimi, çfarĂ« do tĂ« bĂ«jmĂ« me kĂ«tĂ« pĂ«rditĂ«sim. PĂ«rditĂ«simet mund tĂ« jenĂ« shumĂ« tĂ« vogla, dmth. tĂ« vogla nĂ« implementimin YAML, por mund tĂ« sjellin ndryshime shumĂ« tĂ« mĂ«dha nĂ« klaster. Prandaj, operatori krijon njĂ« plan dhe pastaj e ndjek atĂ«.
Ai fillon sipas kĂ«tij plani tĂ« krijojĂ« strukturĂ«n brenda, pĂ«r tĂ« materializuar pod-et, shĂ«rbimet, dmth. tĂ« bĂ«jĂ« atĂ« qĂ« Ă«shtĂ« detyra e tij kryesore. ĂfarĂ« Ă«shtĂ« si tĂ« ndĂ«rtojmĂ« njĂ« klaster ClickHouse nĂ« Kubernetes.
Tani le të prekim një gjë interesante. Ky është ndarjen e përgjegjësive midis Kubernetes-it dhe operatorit, dmth. çfarë bën Kubernetes-i, çfarë bën operatori dhe si ndërveprojnë ata me njëri-tjetrin.
Kubernetes-i përgjigjet për gjërat sistemike, dmth. për grupin bazë të objekteve, të cilin mund ta interpretojmë si sistem-scope. Kubernetes-i di si të nisë pod-et, si të rinisë konteinerët, si të bëjë mount volumes, si të punojë me ConfigMap, dmth. gjithçka që mund të quhet sistem.
OperatorĂ«t operojnĂ« nĂ« fusha tematike. Ădo operator bĂ«het pĂ«r fushĂ«n e tij tĂ« caktuar. Ne e bĂ«mĂ« pĂ«r ClickHouse.
Dhe operatori ndërvepron pikërisht në terma të fushës tematike si, të shtosh një replikë, të krijosh një skemë, të konfigurosh monitorimin. Kështu krijohet kjo ndarje.
Le të shqyrtojmë një shembull praktik, si ndodh kjo ndarje përgjegjësish kur bëjmë veprimin për të shtuar një replikë.
Operatori merr detyrĂ«n â tĂ« shtojĂ« njĂ« replikĂ«. ĂfarĂ« bĂ«n operatori? Operatorit do tĂ« llogarisĂ« se duhet tĂ« krijohet njĂ« StatefulSet tĂ« ri, nĂ« tĂ« cilin duhet tĂ« pĂ«rshkruhen disa modele dhe kĂ«rkesat pĂ«r volume.
Ai e përgatit të gjithë këtë dhe e dërgon më tej në K8s. I thotë se i nevojitet ConfigMap, StatefulSet, Volume. Kubernetes-i e ekzekuton. Ai materializon njësitë bazë me të cilat ai operon.
Dhe pastaj përsëri hyn në punë ClickHouse-operatori. Ai tashmë ka një pod fizik, në të cilin mund të bëhet diçka. Dhe ClickHouse-operatori përsëri punon në terma të fushës tematike. DMth. konkretisht ClickHouse, për të përfshirë një replikë në klaster, së pari duhet të konfigurojë skemën e të dhënave që është në këtë klaster. Dhe, përveç kësaj, duhet të aktivizojë këtë replikë në monitorim, në mënyrë që të shihet mirë. Këtë e konfiguron operatori.
Dhe vetëm pas kësaj, vetë ClickHouse del në veprim, dmth. një entitet tjetër më të avancuar. Kjo është tashmë baza e të dhënave. Ajo ka instancën e saj, një replikë të dytë të konfiguruar, e cila është gati për t'u bashkuar me klasterin.
Kështu, zinxhirin e ekzekutimit dhe ndarjen e përgjegjësive për shtimin e një replike e kemi mjaft të gjatë.
Të vazhdojmë me detyrat tona praktike. Nëse klasteri tashmë ekziston, atëherë mund të realizojmë migrimin e konfiguracionit.
Kemi bërë që në xml-në ekzistuese, të cilën ClickHouse e kupton, mund të kalojmë përmes saj.
Mund tĂ« bĂ«jmĂ« rregullimin e detajuar tĂ« ClickHouse. PikĂ«risht implementimi zonal â Ă«shtĂ« ajo pĂ«r tĂ« cilĂ«n kam folur kur shpjegoja hostPath, magazinim lokal. KĂ«shtu e bĂ«jmĂ« siç duhet implementimin zonal.
Detyra jonë e ardhshme praktike është monitorimi.
Nëse klasteri ynë ndryshon, atëherë duhet të konfiguroni monitorimin periodikisht.
Le të shqyrtojmë diagramin. Ne tashmë kemi shqyrtuar shenjat e gjelbra këtu. Tani le të shqyrtojmë shenjat e kuqe. Kjo është mënyra se si duam të monitorojmë klasterin tonë. Si përfundimet nga klasteri ClickHouse kalojnë në Prometheus, e më pas në Grafana.
Cila është vështirësia me monitorimin? Pse kjo e shohim si një arritje? Vështirësia është pikërisht në dinamikë. Kur kemi një klaster të vetëm dhe ai është statik, mund të konfiguroni një herë monitorimin dhe pastaj të mos shqetësoheni më.
Por nëse kemi shumë klasterë, ose vazhdimisht diçka ndryshon, atëherë procesi është dinamik. Dhe të merresh me përsëritjen e konfigurimit të monitorimit është një humbje burimesh dhe kohe, pra, madje edhe thjesht dembelizëm. Kjo duhet automatizuar. Vështirësia është pikërisht në dinamikën e procesit. Dhe operatori e automatizon këtë shumë mirë.
Si u zhvillua klasteri ynë? Në fillim ishte kështu.
Pastaj ishte kështu.
Në fund ai u bë kështu.
Dhe monitorimi bëhet automatikisht nga operatori. Një pikë e vetme hyrjeje.
Dhe ne thjesht shikojmë në panelin Grafana, si në brendësi jeta e klasterit tonë vlon.
Për më tepër, paneli Grafana gjithashtu shpërndahet me operatorin tonë direkt në burim. Mund ta lidhim dhe ta përdorim. Ky screenshot më dha ekipi ynë DevOps.
Ku do të donim të shkonim më tej? Kjo është:
- Të zhvillojmë automatizimin e testimit. Detyra kryesore është testimi i automatizuar i versioneve të reja.
- Gjithashtu duam shumë të automatizojmë integrimin me ZooKeeper. Dhe në planet është integrimi me ZooKeeper-operatorin. Pra, për ZooKeeper është shkruar një operator dhe është e arsyeshme që dy operatorët të fillojnë të integrohen për të ndërtuar një zgjidhje më të përshtatshme.
- Duam të bëjmë verifikime më të komplikuara të jetës.
- Kam theksuar me gjelbĂ«r atĂ« qĂ« kemi pĂ«r kalimin e trashĂ«gimisĂ« sĂ« Templates â GATSHMĂ, pra, nĂ« lĂ«shimin e ardhshĂ«m tĂ« operatorit do tĂ« kemi tashmĂ« trashĂ«giminĂ« e shablloneve. Ky Ă«shtĂ« njĂ« mjet i fuqishĂ«m qĂ« lejon ndĂ«rtimin e konfigurimeve tĂ« ndĂ«rlikuara nga copĂ«za.
- Dhe duam automatizimin e detyrave të komplikuara. Njëra prej tyre është Re-sharding.
Le të bëjmë një përmbledhje të ndërmjetme.
ĂfarĂ« marrim si rezultat? A ka vlerĂ« tĂ« merremi me kĂ«tĂ« apo jo? A duhet tĂ« pĂ«rpiqemi tĂ« sillnim bazĂ«n e tĂ« dhĂ«nave nĂ« Kubernetes dhe tĂ« zbatonim operatorin nĂ« pĂ«rgjithĂ«si dhe operatorin Alitnity nĂ« veçanti.
Si rezultat marrim:
- Thjeshtim të konsiderueshëm dhe automatizim të konfigurimit, implementimit, si dhe mbështetjes.
- Monitorim të integruar menjëherë.
- Dhe shabllone të kodifikuara me përdorim për situata të komplikuara. Tani veprime të parashikuara si shtimi i replikës nuk duhen bërë manualisht. Këtë e bën operatori.
Ka mbetur vetëm një pyetje e fundit. A kemi tashmë një bazë të dhënash në Kubernetes, virtualizim. Si është performanca e këtij zgjidhjeje, veçanërisht në dritën e faktit se ClickHouse është optimizuar për performancë?
PĂ«rgjigjja Ă«shtĂ« â gjithçka Ă«shtĂ« nĂ« rregull! Nuk do tĂ« jap mĂ« shumĂ« detaje, kjo Ă«shtĂ« njĂ« temĂ« e njĂ« referati tĂ« veçantĂ«.
Por ka njĂ« projekt si TSBS. Cila Ă«shtĂ« detyra e tij kryesore? ĂshtĂ« testi i bazave tĂ« tĂ« dhĂ«nave pĂ«r performancĂ«. Kjo Ă«shtĂ« njĂ« pĂ«rpjekje pĂ«r tĂ« krahasuar ngrohten me ngrohten, butin me butin.
Si funksionon? Generohet një set të dhënash. Pastaj ky set të dhënash kalon në të njëjtin set testesh në bazat e të dhënave të ndryshme. Ndërsa secila bazë e të dhënave zgjidh një problem në mënyrën se si di. Dhe më pas mund të krahasojmë rezultatet.
Ai tashmë mbështet një numër të madh bazash të të dhënave. Kam theksuar tre të rëndësishmet. Këto janë:
- TimescaleDB.
- InfluxDB.
- ClickHouse.
Gjithashtu është bërë një krahasim me një zgjidhje tjetër të ngjashme. Krahasimi me RedShift. Krahasimi është bërë në Amazon. ClickHouse gjithashtu e tejkalon të gjithë në këtë çështje.
ĂfarĂ« konkluzionesh mund tĂ« nxjerrim nga ato qĂ« pĂ«rmenda?
- DB në Kubernetes është i mundur. Ndoshta, është i mundur çdo lloj, por në përgjithësi duket se është i mundur. ClickHouse në Kubernetes me siguri është i mundur falë operatorit tonë.
- Operatori ndihmon në automatizimin e proceseve dhe realisht thjeshton jetën.
- Performanca është e mirë.
- Dhe, na duket, se është diçka që mund dhe duhet të përdoret.
Open source â bashkohuni!
Siç thashë, operatori është një produkt krejtësisht open source, prandaj do të ishte shumë e mirë nëse sa më shumë njerëz ta përdornin atë. Bashkohuni! Ne po ju presim të gjithëve!
Faleminderit të gjithëve!
Pyetje
Faleminderit për prezantimin! Më quajnë Anton. Jam nga kompania SEMrush. Më intereson çështja e logimit. Kemi dëgjuar për monitorimin, por s'kemi dëgjuar asgjë për logimin në lidhje me klasterin në tërësi. Ne, për shembull, kemi ngritur një klaster në pajisje dhe përdorim logim të centralizuar duke mbledhur me mjete standart që i grumbullojmë në një vend të përbashkët. Pastaj prej andej nxjerrim të dhënat e interesit.
ĂshtĂ« njĂ« pyetje e mirĂ«, pra logimi Ă«shtĂ« nĂ« listĂ«n e punĂ«ve pĂ«r tĂ« bĂ«rĂ«. Aktualisht operatori ynĂ« nuk e automatizojnĂ« kĂ«tĂ«. Ai ende po zhvillohet, projekti Ă«shtĂ« akoma mjaft i rinj. Ne e kuptojmĂ« nevojĂ«n pĂ«r logimin. Kjo Ă«shtĂ« edhe njĂ« temĂ« shumĂ« e rĂ«ndĂ«sishme. Dhe ndoshta Ă«shtĂ« po aq e rĂ«ndĂ«sishme sa monitorimi. Por e para nĂ« listĂ«n pĂ«r zbatim ishte monitorimi. Logimi do tĂ« jetĂ«. Ne, sigurisht, po pĂ«rpiqemi tĂ« automatizojmĂ« tĂ« gjitha aspektet e funksionimit tĂ« klasterit. Prandaj, pĂ«rgjigjja Ă«shtĂ« â pĂ«r momentin operatori, pĂ«r fat tĂ« keq, nuk e di si ta bĂ«jĂ« kĂ«tĂ«, por Ă«shtĂ« nĂ« planet tona, ne do ta bĂ«jmĂ«. NĂ«se keni dĂ«shirĂ« tĂ« bashkoheni, atĂ«herĂ« ju lutem bĂ«ni njĂ« pull request.
Përshëndetje! Faleminderit për prezantimin! Kam një pyetje standarde lidhur me Volume të Përhershëm. Kur krijojmë një konfigurim me këtë operator, si e përcakton operatori se në cilin nod kemi montuar një disk apo një dosje? Duhet ta shpjegojmë paraprakisht se, ju lutem, vendosni ClickHouse tonë saktësisht në këto nodet ku ka disk?
Sa e kuptoj unĂ«, kjo pyetje Ă«shtĂ« njĂ« vazhdimĂ«si e ruajtjes lokale, veçanĂ«risht pjesĂ«s sĂ« saj pĂ«r hostPath. ĂshtĂ« si tĂ« shpjegosh tĂ«rĂ« sistemit se duhet qĂ« pod tĂ« lancojĂ« pikĂ«risht nĂ« njĂ« nodĂ« tĂ« tillĂ«, ku kemi njĂ« disk fizik tĂ« lidhur, i cili Ă«shtĂ« montuar nĂ« kĂ«tĂ« rrugĂ«. Kjo Ă«shtĂ« njĂ« e gjithĂ« seksion, qĂ« e kam pĂ«rmendur shumĂ« nĂ« sipĂ«rfaqe, sepse pĂ«rgjigjja Ă«shtĂ« mjaft e gjĂ«rĂ«.
Në thelb duket kështu. Ne, natyrisht, duhet të bëjmë provisionin e këtyre volumeve. Aktualisht, në ruajtjen lokale nuk ka provision të dinamik, prandaj DevOps duhet t'i presë vetë disqet, këto volume. Dhe duhet t'i shpjegojnë Kubernetes-it se do të keni Volume të Përhershëm të një klase të tillë, që ndodhen në këto nodet. Pastaj do të duhet t'i shpjegoni Kubernetes-it se podët që kërkojnë një klasë të tillë të ruajtjes lokale duhet të planifikohen vetëm në këto nodet përmes etiketimeve. Për këto qëllime, operatori ka mundësinë për të caktuar ndonjë etikete dhe një për instancën e çdo hosti. Dhe kështu, podët do të rruhen nga Kubernetes për të u ngjitur vetëm në nodet që plotësojnë kërkesat, etiketimeve, duke folur thjesht. Administratorët caktojnë etiketa, bëjnë provisionin e disqeve me duar. Dhe atëherë ajo do të shkallëzohet.
Dhe pikërisht opsioni i tretë local ndihmon të lehtësojë këtë pak. Siç e theksova, kjo është një punë e mundimshme e konfigurimit, që në fund ndihmon për të arritur maksimalen e performancës.
Kam njĂ« pyetje tĂ« dytĂ«, e cila Ă«shtĂ« e lidhur me kĂ«tĂ«. Kubernetes Ă«shtĂ« menduar qĂ« tĂ« mos na interesojĂ« nĂ«se do tĂ« humbasim njĂ« nodĂ« apo jo. ĂfarĂ« duhet tĂ« bĂ«jmĂ« nĂ« kĂ«tĂ« rast nĂ«se humbim nodĂ«n ku kemi njĂ« shard?
Po, Kubernetes fillimisht është pozicionuar që ne lidhur me podët tanë të mendojmë si derrat, por këtu çdo disk bëhet si një kafshë shtëpiake. Ka një problem se ne nuk mund t'i hedhim thjesht. Dhe zhvillimi i Kubernetes shkon në atë drejtim që nuk është e mundur ta trajtojmë këtë me filozofi, si resurse që mund të hidhni plotësisht.
Tani, pytja praktike. ĂfarĂ« duhet tĂ« bĂ«jmĂ« nĂ«se humbet njĂ« nodĂ« ku ndodhej disku? KĂ«tu problemi zgjidhet nĂ« njĂ« nivel mĂ« tĂ« lartĂ«. NĂ« rastin e ClickHouse kemi riplikime qĂ« punojnĂ« nĂ« njĂ« nivel mĂ« tĂ« lartĂ«, dmth, nĂ« nivelin e ClickHouse.
Cila është disponimi? Për të siguruar që të dhënat të mos humbasin, përgjegjës është DevOps. Ai duhet ta konfigurojë saktë riplikimin dhe duhet të sigurohet që riplikimi të realizohet. Në riplikim në nivelin e ClickHouse duhet të jenë të dhënat e dubluara. Kjo nuk është një detyrë që zgjidh operatori. Dhe nuk është një detyrë që zgjidh vetë Kubernetes. Kjo është në nivelin e ClickHouse.
ĂfarĂ« duhet tĂ« bĂ«jmĂ« nĂ«se ndodhet njĂ« nodĂ« fizike e prishur? Dmth, ne duhet tĂ« vendosim njĂ« tjetĂ«r, ta konfiguroni saktĂ« disku, t'i vendosim etiketat. Dhe pas kĂ«saj ajo do tĂ« pĂ«rmbushĂ« kĂ«rkesat qĂ« Kubernetes mund ta lancojĂ« instancĂ«n e pod-it. Kubernetes do ta lancojĂ«. Numri i podâĂ«ve tuaja do tĂ« jetĂ« i pamjaftueshĂ«m pĂ«r atĂ« qĂ« Ă«shtĂ« caktuar. Ajo do tĂ« kalojĂ« pĂ«rmes ciklit qĂ« tregova. Dhe nĂ« nivelin mĂ« tĂ« lartĂ« ClickHouse do tĂ« kuptojĂ« se kemi pranuar njĂ« riplikim, ai Ă«shtĂ« ende i zbrazĂ«t dhe mbi tĂ« duhet qĂ« tĂ« fillojmĂ« tĂ« derdhim tĂ« dhĂ«nat. Dmth, ky proces Ă«shtĂ« akoma i automatizuar keq.
Faleminderit për referatin! Kur ndodhin ndodhi të papritura, operatori bie dhe ripërdoret, dhe në atë moment ndodhin ngjarje, a e përpunoni ndonjëherë këtë?
ĂfarĂ« do tĂ« ndodhte nĂ«se operatori ra dhe u ripĂ«rkĂ«dhen, apo jo?
Po. Dhe në atë moment ndodhën ngjarje.
Detyra, çfarë të bëni në këtë rast ndan pjesërisht përgjegjësitë midis operatorit dhe Kubernetes. Kubernetes ka mundësinë të riprodhojë eventin që ka ndodhur. Ai e riprodhon. Dhe detyra e operatorit është të sigurojë që, kur të bëhet ripërsëritja e regjistrit të ngjarjeve, ngjarjet të jenë idempotente. Dhe që rikthimi i të njëjtës ngjarje të mos dëmtojë sistemin tonë. Dhe operatori ynë ia del me këtë detyrë.
Përshëndetje! Faleminderit për referatin! Dmitri Zavjalov, kompania Smedova. A ka për të ardhur mundësia për konfigurimin me haproxy? Intereson ndonjë balancues tjetër përveç atij standard, që të jetë më inteligjent dhe të kuptojë që aty është me të vërtetë ClickHouse.
Apo flisni për Ingress?
Po, zëvendësoni Ingress me haproxy. Në haproxy mund të specifikoni topologjinë e klasterit, ku ka replikat.
Deritani nuk kemi menduar pĂ«r kĂ«tĂ«. NĂ«se ju nevojitet dhe mund ta shpjegoni pse Ă«shtĂ« e nevojshme, mund tĂ« realizohet, veçanĂ«risht nĂ«se dĂ«shironi tĂ« merrni pjesĂ«. Ne e shqyrtojmĂ« me kĂ«naqĂ«si variantin. PĂ«rgjigja e shkurtĂ«r â jo, nĂ« momentin aktual nuk kemi njĂ« funksionalitet tĂ« tillĂ«. Faleminderit pĂ«r sugjerimin, do ta shqyrtojmĂ«. NĂ«se gjithashtu mund tĂ« shpjegoni rastin e pĂ«rdorimit dhe pse Ă«shtĂ« e nevojshme nĂ« praktikĂ«, pĂ«r shembull, tĂ« krijoni issues nĂ« GitHub, do tĂ« ishte shkĂ«lqyer.
Tashmë ekziston.
Mirë. Ne jemi të hapur për çdo propozim. Dhe haproxy është në listën tonë të punëve për të bërë. Lista e punëve për të bërë rritet, por jo zvogëlohet për momentin. Por kjo është mirë, do të thotë se produkti është i kërkuar.
Burimi: habr.com
