It rapport is wijd oan praktyske problemen fan it ûntwikkeljen fan in operator yn Kubernetes, it ûntwerpen fan syn arsjitektuer en basisbestjoeringsprinsipes.
Yn it earste diel fan it rapport sille wy beskôgje:
- wat is in operator yn Kubernetes en wêrom is it nedich;
- hoe krekt de operator simplifies it behear fan komplekse systemen;
- wat de operator kin en net dwaan.
Litte wy dan fierder gean nei it besprekken fan 'e ynterne struktuer fan' e operator. Litte wy stap foar stap de arsjitektuer en wurking fan 'e operator sjen. Litte wy it yn detail besjen:
- ynteraksje tusken de operator en Kubernetes;
- hokker funksjes nimt de operator op en hokker funksjes it delegearret oan Kubernetes.
Litte wy sjen nei it behearen fan shards en database-replika's yn Kubernetes.
Folgjende sille wy problemen mei gegevensopslach besprekke:
- hoe te wurkjen mei Persistent Storage út in operator syn eachpunt;
- pitfalls fan it brûken fan Local Storage.
Yn it lêste diel fan it rapport sille wy praktyske foarbylden fan tapassing beskôgje mei Amazon of Google Cloud Service. It rapport is basearre op it foarbyld fan 'e ûntwikkeling en eksploitaasjeûnderfining fan in operator foar ClickHouse.
Video:
Myn namme is Vladislav Klimenko. Hjoed woe ik prate oer ús ûnderfining yn it ûntwikkeljen en betsjinjen fan in operator, en dit is in spesjalisearre operator foar it behearen fan databankklusters. Bygelyks om it ClickHouse-kluster te behearjen.
Wêrom hawwe wy de kâns om te praten oer de operator en ClickHouse?
- Wy stypje en ûntwikkelje ClickHouse.
- Op it stuit besykje wy stadichoan ús bydrage te leverjen oan 'e ûntwikkeling fan ClickHouse. En wy binne twadde nei Yandex yn termen fan it folume fan feroarings makke oan ClickHouse.
- Wy besykje ekstra projekten te dwaan foar it ClickHouse-ekosysteem.
Ik soe graach fertelle oer ien fan dizze projekten. Dit giet oer ClickHouse-operator foar Kubernetes.
Yn myn rapport wol ik twa ûnderwerpen oanroppe:
- It earste ûnderwerp is hoe't ús ClickHouse-databasebehearoperator wurket yn Kubernetes.
- It twadde ûnderwerp is hoe't elke operator wurket, dus hoe't it ynteraksje mei Kubernetes.
Dizze twa fragen sille lykwols troch myn heule rapport krúsje.
Wa soe ynteressearre wêze om te harkjen nei wat ik besykje te fertellen?
- It sil fan it measte belang wêze foar dyjingen dy't operators operearje.
- Of foar dyjingen dy't har eigen wolle meitsje om te begripen hoe't it yntern wurket, hoe't de operator ynteraksje mei Kubernetes, en hokker falkûlen kinne ferskine.
Om it bêste te begripen wat wy hjoed sille besprekke, is it in goed idee om te witten hoe't Kubernetes wurket en wat basale wolktraining hawwe.
Wat is ClickHouse? Dit is in kolomdatabase mei spesifike funksjes foar online ferwurking fan analytyske fragen. En it is folslein iepen boarne.
En it is wichtich foar ús om mar twa dingen te witten. Jo moatte witte dat dit in databank is, dus wat ik jo sil fertelle sil fan tapassing wêze op hast elke databank. En it feit dat de ClickHouse DBMS heul goed skaalt, jout hast lineêre skalberens. En dêrom is de klustersteat in natuerlike steat foar ClickHouse. En wy binne it meast ynteressearre yn besprekken hoe't jo it ClickHouse-kluster yn Kubernetes kinne tsjinje.
Wêrom is er dêr nedich? Wêrom kinne wy it sels net fierder betsjinje? En de antwurden binne foar in part technysk en foar in part organisatoarysk.
- Yn 'e praktyk komme wy hieltyd mear in situaasje tsjin wêr't yn grutte bedriuwen hast alle komponinten al yn Kubernetes binne. Databanken bliuwe bûten.
- En de fraach wurdt hieltyd mear steld: "Kin dit binnen pleatst wurde?" Dêrom besykje grutte bedriuwen maksimale ienwurding fan behear te berikken om har datapakhuzen fluch te kinnen beheare.
- En dit helpt benammen as jo de maksimale kâns nedich hawwe om itselde ding op in nij plak te werheljen, dus maksimale portabiliteit.
Hoe maklik of dreech is it? Dit kin fansels mei de hân. Mar it is net sa ienfâldich, om't wy de tafoege kompleksiteit hawwe fan it behearen fan Kubernetes sels, mar tagelyk binne de spesifiken fan ClickHouse boppe. En sa'n aggregaasje resultaat.
En alles byinoar jout dit in frij grutte set fan technologyen, dy't frijwat lestich wurdt om te behearjen, om't Kubernetes har eigen deistige problemen yn 'e operaasje bringt, en ClickHouse bringt har eigen problemen nei deistige operaasje. Benammen as wy hawwe ferskate ClickHouses, en wy moatte hieltyd dwaan wat mei harren.
Mei in dynamyske konfiguraasje hat ClickHouse in frij grut oantal problemen dy't in konstante lading meitsje op DevOps:
- As wy wat wolle feroarje yn ClickHouse, bygelyks in replika of shard tafoegje, dan moatte wy de konfiguraasje beheare.
- Feroarje dan it gegevensskema, om't ClickHouse in spesifike shardingmetoade hat. Dêr moatte jo it gegevensdiagram útlizze, de konfiguraasjes útlizze.
- Jo moatte tafersjoch ynstelle.
- It sammeljen fan logs foar nije shards, foar nije replika's.
- Soargje foar restauraasje.
- En opnij begjinne.
Dit binne routinetaken dy't ik wirklik makliker meitsje soe om te brûken.
Kubernetes sels helpt goed yn wurking, mar op basis systeem dingen.
Kubernetes is goed yn it fasilitearjen en automatisearjen fan dingen lykas:
- Herstel.
- Op 'e nij begjinne.
- Opslach systeem behear.
Dat is goed, dat is de goede rjochting, mar hy is folslein gjin idee oer hoe't jo in databankkluster operearje.
Wy wolle mear, wy wolle dat de hiele database wurket yn Kubernetes.
Ik wol graach wat krije as in grutte magyske reade knop dy't jo drukke en in kluster mei deistige taken dy't moatte wurde oplost wurdt ynset en ûnderhâlden yn syn hiele libbenssyklus. ClickHouse-kluster yn Kubernetes.
En wy besochten in oplossing te meitsjen dy't it wurk makliker meitsje soe. Dit is in ClickHouse-operator foar Kubernetes fan Altinity.
In operator is in programma waans haadtaak is om oare programma's te behearjen, d.w.s. it is in manager.
En it befettet gedrachspatroanen. Jo kinne dit kodifisearre kennis neame oer it fakgebiet.
En syn haadtaak is om it libben fan DevOps makliker te meitsjen en mikromanagement te ferminderjen, sadat hy (DevOps) al tinkt yn termen op hege nivo's, dat wol sizze dat hy (DevOps) net mei mikromanagement dwaande hâldt, sadat hy net konfigurearret alle details mei de hân.
En krekt de operator is in robotyske assistint dy't mei mikrotaken omgiet en DevOps helpt.
Wêrom hawwe jo in operator nedich? Hy prestearret benammen goed op twa gebieten:
- As de spesjalist dy't mei ClickHouse omgiet net genôch ûnderfining hat, mar al ClickHouse moat operearje, fasilitearret de operator de operaasje en lit jo in ClickHouse-kluster operearje mei in frij komplekse konfiguraasje, sûnder te folle detail te gean oer hoe't it allegear wurket binnenkant. Jo jouwe him gewoan taken op hege nivo, en it wurket.
- En de twadde taak wêryn it it bêste presteart is as it nedich is om in grut oantal typyske taken te automatisearjen. Ferwideret mikrotaken fan systeembehearders.
Dit is it meast nedich troch dyjingen dy't krekt har reis begjinne, of troch dyjingen dy't in protte automatisearring moatte dwaan.
Hoe ferskilt de operator-basearre oanpak fan oare systemen? Dêr is Helm. It helpt ek om ClickHouse te ynstallearjen; jo kinne helmdiagrammen tekenje, dy't sels in heule ClickHouse-kluster sille ynstallearje. Wat is dan it ferskil tusken de operator en deselde, bygelyks Helm?
It wichtichste fûnemintele ferskil is dat Helm pakketbehear is en Operator giet in stap fierder. Dit is stipe foar de hiele libbenssyklus. Dit is net allinich ynstallaasje, dit binne deistige taken dy't skaalfergrutting, sharding omfetsje, dus alles wat dien wurde moat yn 'e libbenssyklus (as nedich, dan ek wiskjen) - dit wurdt allegear besletten troch de operator. It besiket de heule softwarelibbenssyklus te automatisearjen en te ûnderhâlden. Dit is it fûnemintele ferskil fan oare oplossingen dy't wurde presintearre.
Dat wie it ynliedende diel, lit ús fierder gean.
Hoe bouwe wy ús operator? Wy besykje it probleem te benaderjen om it ClickHouse-kluster as ien boarne te behearjen.
Hjir hawwe wy ynfiergegevens oan 'e linkerkant fan' e foto. Dit is YAML mei in kluster spesifikaasje, dy't trochjûn wurdt oan Kubernetes op 'e klassike manier fia kubectl. Dêr hellet ús operator it op en docht syn magy. En by de útfier krije wy it folgjende skema. Dit is in ymplemintaasje fan ClickHouse yn Kubernetes.
En dan sille wy stadichoan sjen hoe't de operator krekt wurket, hokker typyske taken kinne wurde oplost. Wy sille allinich typyske taken beskôgje om't wy beheinde tiid hawwe. En net alles dat de operator kin beslute wurdt besprutsen.
Litte wy begjinne mei de praktyk. Us projekt is folslein iepen boarne, dus jo kinne sjen hoe't it wurket op GitHub. En jo kinne trochgean fan 'e oerwegingen dat as jo it gewoan wolle starte, dan kinne jo begjinne mei de Quick Start Guide.
As jo yn detail wolle begripe, dan besykje wy de dokumintaasje yn in min of mear fatsoenlike foarm te hâlden.
Litte wy begjinne mei in praktysk probleem. De earste taak, wêr't wy allegear wolle begjinne, is it earste foarbyld op ien of oare manier út te fieren. Hoe kin ik ClickHouse starte mei de operator, sels as ik net echt wit hoe't it wurket? Wy skriuwe in manifest, want... Alle kommunikaasje mei k8s is kommunikaasje fia manifesten.
Dit is sa'n kompleks manifest. Wat wy hawwe markearre yn read is wat wy moatte rjochtsje op. Wy freegje de operator om in kluster mei de namme demo te meitsjen.
Dit binne basisfoarbylden foar no. Opslach is noch net beskreaun, mar wy komme in bytsje letter werom nei opslach. Foar no sille wy de dynamyk fan 'e ûntwikkeling fan' e kluster observearje.
Wy hawwe dit manifest makke. Wy jouwe it oan ús operator. Hy wurke, hy makke magy.
Wy sjogge nei de konsole. Trije komponinten binne fan belang: in Pod, twa Tsjinsten, en in StatefulSet.
De operator hat wurke, en wy kinne sjen wat hy krekt makke.
Hy makket soksawat. Wy hawwe in StatefulSet, Pod, ConfigMap foar elke replika, ConfigMap foar it heule kluster. Tsjinsten binne ferplicht as yngongspunten yn it kluster.
Tsjinsten binne de sintrale Load Balancer Service en kinne ek brûkt wurde foar elke replika, foar elke shard.
Us basiskluster sjocht der sa út. It is fan ien inkelde knooppunt.
Litte wy fierder gean en dingen komplisearje. Wy moatte it kluster ferbrekke.
Us taken groeie, dynamyk begjint. Wy wolle in skerpe tafoegje. Wy folgje de ûntwikkeling. Wy feroarje ús spesifikaasje. Wy jouwe oan dat wy twa skuorren wolle.
Dit is itselde bestân dat dynamysk ûntwikkelet mei de groei fan it systeem. Opslach nee, opslach wurdt fierder besprutsen, dit is in apart ûnderwerp.
Wy fiede de YAML-operator en sjoch wat der bart.
De operator tocht en makke de folgjende entiteiten. Wy hawwe al twa Pods, trije Tsjinsten en, ynienen, 2 StatefulSets. Wêrom 2 StatefulSets?
Op it diagram wie it sa - dit is ús earste steat, doe't wy ien pod hienen.
It waard sa. Oant no ta is alles ienfâldich, it is duplikearre.
En wêrom binne der twa StatefulSets wurden? Hjir moatte wy de fraach ôfwike en besprekke hoe't Pods wurde beheard yn Kubernetes.
D'r is in objekt neamd StatefulSet wêrmei jo in set fan Pods kinne meitsje fan in sjabloan. De kaai faktor hjir is Template. En jo kinne in protte Pods starte mei ien sjabloan yn ien StatefulSet. En de kaaiwurd hjir is "in protte Pods foar ien sjabloan."
En d'r wie in grutte ferlieding om it heule kluster te meitsjen, it yn ien StatefulSet te ferpakken. It sil wurkje, d'r is gjin probleem mei. Mar der is ien caveat. As wy in heterogene kluster wolle gearstalle, dus út ferskate ferzjes fan ClickHouse, dan begjinne ús fragen. Ja, StatefulSet kin in rôljende update dwaan, en dêr kinne jo in nije ferzje útrolje, útlizze dat jo net mear moatte besykje as safolle knopen tagelyk.
Mar as wy de taak ekstrapolearje en sizze dat wy in folslein heterogene kluster wolle meitsje en wy wolle net feroarje fan 'e âlde ferzje nei in nije mei in rôljende update, mar wy wolle gewoan in heterogene kluster meitsje sawol yn termen fan ferskate ferzjes fan ClickHouse en yn termen fan ferskate opslach. Wy wolle bygelyks wat replika's meitsje op aparte skiven, op trage, yn 't algemien, om in heterogene kluster folslein te bouwen. En om't StatefulSet in standerdisearre oplossing makket fan ien sjabloan, is der gjin manier om dit te dwaan.
Nei wat tinken is besletten dat wy it sa dwaan soene. Wy hawwe elke replika yn syn eigen StatefulSet. D'r binne wat neidielen oan dizze oplossing, mar yn 'e praktyk is it allegear folslein ynkapsele troch de operator. En d'r binne in protte foardielen. Wy kinne de krekte kluster bouwe dy't wy wolle, bygelyks in absolút heterogene. Dêrom, yn in kluster wêryn wy hawwe twa shards mei ien replika, wy sille hawwe 2 StatefulSets en 2 Pods krekt omdat wy keas dizze oanpak foar de redenen neamd hjirboppe te kinnen bouwe in heterogene kluster.
Litte wy weromgean nei praktyske problemen. Yn ús kluster moatte wy brûkers konfigurearje, d.w.s. jo moatte wat konfiguraasje fan ClickHouse yn Kubernetes dwaan. De operator jout dêr alle mooglikheden foar.
Wy kinne skriuwe wat wy wolle direkt yn YAML. Alle konfiguraasjeopsjes wurde direkt fan dizze YAML yn kaart brocht yn ClickHouse-konfiguraasjes, dy't dan wurde ferspraat oer it kluster.
Jo kinne it sa skriuwe. Dit is bygelyks. It wachtwurd kin fersifere wurde. Absolút alle ClickHouse-konfiguraasjeopsjes wurde stipe. Hjir is mar in foarbyld.
De klusterkonfiguraasje wurdt ferspraat as in ConfigMap. Yn 'e praktyk komt de ConfigMap-fernijing net direkt foar, dus as it kluster grut is, dan nimt it proses fan it drukken fan de konfiguraasje wat tiid. Mar dit alles is heul handich om te brûken.
Litte wy de taak komplisearje. It kluster is yn ûntwikkeling. Wy wolle gegevens replikearje. Dat is, wy hawwe al twa shards, elk ien replika, en brûkers binne konfigureare. Wy groeie en wolle replikaasje dwaan.
Wat hawwe wy nedich foar replikaasje?
Wy hawwe ZooKeeper nedich. Yn ClickHouse wurdt replikaasje boud mei ZooKeeper. ZooKeeper is nedich sadat ferskate ClickHouse-replika's in konsensus hawwe oer hokker gegevensblokken op hokker ClickHouse binne.
ZooKeeper kin troch elkenien brûkt wurde. As it bedriuw in eksterne ZooKeeper hat, dan kin it brûkt wurde. As net, kinne jo it ynstallearje fanút ús repository. D'r is in ynstallearder dy't dit alles makliker makket.
En it ynteraksjediagram fan it heule systeem komt sa út. Wy hawwe Kubernetes as platfoarm. It útfiert de ClickHouse-operator. Ik haw hjir ZooKeeper ôfbylde. En de operator ynteraksje mei sawol ClickHouse as ZooKeeper. Dat is, ynteraksje resultaten.
En dit alles is nedich foar ClickHouse om gegevens mei súkses te replikearjen yn k8s.
Litte wy no sjen nei de taak sels, nei hoe't it manifest foar replikaasje der útsjen sil.
Wy foegje twa seksjes ta oan ús manifest. De earste is wêr't ZooKeeper te krijen is, dy't sawol binnen Kubernetes as ekstern kin wêze. Dit is mar in beskriuwing. En wy bestelle replika's. Dy. wy wolle twa replika's. Yn totaal moatte wy 4 pods hawwe by de útfier. Wy ûnthâlde oer opslach, it komt in bytsje letter werom. Opslach is in apart ferhaal.
It wie sa.
It wurdt sa. Replika's wurde tafoege. De 4e paste net, wy leauwe dat dêr in protte fan wêze kinne. En ZooKeeper wurdt tafoege oan 'e kant. De regelingen wurde komplekser.
En it is tiid om de folgjende taak ta te foegjen. Wy sille Persistent Storage tafoegje.
Foar persistente opslach hawwe wy ferskate opsjes.
As wy yn in wolkprovider rinne, bygelyks Amazon, Google brûke, dan is d'r in grutte ferlieding om wolkopslach te brûken. It is hiel handich, it is goed.
En der is in twadde opsje. Dit is foar lokale opslach, as wy lokale skiven hawwe op elke knooppunt. Dizze opsje is folle dreger om te fieren, mar tagelyk is it produktiver.
Litte wy sjen wat wy hawwe oangeande wolk opslach.
Der binne foardielen. It is heul maklik te konfigurearjen. Wy bestelle gewoan fan 'e wolkprovider dy't ús asjebleaft opslach jouwe fan sa en sa kapasiteit, fan sa en sa klasse. Klassen wurde pland troch providers ûnôfhinklik.
En der is in nadeel. Foar guon is dit in net-kritysk nadeel. Fansels sille d'r wat prestaasjesproblemen wêze. It is heul handich om te brûken en betrouber, mar d'r binne wat potinsjele prestaasjes neidielen.
En omdat ClickHouse rjochtet him spesifyk op produktiviteit, men soe sels sizze kinne dat it alles útdrukt wat it kin, dat is wêrom in protte kliïnten besykje maksimale produktiviteit út te drukken.
En om der it measte út te heljen, hawwe wy lokale opslach nedich.
Kubernetes leveret trije abstraksjes foar it brûken fan lokale opslach yn Kubernetes. Dit:
- EmptyDir
- HostPath.
- Pleatslik
Litte wy sjen hoe't se ferskille en hoe't se fergelykber binne.
As earste, yn alle trije oanpak hawwe wy opslach - dit binne lokale skiven dy't lizze op deselde fysike k8s-knooppunt. Mar se hawwe wat ferskillen.
Litte wy begjinne mei de ienfâldichste, dus leechDir. Wat is dit yn 'e praktyk? Yn ús spesifikaasje freegje wy it containerisaasjesysteem (meastentiids Docker) om ús tagong te jaan ta in map op 'e lokale skiif.
Yn 'e praktyk makket Docker in tydlike map earne lâns syn eigen paden en neamt it in lange hash. En biedt in ynterface om tagong te krijen.
Hoe sil dit prestaasje-wize wurkje? Dit sil wurkje op lokale skiif snelheid, i.e. Dit is folsleine tagong ta jo skroef.
Mar dit gefal hat syn nadeel. Persistent is frij twifelich yn dizze saak. De earste kear dat Docker beweecht mei konteners, is Persistent ferlern. As Kubernetes dizze Pod om ien of oare reden nei in oare skiif ferpleatse wol, sille de gegevens ferlern gean.
Dizze oanpak is goed foar testen, om't it al normale snelheid toant, mar foar wat serieus is dizze opsje net geskikt.
Dêrom is der in twadde oanpak. Dit is hostPath. As jo nei de foarige dia en dizze sjogge, kinne jo mar ien ferskil sjen. Us map ferhuze fan Docker direkt nei it Kubernetes-knooppunt. It is hjir wat ienfâldiger. Wy spesifisearje direkt it paad op it lokale bestânsysteem wêr't wy ús gegevens wolle opslaan.
Dizze metoade hat foardielen. Dit is al in echte Persistent, en dêrby in klassiker. Wy sille hawwe gegevens opnommen op de skiif op guon adres.
Der binne ek neidielen. Dit is de kompleksiteit fan behear. Us Kubernetes wolle miskien de Pod nei in oare fysike knooppunt ferpleatse. En dit is wêr't DevOps yn spiel komt. Hy moat it hiele systeem korrekt útlizze dat dizze pods allinich kinne wurde ferpleatst nei dy knooppunten wêrop jo wat op dizze paden hawwe monteard, en net mear as ien knooppunt tagelyk. It is nochal dreech.
Spesjaal foar dizze doelen makken wy sjabloanen yn ús operator om al dizze kompleksiteit te ferbergjen. En jo kinne gewoan sizze: "Ik wol ien eksimplaar fan ClickHouse hawwe foar elke fysike knooppunt en lâns sa'n en sa'n paad."
Mar wy binne net de iennigen dy't dizze need nedich hawwe, dus de hearen fan Kubernetes sels begripe ek dat minsken tagong hawwe ta fysike skiven, sadat se in tredde laach leverje.
It hjit lokaal. D'r is praktysk gjin ferskil mei de foarige slide. Allinich foardat it wie nedich om mei de hân te befêstigjen dat wy dizze pods net kinne oerdrage fan knooppunt nei knooppunt, om't se op ien of oare manier moatte wurde hechte oan in lokale fysike skiif, mar no is al dizze kennis ynkapsele yn Kubernetes sels. En it docht bliken folle makliker te konfigurearjen.
Lit ús weromgean nei ús praktyske probleem. Litte wy weromgean nei it YAML-sjabloan. Hjir hawwe wy echte opslach. Wy binne der wer by. Wy sette it klassike VolumeClaim-sjabloan as yn k8s. En wy beskriuwe hokker soarte fan opslach wy wolle.
Hjirnei sil k8s opslach freegje. Sil it oan ús tawize yn 'e StatefulSet. En op it lêst sil it ta de beskikking wêze fan ClickHouse.
Wy hiene dit skema. Us Persistent Storage wie read, wat like te hingjen dat it dien wurde moast.
En it wurdt grien. No is it ClickHouse op k8s-klusterskema folslein finalisearre. Wy hawwe shards, replika's, ZooKeeper, wy hawwe in echte Persistent, dy't op ien of oare manier útfierd wurdt. De regeling is al folslein operasjoneel.
Wy libje fierder. Us kluster is yn ûntwikkeling. En Alexey besiket, en jout in nije ferzje fan ClickHouse út.
In praktyske taak ûntstiet - de nije ferzje fan ClickHouse te testen op ús kluster. En, fansels, jo wolle it net allegear útrôlje; jo wolle in nije ferzje yn ien replika earne yn 'e fierste hoeke sette, en miskien net ien nije ferzje, mar twa tagelyk, om't se faak útkomme.
Wat kinne wy sizze oer dit?
Hjir hawwe wy krekt sa'n kâns. Dit binne pod-sjabloanen. Jo kinne skriuwe dat ús operator jo folslein in heterogene kluster kinne bouwe. Dy. konfigurearje, begjinnend fan alle replika's yn in bosk, einigje mei elke persoanlike replika, hokker ferzje wy wolle ClickHouse, hokker ferzje wy wolle opslach. Wy kinne it kluster folslein konfigurearje mei de konfiguraasje dy't wy nedich binne.
Litte wy wat djipper nei binnen gean. Dêrfoar hawwe wy praat oer hoe't ClickHouse-operator wurket yn relaasje ta de spesifiken fan ClickHouse.
No soe ik graach sizze in pear wurden oer hoe't eltse operator wurket yn it algemien, likegoed as hoe't it ynteraksje mei K8s.
Litte wy earst sjen nei ynteraksje mei de K8's. Wat bart der as wy kubectl oanfreegje? Us objekten ferskine yn etcd fia de API.
Bygelyks, basis Kubernetes-objekten: pod, StatefulSet, tsjinst, ensfh.
Tagelyk bart der noch neat fysyks. Dizze objekten moatte materialisearre wurde yn it kluster.
Foar dit doel ferskynt in kontrôler. De controller is in spesjale k8s komponint dat kin materialisearje dizze beskriuwingen. Hy wit hoe en wat te dwaan fysyk. Hy wit hoe't er konteners útfiere moat, wat dêr konfigurearre wurde moat om de tsjinner te wurkjen.
En it materialisearret ús objekten yn K8s.
Mar wy wolle net allinich operearje mei pods en StatefulSets, wy wolle in ClickHouse-ynstallaasje meitsje, dus in objekt fan it ClickHouse-type, om dêrmei as ien gehiel te operearjen. Sa'n mooglikheid is oant no ta net.
Mar K8s hat de folgjende moaie ding. Wy wolle dat wy earne hawwe lykas dizze komplekse entiteit wêryn ús kluster soe wurde gearstald út pods en StatefulSet.
En wat moat dêrfoar dien wurde? Earst komt Custom Resource Definition yn 'e foto. Wat is it? Dit is in beskriuwing foar K8s, dat jo sille hawwe ien mear gegevens type, dat wy wolle tafoegje in oanpaste boarne oan de pod, StatefulSet, dat sil wêze kompleks binnen. Dit is in beskriuwing fan 'e gegevensstruktuer.
Wy stjoere it dêr ek fia kubectl apply. Kubernetes naam it lokkich.
En no yn ús opslach hat it objekt yn etcd de kâns om in oanpaste boarne op te nimmen mei de namme ClickHouseInstallation.
Mar foarearst sil der neat mear barre. Dat is, as wy no it YAML-bestân oanmeitsje wêr't wy nei sjoen hawwe mei it beskriuwen fan shards en replika's en sizze "kubectl jilde," dan sil Kubernetes it akseptearje, it yn etcd pleatse en sizze: "Geweldich, mar ik wit net wat te dwaan mei. Ik wit net hoe't ik ClickHouseInstallation moat ûnderhâlde. ”
Dêrom hawwe wy ien nedich om Kubernetes te helpen it nije gegevenstype te tsjinjen. Links hawwe wy in native Kubernetes-controller dy't wurket mei native gegevenstypen. En rjochts moatte wy in oanpaste controller hawwe dy't kin wurkje mei oanpaste gegevenstypen.
En op in oare manier wurdt it in operator neamd. Ik spesifyk opnommen it hjir as Kubernetes, omdat it kin ek útfierd wurde bûten K8s. Meastentiids wurde fansels alle operators útfierd yn Kubernetes, mar neat hinderet it bûten te stean, dus hjir wurdt it spesjaal nei bûten ferpleatst.
En op syn beurt, de oanpaste controller, ek wol bekend as de operator, ynteraksje mei Kubernetes fia de API. It wit al hoe te ynteraksje mei de API. En hy wit al hoe't it komplekse circuit dat wy wolle meitsje fan in oanpaste boarne materialisearje. Dit is krekt wat de operator docht.
Hoe wurket de operator? Litte wy nei de rjochterkant sjen hoe't hy it docht. Litte wy útfine hoe't de operator dit alles realisearret en hoe't fierdere ynteraksje mei K8s komt.
In operator is in programma. Se is evenemint-rjochte. De operator abonnearret op eveneminten mei de Kubernetes API. De Kubernetes API hat yngongspunten wêr't jo kinne abonnearje op eveneminten. En as der wat feroaret yn K8's, dan stjoert Kubernetes eveneminten nei elkenien, d.w.s. wa't him ynskreaun hat op dit API-punt sil notifikaasjes krije.
De operator abonnearret op eveneminten en moat in soarte fan reaksje meitsje. Syn taak is om te reagearjen op opkommende eveneminten.
Eveneminten wurde generearre troch bepaalde updates. Us YAML-bestân mei in beskriuwing fan ClickHouseInstallation komt oan. Hy gie nei etcd troch kubectl oanfreegje. In barren waard dêr trigger, en as gefolch kaam dit barren nei de ClickHouse-operator. De operator krige dizze beskriuwing. En hy moat wat dwaan. As der in update is oankaam foar it ClickHouseInstallation-objekt, dan moatte jo it kluster bywurkje. En de taak fan de operator is om it kluster te aktualisearjen.
Wat docht hy? Earst moatte wy in aksjeplan opstelle foar wat wy mei dizze fernijing sille dwaan. Updates kinne hiel lyts wêze, d.w.s. lyts yn YAML útfiering, mar kin entail hiel grutte feroarings op it kluster. Dêrom makket de operator in plan, en dan hâldt er him oan.
Neffens dit plan begjint hy dizze struktuer binnen te koken om pods, tsjinsten, d.w.s. dwaan wat syn haadtaak is. Dit is hoe't jo in ClickHouse-kluster bouwe yn Kubernetes.
No litte wy sa'n nijsgjirrich ding oanreitsje. Dit is in ferdieling fan ferantwurdlikens tusken Kubernetes en de operator, d.w.s. wat Kubernetes docht, wat de operator docht, en hoe't se ynteraksje mei elkoar.
Kubernetes is ferantwurdlik foar systeem dingen, d.w.s. foar in basis set fan objekten dy't kin wurde ynterpretearre as systeem-omfang. Kubernetes wit hoe't jo pods starte, hoe't konteners opnij starte, hoe't jo folumes kinne mount, hoe't jo wurkje mei ConfigMap, d.w.s. alles wat in systeem neamd wurde kin.
Operators wurkje yn domeinen. Elke operator is makke foar syn eigen fakgebiet. Wy diene it foar ClickHouse.
En de operator ynteraktearret krekt yn termen fan it ûnderwerpgebiet, lykas it tafoegjen fan in replika, it meitsjen fan in diagram, it ynstellen fan tafersjoch. Dit resultearret yn in ferdieling.
Litte wy nei in praktysk foarbyld sjen hoe't dizze ferdieling fan ferantwurdlikens foarkomt as wy de replika-aksje tafoegje.
De operator krijt in taak - in replika ta te foegjen. Wat docht de operator? De operator sil berekkenje dat in nije StatefulSet moat wurde oanmakke, dêr't sokke en sokke sjabloanen, folume claim, moatte wurde beskreaun.
Hy hat it allegear klearmakke en jout it troch oan K8s. Hy seit dat hy ConfigMap, StatefulSet, Volume nedich is. Kubernetes wurket. Hy materialisearret de basisienheden dêr't er mei operearret.
En dan komt ClickHouse-operator wer yn it spul. Hy hat al in fysike pod dêr't er al wat op kin. En ClickHouse-operator wurket wer yn domeintermen. Dy. Spesifyk ClickHouse, om in replika yn in kluster op te nimmen, moatte jo earst it gegevensskema konfigurearje dat yn dit kluster bestiet. En, twadde, dizze replika moat wurde opnommen yn 'e monitoaring, sadat it dúdlik traceare wurde kin. De operator konfigurearret dit al.
En pas dêrnei komt ClickHouse sels yn it spul, d.w.s. in oare heger nivo entiteit. Dit is al in databank. It hat in eigen eksimplaar, in oare konfigureare replika dy't klear is om mei te dwaan oan it kluster.
It docht bliken dat in keatling fan útfiering en ferdieling fan ferantwurdlikens by it tafoegjen fan in replika frij lang is.
Wy geane troch mei ús praktyske taken. As jo al in kluster hawwe, kinne jo de konfiguraasje migrearje.
Wy hawwe it sa makke dat jo besteande xml kinne plakke, wat ClickHouse begrypt.
Jo kinne ClickHouse fine-tune. Krekt sône ynset is wêr't ik oer praat doe't ik hostPath, lokale opslach, útlis. Dit is hoe't bestimmings ynset goed te dwaan.
De folgjende praktyske taak is tafersjoch.
As ús kluster feroaret, dan moatte wy periodyk tafersjoch konfigurearje.
Litte wy nei it diagram sjen. Wy hawwe hjir al nei de griene pylken sjoen. Litte wy no nei de reade pylken sjen. Sa wolle wy ús kluster kontrolearje. Hoe metriken fan it ClickHouse-kluster yn Prometheus komme, en dan yn Grafana.
Wat is de muoite mei tafersjoch? Wêrom wurdt dit presintearre as in soarte fan prestaasje? De muoite leit yn de dynamyk. As wy ien kluster hawwe en it is statysk, kinne wy ienris tafersjoch ynstelle en net mear lestich falle.
Mar as wy in protte klusters hawwe, of wat hieltyd feroaret, dan is it proses dynamysk. En hieltyd opnij konfigurearjen fan tafersjoch is in fergriemerij fan middels en tiid, d.w.s. sels gewoan luiheid. Dit moat automatisearre wurde. De muoite leit yn 'e dynamyk fan it proses. En de operator automatisearret dit hiel goed.
Hoe hat ús kluster ûntwikkele? Yn it begjin wie er sa.
Doe wie er sa.
Op it lêst waard er sa.
En tafersjoch wurdt automatysk dien troch de operator. Single punt fan yngong.
En krekt by de útgong sjogge wy nei it Grafana-dashboard om te sjen hoe't it libben fan ús kluster fan binnen siet.
Trouwens, Grafana dashboard wurdt ek ferspraat mei ús operator direkt yn 'e boarne koade. Jo kinne ferbine en brûke. Us DevOps joech my dit skermôfbylding.
Wêr wolle wy de folgjende hinne? Dit:
- Untwikkelje testautomatisearring. De wichtichste taak is automatysk testen fan nije ferzjes.
- Wy wolle ek echt de yntegraasje mei ZooKeeper automatisearje. En d'r binne plannen om te yntegrearjen mei ZooKeeper-operator. Dy. In operator is skreaun foar ZooKeeper en it is logysk dat de twa operators begjinne te yntegrearjen om in handiger oplossing te bouwen.
- Wy wolle mear komplekse fitale tekens dwaan.
- Ik markearre yn grien dat wy benaderje erfenis fan Templates - DONE, d.w.s. mei de folgjende release fan de operator wy sille al hawwe erfenis fan sjabloanen. Dit is in krêftich ark wêrmei jo komplekse konfiguraasjes kinne bouwe fan stikken.
- En wy wolle automatisearring fan komplekse taken. De wichtichste is Re-sharding.
Litte wy wat tuskenresultaten nimme.
Wat krije wy as gefolch? En is it wurdich dwaan of net? Is it sels nedich om te besykjen om de databank yn Kubernetes te slepen en de operator yn it algemien en de Alitnity-operator yn it bysûnder te brûken?
By de útfier krije wy:
- Wichtige ferienfâldiging en automatisearring fan konfiguraasje, ynset en ûnderhâld.
- Fuortendaliks ynboude monitoring.
- En klear te brûken kodifisearre sjabloanen foar komplekse situaasjes. In aksje lykas it tafoegjen fan in replika hoecht net mei de hân te dien wurde. De operator docht dit.
Der is mar ien lêste fraach oer. Wy hawwe al in database yn Kubernetes, virtualisaasje. Hoe sit it mei de prestaasjes fan sa'n oplossing, foaral om't ClickHouse is optimalisearre foar prestaasjes?
It antwurd is alles is goed! Ik sil net yn detail gean; dit is it ûnderwerp fan in apart rapport.
Mar der is sa'n projekt as TSBS. Wat is har haadtaak? Dit is in databankprestaasjetest. Dit is in besykjen om waarm te fergelykjen mei waarm, sêft mei sêft.
Hoe wurket hy? Ien dataset wurdt generearre. Dan wurdt dizze set gegevens útfierd op ferskate databases mei deselde set tests. En elke databank lost ien probleem op op 'e manier wêrop it wit hoe. En dan kinne jo de resultaten fergelykje.
It stipet al in grutte boskje databases. Ik haw trije wichtichste identifisearre. Dit:
- Timescale DB.
- InfluxDB.
- ClickHouse.
In ferliking waard ek makke mei in oare ferlykbere oplossing. Ferliking mei RedShift. Fergeliking waard makke op Amazon. ClickHouse is ek goed foar elkenien yn dizze saak.
Hokker konklúzjes kinne wurde lutsen út wat ik sei?
- DB yn Kubernetes is mooglik. Wierskynlik is elk mooglik, mar oer it algemien liket it mooglik. ClickHouse yn Kubernetes is perfoarst mooglik mei help fan ús operator.
- De operator helpt om prosessen te automatisearjen en makket it libben echt makliker.
- Prestaasje is normaal.
- En it liket ús dat dit kin en moat wurde brûkt.
Iepen boarne - doch mei!
Lykas ik al sei, is de operator in folslein iepen boarneprodukt, dus it soe heul goed wêze as it maksimale oantal minsken it brûkte. Kom by ûs! Wy wachtsje op jim allegearre!
Tige tank allegear!
Jo fragen
Tank foar it ferslach! Myn namme is Anton. Ik kom fan SEMrush. Ik freegje my ôf wat der oan de hân is mei logging. Wy hearre oer monitoring, mar neat oer logging, as wy it oer it hiele kluster hawwe. Wy hawwe bygelyks in kluster op hardware opbrocht. En wy brûke sintralisearre logging, sammelje se yn in mienskiplike heap mei standert middels. En dan krije wy de gegevens dy't ús ynteressearje.
Goede fraach, d.w.s. ynlogge op in todo list. Us operator automatisearret dit noch net. It is noch yn ûntwikkeling, it projekt is noch frij jong. Wy begripe de needsaak foar logging. Dit is ek in tige wichtich ûnderwerp. En it is wierskynlik net minder wichtich as tafersjoch. Mar earst op 'e list foar ymplemintaasje wie tafersjoch. Der sil oanmeld wurde. Fansels besykje wy alle aspekten fan it libben fan it kluster te automatisearjen. Dêrom is it antwurd dat op it stuit de operator, spitigernôch, net wit hoe dit te dwaan, mar it is yn 'e plannen, wy sille it dwaan. As jo meidwaan wolle, lûk dan fersyk, asjebleaft.
Hallo! Tank foar it ferslach! Ik haw in standert fraach yn ferbân mei Persistent Volumes. As wy meitsje in konfiguraasje mei dizze operator, hoe bepaalt de operator op hokker node wy hawwe in bepaalde skiif of map taheakke? Wy moatte him earst útlizze dat asjebleaft ús ClickHouse pleatse op dizze knopen dy't in skiif hawwe?
Foar safier't ik begryp, is dizze fraach in fuortsetting fan lokale opslach, benammen it hostPath-diel dêrfan. Dit is as om it hiele systeem út te lizzen dat de pod op sa'n en sa'n knooppunt lansearre wurde moat, dêr't wy in fysyk ferbûn skiif oan hawwe, dy't op sa'n en sa'n paad fêstmakke is. Dit is in hiele paragraaf dy't ik tige oerflakkich oanrekke omdat it antwurd dêr frij grut is.
Koartsein sjocht it der sa út. Fansels moatte wy dizze voluminten leverje. Op it stuit is d'r gjin dynamyske foarsjenning yn lokale opslach, dus DevOps moat de skiven sels snije, dizze folumes. En se moatte útlizze Kubernetes foarsjenning dat jo sille hawwe Persistente folumes fan sokke en sokke klasse, dy't lizze op sokke en sokke knopen. Dan moatte jo Kubernetes útlizze dat pods dy't sa'n en sa'n lokale opslachklasse fereaskje, allinich moatte wurde rjochte op sokke en sokke knooppunten mei labels. Foar dizze doelen hat de operator de mooglikheid om in soarte fan label te jaan en ien per hosteksimplaar. En it docht bliken dat pods sille wurde trochstjoerd troch Kubernetes om allinich te rinnen op knopen dy't foldogge oan de easken, labels, yn ienfâldige termen. Behearders jouwe labels en foarsjenningsskiven manuell ta. En dan slacht it op.
En it is de tredde opsje, lokaal, dat helpt om dit in bytsje makliker te meitsjen. Lykas ik al haw beklamme, is dit mjitten wurk op tuning, dy't úteinlik helpt om maksimale prestaasjes te krijen.
Ik haw in twadde fraach yn ferbân mei dit. Kubernetes is op sa'n manier ûntwurpen dat it ús net makket oft wy in knooppunt ferlieze of net. Wat moatte wy dwaan yn dit gefal as wy hawwe ferlern de knooppunt dêr't ús shard hinget?
Ja, Kubernetes waard ynearsten gepositioneerd dat ús relaasje mei ús pods is as fee, mar hjir by ús wurdt elke skiif wat as in húsdier. D'r is sa'n probleem dat wy se net gewoan fuortsmite kinne. En de ûntwikkeling fan Kubernetes giet yn 'e rjochting dat it ûnmooglik is om it folslein filosofysk te behanneljen, as wie it in folslein ferwidere boarne.
No foar in praktyske fraach. Wat te dwaan as jo it knooppunt ferlern hawwe wêrop de skiif wie? Hjir wurdt it probleem op in heger nivo oplost. Yn it gefal fan ClickHouse hawwe wy replika's dy't wurkje op in heger nivo, d.w.s. op it ClickHouse-nivo.
Wat is de resultearjende disposysje? DevOps is ferantwurdlik foar it garandearjen dat gegevens net ferlern gean. Hy moat replikaasje korrekt ynstelle en moat soargje dat replikaasje rint. De replika op it ClickHouse-nivo moat duplikearre gegevens hawwe. Dit is net it probleem dat de operator oplost. En net it probleem dat Kubernetes sels oplost. Dit is op it ClickHouse-nivo.
Wat te dwaan as jo izeren knooppunt falt? En it docht bliken dat jo in twadde moatte ynstallearje, de skiif derop goed foarstelle en labels tapasse. En dêrnei sil it foldwaan oan de easken dat Kubernetes der in eksimplaarpod op kin lansearje. Kubernetes sil it lansearje. Jo oantal pods is net genôch om te foldwaan oan it opjûne oantal. It sil gean troch de syklus dy't ik liet sjen. En op it heechste nivo sil ClickHouse begripe dat wy in replika hawwe ynfierd, it is noch leech en wy moatte begjinne mei it oerdragen fan gegevens nei it. Dy. Dit proses is noch net goed automatisearre.
Tank foar it ferslach! As allerhanne ferfelende dingen bart, crasht de operator en start op 'e nij, en op dat stuit komme eveneminten, dogge jo dit op ien of oare manier?
Wat bart der as de operator ferûngelokke en opnij starte, krekt?
Ja. En op dat stuit kamen eveneminten oan.
De taak fan wat te dwaan yn dit gefal wurdt foar in part dield tusken de operator en Kubernetes. Kubernetes hat de mooglikheid om in evenemint dat bard is wer te spyljen. Hy replays. En de taak fan 'e operator is om te soargjen dat wannear't it evenemintelog op him wurdt werhelle, dizze eveneminten idempotent binne. En sadat it werhelle foarkommen fan itselde barren ús systeem net brekt. En ús operator omgaat mei dizze taak.
Hallo! Tank foar it ferslach! Dmitry Zavyalov, bedriuw Smedova. Binne d'r plannen om de mooglikheid om te konfigurearjen mei haproxy oan 'e operator ta te foegjen? Ik soe ynteressearre wêze yn in oare balancer neist de standert, sadat it tûk is en begrypt dat ClickHouse der echt is.
Hawwe jo it oer Ingress?
Ja, ferfange Ingress mei haproxy. Yn haproxy kinne jo de topology fan it kluster opjaan wêr't it replika's hat.
Wy ha der noch net oer neitocht. As jo it nedich hawwe en kinne útlizze wêrom't it nedich is, dan sil it mooglik wêze om it út te fieren, benammen as jo meidwaan wolle. Wy sille graach beskôgje de opsje. It koarte antwurd is nee, wy hawwe op it stuit net sa'n funksjonaliteit. Tank foar de tip, wy sille dizze saak besjen. En as jo ek it gebrûksgefal útlizze en wêrom't it yn 'e praktyk nedich is, bygelyks problemen meitsje op GitHub, dan sil dat geweldich wêze.
Hat al.
Moai. Wy steane iepen foar alle suggestjes. En haproxy wurdt tafoege oan de todo list. De todo-list groeit, krimp noch net. Mar dit is goed, it betsjut dat it produkt yn fraach is.
Boarne: www.habr.com