Správa je venovaná praktickým otázkam vývoja operátora v Kubernetes, návrhu jeho architektúry a základných princípov fungovania.
V prvej časti správy sa budeme zaoberať:
- čo je operátor v Kubernetes a prečo je to potrebné;
- ako presne operátor zjednodušuje správu zložitých systémov;
- čo operátor môže a nemôže robiť.
Ďalej prejdime k diskusii o vnútornej štruktúre operátora. Pozrime sa na architektúru a fungovanie operátora krok za krokom. Pozrime sa na to podrobne:
- interakcia medzi operátorom a Kubernetes;
- aké funkcie operátor preberá a aké funkcie deleguje na Kubernetes.
Pozrime sa na správu fragmentov a databázových replík v Kubernetes.
Ďalej budeme diskutovať o problémoch s ukladaním údajov:
- ako pracovať s Perzistentným úložiskom z pohľadu operátora;
- úskalia používania lokálneho úložiska.
V záverečnej časti správy zvážime praktické príklady aplikácie so službou Amazon alebo Google Cloud Service. Správa je založená na príklade vývoja a prevádzkových skúseností operátora ClickHouse.
Video:
Volám sa Vladislav Klimenko. Dnes som chcel hovoriť o našich skúsenostiach s vývojom a prevádzkou operátora, a to je špecializovaný operátor na správu databázových klastrov. Napríklad na správu klastra ClickHouse.
Prečo máme možnosť hovoriť o operátorovi a ClickHouse?
- Podporujeme a rozvíjame ClickHouse.
- V súčasnosti sa snažíme pomaly prispieť k rozvoju ClickHouse. A sme na druhom mieste po Yandex, pokiaľ ide o objem zmien vykonaných v ClickHouse.
- Snažíme sa vytvárať ďalšie projekty pre ekosystém ClickHouse.
Chcel by som vám povedať o jednom z týchto projektov. Toto je o ClickHouse-operátor pre Kubernetes.
Vo svojej správe by som sa chcel dotknúť dvoch tém:
- Prvou témou je, ako funguje náš operátor správy databáz ClickHouse v Kubernetes.
- Druhou témou je, ako funguje ktorýkoľvek operátor, teda ako interaguje s Kubernetes.
Tieto dve otázky sa však budú v mojej správe prelínať.
Kto by mal záujem počúvať, čo sa snažím povedať?
- Najviac to bude zaujímať tých, ktorí prevádzkujú operátorov.
- Alebo pre tých, ktorí si chcú vytvoriť svoj vlastný, aby pochopili, ako to interne funguje, ako operátor komunikuje s Kubernetes a aké úskalia sa môžu objaviť.
Aby ste čo najlepšie pochopili, o čom dnes budeme diskutovať, je dobré vedieť, ako Kubernetes funguje, a absolvovať základné školenie v cloude.
Čo je ClickHouse? Ide o stĺpcovú databázu so špecifickými funkciami pre online spracovanie analytických dopytov. A je to úplne open source.
A pre nás je dôležité vedieť len dve veci. Musíte vedieť, že ide o databázu, takže to, čo vám poviem, bude platiť takmer pre každú databázu. A skutočnosť, že ClickHouse DBMS sa veľmi dobre škáluje, poskytuje takmer lineárnu škálovateľnosť. A preto je stav klastra pre ClickHouse prirodzený stav. A najviac nás zaujíma diskusia o tom, ako obsluhovať klaster ClickHouse v Kubernetes.
Prečo je tam potrebný? Prečo to nemôžeme ďalej prevádzkovať sami? A odpovede sú čiastočne technické a čiastočne organizačné.
- V praxi sa čoraz častejšie stretávame so situáciou, že vo veľkých firmách sú už takmer všetky komponenty v Kubernetes. Databázy zostávajú vonku.
- A čoraz častejšie sa kladie otázka: "Dá sa to umiestniť dovnútra?" Veľké spoločnosti sa preto snažia dosiahnuť maximálne zjednotenie riadenia, aby mohli rýchlo spravovať svoje dátové sklady.
- A to pomáha najmä vtedy, ak potrebujete maximálnu možnosť zopakovať si to isté na novom mieste, teda maximálnu prenosnosť.
Aké ľahké alebo ťažké je to? To sa dá, samozrejme, urobiť ručne. Nie je to však také jednoduché, pretože máme ďalšiu zložitosť správy samotného Kubernetes, ale zároveň sa prekrývajú špecifiká ClickHouse. A takáto agregácia má za následok.
A to všetko dohromady dáva pomerne veľkú množinu technológií, ktoré sa dajú pomerne ťažko spravovať, pretože Kubernetes prináša do prevádzky svoje vlastné každodenné problémy a ClickHouse svoje vlastné problémy každodennej prevádzky. Najmä ak máme niekoľko ClickHouses a musíme s nimi neustále niečo robiť.
S dynamickou konfiguráciou má ClickHouse pomerne veľký počet problémov, ktoré vytvárajú neustále zaťaženie DevOps:
- Keď chceme v ClickHouse niečo zmeniť, napríklad pridať repliku alebo úlomok, potom musíme spravovať konfiguráciu.
- Potom zmeňte dátovú schému, pretože ClickHouse má špecifickú metódu shardingu. Tam musíte rozložiť dátový diagram, rozložiť konfigurácie.
- Musíte si nastaviť monitorovanie.
- Zbieranie logov na nové črepy, na nové repliky.
- Postarajte sa o obnovu.
- A reštartujte.
Toto sú rutinné úlohy, ktorých používanie by som naozaj rád zjednodušil.
Samotný Kubernetes pomáha v prevádzke dobre, ale na základných systémových veciach.
Kubernetes je dobrý v uľahčovaní a automatizácii vecí ako:
- Recovery.
- Reštart.
- Správa úložného systému.
To je dobré, to je správny smer, ale je úplne bezradný v tom, ako prevádzkovať databázový klaster.
Chceme viac, chceme, aby celá databáza fungovala v Kubernetes.
Chcel by som získať niečo ako jedno veľké magické červené tlačidlo, ktoré stlačíte a klaster s každodennými úlohami, ktoré je potrebné vyriešiť, je nasadený a udržiavaný počas celého životného cyklu. Klaster ClickHouse v Kubernetes.
A snažili sme sa nájsť riešenie, ktoré by pomohlo uľahčiť prácu. Toto je ClickHouse-operátor pre Kubernetes od Altinity.
Operátor je program, ktorého hlavnou úlohou je riadiť ostatné programy, t.j. je manažérom.
A obsahuje vzorce správania. Môžete to nazvať kodifikovanými znalosťami o danej oblasti.
A jeho hlavnou úlohou je uľahčiť život DevOps a zredukovať mikromanažment, aby (DevOps) už myslel na vysokej úrovni, t.j. aby sa (DevOps) nezapájal do mikromanažmentu, aby nekonfiguroval všetky podrobnosti ručne.
A práve operátor je robotický asistent, ktorý sa zaoberá mikroúlohami a pomáha DevOps.
Prečo potrebujete operátora? Obzvlášť dobre sa mu darí v dvoch oblastiach:
- Keď špecialista, ktorý sa zaoberá ClickHouse, nemá dostatok skúseností, ale už potrebuje ovládať ClickHouse, operátor vám uľahčí prevádzku a umožní vám prevádzkovať klaster ClickHouse s pomerne zložitou konfiguráciou bez toho, aby ste príliš zachádzali do podrobností o tom, ako to celé funguje. vnútri. Stačí mu zadať úlohy na vysokej úrovni a funguje to.
- A druhá úloha, v ktorej sa darí najlepšie, je, keď je potrebné automatizovať veľké množstvo typických úloh. Odstraňuje mikroúlohy od správcov systému.
To najviac potrebujú buď tí, ktorí svoju cestu len začínajú, alebo tí, ktorí potrebujú veľa automatizovať.
Ako sa prístup založený na operátoroch líši od iných systémov? Je tu Helm. Pomáha tiež nainštalovať ClickHouse; môžete kresliť kormidlo grafy, ktoré dokonca nainštalujú celý klaster ClickHouse. Aký je potom rozdiel medzi operátorom a tým istým, napríklad Helmom?
Hlavný zásadný rozdiel je v tom, že Helm je správa balíkov a Operator ide o krok ďalej. Ide o podporu počas celého životného cyklu. Toto nie je len inštalácia, sú to každodenné úlohy, ktoré zahŕňajú škálovanie, sharding, teda všetko, čo je potrebné urobiť počas životného cyklu (ak je to potrebné, tak aj vymazanie) - o tom všetkom rozhoduje operátor. Pokúša sa automatizovať a udržiavať celý životný cyklus softvéru. To je jeho zásadný rozdiel od iných riešení, ktoré sú prezentované.
To bola úvodná časť, poďme ďalej.
Ako vybudujeme nášho operátora? Snažíme sa pristupovať k problému tak, aby sme spravovali klaster ClickHouse ako jeden zdroj.
Tu máme vstupné údaje na ľavej strane obrázku. Ide o YAML s klastrovou špecifikáciou, ktorá sa odovzdáva Kubernetes klasickým spôsobom cez kubectl. Tam to vyzdvihne náš operátor a urobí svoje kúzla. A na výstupe dostaneme nasledujúcu schému. Toto je implementácia ClickHouse v Kubernetes.
A potom sa pomaly pozrieme na to, ako presne operátor funguje, aké typické úlohy sa dajú riešiť. Budeme brať do úvahy iba typické úlohy, pretože máme obmedzený čas. A nie o všetkom, o čom môže operátor rozhodnúť, sa bude diskutovať.
Začnime z praxe. Náš projekt je úplne open source, takže si môžete pozrieť, ako funguje na GitHub. A môžete vychádzať z úvah, že ak ho chcete len spustiť, môžete začať s Sprievodcom rýchlym spustením.
Ak chcete porozumieť podrobne, potom sa snažíme udržiavať dokumentáciu vo viac-menej slušnej forme.
Začnime praktickým problémom. Prvou úlohou, s ktorou chceme všetci začať, je nejakým spôsobom spustiť prvý príklad. Ako môžem spustiť ClickHouse pomocou operátora, aj keď v skutočnosti neviem, ako to funguje? Píšeme manifest, pretože... Všetka komunikácia s k8s je komunikácia prostredníctvom manifestov.
Toto je taký zložitý manifest. To, čo sme zvýraznili červenou farbou, je to, na čo sa musíme zamerať. Požiadame operátora, aby vytvoril klaster s názvom demo.
Toto sú zatiaľ základné príklady. Skladovanie ešte nebolo popísané, no k skladovaniu sa vrátime o niečo neskôr. Zatiaľ budeme sledovať dynamiku vývoja klastra.
Vytvorili sme tento manifest. Dodávame to nášmu operátorovi. Pracoval, čaroval.
Pozeráme sa na konzolu. Tri komponenty sú zaujímavé: modul, dve služby a StatefulSet.
Operátor zapracoval a my vidíme, čo presne vytvoril.
Vytvára niečo takéto. Máme StatefulSet, Pod, ConfigMap pre každú repliku, ConfigMap pre celý klaster. Služby sú potrebné ako vstupné body do klastra.
Služby sú centrálnou službou Load Balancer a možno ich použiť aj pre každú repliku, pre každý zlomok.
Náš základný klaster vyzerá asi takto. Je z jedného jediného uzla.
Poďme ďalej a skomplikujme veci. Musíme rozdrviť klaster.
Naše úlohy rastú, začína sa dynamika. Chceme pridať črep. Sledujeme vývoj. Meníme našu špecifikáciu. Naznačíme, že chceme dva črepy.
Ide o ten istý súbor, ktorý sa dynamicky vyvíja s rastom systému. Skladovanie nie, o skladovaní sa bude diskutovať ďalej, toto je samostatná téma.
Nakŕmime operátora YAML a uvidíme, čo sa stane.
Operátor premýšľal a vytvoril nasledujúce entity. Už máme dva moduly, tri služby a zrazu 2 stavové sady. Prečo 2 StatefulSets?
Na diagrame to bolo takto - toto je náš počiatočný stav, keď sme mali jeden lusk.
Stalo sa to takto. Zatiaľ je všetko jednoduché, bolo to duplikované.
A prečo vznikli dva StatefulSets? Tu musíme odbočiť a prediskutovať otázku, ako sa v Kubernetes spravujú Pody.
Existuje objekt s názvom StatefulSet, ktorý vám umožňuje vytvoriť sadu modulov zo šablóny. Kľúčovým faktorom je tu šablóna. A môžete spustiť veľa modulov pomocou jednej šablóny v jednej StatefulSet. A kľúčovou frázou je „veľa strukov pre jednu šablónu“.
A bolo tu veľké pokušenie vytvoriť celý klaster a zbaliť ho do jednej StatefulSet. Bude to fungovať, nie je s tým problém. Je tu však jedna výhrada. Ak chceme zostaviť heterogénny klaster, teda z viacerých verzií ClickHouse, začnú sa vynárať otázky. Áno, StatefulSet môže vykonať priebežnú aktualizáciu a tam môžete uviesť novú verziu, vysvetliť, že nemusíte vyskúšať viac ako toľko uzlov súčasne.
Ale ak extrapolujeme úlohu a povieme, že chceme vytvoriť úplne heterogénny klaster a nechceme prejsť zo starej verzie na novú pomocou priebežnej aktualizácie, ale jednoducho chceme vytvoriť heterogénny klaster z hľadiska rôznych verzií ClickHouse a z hľadiska rôzneho úložiska. Chceme napríklad urobiť nejaké repliky na samostatných diskoch, na pomalých, vo všeobecnosti, úplne vybudovať heterogénny klaster. A vzhľadom na skutočnosť, že StatefulSet vytvára štandardizované riešenie z jednej šablóny, neexistuje spôsob, ako to urobiť.
Po premýšľaní sme sa rozhodli, že to urobíme takto. Každú repliku máme vo svojom vlastnom StatefulSet. Toto riešenie má určité nevýhody, ale v praxi je všetko úplne zapuzdrené operátorom. A tých výhod je veľa. Môžeme vytvoriť presne taký klaster, aký chceme, napríklad absolútne heterogénny. Preto v klastri, v ktorom máme dva úlomky s jednou replikou, budeme mať 2 stavové sady a 2 pody práve preto, že sme tento prístup zvolili z dôvodov uvedených vyššie, aby sme mohli postaviť heterogénny klaster.
Vráťme sa k praktickým problémom. V našom klastri potrebujeme nakonfigurovať užívateľov, t.j. musíte urobiť nejakú konfiguráciu ClickHouse v Kubernetes. Prevádzkovateľ na to poskytuje všetky možnosti.
Môžeme si napísať, čo chceme, priamo v YAML. Všetky možnosti konfigurácie sú mapované priamo z tohto YAML do konfigurácií ClickHouse, ktoré sú potom distribuované v rámci klastra.
Môžete to napísať takto. Toto je napr. Heslo je možné zašifrovať. Podporované sú absolútne všetky možnosti konfigurácie ClickHouse. Tu je len príklad.
Konfigurácia klastra je distribuovaná ako ConfigMap. V praxi sa aktualizácia ConfigMap neuskutoční okamžite, takže ak je klaster veľký, proces presunutia konfigurácie nejaký čas trvá. Ale to všetko je veľmi pohodlné na použitie.
Skomplikujme si úlohu. Klaster sa rozvíja. Chceme replikovať dáta. To znamená, že už máme dva fragmenty, každý po jednej replike, a používatelia sú nakonfigurovaní. Rastieme a chceme robiť replikáciu.
Čo potrebujeme na replikáciu?
Potrebujeme ZooKeepera. V ClickHouse je replikácia vytvorená pomocou ZooKeeper. ZooKeeper je potrebný na to, aby rôzne repliky ClickHouse mali konsenzus o tom, ktoré dátové bloky sú na ktorom ClickHouse.
ZooKeeper môže používať ktokoľvek. Ak má podnik externý ZooKeeper, možno ho použiť. Ak nie, môžete si ho nainštalovať z nášho úložiska. Existuje inštalátor, ktorý celú vec uľahčuje.
A interakčný diagram celého systému vyzerá takto. Ako platformu máme Kubernetes. Spustí operátor ClickHouse. Tu som si predstavil ZooKeeper. A operátor spolupracuje s ClickHouse aj ZooKeeperom. To znamená, že výsledky interakcie.
A to všetko je potrebné na to, aby ClickHouse úspešne replikoval dáta v k8s.
Pozrime sa teraz na samotnú úlohu, na to, ako bude vyzerať manifest na replikáciu.
Do nášho manifestu pridávame dve sekcie. Prvým je, kde získať ZooKeeper, ktorý môže byť buď vnútri Kubernetes alebo externý. Toto je len popis. A objednávame repliky. Tie. chceme dve repliky. Celkovo by sme mali mať na výstupe 4 strúčiky. Pamätáme si skladovanie, vráti sa o niečo neskôr. Skladovanie je samostatný príbeh.
Bolo to takto.
Stáva sa to takto. Sú pridané repliky. 4. sa nezmestila, veríme, že by ich tam mohlo byť veľa. A na stranu je pridaný ZooKeeper. Schémy sú čoraz zložitejšie.
A je čas pridať ďalšiu úlohu. Pridáme trvalé úložisko.
Pre trvalé úložisko máme rôzne možnosti.
Ak bežíme v cloudovom poskytovateľovi, napríklad pomocou Amazon, Google, potom je tu veľké pokušenie použiť cloudové úložisko. Je to veľmi pohodlné, je to dobré.
A je tu aj druhá možnosť. Toto je pre lokálne úložisko, keď máme lokálne disky na každom uzle. Táto možnosť je oveľa náročnejšia na implementáciu, ale zároveň je produktívnejšia.
Pozrime sa, čo máme v súvislosti s cloudovým úložiskom.
Existujú výhody. Konfigurácia je veľmi jednoduchá. Jednoducho si objednáme od poskytovateľa cloudu, ktorý nám poskytne úložisko takej a takej kapacity, takej a takej triedy. Kurzy plánujú poskytovatelia nezávisle.
A je tu aj nevýhoda. Pre niektorých je to nekritická nevýhoda. Samozrejme, vyskytnú sa nejaké problémy s výkonom. Je to veľmi pohodlné a spoľahlivé, ale existujú určité potenciálne výkonnostné nevýhody.
A preto ClickHouse sa zameriava špeciálne na produktivitu, dalo by sa dokonca povedať, že vyžmýka všetko, čo sa dá, a preto sa mnohí klienti snažia vyžmýkať maximálnu produktivitu.
A aby sme z neho vyťažili maximum, potrebujeme lokálne úložisko.
Kubernetes poskytuje tri abstrakcie na používanie lokálneho úložiska v Kubernetes. toto:
- EmptyDir
- HostPath.
- Miestne
Pozrime sa, v čom sa líšia a v čom sú si podobné.
Po prvé, vo všetkých troch prístupoch máme úložisko - to sú lokálne disky, ktoré sú umiestnené na rovnakom fyzickom uzle k8s. Ale majú určité rozdiely.
Začnime tým najjednoduchším, t.j. emptyDir. Čo je to v praxi? V našej špecifikácii žiadame kontajnerizačný systém (najčastejšie Docker), aby nám poskytol prístup k priečinku na lokálnom disku.
V praxi Docker vytvorí dočasný priečinok niekde pozdĺž svojich vlastných ciest a nazýva ho dlhý hash. A poskytuje rozhranie na prístup k nemu.
Ako to bude fungovať z hľadiska výkonu? Toto bude fungovať pri rýchlosti lokálneho disku, t.j. Toto je úplný prístup k vašej skrutke.
Ale tento prípad má svoju nevýhodu. Trvalý je v tejto veci dosť pochybný. Pri prvom presune Dockera s kontajnermi sa funkcia Persistent stratí. Ak chce Kubernetes z nejakého dôvodu presunúť tento Pod na iný disk, údaje sa stratia.
Tento prístup je dobrý pre testy, pretože už ukazuje normálnu rýchlosť, ale pre niečo vážne táto možnosť nie je vhodná.
Preto existuje druhý prístup. Toto je hostPath. Ak sa pozriete na predchádzajúcu snímku a túto, môžete vidieť iba jeden rozdiel. Náš priečinok sa presunul z Dockera priamo do uzla Kubernetes. Tu je to trochu jednoduchšie. Priamo špecifikujeme cestu na lokálnom súborovom systéme, kam by sme chceli uložiť naše dáta.
Táto metóda má výhody. Toto je už skutočný Persistent a ešte k tomu klasický. Dáta budeme mať nahraté na disku na nejakej adrese.
Existujú aj nevýhody. Toto je zložitosť riadenia. Naše Kubernetes možno budú chcieť presunúť Pod do iného fyzického uzla. A tu prichádza do hry DevOps. Musí správne vysvetliť celému systému, že tieto pody je možné presúvať len do tých uzlov, na ktorých máte niečo namontované pozdĺž týchto ciest a nie viac ako jeden uzol naraz. Je to dosť ťažké.
Špeciálne pre tieto účely sme u nášho operátora vytvorili šablóny, aby sme všetku túto zložitosť skryli. A môžete jednoducho povedať: „Chcem mať jednu inštanciu ClickHouse pre každý fyzický uzol a pozdĺž takej a takej cesty.“
Ale nie sme jediní, kto túto potrebu potrebuje, takže aj páni zo samotného Kubernetes chápu, že ľudia chcú mať prístup k fyzickým diskom, preto poskytujú tretiu vrstvu.
Volá sa to miestne. Od predchádzajúcej snímky nie je prakticky žiadny rozdiel. Iba predtým bolo potrebné manuálne potvrdiť, že tieto moduly nemôžeme preniesť z uzla do uzla, pretože musia byť pripojené pozdĺž nejakej cesty k lokálnemu fyzickému disku, ale teraz sú všetky tieto znalosti zapuzdrené v samotnom Kubernetes. A ukazuje sa, že je oveľa jednoduchšie konfigurovať.
Vráťme sa k nášmu praktickému problému. Vráťme sa k šablóne YAML. Tu máme skutočné úložisko. Sme späť pri tom. Nastavili sme klasickú šablónu VolumeClaim ako v k8s. A popíšeme, aké úložisko chceme.
Potom k8s požiada o uloženie. Pridelí nám ho v StatefulSet. A nakoniec to bude k dispozícii ClickHouse.
Mali sme túto schému. Naše trvalé úložisko bolo červené, čo naznačovalo, že to treba urobiť.
A zmení sa na zelenú. Teraz je klastrová schéma ClickHouse na k8s úplne dokončená. Máme črepy, repliky, ZooKeeper, máme skutočného Persistenta, ktorý je implementovaný tak či onak. Schéma je už plne funkčná.
Žijeme ďalej. Náš klaster sa rozvíja. A Alexey to skúša a vydáva novú verziu ClickHouse.
Vzniká praktická úloha – otestovať novú verziu ClickHouse na našom klastri. A, prirodzene, nechcete to všetko rozbaliť; chcete dať novú verziu v jednej replike niekde vo vzdialenom rohu a možno nie jednu novú verziu, ale dve naraz, pretože vychádzajú často.
Čo na to povedať?
Tu máme práve takúto príležitosť. Toto sú šablóny pod. Môžete napísať, že náš operátor vám úplne umožňuje vybudovať heterogénny klaster. Tie. konfigurovať, počnúc všetkými replikami v skupine, končiac každou osobnou replikou, akú verziu chceme ClickHouse, akú verziu chceme úložisko. Môžeme plne nakonfigurovať klaster s konfiguráciou, ktorú potrebujeme.
Poďme trochu hlbšie dovnútra. Predtým sme hovorili o tom, ako funguje ClickHouse-operátor vo vzťahu k špecifikám ClickHouse.
Teraz by som chcel povedať pár slov o tom, ako každý operátor vo všeobecnosti funguje, ako aj o tom, ako interaguje s K8.
Najprv sa pozrime na interakciu s K8. Čo sa stane, keď aplikujeme kubectl? Naše objekty sa zobrazujú v etcd cez API.
Napríklad základné objekty Kubernetes: pod, StatefulSet, služba atď.
Zároveň sa zatiaľ nič fyzické nedeje. Tieto objekty musia byť materializované v zhluku.
Na tento účel sa zobrazí ovládač. Ovládač je špeciálny komponent k8s, ktorý dokáže tieto popisy zhmotniť. Vie, ako a čo má fyzicky robiť. Vie, ako spúšťať kontajnery, čo tam treba nakonfigurovať, aby server fungoval.
A zhmotňuje naše objekty v K8.
Chceme však operovať nielen s modulmi a StatefulSets, chceme vytvoriť ClickHouseInstallation, teda objekt typu ClickHouse, aby sme s ním fungovali ako s jedným celkom. Zatiaľ takáto možnosť neexistuje.
Ale K8s má nasledujúcu peknú vec. Chceme, aby sme mali niekde, ako je táto komplexná entita, v ktorej by bol náš klaster zostavený z modulov a StatefulSet.
A čo je pre to potrebné urobiť? Najprv prichádza na scénu definícia vlastného zdroja. Čo to je? Toto je popis pre K8, že budete mať ešte jeden typ údajov, že chceme pridať vlastný zdroj do modulu, StatefulSet, ktorý bude vo vnútri zložitý. Toto je popis štruktúry údajov.
Posielame tam aj cez kubectl apply. Kubernetes to s radosťou zobral.
A teraz v našom úložisku má objekt v etcd možnosť zaznamenať vlastný zdroj s názvom ClickHouseInstallation.
Ale zatiaľ sa nič viac nestane. To znamená, že ak teraz vytvoríme súbor YAML, ktorý sme si prezreli s popisom fragmentov a replík, a povieme „použite kubectl“, potom ho Kubernetes prijme, vloží ho do etcd a povie: „Skvelé, ale neviem, čo mám robiť s tým. Neviem, ako udržiavať ClickHouseInstallation.“
Preto potrebujeme niekoho, kto pomôže Kubernetes obsluhovať nový typ údajov. Vľavo máme natívny ovládač Kubernetes, ktorý pracuje s natívnymi typmi údajov. A na pravej strane by sme mali mať vlastný ovládač, ktorý dokáže pracovať s vlastnými typmi údajov.
A iným spôsobom sa nazýva operátor. Konkrétne som to sem zaradil ako Kubernetes, pretože sa dá spustiť aj mimo K8. Najčastejšie sú samozrejme všetci operátori vykonávaní v Kubernetes, ale nič mu nebráni stáť vonku, takže tu je to špeciálne presunuté von.
A na druhej strane, vlastný ovládač, tiež známy ako operátor, komunikuje s Kubernetes cez API. Už vie, ako interagovať s API. A už vie, ako zhmotniť zložitý obvod, ktorý chceme vyrobiť z vlastného zdroja. Presne to robí operátor.
Ako funguje operátor? Pozrime sa na pravú stranu, ako to robí. Poďme zistiť, ako to všetko operátor zhmotňuje a ako dochádza k ďalšej interakcii s K8.
Operátor je program. Je zameraná na udalosti. Operátor sa prihlasuje na odber udalostí pomocou Kubernetes API. Kubernetes API má vstupné body, kde sa môžete prihlásiť na odber udalostí. A ak sa niečo zmení v K8s, tak Kubernetes posiela udalosti všetkým, t.j. každý, kto sa prihlásil na odber tohto bodu API, bude dostávať upozornenia.
Operátor sa prihlási na odber udalostí a musí urobiť nejakú reakciu. Jeho úlohou je reagovať na vznikajúce udalosti.
Udalosti sú generované určitými aktualizáciami. Prichádza náš súbor YAML s popisom ClickHouseInstallation. Išiel do etcd cez kubectl apply. Tam bola spustená udalosť a v dôsledku toho sa táto udalosť dostala k prevádzkovateľovi ClickHouse. Operátor dostal tento popis. A musí niečo urobiť. Ak prišla aktualizácia pre objekt ClickHouseInstallation, musíte aktualizovať klaster. A úlohou operátora je aktualizovať klaster.
Čo robí? Najprv musíme vypracovať akčný plán toho, čo urobíme s touto aktualizáciou. Aktualizácie môžu byť veľmi malé, t.j. malý pri vykonávaní YAML, ale môže znamenať veľmi veľké zmeny v klastri. Operátor si preto vytvorí plán a ten sa potom drží.
Podľa tohto plánu začne vo vnútri variť túto štruktúru, aby sa zhmotnili lusky, služby, t.j. robiť to, čo je jeho hlavnou úlohou. Takto vytvoríte klaster ClickHouse v Kubernetes.
Teraz sa dotknime takejto zaujímavej veci. Ide o rozdelenie zodpovednosti medzi Kubernetes a prevádzkovateľa, t.j. čo robí Kubernetes, čo robí operátor a ako medzi sebou interagujú.
Kubernetes je zodpovedný za systémové veci, t.j. pre základný súbor objektov, ktoré možno interpretovať ako systémový rozsah. Kubernetes vie ako spúšťať pody, ako reštartovať kontajnery, ako pripájať zväzky, ako pracovať s ConfigMap, t.j. všetko, čo sa dá nazvať systémom.
Operátori pôsobia v doménach. Každý operátor je vytvorený pre svoju vlastnú oblasť. Urobili sme to pre ClickHouse.
A operátor interaguje presne z hľadiska predmetnej oblasti, ako je pridanie repliky, vytvorenie diagramu, nastavenie monitorovania. To má za následok rozdelenie.
Pozrime sa na praktický príklad toho, ako k tomuto rozdeleniu zodpovednosti dochádza, keď vykonáme akciu pridania repliky.
Operátor dostane úlohu – pridať repliku. Čo robí operátor? Operátor vypočíta, že je potrebné vytvoriť nový StatefulSet, v ktorom musia byť popísané také a také šablóny, objemový nárok.
Všetko to pripravil a odovzdáva K8s. Hovorí, že potrebuje ConfigMap, StatefulSet, Volume. Kubernetes funguje. Zhmotňuje základné jednotky, s ktorými operuje.
A potom opäť prichádza do hry ClickHouse-operátor. Už má fyzický lusk, na ktorom už niečo dokáže. A ClickHouse-operátor opäť funguje v doménových podmienkach. Tie. Konkrétne ClickHouse, ak chcete zahrnúť repliku do klastra, musíte najprv nakonfigurovať schému údajov, ktorá existuje v tomto klastri. A po druhé, táto replika musí byť zahrnutá do monitorovania, aby sa dala jasne vysledovať. Operátor to už konfiguruje.
A až potom príde na rad samotný ClickHouse, t.j. iná entita vyššej úrovne. Toto už je databáza. Má svoju vlastnú inštanciu, ďalšiu nakonfigurovanú repliku, ktorá je pripravená na pripojenie ku klastru.
Ukazuje sa, že reťazec vykonávania a rozdelenia zodpovednosti pri pridávaní repliky je pomerne dlhý.
Pokračujeme v praktických úlohách. Ak už máte klaster, môžete migrovať konfiguráciu.
Urobili sme to tak, že môžete vložiť existujúce xml, ktorému ClickHouse rozumie.
ClickHouse môžete doladiť. Práve zónované nasadenie je to, o čom som hovoril pri vysvetľovaní hostPath, lokálneho úložiska. Takto sa správne robí zónové nasadenie.
Ďalšou praktickou úlohou je monitorovanie.
Ak sa náš klaster zmení, musíme pravidelne konfigurovať monitorovanie.
Pozrime sa na diagram. Už sme sa tu pozreli na zelené šípky. Teraz sa pozrime na červené šípky. Takto chceme monitorovať náš klaster. Ako sa metriky z klastra ClickHouse dostanú do Prometheus a potom do Grafany.
Aký je problém s monitorovaním? Prečo sa to prezentuje ako nejaký úspech? Náročnosť spočíva v dynamike. Keď máme jeden klaster a je statický, tak si môžeme nastaviť monitoring raz a už sa netrápime.
Ale ak máme veľa zhlukov, alebo sa niečo neustále mení, tak je proces dynamický. A neustále prestavovanie monitorovania je strata prostriedkov a času, t.j. aj len lenivosť. Toto treba zautomatizovať. Problém spočíva v dynamike procesu. A operátor to veľmi dobre automatizuje.
Ako sa vyvíjal náš klaster? Na začiatku bol taký.
Potom bol takýto.
Nakoniec sa stal takýmto.
A monitorovanie vykonáva automaticky operátor. Jediný vstupný bod.
A práve pri výstupe sa pozrieme na palubnú dosku Grafana, aby sme videli, ako vrie život nášho klastra.
Mimochodom, Grafana dashboard je distribuovaný aj u nášho operátora priamo v zdrojovom kóde. Môžete pripojiť a používať. Náš DevOps mi dal túto snímku obrazovky.
Kam by sme chceli ísť ďalej? toto:
- Vyvinúť automatizáciu testovania. Hlavnou úlohou je automatizované testovanie nových verzií.
- Tiež naozaj chceme automatizovať integráciu so ZooKeeperom. A existujú plány na integráciu s operátorom ZooKeeper. Tie. Pre ZooKeeper bol napísaný operátor a je logické, že sa títo dvaja operátori začali integrovať, aby vytvorili pohodlnejšie riešenie.
- Chceme robiť zložitejšie vitálne funkcie.
- Zelenou farbou som zvýraznil, že sa blížime k dedeniu šablón - HOTOVO, t.j. s ďalším vydaním operátora už budeme mať dedenie šablón. Ide o výkonný nástroj, ktorý vám umožňuje zostavovať zložité konfigurácie z dielikov.
- A chceme automatizáciu zložitých úloh. Hlavným je Re-sharding.
Zoberme si medzivýsledky.
Čo získame ako výsledok? A oplatí sa to robiť alebo nie? Je vôbec potrebné skúsiť pretiahnuť databázu do Kubernetes a použiť operátora všeobecne a operátora Alitnity konkrétne?
Na výstupe dostaneme:
- Výrazné zjednodušenie a automatizácia konfigurácie, nasadenia a údržby.
- Okamžite zabudovaný monitoring.
- A kodifikované šablóny pripravené na použitie pre zložité situácie. Akciu ako pridanie repliky nie je potrebné vykonávať ručne. Operátor to robí.
Zostáva už len posledná otázka. V Kubernetes už máme databázu, virtualizáciu. Ako je to s výkonom takéhoto riešenia, najmä preto, že ClickHouse je optimalizovaný na výkon?
Odpoveď je, že všetko je v poriadku! Nebudem zachádzať do podrobností, toto je téma samostatnej správy.
Ale existuje taký projekt ako TSBS. Čo je jeho hlavnou úlohou? Toto je test výkonu databázy. Toto je pokus o porovnanie teplého s teplým, mäkkého s mäkkým.
ako pracuje? Vygeneruje sa jeden súbor údajov. Potom sa táto sada údajov spustí v rôznych databázach pomocou rovnakej sady testov. A každá databáza rieši jeden problém tak, ako vie. A potom môžete porovnávať výsledky.
Už podporuje veľké množstvo databáz. Identifikoval som tri hlavné. toto:
- Časová mierkaDB.
- InfluxDB.
- ClickHouse.
Bolo urobené porovnanie aj s iným podobným riešením. Porovnanie s RedShift. Porovnanie bolo urobené na Amazone. ClickHouse je v tejto veci tiež ďaleko pred všetkými.
Aké závery možno vyvodiť z toho, čo som povedal?
- DB v Kubernetes je možný. Pravdepodobne je možné čokoľvek, ale celkovo to vyzerá, že je to možné. ClickHouse v Kubernetes je určite možný s pomocou nášho operátora.
- Operátor pomáha automatizovať procesy a skutočne uľahčuje život.
- Výkon je normálny.
- A zdá sa nám, že sa to dá a malo by sa použiť.
Open source – pridajte sa k nám!
Ako som už povedal, operátor je úplne open source produkt, takže by bolo veľmi dobré, keby ho využívalo maximum ľudí. Pripoj sa k nám! Čakáme na vás všetkých!
Ďakujem všetkým!
otázky
Ďakujeme za správu! Volám sa Anton. Som zo SEMrush. Zaujímalo by ma, ako je to s ťažbou dreva. Počuli sme o monitorovaní, ale nič o protokolovaní, ak hovoríme o celom klastri. Napríklad sme vytvorili klaster týkajúci sa hardvéru. A používame centralizované protokolovanie a zhromažďujeme ich do spoločnej haldy pomocou štandardných prostriedkov. A odtiaľ získame údaje, ktoré nás zaujímajú.
Dobrá otázka, teda prihlásenie sa do zoznamu úloh. Náš operátor to zatiaľ neautomatizuje. Stále sa rozvíja, projekt je ešte dosť mladý. Chápeme potrebu ťažby dreva. Toto je tiež veľmi dôležitá téma. A pravdepodobne to nie je o nič menej dôležité ako monitorovanie. Ale na prvom mieste na zozname na implementáciu bolo monitorovanie. Bude prebiehať ťažba dreva. Prirodzene sa snažíme automatizovať všetky aspekty života klastra. Preto odpoveď je, že momentálne to operátor, žiaľ, nevie urobiť, ale je to v pláne, my to urobíme. Ak sa chcete pripojiť, vytiahnite žiadosť.
Ahoj! Ďakujeme za správu! Mám štandardnú otázku týkajúcu sa trvalých objemov. Keď vytvoríme konfiguráciu s týmto operátorom, ako operátor určí, na ktorom uzle máme pripojený konkrétny disk alebo priečinok? Najprv mu musíme vysvetliť, že prosím umiestnite náš ClickHouse na tieto uzly, ktoré majú disk?
Pokiaľ som pochopil, táto otázka je pokračovaním lokálneho úložiska, najmä jeho časti hostPath. To je ako vysvetliť celému systému, že pod treba spustiť na takom a takom uzle, ku ktorému máme fyzicky pripojený disk, ktorý je pripevnený po takej a takej ceste. Toto je celá časť, ktorej som sa dotkol veľmi povrchne, pretože odpoveď je tam dosť veľká.
Skrátka to vyzerá takto. Prirodzene, tieto objemy musíme zabezpečiť. Momentálne neexistuje žiadne dynamické ustanovenie v lokálnom úložisku, takže DevOps musí znížiť samotné disky, tieto zväzky. A musia vysvetliť poskytovanie Kubernetes, že budete mať trvalé zväzky takej a takej triedy, ktoré sa nachádzajú na takých a takých uzloch. Potom budete musieť Kubernetesovi vysvetliť, že moduly, ktoré vyžadujú takú a takú triedu lokálneho úložiska, musia byť nasmerované iba na také a také uzly pomocou štítkov. Na tieto účely má operátor možnosť priradiť nejaký druh označenia a jeden na hostiteľskú inštanciu. A ukázalo sa, že moduly Kubernetes budú smerovať tak, aby bežali iba na uzloch, ktoré jednoducho spĺňajú požiadavky, označenia. Správcovia priraďujú menovky a poskytujú disky manuálne. A potom sa to škáluje.
A je to tretia možnosť, miestna, ktorá to trochu zjednoduší. Ako som už zdôraznil, ide o starostlivú prácu na ladení, ktorá v konečnom dôsledku pomáha dosiahnuť maximálny výkon.
S tým súvisí aj druhá otázka. Kubernetes bol navrhnutý tak, že nám nezáleží na tom, či stratíme uzol alebo nie. Čo máme robiť v tomto prípade, ak sme stratili uzol, kde visí náš črep?
Áno, Kubernetes bol pôvodne postavený tak, že náš vzťah s našimi tobolkami je ako dobytok, ale tu sa s nami každý disk stáva niečím ako domácim miláčikom. Je tu taký problém, že ich nemôžeme len tak vyhodiť. A vývoj Kubernetes ide tým smerom, že sa s ním nedá úplne filozoficky zaobchádzať, ako keby to bol úplne vyradený zdroj.
Teraz prakticka otazka. Čo robiť, ak ste stratili uzol, na ktorom bol disk? Tu sa problém rieši na vyššej úrovni. V prípade ClickHouse máme repliky, ktoré fungujú na vyššej úrovni, t.j. na úrovni ClickHouse.
Aká je výsledná dispozícia? DevOps je zodpovedný za zabezpečenie toho, že sa údaje nestratia. Musí správne nastaviť replikáciu a musí zabezpečiť, aby replikácia bežala. Replika na úrovni ClickHouse musí mať duplicitné údaje. Toto nie je problém, ktorý operátor rieši. A nie problém, ktorý rieši samotný Kubernetes. Toto je na úrovni ClickHouse.
Čo robiť, ak vám odpadne železný uzol? A ukázalo sa, že budete musieť nainštalovať druhý, správne naň umiestniť disk a použiť štítky. A potom bude spĺňať požiadavky, aby na ňom Kubernetes mohol spustiť inštanciu pod. Kubernetes to spustí. Váš počet modulov nestačí na dodržanie určeného počtu. Prejde cyklom, ktorý som ukázal. A na najvyššej úrovni ClickHouse pochopí, že sme zadali repliku, tá je zatiaľ prázdna a musíme do nej začať prenášať dáta. Tie. Tento proces ešte nie je dostatočne automatizovaný.
Ďakujeme za správu! Keď sa dejú všelijaké nepekné veci, operátor sa zrúti a reštartuje a v tom momente prídu udalosti, zvládate to nejako?
Čo sa stane, ak operátor havaruje a reštartuje sa, však?
Áno. A v tej chvíli prišli udalosti.
Úloha, čo robiť v tomto prípade, je čiastočne rozdelená medzi operátora a Kubernetes. Kubernetes má schopnosť prehrať udalosť, ktorá nastala. Prehráva. A úlohou operátora je uistiť sa, že keď sa mu prehrá denník udalostí, tieto udalosti sú idempotentné. A aby opakovaný výskyt tej istej udalosti nezlomil náš systém. A náš operátor sa s touto úlohou vyrovná.
Ahoj! Ďakujeme za správu! Dmitrij Zavyalov, spol Smedová. Plánuje sa pridať operátorovi možnosť konfigurácie pomocou haproxy? Mal by som záujem o nejaký iný balancer okrem štandardného, aby bol šikovný a pochopil, že ClickHouse tam naozaj je.
Hovoríte o Ingress?
Áno, nahraďte Ingress haproxy. V haproxy môžete špecifikovať topológiu klastra, kde má repliky.
Zatiaľ sme nad tým nerozmýšľali. Ak to potrebujete a viete vysvetliť, prečo je to potrebné, potom to bude možné realizovať, najmä ak sa chcete zúčastniť. Radi zvážime možnosť. Krátka odpoveď je nie, v súčasnosti takúto funkčnosť nemáme. Ďakujeme za tip, budeme sa touto záležitosťou zaoberať. A ak vysvetlíte aj prípad použitia a prečo je to potrebné v praxi, napríklad vytvoríte problémy na GitHub, bude to skvelé.
Už má.
Dobre. Sme otvorení akýmkoľvek návrhom. A hapoxy je pridaný do zoznamu úloh. Zoznam úloh rastie, zatiaľ sa nezmenšuje. Ale to je dobré, to znamená, že produkt je žiadaný.
Zdroj: hab.com