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

Izvješće je posvećeno praktičnim pitanjima razvoja operatora u Kubernetesu, projektiranju njegove arhitekture i osnovnim principima rada.

U prvom dijelu izvješća razmotrit ćemo:

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

Zatim, prijeđimo na raspravu o unutarnjoj strukturi operatora. Pogledajmo arhitekturu i rad operatora korak po korak. Pogledajmo to detaljno:

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

Pogledajmo upravljanje shardovima i replikama baze podataka u Kubernetesu.
Zatim ćemo razgovarati o problemima pohrane podataka:

• kako raditi s Persistent Storageom sa stajališta operatera;
• zamke korištenja lokalne pohrane.

U završnom dijelu izvješća razmotrit ćemo praktične primjere primjene clickhouse-operator s Amazona ili Google Cloud Servicea. Izvješće se temelji na primjeru razvoja i radnog iskustva operatera za ClickHouse.

Video:

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

Zašto imamo priliku govoriti o operateru i ClickHouseu?

• Podržavamo i razvijamo ClickHouse.
• Trenutno pokušavamo polako davati svoj doprinos razvoju ClickHouse-a. Drugi smo nakon Yandexa po količini promjena u ClickHouseu.
• Pokušavamo napraviti dodatne projekte za ClickHouse ekosustav.

Želio bih vam ispričati o jednom od ovih projekata. Ovdje se radi o ClickHouse-operatoru za Kubernetes.

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

• Prva tema je kako naš operater za upravljanje bazom podataka ClickHouse radi u Kubernetesu.
• Druga tema je kako svaki operator radi, tj. kako komunicira s Kubernetesom.

Međutim, ova dva pitanja će se presijecati kroz moje izvješće.

Tko bi bio zainteresiran slušati što pokušavam reći?

• Najviše će zanimati one koji upravljaju operaterima.
• Ili za one koji žele napraviti vlastiti kako bi razumjeli kako funkcionira interno, kako operater komunicira s Kubernetesom i koje se zamke mogu pojaviti.

Da bismo najbolje razumjeli ono o čemu ćemo danas razgovarati, bilo bi dobro znati kako radi Kubernetes i imati osnovnu obuku u oblaku.

Što je ClickHouse? Ovo je stupčasta baza podataka sa specifičnim značajkama za online obradu analitičkih upita. I potpuno je otvorenog koda.

A nama je važno 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 mjeri, daje gotovo linearnu skalabilnost. Stoga je stanje klastera prirodno stanje za ClickHouse. A najviše nas zanima rasprava o tome kako opsluživati ​​ClickHouse klaster u Kubernetesu.

Zašto je on tamo potreban? Zašto ne možemo nastaviti upravljati njime sami? A odgovori su dijelom tehnički, a dijelom organizacijski.

• U praksi se sve češće susrećemo sa situacijom da su u velikim tvrtkama gotovo sve komponente već u Kubernetesu. Baze podataka ostaju vani.
• I sve češće se postavlja pitanje: "Može li se ovo staviti unutra?" Stoga velike tvrtke nastoje postići maksimalnu unificiranost upravljanja kako bi što brže mogle upravljati svojim skladištima podataka.
• A to posebno pomaže ako vam je potrebna maksimalna mogućnost ponavljanja iste stvari na novom mjestu, tj. maksimalna prenosivost.

Koliko je lako ili teško? To se, naravno, može učiniti ručno. Ali to nije tako jednostavno, jer imamo dodatnu složenost upravljanja samim Kubernetesom, ali u isto vrijeme specifičnosti ClickHousea su superponirane. I takvo zbrajanje rezultira.

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

Uz dinamičku konfiguraciju, ClickHouse ima prilično velik broj problema koji stvaraju konstantno opterećenje DevOps-a:

• Kada želimo promijeniti nešto u ClickHouseu, na primjer, dodati repliku ili shard, tada moramo upravljati konfiguracijom.
• Zatim promijenite shemu podataka jer ClickHouse ima specifičnu metodu dijeljenja. Tamo morate postaviti dijagram podataka, postaviti konfiguracije.
• Morate postaviti nadzor.
• Prikupljanje zapisa za nove šardove, za nove replike.
• Pobrinite se za restauraciju.
• I ponovno pokrenuti.

To su rutinski zadaci koje bih stvarno želio učiniti jednostavnijima za korištenje.

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

Kubernetes je dobar u olakšavanju i automatizaciji stvari poput:

• Oporavak.
• Ponovno pokretanje.
• Upravljanje sustavom pohrane podataka.

To je dobro, to je pravi smjer, ali on nema pojma kako upravljati klasterom baze podataka.

Želimo više, želimo da cijela baza podataka radi u Kubernetesu.

Želio bih dobiti nešto poput velikog jednog čarobnog crvenog gumba koji pritisnete i klaster sa svakodnevnim zadacima koje treba riješiti se rasporedi i održava tijekom cijelog životnog ciklusa. ClickHouse klaster u Kubernetesu.

I pokušali smo napraviti rješenje koje će olakšati posao. Ovo je ClickHouse-operator za Kubernetes iz Altinityja.

Operator je program čija je glavna zadaća upravljanje drugim programima, odnosno on je upravitelj.

I sadrži obrasce ponašanja. Ovo možete nazvati kodificiranim znanjem o predmetnom području.

A njegov glavni zadatak je olakšati život DevOps-u i smanjiti mikromenadžment, tako da on (DevOps) već razmišlja na visokoj razini, tj. da se on (DevOps) ne bavi mikromenadžmentom, tako da ne konfigurira sve detalje ručno.

A samo operater je robotski asistent koji se bavi mikrozadacima i pomaže DevOps-u.

Zašto vam je potreban operater? Posebno je dobar u dva područja:

• Kada stručnjak koji se bavi ClickHouseom nema dovoljno iskustva, a već mora upravljati ClickHouseom, operater olakšava rad i omogućuje vam upravljanje ClickHouse klasterom prilično složene konfiguracije, ne ulazeći previše u detalje o tome kako sve to funkcionira iznutra. Samo mu daš zadatke na visokoj razini i to funkcionira.
• A drugi zadatak u kojem se najbolje ponaša je kada je potrebno automatizirati veliki broj tipičnih zadataka. Uklanja mikrozadatke od administratora sustava.

To je najpotrebnije ili onima koji su tek krenuli, ili onima koji trebaju puno automatizacije.

Kako se pristup temeljen na operateru razlikuje od drugih sustava? Postoji Helm. Također pomaže instalirati ClickHouse; možete nacrtati karte kormila, što će čak instalirati cijeli ClickHouse klaster. Koja je onda razlika između operatora i istog, npr. Helma?

Glavna temeljna razlika je u tome što je Helm upravljanje paketima, a Operator ide korak dalje. Ovo je podrška za cijeli životni ciklus. Ovo nije samo instalacija, ovo su svakodnevni poslovi koji uključuju skaliranje, šarding, dakle sve što treba napraviti tijekom životnog ciklusa (ako treba i brisanje) - o svemu odlučuje operater. Pokušava automatizirati i održavati cijeli životni ciklus softvera. To je njegova temeljna razlika od ostalih rješenja koja su predstavljena.

To je bio uvodni dio, idemo dalje.

Kako gradimo našeg operatera? Pokušavamo pristupiti problemu upravljanja ClickHouse klasterom kao jedinstvenim resursom.

Ovdje imamo ulazne podatke na lijevoj strani slike. Ovo je YAML sa specifikacijom klastera, koji se prosljeđuje Kubernetesu na klasičan način preko kubectl-a. Tamo ga naš operater preuzima i radi svoju magiju. A na izlazu dobivamo sljedeću shemu. Ovo je implementacija ClickHousea u Kubernetesu.

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

Krenimo od prakse. Naš je projekt potpuno otvorenog koda, pa možete vidjeti kako funkcionira na GitHubu. I možete krenuti od razmatranja da ako ga samo želite pokrenuti, onda možete početi s Quick Start Guide.

Ako želite detaljno razumjeti, onda pokušavamo održavati dokumentaciju u više ili manje pristojnom obliku.

Počnimo s praktičnim problemom. Prvi zadatak, od kojeg svi želimo započeti, jest nekako pokrenuti prvi primjer. Kako mogu pokrenuti ClickHouse pomoću operatora, čak i ako zapravo ne znam kako radi? Pišemo manifest, jer... Sva komunikacija s k8s je komunikacija putem manifesta.

Ovo je tako složen manifest. Ono na što smo istaknuli crveno je ono na što se trebamo fokusirati. Tražimo od operatera da stvori klaster pod nazivom demo.

Ovo su za sada osnovni primjeri. Skladištenje još nije opisano, ali ćemo se na skladištenje vratiti malo kasnije. Za sada ćemo promatrati dinamiku razvoja klastera.

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

Gledamo konzolu. Zanimljive su tri komponente: Pod, dvije usluge i StatefulSet.

Operater je radio i možemo vidjeti što je točno napravio.

On stvara ovako nešto. Imamo StatefulSet, Pod, ConfigMap za svaku repliku, ConfigMap za cijeli klaster. Usluge su potrebne kao ulazne točke u klaster.

Usluge su središnja usluga balansiranja opterećenja i također se mogu koristiti za svaku repliku, za svaki shard.

Naš osnovni klaster izgleda otprilike ovako. To je iz jednog jedinog čvora.

Idemo dalje i zakomplicirajmo stvari. Moramo razdvojiti klaster.

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

Ovo je ista datoteka koja se dinamički razvija s rastom sustava. Pohrana ne, o pohrani će se dalje raspravljati, ovo je zasebna tema.

Napajamo YAML operatera i vidimo što će se dogoditi.

Operater je razmislio i napravio sljedeće entitete. Već imamo dva Poda, tri usluge 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, duplicirano je.

I zašto su nastala dva StatefulSeta? Ovdje moramo skrenuti s teme i raspraviti pitanje kako se upravlja Podovima u Kubernetesu.

Postoji objekt pod nazivom StatefulSet koji vam omogućuje stvaranje skupa Pods iz predloška. Ključni faktor ovdje je predložak. I možete pokrenuti mnoge Podove koristeći jedan predložak u jednom StatefulSet-u. A ključna fraza ovdje je "mnogo podova za jedan predložak."

I bilo je veliko iskušenje da se napravi cijeli klaster, pakirajući ga u jedan StatefulSet. Radit će, nema problema s tim. Ali postoji jedno upozorenje. Ako želimo sastaviti heterogeni klaster, odnosno od nekoliko verzija ClickHousea, onda se počinju postavljati pitanja. Da, StatefulSet može izvršiti tekuće ažuriranje i tamo možete pokrenuti novu verziju, objasniti da ne trebate isprobavati 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 tekućeg ažuriranja, već jednostavno želimo stvoriti heterogeni klaster u oba različitih verzija ClickHousea i u smislu različite pohrane. Želimo, na primjer, napraviti neke replike na zasebnim diskovima, na sporim, općenito, potpuno izgraditi heterogeni klaster. A zbog činjenice da StatefulSet izrađuje standardizirano rješenje iz jednog predloška, ​​ne postoji način da se to učini.

Nakon malo razmišljanja, odlučeno je da ćemo to učiniti na ovaj način. Imamo svaku repliku u vlastitom StatefulSet-u. Postoje neki nedostaci ovog rješenja, ali u praksi je sve u potpunosti zatvoreno od strane operatera. I ima puno prednosti. Možemo izgraditi točno onaj klaster koji želimo, na primjer, apsolutno heterogen. Dakle, u klasteru u kojem imamo dva sharda s jednom replikom, imat ćemo 2 StatefulSeta i 2 Poda upravo zato što smo odabrali ovaj pristup iz gore navedenih razloga kako bismo mogli izgraditi heterogeni klaster.

Vratimo se praktičnim problemima. U našem klasteru moramo konfigurirati korisnike, tj. trebate napraviti neku konfiguraciju ClickHousea u Kubernetesu. Operater pruža sve mogućnosti za to.

Možemo pisati što želimo izravno u YAML-u. Sve opcije konfiguracije mapiraju se izravno iz ovog YAML-a u konfiguracije ClickHousea, koje se zatim distribuiraju po cijelom klasteru.

Možete to napisati ovako. Ovo je na primjer. Lozinka se može šifrirati. Podržane su apsolutno sve opcije konfiguracije ClickHousea. Evo samo primjera.

Konfiguracija klastera distribuira se kao ConfigMap. U praksi, ažuriranje ConfigMap-a ne događa se trenutno, pa ako je klaster velik, proces guranja konfiguracije traje neko vrijeme. Ali sve je to vrlo zgodno za korištenje.

Zakomplicirajmo zadatak. Klaster se razvija. Želimo replicirati podatke. Odnosno, već imamo dva sharda, po jednu repliku, a korisnici su konfigurirani. Rastemo i želimo raditi replikaciju.

Što nam je potrebno za replikaciju?

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

ZooKeeper može koristiti svatko. Ako poduzeće ima vanjski ZooKeeper, tada se on može koristiti. Ako ne, možete ga instalirati iz našeg repozitorija. Postoji instalacijski program koji cijelu stvar olakšava.

I dijagram interakcije cijelog sustava ispada ovako. Imamo Kubernetes kao platformu. Izvršava ClickHouse operator. Zamislio sam ZooKeeper ovdje. A operater komunicira i s ClickHouseom i ZooKeeperom. Odnosno, dolazi do interakcije.

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

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

Našem manifestu dodajemo dva odjeljka. Prvo je gdje nabaviti ZooKeeper, koji može biti unutar Kubernetesa ili vanjski. Ovo je samo opis. I naručujemo replike. Oni. želimo dvije replike. Ukupno bismo trebali imati 4 mahune na izlazu. Sjećamo se pohrane, vratit će se malo kasnije. Skladištenje je posebna priča.

Bilo je ovako.

Postaje ovako. Dodaju se replike. Četvrti se nije uklopio, vjerujemo da bi ih tamo moglo biti puno. A ZooKeeper je dodan sa strane. Sheme postaju sve složenije.

I vrijeme je da dodate sljedeći zadatak. Dodat ćemo Trajnu pohranu.

Za trajnu pohranu imamo različite mogućnosti.

Ako radimo u pružatelju usluga oblaka, na primjer, koristeći Amazon, Google, tada postoji veliko iskušenje koristiti pohranu u oblaku. Vrlo je zgodno, dobro je.

A postoji i druga opcija. Ovo je za lokalnu pohranu, kada imamo lokalne diskove na svakom čvoru. Ovu je opciju mnogo teže implementirati, ali je istodobno produktivnija.

Pogledajmo što imamo u vezi s pohranom u oblaku.

Ima prednosti. Vrlo ga je lako konfigurirati. Jednostavno naručimo od cloud providera da nam da pohranu tog i tog kapaciteta, te i te klase. Nastavu samostalno raspoređuju izvođači.

I postoji nedostatak. Za neke je to nekritičan nedostatak. Naravno, bit će problema s performansama. Vrlo je praktičan za korištenje i pouzdan, ali postoje neki potencijalni nedostaci izvedbe.

I zato što ClickHouse se fokusira upravo na produktivnost, čak bi se moglo reći da istiskuje sve što može, zbog čega mnogi klijenti pokušavaju iscijediti maksimalnu produktivnost.

A kako bismo iz toga izvukli najviše, potrebna nam je lokalna pohrana.

Kubernetes pruža tri apstrakcije za korištenje lokalne pohrane u Kubernetesu. Ovaj:

• PrazanDir
• HostPath.
• lokalne

Pogledajmo po čemu se razlikuju, a po čemu su slični.

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

Počnimo s najjednostavnijim, tj. emptyDir. Što je to u praksi? U našoj specifikaciji tražimo od sustava kontejnerizacije (najčešće Docker) da nam omogući pristup mapi na lokalnom disku.

U praksi, Docker stvara privremenu mapu negdje na svojim stazama i naziva je dugim raspršivanjem. I pruža sučelje za pristup.

Kako će to funkcionirati u smislu izvedbe? Ovo će raditi pri brzini lokalnog diska, tj. Ovo je potpuni pristup vašem vijku.

Ali ovaj slučaj ima svoju manu. Persistent je prilično dvojben po ovom pitanju. Prvi put kada se Docker pomiče s kontejnerima, Persistent se gubi. Ako Kubernetes iz nekog razloga želi premjestiti ovaj Pod na drugi disk, podaci će biti izgubljeni.

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

Stoga postoji drugi pristup. Ovo je hostPath. Ako pogledate prethodni slajd i ovaj, možete vidjeti samo jednu razliku. Naša se mapa preselila iz Dockera izravno u Kubernetes čvor. Ovdje je malo jednostavnije. Izravno određujemo put na lokalnom datotečnom sustavu gdje želimo pohraniti svoje podatke.

Ova metoda ima prednosti. Ovo je već pravi Persistent, i to klasičan. Imat ćemo podatke snimljene na disku na nekoj adresi.

Postoje i nedostaci. To je složenost upravljanja. Naš Kubernetes možda želi premjestiti Pod na drugi fizički čvor. I tu DevOps stupa na scenu. Mora ispravno objasniti cijelom sustavu da se ove mahune mogu premjestiti samo na one čvorove na kojima imate nešto montirano duž tih staza, i ne više od jednog čvora odjednom. Prilično je teško.

Posebno za ove potrebe, napravili smo predloške u našem operateru kako bismo sakrili svu ovu složenost. Mogli biste jednostavno reći: "Želim imati jednu instancu ClickHouse-a za svaki fizički čvor i duž tog i tog puta."

No nismo mi jedini kojima treba ta potreba, pa i gospoda iz samog Kubernetesa shvaćaju da ljudi žele imati pristup fizičkim diskovima, pa daju i treći sloj.

Zove se lokalni. Praktički nema razlike u odnosu na prethodni slajd. Samo prije je bilo potrebno ručno potvrditi da ne možemo prenositi ove podove s čvora na čvor, jer moraju biti pripojeni duž neke staze na lokalni fizički disk, ali sada je sve to znanje kapsulirano u samom Kubernetesu. I ispada da ga je puno lakše konfigurirati.

Vratimo se našem praktičnom problemu. Vratimo se YAML predlošku. Ovdje imamo pravo skladište. Vraćamo se na to. Postavili smo klasični VolumeClaim predložak kao u k8s. I opisujemo kakvu vrstu pohrane želimo.

Nakon toga k8s će zatražiti pohranu. Dodijelit će nam ga u StatefulSet. I na kraju će biti na raspolaganju ClickHouseu.

Imali smo ovu shemu. Naša trajna pohrana bila je crvena, što je nagovještavalo da to treba učiniti.

I pozeleni. Sada je shema klastera ClickHouse na k8s potpuno finalizirana. Imamo shardove, replike, ZooKeeper, imamo pravi Persistent, koji je implementiran na ovaj ili onaj način. Shema je već u potpunosti operativna.

Nastavljamo živjeti dalje. Naš klaster se razvija. I Alexey pokušava i izdaje novu verziju ClickHousea.

Postavlja se praktični zadatak - testirati novu verziju ClickHousea na našem klasteru. I, naravno, ne želite sve izbaciti; želite staviti novu verziju u jednu repliku negdje u udaljeni kut, i to možda ne jednu novu verziju, nego dvije odjednom, jer one često izlaze.

Što možemo reći o ovome?

Ovdje imamo upravo takvu priliku. Ovo su predlošci mahuna. Možete napisati da vam naš operater u potpunosti omogućuje izgradnju heterogenog klastera. Oni. konfigurirati, počevši od svih replika u hrpi, završavajući sa svakom osobnom replikom, koju verziju želimo ClickHouse, koju verziju želimo za pohranu. Možemo u potpunosti konfigurirati klaster s konfiguracijom koja nam je potrebna.

Idemo malo dublje unutra. Prije ovoga smo govorili o tome kako ClickHouse-operator funkcionira u odnosu na specifičnosti ClickHouse-a.

Sada bih želio reći nekoliko riječi o tome kako bilo koji operater općenito radi, kao i kako komunicira s K8.

Pogledajmo prvo interakciju s K8s. Što se događa kada primijenimo kubectl? Naši se objekti pojavljuju u itd. putem API-ja.

Na primjer, osnovni Kubernetes objekti: pod, StatefulSet, service i tako dalje niz popis.

Istodobno, još se ništa fizičko ne događa. Ovi objekti moraju biti materijalizirani u klasteru.

U tu svrhu pojavljuje se kontroler. Kontroler je posebna k8s komponenta koja može materijalizirati ove opise. Fizički zna kako i što učiniti. Zna pokrenuti kontejnere, što tu treba konfigurirati da server radi.

I materijalizira naše objekte u K8s.

Ali mi ne želimo raditi samo s podovima i StatefulSetovima, želimo kreirati ClickHouseInstallation, tj. objekt tipa ClickHouse, kako bismo s njim radili kao s jednom cjelinom. Zasad ne postoji takva mogućnost.

Ali K8s ima sljedeću lijepu stvar. Želimo da imamo negdje poput ove složene cjeline u kojoj bi naš klaster bio sastavljen od mahuna i StatefulSeta.

I što za to treba učiniti? Prvo, Custom Resource Definition dolazi na scenu. Što je? Ovo je opis za K8s, da ćete imati još jednu vrstu podataka, da želimo dodati prilagođeni resurs u pod, StatefulSet, koji će iznutra biti složen. Ovo je opis strukture podataka.

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

A sada u našoj pohrani, objekt u etcd ima priliku zabilježiti prilagođeni resurs pod nazivom ClickHouseInstallation.

Ali za sada se ništa dalje neće dogoditi. To jest, ako sada stvorimo YAML datoteku koju smo pogledali koja opisuje šardove i replike i kažemo "kubectl apply", tada će Kubernetes to prihvatiti, staviti u etcd i reći: "Super, ali ne znam što učiniti s tim. Ne znam kako održavati ClickHouseInstallation.”

U skladu s tim, trebamo nekoga tko će pomoći Kubernetesu da posluži novu vrstu podataka. S lijeve strane imamo izvorni Kubernetes kontroler koji radi s izvornim tipovima podataka. A s desne strane bismo trebali imati prilagođeni kontroler koji može raditi s prilagođenim tipovima podataka.

I na drugi način se naziva operator. Posebno sam ga uključio ovdje kao Kubernetes, jer se također može izvršiti izvan K8. Najčešće se, naravno, svi operatori izvršavaju u Kubernetesu, ali ništa ga ne sprječava da stoji vani, pa je ovdje posebno premješten vani.

Zauzvrat, prilagođeni kontroler, poznat i kao operator, komunicira s Kubernetesom putem API-ja. Već zna kako komunicirati s API-jem. I on već zna kako materijalizirati složeni sklop koji želimo napraviti od prilagođenog resursa. To je upravo ono što operater radi.

Kako radi operater? Pogledajmo desnu stranu da vidimo kako on to radi. Otkrijmo kako operater sve to materijalizira i kako dolazi do daljnje interakcije s K8.

Operator je program. Ona je orijentirana na događaje. Operater se pretplaćuje na događaje pomoću Kubernetes API-ja. Kubernetes API ima ulazne točke na kojima se možete pretplatiti na događaje. A ako se nešto promijeni u K8s, tada Kubernetes šalje događaje svima, tj. tko god se pretplatio na ovu API točku, dobit će obavijesti.

Operater se pretplaćuje na događaje i mora reagirati na neki način. Njegova je zadaća odgovoriti na novonastale događaje.

Događaji se generiraju određenim ažuriranjima. Stiže naša YAML datoteka s opisom ClickHouseInstallation. Otišao je na etcd kroz kubectl apply. Tamo je pokrenut događaj, a kao rezultat toga ovaj je događaj došao do ClickHouse-operatora. Operater je primio ovaj opis. I mora nešto učiniti. Ako je stiglo ažuriranje za objekt ClickHouseInstallation, tada morate ažurirati klaster. A zadatak operatera je ažuriranje klastera.

Što on radi? Prvo, moramo sastaviti akcijski plan za ono što ćemo učiniti s ovim ažuriranjem. Ažuriranja mogu biti vrlo mala, tj. mali u YAML izvršavanju, ali može dovesti do vrlo velikih promjena na klasteru. Stoga operater napravi plan i onda ga se pridržava.

Prema tom planu, on počinje kuhati ovu strukturu unutra kako bi materijalizirao mahune, usluge, t.j. učiniti ono što mu je glavni zadatak. Ovako možete izgraditi ClickHouse klaster u Kubernetesu.

Sada se dotaknimo tako zanimljive stvari. Ovo je podjela odgovornosti između Kubernetesa i operatera, tj. što radi Kubernetes, što radi operater i kako oni međusobno komuniciraju.

Kubernetes je odgovoran za sistemske stvari, tj. za osnovni skup objekata koji se mogu interpretirati kao opseg sustava. Kubernetes zna kako pokrenuti podove, kako ponovno pokrenuti spremnike, kako montirati volumene, kako raditi s ConfigMapom, tj. sve što se može nazvati sustavom.

Operatori djeluju u domenama. Svaki operator je napravljen za svoje područje. Napravili smo to za ClickHouse.

A operater je u interakciji upravo u smislu predmetnog područja, kao što je dodavanje replike, izrada dijagrama, postavljanje nadzora. To rezultira podjelom.

Pogledajmo praktičan primjer kako se ova podjela odgovornosti događa kada radimo akciju dodavanja replike.

Operater dobiva zadatak - dodati repliku. Što operater radi? Operater će izračunati da je potrebno kreirati novi StatefulSet u kojem se moraju opisati ti i takvi predlošci, zahtjev za volumen.

Sve je to pripremio i proslijeđuje K8s. Kaže da mu treba ConfigMap, StatefulSet, Volume. Kubernetes radi. On materijalizira osnovne jedinice s kojima operira.

A onda ClickHouse-operator opet stupa na scenu. On već ima fizičku podlogu na kojoj već može nešto učiniti. I ClickHouse-operator opet radi u terminima domene. Oni. Konkretno ClickHouse, kako biste uključili repliku u klaster, prvo morate konfigurirati podatkovnu shemu koja postoji u ovom klasteru. I, drugo, ta replika mora biti uključena u monitoring kako bi joj se moglo jasno ući u trag. Operater je to već konfigurirao.

I tek nakon toga na scenu stupa sam ClickHouse, tj. drugi entitet više razine. Ovo je već baza podataka. Ima vlastitu instancu, još jednu konfiguriranu repliku koja je spremna pridružiti se klasteru.

Ispostavilo se da je lanac izvršenja i podjele odgovornosti pri dodavanju replike prilično dug.

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

Napravili smo to tako da možete zalijepiti izravno u postojeći xml, što 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 način na koji ispravno izvodite zonsku implementaciju.

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

Ako se naš klaster promijeni, tada moramo povremeno konfigurirati nadzor.

Pogledajmo dijagram. Ovdje smo već pogledali zelene strelice. Sada pogledajmo crvene strelice. Ovako želimo pratiti naš klaster. Kako metrika iz ClickHouse klastera dolazi u Prometheus, a zatim u Grafanu.

U čemu je poteškoća s praćenjem? Zašto se to predstavlja kao nekakvo postignuće? Poteškoća leži u dinamici. Kad imamo jedan klaster i on je statičan, možemo jednom postaviti monitoring i više se ne mučiti.

Ali ako imamo puno klastera, ili se stalno nešto mijenja, onda je proces dinamičan. A stalno rekonfiguriranje nadzora je gubitak resursa i vremena, tj. čak i samo lijenost. Ovo treba automatizirati. Poteškoća leži u dinamici procesa. A operater to vrlo dobro automatizira.

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

Tada je bio ovakav.

Na kraju je postao ovakav.

A nadzor obavlja operater automatski. Jedinstvena ulazna točka.

I tek na izlazu gledamo na upravljačku ploču Grafana da vidimo kako iznutra ključa život našeg klastera.

Inače, Grafana dashboard također se distribuira kod našeg operatera izravno u izvornom kodu. Možete se povezati i koristiti. Naš DevOps mi je dao ovu snimku zaslona.

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

• Razviti automatizaciju testiranja. Glavni zadatak je automatizirano testiranje novih verzija.
• Također stvarno želimo automatizirati integraciju sa ZooKeeperom. A postoje i planovi za integraciju s ZooKeeper-operatorom. Oni. Operator je napisan za ZooKeeper i logično je da se dva operatera počnu integrirati kako bi izgradili praktičnije rješenje.
• Želimo raditi složenije vitalne znakove.
• Označio sam zelenom bojom da se približavamo nasljeđivanju predložaka - GOTOVO, tj. sa sljedećim izdanjem operatora već ćemo imati nasljeđivanje predložaka. Ovo je moćan alat koji vam omogućuje izgradnju složenih konfiguracija iz dijelova.
• I mi želimo automatizaciju složenih zadataka. Glavni je Re-sharding.

Uzmimo neke međurezultate.

Što dobivamo kao rezultat? I vrijedi li to učiniti ili ne? Je li uopće potrebno pokušati dovući bazu podataka u Kubernetes i koristiti operator općenito, a posebno operator Alitnity?

Na izlazu dobivamo:

• Značajno pojednostavljenje i automatizacija konfiguracije, implementacije i održavanja.
• Odmah ugrađeni nadzor.
• I kodificirani predlošci spremni za korištenje za složene situacije. Radnja poput dodavanja replike ne mora se izvoditi ručno. Operater to radi.

Ostalo je još samo jedno zadnje pitanje. Već imamo bazu podataka u Kubernetesu, virtualizaciju. Što je s performansama takvog rješenja, pogotovo jer je ClickHouse optimiziran za performanse?

Odgovor je sve je u redu! Neću ulaziti u detalje, to je tema za poseban izvještaj.

Ali postoji takav projekt kao što je TSBS. Koja je njegova glavna zadaća? Ovo je test performansi baze podataka. Ovo je pokušaj usporedbe toplog s toplim, mekog s mekim.

Kako on radi? Generira se jedan skup podataka. Zatim se ovaj skup podataka pokreće u različitim bazama podataka koristeći isti skup testova. I svaka baza rješava jedan problem onako kako zna. A onda možete usporediti rezultate.

Već podržava veliki broj baza podataka. Identificirao sam tri glavna. Ovaj:

• TimescaleDB.
• InfluxDB.
• ClickHouse.

Napravljena je i usporedba s drugim sličnim rješenjem. Usporedba s RedShiftom. Usporedba je napravljena na Amazonu. ClickHouse je i po ovom pitanju daleko ispred svih.

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

• DB u Kubernetesu je moguć. Vjerojatno je sve moguće, ali općenito izgleda kao da je moguće. ClickHouse u Kubernetesu je definitivno moguć uz pomoć našeg operatera.
• Operater pomaže u automatizaciji procesa i stvarno olakšava život.
• Performanse su normalne.
• I čini nam se da se to može i treba iskoristiti.

Otvoreni kod - pridružite nam se!

Kao što sam već rekao, operator je potpuno open source proizvod, pa bi bilo jako dobro da ga koristi što veći broj ljudi. Pridruži nam se! Čekamo vas sve!

Hvala svima!

pitanja

Hvala na izvješću! Moje ime je Anton. Ja sam iz SEMrusha. Pitam se što je sa sječom. Slušamo o monitoringu, ali ništa o sječi, ako govorimo o cijelom klasteru. Na primjer, podigli smo klaster na hardveru. I koristimo centralizirano bilježenje, skupljajući ih u zajedničku hrpu pomoću standardnih sredstava. I onda odatle dobivamo podatke koji nas zanimaju.

Dobro pitanje, tj. prijava na popis obveza. Naš operater to još ne automatizira. Još je u razvoju, projekt je još prilično mlad. Razumijemo potrebu za sječom. Ovo je također vrlo važna tema. I vjerojatno nije ništa manje važno od praćenja. Ali prvi na popisu za provedbu bio je monitoring. Bit će sječe. Naravno, nastojimo automatizirati sve aspekte života klastera. Dakle, odgovor je da operater u ovom trenutku, nažalost, ne zna kako to napraviti, ali to je u planu, mi ćemo to napraviti. Ako se želite pridružiti, povucite zahtjev.

Zdravo! Hvala na izvješću! Imam standardno pitanje u vezi s trajnim volumenima. Kada kreiramo konfiguraciju s ovim operatorom, kako operator određuje na kojem čvoru imamo priložen određeni disk ili mapu? Prvo mu moramo objasniti da molimo da naš ClickHouse postavimo na ove čvorove koji imaju disk?

Koliko ja razumijem, ovo je pitanje nastavak lokalne pohrane, posebno njezinog hostPath dijela. Ovo je kao da cijelom sustavu objašnjavamo da pod treba pokrenuti na tom i tom čvoru, na koji imamo fizički spojen disk, koji je montiran na tom i tom putu. Ovo je cijeli dio kojeg sam se dotaknuo vrlo površno jer je odgovor tamo prilično velik.

Ukratko to izgleda ovako. Naravno, moramo osigurati ove količine. Trenutačno nema dinamičke odredbe u lokalnoj pohrani, tako da DevOps mora sam rezati diskove, te volumene. I moraju objasniti pružanje Kubernetesa da ćete imati postojane volumene te i te klase, koji se nalaze na tim i tim čvorovima. Tada ćete morati objasniti Kubernetesu da se podovi koji zahtijevaju takvu i takvu klasu lokalne pohrane moraju usmjeriti samo na te i te čvorove pomoću oznaka. U te svrhe, operater ima mogućnost dodijeliti neku vrstu oznake i jednu po instanci glavnog računala. I pokazalo se da će Kubernetes preusmjeravati podove da rade samo na čvorovima koji zadovoljavaju zahtjeve, oznake, jednostavnim rječnikom. Administratori ručno dodjeljuju oznake i dodjelu diskova. I onda se skalira.

A treća opcija, lokalna, pomaže da ovo bude malo lakše. Kao što sam već naglasio, ovo je mukotrpan rad na ugađanju, koji u konačnici pomaže u postizanju maksimalnih performansi.

Imam drugo pitanje vezano za ovo. Kubernetes je dizajniran na način da nam je svejedno hoćemo li izgubiti čvor ili ne. Što trebamo učiniti u ovom slučaju ako smo izgubili čvor na kojem visi naš shard?

Da, Kubernetes je u početku bio pozicioniran da je naš odnos s našim podovima poput stoke, ali ovdje kod nas svaki disk postaje nešto poput kućnog ljubimca. Postoji toliki problem da ih ne možemo jednostavno baciti. A razvoj Kubernetesa ide u smjeru da ga je nemoguće potpuno filozofski tretirati, kao da je potpuno odbačen resurs.

Sada jedno praktično pitanje. Što učiniti ako ste izgubili čvor na kojem je bio disk? Ovdje se problem rješava na višoj razini. U slučaju ClickHouse imamo replike koje rade na višoj razini, tj. na razini ClickHouse.

Kakva je dispozicija iz toga? DevOps je odgovoran za osiguranje da se podaci ne izgube. On mora ispravno postaviti replikaciju i mora osigurati da se replikacija izvodi. Replika na razini ClickHouse mora imati duplicirane podatke. Ovo nije zadatak koji operater rješava. A ne problem koji sam Kubernetes rješava. Ovo je na razini ClickHouse.

Što učiniti ako vam otpadne željezni čvor? I pokazalo se da ćete morati instalirati drugi, pravilno postaviti disk na njega i primijeniti oznake. A nakon toga, ispunit će uvjete da Kubernetes može pokrenuti pod instance na njemu. Kubernetes će ga pokrenuti. Vaš broj mahuna nije dovoljan za postizanje navedenog broja. Proći će kroz ciklus koji sam pokazao. I na najvišoj razini, ClickHouse će shvatiti da smo unijeli repliku, ona je još uvijek prazna i trebamo početi s prijenosom podataka u nju. Oni. Ovaj proces još nije dobro automatiziran.

Hvala na izvješću! Kad se dogode svakakve gadne stvari, operater se sruši i restartuje, i u tom trenutku stignu događaji, rješavate li to nekako?

Što se događa ako se operater sruši i ponovno pokrene, zar ne?

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

Zadatak što učiniti u ovom slučaju djelomično je podijeljen između operatera i Kubernetesa. Kubernetes ima mogućnost ponovnog prikaza događaja koji se dogodio. On ponavlja. A zadatak operatera je osigurati da su ti događaji idempotentni kada se zapisnik događaja ponovno pusti na njemu. I da opetovana pojava istog događaja ne slomi naš sustav. I naš se operater nosi s tim zadatkom.

Zdravo! Hvala na izvješću! Dmitry Zavyalov, tvrtka Smedova. Postoje li planovi da se operateru doda mogućnost konfiguracije s haproxyjem? Zanimao bi me neki drugi balanser osim standardnog, da bude pametan i da shvati da je ClickHouse stvarno tu.

Govorite li o Ingressu?

Da, zamijeni Ingress haproxyjem. U haproxyju možete odrediti topologiju klastera gdje ima replike.

Još nismo o tome razmišljali. Ako vam je to potrebno i možete objasniti zašto je to potrebno, onda će to biti moguće provesti, pogotovo ako želite sudjelovati. Rado ćemo razmotriti opciju. Kratak odgovor je ne, trenutno nemamo takvu funkcionalnost. Hvala na savjetu, istražit ćemo ovo. A ako također objasnite slučaj upotrebe i zašto je to potrebno u praksi, na primjer, stvorite probleme na GitHubu, onda će to biti sjajno.

Već je.

Fino. Otvoreni smo za sve prijedloge. I haproxy je dodan na popis obaveza. Popis obveza raste, ali se još ne smanjuje. Ali ovo je dobro, znači da je proizvod tražen.

Izvor: www.habr.com