Operator u Kubernetesu za upravljanje klasterima baza podataka. Vladislav Klimenko (Altinity, 2019)

Izveštaj je posvećen praktičnim pitanjima razvoja operatora u Kubernetesu, projektovanju njegove arhitekture i osnovnim principima rada.

U prvom dijelu izvještaja razmotrićemo:

• šta je operator u Kubernetesu i zašto je potreban;
• kako tačno operater pojednostavljuje upravljanje složenim sistemima;
• šta operater može, a šta ne može.

Zatim, pređimo na diskusiju o internoj strukturi operatora. Razmotrite arhitekturu i rad operatera korak po korak. Analizirajmo detaljno:

• interakcija između operatera i Kubernetesa;
• koje funkcije operater preuzima i koje delegira Kubernetesu.

Razmislite o upravljanju dijelovima i replikama baze podataka u Kubernetesu.
Zatim ćemo razgovarati o pitanjima skladištenja podataka:

• kako raditi sa Persistent Storage sa stanovišta operatera;
• zamke korištenja lokalne pohrane.

U završnom dijelu izvještaja razmotrit ćemo praktične primjere primjene clickhouse operator uz Amazon ili Google Cloud Service. Izvještaj je zasnovan na primjeru razvoja i operativnog iskustva operatera za ClickHouse.

Video:

Moje ime je Vladislav Klimenko. Danas sam želio govoriti o našem iskustvu u razvoju i radu operatera, a to je specijalizirani operater za upravljanje klasterima baza podataka. Na primjer ClickHouse-operater za upravljanje ClickHouse klasterom.

Zašto imamo priliku razgovarati o operateru i ClickHouseu?

• Podržavamo i razvijamo ClickHouse.
• Trenutno pokušavamo da polako damo svoj doprinos razvoju ClickHouse-a. I mi smo drugi nakon Yandexa po količini izmjena u ClickHouseu.
• Pokušavamo napraviti dodatne projekte za ClickHouse ekosistem.

Želio bih govoriti o jednom od ovih projekata. Radi se o ClickHouse-operatoru za Kubernetes.

U svom izvještaju želio bih se dotaknuti dvije teme:

• Prva tema je kako naš ClickHouse operator baze podataka radi u Kubernetesu.
• Druga tema je kako bilo koji operator radi, odnosno kako je u interakciji sa Kubernetesom.

Međutim, ova dva pitanja će se ukrštati u mom izvještaju.

Ko bi bio zainteresovan da čuje šta pokušavam da kažem?

• Najinteresantniji će biti oni koji iskorištavaju operatere.
• Ili za one koji žele da naprave svoje kako bi razumeli kako to funkcioniše iznutra, kako operater komunicira sa Kubernetesom i koje zamke se mogu pojaviti.

Kako bismo najbolje razumjeli o čemu ćemo danas razgovarati, bilo bi lijepo znati kako Kubernetes funkcionira i imati osnovnu pozadinu u računalstvu u oblaku.

Šta je ClickHouse? Ovo je baza podataka kolona sa specifičnostima u onlajn obradi analitičkih upita. I potpuno je otvorenog koda.

A moramo znati samo dvije stvari. Morate znati da je ovo baza podataka, tako da će ono što ću vam reći biti primjenjivo na gotovo svaku bazu podataka. A činjenica da se ClickHouse DBMS vrlo dobro skalira daje skalabilnost gotovo linearnu. Stoga je stanje klastera prirodno stanje za ClickHouse. A mi smo najviše zainteresovani da razgovaramo o tome kako da opslužujemo ClickHouse klaster u Kubernetesu.

Zašto je on tamo potreban? Zašto ne možemo sami da nastavimo sa radom? A odgovori su dijelom tehnički, a dijelom organizacijski.

• U praksi se sve češće susrećemo sa takvom situacijom kada su u velikim kompanijama gotovo sve komponente već u Kubernetesu. Ostanite baze podataka vani.
• I sve češće se postavlja pitanje: "Može li se staviti unutra?". Stoga se velike kompanije trude da proizvedu maksimalno ujedinjenje menadžmenta kako bi što brže mogle upravljati svojim skladištima podataka.
• A to posebno pomaže ako vam je potrebna maksimalna mogućnost da istu stvar ponovite na novom mjestu, odnosno maksimalnu prenosivost.

Koliko je to lako ili teško? To se, naravno, može uraditi ručno. Ali to nije tako lako, jer zbrajamo složenost upravljanja samim Kubernetesom, ali se u isto vrijeme nameću specifičnosti ClickHousea. I ispada takva agregacija.

A sve zajedno, ovo daje prilično veliki skup tehnologija, kojima već postaje prilično teško upravljati, jer Kubernetes svoje svakodnevne probleme donosi u rad, a ClickHouse svoje probleme donosi u svakodnevni rad. Pogotovo ako imamo nekoliko ClickHouse-a, i treba stalno nešto raditi s njima.

ClickHouse sa dinamičkom konfiguracijom ima prilično veliki broj problema koji stvaraju konstantno opterećenje na DevOps-u:

• Kada želimo nešto promijeniti u ClickHouseu, na primjer, dodati repliku, šard, onda moramo upravljati konfiguracijom.
• Zatim promijenite šemu podataka, jer ClickHouse ima specifičnu metodu dijeljenja. Tamo je potrebno postaviti šemu podataka, postaviti konfiguracije.
• Morate postaviti nadzor.
• Zbirka dnevnika za nove krhotine, za nove replike.
• Vodite računa o oporavku.
• I ponovo pokrenite.

To su tako rutinski poslovi koje bih jako volio olakšati u radu.

Sam Kubernetes dosta pomaže u radu, ali na osnovnim sistemskim stvarima.

Kubernetes je odličan u olakšavanju i automatizaciji stvari kao što su:

• Oporavak.
• Ponovo pokreni.
• Upravljanje skladištem.

To je dobro, to je u pravom smjeru, ali on je potpuno bez veze s tim kako upravljati klasterom baze podataka.

Želim više, želim da cijela baza podataka radi za nas u Kubernetesu.

Želio bih dobiti nešto poput jednog velikog magičnog crvenog dugmeta koje pritisnete i imate klaster raspoređen i održavan tokom cijelog životnog ciklusa sa svakodnevnim zadacima koje treba riješiti. ClickHouse klaster u Kubernetesu.

I pokušali smo napraviti rješenje koje bi olakšalo posao. Ovo je ClickHouse-operator za Kubernetes iz Altinity.

Operator je program čiji je glavni zadatak upravljanje drugim programima, odnosno menadžer je.

I sadrži obrasce ponašanja. To možete nazvati kodifikovanim znanjem o predmetnoj oblasti.

A njegov glavni zadatak je olakšati život DevOps-u i smanjiti mikromenadžment tako da on (DevOps) već razmišlja na visokom nivou, odnosno da on (DevOps) ne mikromenadžira, kako ne bi ručno konfigurirao sve detalji.

A upravo je operater robot pomoćnik koji se bori s mikrozadacima i pomaže DevOps-u.

Zašto je potreban operater? On se ističe u dve oblasti:

• Kada stručnjak za ClickHouse nema dovoljno iskustva, ali je već neophodan za upravljanje ClickHouse-om, operater olakšava rad i omogućava vam da upravljate ClickHouse klasterom s prilično složenom konfiguracijom, a da pritom ne ulazite previše u detalje o tome kako sve funkcionira unutra . Samo mu date zadatke visokog nivoa i to funkcionira.
• A drugi zadatak u kojem se najbolje pokazuje je kada je potrebno automatizirati veliki broj tipičnih zadataka. Uklanja mikrozadatke sa administratora sistema.

Ovo je najpotrebnije ili onima koji tek počinju svoje putovanje, ili onima kojima je potrebno dosta automatizacije.

Koja je razlika između pristupa zasnovanog na operateru i drugih sistema? Tu je i Helm. Pomaže i instaliranje ClickHousea, možete crtati helm grafikone, koji će čak instalirati cijeli ClickHouse klaster. Koja je onda razlika između operatora i istog, na primjer, Helma?

Glavna fundamentalna razlika je u tome što se Helm bavi upravljanjem paketima, a operater ide korak dalje. Ovo je podrška cijelog životnog ciklusa. Ovo nije samo instalacija, to su svakodnevni zadaci koji uključuju skaliranje, sharding, odnosno sve što treba uraditi tokom životnog ciklusa (ako je potrebno i uklanjanje) - o tome odlučuje operater. Pokušava da automatizuje i služi čitav životni ciklus softvera. To je njegova suštinska razlika u odnosu na ostala rješenja koja su predstavljena.

To je bio uvodni dio, idemo dalje.

Kako da izgradimo našeg operatera? Pokušavamo pristupiti problemu kako bismo upravljali ClickHouse klasterom kao jedinstvenim resursom.

Ovdje imamo ulazne podatke na lijevoj strani slike. Ovo je YAML sa specifikacijom klastera, koja se klasično prenosi kroz kubectl u Kubernetes. Tamo ga naš operater preuzima, čini svoju magiju. I kao rezultat, dobijamo takvu šemu. Ovo je implementacija ClickHouse u Kubernetes.

A onda ćemo polako gledati kako operater radi, koji tipični zadaci se mogu riješiti. Razmotrit ćemo samo tipične zadatke, jer imamo ograničeno vrijeme. I neće biti rečeno o svemu što operater može odlučiti.

Krenimo od prakse. Naš projekat je potpuno otvorenog koda, tako da možete vidjeti kako funkcionira na GitHubu. I možete nastaviti od razmatranja, ako samo želite da počnete, onda možete početi s Vodičem za brzi početak.

Ako želite detaljnije razumjeti, onda se trudimo da dokumentaciju održavamo u manje-više pristojnom obliku.

Počnimo s praktičnim problemom. Prvi zadatak s kojim svi želimo započeti je da nekako pokrenemo prvi primjer. Kako pokrenuti ClickHouse uz pomoć operatera, a da uopće ne znate kako funkcionira? Pišemo manifest, jer sva komunikacija sa k8s je komunikacija kroz manifeste.

Evo tako složenog manifesta. Ono što smo označili crvenom bojom je ono na šta se trebamo fokusirati. Tražimo od operatera da kreira klaster pod nazivom demo.

Za sada, ovo su osnovni primjeri. Skladištenje još nije opisano, ali ćemo se vratiti na skladište nešto kasnije. Za sada ćemo posmatrati razvoj klastera u dinamici.

Mi smo kreirali ovaj manifest. Dajemo ga našem operateru. Radio je, radio je magiju.

Gledamo u konzolu. Tri komponente su od interesa - to su Pod, dvije Service-a, StatefulSet.

Operater je proradio, a vidimo šta je tačno napravio.

On stvara ovako nešto. Imamo StatefulSet, Pod, ConfigMap za svaku repliku, ConfigMap za cijeli klaster. Obavezno servisi kao ulazne tačke u klaster.

Servisi su centralna usluga balansiranja opterećenja i moguća je za svaku repliku, za svaki šard.

Ovdje naš osnovni klaster izgleda otprilike ovako. On je iz jednog čvora.

Idemo dalje, komplikovaćemo. Morate razdvojiti klaster.

Naši zadaci rastu, počinje dinamika. Želimo dodati dio. Pratimo razvoj. Mijenjamo našu specifikaciju. Naznačavamo da želimo dva komada.

Ovo je isti fajl koji dinamički razvijamo sa rastom sistema. Nema skladištenja, o skladištenju će se dalje razgovarati, ovo je zasebno pitanje.

Nahranimo YAML operatera i vidimo šta će se dogoditi.

Operater je smislio i napravio sljedeće entitete. Već imamo dva Poda, tri Services i, odjednom, 2 StatefulSeta. Zašto 2 StatefulSeta?

Na dijagramu je bilo ovako - ovo je naše početno stanje, kada smo imali jednu mahunu.

Postalo je ovako. Do sada je sve jednostavno, duplirano.

I zašto je StatefulSet postao dva? Ovdje trebamo skrenuti pažnju i prodiskutirati pitanje kako se upravlja podovima u Kubernetesu.

Postoji takav objekat koji se zove StatefulSet, koji vam omogućava da napravite skup podova iz šablona. Ključni faktor ovdje je Template. I možete pokrenuti mnogo Podova u jednom StatefulSet-u prema jednom šablonu. A ključna fraza ovdje je “jedan šablon mnogo podova”.

I postojalo je veliko iskušenje da se napravi cijeli klaster, upakujući ga u jedan StatefulSet. Radiće, u tome nema problema. Ali postoji jedno upozorenje. Ako želimo sastaviti heterogeni klaster, odnosno iz nekoliko verzija ClickHouse-a, onda počinju naša pitanja. Da, StatefulSet može izvršiti ažuriranje, ali tamo možete izbaciti novu verziju, objasniti da ne morate isprobati više od toliko čvorova u isto vrijeme.

Ali ako ekstrapoliramo zadatak i kažemo da želimo napraviti potpuno heterogeni klaster i ne želimo se mijenjati sa stare verzije na novu pomoću ažuriranja, već jednostavno želimo stvoriti heterogeni klaster i u smislu različitih verzija ClickHouse iu smislu različitog prostora za skladištenje. Želimo, na primjer, napraviti neke replike na odvojenim diskovima, na sporim, općenito, da u potpunosti izgradimo heterogeni klaster. A zbog činjenice da StatefulSet pravi standardizirano rješenje od jednog šablona, ​​tako da ne postoji način da se to uradi.

Nakon malo razmišljanja, odlučeno je da radimo ovako. Svaku repliku imamo u svom StatefulSet-u. Postoje neki nedostaci ovom rješenju, ali u praksi sve to u potpunosti inkapsulira operatora. I ima mnogo prednosti. Možemo izgraditi potpuno takav klaster kakav želimo, na primjer, apsolutno heterogen. Dakle, u klasteru u kojem imamo dva šarda sa jednom replikom, imaćemo 2 StatefulSeta i 2 Poda upravo zato što smo se odlučili za ovaj pristup zbog gore navedenih razloga za mogućnost izgradnje heterogenog klastera.

Vratimo se praktičnim zadacima. U našem klasteru trebamo konfigurirati korisnike, tj. morate napraviti neku konfiguraciju ClickHouse-a u Kubernetesu. Operater pruža sve mogućnosti za to.

Možemo pisati šta želimo direktno u YAML-u. Sve opcije konfiguracije se direktno mapiraju iz ovog YAML-a u ClickHouse konfiguracije, koje se zatim raspoređuju u cijelom klasteru.

Možete pisati i ovako. Ovo je za primjer. Lozinka se može šifrirati. Podržane su apsolutno sve opcije konfiguracije ClickHouse. Evo samo primjera.

Konfiguracija klastera se distribuira kao ConfigMap. U praksi, ažuriranje ConfigMap-a se ne dešava trenutno, pa ako postoji veliki klaster, onda proces guranja konfiguracije traje neko vreme. Ali sve ovo je vrlo zgodno za korištenje.

Komplikujemo zadatak. Klaster se razvija. Želimo replicirati podatke. Odnosno, već imamo dva šarda, po jednu repliku, korisnici su konfigurisani. Rastemo i želimo da se repliciramo.

Šta nam je potrebno za replikaciju?

Trebamo ZooKeeper. U ClickHouseu, replikacija se gradi pomoću ZooKeepera. ZooKeeper je potreban kako bi različite ClickHouse replike imale konsenzus o tome koji se blokovi podataka nalaze na kom ClickHouseu.

ZooKeeper može koristiti bilo tko. Ako preduzeće ima eksterni ZooKeeper, onda se može koristiti. Ako ne, onda možete instalirati iz našeg spremišta. Postoji instalater koji olakšava cijelu ovu stvar.

I shema interakcije cijelog sistema ispada ovako. Imamo Kubernetes kao platformu. Izvršava ClickHouse operator. ZooKeeper sam slikao ovdje. Operater je u interakciji sa ClickHouse i ZooKeeperom. To jest, postiže se interakcija.

A sve je to neophodno da bi ClickHouse uspješno replicirao podatke u k8s.

Pogledajmo sada sam zadatak, kako će izgledati manifest za replikaciju.

Dodali smo dva odjeljka našem manifestu. Prvi je gdje nabaviti ZooKeeper, koji može biti unutar Kubernetesa ili eksterni. Ovo je samo opis. I naručujemo replike. One. želimo dvije replike. Ukupno bismo trebali imati 4 mahune na izlazu. Sjećamo se skladištenja, vratit će se malo dalje. Skladištenje je posebna pjesma.

Bilo je ovako.

Postaje ovako. Dodane su replike. 4. nije odgovarao, vjerujemo da ih može biti mnogo. I ZooKeeper je dodan sa strane. Obrasci postaju sve složeniji.

I vrijeme je da dodate sljedeći zadatak. Dodaćemo Persistent Storage.

Za trajnu pohranu imamo razne opcije.

Ako radimo u cloud provajderu, na primjer, koristeći Amazon, Google, onda postoji veliko iskušenje da koristimo pohranu u oblaku. Veoma je zgodno, dobro je.

A postoji i druga opcija. Ovo je za lokalnu pohranu, kada imamo lokalne diskove na svakom čvoru. Ova opcija je mnogo teža za implementaciju, ali je istovremeno i produktivnija.

Hajde da vidimo šta imamo u vezi sa pohranom u oblaku.

Postoje zasluge. Vrlo je lako konfigurirati. Jednostavno naručujemo od provajdera u oblaku koji nam daje skladište takvog i takvog kapaciteta, takve i takve klase. Časove farbaju provajderi samostalno.

I postoji nedostatak. Za neke je to nekritičan nedostatak. Naravno, bit će i nekih preklapanja performansi. Veoma je zgodan za upotrebu, pouzdan, ali ima nekih potencijalnih padova u performansama.

I od tada ClickHouse se fokusira na performanse, čak se može reći da istiskuje sve što je moguće, pa mnogi klijenti pokušavaju istisnuti maksimalne performanse.

A da bismo izvukli maksimum iz toga, potrebna nam je lokalna pohrana.

Kubernetes pruža tri apstrakcije za korištenje lokalne memorije u Kubernetesu. Ovo:

• EmptyDir
• HostPath.
• lokalne

Razmotrite po čemu se razlikuju, koliko su slični.

Prvo, u sva tri pristupa imamo skladište - to su lokalni diskovi koji se nalaze na istom fizičkom k8s čvoru. Ali oni imaju neke razlike.

Počnimo s najjednostavnijim, odnosno praznim Dir-om. Šta je to u praksi? Mi smo ti koji tražimo od sistema kontejnerizacije (najčešće Docker) iz naše specifikacije da nam omogući pristup folderu na lokalnom disku.

U praksi, docker negdje na vlastitoj putanji kreira privremeni folder, naziva ga dugim hashom. I pruža interfejs za pristup.

Kako će se ponašati u smislu performansi? Ovo će raditi brzinom lokalnog diska, tj. ovo je potpuni pristup vašem zavrtnju.

Ali ovaj slučaj ima svoj nedostatak. Upornost je u ovom slučaju prilično sumnjiva. Pri prvom pomicanju dockera sa kontejnerima, Persistent se gubi. Ako Kubernetes želi premjestiti ovaj Pod na drugi disk iz nekog razloga, podaci će biti izgubljeni.

Ovaj pristup je dobar za testove, jer već pokazuje normalnu brzinu, ali ova opcija nije prikladna za nešto ozbiljno.

Stoga postoji drugi pristup. Ovo je hostPath. Ako pogledate prethodni i ovaj slajd, možete vidjeti samo jednu razliku. Naša fascikla je ostavila docker direktno u Kubernetes čvor. Ovdje je malo brže. Direktno pišemo putanju na lokalnom sistemu datoteka gdje želimo pohraniti naše podatke.

Ova metoda ima prednosti. Ovo je već pravi Persistent, i to klasičan. Na našem disku podaci će biti upisani na neku adresu.

Postoje i nedostaci. Ovo je složenost upravljanja. Naš Kubernetes će možda htjeti premjestiti Pod na drugi fizički čvor. Ovdje na scenu stupa DevOps. Mora ispravno objasniti cijelom sistemu da ove podove možete premjestiti samo na takve čvorove na kojima imate nešto montirano duž ovih putanja, i ne više od jednog čvora u isto vrijeme. Dovoljno je teško.

Posebno za ove svrhe, napravili smo šablone u našem operatoru kako bismo sakrili svu ovu složenost. I mogli biste samo reći: "Želim imati jednu instancu ClickHouse-a po fizičkom čvoru i duž tog i takvog puta."

Ali ova potreba nije samo za nas, pa i gospoda iz Kubernetesa shvataju da ljudi žele da imaju pristup fizičkim diskovima, pa obezbeđuju treći nivo.

Zove se lokalno. Praktično nema razlike u odnosu na prethodni slajd. Samo ranije je bilo potrebno ručno provesti da ove podove ne možemo prenijeti od čvora do čvora, jer moraju biti pričvršćeni duž te i takve putanje do lokalnog fizičkog diska, a sada je svo to znanje inkapsulirano u samom Kubernetesu. I ispostavilo se da je mnogo lakše konfigurirati.

Vratimo se našem praktičnom zadatku. Vratimo se na YAML šablon. Ovdje imamo pravo skladište. Vratili smo se na ovo. Postavili smo klasični VolumeClaim šablon kao u k8s. I opisujemo kakvu vrstu skladišta želimo.

Nakon toga, k8s će zatražiti skladištenje. Dodijelite nam ga u StatefulSet-u. I na kraju će se ispostaviti na raspolaganju ClickHouseu.

Imali smo takvu šemu. Naše Persistent Storage je bilo crveno, što kao da je nagovještavalo da to treba učiniti.

I postaje zeleno. Sada je ClickHouse na k8s šema klastera u potpunosti finalizirana. Imamo šardove, replike, ZooKeeper, imamo pravi Persistent, koji je implementiran na ovaj ili onaj način. Shema je već u potpunosti operativna.

Nastavljamo da živimo. Naš klaster raste. A Aleksey pokušava i izdaje novu verziju ClickHouse-a.

Pojavljuje se praktičan zadatak - testirati novu verziju ClickHouse-a na našem klasteru. I, naravno, ne želim sve to izbaciti, želim novu verziju negdje u krajnjem kutu staviti u jednu repliku, ili možda ne jednu novu verziju, već dvije odjednom, jer često izlaze.

Šta možemo reći o ovome?

Ovdje imamo upravo takvu priliku. Ovo su šabloni pod. Možete slikati, naš operater vam u potpunosti omogućava da izgradite heterogeni klaster. One. konfigurisati, počevši od svih replika u gomili, završavajući sa svakom ličnom replikom, koju verziju želimo ClickHouse, koju verziju želimo skladište. Možemo u potpunosti konfigurirati klaster u takvoj konfiguraciji koja nam je potrebna.

Hajdemo malo dublje. Prije toga smo pričali o tome kako funkcionira ClickHouse-operater u odnosu na specifičnosti ClickHouse-a.

Sada bih želeo da kažem nekoliko reči o tome kako bilo koji operater uopšte radi, kao i kako je u interakciji sa K8s.

Za početak razmislite o interakciji sa K8s. Šta se dešava kada primenimo kubectl? Kroz API, naši objekti se pojavljuju u etcd.

Na primjer, osnovni objekti Kubernetes: pod, StatefulSet, servis i tako dalje kroz listu.

Međutim, još se ništa fizičko ne dešava. Ovi objekti moraju biti materijalizirani u klasteru.

Ovdje dolazi kontroler. Kontroler je posebna k8s komponenta koja može materijalizirati ove opise. Zna kako i šta da radi fizički. Zna kako da pokrene kontejnere, šta tamo treba konfigurisati da bi server radio.

I materijalizira naše objekte u K8s.

Ali želimo da radimo ne samo sa podovima, StatefulSets, mi želimo da kreiramo ClickHouseInstallation, odnosno objekat tipa ClickHouse, da bismo mogli da radimo sa njim kao celinom. Za sada takva mogućnost ne postoji.

Ali K8s ima još jednu lijepu stvar. Želimo da negdje imamo tako složen entitet u kojem bi se naš klaster sastavljao od podova i StatefulSeta.

I šta treba učiniti za ovo? Prvo, na scenu stupa Custom Resource Definition. Šta je to? Ovo je opis za K8s da ćete imati drugi tip podataka koji želimo da dodamo u pod, StatefulSet, prilagođeni resurs koji će biti složen iznutra. Ovo je opis strukture podataka.

Također ga šaljemo tamo putem kubectl apply. Kubernetes ga je sretno uzeo.

A sada u našem skladištu, objekt u etcd-u ima priliku da napiše prilagođeni resurs pod nazivom ClickHouseInstallation.

Ali za sada se ništa drugo neće dogoditi. Odnosno, ako sada kreiramo YAML datoteku koju smo razmatrali sa opisom šarda, replika i kažemo “kubectl apply”, onda će je Kubernetes prihvatiti, staviti u etcd i reći: “Odlično, ali ne znam šta da radim s tim. Ne znam kako održavati ClickHouseInstallation."

Shodno tome, potreban nam je neko da pomogne Kubernetesu da opslužuje novi tip podataka. Na lijevoj strani imamo dionički Kubernetes kontroler koji radi sa tipovima podataka o zalihama. A na desnoj strani, trebali bismo imati prilagođeni kontroler koji može raditi s prilagođenim tipovima podataka.

I na drugi način se zove operator. Posebno sam ga uzeo ovdje za Kubernetes, jer se može izvršiti i van K8s-a. Najčešće se, naravno, svi iskazi izvršavaju u Kubernetesu, ali ništa ga ne sprečava da stoji napolju, pa se ovde posebno iznosi.

I već, zauzvrat, prilagođeni kontroler, takođe poznat kao operator, komunicira sa Kubernetesom preko API-ja. On već zna kako da komunicira sa API-jem. I on već zna kako materijalizirati složenu shemu koju želimo napraviti od prilagođenog resursa. To je upravo ono što operater radi.

Kako operater radi? Hajde da pogledamo desnu stranu da vidimo kako to radi. Saznaćemo kako operater sve to materijalizuje i kako se odvija dalja interakcija sa K8s.

Operater je program. Ona je orijentisana na događaje. Operater se pretplaćuje na događaje koristeći Kubernetes API. Kubernetes API ima ulazne tačke na koje se možete pretplatiti na događaje. A ako se nešto promijeni u K8s, onda Kubernetes šalje događaje svima, tj. koji se pretplatio na ovu API tačku će primati obavještenja.

Operater se pretplaćuje na događaje i mora izvršiti neku vrstu reakcije. Njegov zadatak je da odgovori na novonastale događaje.

Događaji se generiraju nekim ažuriranjima. Naša YAML datoteka stiže s opisom ClickHouseInstallation. Otišao je na etcd preko kubectl apply. Događaj je tamo proradio, kao rezultat toga, ovaj događaj je došao do ClickHouse-operatora. Operater je dobio ovaj opis. I on mora nešto da uradi. Ako je došlo do ažuriranja objekta ClickHouseInstallation, tada morate ažurirati klaster. A zadatak operatera je ažuriranje klastera.

Šta on radi? Prvo, treba da napravimo akcioni plan za ono što ćemo uraditi sa ovim ažuriranjem. Ažuriranja mogu biti vrlo mala, tj. mali u izvršavanju YAML-a, ali može dovesti do vrlo velikih promjena na klasteru. Stoga operater kreira plan, a zatim ga se pridržava.

On počinje, prema ovom planu, da ključa ovu strukturu iznutra da bi materijalizovao mahune, službe, tj. da radi ono što mu je glavni zadatak. To je kao da gradite ClickHouse klaster u Kubernetesu.

Hajde sada da se dotaknemo jedne tako zanimljive stvari. Ovo je podjela odgovornosti između Kubernetesa i operatera, tj. šta radi Kubernetes, šta radi operater i kako međusobno komuniciraju.

Kubernetes je odgovoran za sistemske stvari, tj. za osnovni skup objekata koji se mogu tumačiti kao sistemski opseg. Kubernetes zna kako da pokrene podove, kako da restartuje kontejnere, kako da montira volumene, kako da radi sa ConfigMap-om, tj. sve što se može nazvati sistemom.

Operateri rade u predmetnim oblastima. Svaki operater je napravljen za svoju predmetnu oblast. Napravili smo za ClickHouse.

A operater je u interakciji upravo u smislu predmetne oblasti, kao što je dodavanje replike, pravljenje šeme, postavljanje nadzora. Postoji takva podjela.

Pogledajmo praktičan primjer kako se ovo razdvajanje briga događa kada izvršimo akciju dodavanja replike.

Zadatak dolazi operateru - da doda repliku. Šta radi operater? Operator će izračunati da je potrebno napraviti novi StatefulSet, u kojem je potrebno opisati takve i takve šablone, zahtjev za volumen.

On je sve to pripremio i proslijedio K8s. Kaže da mu treba ConfigMap, StatefulSet, Volume. Kubernetes radi. On materijalizuje osnovne jedinice sa kojima operiše.

I onda ClickHouse-operator ponovo stupa u igru. On već ima fizičku podlogu na kojoj već možete nešto učiniti. I ClickHouse-operator opet radi u smislu predmetne oblasti. One. Konkretno, ClickHouse, da biste uključili repliku u klaster, morate, prvo, konfigurirati šemu podataka koja postoji u ovom klasteru. I, drugo, ova napomena mora biti uključena u monitoring kako bi se mogla jasno ući u trag. Operater to već postavlja.

I tek nakon toga na scenu stupa sam ClickHouse, tj. drugi entitet višeg nivoa. To je već baza podataka. Ima svoju vlastitu instancu, sljedeću konfiguriranu repliku, koja je spremna za pridruživanje klasteru.

Ispostavilo se da je lanac izvršenja i razdvajanja odgovornosti prilikom dodavanja replike dovoljno dug.

Nastavljamo sa praktičnim zadacima. Ako klaster već postoji, možete migrirati konfiguraciju.

Napravili smo tako da je moguće proći u postojeći xml, koji ClickHouse razumije.

Možete fino podesiti ClickHouse. Samo zonirana implementacija je ono o čemu sam govorio kada sam objašnjavao hostPath, lokalnu pohranu. Ovo je kako pravilno izvršiti zonsku implementaciju.

Sljedeći praktični zadatak je praćenje.

Ako se naš klaster promijeni, onda moramo povremeno konfigurirati praćenje.

Hajde da pogledamo dijagram. Ovdje smo već razmotrili zelene strelice. Pogledajmo sada crvene strelice. Ovako želimo da pratimo naš klaster. Kako metrike iz ClickHouse klastera dolaze u Prometheus, a zatim u Grafanu.

Šta je problem sa praćenjem? Zašto se ovo predstavlja kao neka vrsta postignuća? Poteškoća je u dinamici. Kada imamo jedan klaster i on je statičan, onda možete jednom podesiti praćenje i više se ne truditi.

Ali ako imamo puno klastera, ili se nešto stalno mijenja, onda je proces dinamičan. A stalno rekonfigurisanje nadzora je gubljenje resursa i vremena; čak i samo lenj. Ovo treba automatizirati. Poteškoća je u dinamici procesa. A operater ovo veoma dobro automatizuje.

Kako se razvijao naš klaster? U početku je bio ovakav.

Onda je bio ovakav.

Na kraju je postao ovakav.

A nadzor automatski vrši operater. Jedna ulazna tačka.

A mi samo gledamo izlaz na komandnoj tabli Grafane, kako život našeg klastera ključa unutra.

Inače, Grafana dashboard se također distribuira kod našeg operatera direktno u izvornom kodu. Možete se povezati i koristiti. Ovaj snimak ekrana mi je dao naš DevOps.

Gdje bismo željeli ići sljedeće? Ovo:

• Razviti automatizaciju testiranja. Glavni zadatak je automatizirano testiranje novih verzija.
• Također zaista želimo automatizirati integraciju sa ZooKeeperom. I planira integraciju sa ZooKeeper-operatorom. One. operator je napisan za ZooKeeper, i logično je da se dva operatera počnu integrirati kako bi napravili pogodnije rješenje.
• Želimo da radimo složenije provjere života.
• Označio sam zelenom bojom da imamo nasljeđivanje šablona na putu - GOTOVO, tj. sa sljedećim izdanjem operatora, već ćemo imati nasljeđivanje šablona. Ovo je moćan alat koji vam omogućava da napravite složene konfiguracije od komada.
• I želimo da automatizujemo složene zadatke. Glavni je Re-sharding.

Hajde da napravimo neke međurezultate.

Šta dobijamo kao rezultat? I da li se isplati ili ne? Trebam li uopće pokušati prevući bazu podataka u Kubernetes i primijeniti operator općenito i Alitnity operator posebno.

Na izlazu dobijamo:

• Dramatično pojednostavite i automatizujte konfiguraciju, primenu i održavanje.
• Odmah ugrađeni nadzor.
• I kodificirani predlošci spremni za korištenje za složene situacije. Već radnju tipa za dodavanje replike ne treba raditi ručno. To radi operater.

Ostaje samo posljednje pitanje. Već imamo bazu podataka u Kubernetesu, virtuelizacija. Što je s performansama takvog rješenja, pogotovo jer je ClickHouse optimiziran za performanse?

Odgovor je sve je u redu! Neću detaljno opisivati, ovo je tema posebnog izvještaja.

Ali postoji takav projekat kao što je TSBS. Šta je njen glavni zadatak? Ovo je test performansi baze podataka. Ovo je pokušaj da se uporedi toplo sa toplim, meko sa mekim.

Kako on radi? Generira se jedan skup podataka. Zatim se ovaj skup podataka na istom skupu testova izvodi na različitim bazama podataka. I svaka baza podataka rješava jedan problem onako kako može. I onda možete uporediti rezultate.

Već podržava veliku gomilu baza podataka. Identificirao sam tri glavna. Ovo:

• timescaledb.
• InfluxDB.
• clickhouse.

Također je napravljeno poređenje sa drugim sličnim rješenjem. Poređenje sa RedShift. Poređenje je napravljeno na Amazonu. ClickHouse je također daleko ispred svih po ovom pitanju.

Koji se zaključci mogu izvući iz onoga što sam rekao?

• DB u Kubernetesu je moguća. Vjerovatno možete sve, ali generalno izgleda da možete. ClickHouse u Kubernetesu je definitivno moguć uz pomoć našeg operatera.
• Operater pomaže u automatizaciji procesa i zaista pojednostavljuje život.
• Performanse su normalne.
• I, čini nam se da se može i treba koristiti.

Otvoreni kod - pridružite nam se!

Kao što sam rekao, operater je potpuno open source proizvod, pa bi bilo jako dobro da ga koristi maksimalan broj ljudi. Pridružite se sada! Čekamo vas sve!

Hvala svima!

Vaša pitanja

Hvala na izvještaju! Moje ime je Anton. Ja sam iz SEMrush. Pitam se šta je sa logovanjem. Slušamo o monitoringu, ali ništa o logovanju, ako govorimo o cijelom klasteru. Na primjer, imamo klaster na hardveru. I mi koristimo centralizirano evidentiranje, skupljamo ga u zajedničku hrpu standardnim sredstvima. I onda odatle dobijamo podatke koji su nam zanimljivi.

Dobro pitanje, tj. prijavljivanje na listu zadataka. Naš operater to još uvijek ne automatizira. Još se razvija, projekat je još dosta mlad. Razumijemo potrebu za evidentiranjem. Ovo je takođe veoma važna tema. I vjerovatno nije ništa manje važno od praćenja. Ali prvo na listi za implementaciju bilo je praćenje. Biće seče. Naravno, nastojimo da automatizujemo sve aspekte života klastera. Dakle, odgovor je da trenutno operater, nažalost, ne zna kako to da uradi, ali je to u planu, mi ćemo to uraditi. Ako želite da se pridružite, onda povucite zahtjev, molim.

Zdravo! Hvala na izvještaju! Imam standardno pitanje u vezi sa trajnim volumenima. Kada kreiramo konfiguraciju s ovim operatorom, kako operator određuje na kojem čvoru imamo neki disk ili mapu? Prvo mu moramo objasniti da, molim te, postavi naš ClickHouse upravo na ove čvorove koji imaju disk?

Koliko sam shvatio, ovo pitanje je nastavak lokalne memorije, posebno njegovog dijela hostPath. To je kao da cijelom sistemu objašnjavamo da je potrebno da se pod pokrene upravo na tom i tom čvoru, na kojem imamo fizički povezani disk, koji je montiran na tu i tu stazu. Ovo je cijeli dio koji sam dotaknuo vrlo površno, jer je odgovor tamo prilično velik.

Ukratko, to izgleda ovako. Naravno, mi treba da obezbedimo ove količine. Trenutno ne postoji dinamička odredba u lokalnoj pohrani, tako da DevOps mora sam rezati diskove, evo ovih volumena. I oni moraju objasniti Kubernetes proviziju, da ćete imati Persistent volumene takve i takve klase, koja se nalazi na takvim i takvim čvorovima. Tada će biti potrebno objasniti Kubernetesu da se podovi koji zahtijevaju tu i takvu lokalnu klasu pohrane moraju rasporediti prema oznakama samo za te i takve čvorove. Za ove svrhe, operater ima mogućnost da dodijeli neku vrstu oznake i jednu po instanci hosta. I ispostavilo se da će podove biti rutirani od strane Kubernetesa da rade samo na čvorovima koji ispunjavaju zahtjeve, oznake, jednostavnim riječima. Administratori dodjeljuju oznake, ručno obezbjeđuju diskove. A onda se skalira.

I samo treća opcija lokalna pomaže da se malo olakša. Kao što sam već naglasio, ovo je mukotrpan rad podešavanja, koji na kraju pomaže da se postižu maksimalne performanse.

Imam drugo pitanje vezano za ovo. Kubernetes je zamišljen tako da nam nije bitno da li ćemo izgubiti čvor ili ne. Šta da radimo u ovom slučaju ako smo izgubili čvor na kojem imamo olomak?

Da, Kubernetes je prvobitno bio pozicioniran da je naš odnos s našim mahunama kao stoka, ali ovdje svaki disk postaje nešto poput kućnog ljubimca. Postoji takav problem da ih ne možemo tek tako baciti. A razvoj Kubernetesa ide u pravcu da ga je nemoguće potpuno filozofski tretirati, kao potpuno odbačeni resurs.

Sada jedno praktično pitanje. Šta učiniti ako ste izgubili čvor na kojem se nalazio disk? Ovdje je problem riješen na višem nivou. U slučaju ClickHouse-a imamo replike koje rade na višem nivou, tj. na ClickHouse nivou.

Kakva je dispozicija? DevOps je odgovoran da osigura da podaci ne budu izgubljeni. Mora pravilno postaviti replikaciju i mora osigurati da se replikacija izvodi. U replici na ClickHouse nivou, podaci moraju biti duplicirani. Ovo nije zadatak koji operater rješava. A ne zadatak koji sam Kubernetes rješava. Ovo je na ClickHouse nivou.

Šta učiniti ako vam je gvozdeni čvor otpao? I ispostavilo se da će biti potrebno staviti drugi, pravilno premjestiti disk na njega, staviti naljepnice. A nakon toga će zadovoljiti zahtjeve da Kubernetes na njemu može pokrenuti pod instancu. Kubernetes će ga pokrenuti. Vaš broj mahuna nije dovoljan za navedenu. Proći će kroz ciklus koji sam pokazao. I na najvišem nivou, ClickHouse će shvatiti da imamo unesenu repliku, još uvijek je prazna i trebamo početi s prijenosom podataka na nju. One. ovaj proces je još uvijek slabo automatiziran.

Hvala na izvještaju! Kada se dese svakakve gadne stvari, operater se sruši i restartuje i u tom trenutku stignu događaji, da li to nekako obrađujete?

Šta se dešava ako se operater sruši i ponovo pokrene, da?

Da. I u tom trenutku su nastupili događaji.

Zadatak šta učiniti u ovom slučaju je djelimično podijeljen između operatera i Kubernetesa. Kubernetes ima mogućnost da ponovi događaj koji se dogodio. On ponavlja. A zadatak operatera je da osigura da su ti događaji idempotentni kada se na njemu reproducira dnevnik događaja. I tako da nam ponovna pojava istog događaja ne slomi naš sistem. I naš operater se nosi sa ovim zadatkom.

Zdravo! Hvala na izvještaju! Dmitrij Zavialov, kompanija Smedov. Planira li se operateru dodati opcije prilagođavanja sa haproxy? Zanimljiv je i neki drugi balanser osim standardnog, da bude pametan i shvati da je ClickHouse tu stvaran.

Govorite o Ingressu?

Da, zamijenite Ingress sa haproxy. U haproxy-ju možete specificirati topologiju klastera gdje ima replike.

Do sada nismo razmišljali o tome. Ako vam je to potrebno i možete objasniti zašto je potrebno, onda će to biti moguće implementirati, posebno ako želite da učestvujete. Rado ćemo razmotriti opciju. Kratak odgovor je ne, mi trenutno nemamo takvu funkcionalnost. Hvala na savjetu, pogledat ćemo ovo. A ako objasnite i slučaj upotrebe i zašto je to potrebno u praksi, na primjer, kreirati probleme na GitHubu, onda će biti sjajno.

Već je.

U redu. Otvoreni smo za sve prijedloge. I haproxy je stavljen na listu obaveza. Lista zadataka raste, još se ne smanjuje. Ali ovo je dobro, znači da je proizvod tražen.

izvor: www.habr.com