Local<\/li>\n<\/ul>\n<\/p>\n
Razmotrit \u0107emo kako se razlikuju i po \u010demu su sli\u010dni. <\/p>\n
<\/p>\n
Prvo, u sva tri pristupa, pohrana su lokalni diskovi koji se nalaze na istoj fizi\u010dkoj k8s nodi. No, postoji nekoliko razlika.<\/p>\n
<\/p>\n
<\/p>\n
Zapo\u010det \u0107emo s najjednostavnijim, tj. s emptyDir. \u0160to to prakti\u010dki zna\u010di? To je da tra\u017eimo od na\u0161e specifikacije da nam sustav kontejnerizacije (naj\u010de\u0161\u0107e je to Docker) omogu\u0107i pristup mapi na lokalnom disku.<\/p>\n
<\/p>\n
U praksi, Docker negdje u svojim vlastitim putanjama stvara privremenu mapu, naziva je dugim he\u0161em. I omogu\u0107uje pristup toj mapi. <\/p>\n
<\/p>\n
Kako \u0107e to funkcionirati po pitanju performansi? Funkcionirat \u0107e brzinom lokalnog diska, tj. to je potpuno pristup vlastitom disku. <\/p>\n
<\/p>\n
No, ova pojava ima svoj nedostatak. Persistent pohrana u ovome je prili\u010dno sumnjiva. Pri prvom pomaku Dockera s kontejnerima, Persistent se gubi. Ako Kubernetes iz nekog razloga \u017eeli premjestiti ovu Pod na drugi disk, podaci \u0107e se izgubiti. <\/p>\n
<\/p>\n
Ovaj pristup je dobar za testiranje, jer pokazuje normalnu brzinu, ali za ne\u0161to ozbiljnije ovaj izbor nije prikladan. <\/p>\n
<\/p>\n
<\/p>\n
Stoga postoji drugi pristup. To je hostPath. Ako pogledate prethodni slajd i ovaj, mo\u017eete vidjeti samo jednu razliku. Na\u0161a mapa je iza\u0161la iz Dockera direktno na Kubernetes nodu. Tu je malo jednostavnije. Direktno navodimo put po lokalnom datote\u010dnom sustavu gdje bismo \u017eeljeli pohraniti svoje podatke. <\/p>\n
<\/p>\n
Ovaj na\u010din ima svoje prednosti. To je ve\u0107 prava Persistent pohrana, i to klasi\u010dna. Na disku \u0107e biti zapisana podaci na nekoj adresi. <\/p>\n
<\/p>\n
Postoje i nedostaci. To je slo\u017eenost upravljanja. Na\u0161 Kubernetes mo\u017ee po\u017eeljeti premjestiti Pod na drugi fizi\u010dki \u010dvor. I tada dolazi do izra\u017eaja DevOps. On mora pravilno objasniti cijelom sustavu da se ti podovi mogu premje\u0161tati samo na one \u010dvorove na kojima imate ne\u0161to montirano putem tih putanja i ne vi\u0161e od jednog \u010dvora odjednom. To je prili\u010dno slo\u017eeno. <\/p>\n
<\/p>\n
Specijalno za te svrhe, mi smo u na\u0161em operateru napravili predlo\u0161ke kako bismo svu tu slo\u017eenost sakrili. I moglo bi se jednostavno re\u0107i: \u201e\u017delim da imam jedan instance ClickHouse-a na svakoj fizi\u010dkoj \u010dvoru i po takvom putu\u201c. <\/p>\n
<\/p>\n
<\/p>\n
Ali ta potreba nije potrebna samo nama, stoga gospoda iz samog Kubernetesa tako\u0111er razumiju da ljudima treba pristup fizi\u010dkim diskovima, pa oni pru\u017eaju tre\u0107u razinu.<\/p>\n
<\/p>\n
Ona se zove local. Razlike od prethodnog slajda prakti\u010dki nema. Samo \u0161to je ranije trebalo ru\u010dno provoditi pravila da se ti podovi ne smiju premje\u0161tati s \u010dvora na \u010dvor, jer moraju biti vezani na takav put za lokalni fizi\u010dki disk, a sad se sve te informacije inkapsuliraju u Kubernetesa. I postaje mnogo jednostavnije konfigurirati.<\/p>\n
<\/p>\n
<\/p>\n
Vratimo se na\u0161oj prakti\u010dnoj zadatku. Vratimo se YAML predlo\u0161ku. Tu imamo pravi storage. Vratili smo se tome. Postavljamo klasi\u010dni VolumeClaim predlo\u017eak kao u k8s. I opisujemo koji storage \u017eelimo.<\/p>\n
<\/p>\n
Nakon toga k8s \u0107e zatra\u017eiti storage. Dodelit \u0107e nam ga u StatefulSet-u. I na kraju \u0107e to biti na raspolaganju ClickHouse-u.<\/p>\n
<\/p>\n
<\/p>\n
Imali smo ovakvu shemu. Na\u0161 Persistent Storage bio je crven, \u0161to nam je kao nagovijestilo da bismo ga trebali napraviti. <\/p>\n
<\/p>\n
<\/p>\n
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\u010din. Shema je ve\u0107 potpuno funkcionalna. <\/p>\n
<\/p>\n
<\/p>\n
Nastavljamo \u017eivjeti dalje. Na\u0161 klaster se razvija. I Aleksey se trudi i objavljuje novu verziju ClickHouse-a.<\/p>\n
<\/p>\n
Pojavljuje se prakti\u010dni zadatak \u2013 testirati novu verziju ClickHouse-a na na\u0161em klasteru. Pri tome, naravno, ne \u017eelimo je primijeniti na cijeli klaster, \u017eelimo negdje u udaljeni kutak staviti novu verziju, ili mo\u017eda ne samo jednu novu verziju, ve\u0107 odmah dvije, jer one \u010desto izlaze. <\/p>\n
<\/p>\n
\u0160to mo\u017eemo re\u0107i o tome?<\/p>\n
<\/p>\n
<\/p>\n
Ovdje imamo upravo tu priliku. To su predlo\u0161ci podova. Mo\u017eemo ih definirati, na\u0161 operator potpuno omogu\u0107uje izgradnju heterogenog klastera. To jest, mo\u017eemo konfigurirati, po\u010dev\u0161i od svih replikacija kao skupa, do svake pojedina\u010dne replike, koju verziju ClickHouse-a \u017eelimo, koju verziju storage-a \u017eelimo. Potpuno mo\u017eemo konfigurirati klaster prema na\u0161im potrebama. <\/p>\n
<\/p>\n
<\/p>\n
Malo \u0107emo se dublje uputiti. Do sada smo govorili o tome kako ClickHouse-operator funkcionira u vezi sa specifi\u010dnostima ClickHouse-a.<\/p>\n
<\/p>\n
Sada bih \u017eelio re\u0107i nekoliko rije\u010di o tome kako funkcionira bilo koji operator, kao i o tome kako se on povezuje s K8s.<\/p>\n
<\/p>\n
<\/p>\n
Razmotrit \u0107emo interakciju s K8s na po\u010detku. \u0160to se doga\u0111a kada napravimo kubectl apply? Na\u0161i objekti se pojavljuju u etcd putem API-ja. <\/p>\n
<\/p>\n
<\/p>\n
Na primjer, osnovni objekti Kubernetes-a: pod, StatefulSet, servis i tako dalje. <\/p>\n
<\/p>\n
Pri tome, fizi\u010dki se jo\u0161 ni\u0161ta ne doga\u0111a. Ove objekte trebamo materializirati u klasteru. <\/p>\n
<\/p>\n
<\/p>\n
Za to dolazi kontroler. Kontroler je specijalna komponenta k8s koja zna materializirati ove opise. On zna kako i \u0161to treba u\u010diniti fizi\u010dki. Zna kako pokrenuti kontejnere i \u0161to treba konfigurirati da bi server radio. <\/p>\n
<\/p>\n
<\/p>\n
I on materializira na\u0161e objekte u K8s.<\/p>\n
<\/p>\n
Ali \u017eelimo upravljati ne samo pod-ovima i StatefulSet-ima, \u017eelimo stvoriti ClickHouseInstallation, tj. objekt tipa ClickHouse, kako bismo njime upravljali kao jedinstvenom cjelinom. Za sada ta mogu\u0107nost ne postoji. <\/p>\n
<\/p>\n
<\/p>\n
Ali K8s ima jo\u0161 jednu lijepu stvar. \u017delimo da imamo negdje takvu slo\u017eenu jedinstvenu tvorevinu, koja \u0107e biti sastavljena od pod-ova i StatefulSet-a na\u0161eg klastera. <\/p>\n
<\/p>\n
<\/p>\n
\u0160to je potrebno u\u010diniti za to? Prvo, na scenu stupa Custom Resource Definition. \u0160to je to? To je opis za K8s koji definira da \u0107e imati jo\u0161 jedan tip podataka, da \u017eelimo dodati prilago\u0111eni resurs pod, StatefulSet-u, koji \u0107e biti slo\u017een iznutra. To je opis strukture podataka. <\/p>\n
<\/p>\n
<\/p>\n
Tako\u0111er ga \u0161aljemo preko kubectl apply. Kubernetes ga s rado\u0161\u0107u prihva\u0107a. <\/p>\n
<\/p>\n
I sada u na\u0161em skladi\u0161tu, kod objekta u etcd, nabavljamo mogu\u0107nost da zapi\u0161emo prilago\u0111eni resurs pod nazivom ClickHouseInstallation.<\/p>\n
<\/p>\n
Ali za sada se ni\u0161ta dalje ne\u0107e dogoditi. Odnosno, ako sada stvorimo YAML datoteku koju smo razmatrali s opisom shardova, replika i ka\u017eemo 'kubectl apply', Kubernetes \u0107e je prihvatiti, pohraniti u etcd i re\u0107i: 'Odli\u010dno, ali ne znam \u0161to u\u010diniti s tim. Kako odr\u017eavati ClickHouseInstallation, nemam pojma.' <\/p>\n
<\/p>\n
<\/p>\n
Prema tome, potrebna nam je osoba koja \u0107e pomo\u0107i Kubernetesu u odr\u017eavanju novog tipa podataka. S lijeve strane imamo ugra\u0111eni kontroler Kubernetesa koji radi s ugra\u0111enim tipovima podataka. A s desne strane trebao bi se pojaviti prilago\u0111eni kontroler koji mo\u017ee raditi s prilago\u0111enim tipovima podataka. <\/p>\n
<\/p>\n
I druga\u010dije se naziva operator. Ovdje sam ga namjerno istaknuo izvan K8s, jer se mo\u017ee izvoditi i izvan K8s. Naj\u010de\u0161\u0107e, naravno, svi operatori se izvode unutar Kubernetesa, ali ni\u0161ta ne sprje\u010dava da stoji izvana, pa je ovdje posebno istaknut izvana. <\/p>\n
<\/p>\n
<\/p>\n
I ve\u0107 u svoju ruku prilago\u0111eni kontroler, odnosno operator, komunicira s Kubernetesom putem API-ja. On ve\u0107 zna kako komunicirati s API-jem. I on ve\u0107 zna kako iz prilago\u0111enog resursa materijalizirati slo\u017eeni obrazac koji \u017eelimo stvoriti. Time se bavi operator. <\/p>\n
<\/p>\n
<\/p>\n
Kako radi operator? Pogledajmo desnu stranu kako bismo saznali kako to radi. Saznat \u0107emo kako operator sve to materijalizira i kako dalje dolazi do interakcije s K8s.<\/p>\n
<\/p>\n
<\/p>\n
Operator je program. On je orijentiran na doga\u0111aje. Operator se uz pomo\u0107 Kubernetes API-ja pretpla\u0107uje na doga\u0111aje. U Kubernetes API-ju postoje ulazne to\u010dke na koje se mo\u017ee pretplatiti na doga\u0111aje. I ako do\u0111e do promjene u K8s, Kubernetes \u0161alje doga\u0111aje svima koji su zainteresirani, tj. tko se pretplatio na tu to\u010dku API-ja, taj \u0107e primiti obavijesti.<\/p>\n
<\/p>\n
Operator se pretpla\u0107uje na doga\u0111aje i treba u\u010diniti neku reakciju. Njegov zadatak je reagirati na nastale doga\u0111aje. <\/p>\n
<\/p>\n
<\/p>\n
Doga\u0111aji se generiraju odre\u0111enim a\u017euriranjima. Na\u0161a YAML datoteka s opisom ClickHouseInstallation dolazi. Ona je putem kubectl apply oti\u0161la u etcd. Tamo se dogodio event, u kona\u010dnici je taj event do\u0161ao do ClickHouse-operatjera. Operator je primio ovaj opis. I on mora ne\u0161to u\u010diniti. Ako je stiglo a\u017euriranje objekta ClickHouseInstallation, treba a\u017eurirati klaster. I zadatak operatora je a\u017eurirati klaster. <\/p>\n
<\/p>\n
<\/p>\n
\u0160to on radi? Prvo, potrebno je sastaviti plan akcije, \u0161to \u0107emo 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.<\/p>\n
<\/p>\n
<\/p>\n
On po\u010dinje prema tom planu stvarati ovu strukturu unutar, kako bi materializirao podove, servise, tj. obavljao ono \u0161to mu je osnovni zadatak. To je kao izgradnja ClickHouse klastera u Kubernetesu.<\/p>\n
<\/p>\n
<\/p>\n
Sada se dotaknimo jedne zanimljive stvari. To je podjela odgovornosti izme\u0111u Kubernetesa i operatora, tj. \u0161to radi Kubernetes, \u0161to radi operator i kako me\u0111usobno djeluju. <\/p>\n
<\/p>\n
Kubernetes je odgovoran za sistemske stvari, tj. za osnovni skup objekata koji se mo\u017ee interpretirati kao sustavske stvari. Kubernetes zna kako pokrenuti podove, kako ponovno pokrenuti kontejnere, kako montirati volumene, kako raditi s ConfigMap, tj. sve \u0161to se mo\u017ee nazvati sustavom. <\/p>\n
<\/p>\n
Operatori djeluju u smislu predmetnih podru\u010dja. Svaki operator se razvija za svoje predmetno podru\u010dje. Mi smo razvili za ClickHouse.<\/p>\n
<\/p>\n
Operator djeluje upravo u terminima predmetnog podru\u010dja, poput dodavanja replike, izrade sheme, postavljanja monitoringa. To rezultira tom podjelom.<\/p>\n
<\/p>\n
<\/p>\n
Pogledajmo prakti\u010dan primjer kako se ta podjela odgovornosti odvija kada izvr\u0161avamo radnju dodavanja replike. <\/p>\n
<\/p>\n
Operator dobija zadatak \u2013 dodati repliku. \u0160to operator radi? Operator \u0107e izra\u010dunati da je potrebno stvoriti novi StatefulSet, u kojem treba opisati odre\u0111ene predlo\u0161ke, potra\u017eivanje volumena. <\/p>\n
<\/p>\n
<\/p>\n
Sve to priprema i dalje proslje\u0111uje u K8s. Ka\u017ee da mu trebaju ConfigMap, StatefulSet, Volumen. Kubernetes to obra\u0111uje. Materijalizira osnovne jedinice s kojima upravlja. <\/p>\n
<\/p>\n
<\/p>\n
I dalje uvo\u0111enjem ponovo dolazi ClickHouse-operator. Ve\u0107 ima fizi\u010dki pod na kojem mo\u017ee raditi. I ClickHouse-operator ponovo radi u terminima predmetnog podru\u010dja. Tj. konkretno ClickHouse da uklju\u010di repliku u klaster, prvo je potrebno postaviti shemu podataka koja u tom klasteru postoji. A, drugo, tu repliku treba uklju\u010diti u monitoring, kako bi bila dobro pra\u0107ena. To ve\u0107 operator postavlja. <\/p>\n
<\/p>\n
<\/p>\n
I samo nakon toga u posao ulazi sam ClickHouse, tj. jo\u0161 jedan vi\u0161i nivo entiteta. To je ve\u0107 baza podataka. Ima svoj instance, jo\u0161 jednu repliku konfiguriranu, koja je spremna da u\u0111e u klaster.<\/p>\n
<\/p>\n
Dakle, lanac izvr\u0161avanja i razdvajanja odgovornosti prilikom dodavanja replike je dovoljno dug.<\/p>\n
<\/p>\n
<\/p>\n
Nastavljamo na\u0161e prakti\u010dne zadatke. Ako klaster ve\u0107 postoji, mo\u017ee se izvr\u0161iti migracija konfiguracije. <\/p>\n
<\/p>\n
<\/p>\n
U\u010dinili smo tako da se u postoje\u0107i xml, koji ClickHouse razume, mo\u017ee pro\u0107i kroz.<\/p>\n
<\/p>\n
<\/p>\n
Mo\u017ee se izvr\u0161iti fino pode\u0161avanje ClickHousea. Ba\u0161 zoned deployment - to je ono o \u010demu sam pri\u010dao prilikom obja\u0161njavanja hostPath, lokalne pohrane. Ovo je kako pravilno uraditi zoned deployment.<\/p>\n
<\/p>\n
<\/p>\n
Sljede\u0107i prakti\u010dni zadatak \u2013 monitoring.<\/p>\n
<\/p>\n
<\/p>\n
Ako se na\u0161 klaster menja, povremeno je potrebno pode\u0161avati monitoring. <\/p>\n
<\/p>\n
Pogledajmo shemu. Zelene strelice ovde smo ve\u0107 razmotrili. Sada da razmotrimo crvene strelice. To je na\u010din na koji \u017eelimo da pratimo na\u0161 klaster. Kako metrike iz klastera ClickHouse ulaze u Prometheus, a zatim u Grafana.<\/p>\n
<\/p>\n
<\/p>\n
A koja je slo\u017eenost s monitoringom? Za\u0161to se to isti\u010de kao neki postignu\u0107e? Slo\u017eenost le\u017ei u dinamici. Kada imamo jedan klaster i on je stati\u010dan, mo\u017ee se jednom podesiti monitoring i onda vi\u0161e ne brinuti.<\/p>\n
<\/p>\n
Ali ako imamo mnogo klastera ili se stalno ne\u0161to menja, proces je dinami\u010dan. Stalno se baviti ponovnim pode\u0161avanjem monitoringa je tro\u0161enje resursa i vremena, tj. \u010dak i jednostavna lenjost. To treba automatizovati. Slo\u017eenost le\u017ei upravo u dinamici procesa. I operater to veoma dobro automatizuje. <\/p>\n
<\/p>\n
<\/p>\n
Kako se na\u0161 klaster razvijao? Na po\u010detku je bio ovakav.<\/p>\n
<\/p>\n
<\/p>\n
Zatim je bio ovakav.<\/p>\n
<\/p>\n
<\/p>\n
Na kraju je postao ovakav. <\/p>\n
<\/p>\n
A monitoring se automatski obavlja od strane operatera. Jedina ta\u010dka pristupa. <\/p>\n
<\/p>\n
<\/p>\n
I mi samo na izlazu gledamo u Grafana dashboard, kako unutra \u017eivi \u017eivot na\u0161eg klastera. <\/p>\n
<\/p>\n
Usput, Grafana dashboard se tako\u0111e distribuira s na\u0161im operaterom direktno u izvorima. Mo\u017ee se povezati i koristiti. Ovu sliku su mi dali na\u0161i DevOps.<\/p>\n
<\/p>\n
<\/p>\n
Kuda bismo \u017eeleli i\u0107i dalje? To je:<\/p>\n
<\/p>\n
\nRazvijati automatizaciju testiranja. Glavni zadatak je automatizovano testiranje novih verzija. <\/li>\n Tako\u0111er \u017eelimo automatizirati integraciju s ZooKeeper-om. Planiramo se integrirati s ZooKeeper-operatorom. To jest, za ZooKeeper napisan je operator i logi\u010dno je da se dva operatora integriraju za izgradnju prakti\u010dnijeg rje\u0161enja. <\/li>\n \u017delimo napraviti slo\u017eenije provjere odr\u017eivosti. <\/li>\n Zelenom sam ozna\u010dio ono \u0161to nam dolazi \u2013 naslje\u0111ivanje predlo\u017eaka \u2013 GOTOVO, to jest, s sljede\u0107im izdanjem operatora ve\u0107 \u0107emo imati naslje\u0111ivanje predlo\u017eaka. To je mo\u0107an alat koji omogu\u0107uje gradnju slo\u017eenih konfiguracija od dijelova. <\/li>\n \u017delimo automatizaciju slo\u017eenih zadataka. Glavni od njih je Re-sharding. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Hajde da napravimo me\u0111ufinalne rezultate. <\/p>\n
<\/p>\n
<\/p>\n
\u0160to dobijamo na izlazu? I vrijedi li se time baviti ili ne? Treba li uop\u0107e poku\u0161ati uvu\u0107i bazu podataka u Kubernetes i primijeniti operator u cjelini, a posebno Alitnity-operator?<\/p>\n
<\/p>\n
Na izlazu dobijamo:<\/p>\n
<\/p>\n
\nZna\u010dajno pojednostavljenje i automatizaciju konfiguriranja, implementacije, ali i odr\u017eavanja. <\/li>\n Odmah ugra\u0111eno pra\u0107enje. <\/li>\n I gotovi za kori\u0161tenje kodificirani predlo\u0161ci za slo\u017eene situacije. Ve\u0107 akcija poput dodavanja replikacije ne treba raditi ru\u010dno. To radi operator. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Ostalo je samo posljednje pitanje. Ve\u0107 imamo bazu podataka u Kubernetesu, virtualizaciju. \u0160to je s performansama tog rje\u0161enja, posebno s obzirom na to da je ClickHouse optimiziran za performanse?<\/p>\n
<\/p>\n
Odgovor \u2013 sve je u redu! Ne\u0107u detaljno opisivati, to je tema zasebnog izlaganja. <\/p>\n
<\/p>\n
<\/p>\n
Ali postoji projekt pod nazivom TSBS. Koji je njegov glavni zadatak? To je testiranje baza podataka na performanse. To je poku\u0161aj usporedbe toplog s toplim, mekog s mekim. <\/p>\n
<\/p>\n
Kako to radi? Generira se jedan set podataka. Zatim se taj set podataka na istom skupu testova prolazi kroz razli\u010dite baze podataka. I svaka baza podataka rje\u0161ava jedan zadatak onako kako ga zna. A potom se mogu uspore\u0111ivati rezultati. <\/p>\n
<\/p>\n
Ve\u0107 podr\u017eava veliki broj baza podataka. Istaknuo sam tri glavne. To su:<\/p>\n
<\/p>\n
\nTimescaleDB.<\/li>\n InfluxDB.<\/li>\n ClickHouse.<\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Tako\u0111er je provedena usporedba s jo\u0161 jednim sli\u010dnim rje\u0161enjem. Usporedba s RedShift-om. Usporedba je provedena na Amazonu. ClickHouse tako\u0111er dobro nadma\u0161uje sve u ovom pogledu. <\/p>\n
<\/p>\n
<\/p>\n
Koje se zaklju\u010dke mogu izvu\u0107i iz onoga \u0161to sam ispri\u010dao?<\/p>\n
<\/p>\n
\nDB u Kubernetes je mogu\u0107. Vjerojatno je mogu\u0107e sve, ali u cjelini izgleda da je to mogu\u0107e. ClickHouse u Kubernetesu definitivno mo\u017ee putem na\u0161eg operatora. <\/li>\n Operator poma\u017ee automatizirati procese i stvarno olak\u0161ava \u017eivot.<\/li>\n Performanse su zadovoljavaju\u0107e.<\/li>\n I, \u010dini nam se da se to mo\u017ee i treba koristiti. <\/li>\n<\/ul>\n<\/p>\n
Open source \u2013 pridru\u017eite se!<\/p>\n
<\/p>\n
Kao \u0161to sam ve\u0107 spomenuo, operator je potpuno open source proizvod, stoga bi bilo jako dobro da \u0161to vi\u0161e ljudi to koristi. Pridru\u017eite se! \u010cekamo vas sve!<\/p>\n
<\/p>\n
Hvala svima!<\/p>\n
<\/p>\n
Pitanja<\/p>\n
<\/p>\n
<\/p>\n
Hvala na prezentaciji! Ja sam Anton. Dolazim iz tvrtke SEMrush. Zanima me \u0161to s logiranjem. O monitoringu se \u010duje, ali o logiranju ni\u0161ta, ako govorimo o klasteru u cjelini. Kod nas je, na primjer, podignut klaster na hardveru. I koristimo centralizirano logiranje, standardnim metodama prikupljamo u zajedni\u010dku bazu. A zatim odatle izvla\u010dimo zanimljive podatke.<\/em> <\/p>\n<\/p>\n
Dobar \u0432\u043e\u043f\u0440\u043e\u0441, tj. logiranje je na listi zadataka. Na\u0161 operator za sada to ne automatizira. Jo\u0161 se razvija, projekt je jo\u0161 dovoljno mlad. Razumijemo potrebu za logiranjem. To je tako\u0111er vrlo va\u017eno pitanje. I vjerovatno nije manje va\u017eno od monitoringa. No, prvi na listi za implementaciju bio je monitoring. Logiranje \u0107e biti. Naravno, nastojimo automatizirati sve aspekte rada klastera. Stoga odgovor - u trenutnom trenutku operator, na\u017ealost, to ne zna, ali to je u planovima i napravit \u0107emo to. Ako postoji \u017eelja pridru\u017eiti se, slobodno napravite pull request.<\/p>\n
<\/p>\n
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\u0161 ClickHouse upravo na tim nodama na kojima postoji disk?<\/em><\/p>\n<\/p>\n
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\u0111enoj nodi na kojoj imamo fizi\u010dki priklju\u010den disk koji je montiran na odre\u0111enu putanju. To je cijela sekcija koju sam dodirnuo vrlo povr\u0161no, jer je odgovor prili\u010dno op\u0161iran. <\/p>\n
<\/p>\n
Ukratko, to izgleda ovako. Naravno, moramo obaviti provisioning ovih volumena. Trenutno u lokalnom skladi\u0161tu nema dinami\u010dkog provisioninga, pa DevOps timovi moraju sami podijeliti diskove, te volumene. Tako\u0111er, moraju objasniti Kubernetes provisioningu da \u0107e imati Persistent volumene odre\u0111enog razreda, koji se nalaze na odre\u0111enim \u010dvorovima. Zatim treba objasniti Kubernetesu da se podovi koji zahtijevaju takav razred lokalnog skladi\u0161ta trebaju raspore\u0111ivati samo na takve \u010dvorove prema etiketama. Za te namjene u operatoru postoji mogu\u0107nost dodjeljivanja neke etikete i one per host instance. Tako \u0107e podovi biti usmjereni od strane Kubernetesa za pokretanje samo na \u010dvorovima koji zadovoljavaju te zahtjeve, jednostavnim jezikom govore\u0107i. Administratori dodjeljuju etikete, ru\u010dno rade provisioning diskova. I tada se to mo\u017ee skalirati.<\/p>\n
<\/p>\n
Tre\u0107a opcija lokalnog skladi\u0161ta poma\u017ee da se to malo olak\u0161a. Kao \u0161to sam ve\u0107 naglasio, to je mukotrpan zadatak postavljanja, koji na kraju poma\u017ee da se ostvari maksimalna izvedba.<\/p>\n
<\/p>\n
Imam drugo pitanje vezano uz ovo. Kubernetes je zami\u0161ljen tako da nije va\u017eno ho\u0107emo li izgubiti \u010dvor ili ne. \u0160to trebamo u\u010diniti u tom slu\u010daju, ako izgubimo \u010dvor na kojem se nalazi shard?<\/em><\/p>\n<\/p>\n
Da, Kubernetes je izvorno pozicioniran tako da je na\u0161 odnos prema na\u0161im podovima poput stoke, a svaki disk ovdje postaje ne\u0161to poput ku\u0107nog ljubimca. Postoji problem u tome \u0161to ih ne mo\u017eemo jednostavno odbaciti. Razvoj Kubernetesa ide u smjeru da se prema tome ne mo\u017ee potpuno filozofski odnositi kao prema resursima koji se potpuno odbacuju.<\/p>\n
<\/p>\n
Sada prakti\u010dno pitanje. \u0160to u\u010diniti ako izgubi\u0161 \u010dvor na kojem se nalazio disk? Tada se problem rje\u0161ava na vi\u0161oj razini. U slu\u010daju ClickHousea imamo replike koje rade na vi\u0161oj razini, odnosno na razini ClickHousea.<\/p>\n
<\/p>\n
Koja je situacija? Za sprje\u010davanje 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\u0161ava operator. I nije to zadatak koji rje\u0161ava sam Kubernetes. To je na razini ClickHousea.<\/p>\n
<\/p>\n
\u0160to u\u010diniti ako vam je oti\u0161ao hardverski \u010dvor? Morat \u0107ete postaviti drugi \u010dvor, ispravno provizoriti disk i dodati oznake. Nakon toga, mo\u0107i \u0107e zadovoljiti zahtjeve da Kubernetes mo\u017ee pokrenuti instancu pod-a na njemu. Kubernetes \u0107e to pokrenuti. Broj pod-ova vam ne odgovara o\u010dekivanom. Pro\u0107i \u0107e kroz ciklus koji sam pokazao. Na najvi\u0161oj razini ClickHouse \u0107e razumjeti da nam je do\u0161la replika, koja je jo\u0161 prazna i na nju treba po\u010deti prebacivati podatke. Taj proces jo\u0161 nije potpuno automatiziran. <\/p>\n
<\/p>\n
Hvala na izlaganju! Kada se doga\u0111aju razne nevolje, operator se sru\u0161i i ponovno pokrene, a u tom trenutku dolaze doga\u0111aji, kako to obra\u0111ujete?<\/em><\/p>\n<\/p>\n
\u0160to \u0107e se dogoditi ako se operator sru\u0161i i ponovno pokrene? <\/p>\n
<\/p>\n
Da. I u tom trenutku zaprimljeni su doga\u0111aji.<\/em> <\/p>\n<\/p>\n
Zadatak \u0161to u\u010diniti u tom slu\u010daju dijelom se dijeli izme\u0111u operatera i Kubernetesa. Kubernetes ima mogu\u0107nost ponovnog reprodukcije doga\u0111aja koji su se dogodili. On to ponovo reproducira. A zadatak operatera je osigurati da kada se izvr\u0161i ponovna reprodukcija dnevnika doga\u0111aja, ti doga\u0111aji budu idempotentni. Da ponovno dolazak istog doga\u0111aja ne uni\u0161ti na\u0161 sustav. I na\u0161 operator se nosi s tim zadatkom. <\/p>\n
<\/p>\n
Pozdrav! Hvala na izlaganju! Dmitrij Zavaljov, tvrtka<\/em> Smedova. Planira li se dodati mogu\u0107nost postavljanja s haproxy u operator? Interesira me neki drugi balansator osim standardnog, koji bi bio pametan i razumio da je stvarno ClickHouse.<\/em> <\/p>\n<\/p>\n
Govori\u0161 o Ingressu?<\/p>\n
<\/p>\n
Da, zamijeniti Ingress s haproxy. U haproxy mo\u017eete nazna\u010diti topologiju klastera u kojem su njegovi replikati.<\/em><\/p>\n<\/p>\n
Za sada o tome nismo razmi\u0161ljali. Ako vam je to potrebno i mo\u017eete objasniti za\u0161to je to potrebno, moglo bi se implementirati, posebno ako \u017eelite sudjelovati. Rado \u0107emo razmotriti tu mogu\u0107nost. Kratak odgovor \u2013 ne, trenutno nemamo tu funkcionalnost. Hvala na prijedlogu, pogledat \u0107emo to. A ako nam dodatno objasnite use case i za\u0161to je to potrebno u praksi, na primjer, ako kreirate issue na GitHubu, bilo bi odli\u010dno.<\/p>\n
<\/p>\n
Ve\u0107 postoji.<\/em><\/p>\n<\/p>\n
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\u010di da je proizvod tra\u017een.<\/p>\n
Izvor: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0414\u043e\u043a\u043b\u0430\u0434 \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u043c \u0432\u043e\u043f\u0440\u043e\u0441\u0430\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440\u0430 \u0432 Kubernetes, \u043f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044e \u0435\u0433\u043e \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b \u0438 \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u0445 \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u043e\u0432 \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f. \u0412 \u043f\u0435\u0440\u0432\u043e\u0439 \u0447\u0430\u0441\u0442\u0438 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c: \u0447\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u0432 Kubernetes \u0438 \u0437\u0430\u0447\u0435\u043c \u043e\u043d \u043d\u0443\u0436\u0435\u043d; \u043a\u0430\u043a \u0438\u043c\u0435\u043d\u043d\u043e \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u0443\u043f\u0440\u043e\u0449\u0430\u0435\u0442 \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0435 \u0441\u043b\u043e\u0436\u043d\u044b\u043c\u0438 \u0441\u0438\u0441\u0442\u0435\u043c\u0430\u043c\u0438; \u0447\u0442\u043e \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u043c\u043e\u0436\u0435\u0442, \u0430 \u0447\u0442\u043e \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u043d\u0435 \u043c\u043e\u0436\u0435\u0442. \u0414\u0430\u043b\u0435\u0435, \u043f\u0435\u0440\u0435\u0439\u0434\u0451\u043c \u043a \u043e\u0431\u0441\u0443\u0436\u0434\u0435\u043d\u0438\u044e \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0433\u043e \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432\u0430 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440\u0430. \u0420\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0443 \u0438 \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":96966,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-96965","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Operator](\"\/wp-content\/uploads\/2020\/10\/56e002c7408c4708e39ece867f84171e.jpeg\")
<\/p>\n