Lokaalne<\/li>\n<\/ul>\n<\/p>\n
Vaadake, millised on nende erinevused ja sarnasused. <\/p>\n
<\/p>\n
Esiteks, k\u00f5ikides kolmes l\u00e4henemisviisis on storage \u2013 lokaalsed kettad, mis asuvad samal f\u00fc\u00fcsilisel k8s node'il. Kuid neil on m\u00f5ned erinevused.<\/p>\n
<\/p>\n
<\/p>\n
Alustame k\u00f5ige lihtsamast, st emptyDir-st. Mis see praktikas t\u00e4hendab? Me palume oma spetsifikatsioonis konteinerite s\u00fcsteemil (enamasti on see Docker) anda meile juurdep\u00e4\u00e4s kaustale lokaalsel kettal.<\/p>\n
<\/p>\n
Tavaselt loob Docker kusagil oma teedel ajutise kausta, nimetab selle pikaks hash'iks ja pakub p\u00e4\u00e4sumehhanismi sellele. <\/p>\n
<\/p>\n
Kuidas see j\u00f5udluses t\u00f6\u00f6tab? See t\u00f6\u00f6tab lokaalse ketta kiirusel, st see on t\u00e4ies ulatuses juurdep\u00e4\u00e4s oma draivile. <\/p>\n
<\/p>\n
Kuid sellel meetodil on oma puudus. Persistent on selles osas piisavalt kahtlane. Vahetult Dockeriga konteinerite liikumisel kaob Persistent \u00e4ra. Kui Kubernetes mingil p\u00f5hjusel soovib selle Pod'i teisaldada teisele kettale, siis andmed kaovad. <\/p>\n
<\/p>\n
Selline l\u00e4henemine sobib h\u00e4sti katsetamiseks, kuna see n\u00e4itab normaalset kiirusnat, kuid t\u00f5siste \u00fclesannete jaoks ei sobi see variant. <\/p>\n
<\/p>\n
<\/p>\n
Seet\u00f5ttu on olemas teine l\u00e4henemine. See on hostPath. Kui vaadata eelmist slaidi ja seda, siis v\u00f5ib n\u00e4ha ainult \u00fchte erinevust. Meie kaust on v\u00e4lja viidud Dockerist otse Kubernetes'i s\u00f5lme. Siin on natuke lihtsam. Me m\u00e4\u00e4rame otse kohaliku failis\u00fcsteemi tee, kus soovime andmeid hoida. <\/p>\n
<\/p>\n
Selle meetodi eelised on olemas. See on juba t\u00f5eline Persistent, ja traditsiooniline. Meie kettale salvestatakse andmed kindlasse aadressi. <\/p>\n
<\/p>\n
Kuna ka puudusi. \u00dcks neist on haldamise keerukus. Meie Kubernetes v\u00f5ib soovida liigutada Pod'i teisele f\u00fc\u00fcsilisele s\u00f5lmele. Siin tuleb m\u00e4ngu DevOps, kes peab \u00f5igesti seletama kogu s\u00fcsteemile, et neid pod'e tohib liigutada ainult sellistele s\u00f5lmedele, kus sul on nende teede kaudu midagi \u00fchendatud, ja mitte rohkem kui \u00fchte s\u00f5lme korraga. See on piisavalt keeruline. <\/p>\n
<\/p>\n
Just nende eesm\u00e4rkide tarbeks oleme meie operaatoris loonud mallid, et kogu see keerukus peita. Nii saab lihtsalt \u00f6elda: \u201eMa tahan, et mul oleks iga f\u00fc\u00fcsilise s\u00f5lme kohta \u00fcks ClickHouse'i instance ja sellisel teel.\u201d <\/p>\n
<\/p>\n
<\/p>\n
Kuid see vajadus on vajalik mitte ainult meile, mist\u00f5ttu Kubernetes'i h\u00e4rrased m\u00f5istavad ka, et inimestele meeldib juurdep\u00e4\u00e4s f\u00fc\u00fcsilistele kettale, ja pakuvad seet\u00f5ttu kolmandat taset.<\/p>\n
<\/p>\n
See nimetatakse local. Erinevused eelmisest slaidist on praktiliselt olematud. Ainult et varem pidime k\u00e4sitsi vasestama, et me ei saa neid pod\u2019e \u00fchest s\u00f5lmedest teise viia, sest nad peavad olema seotud sellise tee kaudu kohaliku f\u00fc\u00fcsilise kettaga. N\u00fc\u00fcd on kogu see teadmine kapseldatud Kubernetesesse. See muudab konfigureerimise palju lihtsamaks.<\/p>\n
<\/p>\n
<\/p>\n
Naaseme taas meie praktilise \u00fclesande juurde. Naaseme YAML mallide juurde. Siin on meil t\u00f5eline storage. Oleme tagasi selle juurde. M\u00e4\u00e4rame klassikalise VolumeClaim malli nagu k8s-is. Ja kirjeldame, millist storage'i soovime.<\/p>\n
<\/p>\n
P\u00e4rast seda k\u00fcsib k8s storage'i. Eraldab sellele meie StatefulSetis. Ja l\u00f5puks saab see ClickHouse'i k\u00e4sutusse.<\/p>\n
<\/p>\n
<\/p>\n
Meil oli selline skeem. Meie Persistent Storage oli punane, mis vihjas, et see tuleks teha. <\/p>\n
<\/p>\n
<\/p>\n
Ja see muutub roheliseks. N\u00fc\u00fcd on ClickHouse'i klastrite skeem k8s-is t\u00e4ielikult l\u00f5pule viidud. Meil on shard'id, koopiad, ZooKeeper, on olemas t\u00f5eline Persistent, mis on ellu viidud eri viisidel. Skeem on juba t\u00e4ielikult t\u00f6\u00f6tav. <\/p>\n
<\/p>\n
<\/p>\n
Me elame edasi. Meie klaster areneb. Ja Aleksei pingutab, et v\u00e4lja anda uus versioon ClickHouse'ist.<\/p>\n
<\/p>\n
T\u00f5useb praktiline \u00fclesanne \u2013 testida uue ClickHouse'i versiooni meie klastris. Loomulikult ei taha me seda kogu aeg uuendada, vaid soovime uue versiooni kuskil kauges nurgas \u00fchte replit panna, v\u00f5ib-olla isegi mitte \u00fchte uut versiooni, vaid kohe kahte, sest need v\u00e4ljuvad \u00fcsna tihti. <\/p>\n
<\/p>\n
Mida me selle kohta \u00f6elda saame?<\/p>\n
<\/p>\n
<\/p>\n
Siinkohal on meil just selline v\u00f5imalus. Need on pod'i mallid. Saame v\u00e4lja kirjutada, meie operaator v\u00f5imaldab t\u00e4ielikult ehitada heterogeense klastrite. See t\u00e4hendab, et me saame konfigureerida alates k\u00f5igist replitest hunnikus, l\u00f5petades igasuguste isiklike replititega selle kohta, millist versiooni me soovime ClickHouse'ist ja millist versiooni me soovime salvestamisest. Me saame t\u00e4ielikult konfigureerida klastrit selliseks konfiguratsiooniks, nagu me soovime. <\/p>\n
<\/p>\n
<\/p>\n
Natuke s\u00fcveneme juba s\u00fcgavamale. Varem r\u00e4\u00e4kisime sellest, kuidas ClickHouse-operator t\u00f6\u00f6tab ClickHouse'i spetsiifika suhtes.<\/p>\n
<\/p>\n
N\u00fc\u00fcd tahaksin \u00f6elda paar s\u00f5na selle kohta, kuidas toimib igasugune operaator, samuti sellest, kuidas see suhtleb K8s-iga.<\/p>\n
<\/p>\n
<\/p>\n
Vaadakem alustuseks suhet K8s-iga. Mis juhtub, kui teeme kubectl apply? Meie objektid ilmuvad l\u00e4bi API etcd-sse. <\/p>\n
<\/p>\n
<\/p>\n
N\u00e4iteks Kubernetes'i baikeskonnad: pod, StatefulSet, teenus ja nii edasi. <\/p>\n
<\/p>\n
Samuti ei juhtu veel midagi f\u00fc\u00fcsilist. Need objektid tuleb klastrisse materialiseerida. <\/p>\n
<\/p>\n
<\/p>\n
Selleks tuleb kontrollija. Kontrollija on eriline komponent k8s, mis oskab neid kirjelduse alusel materialiseerida. Ta teab, kuidas ja mida teha f\u00fc\u00fcsiliselt. Ta teab, kuidas konteinerid k\u00e4ivitada, mida on vajalik serveri t\u00f6\u00f6lepanekuks seadistada. <\/p>\n
<\/p>\n
<\/p>\n
Ja ta materialiseerib meie objektid K8s.<\/p>\n
<\/p>\n
Kuid me ei soovi opereerida vaid pod'ide ja StatefulSet'idega, me tahame luua ClickHouseInstallation, st ClickHouse t\u00fc\u00fcpi objekti, et hallata seda kui \u00fchtset tervikut. Praegu sellist v\u00f5imalust ei ole. <\/p>\n
<\/p>\n
<\/p>\n
Kuid K8s-l on j\u00e4rgmine meeldiv asi. Me soovime, et meil oleks kuskil selline keeruline entiteet, mis koosneks pod'idest ja StatefulSet'ist meie klastrist. <\/p>\n
<\/p>\n
<\/p>\n
Ja mida selleks teha? Esiteks, astub lavale Custom Resource Definition. Mis see on? See on K8s jaoks kirjeldus, et sul on veel \u00fcks andmet\u00fc\u00fcp, et me soovime pod'ile, StatefulSet'ile lisada kohandatud ressurssi, mis oleks keeruline sees. See on andmestruktuuri kirjeldus. <\/p>\n
<\/p>\n
<\/p>\n
Me saadame selle ka kubectl apply kaudu sinna. Kubernetes on selle r\u00f5\u00f5muga vastu v\u00f5tnud. <\/p>\n
<\/p>\n
Ja n\u00fc\u00fcd on meil salvestuses, objekti etcd juures v\u00f5imalus registreerida kohandatud ressurssi nimega ClickHouseInstallation.<\/p>\n
<\/p>\n
Aga praegu ei juhtu midagi enamat. See t\u00e4hendab, et kui me praegu loome YAML-faili, mida oleme vaadanud shardide, replikate kirjeldamiseks ja \u00fctleme 'kubectl apply', siis Kubernetes v\u00f5tab selle vastu, paneb etcd-sse ja \u00fctleb: 'Suurep\u00e4rane, aga mida sellega teha, ma ei tea. Kuidas ClickHouseInstallation teenindada, ma ei tea.' <\/p>\n
<\/p>\n
<\/p>\n
Seega on meil vaja kedagi, kes aitab Kubernetesel uue andmet\u00fc\u00fcbi teenindamisel. Vasakul on meil Raudtee Kubernetesi kontroller, mis t\u00f6\u00f6tab standardsete andmet\u00fc\u00fcpidega. Paremal peab ilmuma kohandatud kontroller, mis oskab t\u00f6\u00f6tada kohandatud andmet\u00fc\u00fcpidega. <\/p>\n
<\/p>\n
Ja teistmoodi nimetatakse seda operaatoriks. Olen selle siin spetsiaalselt v\u00e4lja t\u00f5stnud, sest see v\u00f5ib t\u00f6\u00f6tada ka v\u00e4ljaspool K8s. Enamasti t\u00f6\u00f6tavad k\u00f5ik operaatorid muidugi Kuberneteses, aga miski ei takista tal seista v\u00e4ljas, seet\u00f5ttu on see siin spetsiaalselt v\u00e4lja t\u00f5stetud. <\/p>\n
<\/p>\n
<\/p>\n
Ja seej\u00e4rel suhtleb kohandatud kontroller, samuti operaator, Kubernetesega API kaudu. Ta oskab juba suhelda APIga. Ja ta teab, kuidas kohandatud ressursist materialiseerida keeruline skeem, mida soovime luua. Selle tegevusega operaator tegelebki. <\/p>\n
<\/p>\n
<\/p>\n
Kuidas operaator t\u00f6\u00f6tab? Vaatame paremale poole, et teada saada, kuidas ta seda teeb. Saame teada, kuidas operaator k\u00f5ik selle materialiseerib ja kuidas toimub edasine suhtlemine K8s-iga.<\/p>\n
<\/p>\n
<\/p>\n
Operaator on programm. See on s\u00fcndmustele orienteeritud. Operaator registreerib end Kubernetes API kaudu s\u00fcndmuste osas. Kubernetes API-s on sissep\u00e4\u00e4supunktid, kuhu saab registreeruda s\u00fcndmuste jaoks. Ja kui K8s-is midagi muutub, siis saadab Kubernetes s\u00fcndmused igale soovijale, st see, kes on selle API punkti tellinud, saab teateid.<\/p>\n
<\/p>\n
Operaator registreerib end s\u00fcndmuste osas ja peab tegema mingi reageeringu. Tema \u00fclesanne on reageerida tekkivatele s\u00fcndmustele. <\/p>\n
<\/p>\n
<\/p>\n
S\u00fcndmused genereeritakse teatud uuenduste kaudu. Meie YAML-fail koos ClickHouseInstallationi kirjeldusega saadetakse kubectl apply kaudu etcd-sse. Seal toimub s\u00fcndmus, mis j\u00f5uab ClickHouse-i operaatorini. Operaator saab selle kirjelduse k\u00e4tte ja tema \u00fclesanne on midagi teha. Kui ClickHouseInstallationi objektile on tulnud uuendus, tuleb klastrit uuendada. Operaatori \u00fclesanne on klastrit uuendada. <\/p>\n
<\/p>\n
<\/p>\n
Mida ta teeb? Esiteks peab ta koostama tegevusplaani, mida me selle uuendusega teeme. Uuendused v\u00f5ivad olla v\u00e4ga v\u00e4ikesed, st YAML-implementatsioonis v\u00e4ikesed, kuid need v\u00f5ivad kutsuda esile suurde klastrisse suuri muudatusi. Seet\u00f5ttu koostab operaator plaani ja j\u00e4rgib seda edasi.<\/p>\n
<\/p>\n
<\/p>\n
Ta hakkab vastavalt sellele plaanile vajalikku struktuuri loobuma, et materialiseerida pod'e, teenuseid, st teha seda, mis on tema peamine \u00fclesanne. See on nagu ClickHouse klastrite ehitamine Kuberneteses.<\/p>\n
<\/p>\n
<\/p>\n
N\u00fc\u00fcd puudutame sellist huvitavat teemat. See on vastutuse jagamine Kubernetes'i ja operaatori vahel, st mida teeb Kubernetes, mida teeb operaator ja kuidas nad omavahel suhtlevad. <\/p>\n
<\/p>\n
Kubernetes vastutab s\u00fcsteemsete asjade eest, st p\u00f5hikomplekti objektide eest, mida saab t\u00f5lgendada s\u00fcsteemi ulatusena. Kubernetes teab, kuidas k\u00e4ivitada pod'e, kuidas konteinerit restartida, kuidas mountida mahtusid, kuidas t\u00f6\u00f6tada ConfigMap'iga \u2014 k\u00f5ik, mida v\u00f5ib nimetada s\u00fcsteemiks. <\/p>\n
<\/p>\n
Operaatorid t\u00f6\u00f6tavad valdkondades. Iga operaator on loodud oma valdkonna jaoks. Me valmistasime selle ClickHouse'i jaoks.<\/p>\n
<\/p>\n
Ja operaator suhtleb just sellistes valdkonna m\u00f5istetes nagu uue repliibi lisamine, skeemi loomine, j\u00e4lgimise seadistamine. Tekib selline jaotus.<\/p>\n
<\/p>\n
<\/p>\n
Vaatame praktilise n\u00e4ite kaudu, kuidas see vastutuse jaotus toimub, kui teeme tegevuse, et lisada repliik. <\/p>\n
<\/p>\n
Operaator saab \u00fclesande \u2014 lisada repliik. Mida operaator teeb? Operaator arvutab v\u00e4lja, et on vaja teha uus StatefulSet, kus tuleb kirjeldada teatud mallid, mahtude n\u00f5udmine. <\/p>\n
<\/p>\n
<\/p>\n
Ta valmistab selle k\u00f5ik ette ja edastab edasi K8s. \u00dctleb, et tal on vaja ConfigMap'i, StatefulSet'i ja mahtu. Kubernetes t\u00f6\u00f6tab v\u00e4lja. Ta materialiseerib p\u00f5hielemendid, millega ta opereerib. <\/p>\n
<\/p>\n
<\/p>\n
Ja j\u00e4tkab ClickHouse-operator, kellel on juba f\u00fc\u00fcsiline pod, millega midagi teha. ClickHouse-operator t\u00f6\u00f6tab taas domeeni m\u00f5istetega. See t\u00e4hendab, et ClickHouse'i puhul tuleb repliika klastrisse lisamiseks k\u00f5igepealt seadistada andmeskeem, mis on selles klastris olemas. Teiseks tuleb see repliika integreerida j\u00e4lgimise, et see oleks h\u00e4sti j\u00e4lgitav. Selle seadistab juba operaator. <\/p>\n
<\/p>\n
<\/p>\n
Ja alles siis astub m\u00e4ngu ClickHouse, st veel \u00fcks k\u00f5rgem taseme element. See on juba andmebaas, millel on oma instants, uus konfigureeritud repliika, mis on valmis klastrisse astuma.<\/p>\n
<\/p>\n
Tekib piisavalt pikk tegevuste ahela ja vastutuse jaotuse skeem repliika lisamisel.<\/p>\n
<\/p>\n
<\/p>\n
J\u00e4tkame oma praktiliste \u00fclesannetega. Kui klaster on juba olemas, saab teostada konfiguratsiooni migreerimist. <\/p>\n
<\/p>\n
<\/p>\n
Oleme teinud nii, et olemasolevasse xml-i, mida ClickHouse m\u00f5istab, saab andmeid suunata otse.<\/p>\n
<\/p>\n
<\/p>\n
ClickHouse'i v\u00f5ib t\u00e4iendavalt h\u00e4\u00e4lestada. Zonaalne kaasamine on just see, millest r\u00e4\u00e4kisin selgitades hostPathi ja lokaalset salvestust. See on \u00f5ige viis zonaalse kaasamise tegemiseks.<\/p>\n
<\/p>\n
<\/p>\n
J\u00e4rgmine praktiline \u00fclesanne on j\u00e4lgimine.<\/p>\n
<\/p>\n
<\/p>\n
Kui meie klaster muutub, tuleb j\u00e4lgimist aeg-ajalt seadistada. <\/p>\n
<\/p>\n
Vaadakem skeemi. Oleme juba k\u00e4sitlenud rohelisi nooli. N\u00fc\u00fcd uurime punaseid nooli. See on see, kuidas me tahame oma klastrit j\u00e4lgida. Kuidas ClickHouse' klastrist p\u00e4rit m\u00f5\u00f5dikud l\u00e4hevad Prometheusesse ja seej\u00e4rel Grafanasse.<\/p>\n
<\/p>\n
<\/p>\n
Kus on t\u00f5rge j\u00e4lgimises? Miks see tuuakse esile kui mingi saavutus? Probleem seisneb d\u00fcnaamikas. Kui meil on \u00fcks klaster ja see on staatiline, saab j\u00e4lgimise seadistada \u00fcks kord ja rohkem ei pea muretsema.<\/p>\n
<\/p>\n
Aga kui meil on palju klasse v\u00f5i pidevalt midagi muutub, on protsess d\u00fcnaamiline. Ja pidev j\u00e4lgimise seadistamine on ressursi ja aja raiskamine, see on lihtsalt laiskus. See tuleb automatiseerida. Probleem on protsessi d\u00fcnaamikas. Ja operaator automatiseerib seda v\u00e4ga h\u00e4sti. <\/p>\n
<\/p>\n
<\/p>\n
Kuidas meie klaster arenes? Alguses oli see selline.<\/p>\n
<\/p>\n
<\/p>\n
Siis oli see selline.<\/p>\n
<\/p>\n
<\/p>\n
L\u00f5puks sai see selliseks. <\/p>\n
<\/p>\n
Ja j\u00e4lgimist tehakse operaatori poolt automaatselt. \u00dcksne sisenemiskoht. <\/p>\n
<\/p>\n
<\/p>\n
Ja j\u00e4lgime ainult Grafana juhtpaneelil, kuidas meie klastri elu sees toimub. <\/p>\n
<\/p>\n
Muide, Grafana juhtpaneel levib samuti meie operaatoriga otse allikakoodis. Seda saab \u00fchendada ja kasutada. Selle ekraanipildi andsid mulle meie DevOps.<\/p>\n
<\/p>\n
<\/p>\n
Kuhu tahaksime edasi liikuda? Need on:<\/p>\n
<\/p>\n
\nArendada testimise automatiseerimist. Peamine \u00fclesanne on uute versioonide automatiseeritud testimine. <\/li>\n Samuti soovime tugevalt automatiseerida integreerimist ZooKeeperiga. Plaanis on integreeruda ZooKeeper-operatoriga. St. ZooKeeperi jaoks on kirjutatud operaator ja oleks loogiline, et kaks operaatorit hakkaksid integreeruma mugavama lahenduse loomiseks. <\/li>\n Tahame teha keerulisemaid t\u00f6\u00f6kindluse kontrolle. <\/li>\n Rohelisega m\u00e4rkisin, et meil on tulemas mallide p\u00e4rimise funktsioon \u2013 VALMIS, st j\u00e4rgmise operaatori versiooniga on meil juba mallide p\u00e4rimine. See on v\u00f5imas t\u00f6\u00f6riist, mis v\u00f5imaldab koostada keerulisi konfiguratsioone t\u00fckkidest. <\/li>\n Ja tahame keeruliste \u00fclesannete automatiseerimist. Peamine neist on Re-sharding. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Teeme vahekokkuv\u00f5tte. <\/p>\n
<\/p>\n
<\/p>\n
Mida me l\u00f5puks saame? Kas peaksime sellega tegelema v\u00f5i mitte? Kas on \u00fcldse m\u00f5tet viia andmebaas Kubernetesesse ja rakendada operaatorit laiemalt ning Alitnity operaatorit konkreetselt?<\/p>\n
<\/p>\n
L\u00f5puks saame:<\/p>\n
<\/p>\n
\nOluliselt lihtsustatud ja automatiseeritud seadistamise, juurutamise ja hooldamise. <\/li>\n Koheselt sisse ehitatud j\u00e4lgimine. <\/li>\n Ja valmis kasutamiseks kooditud mallid keeruliste olukordade jaoks. N\u00e4iteks pole enam vaja k\u00e4sitsi lisada koopiat. Selle teeb operaator. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
J\u00e4\u00e4nud on vaid viimane k\u00fcsimus. Meil on juba andmebaas Kuberneteses, virtualiseerimine. Kuidas on sellise lahenduse j\u00f5udlust, eriti arvestades seda, et ClickHouse on optimeeritud j\u00f5udluse jaoks?<\/p>\n
<\/p>\n
Vastus \u2013 k\u00f5ik on korras! Ma ei hakka detailidesse laskuma, see on eraldi ettekande teema. <\/p>\n
<\/p>\n
<\/p>\n
Aga on selline projekt nagu TSBS. Mis on selle peamine eesm\u00e4rk? Andmebaaside j\u00f5udluse testimine. See on katse v\u00f5rrelda sooja sooja, pehmet pehme. <\/p>\n
<\/p>\n
Kuidas see t\u00f6\u00f6tab? Generatakse \u00fcks andmekogum. Siis k\u00e4ib see andmekogum erinevatel andmebaasidel sama testkomplekti peal. Iga andmebaas lahendab \u00fclesande nii, nagu oskab. Ja siis saab tulemusi v\u00f5rrelda. <\/p>\n
<\/p>\n
See toetab juba suurt hulka andmebaase. Olen v\u00e4lja toonud kolm peamist. Need on:<\/p>\n
<\/p>\n
\nTimescaleDB.<\/li>\n InfluxDB.<\/li>\n ClickHouse.<\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Samuti on tehtud v\u00f5rdlus teise sarnase lahendusega. V\u00f5rdlus RedShiftiga. See tehti Amazonis. ClickHouse \u00fcletab ka selles osas k\u00f5ik teised. <\/p>\n
<\/p>\n
<\/p>\n
Milliseid j\u00e4reldusi saab teha selle p\u00f5hjal, mida ma r\u00e4\u00e4kisin?<\/p>\n
<\/p>\n
\nAndmebaasid Kuberneteses on v\u00f5imalikud. T\u00f5en\u00e4oliselt saab igasuguseid, aga \u00fcldiselt tundub, et see on v\u00f5imalik. ClickHouse Kuberneteses on kindlasti v\u00f5imalik meie operaatori abiga. <\/li>\n Operaator aitab automatiseerida protsesse ja lihtsustab t\u00f5eliselt elu.<\/li>\n Toimev\u00f5ime on normaalne.<\/li>\n Ja me arvame, et seda saab ja tuleb kasutada. <\/li>\n<\/ul>\n<\/p>\n
Avatud l\u00e4htekood \u2013 liituge!<\/p>\n
<\/p>\n
Nagu ma juba \u00fctlesin, on operaator t\u00e4ielikult avatud l\u00e4htekoodiga toode, seega oleks v\u00e4ga hea, kui v\u00f5imalikult palju inimesi seda kasutaks. Liituge! Ootame teid k\u00f5iki!<\/p>\n
<\/p>\n
Ait\u00e4h k\u00f5igile!<\/p>\n
<\/p>\n
K\u00fcsimused<\/p>\n
<\/p>\n
<\/p>\n
Ait\u00e4h esitlust! Mina olen Anton. Ma olen ettev\u00f5ttest SEMrush. Mind huvitab, mis logimisega toimub. Jutt on kuulda j\u00e4lgimisest, aga logimisest ei ole midagi, kui r\u00e4\u00e4kida klastrist tervikuna. N\u00e4iteks meil on \u00fcles seatud klaster riistvaral. Ja me kasutame tsentraliseeritud logimist, standardsete vahenditega kogume k\u00f5ik koos. Ja siis sealt v\u00f5tame v\u00e4lja huvitavad andmed.<\/em> <\/p>\n<\/p>\n
Hea k\u00fcsimus, st logimine on todo nimekirjas. Meie operaator ei automatiseeri seda veel. Ta veel areneb, projekt on ikka veel piisavalt noor. Me m\u00f5istame logimise vajadust. See on samuti v\u00e4ga oluline teema. Ja see pole t\u00f5en\u00e4oliselt v\u00e4hem oluline kui j\u00e4lgimine. Kuid esimene teema elluviimiseks oli j\u00e4lgimine. Logimine tuleb. Me p\u00fc\u00fcame loomulikult automatiseerida k\u00f5ik klastriga seotud tegevused. Seet\u00f5ttu on vastus - hetkel operaator, kahjuks, ei oska seda veel teha, kuid see on plaanis ja me teeme seda. Kui on soov liituda, siis palun tee pull request.<\/p>\n
<\/p>\n
Tere! Ait\u00e4h ettekande eest! Mul on tavaline k\u00fcsimus, mis on seotud Persistent Volumes'iga. Kui me loome selle operaatori kaudu konfigureerimise, kuidas operaator m\u00e4\u00e4rab, millisel node'il on meil m\u00f5ni ketas v\u00f5i kaust primountitud? Kas me peame talle eelnevalt selgitama, et palun paigalda meie ClickHouse just nendele node'idele, kus on ketas?<\/em><\/p>\n<\/p>\n
Nii palju, kui ma aru saan, on see k\u00fcsimus kohaliku salvestuse j\u00e4tk, eriti selle osa kohta hostPath. See on nagu kogu s\u00fcsteemile selgitamine, et pod peab t\u00f6\u00f6tama just kindlal node'il, kus meil on f\u00fc\u00fcsiliselt \u00fchendatud ketas, mis on mountitud teatud teele. See on terve sektsioon, mida ma katsusin v\u00e4ga pinnapealselt, sest vastus on piisavalt ulatuslik. <\/p>\n
<\/p>\n
L\u00fchidalt \u00f6eldes n\u00e4eb see v\u00e4lja j\u00e4rgmiselt. Loomulikult peame nende mahtude provisionimise \u00e4ra tegema. Hetkel puudub kohaliku salvestuse d\u00fcnaamiline provisionimine, seega peavad DevOps ise kettad l\u00f5ikama, need mahud. Samuti peavad nad Kubernetes'ile selgitama, et sul on teatud klassi Persistent volumes, mis asuvad teatud s\u00f5lmedes. Seej\u00e4rel tuleb Kubernetes'ile selgitada, et pod'id, mis n\u00f5uavad sellist klassi kohaliku salvestuse, tuleb labelite j\u00e4rgi graafikule v\u00f5tta ainult teatud s\u00f5lmedes. Selleks on operaatoris v\u00f5imalus m\u00e4\u00e4rata teatud label ja one per host instance. Nii et pod'id marsrutiseeritakse Kubernetes'i poolt k\u00e4ivitamiseks ainult nendel s\u00f5lmedel, mis vastavad n\u00f5uetele, lihtsustades seda \u00f6eldes. S\u00fcsteemiadministraatorid m\u00e4\u00e4ravad labelid ja teevad kettaste provisionimise k\u00e4sitsi. Siis saab s\u00fcsteem skaleeruda.<\/p>\n
<\/p>\n
Ja just kolmas variant kohaliku salvestuse abil aitab seda veidi lihtsustada. Nagu ma juba r\u00f5hutasin, on see p\u00f5hjalik seadistust\u00f6\u00f6, mis aitab saavutada maksimaalset j\u00f5udlust.<\/p>\n
<\/p>\n
Mul on selle teemaga seoses teine k\u00fcsimus. Kubernetes on m\u00f5eldud nii, et me ei pea muretsema, kas me kaotame s\u00f5lme v\u00f5i mitte. Mida me peaksime tegema, kui me kaotasime s\u00f5lme, kus on meie shard?<\/em><\/p>\n<\/p>\n
Jah, Kubernetes on algselt positsioneeritud nii, et meie suhted meie pod\u2018idega on nagu kariloomadega, aga n\u00fc\u00fcd on iga ketas midagi nagu lemmikloom. On probleem, et me ei saa neid lihtsalt \u00e4ra visata. Kubernetes'e areng viib selleni, et ei ole v\u00f5imalik t\u00e4ielikult suhtuda sellesse filosoofiliselt nagu t\u00e4ielikult \u00e4ra visatavate ressurssidena.<\/p>\n
<\/p>\n
N\u00fc\u00fcd praktiline k\u00fcsimus. Mida teha, kui sul on kaduma l\u00e4inud s\u00f5lm, kus ketas oli? Siin lahendatakse probleem k\u00f5rgemal tasemel. ClickHouse'i puhul on meil replikad, mis t\u00f6\u00f6tavad k\u00f5rgemal tasemel, st ClickHouse tasemel.<\/p>\n
<\/p>\n
Milline on olukord? Andmete kadumise eest vastutab DevOps. Ta peab korralikult seadistama replikatsiooni ja j\u00e4lgima, et replikatsioon toimiks. ClickHouse tasemel peavad andmed olema replikas dubleeritud. See ei ole \u00fclesanne, mida lahendab operaator. Ja see ei ole \u00fclesanne, mida lahendab Kubernetes. See on ClickHouse tasemel.<\/p>\n
<\/p>\n
Mis teha, kui teie serveri nodi kukkus? Tundub, et peate seadma teise, \u00f5igesti paigaldama kettad ja m\u00e4rkima sildid. P\u00e4rast seda peab see vastama n\u00f5uetele, et Kubernetes saab sellel k\u00e4ivitada pod'i koopia. Kubernetes k\u00e4ivitab selle. Teil on ju pod'ide arv allapoole seatud. See l\u00e4bib ts\u00fcklit, mida ma n\u00e4itasin. Ja k\u00f5ige k\u00f5rgemal tasemel m\u00f5istab ClickHouse, et meil on sisse tulnud replikatsioon, see on veel t\u00fchi ja sellele tuleb hakata andmeid \u00fcle kandma. See protsess on veel halvasti automatiseeritud. <\/p>\n
<\/p>\n
Ait\u00e4h ettekande eest! Kui midagi hullu juhtub, langeb operaator ja ta taask\u00e4ivitub, samal ajal kui toimub s\u00fcndmuste vastuv\u00f5tt, kas te t\u00f6\u00f6deldes seda kuidagi teete?<\/em><\/p>\n<\/p>\n
Mis juhtub, kui operaator kukkus ja ta taask\u00e4ivitub, eks? <\/p>\n
<\/p>\n
Jah. Ja sel hetkel toimusid s\u00fcndmused.<\/em> <\/p>\n<\/p>\n
\u00dclesanne, mida selles olukorras teha, jaguneb osaliselt operaatori ja Kubernetes'i vahel. Kubernetes'il on v\u00f5imalus juhtunud s\u00fcndmust uuesti taasesitada. Ta taasesitab selle. Operaatori \u00fclesanne on aga tagada, et kui s\u00fcndmuste logi taasesitatakse, oleksid need s\u00fcndmused idempotentsed. Ja et sama s\u00fcndmuse korduv esinemine ei rikuks meie s\u00fcsteemi. Meie operaator suudab sellega toime tulla. <\/p>\n
<\/p>\n
Tere! Ait\u00e4h ettekande eest! Dmitri Zavyalov, ettev\u00f5te<\/em> Smedova. Kas plaanitakse operaatorisse lisada v\u00f5imalust seadistada haproxy? Olen huvitatud millestki muust koormustasakaalustajast peale standardse, mis oleks nutikas ja m\u00f5istaks, mis seal tegelikult ClickHouse'is toimub.<\/em> <\/p>\n<\/p>\n
Kas te r\u00e4\u00e4gite Ingress'ist?<\/p>\n
<\/p>\n
Jah, asendame Ingress'i haproxy'ga. Haproxy's saab m\u00e4\u00e4rata klooster topoloogia, kus tal on replikad.<\/em><\/p>\n<\/p>\n
Praegu ei ole me selle peale m\u00f5elnud. Kui see on teile vajalik ja oskate selgitada, miks see vajalik on, siis on v\u00f5imalik see ellu viia, eriti kui soovite osaleda. Me hindame hea meelega seda varianti. L\u00fchike vastus \u2013 ei, meil ei ole sellist funktsionaalsust hetkel. Ait\u00e4h vihje eest, vaatame selle asja \u00fcle. Ja kui saaksid veel selgitada kasutusjuhtu ja miks see praktikas vajalik on, n\u00e4iteks luua GitHubis teemasid, siis oleks see suurep\u00e4rane.<\/p>\n
<\/p>\n
Juba olemas.<\/em><\/p>\n<\/p>\n
Hea. Oleme avatud igasugustele ettepanekutele. Ja haproxy antakse to-do nimekirja. To-do nimekiri kasvab, mitte ei v\u00e4hene praegu. Aga see on hea, see t\u00e4hendab, et toode on n\u00f5udlik.<\/p>\n
Allikas: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0414\u043e\u043a\u043b\u0430\u0434 \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u043c \u0432\u043e\u043f\u0440\u043e\u0441\u0430\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440\u0430 \u0432 Kubernetes, \u043f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044e \u0435\u0433\u043e \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b \u0438 \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u0445 \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u043e\u0432 \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f. \u0412 \u043f\u0435\u0440\u0432\u043e\u0439 \u0447\u0430\u0441\u0442\u0438 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c: \u0447\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u0432 Kubernetes \u0438 \u0437\u0430\u0447\u0435\u043c \u043e\u043d \u043d\u0443\u0436\u0435\u043d; \u043a\u0430\u043a \u0438\u043c\u0435\u043d\u043d\u043e \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u0443\u043f\u0440\u043e\u0449\u0430\u0435\u0442 \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0435 \u0441\u043b\u043e\u0436\u043d\u044b\u043c\u0438 \u0441\u0438\u0441\u0442\u0435\u043c\u0430\u043c\u0438; \u0447\u0442\u043e \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u043c\u043e\u0436\u0435\u0442, \u0430 \u0447\u0442\u043e \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u043d\u0435 \u043c\u043e\u0436\u0435\u0442. \u0414\u0430\u043b\u0435\u0435, \u043f\u0435\u0440\u0435\u0439\u0434\u0451\u043c \u043a \u043e\u0431\u0441\u0443\u0436\u0434\u0435\u043d\u0438\u044e \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0433\u043e \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432\u0430 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440\u0430. \u0420\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0443 \u0438 \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":96966,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-96965","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Kubernetes'i](\"\/wp-content\/uploads\/2020\/10\/56e002c7408c4708e39ece867f84171e.jpeg\")
<\/p>\n