Poročilo je posvečeno praktičnim vprašanjem razvoja operaterja v Kubernetesu, oblikovanju njegove arhitekture in osnovnih načel delovanja.
V prvem delu poročila bomo obravnavali:
- kaj je operater v Kubernetesu in zakaj je potreben;
- kako natančno operater poenostavi upravljanje kompleksnih sistemov;
- kaj operater sme in česa ne sme.
Nato preidimo na razpravo o notranji strukturi operaterja. Oglejmo si arhitekturo in delovanje operaterja korak za korakom. Oglejmo si ga podrobneje:
- interakcija med operaterjem in Kubernetesom;
- katere funkcije prevzame operater in katere funkcije prenese na Kubernetes.
Oglejmo si upravljanje drobcev in replik baze podatkov v Kubernetesu.
Nato bomo razpravljali o vprašanjih shranjevanja podatkov:
- kako delati s Persistent Storage z vidika operaterja;
- pasti uporabe lokalnega pomnilnika.
V zadnjem delu poročila bomo obravnavali praktične primere uporabe s storitvijo Amazon ali Google Cloud Service. Poročilo temelji na primeru razvojnih in obratovalnih izkušenj operaterja za ClickHouse.
Video:
Moje ime je Vladislav Klimenko. Danes sem želel govoriti o naših izkušnjah pri razvoju in delovanju operaterja, in to je specializiran operater za upravljanje gruč baz podatkov. Na primer za upravljanje gruče ClickHouse.
Zakaj imamo priložnost govoriti o operaterju in ClickHouse?
- Podpiramo in razvijamo ClickHouse.
- Trenutno poskušamo počasi prispevati k razvoju ClickHouse. Po obsegu sprememb ClickHouse smo drugi za Yandexom.
- Poskušamo narediti dodatne projekte za ekosistem ClickHouse.
Rad bi vam povedal o enem od teh projektov. Gre za operaterja ClickHouse za Kubernetes.
V svojem poročilu bi se rad dotaknil dveh tem:
- Prva tema je, kako naš operater upravljanja baze podatkov ClickHouse deluje v Kubernetesu.
- Druga tema je, kako kateri koli operater deluje, tj. kako komunicira s Kubernetesom.
Vendar se bosta ti dve vprašanji križali v mojem poročilu.
Koga bi zanimalo poslušanje tega, kar hočem povedati?
- Najbolj bo zanimiv za tiste, ki upravljajo operaterje.
- Ali za tiste, ki želijo narediti svojega, da bi razumeli, kako deluje interno, kako operater komunicira s Kubernetesom in kakšne pasti se lahko pojavijo.
Da bi najbolje razumeli, o čem bomo danes razpravljali, je dobro vedeti, kako deluje Kubernetes, in imeti nekaj osnovnega usposabljanja v oblaku.
Kaj je ClickHouse? To je stolpična zbirka podatkov s posebnimi funkcijami za spletno obdelavo analitičnih poizvedb. In je popolnoma odprtokoden.
In pomembno je, da vemo samo dve stvari. Vedeti morate, da je to baza podatkov, zato bo to, kar vam bom povedal, uporabno za skoraj vsako bazo podatkov. Dejstvo, da se ClickHouse DBMS zelo dobro prilagaja, daje skoraj linearno razširljivost. Zato je stanje gruče naravno stanje za ClickHouse. In najbolj nas zanima razprava o tem, kako služiti gruči ClickHouse v Kubernetesu.
Zakaj je tam potreben? Zakaj ga ne moremo še naprej upravljati sami? In odgovori so delno tehnični in delno organizacijski.
- V praksi se vse pogosteje srečujemo s situacijo, ko so v velikih podjetjih skoraj vse komponente že v Kubernetesu. Podatkovne baze ostajajo zunaj.
- In vse pogosteje se postavlja vprašanje: "Ali je to mogoče postaviti notri?" Zato si velika podjetja prizadevajo doseči maksimalno poenotenje upravljanja, da bi lahko hitro upravljala s svojimi podatkovnimi skladišči.
- In to še posebej pomaga, če potrebujete največ možnosti za ponovitev iste stvari na novem mestu, tj. največjo prenosljivost.
Kako enostavno ali težko je? To je seveda mogoče storiti ročno. A ni tako preprosto, saj imamo dodatno kompleksnost upravljanja samega Kubernetesa, hkrati pa se prekrivajo specifike ClickHouse. In takšno združevanje nastane.
In vse skupaj daje dokaj velik nabor tehnologij, ki jih postane precej težko obvladovati, saj Kubernetes prinaša svoje vsakdanje težave v delovanje, ClickHouse pa svoje probleme v vsakdanje delovanje. Še posebej, če imamo več ClickHouse in moramo z njimi nenehno nekaj početi.
Z dinamično konfiguracijo ima ClickHouse dokaj veliko težav, ki povzročajo stalno obremenitev DevOps:
- Ko želimo nekaj spremeniti v ClickHouse, na primer dodati repliko ali shard, potem moramo upravljati konfiguracijo.
- Nato spremenite podatkovno shemo, ker ima ClickHouse posebno metodo razdeljevanja. Tam morate postaviti podatkovni diagram, postaviti konfiguracije.
- Nastaviti morate spremljanje.
- Zbiranje dnevnikov za nove šarde, za nove replike.
- Poskrbite za obnovo.
- In znova zaženite.
To so rutinska opravila, ki bi jih res rad poenostavil.
Sam Kubernetes dobro pomaga pri delovanju, vendar pri osnovnih sistemskih stvareh.
Kubernetes je dober pri omogočanju in avtomatizaciji stvari, kot so:
- Okrevanje.
- Ponovni zagon.
- Upravljanje pomnilniškega sistema.
To je dobro, to je prava smer, vendar nima pojma o tem, kako upravljati gručo baze podatkov.
Želimo več, želimo, da celotna zbirka podatkov deluje v Kubernetesu.
Rad bi dobil nekaj podobnega velikemu čarobnemu rdečemu gumbu, na katerega pritisnete in gruča z vsakodnevnimi nalogami, ki jih je treba rešiti, se razmesti in vzdržuje skozi celoten življenjski cikel. Gruča ClickHouse v Kubernetesu.
In poskušali smo narediti rešitev, ki bi olajšala delo. To je operater ClickHouse za Kubernetes podjetja Altinity.
Operater je program, katerega glavna naloga je upravljanje drugih programov, torej je upravitelj.
In vsebuje vzorce obnašanja. Temu lahko rečete kodificirano znanje o predmetnem področju.
In njegova glavna naloga je olajšati življenje DevOps in zmanjšati mikromanagement, tako da on (DevOps) že razmišlja na visoki ravni, tj. da se (DevOps) ne ukvarja z mikromanagementom, da ne konfigurira vse podrobnosti ročno.
In samo operater je robotski pomočnik, ki se ukvarja z mikronalogami in pomaga DevOps.
Zakaj potrebujete operaterja? Še posebej dobro se obnese na dveh področjih:
- Kadar specialist, ki se ukvarja s ClickHouse, nima dovolj izkušenj, ampak že mora upravljati ClickHouse, operater olajša delovanje in vam omogoči upravljanje ClickHouse grozda z dokaj kompleksno konfiguracijo, ne da bi se preveč spuščali v podrobnosti o tem, kako vse skupaj deluje. znotraj. Samo daš mu naloge na visoki ravni in deluje.
- In druga naloga, pri kateri se najbolje obnese, je, ko je treba avtomatizirati veliko število tipičnih opravil. Odstrani mikroopravila sistemskih skrbnikov.
To najbolj potrebujejo bodisi tisti, ki šele začenjajo svojo pot, bodisi tisti, ki morajo narediti veliko avtomatizacije.
Kako se operaterski pristop razlikuje od drugih sistemov? Tam je Helm. Pomaga tudi namestitev ClickHouse; lahko narišete krmilne karte, kar bo celo namestilo celotno gručo ClickHouse. Kakšna je potem razlika med operaterjem in istim, na primer, Helm?
Glavna temeljna razlika je v tem, da je Helm upravljanje paketov, Operator pa gre še korak dlje. To je podpora za celoten življenjski cikel. To ni samo namestitev, to so vsakdanja opravila, ki vključujejo skaliranje, sharding, torej vse, kar je treba narediti v življenjskem ciklu (če je treba, tudi brisanje) - o vsem odloča operater. Poskuša avtomatizirati in vzdrževati celoten življenjski cikel programske opreme. To je njegova temeljna razlika od drugih predstavljenih rešitev.
To je bil uvodni del, gremo naprej.
Kako zgradimo svojega operaterja? Težavi poskušamo pristopiti tako, da upravljamo gručo ClickHouse kot en sam vir.
Tukaj imamo vhodne podatke na levi strani slike. To je YAML s specifikacijo gruče, ki se v Kubernetes posreduje na klasičen način preko kubectl. Tam ga naš operater prevzame in naredi svoje. In na izhodu dobimo naslednjo shemo. To je implementacija ClickHouse v Kubernetesu.
In potem bomo počasi pogledali, kako natančno deluje operater, katere tipične naloge je mogoče rešiti. Upoštevali bomo samo tipične naloge, ker imamo omejen čas. In ne bo razpravljalo o vsem, o čemer se lahko odloči operater.
Začnimo s prakso. Naš projekt je popolnoma odprtokoden, zato si lahko ogledate, kako deluje na GitHubu. In lahko izhajate iz premislekov, da če ga želite samo zagnati, potem lahko začnete z vodnikom za hiter začetek.
Če želite podrobno razumeti, potem poskušamo vzdrževati dokumentacijo v bolj ali manj spodobni obliki.
Začnimo s praktičnim problemom. Prva naloga, pri kateri vsi želimo začeti, je nekako zagnati prvi primer. Kako lahko zaženem ClickHouse z operaterjem, tudi če pravzaprav ne vem, kako deluje? Pišemo manifest, ker... Vsa komunikacija s k8s je komunikacija prek manifestov.
To je tako zapleten manifest. To, kar smo označili z rdečo, je tisto, na kar se moramo osredotočiti. Operaterja prosimo, da ustvari gručo z imenom demo.
To so za zdaj osnovni primeri. Shranjevanje še ni bilo opisano, vendar se bomo k shranjevanju vrnili nekoliko kasneje. Za zdaj bomo opazovali dinamiko razvoja grozda.
Ustvarili smo ta manifest. Posredujemo ga našemu operaterju. Delal je, delal je čarovnije.
Pogledamo konzolo. Zanimive so tri komponente: Pod, dve storitvi in StatefulSet.
Operater je delal in lahko vidimo, kaj točno je ustvaril.
Ustvari nekaj takega. Imamo StatefulSet, Pod, ConfigMap za vsako repliko, ConfigMap za celotno gručo. Storitve so potrebne kot vstopne točke v gručo.
Storitve so osrednja storitev za izravnavo obremenitve in se lahko uporabljajo tudi za vsako repliko, za vsak delček.
Naša osnovna gruča izgleda nekako takole. Je iz enega samega vozlišča.
Pojdimo dalje in zakomplicirajmo. Grozd moramo razdeliti.
Naše naloge rastejo, začenja se dinamika. Želimo dodati drobec. Sledimo razvoju. Spreminjamo našo specifikacijo. Označimo, da želimo dva sharda.
To je ista datoteka, ki se dinamično razvija z rastjo sistema. Shranjevanje ne, o shranjevanju bomo še razpravljali, to je ločena tema.
Napajamo operaterja YAML in vidimo, kaj se zgodi.
Operater je razmišljal in naredil naslednje entitete. Imamo že dva Poda, tri storitve in nenadoma 2 StatefulSeta. Zakaj 2 StatefulSets?
Na diagramu je bilo tako - to je naše začetno stanje, ko smo imeli en pod.
Postalo je takole. Doslej je vse preprosto, podvojeno.
In zakaj sta nastala dva StatefulSeta? Tukaj se moramo oddaljiti in razpravljati o vprašanju, kako se Pods upravljajo v Kubernetesu.
Obstaja objekt, imenovan StatefulSet, ki vam omogoča, da iz predloge ustvarite nabor podov. Ključni dejavnik pri tem je predloga. Z uporabo ene predloge v enem StatefulSetu lahko zaženete veliko podov. In ključna besedna zveza tukaj je "več podov za eno predlogo."
In bila je velika skušnjava, da bi naredili celotno gručo in jo zapakirali v en StatefulSet. Bo šlo, ni problema. Vendar obstaja eno opozorilo. Če želimo sestaviti heterogeni grozd, torej iz več različic ClickHouse, se začnejo porajati vprašanja. Da, StatefulSet lahko naredi tekočo posodobitev in tam lahko uvedete novo različico, razložite, da ne smete poskusiti več kot toliko vozlišč hkrati.
Toda če ekstrapoliramo nalogo in rečemo, da želimo narediti popolnoma heterogeno gručo in ne želimo spremeniti stare različice v novo s tekočo posodobitvijo, ampak preprosto želimo ustvariti heterogeno gručo tako v smislu različnih različic ClickHouse in v smislu različnega shranjevanja. Želimo, na primer, narediti nekaj replik na ločenih diskih, na počasnih, sploh v celoti zgraditi heterogeno gručo. In zaradi dejstva, da StatefulSet naredi standardizirano rešitev iz ene predloge, tega ni mogoče storiti.
Po premisleku smo se odločili, da bomo to naredili na ta način. Vsako repliko imamo v svojem StatefulSet-u. Ta rešitev ima nekaj pomanjkljivosti, vendar v praksi operater vse to popolnoma zajame. In prednosti je veliko. Zgradimo lahko natančen grozd, ki ga želimo, na primer popolnoma heterogen. Zato bomo v gruči, v kateri imamo dva sharda z eno repliko, imeli 2 StatefulSet-a in 2 Pods ravno zato, ker smo se za ta pristop odločili iz zgoraj navedenih razlogov, da lahko zgradimo heterogeno gručo.
Vrnimo se k praktičnim težavam. V naši gruči moramo konfigurirati uporabnike, tj. narediti morate nekaj konfiguracije ClickHouse v Kubernetesu. Operater zagotavlja vse možnosti za to.
V YAML lahko napišemo, kar želimo. Vse konfiguracijske možnosti so preslikane neposredno iz tega YAML v konfiguracije ClickHouse, ki so nato porazdeljene po gruči.
Lahko zapišeš takole. To je na primer. Geslo je lahko šifrirano. Podprte so absolutno vse možnosti konfiguracije ClickHouse. Tukaj je samo primer.
Konfiguracija gruče je distribuirana kot ConfigMap. V praksi se posodobitev ConfigMap ne zgodi takoj, tako da, če je gruča velika, postopek potiskanja konfiguracije traja nekaj časa. Toda vse to je zelo priročno za uporabo.
Zakomplicirajmo nalogo. Grozd se razvija. Podatke želimo posnemati. To pomeni, da že imamo dva sharda, po eno repliko, uporabniki pa so konfigurirani. Rastemo in želimo narediti replikacijo.
Kaj potrebujemo za replikacijo?
Potrebujemo ZooKeeper. V ClickHouse je replikacija zgrajena z ZooKeeperjem. ZooKeeper je potreben, da imajo različne replike ClickHouse soglasje glede tega, kateri podatkovni bloki so na kateri ClickHouse.
ZooKeeper lahko uporablja vsak. Če ima podjetje zunanji ZooKeeper, ga je mogoče uporabiti. Če ne, ga lahko namestite iz našega skladišča. Obstaja namestitveni program, ki olajša to stvar.
In interakcijski diagram celotnega sistema se izkaže takole. Kot platformo imamo Kubernetes. Izvaja operater ClickHouse. ZooKeeper sem si zamislil tukaj. In operater sodeluje s ClickHouse in ZooKeeper. Se pravi, rezultati interakcije.
In vse to je potrebno, da ClickHouse uspešno replicira podatke v k8s.
Poglejmo zdaj samo nalogo, kakšen bo manifest za replikacijo.
Našemu manifestu dodajamo dva razdelka. Prvi je, kje dobiti ZooKeeper, ki je lahko znotraj Kubernetesa ali zunaj. To je samo opis. In naročamo replike. Tisti. želimo dve repliki. Skupaj bi morali imeti na izhodu 4 stroke. Spomnimo se na shranjevanje, vrnilo se bo malo kasneje. Shranjevanje je posebna zgodba.
Tako je bilo.
Takole postane. Dodane so replike. Četrti ni ustrezal, verjamemo, da bi jih tam lahko bilo veliko. In ZooKeeper je dodan ob strani. Sheme postajajo vse bolj zapletene.
In čas je, da dodamo naslednjo nalogo. Dodali bomo trajno shranjevanje.
Za trajno shranjevanje imamo na voljo različne možnosti.
Če delujemo pri ponudniku v oblaku, na primer z uporabo Amazona, Googla, potem obstaja velika skušnjava, da bi uporabili shranjevanje v oblaku. Zelo je priročno, dobro je.
In obstaja druga možnost. To je za lokalno shranjevanje, ko imamo lokalne diske na vsakem vozlišču. To možnost je veliko težje izvesti, vendar je hkrati bolj produktivna.
Poglejmo, kaj imamo glede shranjevanja v oblaku.
Obstajajo prednosti. Zelo enostavno ga je konfigurirati. Preprosto naročimo ponudniku oblaka, naj nam odstopi skladišče takšne in take kapacitete, takšnega in takega razreda. Urnik pouka izvajajo samostojno.
In obstaja pomanjkljivost. Za nekatere je to nekritična pomanjkljivost. Seveda bo nekaj težav z zmogljivostjo. Je zelo priročen za uporabo in zanesljiv, vendar ima nekaj možnih pomanjkljivosti pri delovanju.
In ker ClickHouse se osredotoča predvsem na produktivnost, lahko bi celo rekli, da iz sebe iztisne vse, kar lahko, zato se veliko naročnikov trudi iztisniti maksimalno produktivnost.
Da bi kar najbolje izkoristili, potrebujemo lokalno shrambo.
Kubernetes ponuja tri abstrakcije za uporabo lokalnega pomnilnika v Kubernetesu. to:
- EmptyDir
- HostPath.
- Lokalno
Poglejmo, v čem se razlikujejo in v čem so si podobni.
Prvič, v vseh treh pristopih imamo shranjevanje - to so lokalni diski, ki se nahajajo na istem fizičnem vozlišču k8s. Imajo pa nekaj razlik.
Začnimo z najpreprostejšim, tj. emptyDir. Kaj je to v praksi? V naši specifikaciji zahtevamo kontejnerski sistem (najpogosteje Docker), da nam omogoči dostop do mape na lokalnem disku.
V praksi Docker ustvari začasno mapo nekje na svojih poteh in jo imenuje dolga zgoščena vrednost. In ponuja vmesnik za dostop do njega.
Kako bo to delovalo z vidika uspešnosti? To bo delovalo pri hitrosti lokalnega diska, tj. To je popoln dostop do vašega vijaka.
Toda ta primer ima svojo pomanjkljivost. Persistent je v tej zadevi precej dvomljiv. Ko se Docker prvič premakne z vsebniki, se Persistent izgubi. Če Kubernetes iz nekega razloga želi ta Pod premakniti na drug disk, bodo podatki izgubljeni.
Ta pristop je dober za teste, saj že kaže normalno hitrost, vendar za nekaj resnega ta možnost ni primerna.
Zato obstaja drugi pristop. To je hostPath. Če pogledate prejšnji in ta diapozitiv, lahko vidite samo eno razliko. Naša mapa se je premaknila iz Dockerja neposredno v vozlišče Kubernetes. Tukaj je malo bolj preprosto. Neposredno določimo pot v lokalnem datotečnem sistemu, kamor želimo shraniti naše podatke.
Ta metoda ima prednosti. To je že pravi Persistent, in to klasičen. Podatke bomo imeli zapisane na disku na nekem naslovu.
Obstajajo tudi slabosti. To je kompleksnost upravljanja. Naš Kubernetes bo morda želel Pod premakniti v drugo fizično vozlišče. In tukaj nastopi DevOps. Celotnemu sistemu mora pravilno razložiti, da je te pode mogoče premakniti samo na tista vozlišča, na katerih imate nekaj nameščeno vzdolž teh poti, in ne več kot eno vozlišče naenkrat. Je precej težko.
Posebej za te namene smo v našem operaterju naredili predloge, da bi skrili vso to kompleksnost. Lahko bi preprosto rekli: "Želim imeti en primerek ClickHouse za vsako fizično vozlišče in vzdolž te in te poti."
Nismo pa edini, ki potrebujemo to potrebo, zato tudi gospodje iz Kubernetesa razumejo, da ljudje želijo imeti dostop do fizičnih diskov, zato poskrbijo za tretjo plast.
Imenuje se lokalno. Razlike od prejšnjega diapozitiva praktično ni. Samo prej je bilo treba ročno potrditi, da teh podov ne moremo prenesti iz vozlišča v vozlišče, ker morajo biti pripeti po neki poti na lokalni fizični disk, zdaj pa je vse to znanje inkapsulirano v samem Kubernetesu. In izkaže se, da ga je veliko lažje konfigurirati.
Vrnimo se k našemu praktičnemu problemu. Vrnimo se k predlogi YAML. Tukaj imamo resnično skladišče. Spet smo pri tem. Nastavili smo klasično predlogo VolumeClaim kot v k8s. In opišemo, kakšno vrsto shranjevanja želimo.
Po tem bo k8s zahteval shranjevanje. Dodelil nam ga bo v StatefulSet. In na koncu bo na razpolago ClickHouse.
Imeli smo to shemo. Naša trajna shramba je bila rdeča, kar je nakazovalo, da je treba to narediti.
In postane zelena. Zdaj je shema gruče ClickHouse na k8s popolnoma dokončana. Imamo šarde, replike, ZooKeeper, imamo pravi Persistent, ki je tako ali drugače implementiran. Shema je že v celoti operativna.
Živimo naprej. Naš grozd se razvija. In Alexey poskusi in izda novo različico ClickHouse.
Pojavi se praktična naloga - preizkusiti novo različico ClickHouse na našem grozdu. In seveda ne želite razviti vsega; želite dati novo različico v eno repliko nekje v skrajnem kotu in morda ne eno novo različico, ampak dve naenkrat, ker se pogosto pojavljata.
Kaj lahko rečemo o tem?
Tukaj imamo ravno takšno priložnost. To so predloge za stroke. Lahko napišete, da vam naš operater popolnoma omogoča izgradnjo heterogenega grozda. Tisti. konfigurirati, začenši od vseh replik v kupu, konča z vsako osebno repliko, katero različico želimo ClickHouse, katero različico želimo shranjevanje. Grozd lahko v celoti konfiguriramo s konfiguracijo, ki jo potrebujemo.
Pojdimo malo globlje vase. Pred tem smo govorili o tem, kako deluje operater ClickHouse v povezavi s posebnostmi ClickHouse.
Zdaj bi rad povedal nekaj besed o tem, kako na splošno deluje kateri koli operater, pa tudi o tem, kako deluje s K8.
Najprej si poglejmo interakcijo s K8s. Kaj se zgodi, ko uporabimo kubectl? Naši predmeti se prikažejo v etcd prek API-ja.
Na primer osnovni predmeti Kubernetes: pod, StatefulSet, storitev in tako naprej po seznamu.
Hkrati se ne zgodi še nič fizičnega. Ti objekti morajo biti materializirani v gruči.
V ta namen se pojavi krmilnik. Krmilnik je posebna komponenta k8s, ki lahko materializira te opise. Fizično ve, kako in kaj narediti. Ve, kako poganjati kontejnerje, kaj je tam treba konfigurirati, da strežnik deluje.
In materializira naše predmete v K8s.
Vendar ne želimo delovati samo s podi in StatefulSet-i, želimo ustvariti ClickHouseInstallation, torej objekt tipa ClickHouse, da bi z njim delovali kot z eno celoto. Zaenkrat te možnosti ni.
Ampak K8s ima naslednjo lepo stvar. Želimo, da imamo nekje, kot je ta kompleksna entiteta, v kateri bi bila naša gruča sestavljena iz podov in StatefulSeta.
In kaj je treba storiti za to? Najprej pride na vrsto definicija virov po meri. Kaj je to? To je opis za K8s, da boste imeli še eno vrsto podatkov, da želimo dodati vir po meri v pod, StatefulSet, ki bo znotraj zapleten. To je opis podatkovne strukture.
Tja ga pošljemo tudi preko kubectl apply. Kubernetes ga je z veseljem sprejel.
In zdaj ima objekt v našem skladišču priložnost za snemanje vira po meri, imenovanega ClickHouseInstallation.
A za zdaj se ne bo zgodilo nič več. Se pravi, če zdaj ustvarimo datoteko YAML, ki smo si jo ogledali in opisuje drobce in replike, in rečemo »kubectl apply«, jo bo Kubernetes sprejel, dal v etcd in rekel: »Super, ampak ne vem, kaj naj naredim. z njim. Ne vem, kako vzdrževati ClickHouseInstallation.«
V skladu s tem potrebujemo nekoga, ki bo Kubernetesu pomagal streči novo vrsto podatkov. Na levi strani imamo izvorni krmilnik Kubernetes, ki deluje z izvornimi tipi podatkov. In na desni bi morali imeti krmilnik po meri, ki lahko deluje s tipi podatkov po meri.
In na drug način se imenuje operater. Sem sem ga posebej vključil kot Kubernetes, ker ga je mogoče izvajati tudi zunaj K8. Najpogosteje se seveda vsi operaterji izvajajo v Kubernetesu, vendar nič ne preprečuje, da bi stal zunaj, zato je tukaj posebej premaknjen zunaj.
Po drugi strani pa krmilnik po meri, znan tudi kot operater, komunicira s Kubernetesom prek API-ja. Že ve, kako komunicirati z API-jem. In že ve, kako materializirati kompleksno vezje, ki ga želimo izdelati iz vira po meri. Točno to dela operater.
Kako deluje operater? Poglejmo desno stran, da vidimo, kako to počne. Ugotovimo, kako operater vse to materializira in kako pride do nadaljnje interakcije s K8.
Operater je program. Usmerjena je na dogodke. Operater se na dogodke naroči s pomočjo API-ja Kubernetes. Kubernetes API ima vstopne točke, kjer se lahko naročite na dogodke. In če se kaj spremeni v K8s, potem Kubernetes pošilja dogodke vsem, tj. kdor je naročen na to API točko, bo prejemal obvestila.
Operater je naročen na dogodke in se mora nekako odzvati. Njegova naloga je odzivanje na nastajajoče dogodke.
Dogodke ustvarijo določene posodobitve. Prispe naša datoteka YAML z opisom ClickHouseInstallation. Na etcd je šel prek kubectl apply. Tam se je sprožil dogodek, posledično pa je ta dogodek prišel do operaterja ClickHouse. Operater je prejel ta opis. In mora nekaj narediti. Če je prispela posodobitev za objekt ClickHouseInstallation, morate posodobiti gručo. In naloga operaterja je posodobiti gručo.
Kaj dela? Najprej moramo sestaviti akcijski načrt, kaj bomo storili s to posodobitvijo. Posodobitve so lahko zelo majhne, tj. majhna pri izvajanju YAML, vendar lahko povzroči zelo velike spremembe v gruči. Zato operater naredi načrt, ki se ga nato drži.
Po tem načrtu začne notri kuhati to strukturo, da bi materializiral stroke, storitve, t.j. narediti tisto, kar je njegova glavna naloga. Tako zgradite gručo ClickHouse v Kubernetesu.
Zdaj pa se dotaknimo tako zanimive stvari. To je delitev odgovornosti med Kubernetes in operaterjem, tj. kaj počne Kubernetes, kaj počne operater in kako medsebojno delujejo.
Kubernetes je odgovoren za sistemske stvari, tj. za osnovni nabor predmetov, ki jih je mogoče interpretirati kot obseg sistema. Kubernetes ve, kako zagnati pode, kako znova zagnati vsebnike, kako namestiti nosilce, kako delati s ConfigMap, tj. vse, čemur lahko rečemo sistem.
Operaterji delujejo v domenah. Vsak operater je narejen za svoje predmetno področje. To smo naredili za ClickHouse.
In operater sodeluje natančno v smislu predmetnega področja, kot je dodajanje replike, izdelava diagrama, nastavitev spremljanja. Posledica tega je delitev.
Oglejmo si praktični primer, kako pride do te delitve odgovornosti, ko izvedemo dejanje dodajanja replike.
Operater prejme nalogo - dodati repliko. Kaj dela operater? Operater bo izračunal, da je treba ustvariti nov StatefulSet, v katerem je treba opisati takšne in drugačne predloge, zahtevek za količino.
Vse je pripravil in posreduje K8s. Pravi, da potrebuje ConfigMap, StatefulSet, Volume. Kubernetes deluje. Materializira osnovne enote, s katerimi operira.
In potem spet pride v igro ClickHouse-operator. Ima že fizični pod, na katerem že lahko nekaj naredi. In operater ClickHouse spet deluje v smislu domene. Tisti. Natančneje ClickHouse, če želite vključiti repliko v gručo, morate najprej konfigurirati podatkovno shemo, ki obstaja v tej gruči. In drugič, ta replika mora biti vključena v monitoring, da se ji jasno sledi. Operater to že konfigurira.
In šele nato pride v poštev sam ClickHouse, tj. drugo entiteto na višji ravni. To je že zbirka podatkov. Ima svoj primerek, drugo konfigurirano repliko, ki se je pripravljena pridružiti gruči.
Izkazalo se je, da je veriga izvajanja in delitve odgovornosti pri dodajanju replike kar dolga.
Nadaljujemo s praktičnimi nalogami. Če že imate gručo, lahko preselite konfiguracijo.
Naredili smo tako, da lahko prilepite naravnost v obstoječi xml, kar ClickHouse razume.
ClickHouse lahko natančno prilagodite. Samo consko uvajanje je tisto, o čemer sem govoril, ko sem razlagal hostPath, lokalno shranjevanje. Tako pravilno izvedete consko uvajanje.
Naslednja praktična naloga je spremljanje.
Če se naša gruča spremeni, moramo občasno konfigurirati nadzor.
Poglejmo diagram. Tukaj smo si že ogledali zelene puščice. Zdaj pa poglejmo rdeče puščice. Tako želimo spremljati naš grozd. Kako metrike iz gruče ClickHouse pridejo v Prometheus in nato v Grafana.
V čem je težava pri spremljanju? Zakaj se to predstavlja kot nekakšen dosežek? Težava je v dinamiki. Ko imamo eno gručo in je statična, potem lahko enkrat nastavimo monitoring in se ne trudimo več.
Če pa imamo veliko grozdov ali pa se nenehno nekaj spreminja, potem je proces dinamičen. In nenehno ponovno konfiguriranje spremljanja je izguba sredstev in časa, tj. tudi samo lenoba. To je treba avtomatizirati. Težava je v dinamiki procesa. In operater to zelo dobro avtomatizira.
Kako se je razvijal naš grozd? Na začetku je bil tak.
Potem je bil takšen.
Na koncu je postal tak.
In spremljanje izvaja operater samodejno. Enotna vstopna točka.
In ravno pri izhodu pogledamo na armaturno ploščo Grafana, da vidimo, kako v notranjosti vre življenje našega grozda.
Mimogrede, nadzorno ploščo Grafana distribuiramo tudi pri našem operaterju neposredno v izvorni kodi. Lahko se povežete in uporabljate. Naš DevOps mi je dal ta posnetek zaslona.
Kam bi radi šli naslednjič? to:
- Razvijte avtomatizacijo testiranja. Glavna naloga je avtomatizirano testiranje novih različic.
- Prav tako resnično želimo avtomatizirati integracijo z ZooKeeper. Obstajajo tudi načrti za integracijo z operaterjem ZooKeeper. Tisti. Za ZooKeeper je bil napisan operater in logično je, da se oba operaterja začneta integrirati, da bi zgradili bolj priročno rešitev.
- Želimo narediti bolj zapletene vitalne znake.
- Z zeleno sem označil, da se bližamo dedovanju predlog - KONČANO, torej z naslednjo izdajo operaterja bomo že imeli dedovanje predlog. To je močno orodje, ki vam omogoča sestavljanje zapletenih konfiguracij iz kosov.
- In želimo avtomatizacijo kompleksnih nalog. Glavni je Re-sharding.
Vzemimo nekaj vmesnih rezultatov.
Kaj dobimo kot rezultat? In ali je vredno narediti ali ne? Ali je sploh treba poskušati povleči bazo v Kubernetes in uporabiti operater na splošno in še posebej operater Alitnity?
Na izhodu dobimo:
- Bistvena poenostavitev in avtomatizacija konfiguracije, uvajanja in vzdrževanja.
- Takoj vgrajen nadzor.
- In za uporabo pripravljene kodificirane predloge za zapletene situacije. Dejanja, kot je dodajanje replike, ni treba izvesti ročno. To naredi operater.
Samo še zadnje vprašanje je ostalo. Bazo podatkov v Kubernetesu že imamo, virtualizacijo. Kaj pa zmogljivost takšne rešitve, še posebej, ker je ClickHouse optimiziran za zmogljivost?
Odgovor je, da je vse v redu! Ne bom šel v podrobnosti, to je tema ločenega poročila.
Toda obstaja tak projekt, kot je TSBS. Kaj je njegova glavna naloga? To je preizkus zmogljivosti baze podatkov. To je poskus primerjave toplega s toplim, mehkega z mehkim.
Kako deluje? Ustvari se en niz podatkov. Nato se ta niz podatkov izvede v različnih zbirkah podatkov z uporabo istega niza testov. In vsaka baza podatkov rešuje en problem tako, kot zna in zna. In potem lahko primerjate rezultate.
Podpira že velik kup baz podatkov. Identificiral sem tri glavne. To:
- TimescaleDB.
- InfluxDB.
- ClickHouse.
Narejena je bila tudi primerjava z drugo podobno rešitvijo. Primerjava z RedShift. Primerjava je bila narejena na Amazonu. ClickHouse je tudi v tej zadevi precej pred vsemi.
Kakšne sklepe je mogoče potegniti iz tega, kar sem rekel?
- DB v Kubernetesu je možen. Verjetno je vse mogoče, a na splošno je videti, da je mogoče. ClickHouse v Kubernetesu je vsekakor mogoč s pomočjo našega operaterja.
- Operater pomaga avtomatizirati procese in resnično olajša življenje.
- Delovanje je normalno.
- In zdi se nam, da je to mogoče in treba uporabiti.
Odprta koda - pridružite se nam!
Kot sem že rekel, je operater popolnoma odprtokodni izdelek, zato bi bilo zelo dobro, če bi ga uporabljalo čim več ljudi. Pridruži se nam! Čakamo vas vse!
Hvala vsem!
vprašanja
Hvala za poročilo! Moje ime je Anton. Jaz sem iz SEMrush. Zanima me, kaj je s sečnjo. Slišimo o spremljanju, nič pa o beleženju, če govorimo o celotnem grozdu. Na primer, dvignili smo grozd na strojni opremi. In uporabljamo centralizirano beleženje, zbiramo jih v skupno kopico s standardnimi sredstvi. In potem od tam dobimo podatke, ki nas zanimajo.
Dobro vprašanje, tj. prijava na seznam opravil. Naš operater tega še ne avtomatizira. Še vedno se razvija, projekt je še precej mlad. Zavedamo se potrebe po sečnji. Tudi to je zelo pomembna tema. In verjetno ni nič manj pomembno kot spremljanje. Toda prvi na seznamu za izvedbo je bil monitoring. Sečnja bo. Seveda poskušamo avtomatizirati vse vidike življenja grozda. Zato je odgovor, da operater trenutno žal ne ve, kako to narediti, je pa v načrtih, mi bomo to naredili. Če se želite pridružiti, prosim potegnite zahtevo.
Zdravo! Hvala za poročilo! Imam standardno vprašanje v zvezi s trajnimi nosilci. Ko ustvarimo konfiguracijo s tem operaterjem, kako operater določi, na katerem vozlišču imamo pripet določen disk ali mapo? Najprej mu moramo pojasniti, da prosimo, da našo ClickHouse postavimo na ta vozlišča, ki imajo disk?
Kolikor razumem, je to vprašanje nadaljevanje lokalnega pomnilnika, zlasti njegovega dela hostPath. To je tako, kot da bi celotnemu sistemu razložili, da je treba pod zagnati na takem in takem vozlišču, na katerega imamo fizično povezan disk, ki je montiran po takšni in taki poti. To je cel razdelek, ki sem se ga dotaknil zelo površno, ker je odgovor tam precej obsežen.
Na kratko je videti takole. Seveda moramo zagotoviti te količine. Trenutno v lokalnem pomnilniku ni dinamične ponudbe, zato mora DevOps sam rezati diske, te količine. In pojasniti morajo zagotavljanje Kubernetes, da boste imeli obstojne nosilce takšnega in takega razreda, ki se nahajajo na takšnih in drugačnih vozliščih. Potem boste morali razložiti Kubernetesu, da morajo biti podi, ki zahtevajo tak in takšen lokalni razred shranjevanja, usmerjeni samo na takšna in drugačna vozlišča z uporabo oznak. Za te namene ima operater možnost dodeliti neko vrsto oznake in eno na primerek gostitelja. In izkazalo se je, da bo Kubernetes usmeril pode, da bodo delovali samo na vozliščih, ki izpolnjujejo zahteve, oznake, preprosto povedano. Skrbniki ročno dodeljujejo oznake in zagotavljanje diskov. In potem se skali.
In tretja možnost, lokalna, je tista, ki to nekoliko olajša. Kot sem že poudaril, je to skrbno delo pri uglaševanju, ki na koncu pomaga doseči največjo zmogljivost.
Imam drugo vprašanje v zvezi s tem. Kubernetes je bil zasnovan tako, da nam ni pomembno, ali izgubimo vozlišče ali ne. Kaj storiti v tem primeru, če smo izgubili vozlišče, kjer visi naš shard?
Da, Kubernetes je bil prvotno postavljen, da je naš odnos z našimi podi kot govedo, toda pri nas vsak disk postane nekaj podobnega hišnemu ljubljenčku. Obstaja takšen problem, da jih ne moremo kar zavreči. In razvoj Kubernetesa gre v smeri, da ga je nemogoče obravnavati povsem filozofsko, kot da bi bil popolnoma zavržen vir.
Zdaj pa praktično vprašanje. Kaj storiti, če ste izgubili vozlišče, na katerem je bil disk? Tukaj se problem rešuje na višji ravni. V primeru ClickHouse imamo replike, ki delujejo na višji ravni, t.j. na nivoju ClickHouse.
Kakšna je posledična dispozicija? DevOps je odgovoren za to, da se podatki ne izgubijo. Pravilno mora nastaviti replikacijo in mora zagotoviti, da replikacija teče. Replika na ravni ClickHouse mora imeti podvojene podatke. To ni naloga, ki jo rešuje operater. In ne problem, ki ga rešuje sam Kubernetes. To je na ravni ClickHouse.
Kaj storiti, če vam železni vozel odpade? In izkazalo se je, da boste morali namestiti drugo, pravilno pripraviti disk na njej in uporabiti oznake. Po tem bo izpolnjeval zahteve, da lahko Kubernetes na njem zažene instanco. Kubernetes ga bo zagnal. Vaše število podov ne zadostuje za dosego navedenega števila. Šlo bo skozi cikel, ki sem ga pokazal. In na najvišji ravni bo ClickHouse razumel, da smo vnesli repliko, je še vedno prazna in moramo začeti prenašati podatke vanjo. Tisti. Ta postopek še ni dobro avtomatiziran.
Hvala za poročilo! Ko se zgodijo najrazličnejše grde stvari, se operater sesuje in znova zažene in v tistem trenutku pridejo dogodki, ali to nekako obvladate?
Kaj se zgodi, če se operater zruši in znova zažene, kajne?
ja In v tistem trenutku so prišli dogodki.
Nalogo, kaj storiti v tem primeru, si deloma delita operater in Kubernetes. Kubernetes ima možnost ponovnega predvajanja dogodka, ki se je zgodil. Ponavlja. In naloga operaterja je zagotoviti, da so ti dogodki idempotentni, ko se na njem ponovno predvaja dnevnik dogodkov. In da ponavljanje istega dogodka ne poruši našega sistema. In naš operater se spopade s to nalogo.
Zdravo! Hvala za poročilo! Dmitry Zavyalov, podjetje Smedova. Ali obstajajo načrti, da bi operaterju dodali možnost konfiguracije s haproxyjem? Mene bi zanimal še kakšen balanser poleg standardnega, da bo pameten in bo razumel, da je ClickHouse res tam.
Ali govorite o Ingressu?
Da, zamenjaj Ingress s haproxy. V haproxyju lahko določite topologijo gruče, kjer ima replike.
O tem še nismo razmišljali. Če ga potrebujete in lahko pojasnite, zakaj je potreben, potem ga bo mogoče izvesti, še posebej, če želite sodelovati. Opcijo bomo z veseljem preučili. Kratek odgovor je ne, trenutno nimamo takšne funkcije. Hvala za namig, zadevo bomo preučili. In če razložite tudi primer uporabe in zakaj je to potrebno v praksi, na primer ustvarite težave na GitHubu, potem bo to super.
Je že.
Globa. Odprti smo za vse predloge. In haproxy je dodan na seznam opravil. Seznam opravil se povečuje, ne pa še krči. Ampak to je dobro, pomeni, da je izdelek v povpraševanju.
Vir: www.habr.com