Raporti i kushtohet çështjeve praktike të zhvillimit të një operatori në Kubernetes, dizajnimit të arkitekturës së tij dhe parimeve bazë 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 saktësisht operatori menaxhimin e sistemeve komplekse;
- çfarë mundet operatori dhe çfarë nuk mundet operatori.
Më pas, ne i drejtohemi një diskutimi të strukturës së brendshme të operatorit. Konsideroni arkitekturën dhe funksionimin e operatorit hap pas hapi. Le të analizojmë në detaje:
- ndërveprimi midis operatorit dhe Kubernetes;
- çfarë funksionesh merr operatori dhe çfarë i delegon Kubernetes.
Le të shohim menaxhimin e copëzave dhe kopjeve të bazës së të dhënave në Kubernetes.
Më pas, ne do të diskutojmë çështjet e ruajtjes së të dhënave:
- si të punohet me Persistent Storage nga këndvështrimi i një operatori;
- kurthet e përdorimit të hapësirës ruajtëse lokale.
Në pjesën e fundit të raportit, ne do të shqyrtojmë shembuj praktikë të aplikimit me Amazon ose Google Cloud Service. Raporti bazohet në shembullin e zhvillimit dhe përvojës operative të operatorit për ClickHouse.
Video:
Emri im është Vladislav Klimenko. Sot doja të flisja për përvojën tonë në zhvillimin dhe funksionimin e një operatori, dhe ky është një operator i specializuar për menaxhimin e grupimeve të bazës së të dhënave. Për shembull për të menaxhuar grupin ClickHouse.
Pse kemi mundësinë të flasim për operatorin dhe ClickHouse?
- Ne mbështesim dhe zhvillojmë ClickHouse.
- Për momentin, ne po përpiqemi të japim ngadalë kontributin tonë në zhvillimin e ClickHouse. Dhe ne jemi të dytët pas Yandex për sa i përket sasisë së ndryshimeve të bëra në ClickHouse.
- Ne po përpiqemi të bëjmë projekte shtesë për ekosistemin ClickHouse.
Do të doja të flisja për një nga këto projekte. Bëhet fjalë për operatorin ClickHouse për Kubernetes.
Në raportin tim, do të doja të prekja dy tema:
- Tema e parë është se si funksionon operatori ynë i bazës së të dhënave ClickHouse në Kubernetes.
- Tema e dytë është se si funksionon çdo operator, pra si ndërvepron me Kubernetes.
Megjithatë, këto dy pyetje do të kryqëzohen gjatë gjithë raportit tim.
Kush do të ishte i interesuar të dëgjonte atë që po përpiqem të them?
- Do të jetë më me interes për ata që operojnë operatorë.
- Ose për ata që duan të bëjnë të tyren në mënyrë që të kuptojnë se si funksionon brenda, si ndërvepron operatori me Kubernetes dhe cilat gracka mund të shfaqen.
Për të kuptuar më mirë atë që do të diskutojmë sot, do të ishte mirë të dinim se si funksionon Kubernetes dhe të kishim një sfond bazë në kompjuterin cloud.
Çfarë është ClickHouse? Kjo është një bazë të dhënash kolone me specifika në përpunimin online të pyetjeve analitike. Dhe është plotësisht me burim të hapur.
Dhe ne duhet të dimë vetëm dy gjëra. Ju duhet të dini se kjo është një bazë të dhënash, kështu që ajo që do t'ju them do të jetë e zbatueshme për pothuajse çdo bazë të dhënash. Dhe fakti që ClickHouse DBMS shkallëzohet shumë mirë, jep shkallëzim pothuajse linear. Prandaj, gjendja e grupit është një gjendje e natyrshme për ClickHouse. Dhe ne jemi më të interesuar të diskutojmë se si të shërbejmë një grupim ClickHouse në Kubernetes.
Pse është i nevojshëm ai atje? Pse nuk mund të vazhdojmë ta operojmë vetë? Dhe përgjigjet janë pjesërisht teknike dhe pjesërisht organizative.
- Në praktikë, ne gjithnjë e më shpesh hasim një situatë ku në kompanitë e mëdha pothuajse të gjithë përbërësit janë tashmë në Kubernetes. Mbeten bazat e të dhënave jashtë.
- Dhe gjithnjë e më shpesh shtrohet pyetja: "A mund të vendoset brenda?". Prandaj, kompanitë e mëdha po përpiqen të prodhojnë unifikimin maksimal të menaxhimit në mënyrë që të jenë në gjendje të menaxhojnë shpejt depot e tyre të të dhënave.
- Dhe kjo ndihmon veçanërisht nëse keni nevojë për mundësinë maksimale për të përsëritur të njëjtën gjë në një vend të ri, domethënë transportueshmëri maksimale.
Sa e lehtë apo e vështirë është? Kjo, natyrisht, mund të bëhet me dorë. Por kjo nuk është aq e lehtë, sepse ne shtojmë kompleksitetin e menaxhimit të vetë Kubernetes, por në të njëjtën kohë imponohen specifikat e ClickHouse. Dhe rezulton një grumbullim i tillë.
Dhe së bashku, kjo jep një grup mjaft të madh teknologjish, të cilat tashmë po bëhen mjaft të vështira për t'u menaxhuar, sepse Kubernetes sjell problemet e tij të përditshme në funksionim, dhe ClickHouse sjell problemet e tij në funksionimin e përditshëm. Sidomos nëse kemi disa ClickHouse dhe duhet të bëjmë vazhdimisht diçka me to.
Me një konfigurim dinamik, ClickHouse ka një numër mjaft të madh çështjesh që krijojnë një ngarkesë të vazhdueshme në DevOps:
- Kur duam të ndryshojmë diçka në ClickHouse, për shembull, të shtojmë një kopje ose copëza, atëherë duhet të menaxhojmë konfigurimin.
- Pastaj ndryshoni skemën e të dhënave, sepse ClickHouse ka një metodë specifike të ndarjes. Atje është e nevojshme të vendosni skemën e të dhënave, të vendosni konfigurimet.
- Duhet të konfiguroni monitorimin.
- Koleksion shkrimesh për copëza të reja, për kopje të reja.
- Kujdesuni për restaurimin.
- Dhe rinisni.
Këto janë punë të tilla rutinë që do të doja shumë t'i lehtësoja në funksionim.
Vetë Kubernetes ndihmon shumë në funksionim, por në gjërat bazë të sistemit.
Kubernetes është i shkëlqyeshëm në lehtësimin dhe automatizimin e gjërave si:
- Rimëkëmbja.
- Rifillo, fillo përsëri.
- Menaxhimi i ruajtjes.
Kjo është mirë, ky është drejtimi i duhur, por ai është plotësisht jashtë kontaktit me mënyrën e funksionimit të një grupi bazë të dhënash.
Unë dua më shumë, dua që e gjithë baza e të dhënave të punojë për ne në Kubernetes.
Do të doja të merrja diçka si një buton i madh i kuq magjik që shtypni dhe keni një grup të vendosur dhe mirëmbajtur gjatë gjithë ciklit jetësor me detyra të përditshme që duhet të zgjidhen. Grupi i ClickHouse në Kubernetes.
Dhe ne u përpoqëm të bënim një zgjidhje që do të ndihmonte në lehtësimin e punës. Ky është operatori ClickHouse për Kubernetes nga Altinity.
Një operator është një program, detyra kryesore e të cilit është të menaxhojë programe të tjera, pra është një menaxher.
Dhe përmban modele të sjelljes. Mund ta quani njohuri të kodifikuara rreth fushës lëndore.
Dhe detyra e tij kryesore është të lehtësojë jetën për DevOps dhe të zvogëlojë mikromenaxhimin në mënyrë që ai (DevOps) të mendojë tashmë në terma të nivelit të lartë, domethënë, në mënyrë që ai (DevOps) të mos mikromenaxhojë, në mënyrë që të mos konfigurojë manualisht të gjitha detajet.
Dhe vetëm operatori është një ndihmës robot që lufton me mikrodetyrat dhe ndihmon DevOps.
Pse nevojitet një operator? Ai shkëlqen në dy fusha:
- Kur një specialist i ClickHouse nuk ka përvojë të mjaftueshme, por tashmë është e nevojshme të përdoret ClickHouse, operatori lehtëson funksionimin dhe ju lejon të përdorni një grup ClickHouse me një konfigurim mjaft kompleks, duke mos hyrë në shumë 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 shfaqet më mirë është kur është e nevojshme të automatizohet një numër i madh detyrash tipike. Heq mikrodetyrat nga sysadmins.
Kjo është më e nevojshme ose nga ata që sapo kanë filluar udhëtimin e tyre, ose nga ata që duhet të bëjnë shumë automatizim.
Cili është ndryshimi midis qasjes së bazuar në operator dhe sistemeve të tjera? Ekziston edhe Helm. Ndihmon gjithashtu për të instaluar ClickHouse, ju mund të vizatoni diagrame drejtuese, të cilat madje do të instalojnë një grup të tërë ClickHouse. Cili është atëherë ndryshimi midis operatorit dhe nga i njëjti, për shembull, Helm?
Dallimi kryesor themelor është se Helm është menaxhimi i paketave dhe Operatori shkon një hap më tej. Kjo është mbështetje për të gjithë ciklin e jetës. Ky nuk është vetëm instalim, këto janë detyra të përditshme që përfshijnë shkallëzimin, ndarjen, d.m.th. gjithçka që duhet të bëhet gjatë ciklit të jetës (nëse është e nevojshme, atëherë edhe fshirja) - e gjithë kjo vendoset nga operatori. Ai përpiqet të automatizojë dhe mbajë të gjithë ciklin e jetës së softuerit. Ky është ndryshimi i tij thelbësor nga zgjidhjet e tjera që janë paraqitur.
Kjo ishte pjesa hyrëse, le të vazhdojmë.
Si e ndërtojmë operatorin tonë? Ne po përpiqemi t'i qasemi çështjes për të menaxhuar grupin ClickHouse si një burim i vetëm.
Këtu kemi të dhënat hyrëse në anën e majtë të figurës. Ky është YAML me një specifikim grupi, i cili kalohet në mënyrë klasike përmes kubectl në Kubernetes. Atje operatori ynë e merr, bën magjinë e tij. Dhe si rezultat, ne marrim një skemë të tillë. Ky është zbatimi i ClickHouse në Kubernetes.
Dhe pastaj ngadalë do të shikojmë se si funksionon operatori, cilat detyra tipike mund të zgjidhen. Ne do të shqyrtojmë vetëm detyrat tipike, sepse kemi kohë të kufizuar. Dhe nuk do të tregohet për gjithçka që operatori mund të vendosë.
Le të fillojmë nga praktika. Projekti ynë është plotësisht me burim të hapur, kështu që ju mund të shihni se si funksionon në GitHub. Dhe mund të vazhdoni nga konsideratat, nëse thjesht dëshironi të filloni, atëherë mund të filloni me Udhëzuesin e Fillimit të Shpejtë.
Nëse doni të kuptoni në detaje, atëherë ne përpiqemi ta ruajmë dokumentacionin në një formë pak a shumë të mirë.
Le të fillojmë me një problem praktik. Detyra e parë me të cilën duam të fillojmë të gjithë është të ekzekutojmë disi shembullin e parë. Si të nisni ClickHouse me ndihmën e një operatori, pa e ditur as se si funksionon? Ne po shkruajmë një manifest, sepse i gjithë komunikimi me k8 është komunikim përmes manifesteve.
Këtu është një manifest kaq kompleks. Ajo që kemi theksuar me të kuqe është ajo ku duhet të fokusohemi. Ne i kërkojmë operatorit të krijojë një grup të quajtur demo.
Tani për tani, këta janë shembuj bazë. Ruajtja nuk është përshkruar ende, por ne do të kthehemi në ruajtje pak më vonë. Tani për tani, ne do të vëzhgojmë zhvillimin e grupit në dinamikë.
Ne kemi krijuar këtë manifestim. Ne ia japim operatorit tonë. Ai punonte, bënte magji.
Ne shikojmë konsolën. Tre komponentë janë me interes: një Pod, dy Shërbime dhe një StatfulSet.
Operatori ka punuar, dhe ne mund të shohim se çfarë saktësisht krijoi.
Ai krijon diçka të tillë. Ne kemi një StatefulSet, Pod, ConfigMap për çdo kopje, ConfigMap për të gjithë grupimin. Domosdoshmërisht shërbimet si pika hyrëse në grup.
Shërbimet janë shërbimi qendror Load Balancer dhe është i mundur për çdo kopje, për çdo copë.
Këtu është grupi ynë bazë duket diçka si kjo. Ai është nga një nyje e vetme.
Le të shkojmë më tej, do të ndërlikojmë. Ju duhet të copëtoni grupin.
Detyrat tona po rriten, dinamika po fillon. Ne duam të shtojmë një copë. Ne ndjekim zhvillimin. Ne ndryshojmë specifikimet tona. Ne tregojmë se duam dy copëza.
Ky është i njëjti skedar që ne zhvillojmë në mënyrë dinamike me rritjen e sistemit. Nuk ka ruajtje, ruajtja do të diskutohet më tej, kjo është një çështje më vete.
Ne ushqejmë operatorin YAML dhe shohim se çfarë ndodh.
Operatori mendoi dhe bëri entitetet e mëposhtme. Ne tashmë kemi dy Pods, tre Shërbime dhe, papritmas, 2 StatfulSets. Pse 2 StatefulSets?
Në diagram ishte kështu - kjo është gjendja jonë fillestare, kur kishim një pod.
U bë kështu. Deri më tani, gjithçka është e thjeshtë, është dyfishuar.
Dhe pse StatefulSet u bë dy? Këtu duhet të shmangemi dhe të diskutojmë çështjen se si menaxhohen Pods në Kubernetes.
Ekziston një objekt i tillë i quajtur StatefulSet, i cili ju lejon të krijoni një grup Pods nga një shabllon. Faktori kryesor këtu është Template. Dhe mund të ekzekutoni shumë Pods në një StatefulSet sipas një shablloni. Dhe fraza kryesore këtu është "një shabllon shumë Pods".
Dhe kishte një tundim të madh për të krijuar të gjithë grupin, duke e paketuar atë në një Shtesë Stateshe. Do të funksionojë, nuk ka asnjë problem në të. Por ka një paralajmërim. Nëse duam të mbledhim një grup heterogjen, d.m.th. nga disa versione të ClickHouse, atëherë fillojnë pyetjet tona. Po, StatefulSet mund të bëjë një përditësim të vazhdueshëm, por aty mund të lëshoni një version të ri, shpjegoni se nuk duhet të provoni më shumë se kaq shumë nyje në të njëjtën kohë.
Por nëse ekstrapolojmë detyrën dhe themi se duam të bëjmë një grupim plotësisht heterogjen dhe nuk duam të ndryshojmë nga versioni i vjetër në një të ri duke përdorur një përditësim të vazhdueshëm, por thjesht duam të krijojmë një grup heterogjen si përsa i përket versioneve të ndryshme e ClickHouse dhe për sa i përket ruajtjes së ndryshme. Ne duam, për shembull, të bëjmë disa kopje në disqe të veçantë, në të ngadaltë, në përgjithësi, për të ndërtuar plotësisht një grup heterogjen. Dhe për shkak të faktit se StatefulSet bën një zgjidhje të standardizuar nga një shabllon, kështu që nuk ka asnjë mënyrë për ta bërë këtë.
Pas një mendimi, u vendos që ne të veprojmë kështu. Ne kemi secilën kopje në StatefulSet-in e vet. Ka disa të meta për këtë zgjidhje, por në praktikë e gjithë kjo përfshin plotësisht operatorin. Dhe ka shumë përfitime. Ne mund të ndërtojmë një grup krejtësisht të tillë siç duam, për shembull, një absolutisht heterogjen. Prandaj, në një grup në të cilin kemi dy copëza me një kopje, do të kemi 2 StatefulSets dhe 2 Pods pikërisht sepse kemi zgjedhur këtë qasje për arsyet e mësipërme për aftësinë për të ndërtuar një grup heterogjen.
Le të kthehemi te detyrat praktike. Në grupin tonë, ne duhet të konfigurojmë përdoruesit, d.m.th. ju duhet të bëni disa konfigurime të ClickHouse në Kubernetes. Operatori ofron të gjitha mundësitë për këtë.
Ne mund të shkruajmë atë që duam drejtpërdrejt në YAML. Të gjitha opsionet e konfigurimit janë hartuar drejtpërdrejt nga ky YAML në konfigurimet e ClickHouse, të cilat më pas vendosen në të gjithë grupin.
Ju gjithashtu mund të shkruani kështu. Ky është për shembull. Fjalëkalimi mund të kodohet. Mbështeten absolutisht të gjitha opsionet e konfigurimit të ClickHouse. Këtu është vetëm një shembull.
Konfigurimi i grupit shpërndahet si ConfigMap. Në praktikë, përditësimi i ConfigMap nuk ndodh menjëherë, kështu që nëse ka një grup të madh, atëherë procesi i shtyrjes së konfigurimit kërkon ca kohë. Por e gjithë kjo është shumë e përshtatshme për t'u përdorur.
Le ta komplikojmë detyrën. Grupi po zhvillohet. Ne duam të përsërisim të dhënat. Kjo do të thotë, ne tashmë kemi dy copëza, një kopje secila, përdoruesit janë konfiguruar. Ne po rritemi dhe duam të përsërisim.
Çfarë na nevojitet për replikim?
Ne kemi nevojë për ZooKeeper. Në ClickHouse, riprodhimi ndërtohet duke përdorur ZooKeeper. ZooKeeper është i nevojshëm në mënyrë që kopje të ndryshme të ClickHouse të kenë një konsensus se cilat blloqe të dhënash janë në cilin ClickHouse.
ZooKeeper mund të përdoret nga kushdo. Nëse ndërmarrja ka një ZooKeeper të jashtëm, atëherë ai mund të përdoret. Nëse jo, mund ta instaloni nga depoja jonë. Ekziston një instalues që e bën të gjithë këtë më të lehtë.
Dhe skema e ndërveprimit të të gjithë sistemit rezulton kështu. Ne kemi Kubernetes si një platformë. Ai ekzekuton deklaratën ClickHouse. ZooKeeper Unë fotografova këtu. Dhe operatori ndërvepron si me ClickHouse ashtu edhe me ZooKeeper. Kjo do të thotë, arrihet një ndërveprim.
Dhe e gjithë kjo është e nevojshme që ClickHouse të riprodhojë me sukses të dhënat në k8s.
Le të shohim tani vetë detyrën, si do të duket manifesti për replikim.
Ne shtojmë dy seksione në manifestin tonë. E para është se ku mund të merrni ZooKeeper, i cili mund të jetë ose brenda Kubernetes ose i jashtëm. Ky është vetëm një përshkrim. Dhe ne porosisim kopje. Ato. duam dy kopje. Në total, duhet të kemi 4 pods në dalje. Kujtojmë për ruajtjen, do të kthehet pak më tej. Ruajtja është një këngë më vete.
Ishte kështu.
Bëhet kështu. Janë shtuar kopjet. E 4-ta nuk u përshtat, besojmë se mund të jenë të shumtë. Dhe ZooKeeper shtohet në anën. Modelet po bëhen më komplekse.
Dhe është koha për të shtuar detyrën tjetër. Ne do të shtojmë hapësirën ruajtëse të vazhdueshme.
Për ruajtjen e vazhdueshme, ne kemi opsione të ndryshme zbatimi.
Nëse po funksionojmë në një ofrues cloud, për shembull, duke përdorur Amazon, Google, atëherë ekziston një tundim i madh për të përdorur hapësirën ruajtëse në cloud. Është shumë i përshtatshëm, është i mirë.
Dhe ka një opsion të dytë. Kjo është për ruajtjen lokale, kur kemi disqe lokale në secilën nyje. Ky opsion është shumë më i vështirë për t'u zbatuar, por në të njëjtën kohë është më produktiv.
Le të shohim se çfarë kemi në lidhje me ruajtjen e cloud.
Ka merita. Është shumë e lehtë për tu konfiguruar. Ne thjesht porosisim nga një ofrues i reve kompjuterike që ju lutemi të na jepni ruajtje të një kapaciteti të tillë, të një klase të tillë. Klasat pikturohen nga ofruesit në mënyrë të pavarur.
Dhe ka një pengesë. Për disa, kjo është një mangësi jokritike. Sigurisht, do të ketë disa mbivendosje të performancës. Është shumë i përshtatshëm për t'u përdorur, i besueshëm, por ka disa pengesa të mundshme në performancë.
Dhe që nga ajo kohë ClickHouse fokusohet në performancën, madje mund të thuash se shtrydh gjithçka që është e mundur, kështu që shumë klientë përpiqen të shtrydhin performancën maksimale.
Dhe për të përfituar sa më shumë prej saj, ne kemi nevojë për ruajtje lokale.
Kubernetes ofron tre abstraksione për përdorimin e ruajtjes lokale në Kubernetes. Kjo:
- EmptyDir
- HostPath.
- Lokal
Konsideroni se si ndryshojnë ato, si janë të ngjashme.
Së pari, në të tre qasjet, ne kemi ruajtje - këto janë disqe lokale që ndodhen në të njëjtën nyje fizike k8s. Por ata kanë disa dallime.
Le të fillojmë me më të thjeshtën, d.m.th. Çfarë është ajo në praktikë? Jemi ne që i kërkojmë sistemit të kontejnerizimit (më shpesh Docker) nga specifikimi ynë që të na sigurojë akses në një dosje në një disk lokal.
Në praktikë, docker krijon një dosje të përkohshme diku në shtigjet e veta, e quan atë një hash të gjatë. Dhe ofron një ndërfaqe për të hyrë në të.
Si do të jetë performanca? Kjo do të funksionojë me shpejtësinë e diskut lokal, d.m.th. kjo është akses i plotë në vidhën tuaj.
Por ky rast ka të metat e veta. Këmbëngulja në këtë rast është mjaft e dyshimtë. Në lëvizjen e parë të dokerit me kontejnerë, Persistent humbet. Nëse Kubernetes dëshiron ta zhvendosë këtë Pod në një disk tjetër për ndonjë arsye, atëherë të dhënat do të humbasin.
Kjo qasje është e mirë për teste, sepse tashmë tregon shpejtësi normale, por ky opsion nuk është i përshtatshëm për diçka serioze.
Prandaj, ekziston një qasje e dytë. Ky është hostPath. Nëse shikoni rrëshqitjen e mëparshme dhe këtë, mund të shihni vetëm një ndryshim. Dosja jonë e la dokerin direkt në nyjen Kubernetes. Këtu është pak më shpejt. Ne shkruajmë drejtpërdrejt shtegun në sistemin lokal të skedarëve ku do të dëshironim të ruanim të dhënat tona.
Kjo metodë ka përparësi. Ky është tashmë një Këmbëngulës i vërtetë, dhe një klasik. Në diskun tonë, të dhënat do të shkruhen në një adresë.
Ka edhe disavantazhe. Ky është kompleksiteti i menaxhimit. Kubernetët tanë mund të dëshirojnë ta zhvendosin Pod-in në një nyje tjetër fizike. Këtu hyn në lojë DevOps. Duhet t'i shpjegojë saktë të gjithë sistemit se mund t'i zhvendosni këto nyje vetëm në nyje të tilla në të cilat keni diçka të montuar përgjatë këtyre shtigjeve, dhe jo më shumë se një nyje në të njëjtën kohë. Është mjaft e vështirë.
Veçanërisht për këto qëllime, ne kemi bërë shabllone në operatorin tonë për të fshehur gjithë këtë kompleksitet. Dhe thjesht mund të thuash: "Unë dua të kem një shembull të ClickHouse për nyje fizike dhe përgjatë një rruge të tillë."
Por kjo nevojë nuk është vetëm për ne, kështu që zotërinjtë nga vetë Kubernetes e kuptojnë gjithashtu se njerëzit duan të kenë akses në disqe fizike, kështu që ata ofrojnë një nivel të tretë.
Quhet lokale. Praktikisht nuk ka asnjë ndryshim nga rrëshqitja e mëparshme. Vetëm më parë ishte e nevojshme të konfirmohej manualisht se ne nuk mund t'i transferojmë këto pods nga nyja në nyje, sepse ato duhet të bashkëngjiten përgjatë një shtegu në një disk fizik lokal, por tani e gjithë kjo njohuri është e kapsuluar në vetë Kubernetes. Dhe rezulton shumë më e lehtë për t'u konfiguruar.
Le të kthehemi në detyrën tonë praktike. Le të kthehemi te shablloni YAML. Këtu kemi një ruajtje të vërtetë. Ne i jemi kthyer kësaj. Ne vendosëm shabllonin klasik të VolumeClaim si në k8s. Dhe ne përshkruajmë se çfarë lloj ruajtjeje duam.
Pas kësaj, k8s do të kërkojë ruajtje. Na jepni atë në StatefulSet. Dhe në fund, do të dalë në dispozicion të ClickHouse.
Ne kishim një skemë të tillë. Magazinimi ynë i vazhdueshëm ishte i kuq, gjë që dukej se lë të kuptohet se duhej bërë.
Dhe bëhet e gjelbër. Tani skema e grupit ClickHouse në k8s është finalizuar plotësisht. Ne kemi copëza, kopje, ZooKeeper, kemi Persistent të vërtetë, i cili zbatohet në një mënyrë ose në një tjetër. Skema tashmë është plotësisht funksionale.
Ne vazhdojmë të jetojmë. Grupi ynë po rritet. Dhe Aleksey po provon dhe lëshon një version të ri të ClickHouse.
Një detyrë praktike lind - për të testuar versionin e ri të ClickHouse në grupin tonë. Dhe, sigurisht, nuk dua t'i shpërndaj të gjitha, dua të vendos një version të ri diku në këndin e largët në një kopje, ose ndoshta jo një version të ri, por dy menjëherë, sepse ato dalin shpesh.
Çfarë mund të themi për këtë?
Këtu kemi vetëm një mundësi të tillë. Këto janë shabllone pod. Mund të shkruani që operatori ynë ju lejon plotësisht të ndërtoni një grup heterogjen. Ato. konfiguroni, duke filluar nga të gjitha kopjet në një grup, duke përfunduar me secilën kopje personale, cilin version duam ClickHouse, cilin version duam ruajtjen. Ne mund ta konfigurojmë plotësisht grupin me konfigurimin që na nevojitet.
Le të futemi pak më thellë. Para kësaj, ne folëm se si funksionon operatori ClickHouse në lidhje me specifikat e ClickHouse.
Tani do të doja të them disa fjalë se si funksionon çdo operator në përgjithësi, si dhe se si ndërvepron me K8.
Merrni parasysh ndërveprimin me K8 për të filluar. Çfarë ndodh kur aplikojmë kubectl? Nëpërmjet API, objektet tona shfaqen në etj.
Për shembull, objektet bazë të Kubernetes: pod, StatefulSet, shërbimi dhe kështu me radhë përmes listës.
Megjithatë, asgjë fizike nuk po ndodh ende. Këto objekte duhet të materializohen në një grup.
Këtu hyn kontrollori. Kontrolluesi është një komponent i veçantë k8s që mund të materializojë këto përshkrime. Ai e di se si dhe çfarë të bëjë fizikisht. Ai e di se si të ekzekutojë kontejnerët, çfarë duhet të konfigurohet atje në mënyrë që serveri të funksionojë.
Dhe materializon objektet tona në K8.
Por ne duam të operojmë jo vetëm me pods, StatefulSets, ne duam të krijojmë një ClickHouseInstallation, domethënë një objekt të llojit ClickHouse, në mënyrë që të operojmë me të në tërësi. Deri më tani, nuk ka një mundësi të tillë.
Por K8s ka një tjetër gjë të bukur. Ne duam që ne të kemi një entitet kaq kompleks diku, në të cilin grupi ynë do të mblidhet nga pods dhe StatefulSet.
Dhe çfarë duhet bërë për këtë? Së pari, përkufizimi i burimeve të personalizuara hyn në skenë. Cfare eshte? Ky është një përshkrim për K8 që ju do të keni një lloj tjetër të dhënash që duam ta shtojmë në pod, StatefulSet, një burim i personalizuar që do të jetë kompleks brenda. Ky është një përshkrim i strukturës së të dhënave.
E dërgojmë atje edhe nëpërmjet kubectl application. Kubernetes e mori me kënaqësi.
Dhe tani në ruajtjen tonë, objekti në etcd ka mundësinë të shkruajë një burim të personalizuar të quajtur ClickHouseInstallation.
Por tani për tani, asgjë tjetër nuk do të ndodhë. Kjo do të thotë, nëse tani krijojmë një skedar YAML që kemi konsideruar me një përshkrim të copëzës, kopjet dhe themi "kubectl zbatohet", atëherë Kubernetes do ta pranojë atë, do ta vendosë në etcd dhe do të thotë: "Shkëlqyeshëm, por nuk e di. çfarë të bëni me të. Nuk di si të mirëmbaj ClickHouseInstallation."
Prandaj, ne kemi nevojë për dikë që të ndihmojë Kubernetes të shërbejë llojin e ri të të dhënave. Në të majtë kemi një kontrollues vendas Kubernetes që punon me llojet e të dhënave vendase. Dhe në të djathtë duhet të kemi një kontrollues të personalizuar që mund të punojë me llojet e të dhënave të personalizuara.
Dhe në një mënyrë tjetër quhet operator. Unë e nxora atë posaçërisht këtu për Kubernetes, sepse mund të ekzekutohet edhe jashtë K8s. Më shpesh, natyrisht, të gjitha deklaratat ekzekutohen në Kubernetes, por asgjë nuk e pengon atë të qëndrojë jashtë, kështu që këtu është nxjerrë posaçërisht.
Dhe tashmë, nga ana tjetër, kontrolluesi me porosi, i njohur gjithashtu si operatori, ndërvepron me Kubernetes përmes API. Ai tashmë e di se si të ndërveprojë me API. Dhe ai tashmë e di se si të materializojë një skemë komplekse që ne duam të bëjmë nga një burim i personalizuar. Kjo është pikërisht ajo që bën operatori.
Si funksionon operatori? Le të hedhim një vështrim në anën e djathtë për të parë se si e bën atë. Ne do të zbulojmë se si operatori i materializon të gjitha këto dhe si zhvillohet ndërveprimi i mëtejshëm me K8.
Operatori është programi. Ajo është e orientuar nga ngjarjet. Operatori pajtohet në ngjarje duke përdorur Kubernetes API. Kubernetes API ka pika hyrjeje ku mund të abonoheni në ngjarje. Dhe nëse diçka ndryshon në K8, atëherë Kubernetes u dërgon ngjarje të gjithëve, d.m.th. kush është abonuar në këtë pikë API do të marrë njoftime.
Operatori pajtohet në ngjarje dhe duhet të bëjë një lloj reagimi. Detyra e tij është të përgjigjet ndaj ngjarjeve në zhvillim.
Ngjarjet krijohen nga disa përditësime. Skedari ynë YAML mbërrin me një përshkrim të ClickHouseInstallation. Ai shkoi në etcd nëpërmjet kubectl application. Një ngjarje funksionoi atje, si rezultat, kjo ngjarje erdhi në operatorin ClickHouse. Operatori mori këtë përshkrim. Dhe ai duhet të bëjë diçka. Nëse një përditësim erdhi në objektin ClickHouseInstallation, atëherë duhet të përditësoni grupin. Dhe detyra e operatorit është të përditësojë grupin.
Çfarë po bën ai? Së pari, ne duhet të hartojmë një plan veprimi për atë që do të bëjmë me këtë përditësim. Përditësimet mund të jenë shumë të vogla, dmth. i vogël në ekzekutimin e YAML, por mund të çojë në ndryshime shumë të mëdha në grup. Prandaj, operatori krijon një plan, dhe më pas ai i përmbahet atij.
Ai fillon, sipas këtij plani, ta ziejë këtë strukturë brenda për të materializuar bishtajat, shërbimet, d.m.th. të bëjë atë që është detyra kryesore. Është si ndërtimi i një grupi ClickHouse në Kubernetes.
Tani le të prekim një gjë kaq interesante. Kjo është një ndarje përgjegjësie midis Kubernetes dhe operatorit, d.m.th. çfarë bën Kubernetes, çfarë bën operatori dhe si ndërveprojnë me njëri-tjetrin.
Kubernetes është përgjegjës për gjërat e sistemit, d.m.th. për një grup themelor objektesh që mund të interpretohen si një fushëveprimi i sistemit. Kubernetes di se si të fillojë pods, si të rifillojë kontejnerët, si të bëjë montimin e vëllimeve, si të punojë me ConfigMap, d.m.th. çdo gjë që mund të quhet sistem.
Operatorët operojnë në fusha lëndore. Çdo operator është krijuar për zonën e tij lëndore. Ne bëmë për ClickHouse.
Dhe operatori ndërvepron pikërisht për sa i përket fushës së temës, si shtimi i një kopjeje, krijimi i një skeme, vendosja e monitorimit. Ekziston një ndarje e tillë.
Le të shohim një shembull praktik se si ndodh kjo ndarje shqetësimesh kur bëjmë një veprim shtesë të kopjes.
Detyra i vjen operatorit - të shtojë një kopje. Çfarë po bën operatori? Operatori do të llogarisë se është e nevojshme të bëhet një StatefulSet i ri, në të cilin është e nevojshme të përshkruhen modele të tilla dhe të tilla, pretendim vëllimi.
Ai i përgatiti të gjitha dhe ia kalon K8-ve. Ai thotë se ka nevojë për ConfigMap, StatefulSet, Volume. Kubernetes po funksionon. Ai materializon njësitë bazë me të cilat operon.
Dhe pastaj ClickHouse-operatori hyn përsëri në lojë. Ai tashmë ka një pod fizik mbi të cilin ju tashmë mund të bëni diçka. Dhe ClickHouse-operatori përsëri funksionon në terma domeni. Ato. Konkretisht ClickHouse, për të përfshirë një kopje në një grup, së pari duhet të konfiguroni skemën e të dhënave që ekziston në këtë grup. Dhe së dyti, kjo kopje duhet të përfshihet në monitorim që të mund të gjurmohet qartë. Operatori tashmë e konfiguron këtë.
Dhe vetëm pas kësaj vjen në lojë vetë ClickHouse, d.m.th. një ent tjetër i nivelit më të lartë. Është tashmë një bazë të dhënash. Ajo ka shembullin e vet, kopjen tjetër të konfiguruar, e cila është gati për t'u bashkuar me grupin.
Rezulton se zinxhiri i ekzekutimit dhe ndarja e përgjegjësisë kur shtohet një kopje është mjaft i gjatë.
Ne vazhdojmë detyrat tona praktike. Nëse grupi ekziston tashmë, atëherë mund të migroni konfigurimin.
Ne e bëmë atë në mënyrë që të jetë e mundur të kalohet në xml ekzistuese, të cilën ClickHouse e kupton.
Mund të rregulloni mirë ClickHouse. Thjesht vendosja e zonës është ajo për të cilën fola kur shpjegova hostPath, ruajtjen lokale. Kjo është mënyra se si të bëni vendosjen e zonave në mënyrë korrekte.
Detyra tjetër praktike është monitorimi.
Nëse grupi ynë ndryshon, atëherë duhet të konfigurojmë periodikisht monitorimin.
Le të hedhim një vështrim në diagramin. Ne kemi konsideruar tashmë shigjetat e gjelbra këtu. Tani le të shohim shigjetat e kuqe. Kjo është mënyra se si ne duam të monitorojmë grupin tonë. Si futen metrikat nga grupi ClickHouse në Prometheus dhe më pas në Grafana.
Cili është problemi me monitorimin? Pse kjo paraqitet si një lloj arritjeje? Vështirësia qëndron tek dinamika. Kur kemi një grup dhe ai është statik, atëherë mund të vendosni monitorimin një herë dhe të mos shqetësoheni më.
Por nëse kemi shumë grupime, ose diçka po ndryshon vazhdimisht, atëherë procesi është dinamik. Dhe rikonfigurimi i vazhdueshëm i monitorimit është humbje burimesh dhe kohe; edhe thjesht dembel. Kjo duhet të automatizohet. Vështirësia është në dinamikën e procesit. Dhe operatori e automatizon këtë shumë mirë.
Si u zhvillua grupi ynë? Në fillim ai ishte i tillë.
Pastaj ai ishte i tillë.
Në fund, ai u bë i tillë.
Dhe monitorimi bëhet automatikisht nga operatori. Pika e vetme e hyrjes.
Dhe ne shikojmë vetëm daljen në pultin e Grafanës, se si vlon jeta e grupit tonë brenda.
Nga rruga, pulti i Grafana shpërndahet gjithashtu me operatorin tonë direkt në kodin burimor. Mund të lidheni dhe të përdorni. Kjo pamje e ekranit m'u dha nga DevOps-ët tanë.
Ku do të donim të shkonim më pas? Kjo:
- Zhvilloni automatizimin e testimit. Detyra kryesore është testimi i automatizuar i versioneve të reja.
- Ne gjithashtu dëshirojmë vërtet të automatizojmë integrimin me ZooKeeper. Dhe planifikon të integrohet me operatorin ZooKeeper. Ato. është shkruar një operator për ZooKeeper dhe është logjike që të dy operatorët të fillojnë të integrohen për të ndërtuar një zgjidhje më të përshtatshme.
- Ne duam të bëjmë shenja vitale më komplekse.
- E theksova me të gjelbër se ne kemi trashëgiminë e shablloneve në rrugë - KRYER, d.m.th. me lëshimin e ardhshëm të operatorit, tashmë do të kemi trashëgimi shabllon. Ky është një mjet i fuqishëm që ju lejon të ndërtoni konfigurime komplekse nga pjesët.
- Dhe ne duam të automatizojmë detyrat komplekse. Kryesorja është Re-sharding.
Le të bëjmë disa rezultate të ndërmjetme.
Çfarë marrim si rezultat? Dhe a ia vlen apo jo? A duhet të përpiqem të tërheq bazën e të dhënave në Kubernetes dhe të aplikoj operatorin në përgjithësi dhe operatorin Alitnity në veçanti.
Në dalje marrim:
- Thjeshtoni dhe automatizoni në mënyrë dramatike konfigurimin, vendosjen dhe mirëmbajtjen.
- Monitorim i integruar menjëherë.
- Dhe shabllone të kodifikuar të gatshëm për përdorim për situata komplekse. Tashmë veprimi i tipit për të shtuar një kopje nuk ka nevojë të bëhet me dorë. Kjo bëhet nga operatori.
Mbetet vetëm pyetja e fundit. Ne tashmë kemi një bazë të dhënash në Kubernetes, virtualizim. Po në lidhje me performancën e një zgjidhjeje të tillë, veçanërisht pasi ClickHouse është optimizuar për performancën?
Përgjigja është se gjithçka është në rregull! Nuk do të përshkruaj në detaje, kjo është tema e një raporti të veçantë.
Por ekziston një projekt i tillë si TSBS. Cila është detyra e saj kryesore? Ky është një test i performancës së bazës së të dhënave. Kjo është një përpjekje për të krahasuar të ngrohtë me të ngrohtë, të butë me të butë.
Si punon ai? Krijohet një grup i të dhënave. Pastaj ky grup të dhënash ekzekutohet në baza të ndryshme të dhënash duke përdorur të njëjtin grup testesh. Dhe çdo bazë të dhënash zgjidh një problem ashtu siç mundet. Dhe pastaj ju mund të krahasoni rezultatet.
Ai tashmë mbështet një grup të madh të bazave të të dhënave. Unë kam identifikuar tre kryesore. Kjo:
- timescaledb.
- InfluxDB.
- klikim shtëpie.
Një krahasim është bërë edhe me një zgjidhje tjetër të ngjashme. Krahasimi me RedShift. Krahasimi është bërë në Amazon. ClickHouse është gjithashtu shumë përpara të gjithëve në këtë çështje.
Çfarë përfundimesh mund të nxirren nga ajo që thashë?
- DB në Kubernetes është e mundur. Ndoshta, ju mund të bëni gjithçka, por në përgjithësi duket se mundeni. ClickHouse në Kubernetes është padyshim i mundur me ndihmën e operatorit tonë.
- Operatori ndihmon në automatizimin e proceseve dhe thjeshton vërtet jetën.
- Performanca është normale.
- Dhe, na duket se mund dhe duhet të përdoret.
Burim i hapur - bashkohuni me ne!
Siç thashë, operatori është një produkt tërësisht me kod të hapur, kështu që do të ishte shumë mirë që ta përdornin numrin maksimal të njerëzve. Bashkohu tani! Ju presim të gjithëve!
Faleminderit të gjithëve!
Pyetjet tuaja
Faleminderit për raportin! Emri im është Anton. Unë jam nga SEMrush. Po pyes veten se çfarë po ndodh me prerjet. Dëgjojmë për monitorim, por asgjë për prerjet, nëse flasim për të gjithë grupin. Për shembull, ne kemi një grup në harduer. Dhe ne përdorim prerje të centralizuara, e mbledhim atë në një grumbull të përbashkët me mjete standarde. Dhe pastaj nga atje marrim të dhëna që janë interesante për ne.
Pyetje e mirë, d.m.th. regjistrimi në listën e detyrave. Operatori ynë nuk e automatizon këtë ende. Është ende në zhvillim, projekti është ende mjaft i ri. Ne e kuptojmë nevojën për prerje. Kjo është gjithashtu një temë shumë e rëndësishme. Dhe ndoshta nuk është më pak e rëndësishme sesa monitorimi. Por i pari në listën për zbatim ishte monitorimi. Do të ketë prerje. Natyrisht, ne po përpiqemi të automatizojmë të gjitha aspektet e jetës së grupit. Prandaj, përgjigja është se për momentin operatori, për fat të keq, nuk di ta bëjë këtë, por është në plane, ne do ta bëjmë. Nëse dëshironi të bashkoheni, atëherë tërhiqni kërkesën, ju lutem.
Përshëndetje! Faleminderit për raportin! Unë kam një pyetje standarde në lidhje me vëllimet e vazhdueshme. Kur krijojmë një konfigurim me këtë operator, si e përcakton operatori se në cilën nyje kemi një disk ose dosje? Së pari duhet t'i shpjegojmë atij se, ju lutem, vendosni ClickHouse tonë pikërisht në këto nyje që kanë një disk?
Me sa kuptoj unë, kjo pyetje është një vazhdim i ruajtjes lokale, veçanërisht pjesa hostPath e saj. Kjo është njësoj si t'i shpjegosh të gjithë sistemit se pod duhet të lëshohet në një nyje të tillë, në të cilën kemi një disk të lidhur fizikisht, i cili është montuar përgjatë një rruge të tillë. Kjo është një pjesë e tërë që e preka shumë sipërfaqësisht sepse përgjigja atje është mjaft e madhe.
Shkurtimisht, duket kështu. Natyrisht, ne duhet të bëjmë sigurimin e këtyre vëllimeve. Për momentin, nuk ka asnjë dispozitë dinamike në ruajtjen lokale, kështu që DevOps duhet të prerë vetë disqet, këtu janë këto vëllime. Dhe ata duhet të shpjegojnë sigurimin e Kubernetes, se ju do të keni vëllime të vazhdueshme të një klase të tillë dhe të tillë, e cila ndodhet në nyjet e tilla dhe të tilla. Atëherë do të jetë e nevojshme t'i shpjegohet Kubernetes se pods që kërkojnë një klasë të tillë dhe të tillë të ruajtjes lokale duhet të planifikohen sipas etiketave vetëm për ato nyje. Për këto qëllime, operatori ka aftësinë të caktojë një lloj etikete dhe një për shembull pritës. Dhe rezulton se pods do të drejtohen nga Kubernetes për të ekzekutuar vetëm në nyje që plotësojnë kërkesat, etiketat, në terma të thjeshtë. Administratorët caktojnë etiketa, bëjnë sigurimin e disqeve me dorë. Dhe pastaj ajo shkallëzohet.
Dhe vetëm opsioni i tretë lokal ndihmon për ta bërë atë pak më të lehtë. Siç e kam theksuar tashmë, kjo është një punë e mundimshme akordimi, e cila në fund të fundit ndihmon për të marrë performancën maksimale.
Unë kam një pyetje të dytë në lidhje me këtë. Kubernetes u konceptua në atë mënyrë që për ne nuk ka rëndësi nëse humbim një nyje apo jo. Çfarë duhet të bëjmë në këtë rast nëse kemi humbur nyjen ku kemi një copëz?
Po, Kubernetes fillimisht u pozicionua se marrëdhënia jonë me bishtajat tona është si bagëtia, por këtu çdo disk bëhet diçka si një kafshë shtëpiake. Ekziston një problem i tillë që nuk mund t'i hedhim ato. Dhe zhvillimi i Kubernetes po shkon në atë drejtim që është e pamundur të trajtohet plotësisht filozofikisht, si një burim plotësisht i hedhur poshtë.
Tani një pyetje praktike. Çfarë duhet të bëni nëse keni humbur nyjen në të cilën ishte disku? Këtu problemi zgjidhet në një nivel më të lartë. Në rastin e ClickHouse, kemi kopje që funksionojnë në një nivel më të lartë, d.m.th. në nivelin ClickHouse.
Cila është dispozita? DevOps është përgjegjës për të siguruar që të dhënat të mos humbasin. Ai duhet të konfigurojë siç duhet replikimin dhe duhet të sigurojë që riprodhimi po funksionon. Në kopjen në nivelin ClickHouse, të dhënat duhet të dublikohen. Kjo nuk është detyra që zgjidh operatori. Dhe jo detyra që zgjidh vetë Kubernetes. Kjo është në nivelin ClickHouse.
Çfarë duhet të bëni nëse nyja juaj e hekurit ka rënë? Dhe rezulton se do të jetë e nevojshme të vendosni të dytin, të lëvizni siç duhet diskun në të, të aplikoni etiketa. Dhe pas kësaj, ai do të plotësojë kërkesat që Kubernetes në të mund të ekzekutojë një shembull pod. Kubernetes do ta nisë atë. Numri juaj i bishtajave nuk është i mjaftueshëm për atë të specifikuar. Do të kalojë ciklin që tregova. Dhe në nivelin më të lartë, ClickHouse do të kuptojë se kemi një kopje të futur, ajo është ende bosh dhe duhet të fillojmë transferimin e të dhënave në të. ato. ky proces është ende i automatizuar dobët.
Faleminderit për raportin! Kur ndodhin të gjitha llojet e gjërave të këqija, operatori rrëzohet dhe rifillon, dhe në atë moment mbërrijnë ngjarjet, a e përpunoni disi këtë?
Çfarë ndodh nëse operatori rrëzohet dhe rindizet, po?
Po. Dhe në atë moment erdhën ngjarjet.
Detyra se çfarë duhet bërë në këtë rast ndahet pjesërisht midis operatorit dhe Kubernetes. Kubernetes ka aftësinë të riprodhojë një ngjarje që ka ndodhur. Ai përsërit. Dhe detyra e operatorit është të sigurohet që kur regjistri i ngjarjeve të riprodhohet tek ai, këto ngjarje janë të pafuqishme. Dhe në mënyrë që rishfaqja e së njëjtës ngjarje të mos na prishë sistemin tonë. Dhe operatori ynë përballon këtë detyrë.
Përshëndetje! Faleminderit për raportin! Dmitry Zavialov, kompani Smedov. A është planifikuar të shtohen opsionet e personalizimit me haproksi te operatori? Një balancues tjetër është interesant përveç atij standardi, në mënyrë që të jetë i zgjuar dhe të kuptojë që ClickHouse është i vërtetë atje.
E ke fjalen per Ingress?
Po, zëvendësoni Ingress me haproksinë. Në haproksinë, mund të specifikoni topologjinë e grupimit ku ka kopje.
Deri tani nuk e kemi menduar. Nëse ju nevojitet dhe mund të shpjegoni pse është e nevojshme, atëherë do të jetë e mundur ta zbatoni atë, veçanërisht nëse dëshironi të merrni pjesë. Ne do të jemi të lumtur të shqyrtojmë opsionin. Përgjigja e shkurtër është jo, aktualisht nuk kemi një funksionalitet të tillë. Faleminderit për këshillën, ne do t'i hedhim një sy kësaj. Dhe nëse shpjegoni gjithashtu rastin e përdorimit dhe pse është i nevojshëm në praktikë, për shembull, krijoni probleme në GitHub, atëherë do të jetë mirë.
Tashmë ka.
Mirë. Jemi të hapur për çdo sugjerim. Dhe haproksi është vënë në listën e detyrave. Lista e detyrave po rritet, nuk po zvogëlohet ende. Por kjo është e mirë, do të thotë që produkti është në kërkesë.
Burimi: www.habr.com