Aruanne on pühendatud Kubernetes operaatori arendamise praktilistele küsimustele, selle arhitektuuri kujundamisele ja põhilistele tööpõhimõtetele.
Aruande esimeses osas käsitleme järgmist:
- mis on Kubernetes operaator ja miks seda vaja on;
- kuidas täpselt operaator keeruliste süsteemide haldamist lihtsustab;
- mida operaator saab teha ja mida mitte.
Järgmisena liigume edasi operaatori sisemise struktuuri üle. Vaatame samm-sammult operaatori arhitektuuri ja toimimist. Vaatame seda üksikasjalikult:
- operaatori ja Kubernetese vaheline suhtlus;
- milliseid funktsioone operaator endale võtab ja milliseid funktsioone ta Kubernetesele delegeerib.
Vaatame killude ja andmebaasi koopiate haldamist Kubernetesis.
Järgmisena käsitleme andmete salvestamise küsimusi:
- kuidas töötada püsiva salvestusega operaatori vaatenurgast;
- kohaliku salvestusruumi kasutamise lõkse.
Aruande viimases osas käsitleme praktilisi rakendusnäiteid Amazoni või Google'i pilveteenusega. Aruanne põhineb ClickHouse'i operaatori arendus- ja tegevuskogemuse näitel.
Video:
Minu nimi on Vladislav Klimenko. Täna tahtsin rääkida meie kogemustest operaatori arendamise ja käitamise vallas ning see on andmebaasiklastrite haldamiseks spetsialiseerunud operaator. Näiteks ClickHouse'i klastri haldamiseks.
Miks on meil võimalus rääkida operaatorist ja ClickHouse'ist?
- Toetame ja arendame ClickHouse'i.
- Hetkel proovime aeglaselt anda oma panust ClickHouse'i arengusse. Ja ClickHouse'is tehtud muudatuste mahu poolest oleme Yandexi järel teisel kohal.
- Püüame teha ClickHouse'i ökosüsteemi jaoks täiendavaid projekte.
Tahaksin teile rääkida ühest neist projektidest. See puudutab Kubernetese ClickHouse-operaatorit.
Oma raportis tahaksin puudutada kahte teemat:
- Esimene teema on see, kuidas meie ClickHouse'i andmebaasihaldusoperaator Kubernetesis töötab.
- Teine teema on see, kuidas mis tahes operaator töötab, st kuidas see Kubernetesega suhtleb.
Kuid need kaks küsimust ristuvad kogu minu raportis.
Kellel oleks huvi kuulata, mida ma räägin?
- See pakub kõige rohkem huvi neile, kes opereerivad.
- Või neile, kes soovivad ise teha, et mõista, kuidas see sisemiselt toimib, kuidas operaator Kubernetesega suhtleb ja millised lõksud võivad ilmneda.
Selleks, et mõista, mida täna arutame, on hea teada, kuidas Kubernetes töötab, ja läbida mõned põhilised pilvekoolitused.
Mis on ClickHouse? See on veergude andmebaas, millel on spetsiifilised funktsioonid analüütiliste päringute veebipõhiseks töötlemiseks. Ja see on täiesti avatud lähtekoodiga.
Ja meie jaoks on oluline teada ainult kahte asja. Peate teadma, et see on andmebaas, nii et see, mida ma teile ütlen, kehtib peaaegu kõigi andmebaaside kohta. Ja tõsiasi, et ClickHouse DBMS mastaabib väga hästi, annab peaaegu lineaarse skaleeritavuse. Seetõttu on klastri olek ClickHouse'i jaoks loomulik. Ja me oleme kõige rohkem huvitatud sellest, kuidas Kubernetesis ClickHouse'i klastrit teenindada.
Miks teda sinna vaja on? Miks me ei võiks seda ise edasi kasutada? Ja vastused on osaliselt tehnilised ja osaliselt organisatsioonilised.
- Praktikas puutume üha enam kokku olukorraga, kus suurettevõtetes on pea kõik komponendid juba Kubernetes. Andmebaasid jäävad väljapoole.
- Ja üha enam küsitakse: "Kas seda saab sisse panna?" Seetõttu püüavad suurettevõtted saavutada juhtimist maksimaalselt ühtlustada, et oma andmeladusid kiiresti hallata.
- Ja see aitab eriti siis, kui vajate maksimaalset võimalust sama asja uues kohas korrata, st maksimaalset teisaldatavust.
Kui lihtne või raske see on? Seda saab muidugi käsitsi teha. Kuid see pole nii lihtne, sest meil on Kubernetese enda haldamine veelgi keerukam, kuid samal ajal on ClickHouse'i eripärad kattuvad. Ja selline liitmine annab tulemuseks.
Ja see kõik kokku annab üsna suure hulga tehnoloogiaid, mille haldamine muutub üsna keeruliseks, sest Kubernetes toob tööle oma igapäevased probleemid ja ClickHouse toob oma probleemid igapäevatöösse. Eriti kui meil on mitu ClickHouse'i ja me peame nendega pidevalt midagi ette võtma.
Dünaamilise konfiguratsiooniga on ClickHouse'il üsna palju probleeme, mis loovad DevOpsile pideva koormuse:
- Kui tahame ClickHouse'is midagi muuta, näiteks lisada koopiat või killu, peame konfiguratsiooni haldama.
- Seejärel muutke andmeskeemi, sest ClickHouse'il on spetsiifiline jagamismeetod. Seal peate välja panema andmediagrammi, panema konfiguratsioonid.
- Peate seadistama jälgimise.
- Logide kogumine uute kildude ja uute koopiate jaoks.
- Hoolitse taastamise eest.
- Ja taaskäivitage.
Need on rutiinsed ülesanded, mille kasutamist tahaks väga lihtsamaks muuta.
Kubernetes ise aitab hästi töös, aga põhiliste süsteemi asjade peal.
Kubernetes on hea selliste asjade hõlbustamiseks ja automatiseerimiseks nagu:
- Taastumine.
- Taaskäivita.
- Salvestussüsteemi haldamine.
See on hea, see on õige suund, kuid ta on täiesti teadmata, kuidas andmebaasiklastrit juhtida.
Tahame rohkem, tahame, et kogu andmebaas töötaks Kubernetesis.
Tahaksin saada midagi nagu suur punane võlunupp, millele vajutate, ja igapäevaste lahendamist vajavate ülesannetega klastrit rakendatakse ja hooldatakse kogu selle elutsükli jooksul. ClickHouse'i klaster Kubernetesis.
Ja püüdsime teha lahenduse, mis aitaks tööd lihtsamaks teha. See on Altinity Kubernetese ClickHouse-operaator.
Operaator on programm, mille põhiülesanne on teiste programmide haldamine, s.t ta on haldur.
Ja see sisaldab käitumismustreid. Seda võib nimetada kodeeritud teadmisteks ainevaldkonna kohta.
Ja tema põhiülesanne on teha DevOpsi elu lihtsamaks ja vähendada mikrojuhtimist, et ta (DevOps) mõtleks juba kõrgel tasemel, st et ta (DevOps) ei tegeleks mikrohaldusega, et ta ei seadistaks. kõik üksikasjad käsitsi.
Ja lihtsalt operaator on robot-assistent, kes tegeleb mikroülesannetega ja aitab DevOpsi.
Miks on operaatorit vaja? Ta toimib eriti hästi kahes valdkonnas:
- Kui ClickHouse'iga tegeleval spetsialistil pole piisavalt kogemusi, kuid ta peab juba ClickHouse'iga opereerima, hõlbustab operaator selle toimimist ja võimaldab teil hallata üsna keerulise konfiguratsiooniga ClickHouse'i klastrit, laskumata selle kõige toimimisesse liiga üksikasjalikult. sees. Sa lihtsalt annad talle kõrgetasemelisi ülesandeid ja see toimib.
- Ja teine ülesanne, mille puhul see kõige paremini toimib, on see, kui on vaja automatiseerida suur hulk tüüpilisi ülesandeid. Eemaldab süsteemiadministraatoritelt mikroülesanded.
Seda vajavad enim kas need, kes alles alustavad oma teekonda, või need, kes peavad tegema palju automatiseerimist.
Mille poolest operaatoripõhine lähenemine erineb teistest süsteemidest? Seal on Helm. Samuti aitab see installida ClickHouse'i; saate joonistada roolidiagramme, mis installivad isegi terve ClickHouse'i klastri. Mis vahe on siis operaatoril ja samal, näiteks Helmil?
Peamine põhimõtteline erinevus seisneb selles, et Helm on paketihaldus ja Operaator läheb sammu kaugemale. See on toetus kogu elutsükliks. See ei ole ainult installimine, need on igapäevased toimingud, mis hõlmavad skaleerimist, killustamist, st kõike, mida on vaja elutsükli jooksul teha (vajadusel, siis ka kustutada) - selle kõik otsustab operaator. See püüab automatiseerida ja hooldada kogu tarkvara elutsüklit. See on selle põhimõtteline erinevus teistest esitatud lahendustest.
See oli sissejuhatav osa, lähme edasi.
Kuidas me oma operaatorit ehitame? Püüame probleemile läheneda, et hallata ClickHouse'i klastrit ühe ressursina.
Siin on pildi vasakus servas sisendandmed. See on klastri spetsifikatsiooniga YAML, mis edastatakse Kubernetesile klassikalisel viisil kubectli kaudu. Seal võtab meie operaator selle üles ja teeb oma maagiat. Ja väljundis saame järgmise skeemi. See on ClickHouse'i rakendus Kubernetesis.
Ja siis vaatame aeglaselt, kuidas operaator täpselt töötab, milliseid tüüpilisi ülesandeid saab lahendada. Kaalume ainult tüüpilisi ülesandeid, kuna meil on piiratud aeg. Ja kõike, mida operaator saab otsustada, ei arutata.
Alustame praktikast. Meie projekt on täiesti avatud lähtekoodiga, nii et näete, kuidas see GitHubis töötab. Ja võite lähtuda sellest, et kui soovite selle lihtsalt käivitada, võite alustada kiirjuhendist.
Kui soovite üksikasjalikult aru saada, siis püüame dokumentatsiooni säilitada enam-vähem korralikul kujul.
Alustame praktilise probleemiga. Esimene ülesanne, millest me kõik alustada tahame, on esimene näide kuidagi käivitada. Kuidas saan ClickHouse'i operaatori abil käivitada, isegi kui ma ei tea, kuidas see tegelikult töötab? Kirjutame manifesti, sest... Kogu suhtlus k8-ga on suhtlemine manifestide kaudu.
See on nii keeruline manifest. See, mille oleme punasega esile tõstnud, on see, millele peame keskenduma. Palume operaatoril luua klastri nimega demo.
Need on praegu põhinäited. Hoiustamist pole veel kirjeldatud, kuid naaseme ladustamise juurde veidi hiljem. Praegu jälgime klastri arengu dünaamikat.
Me koostasime selle manifesti. Toidame selle oma operaatorile. Ta töötas, tegi maagiat.
Vaatame konsooli. Kolm komponenti pakuvad huvi: Pod, kaks teenust ja StatefulSet.
Operaator on töötanud ja me näeme, mida ta täpselt lõi.
Ta loob midagi sellist. Meil on iga koopia jaoks StatefulSet, Pod, ConfigMap ja kogu klastri jaoks ConfigMap. Teenused on vajalikud klastri sisenemispunktidena.
Teenused on keskne Load Balancer Service ja neid saab kasutada ka iga koopia ja iga killu jaoks.
Meie põhiklaster näeb välja umbes selline. See pärineb ühest sõlmest.
Läheme kaugemale ja teeme asjad keeruliseks. Peame klastri killustama.
Meie ülesanded kasvavad, dünaamika algab. Tahame lisada killu. Jälgime arengut. Muudame oma spetsifikatsiooni. Anname märku, et tahame kahte kildu.
See on sama fail, mis areneb dünaamiliselt koos süsteemi kasvuga. Hoidmine ei, ladustamisest tuleb veel juttu, see on eraldi teema.
Toidame YAML-i operaatorit ja vaatame, mis juhtub.
Operaator mõtles ja tegi järgmised olemid. Meil on juba kaks Podit, kolm teenust ja äkki 2 StatefulSetsi. Miks 2 StatefulSets?
Diagrammil oli see nii - see on meie algseisund, kui meil oli üks kaun.
Sellest sai selline. Siiani on kõik lihtne, seda on dubleeritud.
Ja miks sai kaks StatefulSeti? Siin peame kõrvale kalduma ja arutama küsimust, kuidas Podisid Kubernetesis hallatakse.
Seal on objekt nimega StatefulSet, mis võimaldab teil malli põhjal luua komplekti Pods. Peamine tegur on siin mall. Ja saate käivitada mitu Podit, kasutades ühte malli ühes StatefulSetis. Ja võtmefraas on siin "palju kaunasid ühe malli jaoks".
Ja tekkis suur kiusatus teha kogu klaster, pakkides selle ühte StatefulSetisse. See toimib, sellega pole probleemi. Kuid on üks hoiatus. Kui tahame kokku panna heterogeense klastri ehk siis mitmest ClickHouse'i versioonist, siis hakkavad tekkima küsimused. Jah, StatefulSet saab teha jooksva värskenduse ja seal saate välja panna uue versiooni, selgitades, et peate proovima korraga mitte rohkem kui palju sõlme.
Aga kui me ekstrapoleerime ülesande ja ütleme, et tahame teha täiesti heterogeense klastri ja me ei taha jooksva värskenduse abil vanalt versioonilt uuele üle minna, vaid tahame lihtsalt luua heterogeense klastri mõlemas mõttes. ClickHouse'i erinevatest versioonidest ja erineva salvestusruumi osas. Näiteks tahame teha mõned koopiad eraldi ketastel, üldiselt aeglastel, et luua täielikult heterogeenne klaster. Ja kuna StatefulSet teeb standardlahenduse ühest mallist, ei saa seda teha.
Pärast mõningast mõtlemist otsustati, et teeme nii. Meil on igal koopial oma StatefulSet. Sellel lahendusel on mõned puudused, kuid praktikas on see kõik operaatori poolt täielikult kapseldatud. Ja sellel on palju eeliseid. Saame ehitada täpselt soovitud klastri, näiteks absoluutselt heterogeense klastri. Seetõttu on klastris, milles meil on kaks ühe koopiaga killukest, 2 StatefulSeti ja 2 Podit just seetõttu, et valisime selle lähenemisviisi ülaltoodud põhjustel, et saaksime luua heterogeense klastri.
Tuleme tagasi praktiliste probleemide juurde. Meie klastris peame konfigureerima kasutajad, st. peate Kubernetesis ClickHouse'i konfigureerima. Operaator pakub selleks kõik võimalused.
Saame kirjutada, mida tahame, otse YAML-is. Kõik konfiguratsioonivalikud kaardistatakse otse sellest YAML-ist ClickHouse'i konfiguratsioonidega, mis seejärel jaotatakse kogu klastris.
Saate seda kirjutada nii. See on näiteks. Parooli saab krüpteerida. Toetatud on absoluutselt kõik ClickHouse'i konfiguratsioonisuvandid. Siin on vaid näide.
Klastri konfiguratsioon levitatakse ConfigMap-ina. Praktikas ei toimu ConfigMapi värskendust kohe, nii et kui klaster on suur, võtab konfiguratsiooni surumise protsess veidi aega. Kuid seda kõike on väga mugav kasutada.
Teeme ülesande keerulisemaks. Klaster areneb. Tahame andmeid kopeerida. See tähendab, et meil on juba kaks kildu, kummalgi üks koopia, ja kasutajad on konfigureeritud. Kasvame ja tahame replikatsiooni teha.
Mida me replikatsiooniks vajame?
Meil on vaja ZooKeeperit. ClickHouse'is luuakse replikatsioon ZooKeeperi abil. ZooKeeper on vajalik selleks, et erinevatel ClickHouse'i koopiatel oleks konsensus selles, millised andmeplokid millisel ClickHouse'il asuvad.
ZooKeeperit saavad kasutada kõik. Kui ettevõttel on väline ZooKeeper, siis saab seda kasutada. Kui ei, saate selle installida meie hoidlast. Seal on installiprogramm, mis muudab selle kogu asja lihtsamaks.
Ja kogu süsteemi interaktsiooniskeem kujuneb selliseks. Meil on platvormiks Kubernetes. See käivitab ClickHouse'i operaatori. Kujutasin ZooKeeperit siin. Ja operaator suhtleb nii ClickHouse'i kui ka ZooKeeperiga. See tähendab, interaktsiooni tulemused.
Ja see kõik on vajalik selleks, et ClickHouse saaks edukalt andmeid k8s-is paljundada.
Vaatame nüüd ülesannet ennast, milline näeb välja replikatsiooni manifest.
Lisame oma manifesti kaks jaotist. Esimene on see, kust hankida ZooKeeper, mis võib olla nii Kubernetese sees kui ka väljaspool. See on vaid kirjeldus. Ja me tellime koopiaid. Need. me tahame kahte koopiat. Kokku peaks meil väljundis olema 4 kauna. Mäletame hoiustamise kohta, see tuleb veidi hiljem tagasi. Hoiustamine on omaette lugu.
See oli selline.
See muutub selliseks. Lisatakse koopiad. 4. ei sobinud, usume, et neid võiks seal palju olla. Ja kõrvale lisatakse ZooKeeper. Skeemid muutuvad keerukamaks.
Ja on aeg lisada järgmine ülesanne. Lisame püsiva salvestusruumi.
Püsisalvestuse jaoks on meil erinevaid võimalusi.
Kui töötame pilveteenuse pakkujas, kasutades näiteks Amazoni, Google'it, siis on suur kiusatus pilvesalvestust kasutada. See on väga mugav, see on hea.
Ja on ka teine variant. See on mõeldud kohaliku salvestusruumi jaoks, kui igas sõlmes on kohalikud kettad. Seda võimalust on palju keerulisem rakendada, kuid samal ajal on see produktiivsem.
Vaatame, mis meil pilvesalvestusega seoses on.
On eeliseid. Seda on väga lihtne konfigureerida. Tellime lihtsalt pilveteenuse pakkujalt, et palun andke meile sellise ja sellise mahu, sellise ja sellise klassi salvestusruum. Tunnid planeerivad pakkujad iseseisvalt.
Ja sellel on puudus. Mõne jaoks on see ebaoluline puudus. Muidugi tekivad mõned jõudlusega seotud probleemid. Seda on väga mugav kasutada ja see on töökindel, kuid sellel on mõned võimalikud puudused.
Ja sellepärast ClickHouse keskendub konkreetselt tootlikkusele, võib isegi öelda, et see pigistab välja kõik, mis suudab, mistõttu paljud kliendid püüavad välja pigistada maksimaalset tootlikkust.
Ja selleks, et sellest maksimumi saada, vajame kohalikku salvestusruumi.
Kubernetes pakub Kubernetes kohaliku salvestusruumi kasutamiseks kolm abstraktsiooni. See:
- EmptyDir
- HostPath.
- kohalik
Vaatame, kuidas need erinevad ja kuidas nad on sarnased.
Esiteks on meil kõigis kolmes lähenemisviisis salvestusruum - need on kohalikud kettad, mis asuvad samas füüsilises k8s-sõlmes. Kuid neil on mõned erinevused.
Alustame kõige lihtsamast, st tühjast kaustast. Mis see praktikas on? Meie spetsifikatsioonis palume konteinersüsteemil (kõige sagedamini Dockeril) anda meile juurdepääs kohalikul kettal olevale kaustale.
Praktikas loob Docker kuskil oma rada pidi ajutise kausta ja nimetab seda pikaks räsiks. Ja pakub sellele juurdepääsuks liidest.
Kuidas see tulemuslikkuse osas toimib? See töötab kohaliku ketta kiirusel, st. See on täielik juurdepääs teie kruvile.
Kuid sellel juhtumil on oma puudus. Püsiv on selles küsimuses üsna kahtlane. Kui Docker esimest korda konteineritega liigub, kaob püsiv. Kui Kubernetes soovib selle Podi mingil põhjusel teisele kettale teisaldada, lähevad andmed kaotsi.
Testide jaoks on selline lähenemine hea, sest näitab juba normaalset kiirust, kuid millegi tõsise jaoks see valik ei sobi.
Seetõttu on olemas teine lähenemisviis. See on hostPath. Kui vaatate eelmist ja seda slaidi, näete ainult ühte erinevust. Meie kaust kolis Dockerist otse Kubernetese sõlme. Siin on natuke lihtsam. Määrame otse kohalikus failisüsteemis tee, kuhu soovime oma andmeid salvestada.
Sellel meetodil on eelised. See on juba tõeline püsiv ja klassikaline. Andmed salvestatakse kettale mingil aadressil.
On ka puudusi. See on juhtimise keerukus. Meie Kubernetes võib soovida Podi teisaldada teise füüsilisse sõlme. Ja siin tuleb mängu DevOps. Ta peab kogu süsteemile õigesti selgitama, et neid potte saab teisaldada ainult nendesse sõlmedesse, millele teil on neid teid mööda midagi paigaldatud, ja mitte rohkem kui ühte sõlme korraga. See on üsna raske.
Spetsiaalselt selleks otstarbeks tegime oma operaatoris mallid, et kogu seda keerukust varjata. Ja võite lihtsalt öelda: "Ma tahan, et iga füüsilise sõlme jaoks oleks üks ClickHouse'i eksemplar ja seda teed mööda."
Kuid me pole ainsad, kes seda vajadust vajavad, nii et Kubernetese enda härrad saavad ka aru, et inimesed tahavad juurdepääsu füüsilistele ketastele, seega pakuvad nad kolmanda kihi.
Seda nimetatakse kohalikuks. Eelmisest slaidist pole praktiliselt mingit erinevust. Alles enne oli vaja käsitsi kinnitada, et me ei saa neid kaunasid sõlmest sõlme üle kanda, sest need tuleb mingit teed pidi kohalikule füüsilisele kettale kinnitada, aga nüüd on kogu see teadmine kapseldatud Kubernetes endasse. Ja seda on palju lihtsam konfigureerida.
Tuleme tagasi oma praktilise probleemi juurde. Pöördume tagasi YAML-i malli juurde. Siin on meil tõeline hoiuruum. Oleme selle juures tagasi. Seadsime klassikalise VolumeClaimi malli nagu k8s. Ja me kirjeldame, millist salvestusruumi me tahame.
Pärast seda küsib k8s salvestusruumi. Jaotab selle meile StatefulSetis. Ja lõpuks on see ClickHouse'i käsutuses.
Meil oli selline skeem. Meie püsisalvestus oli punane, mis näis vihjavat, et seda on vaja teha.
Ja see muutub roheliseks. Nüüd on ClickHouse'i k8s-klastriskeem täielikult valmis. Meil on killud, koopiad, ZooKeeper, meil on tõeline Persistent, mida ühel või teisel viisil rakendatakse. Skeem on juba täielikult toimiv.
Elame edasi. Meie klaster areneb. Ja Aleksei proovib ja annab välja ClickHouse'i uue versiooni.
Tekib praktiline ülesanne - testida ClickHouse'i uut versiooni meie klastris. Ja loomulikult ei taha te seda kõike levitada; soovite panna uue versiooni ühte koopiasse kuskil kaugemas nurgas ja võib-olla mitte ühe uue versiooni, vaid kaks korraga, sest need ilmuvad sageli.
Mida me saame selle kohta öelda?
Siin on meil just selline võimalus. Need on kaustade mallid. Võite kirjutada, et meie operaator võimaldab teil luua heterogeense klastri. Need. konfigureerida, alustades kõigist koopiatest hunnikus ja lõpetades iga isikliku koopiaga, millist ClickHouse'i versiooni tahame, millist versiooni me salvestusruumi tahame. Saame klastri täielikult konfigureerida vajaliku konfiguratsiooniga.
Lähme natukene sügavamale sisemusse. Enne seda rääkisime ClickHouse-operaatori toimimisest seoses ClickHouse'i spetsiifikaga.
Nüüd tahaksin öelda paar sõna selle kohta, kuidas iga operaator üldiselt töötab ja kuidas see K8-dega suhtleb.
Vaatame kõigepealt K8-dega suhtlemist. Mis juhtub, kui me kubectli rakendame? Meie objektid kuvatakse API kaudu etcd-s.
Näiteks põhilised Kubernetese objektid: pod, StatefulSet, teenus jne.
Samal ajal ei juhtu veel midagi füüsilist. Need objektid peavad olema klastris materialiseerunud.
Selleks kuvatakse kontroller. Kontroller on spetsiaalne k8s-komponent, mis suudab neid kirjeldusi realiseerida. Ta teab, kuidas ja mida füüsiliselt teha. Ta teab, kuidas konteinereid käivitada, mida seal peab seadistama, et server töötaks.
Ja see realiseerib meie objektid K8-des.
Kuid me tahame opereerida mitte ainult kaustade ja StatefulSetidega, vaid luua ClickHouseInstallationi, st ClickHouse tüüpi objekti, et sellega ühtse tervikuna toimida. Siiani selline võimalus puudub.
Aga K8s on järgmine tore asi. Soovime, et meil oleks selline keeruline üksus, kus meie klaster oleks kokku pandud kaunadest ja StatefulSetist.
Ja mida selleks tuleb teha? Esiteks tuleb pildile kohandatud ressursi määratlus. Mis see on? See on K8-de kirjeldus, et teil on veel üks andmetüüp, et me tahame lisada poodile kohandatud ressursi StatefulSet, mis on seest keeruline. See on andmestruktuuri kirjeldus.
Saadame selle sinna ka kubectl application kaudu. Kubernetes võttis selle rõõmsalt vastu.
Ja nüüd on meie salvestusruumis etcd objektil võimalus salvestada kohandatud ressurss nimega ClickHouseInstallation.
Aga praegu ei juhtu enam midagi. See tähendab, et kui loome nüüd YAML-faili, mida vaatasime, kirjeldades killud ja koopiad, ja ütleme "kubectl apply", siis Kubernetes nõustub sellega, paneb selle etcd-sse ja ütleb: "Tore, aga ma ei tea, mida teha. sellega. Ma ei tea, kuidas ClickHouseInstallationit hooldada.
Seetõttu vajame kedagi, kes aitaks Kubernetes uut andmetüüpi teenindada. Vasakul on Kubernetese natiivne kontroller, mis töötab natiivsete andmetüüpidega. Ja paremal peaks meil olema kohandatud kontroller, mis suudab töötada kohandatud andmetüüpidega.
Ja teisel viisil nimetatakse seda operaatoriks. Lisasin selle konkreetselt siia Kubernetese nime all, sest seda saab teostada ka väljaspool K8-sid. Kõige sagedamini täidetakse muidugi kõik operaatorid Kubernetesis, kuid miski ei takista sellel väljas seista, nii et siin liigutatakse see spetsiaalselt väljapoole.
Ja kohandatud kontroller, tuntud ka kui operaator, suhtleb Kubernetesiga API kaudu. See juba teab, kuidas API-ga suhelda. Ja ta juba teab, kuidas realiseerida keerulist vooluringi, mida tahame kohandatud ressursist teha. See on täpselt see, mida operaator teeb.
Kuidas operaator töötab? Vaatame paremat poolt, et näha, kuidas ta seda teeb. Uurime, kuidas operaator seda kõike realiseerib ja kuidas toimub edasine suhtlus K8-dega.
Operaator on programm. Ta on sündmustele orienteeritud. Operaator tellib üritusi Kubernetes API abil. Kubernetes API-l on sisenemispunktid, kus saate üritusi tellida. Ja kui K8s midagi muutub, siis Kubernetes saadab üritusi kõigile, st. kes on selle API-punkti tellinud, saab märguandeid.
Operaator tellib sündmused ja peab reageerima. Tema ülesanne on reageerida esilekerkivatele sündmustele.
Sündmusi genereerivad teatud värskendused. Saabub meie YAML-fail koos ClickHouseInstallationi kirjeldusega. Ta läks etcd-sse kubectli rakenduse kaudu. Seal käivitati sündmus ja selle tulemusena jõudis see sündmus ClickHouse-operaatorini. Operaator sai selle kirjelduse. Ja ta peab midagi tegema. Kui ClickHouseInstallation objektile on saabunud värskendus, siis tuleb klastrit värskendada. Ja operaatori ülesanne on klastri värskendamine.
Mida ta teeb? Esiteks peame koostama tegevuskava selle värskendusega ettevõtmiseks. Uuendused võivad olla väga väikesed, s.t. YAML-i täitmisel väike, kuid võib klastris kaasa tuua väga suuri muudatusi. Seetõttu koostab operaator plaani ja jääb sellest siis kinni.
Selle plaani järgi hakkab ta seda struktuuri sees küpsetama, et realiseerida kaunad, teenused, s.t. teha seda, mis on tema põhiülesanne. Nii saate luua Kubernetesis ClickHouse'i klastri.
Nüüd puudutame sellist huvitavat asja. See on vastutuse jaotus Kubernetese ja operaatori vahel, st. mida Kubernetes teeb, mida operaator teeb ja kuidas nad omavahel suhtlevad.
Kubernetes vastutab süsteemi asjade eest, st. objektide põhikomplekti jaoks, mida saab tõlgendada süsteemi ulatusena. Kubernetes teab, kuidas käivitada podse, kuidas restarteerida konteinereid, kuidas ühendada köiteid, kuidas töötada ConfigMapiga, st. kõike, mida saab süsteemiks nimetada.
Operaatorid tegutsevad domeenides. Iga operaator on loodud oma ainevaldkonna jaoks. Tegime seda ClickHouse'i jaoks.
Ja operaator suhtleb täpselt ainevaldkonnas, näiteks lisab koopiat, teeb diagrammi, seadistab monitooringu. Selle tulemuseks on jagunemine.
Vaatame praktilist näidet selle kohta, kuidas selline vastutuse jaotus toimub, kui teeme koopia lisamise toimingu.
Operaator saab ülesande – lisada koopia. Mida operaator teeb? Operaator arvutab, et tuleb luua uus StatefulSet, milles tuleb kirjeldada selliseid ja selliseid malle, mahunõue.
Ta valmistas selle kõik ette ja edastab selle K8-dele. Ta ütleb, et tal on vaja ConfigMap, StatefulSet, Volume. Kubernetes töötab. Ta materialiseerib põhiüksused, millega ta tegutseb.
Ja siis tuleb jälle mängu ClickHouse-operator. Tal on juba füüsiline pod, mille peal saab juba midagi teha. Ja ClickHouse-operaator töötab taas domeeni terminites. Need. Täpsemalt ClickHouse'i puhul peate koopia lisamiseks klastris esmalt konfigureerima selles klastris oleva andmeskeemi. Ja teiseks tuleb see koopia seiresse kaasata, et seda oleks võimalik selgelt jälgida. Operaator on selle juba konfigureerinud.
Ja alles pärast seda tuleb mängu ClickHouse ise, st. teine kõrgema taseme üksus. See on juba andmebaas. Sellel on oma eksemplar, teine konfigureeritud koopia, mis on valmis klastriga liituma.
Selgub, et täitmise ahel ja vastutuse jagamine koopia lisamisel on üsna pikk.
Jätkame oma praktilisi ülesandeid. Kui teil on juba klaster, saate konfiguratsiooni migreerida.
Tegime selle nii, et saate kleepida otse olemasolevasse xml-i, millest ClickHouse aru saab.
Saate ClickHouse'i peenhäälestada. Just tsoneeritud juurutus on see, millest ma rääkisin hostPathi ehk kohalikku salvestusruumi selgitades. Nii saate tsoneeritud juurutamist õigesti teha.
Järgmine praktiline ülesanne on monitooring.
Kui meie klaster muutub, peame perioodiliselt seire konfigureerima.
Vaatame diagrammi. Oleme siin juba vaadanud rohelisi nooli. Nüüd vaatame punaseid nooli. Nii tahame oma klastrit jälgida. Kuidas ClickHouse'i klastri mõõdikud Prometheusesse ja seejärel Grafanasse jõuavad.
Mis on jälgimise raskus? Miks seda mingi saavutusena esitletakse? Raskus seisneb dünaamikas. Kui meil on üks klaster ja see on staatiline, siis saame ühe korra seire seadistada ja enam ei viitsi.
Aga kui meil on palju klastreid või midagi pidevalt muutub, siis on protsess dünaamiline. Ja jälgimise pidev ümberseadistamine on ressursside ja aja raiskamine, s.t. isegi lihtsalt laiskus. Seda tuleb automatiseerida. Raskus seisneb protsessi dünaamikas. Ja operaator automatiseerib selle väga hästi.
Kuidas meie klaster arenes? Alguses oli ta selline.
Siis ta oli selline.
Lõpuks sai ta selliseks.
Ja jälgimist teeb operaator automaatselt. Üks sisenemispunkt.
Ja just väljapääsu juures vaatame Grafana armatuurlauda, et näha, kuidas meie klastri elu sees keeb.
Muide, Grafana armatuurlauda levitatakse ka meie operaatoriga otse lähtekoodis. Saate ühendada ja kasutada. Meie DevOps andis mulle selle ekraanipildi.
Kuhu me järgmisena minna tahaksime? See:
- Arendada testimise automatiseerimist. Peamine ülesanne on uute versioonide automatiseeritud testimine.
- Samuti tahame tõesti ZooKeeperiga integreerimist automatiseerida. Ja plaanis on integreerida ZooKeeper-operaatoriga. Need. ZooKeeperi jaoks on kirjutatud operaator ja on loogiline, et kaks operaatorit hakkavad mugavama lahenduse loomiseks integreerima.
- Tahame teha keerukamaid elulisi näitajaid.
- Tõstsin rohelisega esile, et läheneme mallide pärimisele – VALMIS, st operaatori järgmise väljalaskega on meil juba mallide pärand. See on võimas tööriist, mis võimaldab teil tükkidest keerukaid konfiguratsioone ehitada.
- Ja me tahame keerukate ülesannete automatiseerimist. Peamine on Re-sharding.
Võtame mõned vahetulemused.
Mida me selle tulemusena saame? Ja kas seda tasub teha või mitte? Kas on üldse vaja proovida andmebaasi Kubernetesesse lohistada ja operaatorit üldiselt ja Alitnity operaatorit eriti kasutada?
Väljundis saame:
- Konfigureerimise, juurutamise ja hoolduse oluline lihtsustamine ja automatiseerimine.
- Kohe sisseehitatud monitooring.
- Ja kasutusvalmis kodeeritud mallid keeruliste olukordade jaoks. Selliseid toiminguid nagu koopia lisamine ei pea tegema käsitsi. Operaator teeb seda.
Jäänud on ainult üks viimane küsimus. Meil on juba Kubernetes andmebaas, virtualiseerimine. Kuidas on lood sellise lahenduse jõudlusega, eriti kuna ClickHouse on optimeeritud jõudluse jaoks?
Vastus on, et kõik on hästi! Ma ei lasku üksikasjadesse, see on eraldi raporti teema.
Kuid on olemas selline projekt nagu TSBS. Mis on selle peamine ülesanne? See on andmebaasi jõudluse test. See on katse võrrelda sooja soojaga, pehmet pehmega.
Kuidas ta töötab? Luuakse üks andmekogum. Seejärel käitatakse seda andmekogumit erinevates andmebaasides, kasutades samu teste. Ja iga andmebaas lahendab ühe probleemi nii, nagu ta teab. Ja siis saate tulemusi võrrelda.
See toetab juba suurt hulka andmebaase. Olen välja toonud kolm peamist. See:
- TimescaleDB.
- InfluxDB.
- ClickHouse.
Võrdlus tehti ka teise sarnase lahendusega. Võrdlus RedShiftiga. Võrdlus tehti Amazonis. ClickHouse on ka selles küsimuses kõigist tublisti ees.
Milliseid järeldusi saab minu öeldu põhjal teha?
- DB Kubernetesis on võimalik. Tõenäoliselt on kõik võimalik, kuid üldiselt tundub see olevat võimalik. ClickHouse Kubernetes on kindlasti võimalik meie operaatori abiga.
- Operaator aitab protsesse automatiseerida ja teeb elu tõesti lihtsamaks.
- Jõudlus on normaalne.
- Ja meile tundub, et seda saab ja tuleks kasutada.
Avatud lähtekoodiga – liitu meiega!
Nagu ma juba ütlesin, on operaator täiesti avatud lähtekoodiga toode, seega oleks väga hea, kui seda kasutaks maksimaalne arv inimesi. Liitu meiega! Ootame teid kõiki!
Tänan teid kõiki!
küsimused
Täname raporti eest! Minu nimi on Anton. Olen pärit SEMrushist. Mind huvitab, kuidas metsaraie lahti on. Me kuuleme seirest, kuid mitte midagi metsaraie, kui räägime kogu klastrist. Näiteks oleme loonud riistvara klastri. Ja me kasutame tsentraliseeritud logimist, kogudes need tavaliste vahenditega ühisesse hunnikusse. Ja siis sealt saame meid huvitavad andmed.
Hea küsimus, st ülesandeloendisse logimine. Meie operaator ei automatiseeri seda veel. See alles areneb, projekt on veel üsna noor. Mõistame metsaraie vajalikkust. See on ka väga oluline teema. Ja see pole ilmselt vähem oluline kui jälgimine. Kuid kõigepealt oli rakendamise nimekirjas järelevalve. Toimub metsaraie. Loomulikult püüame automatiseerida klastri elu kõiki aspekte. Seega vastus on, et hetkel operaator kahjuks ei tea, kuidas seda teha, aga see on plaanis, teeme ära. Kui soovid liituda, siis tõmba palun taotlus.
Tere! Täname raporti eest! Mul on püsimahtudega seotud tavaküsimus. Kui loome selle operaatoriga konfiguratsiooni, siis kuidas operaator määrab, millisele sõlmele on konkreetne ketas või kaust lisatud? Kõigepealt peame talle selgitama, et palun asetage meie ClickHouse nendele sõlmedele, millel on ketas?
Minu arusaamist mööda on see küsimus kohaliku salvestusruumi, eriti selle hostPathi osa jätk. See on nagu kogu süsteemile selgitamine, et pod tuleb käivitada sellisel ja sellisel sõlmel, mille külge on meil füüsiliselt ühendatud ketas, mis on monteeritud mööda sellist ja sellist rada. See on terve osa, mida ma puudutasin väga pealiskaudselt, sest vastus on seal üsna suur.
Lühidalt näeb see välja selline. Loomulikult peame need mahud varustama. Hetkel pole kohalikus salvestusruumis dünaamilist sätet, seega peab DevOps ise kettad, need mahud, lõikama. Ja nad peavad selgitama Kubernetese pakkumist, et teil on sellise ja sellise klassi püsivad köited, mis asuvad sellistel ja sellistel sõlmedel. Seejärel peate Kubernetesile selgitama, et sellist ja sellist kohalikku salvestusklassi nõudvad kaustad tuleb siltide abil suunata ainult sellistesse ja sellistesse sõlmedesse. Nendel eesmärkidel saab operaator määrata teatud tüüpi sildi ja ühe hosti eksemplari kohta. Ja selgub, et Kubernetes suunab kaustasid nii, et need töötaksid ainult sõlmedes, mis vastavad lihtsas mõttes nõuetele, siltidele. Administraatorid määravad sildid ja sättekettad käsitsi. Ja siis see kaalub.
Ja see on kolmas võimalus, kohalik, mis aitab seda veidi lihtsamaks muuta. Nagu ma juba rõhutasin, on see hoolikas töö häälestamise kallal, mis lõppkokkuvõttes aitab saavutada maksimaalset jõudlust.
Mul on sellega seotud teine küsimus. Kubernetes loodi nii, et meie jaoks pole vahet, kas kaotame sõlme või mitte. Mida peaksime sel juhul tegema, kui oleme kaotanud sõlme, kus meie kild ripub?
Jah, Kubernetes oli algselt seisukohal, et meie suhe kaunadega on nagu veis, kuid siin saab igast kettast midagi lemmiklooma sarnast. On selline probleem, et me ei saa neid lihtsalt ära visata. Ja Kubernetese areng liigub selles suunas, et seda pole võimalik täielikult filosoofiliselt käsitleda, nagu oleks see täiesti kõrvale heidetud ressurss.
Nüüd praktiline küsimus. Mida teha, kui kaotasite sõlme, millel ketas oli? Siin lahendatakse probleem kõrgemal tasemel. ClickHouse’i puhul on meil koopiad, mis töötavad kõrgemal tasemel, st. ClickHouse'i tasemel.
Mis on sellest tulenev dispositsioon? DevOps vastutab selle eest, et andmed ei läheks kaduma. Ta peab replikatsiooni õigesti seadistama ja tagama, et replikatsioon töötab. ClickHouse'i taseme koopial peavad olema dubleeritud andmed. See ei ole ülesanne, mida operaator lahendab. Ja mitte probleem, mida Kubernetes ise lahendab. See on ClickHouse'i tasemel.
Mida teha, kui rauasõlm kukub ära? Ja selgub, et peate installima teise, varustama sellel oleva ketta ja kinnitama sildid. Ja pärast seda vastab see nõuetele, et Kubernetes saaks käivitada sellel eksemplaride paketi. Kubernetes käivitab selle. Teie kaunade arv ei ole määratud arvu saavutamiseks piisav. See läbib tsükli, mida näitasin. Ja kõige kõrgemal tasemel saab ClickHouse aru, et oleme sisestanud koopia, see on endiselt tühi ja peame hakkama sellele andmeid edastama. Need. See protsess ei ole veel hästi automatiseeritud.
Täname raporti eest! Kui juhtub igasuguseid ebameeldivaid asju, siis operaator jookseb kokku ja taaskäivitab ning sel hetkel saabuvad sündmused, kas te saate sellega kuidagi hakkama?
Mis juhtub, kui operaator jookseb kokku ja taaskäivitab, eks?
Jah. Ja sel hetkel saabusid sündmused.
Ülesanne, mida sel juhul teha, on osaliselt jagatud operaatori ja Kubernetese vahel. Kubernetesil on võimalus toimunud sündmust uuesti esitada. Ta mängib uuesti. Ja operaatori ülesanne on veenduda, et sündmuselogi taasesitamisel on need sündmused idempotentsed. Ja et sama sündmuse korduv esinemine meie süsteemi ei lõhuks. Ja meie operaator saab selle ülesandega hakkama.
Tere! Täname raporti eest! Dmitri Zavjalov, ettevõte Smedova. Kas operaatorile on plaanis lisada haproxyga konfigureerimise võimalus? Oleksin huvitatud mõnest muust tasakaalustajast peale standardse, et see oleks tark ja saaks aru, et ClickHouse on tõesti olemas.
Kas sa räägid Ingressist?
Jah, asendage Ingress haproxyga. Haproxys saate määrata selle klastri topoloogia, kus sellel on koopiad.
Me pole sellele veel mõelnud. Kui vajad ja oskad selgitada, miks seda vaja on, siis on võimalik seda ka ellu viia, eriti kui soovid osaleda. Kaalume seda võimalust hea meelega. Lühike vastus on ei, meil praegu sellist funktsiooni pole. Täname vihje eest, uurime seda asja. Ja kui selgitate ka kasutusjuhtu ja miks seda praktikas vaja on, näiteks GitHubis probleeme tekitate, siis on see suurepärane.
On juba.
Hästi. Oleme avatud kõikidele ettepanekutele. Ja haproxy lisatakse ülesandeloendisse. Todo nimekiri kasvab, mitte veel kahaneb. Kuid see on hea, see tähendab, et toode on nõutud.
Allikas: www.habr.com