Izvještaj se fokusira na praktična pitanja razvoja operatora u Kubernetesu, projektiranja njegove arhitekture i osnovnih principa funkcioniranja.
U prvom dijelu izlaganja razmotrit ćemo:
- što je operator u Kubernetesu i zašto nam je potreban;
- kako operator olakšava upravljanje složenim sustavima;
- šta operator može, a šta operator ne može.
Nakon toga prelazimo na diskusiju o unutarnjoj strukturi operatora. Razmotrit ćemo arhitekturu i funkcioniranje operatora korak po korak. Detaljno ćemo obraditi:
- interakciju između operatora i Kubernetesa;
- koje funkcije operator preuzima na sebe, a šta delegira u Kubernetes.
Razmotrit ćemo upravljanje shardovima i replikama baze podataka u Kubernetesu.
Nakon toga, raspravljat ćemo o pitanjima pohrane podataka:
- kako raditi s Persistent Storage s gledišta operatora;
- zamke korištenja Local Storage.
U završnom dijelu izlaganja razmotrit ćemo praktične primjere primjene s Amazon ili Google Cloud servisom. Izvještaj se temelji na primjeru razvoja i iskustva korištenja operatora za ClickHouse.
Video:
Zovem se Vladislav Klimenko. Danas bih želio govoriti o našem iskustvu razvoja i korištenja operatora, a to je specijalizirani operator za upravljanje klasterima baza podataka. Na primjeru za upravljanje klasterom ClickHouse.
Zašto imamo mogućnost govoriti o operatoru i ClickHouseu?
- Bavimo se podrškom i razvojem ClickHousea.
- Trenutno pokušavamo polako doprinijeti razvoju ClickHousea. I drugi smo po obimu napravljenih promjena u ClickHouseu, odmah nakon Yandexa.
- Pokušavamo raditi dodatne projekte za ekosustav ClickHouse.
O jednom od takvih projekata želio bih govoriti. To je ClickHouse-operator za Kubernetes.
U svom izlaganju želio bih se dotaknuti dvije teme:
- Prva tema – kako naš operator za upravljanje bazama podataka ClickHouse u Kubernetesu radi.
- Druga tema – kako radi bilo koji operator, tj. kako on komunicira s Kubernetesom.
Ova dva pitanja će se preklapati tokom cijelog mog izlaganja.
Kome će biti zanimljivo poslušati ono što pokušavam predstaviti?
- Najzanimljivije će biti onima koji koriste operatore.
- Ili onima koji žele napraviti svoj, kako bi razumjeli kako to funkcionira iznutra, kako operator komunicira s Kubernetesom i koje zamke se mogu pojaviti.
Kako bismo najbolje razumjeli ono o čemu ćemo danas razgovarati, bilo bi dobro poznavati kako radi Kubernetes i imati osnovno znanje o oblaku.
Što je ClickHouse? To je kolumnasta baza podataka specijalizirana za online obradu analitičkih upita. I potpuno je open source.
I važno je znati samo dvije stvari. Treba znati da je to baza podataka, tako da će sve što budem pričao biti primjenjivo na gotovo bilo koju bazu podataka. I da se SGBD ClickHouse vrlo dobro skalira, gotovo linearno pruža skalabilnost. Stanje klastera je stoga za ClickHouse prirodno stanje. Najviše nas zanima raspraviti kako održavati ClickHouse klaster u Kubernetesu.
Zašto je potreban tamo? Zašto ne možemo nastaviti raditi sami? Odgovori su djelomično tehnički, a djelomično organizacijski.
- U praksi se sve više susrećemo sa situacijom gdje su u velikim tvrtkama gotovo svi komponenti već u Kubernetesu. Baze podataka ostaju izvan.
- I sve se češće postavlja pitanje: „Može li se to smjestiti unutra?“. Zato velike tvrtke nastoje postići maksimalnu unifikaciju upravljanja kako bi brzo mogle upravljati svojim skladištima podataka.
- I to posebno pomaže ako je potrebna maksimalna mogućnost ponovnog postavljanja na novom mjestu, tj. maksimalna prenosivost.
Koliko je to jednostavno ili teško? Naravno, to se može raditi ručno. Ali nije tako jednostavno, jer se zbraja složenost upravljanja samim Kubernetesom, dok se istovremeno pridodaje specifičnost ClickHousea. Tako dolazi do agregacije.
Sve zajedno daje dovoljno velik skup tehnologija kojima se upravlja, što postaje već dovoljno složeno, jer Kubernetes donosi svoja svakodnevna pitanja za rad, a ClickHouse donosi svoja pitanja za svakodnevni rad. Osobito, ako imamo više ClickHousea i stalno trebamo nešto raditi s njima.
ClickHouse uz dinamičku konfiguraciju ima dovoljno velik broj pitanja koja stvaraju stalni opterećenje na DevOps:
- Kada želimo promijeniti nešto u ClickHouseu, na primjer, dodati replikaciju, shard, moramo upravljati konfiguracijom.
- Zatim promijeniti shemu podataka, jer ClickHouse ima specifičan način shardiranja. Tamo je potrebno rasporediti shemu podataka i rasporediti konfiguracije.
- Trebate postaviti monitoring.
- Prikupljanje logova za nove shardove, za nove replike.
- Pobrinuti se za oporavak.
- I ponovno pokretanje.
To su rutinski poslovi koje bi bilo lijepo olakšati u eksploataciji.
Sam Kubernetes dobro pomaže u eksploataciji, ali u osnovnim sistemskim stvarima.
Kubernetes dobro olakšava i automatizira takve stvari kao što su:
- Oporavak.
- Ponovno pokretanje.
- Upravljanje sustavom pohrane.
To je dobro, to je ispravna smjernica, ali on u potpunosti nema predstavu o tome kako eksploatirati klaster baze podataka.
Želi se više, želi se da nam cijela baza podataka radi u Kubernetesu.
Želi se dobiti nešto poput velikog čarobnog crvenog dugmeta koje pritisneš i pokrene se i održava tijekom cijelog životnog ciklusa klaster s dnevnim zadacima koje je potrebno rješavati. Klaster ClickHouse u Kubernetesu.
I trudili smo se napraviti takvo rješenje koje bi olakšalo rad. To je ClickHouse-operator za Kubernetes od tvrtke Altinity.
Operator je program, čija je glavna zadaća upravljati drugim programima, tj. to je menadžer.
I sadrži obrasce ponašanja. To se može nazvati kodificiranim znanjima o predmetnom području.
I njegova glavna zadaća je olakšati život DevOps-u i smanjiti mikroupravljanje, kako bi on (DevOps) razmišljao u pojmovima visokog nivoa, tj. da se ne bavi mikroupravljanjem niti manualnom konfiguracijom svih detalja.
I upravo je operator robot asistent koji se bori protiv mikrozadataka i pomaže DevOps-u.
Zašto je potreban operator? Posebno dobro se pokazuje u dva pitanja:
- Kada stručnjaku koji se bavi ClickHouse-om nedostaje iskustva, ali već treba eksploatirati ClickHouse, operator olakšava eksploataciju i omogućava eksploataciju klastera ClickHouse sa dovoljno složenom konfiguracijom, pritom ne upuštajući se previše u detalje o tome kako to sve radi iznutra. Samo mu se daju visoko nivojski zadaci, i to funkcionira.
- I druga zadaća u kojoj se najbolje pokazuje je automatizacija velikog broja standardnih zadataka. Uklanja mikrozadatke sa sustavnih administratora.
To je najpotrebnije ili onima koji tek započinju svoj put, ili onima koji se puno bave automatizacijom.
Koja je razlika između pristupa temeljenog na operatorima i drugih sustava? Ima i Helm. Također pomaže u postavljanju ClickHouse-a, može se nacrtati helm charts koji čak postavljaju cijeli klaster ClickHouse-a. Koja je onda razlika između operatora i Helm-a?
Osnovna temeljna razlika je u tome što je Helm upravljanje paketima, dok operator ide dalje. To je praćenje cijelog životnog ciklusa. To nije samo instalacija, već svakodnevni zadaci koji uključuju skaliranje, shardiranje, tj. sve što je potrebno izvršiti tijekom životnog ciklusa (ako je potrebno, i uklanjanje) – to sve rješava operator. Pokušava automatizirati i održavati cijeli životni ciklus softvera. U tome leži njegova temeljna razlika od drugih predstavljenih rješenja.
To je bila uvodna dio, idemo dalje.
Kako gradimo svoj operator? Pokušavamo pristupiti pitanju upravljanja klasterom ClickHouse kao jednim izvorom.
Evo, s lijeve strane slike imamo ulazne podatke. To je YAML s specifikacijom klastera, koji se na klasičan način prenosi u Kubernetes putem kubectl-a. Tamo naš operator preuzima, izvodi svoju magiju. I na izlazu dobivamo ovakvu shemu. To je implementacija ClickHouse-a u Kubernetesu.
I dalje ćemo polako gledati kako operator zapravo radi, koje tipične zadatke možemo rješavati. Razmotrit ćemo samo tipične zadatke, jer imamo ograničeno vrijeme. I neće biti riječi o svemu što operator može riješiti.
Oslonimo se na praksu. Naš projekt je potpuno open source, stoga možete pogledati na GitHubu kako to funkcionira. I može se krenuti od ideje, ako želite samo pokrenuti, s Quick Start Guide možete početi.
Ako želite detaljno istražiti, trudimo se održavati dokumentaciju u više-manje pristojnom stanju.
Započnimo sa praktičnim zadatkom. Prvi zadatak s kojim želimo početi jest pokrenuti prvi primjer na bilo koji način. Kako pokrenuti ClickHouse putem operatora, čak i ne znajući mnogo o tome kako radi? Pišemo manifest, budući da je sva komunikacija s k8s komunikacija putem manifestata.
Evo jednog složenog manifesta. Ono što je označeno crvenom bojom je ono na čemu trebamo naglasiti. Od operatora tražimo da stvori klaster imenom demo.
Za sada su to osnovni primjeri. Pohrana (Storage) još nije opisana, ali ćemo se na pohranu vratiti malo kasnije. Za sada ćemo pratiti razvoj klastera.
Stvorili smo ovaj manifest. Donosimo ga našem operatoru. On je radio i napravio magiju.
Gledamo u konzolu. Interesantna su tri komponente – to su Pod, dva servisa (Service-a), StatefulSet.
Operator je odradio i možemo vidjeti što je točno stvorio.
Stvara otprilike ovakav raspored. Imamo StatefulSet, Pod, ConfigMap za svaku replikaciju, ConfigMap za cijeli klaster. Obavezno su potrebni servisi kao ulazne točke u klaster.
Servisi – to su centralni Load Balancer Service i još jedan za svaku replikaciju, za svaki shard.
Naš osnovni klaster izgleda otprilike ovako. Sastoji se od jedne jedine čvor (node).
Idemo dalje, zakomplicirajmo stvari. Trebamo shardirati klaster.
Naši zadaci rastu, počinje dinamika. Želimo dodati shard. Pratimo razvoj. Mijenjamo našu specifikaciju. Navodimo da želimo dva sharda.
To je isti onaj fajl koji se dinamički razvija s rastom sustava. Pohrana ne postoji, pohrana će biti razmatrana kasnije, to je posebna tema.
Dajemo YAML operatoru i gledamo što se događa.
Operator je razmislio i stvorio sljedeće entitete. Već imamo dva Poda, tri Servisa i, iznenada, 2 StatefulSet-a. Zašto 2 StatefulSet-a?
Na dijagramu je bilo ovako – ovo je naše prvotno stanje, kada je postojao jedan pod.
Postalo je ovako. Za sada je sve jednostavno, duplicirano je.
I zašto je StatefulSet postao dva? Ovdje se trebamo odmaknuti i raspraviti o tome kako se u Kubernetes-u upravlja Pod-ovima.
Postoji objekt pod nazivom StatefulSet, koji omogućuje kreiranje skupa Pod-ova iz predloška. Ključni faktor ovdje je Template. U jednom StatefulSet-u možete pokrenuti više Pod-ova iz jednog predloška. Ključna fraza ovdje je 'više Pod-ova iz jednog predloška'.
Postojala je velika iskušenja da se cijeli klaster pakira u jedan StatefulSet. To bi funkcioniralo, tu nema nikakvih problema. No postoji jedan uvjet. Ako želimo sastaviti heterogeni klaster, tj. od više verzija ClickHouse-a, tada se javljaju pitanja. Da, StatefulSet može izvršiti rolling update, da se može primijeniti nova verzija, objašnjavajući da ne bi trebalo imati više od toliko nodova odjednom.
Ali ako ekstrapoliramo zadatak i kažemo da želimo stvoriti potpuno heterogeni klaster i ne želimo zamijeniti staru verziju s novom pomoću rolling update-a, već jednostavno želimo stvoriti heterogeni klaster u smislu različitih verzija ClickHouse-a, tako i u smislu različitog storage-a. Želimo, na primjer, neke replike napraviti na posebnim diskovima, sporim, općenito, potpuno izgraditi heterogeni klaster. I zbog toga što StatefulSet stvara standardizirano rješenje iz jednog predloška, nema mogućnosti to ostvariti.
Nakon nekog razmišljanja donesena je odluka da ćemo to napraviti ovako. Svaka replika ima svoj StatefulSet. Ima nekih nedostataka u ovom rješenju, ali u praksi sve to potpuno inkapsulira operator. I ima mnogo prednosti. Možemo izgraditi potpuno takav klaster kakav želimo, na primjer, apsolutno heterogen. Stoga, u klasteru gdje imamo dva shard-a sa jednom replikom, imat ćemo 2 StatefulSet-a i 2 Pod-a upravo zbog toga što smo izabrali takav pristup iz navedenih razloga za mogućnost izgradnje heterogenog klastera.
Vratimo se praktičnim zadacima. U našem klasteru potrebno je postaviti korisnike, tj. potrebno je izvršiti neku konfiguraciju ClickHouse-a u Kubernetes-u. Operator za to pruža sve mogućnosti.
Možemo direktno u YAML-u pisati ono što želimo. Sve konfiguracijske opcije mapiraju se iz ovog YAML-a u ClickHouse konfiguracije, koje se potom raspoređuju po cijelom klasteru.
Može se pisati i ovako. Ovo je samo primjer. Lozinka se može napraviti šifriranom. Podržavaju se apsolutno sve konfiguracijske opcije ClickHouse-a. Ovdje je samo primjer.
Konfiguracija se po klasteru širi kao ConfigMap. U praksi, ažuriranje ConfigMap-a ne događa se odmah, stoga, ako je klaster velik, proces prenošenja konfiguracije traje nešto vremena. Ali sve to je vrlo prikladno za eksploataciju.
Komplikujemo zadatak. Klaster se razvija. Želimo replicirati podatke. Drugim rečima, već imamo dva šarda, po jednu repliku, korisnici su podešeni. Raste i želimo se baviti replikacijom.
Šta nam je potrebno za replikaciju?
Potreban nam je ZooKeeper. U ClickHouse replikacija je izgrađena uz pomoć ZooKeeper-a. ZooKeeper je potreban kako bi različite replike ClickHouse-a imale konsenzus o tome koji blokovi podataka postoje na kojem ClickHouse-u.
Može se koristiti bilo koji ZooKeeper. Ako preduzeće ima eksterni ZooKeeper, može se koristiti. Ako ne, može se instalirati iz našeg repozitorija. Postoji instalater koji sve ovo olakšava.
I shema interakcije celog sistema izgleda ovako. Imamo Kubernetes kao platformu. Na njemu se izvršava ClickHouse operator. ZooKeeper sam prikazao ovde. I operator komunicira sa ClickHouse-om i sa ZooKeeper-om. Drugim rečima, dolazi do interakcije.
Sve ovo je potrebno kako bi ClickHouse uspešno replikovao podatke u k8s.
Hajde da pogledamo samo zadatak, kako će izgledati manifest za replikaciju.
U naš manifest dodajemo dve sekcije. Prva - gde uzimamo ZooKeeper, koji može biti unutar Kubernetes-a ili eksterni. Ovo je jednostavno opisivanje. I naručujemo replikacije. Drugim rečima, želimo dve replike. Dakle, na izlazu treba da imamo 4 pod-a. Za skladište se sećamo, vratiće se malo kasnije. Skladište - to je posebna priča.
Bilo je ovako.
Sada izgleda ovako. Dodaju se replike. 4. nije stajala, verujemo da ih može biti mnogo. I sa strane se dodaje ZooKeeper. Schemi se komplikuju.
I vreme je da dodamo sledeći zadatak. Počećemo da dodajemo Persistent Storage.
Što se tiče Persistent Storage, imamo različite opcije realizacije.
U slučaju da se izvršavamo u cloud provajderu, na primer, koristeći Amazon, Google, postoji velika primamljivost da se iskoristi cloud storage. To je veoma zgodno, to je dobro.
I postoji druga opcija. To je za lokalno skladište, kada imamo lokalne diskove na svakoj nodi. Ova opcija je mnogo složenija za realizaciju, ali je pritom i produktivnija.
Hajde da vidimo šta imamo u vezi sa cloud storage-om.
Postoje prednosti. Veoma je lako konfigurirati. Samo naručimo od cloud provajdera, daj nam, molim te, skladište određene kapaciteta, određene klase. Klase su opisane od strane provajdera.
I postoji nedostatak. Za nekoga je to neprimjetan nedostatak. Naravno, bit će nekih problema s performansama. Ovo je vrlo praktično za rad, pouzdano je, ali postoje određeni potencijalni padovi u performansama.
Kako je ClickHouse usredotočen na performanse, može se čak reći da izvlači maksimum iz svega što može, stoga mnogi klijenti nastoje izvući najviše performansi.
A kako bismo izvukli maksimum, potrebna nam je lokalna pohrana.
Kubernetes pruža tri apstrakcije za korištenje lokalne pohrane. To su:
- EmptyDir
- HostPath.
- Local
Razmotrit ćemo kako se razlikuju i po čemu su slični.
Prvo, u sva tri pristupa, pohrana su lokalni diskovi koji se nalaze na istoj fizičkoj k8s nodi. No, postoji nekoliko razlika.
Započet ćemo s najjednostavnijim, tj. s emptyDir. Što to praktički znači? To je da tražimo od naše specifikacije da nam sustav kontejnerizacije (najčešće je to Docker) omogući pristup mapi na lokalnom disku.
U praksi, Docker negdje u svojim vlastitim putanjama stvara privremenu mapu, naziva je dugim hešem. I omogućuje pristup toj mapi.
Kako će to funkcionirati po pitanju performansi? Funkcionirat će brzinom lokalnog diska, tj. to je potpuno pristup vlastitom disku.
No, ova pojava ima svoj nedostatak. Persistent pohrana u ovome je prilično sumnjiva. Pri prvom pomaku Dockera s kontejnerima, Persistent se gubi. Ako Kubernetes iz nekog razloga želi premjestiti ovu Pod na drugi disk, podaci će se izgubiti.
Ovaj pristup je dobar za testiranje, jer pokazuje normalnu brzinu, ali za nešto ozbiljnije ovaj izbor nije prikladan.
Stoga postoji drugi pristup. To je hostPath. Ako pogledate prethodni slajd i ovaj, možete vidjeti samo jednu razliku. Naša mapa je izašla iz Dockera direktno na Kubernetes nodu. Tu je malo jednostavnije. Direktno navodimo put po lokalnom datotečnom sustavu gdje bismo željeli pohraniti svoje podatke.
Ovaj način ima svoje prednosti. To je već prava Persistent pohrana, i to klasična. Na disku će biti zapisana podaci na nekoj adresi.
Postoje i nedostaci. To je složenost upravljanja. Naš Kubernetes može poželjeti premjestiti Pod na drugi fizički čvor. I tada dolazi do izražaja DevOps. On mora pravilno objasniti cijelom sustavu da se ti podovi mogu premještati samo na one čvorove na kojima imate nešto montirano putem tih putanja i ne više od jednog čvora odjednom. To je prilično složeno.
Specijalno za te svrhe, mi smo u našem operateru napravili predloške kako bismo svu tu složenost sakrili. I moglo bi se jednostavno reći: „Želim da imam jedan instance ClickHouse-a na svakoj fizičkoj čvoru i po takvom putu“.
Ali ta potreba nije potrebna samo nama, stoga gospoda iz samog Kubernetesa također razumiju da ljudima treba pristup fizičkim diskovima, pa oni pružaju treću razinu.
Ona se zove local. Razlike od prethodnog slajda praktički nema. Samo što je ranije trebalo ručno provoditi pravila da se ti podovi ne smiju premještati s čvora na čvor, jer moraju biti vezani na takav put za lokalni fizički disk, a sad se sve te informacije inkapsuliraju u Kubernetesa. I postaje mnogo jednostavnije konfigurirati.
Vratimo se našoj praktičnoj zadatku. Vratimo se YAML predlošku. Tu imamo pravi storage. Vratili smo se tome. Postavljamo klasični VolumeClaim predložak kao u k8s. I opisujemo koji storage želimo.
Nakon toga k8s će zatražiti storage. Dodelit će nam ga u StatefulSet-u. I na kraju će to biti na raspolaganju ClickHouse-u.
Imali smo ovakvu shemu. Naš Persistent Storage bio je crven, što nam je kao nagovijestilo da bismo ga trebali napraviti.
I postaje zeleni. Sada je shema klastera ClickHouse na k8s potpuno finalizirana. Imamo shardove, replike, ZooKeeper, imamo pravi Persistent, koji je realiziran na ovaj ili onaj način. Shema je već potpuno funkcionalna.
Nastavljamo živjeti dalje. Naš klaster se razvija. I Aleksey se trudi i objavljuje novu verziju ClickHouse-a.
Pojavljuje se praktični zadatak – testirati novu verziju ClickHouse-a na našem klasteru. Pri tome, naravno, ne želimo je primijeniti na cijeli klaster, želimo negdje u udaljeni kutak staviti novu verziju, ili možda ne samo jednu novu verziju, već odmah dvije, jer one često izlaze.
Što možemo reći o tome?
Ovdje imamo upravo tu priliku. To su predlošci podova. Možemo ih definirati, naš operator potpuno omogućuje izgradnju heterogenog klastera. To jest, možemo konfigurirati, počevši od svih replikacija kao skupa, do svake pojedinačne replike, koju verziju ClickHouse-a želimo, koju verziju storage-a želimo. Potpuno možemo konfigurirati klaster prema našim potrebama.
Malo ćemo se dublje uputiti. Do sada smo govorili o tome kako ClickHouse-operator funkcionira u vezi sa specifičnostima ClickHouse-a.
Sada bih želio reći nekoliko riječi o tome kako funkcionira bilo koji operator, kao i o tome kako se on povezuje s K8s.
Razmotrit ćemo interakciju s K8s na početku. Što se događa kada napravimo kubectl apply? Naši objekti se pojavljuju u etcd putem API-ja.
Na primjer, osnovni objekti Kubernetes-a: pod, StatefulSet, servis i tako dalje.
Pri tome, fizički se još ništa ne događa. Ove objekte trebamo materializirati u klasteru.
Za to dolazi kontroler. Kontroler je specijalna komponenta k8s koja zna materializirati ove opise. On zna kako i što treba učiniti fizički. Zna kako pokrenuti kontejnere i što treba konfigurirati da bi server radio.
I on materializira naše objekte u K8s.
Ali želimo upravljati ne samo pod-ovima i StatefulSet-ima, želimo stvoriti ClickHouseInstallation, tj. objekt tipa ClickHouse, kako bismo njime upravljali kao jedinstvenom cjelinom. Za sada ta mogućnost ne postoji.
Ali K8s ima još jednu lijepu stvar. Želimo da imamo negdje takvu složenu jedinstvenu tvorevinu, koja će biti sastavljena od pod-ova i StatefulSet-a našeg klastera.
Što je potrebno učiniti za to? Prvo, na scenu stupa Custom Resource Definition. Što je to? To je opis za K8s koji definira da će imati još jedan tip podataka, da želimo dodati prilagođeni resurs pod, StatefulSet-u, koji će biti složen iznutra. To je opis strukture podataka.
Također ga šaljemo preko kubectl apply. Kubernetes ga s radošću prihvaća.
I sada u našem skladištu, kod objekta u etcd, nabavljamo mogućnost da zapišemo prilagođeni resurs pod nazivom ClickHouseInstallation.
Ali za sada se ništa dalje neće dogoditi. Odnosno, ako sada stvorimo YAML datoteku koju smo razmatrali s opisom shardova, replika i kažemo 'kubectl apply', Kubernetes će je prihvatiti, pohraniti u etcd i reći: 'Odlično, ali ne znam što učiniti s tim. Kako održavati ClickHouseInstallation, nemam pojma.'
Prema tome, potrebna nam je osoba koja će pomoći Kubernetesu u održavanju novog tipa podataka. S lijeve strane imamo ugrađeni kontroler Kubernetesa koji radi s ugrađenim tipovima podataka. A s desne strane trebao bi se pojaviti prilagođeni kontroler koji može raditi s prilagođenim tipovima podataka.
I drugačije se naziva operator. Ovdje sam ga namjerno istaknuo izvan K8s, jer se može izvoditi i izvan K8s. Najčešće, naravno, svi operatori se izvode unutar Kubernetesa, ali ništa ne sprječava da stoji izvana, pa je ovdje posebno istaknut izvana.
I već u svoju ruku prilagođeni kontroler, odnosno operator, komunicira s Kubernetesom putem API-ja. On već zna kako komunicirati s API-jem. I on već zna kako iz prilagođenog resursa materijalizirati složeni obrazac koji želimo stvoriti. Time se bavi operator.
Kako radi operator? Pogledajmo desnu stranu kako bismo saznali kako to radi. Saznat ćemo kako operator sve to materijalizira i kako dalje dolazi do interakcije s K8s.
Operator je program. On je orijentiran na događaje. Operator se uz pomoć Kubernetes API-ja pretplaćuje na događaje. U Kubernetes API-ju postoje ulazne točke na koje se može pretplatiti na događaje. I ako dođe do promjene u K8s, Kubernetes šalje događaje svima koji su zainteresirani, tj. tko se pretplatio na tu točku API-ja, taj će primiti obavijesti.
Operator se pretplaćuje na događaje i treba učiniti neku reakciju. Njegov zadatak je reagirati na nastale događaje.
Događaji se generiraju određenim ažuriranjima. Naša YAML datoteka s opisom ClickHouseInstallation dolazi. Ona je putem kubectl apply otišla u etcd. Tamo se dogodio event, u konačnici je taj event došao do ClickHouse-operatjera. Operator je primio ovaj opis. I on mora nešto učiniti. Ako je stiglo ažuriranje objekta ClickHouseInstallation, treba ažurirati klaster. I zadatak operatora je ažurirati klaster.
Što on radi? Prvo, potrebno je sastaviti plan akcije, što ćemo raditi s ovom nadogradnjom. Nadogradnje mogu biti vrlo male, tj. male u YAML izvedbi, ali mogu izazvati velike promjene u klasteru. Stoga, operator stvara plan i zatim ga slijedi.
On počinje prema tom planu stvarati ovu strukturu unutar, kako bi materializirao podove, servise, tj. obavljao ono što mu je osnovni zadatak. To je kao izgradnja ClickHouse klastera u Kubernetesu.
Sada se dotaknimo jedne zanimljive stvari. To je podjela odgovornosti između Kubernetesa i operatora, tj. što radi Kubernetes, što radi operator i kako međusobno djeluju.
Kubernetes je odgovoran za sistemske stvari, tj. za osnovni skup objekata koji se može interpretirati kao sustavske stvari. Kubernetes zna kako pokrenuti podove, kako ponovno pokrenuti kontejnere, kako montirati volumene, kako raditi s ConfigMap, tj. sve što se može nazvati sustavom.
Operatori djeluju u smislu predmetnih područja. Svaki operator se razvija za svoje predmetno područje. Mi smo razvili za ClickHouse.
Operator djeluje upravo u terminima predmetnog područja, poput dodavanja replike, izrade sheme, postavljanja monitoringa. To rezultira tom podjelom.
Pogledajmo praktičan primjer kako se ta podjela odgovornosti odvija kada izvršavamo radnju dodavanja replike.
Operator dobija zadatak – dodati repliku. Što operator radi? Operator će izračunati da je potrebno stvoriti novi StatefulSet, u kojem treba opisati određene predloške, potraživanje volumena.
Sve to priprema i dalje prosljeđuje u K8s. Kaže da mu trebaju ConfigMap, StatefulSet, Volumen. Kubernetes to obrađuje. Materijalizira osnovne jedinice s kojima upravlja.
I dalje uvođenjem ponovo dolazi ClickHouse-operator. Već ima fizički pod na kojem može raditi. I ClickHouse-operator ponovo radi u terminima predmetnog područja. Tj. konkretno ClickHouse da uključi repliku u klaster, prvo je potrebno postaviti shemu podataka koja u tom klasteru postoji. A, drugo, tu repliku treba uključiti u monitoring, kako bi bila dobro praćena. To već operator postavlja.
I samo nakon toga u posao ulazi sam ClickHouse, tj. još jedan viši nivo entiteta. To je već baza podataka. Ima svoj instance, još jednu repliku konfiguriranu, koja je spremna da uđe u klaster.
Dakle, lanac izvršavanja i razdvajanja odgovornosti prilikom dodavanja replike je dovoljno dug.
Nastavljamo naše praktične zadatke. Ako klaster već postoji, može se izvršiti migracija konfiguracije.
Učinili smo tako da se u postojeći xml, koji ClickHouse razume, može proći kroz.
Može se izvršiti fino podešavanje ClickHousea. Baš zoned deployment - to je ono o čemu sam pričao prilikom objašnjavanja hostPath, lokalne pohrane. Ovo je kako pravilno uraditi zoned deployment.
Sljedeći praktični zadatak – monitoring.
Ako se naš klaster menja, povremeno je potrebno podešavati monitoring.
Pogledajmo shemu. Zelene strelice ovde smo već razmotrili. Sada da razmotrimo crvene strelice. To je način na koji želimo da pratimo naš klaster. Kako metrike iz klastera ClickHouse ulaze u Prometheus, a zatim u Grafana.
A koja je složenost s monitoringom? Zašto se to ističe kao neki postignuće? Složenost leži u dinamici. Kada imamo jedan klaster i on je statičan, može se jednom podesiti monitoring i onda više ne brinuti.
Ali ako imamo mnogo klastera ili se stalno nešto menja, proces je dinamičan. Stalno se baviti ponovnim podešavanjem monitoringa je trošenje resursa i vremena, tj. čak i jednostavna lenjost. To treba automatizovati. Složenost leži upravo u dinamici procesa. I operater to veoma dobro automatizuje.
Kako se naš klaster razvijao? Na početku je bio ovakav.
Zatim je bio ovakav.
Na kraju je postao ovakav.
A monitoring se automatski obavlja od strane operatera. Jedina tačka pristupa.
I mi samo na izlazu gledamo u Grafana dashboard, kako unutra živi život našeg klastera.
Usput, Grafana dashboard se takođe distribuira s našim operaterom direktno u izvorima. Može se povezati i koristiti. Ovu sliku su mi dali naši DevOps.
Kuda bismo želeli ići dalje? To je:
- Razvijati automatizaciju testiranja. Glavni zadatak je automatizovano testiranje novih verzija.
- Također želimo automatizirati integraciju s ZooKeeper-om. Planiramo se integrirati s ZooKeeper-operatorom. To jest, za ZooKeeper napisan je operator i logično je da se dva operatora integriraju za izgradnju praktičnijeg rješenja.
- Želimo napraviti složenije provjere održivosti.
- Zelenom sam označio ono što nam dolazi – nasljeđivanje predložaka – GOTOVO, to jest, s sljedećim izdanjem operatora već ćemo imati nasljeđivanje predložaka. To je moćan alat koji omogućuje gradnju složenih konfiguracija od dijelova.
- Želimo automatizaciju složenih zadataka. Glavni od njih je Re-sharding.
Hajde da napravimo međufinalne rezultate.
Što dobijamo na izlazu? I vrijedi li se time baviti ili ne? Treba li uopće pokušati uvući bazu podataka u Kubernetes i primijeniti operator u cjelini, a posebno Alitnity-operator?
Na izlazu dobijamo:
- Značajno pojednostavljenje i automatizaciju konfiguriranja, implementacije, ali i održavanja.
- Odmah ugrađeno praćenje.
- I gotovi za korištenje kodificirani predlošci za složene situacije. Već akcija poput dodavanja replikacije ne treba raditi ručno. To radi operator.
Ostalo je samo posljednje pitanje. Već imamo bazu podataka u Kubernetesu, virtualizaciju. Što je s performansama tog rješenja, posebno s obzirom na to da je ClickHouse optimiziran za performanse?
Odgovor – sve je u redu! Neću detaljno opisivati, to je tema zasebnog izlaganja.
Ali postoji projekt pod nazivom TSBS. Koji je njegov glavni zadatak? To je testiranje baza podataka na performanse. To je pokušaj usporedbe toplog s toplim, mekog s mekim.
Kako to radi? Generira se jedan set podataka. Zatim se taj set podataka na istom skupu testova prolazi kroz različite baze podataka. I svaka baza podataka rješava jedan zadatak onako kako ga zna. A potom se mogu uspoređivati rezultati.
Već podržava veliki broj baza podataka. Istaknuo sam tri glavne. To su:
- TimescaleDB.
- InfluxDB.
- ClickHouse.
Također je provedena usporedba s još jednim sličnim rješenjem. Usporedba s RedShift-om. Usporedba je provedena na Amazonu. ClickHouse također dobro nadmašuje sve u ovom pogledu.
Koje se zaključke mogu izvući iz onoga što sam ispričao?
- DB u Kubernetes je moguć. Vjerojatno je moguće sve, ali u cjelini izgleda da je to moguće. ClickHouse u Kubernetesu definitivno može putem našeg operatora.
- Operator pomaže automatizirati procese i stvarno olakšava život.
- Performanse su zadovoljavajuće.
- I, čini nam se da se to može i treba koristiti.
Open source – pridružite se!
Kao što sam već spomenuo, operator je potpuno open source proizvod, stoga bi bilo jako dobro da što više ljudi to koristi. Pridružite se! Čekamo vas sve!
Hvala svima!
Pitanja
Hvala na prezentaciji! Ja sam Anton. Dolazim iz tvrtke SEMrush. Zanima me što s logiranjem. O monitoringu se čuje, ali o logiranju ništa, ako govorimo o klasteru u cjelini. Kod nas je, na primjer, podignut klaster na hardveru. I koristimo centralizirano logiranje, standardnim metodama prikupljamo u zajedničku bazu. A zatim odatle izvlačimo zanimljive podatke.
Dobar вопрос, tj. logiranje je na listi zadataka. Naš operator za sada to ne automatizira. Još se razvija, projekt je još dovoljno mlad. Razumijemo potrebu za logiranjem. To je također vrlo važno pitanje. I vjerovatno nije manje važno od monitoringa. No, prvi na listi za implementaciju bio je monitoring. Logiranje će biti. Naravno, nastojimo automatizirati sve aspekte rada klastera. Stoga odgovor - u trenutnom trenutku operator, nažalost, to ne zna, ali to je u planovima i napravit ćemo to. Ako postoji želja pridružiti se, slobodno napravite pull request.
Dobar dan! Hvala na prezentaciji! Imam standardno pitanje vezano za Persistent Volumes. Kada kreiramo konfiguraciju ovim operatorom, kako operator definira na kojoj nodi imamo montirani neki disk ili folder? Moramo mu unaprijed objasniti da, molim vas, postavite naš ClickHouse upravo na tim nodama na kojima postoji disk?
Koliko razumijem, ovo pitanje je nastavak local storage, osobito dijela o hostPath. To je kao objasniti cijelom sustavu da treba da pod bude pokrenut na određenoj nodi na kojoj imamo fizički priključen disk koji je montiran na određenu putanju. To je cijela sekcija koju sam dodirnuo vrlo površno, jer je odgovor prilično opširan.
Ukratko, to izgleda ovako. Naravno, moramo obaviti provisioning ovih volumena. Trenutno u lokalnom skladištu nema dinamičkog provisioninga, pa DevOps timovi moraju sami podijeliti diskove, te volumene. Također, moraju objasniti Kubernetes provisioningu da će imati Persistent volumene određenog razreda, koji se nalaze na određenim čvorovima. Zatim treba objasniti Kubernetesu da se podovi koji zahtijevaju takav razred lokalnog skladišta trebaju raspoređivati samo na takve čvorove prema etiketama. Za te namjene u operatoru postoji mogućnost dodjeljivanja neke etikete i one per host instance. Tako će podovi biti usmjereni od strane Kubernetesa za pokretanje samo na čvorovima koji zadovoljavaju te zahtjeve, jednostavnim jezikom govoreći. Administratori dodjeljuju etikete, ručno rade provisioning diskova. I tada se to može skalirati.
Treća opcija lokalnog skladišta pomaže da se to malo olakša. Kao što sam već naglasio, to je mukotrpan zadatak postavljanja, koji na kraju pomaže da se ostvari maksimalna izvedba.
Imam drugo pitanje vezano uz ovo. Kubernetes je zamišljen tako da nije važno hoćemo li izgubiti čvor ili ne. Što trebamo učiniti u tom slučaju, ako izgubimo čvor na kojem se nalazi shard?
Da, Kubernetes je izvorno pozicioniran tako da je naš odnos prema našim podovima poput stoke, a svaki disk ovdje postaje nešto poput kućnog ljubimca. Postoji problem u tome što ih ne možemo jednostavno odbaciti. Razvoj Kubernetesa ide u smjeru da se prema tome ne može potpuno filozofski odnositi kao prema resursima koji se potpuno odbacuju.
Sada praktično pitanje. Što učiniti ako izgubiš čvor na kojem se nalazio disk? Tada se problem rješava na višoj razini. U slučaju ClickHousea imamo replike koje rade na višoj razini, odnosno na razini ClickHousea.
Koja je situacija? Za sprječavanje gubitka podataka odgovoran je DevOps. Mora pravilno postaviti replikaciju i paziti da se replikacija provodi. Na razini ClickHousea podaci u replici trebaju biti duplicirani. To nije zadatak koji rješava operator. I nije to zadatak koji rješava sam Kubernetes. To je na razini ClickHousea.
Što učiniti ako vam je otišao hardverski čvor? Morat ćete postaviti drugi čvor, ispravno provizoriti disk i dodati oznake. Nakon toga, moći će zadovoljiti zahtjeve da Kubernetes može pokrenuti instancu pod-a na njemu. Kubernetes će to pokrenuti. Broj pod-ova vam ne odgovara očekivanom. Proći će kroz ciklus koji sam pokazao. Na najvišoj razini ClickHouse će razumjeti da nam je došla replika, koja je još prazna i na nju treba početi prebacivati podatke. Taj proces još nije potpuno automatiziran.
Hvala na izlaganju! Kada se događaju razne nevolje, operator se sruši i ponovno pokrene, a u tom trenutku dolaze događaji, kako to obrađujete?
Što će se dogoditi ako se operator sruši i ponovno pokrene?
Da. I u tom trenutku zaprimljeni su događaji.
Zadatak što učiniti u tom slučaju dijelom se dijeli između operatera i Kubernetesa. Kubernetes ima mogućnost ponovnog reprodukcije događaja koji su se dogodili. On to ponovo reproducira. A zadatak operatera je osigurati da kada se izvrši ponovna reprodukcija dnevnika događaja, ti događaji budu idempotentni. Da ponovno dolazak istog događaja ne uništi naš sustav. I naš operator se nosi s tim zadatkom.
Pozdrav! Hvala na izlaganju! Dmitrij Zavaljov, tvrtka Smedova. Planira li se dodati mogućnost postavljanja s haproxy u operator? Interesira me neki drugi balansator osim standardnog, koji bi bio pametan i razumio da je stvarno ClickHouse.
Govoriš o Ingressu?
Da, zamijeniti Ingress s haproxy. U haproxy možete naznačiti topologiju klastera u kojem su njegovi replikati.
Za sada o tome nismo razmišljali. Ako vam je to potrebno i možete objasniti zašto je to potrebno, moglo bi se implementirati, posebno ako želite sudjelovati. Rado ćemo razmotriti tu mogućnost. Kratak odgovor – ne, trenutno nemamo tu funkcionalnost. Hvala na prijedlogu, pogledat ćemo to. A ako nam dodatno objasnite use case i zašto je to potrebno u praksi, na primjer, ako kreirate issue na GitHubu, bilo bi odlično.
Već postoji.
Dobro. Otvoreni smo za sve prijedloge. I haproxy se stavlja na listu obaveza. Lista obaveza raste, a ne smanjuje se, barem za sada. To je dobro, znači da je proizvod tražen.
Izvor: habr.com
