Zpráva je věnována praktickým otázkám vývoje operátora v Kubernetes, návrhu jeho architektury a základním principům fungování.
V první části zprávy se budeme zabývat:
- co je operátor v Kubernetes a proč je potřeba;
- jak přesně operátor zjednodušuje správu složitých systémů;
- co operátor může a co operátor nemůže.
Dále přejděme k diskuzi o vnitřní struktuře operátoru. Zvažte architekturu a fungování operátora krok za krokem. Pojďme analyzovat podrobně:
- interakce mezi operátorem a Kubernetes;
- jaké funkce operátor přebírá a co deleguje na Kubernetes.
Zvažte správu fragmentů a replik databází v Kubernetes.
Dále probereme problémy s ukládáním dat:
- jak pracovat s Perzistentním úložištěm z pohledu operátora;
- úskalí používání místního úložiště.
V závěrečné části zprávy se budeme zabývat praktickými příklady aplikace se službou Amazon nebo Google Cloud Service. Zpráva je založena na příkladu vývoje a provozních zkušeností operátora pro ClickHouse.
Video:
Jmenuji se Vladislav Klimenko. Dnes jsem chtěl mluvit o našich zkušenostech s vývojem a provozem operátora, a to je specializovaný operátor pro správu databázových clusterů. Například ke správě clusteru ClickHouse.
Proč máme možnost mluvit o operátorovi a ClickHouse?
- Podporujeme a vyvíjíme ClickHouse.
- V tuto chvíli se snažíme pomalu přispívat k rozvoji ClickHouse. A jsme druzí po Yandexu, pokud jde o množství změn provedených v ClickHouse.
- Snažíme se dělat další projekty pro ekosystém ClickHouse.
Rád bych hovořil o jednom z těchto projektů. Toto je o ClickHouse-operátor pro Kubernetes.
Ve své zprávě bych se rád dotkl dvou témat:
- Prvním tématem je, jak funguje náš databázový operátor ClickHouse v Kubernetes.
- Druhým tématem je, jak funguje kterýkoli operátor, tedy jak interaguje s Kubernetes.
Tyto dvě otázky se však budou v mé zprávě prolínat.
Kdo by měl zájem slyšet, co se snažím říct?
- Nejzajímavější budou ti, kteří vykořisťují operátory.
- Nebo pro ty, kteří si chtějí vytvořit vlastní, aby pochopili, jak to uvnitř funguje, jak operátor komunikuje s Kubernetes a jaká úskalí se mohou objevit.
Abyste co nejlépe porozuměli tomu, o čem dnes budeme diskutovat, bylo by hezké vědět, jak Kubernetes funguje, a mít základní znalosti z cloud computingu.
Co je ClickHouse? Jedná se o sloupcovou databázi se specifiky v online zpracování analytických dotazů. A je to zcela open source.
A potřebujeme vědět jen dvě věci. Musíte vědět, že se jedná o databázi, takže to, co vám řeknu, bude platit téměř pro každou databázi. A skutečnost, že ClickHouse DBMS se velmi dobře škáluje, poskytuje téměř lineární škálovatelnost. A proto je stav clusteru pro ClickHouse přirozený stav. A nejvíce nás zajímá diskuse o tom, jak obsluhovat cluster ClickHouse v Kubernetes.
Proč je tam potřeba? Proč to nemůžeme dál provozovat sami? A odpovědi jsou částečně technické a částečně organizační.
- V praxi se stále častěji setkáváme s takovou situací, kdy ve velkých společnostech jsou téměř všechny komponenty již v Kubernetes. Zůstaňte databáze venku.
- A stále častěji se objevuje otázka: „Lze to umístit dovnitř?“. Velké společnosti se proto snaží o maximální unifikaci řízení, aby mohly rychle spravovat své datové sklady.
- A to pomáhá zejména v případě, že potřebujete maximální možnost opakovat to samé na novém místě, tedy maximální přenositelnost.
Jak snadné nebo obtížné to je? To lze samozřejmě provést ručně. To ale není tak jednoduché, protože sečteme složitost správy samotného Kubernetes, ale zároveň jsou vnucena specifika ClickHouse. A ukazuje se taková agregace.
A dohromady to dává poměrně velkou sadu technologií, které už teď začíná být docela obtížné spravovat, protože Kubernetes přináší své každodenní problémy do provozu a ClickHouse přináší své problémy do každodenního provozu. Zvláště pokud máme několik ClickHouses a potřebujeme s nimi neustále něco dělat.
ClickHouse s dynamickou konfigurací má poměrně velký počet problémů, které vytvářejí konstantní zatížení DevOps:
- Když chceme v ClickHouse něco změnit, například přidat repliku, shard, pak musíme spravovat konfiguraci.
- Poté změňte schéma dat, protože ClickHouse má specifickou metodu shardingu. Tam je potřeba rozvrhnout datové schéma, rozvrhnout konfigurace.
- Musíte nastavit sledování.
- Sběr klád na nové střepy, na nové repliky.
- Postarejte se o zotavení.
- A restartujte.
Jsou to takové rutinní práce, které bych velmi rád usnadnil v provozu.
Samotný Kubernetes hodně pomáhá v provozu, ale na základních systémových věcech.
Kubernetes je skvělý v usnadňování a automatizaci věcí jako:
- Zotavení.
- Restartujte.
- Správa úložiště.
To je dobře, to je správný směr, ale on je úplně mimo, jak provozovat databázový cluster.
Chci víc, chci, aby nám v Kubernetes fungovala celá databáze.
Chtěl bych získat něco jako jedno velké magické červené tlačítko, které stisknete a máte cluster nasazený a udržovaný po celý životní cyklus s každodenními úkoly, které je třeba vyřešit. Cluster ClickHouse v Kubernetes.
A snažili jsme se vytvořit řešení, které by pomohlo usnadnit práci. Toto je ClickHouse-operátor pro Kubernetes od Altinity.
Operátor je program, jehož hlavním úkolem je správa ostatních programů, to znamená, že je manažerem.
A obsahuje vzorce chování. Můžete to nazvat kodifikovanými znalostmi o dané oblasti.
A jeho hlavním úkolem je usnadnit život DevOps a omezit mikromanagement tak, aby (DevOps) už myslel na vysoké úrovni, tedy aby (DevOps) nemikromanažoval, aby ručně nenastavoval všechny podrobnosti.
A právě operátor je robotický asistent, který se potýká s mikroúkoly a pomáhá DevOps.
Proč je potřeba operátor? Vyniká ve dvou oblastech:
- Když specialista ClickHouse nemá dostatek zkušeností, ale je již nutné provozovat ClickHouse, operátor usnadní obsluhu a umožní provozovat ClickHouse cluster s poměrně složitou konfigurací, aniž by se příliš rozepisoval o tom, jak to celé uvnitř funguje. . Prostě mu dáte úkoly na vysoké úrovni a funguje to.
- A druhý úkol, ve kterém se nejlépe projevuje, je, když je potřeba zautomatizovat velké množství typických úkolů. Odstraňuje mikroúlohy ze systémových administrátorů.
To nejvíce potřebují buď ti, kteří svou cestu teprve začínají, nebo ti, kteří potřebují hodně automatizovat.
Jaký je rozdíl mezi přístupem založeným na operátorovi a jinými systémy? Existuje také Helm. Pomáhá také nainstalovat ClickHouse, můžete kreslit grafy kormidla, které dokonce nainstalují celý cluster ClickHouse. Jaký je tedy rozdíl mezi operátorem a od téhož např. Helmem?
Hlavní zásadní rozdíl je v tom, že Helm je o správě balíků a operátor jde ještě o krok dál. To je podpora celého životního cyklu. Nejedná se pouze o instalaci, jedná se o každodenní úkony, které zahrnují škálování, sharding, tedy vše, co je třeba během životního cyklu udělat (v případě potřeby i odstranění) – o tom všem rozhoduje provozovatel. Snaží se automatizovat a obsluhovat celý životní cyklus softwaru. To je jeho zásadní rozdíl od ostatních prezentovaných řešení.
To byla úvodní část, pojďme dál.
Jak postavíme našeho operátora? Snažíme se přistupovat k problému, abychom mohli klastr ClickHouse spravovat jako jeden zdroj.
Zde máme vstupní data na levé straně obrázku. Jedná se o YAML s clusterovou specifikací, která se klasicky předává přes kubectl do Kubernetes. Tam to náš operátor zvedne a udělá svá kouzla. A v důsledku toho dostaneme takové schéma. Toto je implementace ClickHouse v Kubernetes.
A pak se pomalu podíváme na to, jak operátor pracuje, jaké typické úlohy lze řešit. Budeme zvažovat pouze typické úkoly, protože máme omezený čas. A nebude řečeno o všem, co může operátor rozhodnout.
Začněme z praxe. Náš projekt je kompletně open source, takže se můžete podívat, jak funguje na GitHubu. A můžete vycházet z úvah, pokud chcete jen začít, pak můžete začít s Rychlou úvodní příručkou.
Pokud chcete rozumět podrobně, pak se snažíme dokumentaci udržovat ve víceméně slušné podobě.
Začněme praktickým problémem. Prvním úkolem, se kterým všichni chceme začít, je nějak spustit první příklad. Jak spustit ClickHouse s pomocí operátora, aniž byste věděli, jak to funguje? Píšeme manifest, protože veškerá komunikace s k8s je komunikace prostřednictvím manifestů.
Tady je takový složitý manifest. To, co jsme zvýraznili červeně, je to, na co se musíme zaměřit. Požádáme operátora, aby vytvořil cluster s názvem demo.
Toto jsou zatím základní příklady. Skladování ještě nebylo popsáno, ale k ukládání se vrátíme o něco později. Vývoj shluku budeme zatím sledovat v dynamice.
Vytvořili jsme tento manifest. Podáváme to našemu operátorovi. Pracoval, dělal kouzla.
Díváme se na konzoli. Zajímavé jsou tři komponenty - jsou to Pod, dvě Service-a, StatefulSet.
Operátor fungoval a my vidíme, co přesně vytvořil.
Vytvoří něco takového. Máme StatefulSet, Pod, ConfigMap pro každou repliku, ConfigMap pro celý cluster. Nezbytně služby jako vstupní body do clusteru.
Služby jsou centrální službou Load Balancer a jsou možné pro každou repliku, pro každý fragment.
Tady náš základní cluster vypadá nějak takto. Je z jednoho uzlu.
Pojďme dále, zkomplikujeme. Cluster musíte rozstříhat.
Naše úkoly rostou, začíná dynamika. Chceme přidat střípek. Sledujeme vývoj. Měníme naši specifikaci. Naznačíme, že chceme dva střepy.
Jedná se o stejný soubor, který dynamicky vyvíjíme s růstem systému. Neexistuje žádné úložiště, o skladování bude řeč dále, toto je samostatná otázka.
Nakrmíme operátora YAML a uvidíme, co se stane.
Operátor přemýšlel a vytvořil následující entity. Už máme dva moduly, tři služby a najednou 2 stavové sady. Proč 2 StatefulSets?
Na diagramu to bylo takto - to je náš počáteční stav, kdy jsme měli jeden lusk.
Stalo se to takto. Zatím je vše jednoduché, bylo to zdvojené.
A proč se ze StatefulSet staly dva? Zde musíme odbočit a prodiskutovat otázku, jak jsou Pody spravovány v Kubernetes.
Existuje takový objekt nazvaný StatefulSet, který umožňuje vytvořit sadu Podů ze šablony. Klíčovým faktorem je zde šablona. A můžete spustit mnoho Podů v jedné StatefulSet podle jedné šablony. A klíčová fráze je zde „jedna šablona mnoho podů“.
A bylo velké pokušení vytvořit celý cluster a zabalit jej do jedné StatefulSet. Bude to fungovat, není v tom žádný problém. Ale je tu jedno upozornění. Pokud chceme sestavit heterogenní cluster, tedy z několika verzí ClickHouse, pak začínají naše otázky. Ano, StatefulSet může provádět průběžnou aktualizaci, ale tam můžete zavést novou verzi, vysvětlit, že nemusíte vyzkoušet více než tolik uzlů současně.
Pokud ale extrapolujeme úlohu a řekneme, že chceme vytvořit zcela heterogenní cluster a nechceme pomocí průběžné aktualizace měnit ze staré verze na novou, ale jednoduše chceme vytvořit heterogenní cluster jak z hlediska různých verzí ClickHouse a pokud jde o různé úložiště. Chceme například udělat nějaké repliky na samostatných discích, na pomalých, obecně, kompletně postavit heterogenní cluster. A vzhledem k tomu, že StatefulSet dělá standardizované řešení z jedné šablony, tak to nejde nijak udělat.
Po chvíli přemýšlení jsme se rozhodli, že to uděláme takhle. Každou repliku máme ve své vlastní StatefulSet. Toto řešení má určité nevýhody, ale v praxi to vše zcela zapouzdřuje operátora. A má to spoustu výhod. Můžeme postavit úplně takový shluk, jaký chceme, třeba absolutně heterogenní. Proto v clusteru, ve kterém máme dva střepy s jednou replikou, budeme mít 2 StatefulSets a 2 Pody právě proto, že jsme tento přístup zvolili kvůli výše uvedeným důvodům pro schopnost sestavit heterogenní cluster.
Vraťme se k praktickým úkolům. V našem clusteru potřebujeme nakonfigurovat uživatele, tzn. musíte provést nějakou konfiguraci ClickHouse v Kubernetes. Provozovatel k tomu poskytuje všechny možnosti.
Můžeme si přímo v YAML napsat, co chceme. Všechny možnosti konfigurace jsou přímo mapovány z tohoto YAML do konfigurací ClickHouse, které jsou poté nasazeny v celém clusteru.
Můžete psát i takto. Toto je příklad. Heslo lze zašifrovat. Jsou podporovány absolutně všechny možnosti konfigurace ClickHouse. Zde je jen příklad.
Konfigurace clusteru je distribuována jako ConfigMap. V praxi neproběhne aktualizace ConfigMap okamžitě, takže pokud existuje velký cluster, proces předání konfigurace nějakou dobu trvá. Ale to vše je velmi pohodlné použití.
Úkol komplikujeme. Klastr se rozvíjí. Chceme replikovat data. To znamená, že již máme dva fragmenty, každý po jedné replikě, uživatelé jsou nakonfigurováni. Rosteme a chceme se replikovat.
Co potřebujeme k replikaci?
Potřebujeme ZooKeeper. V ClickHouse je replikace vytvořena pomocí ZooKeeper. ZooKeeper je potřeba k tomu, aby různé repliky ClickHouse měly shodu na tom, které datové bloky jsou na kterém ClickHouse.
ZooKeeper může používat kdokoli. Pokud má podnik externí ZooKeeper, lze jej použít. Pokud ne, můžete nainstalovat z našeho úložiště. Existuje instalační program, který celou věc usnadňuje.
A schéma interakce celého systému dopadá takto. Jako platformu máme Kubernetes. Spustí operátor ClickHouse. ZooKeeper, kterého jsem si zde vyfotil. A operátor spolupracuje s ClickHouse i ZooKeeperem. To znamená, že se získá interakce.
A to vše je nezbytné pro to, aby ClickHouse úspěšně replikoval data do k8s.
Podívejme se nyní na samotný úkol, jak bude vypadat manifest pro replikaci.
Do našeho manifestu přidáváme dvě sekce. První je, kde získat ZooKeeper, který může být buď uvnitř Kubernetes, nebo externí. Toto je jen popis. A objednáváme repliky. Tito. chceme dvě repliky. Celkem bychom měli mít na výstupu 4 lusky. Pamatujeme na skladování, vrátí se o něco dále. Úložiště je samostatná skladba.
Bylo to takhle.
Stává se to takto. Jsou přidány repliky. 4. se nevešla, věříme, že jich může být hodně. A na straně je přidán ZooKeeper. Vzory jsou stále složitější.
A je čas přidat další úkol. Přidáme trvalé úložiště.
Pro trvalé úložiště máme různé možnosti implementace.
Pokud běžíme v cloudovém poskytovateli, například pomocí Amazon, Google, pak je velké pokušení využít cloudové úložiště. Je to velmi pohodlné, je to dobré.
A je tu druhá možnost. To je pro lokální úložiště, kdy máme na každém uzlu lokální disky. Tato možnost je mnohem obtížnější implementovat, ale zároveň je produktivnější.
Podívejme se, co máme ohledně cloudového úložiště.
Jsou tam zásluhy. Je velmi snadné jej nakonfigurovat. Jednoduše objednáme od poskytovatele cloudu, který nám prosím poskytne úložiště takové a takové kapacity, takové a takové třídy. Třídy jsou malovány poskytovateli nezávisle.
A je tu nevýhoda. Pro některé je to nekritický nedostatek. Samozřejmostí budou nějaké výkonnostní překryvy. Je velmi pohodlné použití, spolehlivé, ale existují určité potenciální nedostatky ve výkonu.
A od té doby ClickHouse se zaměřuje na výkon, dá se dokonce říci, že vymáčkne vše, co se dá, a tak se mnoho klientů snaží vyždímat maximum výkonu.
A abychom z toho vytěžili maximum, potřebujeme místní úložiště.
Kubernetes poskytuje tři abstrakce pro použití místního úložiště v Kubernetes. Tento:
- EmptyDir
- HostPath.
- Místní
Zvažte, jak se liší, jak jsou podobné.
Za prvé, ve všech třech přístupech máme úložiště - to jsou místní disky, které jsou umístěny na stejném fyzickém uzlu k8s. Ale mají určité rozdíly.
Začněme tím nejjednodušším, tedy prázdným adresářem. Co je to v praxi? Jsme to my, kdo žádá kontejnerizační systém (nejčastěji Docker) z naší specifikace, aby nám poskytl přístup ke složce na lokálním disku.
V praxi docker vytvoří dočasnou složku někde ve svých vlastních cestách, nazývá ji dlouhý hash. A poskytuje rozhraní pro přístup.
Jak si povede z hlediska výkonu? To poběží rychlostí lokálního disku, tzn. toto je plný přístup k vašemu šroubu.
Tento případ má ale svou nevýhodu. Vytrvalost je v tomto případě spíše pochybná. Při prvním pohybu dockeru s kontejnery se Persistent ztratí. Pokud chce Kubernetes z nějakého důvodu přesunout tento Pod na jiný disk, data budou ztracena.
Tento přístup je dobrý pro testy, protože již ukazuje normální rychlost, ale tato možnost není vhodná pro něco vážného.
Proto existuje druhý přístup. Toto je hostPath. Pokud se podíváte na předchozí snímek a tento, můžete vidět pouze jeden rozdíl. Naše složka opustila docker přímo do uzlu Kubernetes. Tady je to trochu rychlejší. Přímo zapíšeme cestu do místního souborového systému, kam bychom chtěli naše data uložit.
Tato metoda má výhody. Tohle už je opravdový Persistent, a to klasický. Na našem disku budou data zapsána na nějakou adresu.
Existují i nevýhody. To je složitost řízení. Naše Kubernetes může chtít přesunout Pod do jiného fyzického uzlu. Zde přichází na řadu DevOps. Musí to celému systému správně vysvětlit, že tyto pody můžete přesouvat pouze do takových uzlů, na kterých máte po těchto drahách něco namontovaného, a ne více než jeden uzel najednou. Je to dost těžké.
Speciálně pro tyto účely jsme u našeho operátora vytvořili šablony, abychom všechny tyto složitosti skryli. A můžete jen říct: "Chci mít jednu instanci ClickHouse na fyzický uzel a podél takové a takové cesty."
Tato potřeba ale není jen pro nás, takže i pánové ze samotného Kubernetes chápou, že lidé chtějí mít přístup k fyzickým diskům, a tak poskytují třetí úroveň.
Říká se tomu místní. Oproti předchozímu snímku není prakticky žádný rozdíl. Pouze dříve bylo nutné rukama provést, že tyto pody nemůžeme přenášet z uzlu do uzlu, protože musí být připojeny po takové a takové cestě k místnímu fyzickému disku, a nyní jsou všechny tyto znalosti zapouzdřeny v samotném Kubernetes. A ukazuje se, že konfigurace je mnohem jednodušší.
Vraťme se k našemu praktickému úkolu. Vraťme se k šabloně YAML. Tady máme skutečné úložiště. Vracíme se k tomu. Nastavili jsme klasickou šablonu VolumeClaim jako v k8s. A popíšeme, jaké úložiště chceme.
Poté k8s požádá o uložení. Přidělte nám jej ve StatefulSet. A nakonec se ukáže, že má k dispozici ClickHouse.
Měli jsme takové schéma. Naše trvalé úložiště bylo červené, což naznačovalo, že by se to mělo udělat.
A zezelená. Nyní je klastrové schéma ClickHouse na k8s plně dokončeno. Máme střepy, repliky, ZooKeeper, máme skutečný Persistent, který je implementován tak či onak. Schéma je již plně funkční.
Žijeme dál. Náš klastr se rozrůstá. A Aleksey zkouší a vydává novou verzi ClickHouse.
Vyvstává praktický úkol – otestovat novou verzi ClickHouse na našem clusteru. A samozřejmě, nechci to všechno rozbalit, chci dát novou verzi někam do vzdáleného rohu v jedné replice, nebo možná ne jednu novou verzi, ale dvě najednou, protože vycházejí často.
Co k tomu můžeme říci?
Tady máme právě takovou příležitost. Toto jsou šablony pod. Můžete malovat, náš operátor vám zcela umožňuje sestavit heterogenní cluster. Tito. konfigurovat, počínaje všemi replikami ve skupině, konče každou osobní replikou, jakou verzi chceme ClickHouse, jakou verzi chceme úložiště. Cluster můžeme plně nakonfigurovat v takové konfiguraci, jakou potřebujeme.
Pojďme trochu hlouběji dovnitř. Předtím jsme hovořili o tom, jak funguje ClickHouse-operátor ve vztahu ke specifikům ClickHouse.
Nyní bych rád řekl pár slov o tom, jak kterýkoli operátor obecně funguje, a také o tom, jak interaguje s K8.
Nejprve zvažte interakci s K8. Co se stane, když aplikujeme kubectl? Prostřednictvím API se naše objekty objevují v etcd.
Například základní objekty Kubernetes: pod, StatefulSet, služba a tak dále prostřednictvím seznamu.
Nic fyzického se však zatím neděje. Tyto objekty musí být materializovány ve shluku.
Zde přichází na řadu ovladač. Ovladač je speciální komponenta k8s, která může tyto popisy zhmotnit. Ví, jak a co má fyzicky dělat. Ví, jak spouštět kontejnery, co je tam potřeba nakonfigurovat, aby server fungoval.
A zhmotňuje naše objekty v K8s.
My ale chceme operovat nejen s pody, StatefulSets, chceme vytvořit ClickHouseInstallation, tedy objekt typu ClickHouse, abychom s ním mohli pracovat jako s celkem. Zatím taková možnost není.
K8s má ale ještě jednu příjemnou věc. Chceme, abychom někde měli takovou komplexní entitu, ve které by se náš cluster skládal z podů a StatefulSet.
A co by se pro to mělo udělat? Nejprve na scénu vstupuje Custom Resource Definition. co to je? Toto je popis pro K8, že budete mít další datový typ, který chceme přidat do modulu, StatefulSet, vlastní zdroj, který bude uvnitř složitý. Toto je popis datové struktury.
Posíláme to tam i přes kubectl apply. Kubernetes to s radostí vzal.
A nyní v našem úložišti má objekt v etcd možnost napsat vlastní zdroj s názvem ClickHouseInstallation.
Zatím se ale nic jiného dít nebude. To znamená, že pokud nyní vytvoříme soubor YAML, o kterém jsme uvažovali, s popisem úlomku, replik a řekneme „použít kubectl“, pak jej Kubernetes přijme, vloží do etcd a řekne: „Skvělé, ale nevím co s tím dělat. Nevím, jak udržovat ClickHouseInstallation."
Potřebujeme tedy někoho, kdo pomůže Kubernetes obsluhovat nový datový typ. Vlevo máme skladový řadič Kubernetes, který pracuje s datovými typy akcií. A napravo bychom měli mít vlastní ovladač, který umí pracovat s vlastními datovými typy.
A jinak se tomu říká operátor. Konkrétně jsem to vytáhl zde pro Kubernetes, protože to lze spustit i mimo K8. Nejčastěji se samozřejmě všechny příkazy provádějí v Kubernetes, ale nic mu nebrání stát venku, takže tady je to speciálně vyvedeno.
A již na oplátku vlastní řadič, známý také jako operátor, interaguje s Kubernetes prostřednictvím API. Už ví, jak interagovat s API. A už ví, jak zhmotnit složité schéma, které chceme vyrobit z vlastního zdroje. To je přesně to, co operátor dělá.
Jak funguje operátor? Pojďme se podívat na pravou stranu, jak to dělá. Zjistíme, jak to vše operátor zhmotní a jak probíhá další interakce s K8s.
Provozovatelem je program. Je zaměřená na události. Operátor se přihlásí k odběru událostí pomocí Kubernetes API. Kubernetes API má vstupní body, kde se můžete přihlásit k odběru událostí. A pokud se něco změní v K8s, tak Kubernetes posílá události všem, tzn. kdo se přihlásil k odběru tohoto bodu API, obdrží upozornění.
Operátor se přihlásí k odběru událostí a musí nějak reagovat. Jeho úkolem je reagovat na vznikající události.
Události jsou generovány některými aktualizacemi. Náš soubor YAML přichází s popisem ClickHouseInstallation. Šel na etcd přes kubectl apply. Zafungovala tam akce, v důsledku toho se tato akce dostala k provozovateli ClickHouse. Operátor obdržel tento popis. A musí něco udělat. Pokud došlo k aktualizaci objektu ClickHouseInstallation, musíte aktualizovat cluster. A úkolem operátora je aktualizovat cluster.
Co dělá? Nejprve musíme sestavit akční plán toho, co s touto aktualizací uděláme. Aktualizace mohou být velmi malé, tzn. malý v provádění YAML, ale může vést k velmi velkým změnám v clusteru. Operátor si proto vytvoří plán a ten pak dodržuje.
Začne podle tohoto plánu tuto strukturu uvnitř vařit, aby se zhmotnily lusky, služby, tzn. dělat to, co je jeho hlavním úkolem. Je to jako vytvořit cluster ClickHouse v Kubernetes.
Nyní se dotkneme takové zajímavé věci. Jedná se o rozdělení odpovědnosti mezi Kubernetes a provozovatele, tzn. co dělá Kubernetes, co dělá operátor a jak se vzájemně ovlivňují.
Kubernetes je zodpovědný za systémové věci, tzn. pro základní sadu objektů, které lze interpretovat jako systémový rozsah. Kubernetes ví, jak spouštět pody, jak restartovat kontejnery, jak dělat mount volumes, jak pracovat s ConfigMap, tzn. cokoli, co lze nazvat systémem.
Operátoři působí v předmětných oblastech. Každý operátor je vytvořen pro svou předmětnou oblast. Dělali jsme pro ClickHouse.
A operátor interaguje přesně z hlediska předmětné oblasti, jako je přidání repliky, vytvoření schématu, nastavení monitorování. Existuje takové oddělení.
Podívejme se na praktický příklad toho, jak k tomuto oddělení obav dochází, když provádíme akci přidání repliky.
Úkol přichází na operátora - přidat repliku. Co dělá operátor? Operátor si spočítá, že je potřeba udělat nový StatefulSet, ve kterém je potřeba popsat takové a takové šablony, objemový nárok.
Vše připravil a předá K8s. Říká, že potřebuje ConfigMap, StatefulSet, Volume. Kubernetes funguje. Zhmotňuje základní jednotky, se kterými operuje.
A pak znovu přichází do hry ClickHouse-operator. Už má fyzický modul, na kterém už můžete něco dělat. A ClickHouse-operátor opět funguje z hlediska předmětové oblasti. Tito. Konkrétně ClickHouse, abyste mohli zahrnout repliku do clusteru, musíte nejprve nakonfigurovat datové schéma, které v tomto clusteru existuje. A za druhé, tato poznámka musí být zahrnuta do monitorování, aby bylo možné ji jasně vysledovat. Operátor to již nastavil.
A až poté přichází na řadu samotný ClickHouse, tzn. další entita vyšší úrovně. Už je to databáze. Má svou vlastní instanci, další nakonfigurovanou repliku, která je připravena se připojit ke clusteru.
Ukazuje se, že řetězec provádění a oddělení odpovědnosti při přidávání repliky je dostatečně dlouhý.
Pokračujeme v praktických úkolech. Pokud cluster již existuje, můžete migrovat konfiguraci.
Udělali jsme to tak, aby bylo možné projít do stávajícího xml, kterému ClickHouse rozumí.
ClickHouse můžete doladit. Právě zónované nasazení je to, o čem jsem mluvil, když jsem vysvětloval hostPath, místní úložiště. Takto správně provést zónové nasazení.
Dalším praktickým úkolem je monitorování.
Pokud se náš cluster změní, musíme pravidelně konfigurovat monitorování.
Pojďme se podívat na schéma. Zelené šipky jsme zde již zvažovali. Nyní se podíváme na červené šipky. Takto chceme monitorovat náš cluster. Jak se metriky z clusteru ClickHouse dostanou do Promethea a poté do Grafany.
Jaký je problém s monitorováním? Proč je to prezentováno jako nějaký úspěch? Obtížnost spočívá v dynamice. Když máme jeden cluster a ten je statický, pak si můžete nastavit sledování jednou a už se nemusíte trápit.
Ale pokud máme hodně shluků nebo se něco neustále mění, pak je proces dynamický. A neustálé přestavování monitorování je plýtvání zdroji a časem; i jen líný. To je potřeba zautomatizovat. Potíž je v dynamice procesu. A operátor to velmi dobře automatizuje.
Jak se náš klastr vyvíjel? Na začátku byl takový.
Pak byl takový.
Nakonec se stal takovým.
A monitorování je automaticky prováděno operátorem. Jediný vstupní bod.
A my se jen díváme na východ v palubní desce Grafana, jak uvnitř vře život našeho clusteru.
Mimochodem, Grafana dashboard je distribuován i u našeho operátora přímo ve zdrojovém kódu. Můžete připojit a používat. Tento snímek obrazovky mi poskytl náš DevOps.
Kam bychom chtěli jet příště? Tento:
- Vyvinout automatizaci testování. Hlavním úkolem je automatizované testování nových verzí.
- Také opravdu chceme automatizovat integraci se ZooKeeperem. A plánuje integraci s operátorem ZooKeeper. Tito. pro ZooKeeper byl napsán operátor a je logické, že se oba operátoři začnou integrovat, aby vytvořili pohodlnější řešení.
- Chceme dělat složitější životní kontroly.
- Zeleně jsem zvýraznil, že máme na cestě dědění šablon - HOTOVO, tj. s příštím vydáním operátora již budeme mít dědičnost šablon. Jedná se o výkonný nástroj, který vám umožní vytvářet složité konfigurace z kusů.
- A chceme automatizovat složité úkoly. Tím hlavním je Re-sharding.
Udělejme nějaké mezivýsledky.
Co jako výsledek získáme? A stojí to za to nebo ne? Musím vůbec zkusit přetáhnout databázi do Kubernetes a použít operátor obecně a operátor Alitnity konkrétně.
Na výstupu dostaneme:
- Výrazně zjednodušte a zautomatizujte konfiguraci, nasazení a údržbu.
- Okamžitě zabudovaný monitoring.
- A připravené k použití kodifikované šablony pro složité situace. Již akci typu přidání repliky není nutné provádět ručně. To provádí operátor.
Zbývá jen poslední otázka. Už máme databázi v Kubernetes, virtualizaci. Jak je to s výkonem takového řešení, zvláště když je ClickHouse optimalizován pro výkon?
Odpověď je, že je vše v pořádku! Nebudu podrobně popisovat, to je téma samostatné zprávy.
Ale existuje takový projekt jako TSBS. Co je jeho hlavním úkolem? Toto je test výkonu databáze. Toto je pokus o srovnání teplého s teplým, měkkého s měkkým.
Jak pracuje? Vygeneruje se jedna sada dat. Poté je tato datová sada na stejné testovací sadě spuštěna v různých databázích. A každá databáze řeší jeden problém tak, jak umí. A pak můžete porovnávat výsledky.
Již podporuje velké množství databází. Identifikoval jsem tři hlavní. Tento:
- timescaledb.
- InfluxDB.
- clickhouse.
Bylo také provedeno srovnání s jiným podobným řešením. Srovnání s RedShift. Srovnání bylo provedeno na Amazonu. ClickHouse je v této věci také daleko před všemi.
Jaké závěry lze vyvodit z toho, co jsem řekl?
- DB v Kubernetes je možná. Pravděpodobně můžete dělat cokoliv, ale obecně to vypadá, že můžete. ClickHouse v Kubernetes je určitě možný s pomocí našeho operátora.
- Operátor pomáhá automatizovat procesy a skutečně zjednodušuje život.
- Výkon je normální.
- A zdá se nám, že může a měla by být použita.
Open source – přidejte se k nám!
Jak jsem řekl, operátor je zcela open source produkt, takže by bylo velmi dobré, kdyby jej využívalo maximum lidí. Přidej se teď! Těšíme se na vás všechny!
Děkuji vám!
otázky
Díky za zprávu! Jmenuji se Anton. Jsem ze SEMrush. Zajímalo by mě, jak je to s logováním. Slyšíme o monitorování, ale nic o protokolování, pokud mluvíme o celém clusteru. Máme například cluster na hardwaru. A používáme centralizované protokolování, shromažďujeme ho na společné hromadě standardními prostředky. A odtud pak získáváme data, která jsou pro nás zajímavá.
Dobrá otázka, tedy přihlášení do seznamu úkolů. Náš operátor to zatím neautomatizuje. Stále se rozvíjí, projekt je ještě docela mladý. Chápeme potřebu těžby dřeva. To je také velmi důležité téma. A to je pravděpodobně neméně důležité než sledování. Ale první na seznamu pro implementaci byl monitoring. Proběhne těžba dřeva. Přirozeně se snažíme automatizovat všechny aspekty života clusteru. Proto odpověď zní, že v tuto chvíli operátor bohužel neví, jak to udělat, ale je to v plánu, my to uděláme. Pokud se chcete připojit, vytáhněte žádost, prosím.
Ahoj! Díky za zprávu! Mám standardní otázku týkající se trvalých svazků. Když vytvoříme konfiguraci s tímto operátorem, jak operátor určí, na kterém uzlu máme nějaký disk nebo složku? Nejprve mu musíme vysvětlit, že prosím, umístěte náš ClickHouse přesně na tyto uzly, které mají disk?
Pokud jsem pochopil, tato otázka je pokračováním místního úložiště, zejména jeho části hostPath. Je to jako vysvětlovat celému systému, že je potřeba, aby se pod spouštěl přesně na tom a takovém uzlu, na kterém máme fyzický připojený disk, který je namontován na takové a takové cestě. Toto je celá sekce, které jsem se dotkl velmi povrchně, protože odpověď je tam poměrně rozsáhlá.
Stručně řečeno, vypadá to takto. Tyto objemy samozřejmě musíme zajistit. V současné době neexistuje žádné dynamické ustanovení v místním úložišti, takže DevOps musí uříznout disky sami, zde jsou tyto svazky. A musí vysvětlit zajišťování Kubernetes, že budete mít trvalé svazky takové a takové třídy, která se nachází na takových a takových uzlech. Pak bude nutné Kubernetes vysvětlit, že pody, které vyžadují takovou a takovou třídu lokálního úložiště, je potřeba naplánovat podle štítků jen do takových a takových uzlů. Pro tyto účely má operátor možnost přiřadit nějaký druh štítku a jeden na hostitelskou instanci. A ukázalo se, že pody budou Kubernetes směrovány tak, aby běžely pouze na uzlech, které splňují požadavky, štítky, jednoduše řečeno. Správci přidělují štítky, provádějí zajišťování disků ručně. A pak se to škáluje.
A právě třetí možnost místní to pomáhá trochu usnadnit. Jak jsem již zdůraznil, jedná se o pečlivé ladění, které nakonec pomáhá k maximálnímu výkonu.
S tím souvisí druhá otázka. Kubernetes byl koncipován tak, že nám nezáleží na tom, zda o uzel přijdeme nebo ne. Co bychom měli dělat v tomto případě, pokud jsme ztratili uzel, kde máme úlomek?
Ano, Kubernetes byl původně postaven tak, že náš vztah s našimi lusky je jako dobytek, ale zde se každý disk stává něčím jako domácím mazlíčkem. Je tu takový problém, že je nemůžeme jen tak vyhodit. A vývoj Kubernetes jde tím směrem, že se s ním úplně filozoficky, jako se zcela zahozeným zdrojem, nedá zacházet.
Nyní praktická otázka. Co dělat, když jste ztratili uzel, na kterém byl disk? Zde je problém vyřešen na vyšší úrovni. V případě ClickHouse máme repliky, které fungují na vyšší úrovni, tzn. na úrovni ClickHouse.
Jaká je dispozice? DevOps odpovídá za to, že nedojde ke ztrátě dat. Musí správně nastavit replikaci a musí zajistit, že replikace běží. V replice na úrovni ClickHouse musí být data duplikována. To není úkol, který operátor řeší. A ne úkol, který řeší samotný Kubernetes. Toto je na úrovni ClickHouse.
Co dělat, když vám spadl železný uzel? A ukazuje se, že bude nutné položit druhý, správně na něj posunout disk, aplikovat štítky. A poté splní požadavky, aby na něm Kubernetes mohl provozovat instanci podu. Kubernetes to spustí. Váš počet podů nestačí zadanému počtu. Projde cyklem, který jsem ukázal. A na nejvyšší úrovni ClickHouse pochopí, že máme zadanou repliku, ta je zatím prázdná a musíme do ní začít přenášet data. Tito. tento proces je stále špatně automatizován.
Díky za zprávu! Když se dějí všelijaké nepěkné věci, operátor spadne a restartuje a v tu chvíli přijdou události, zpracováváte to nějak?
Co se stane, když se operátor zhroutí a restartuje, ano?
Ano. A v tu chvíli přišly události.
Úkol, co dělat v tomto případě, je částečně rozdělen mezi operátora a Kubernetes. Kubernetes má schopnost přehrát událost, ke které došlo. Přehrává. A úkolem operátora je zajistit, aby při přehrání protokolu událostí na něm byly tyto události idempotentní. A aby nám opakovaný výskyt stejné události nerozbil náš systém. A náš operátor se s tímto úkolem vyrovná.
Ahoj! Díky za zprávu! Dmitrij Zavialov, spol Smedov. Plánuje se přidat operátorovi možnosti přizpůsobení s haproxy? Zajímavý je nějaký jiný balancer kromě standardního, aby byl chytrý a pochopil, že ClickHouse je tam skutečný.
Mluvíš o Ingressu?
Ano, nahraďte Ingress haproxy. V haproxy můžete určit topologii clusteru, kde má repliky.
Zatím jsme o tom nepřemýšleli. Pokud to potřebujete a dokážete vysvětlit, proč je to potřeba, pak to bude možné realizovat, zvláště pokud se chcete zúčastnit. Rádi variantu zvážíme. Krátká odpověď zní ne, v současné době takovou funkcionalitu nemáme. Díky za tip, podíváme se na to. A pokud vysvětlíte i případ použití a proč je v praxi nutné například vytvářet problémy na GitHubu, tak to bude skvělé.
Již.
Pokuta. Jsme otevřeni jakýmkoli návrhům. A haproxy je zařazen na seznam úkolů. Seznam úkolů roste, zatím se nezmenšuje. Ale to je dobře, to znamená, že produkt je žádaný.
Zdroj: www.habr.com