Local<\/li>\n<\/ul>\n<\/p>\n
Le t\u00eb shqyrtojm\u00eb se si ndryshojn\u00eb dhe si jan\u00eb t\u00eb ngjash\u00ebm. <\/p>\n
<\/p>\n
S\u00eb pari, n\u00eb t\u00eb tre qasjet ruajtja p\u00ebrb\u00ebn disqet lokale q\u00eb ndodhen n\u00eb t\u00eb nj\u00ebjt\u00ebn nod\u00eb fizike k8s. Por ato kan\u00eb disa ndryshime.<\/p>\n
<\/p>\n
<\/p>\n
T\u00eb fillojm\u00eb me gj\u00ebn\u00eb m\u00eb t\u00eb thjesht\u00eb, pra me emptyDir. \u00c7far\u00eb \u00ebsht\u00eb kjo n\u00eb praktik\u00eb? Kjo \u00ebsht\u00eb kur ne i k\u00ebrkojm\u00eb sistemit t\u00eb kontenjer\u00ebve (m\u00eb shpesh \u00ebsht\u00eb docker) q\u00eb t\u00eb na jap\u00eb akses n\u00eb nj\u00eb dosje n\u00eb diskun lokal.<\/p>\n
<\/p>\n
N\u00eb praktik\u00eb, docker krijon ndonj\u00ebher\u00eb nj\u00eb dosje t\u00eb p\u00ebrkohshme n\u00eb rrug\u00ebt e tij t\u00eb veta, e em\u00ebrton at\u00eb me nj\u00eb hash t\u00eb gjat\u00eb. Dhe ofron nj\u00eb nd\u00ebrfaqe p\u00ebr aksesin n\u00eb t\u00eb. <\/p>\n
<\/p>\n
Si do t\u00eb funksionoj\u00eb kjo p\u00ebr sa i p\u00ebrket performanc\u00ebs? Kjo do t\u00eb funksionoj\u00eb me shpejt\u00ebsin\u00eb e diskut lokal, dmth. kjo \u00ebsht\u00eb plot\u00ebsisht e aksesueshme p\u00ebr diskun tuaj. <\/p>\n
<\/p>\n
Por kjo ka nj\u00eb mang\u00ebsi t\u00eb vet. Persistente jan\u00eb mjaft t\u00eb dyshimta. Me l\u00ebvizjen e par\u00eb t\u00eb dockers me kontejner\u00ebt, Persistente humbin. N\u00ebse Kubernetes d\u00ebshiron, p\u00ebr ndonj\u00eb arsye, t\u00eb transferoj\u00eb k\u00ebt\u00eb Pod n\u00eb nj\u00eb disk tjet\u00ebr, at\u00ebher\u00eb t\u00eb dh\u00ebnat humbasin. <\/p>\n
<\/p>\n
Ky qasje \u00ebsht\u00eb e mir\u00eb p\u00ebr teste, sepse shpejt\u00ebsia tregon tashm\u00eb normale, por p\u00ebr di\u00e7ka t\u00eb r\u00ebnd\u00ebsishme ky variant nuk \u00ebsht\u00eb i p\u00ebrshtatsh\u00ebm. <\/p>\n
<\/p>\n
<\/p>\n
Prandaj ka nj\u00eb qasje t\u00eb dyt\u00eb. Kjo \u00ebsht\u00eb hostPath. N\u00ebse shikoni slajdin e kaluar dhe k\u00ebt\u00eb, mund t\u00eb shihni nj\u00eb vet\u00ebm dallim. Dosja \u00ebsht\u00eb shkuar nga docker drejtp\u00ebrdrejt n\u00eb nod\u00ebn Kubernetes. K\u00ebtu \u00ebsht\u00eb pak m\u00eb e thjesht\u00eb. Ne shkruajm\u00eb direkt rrug\u00ebn n\u00eb sistemin e skedar\u00ebve vendas, ku do t\u00eb doja t\u00eb ruaja t\u00eb dh\u00ebnat e mia. <\/p>\n
<\/p>\n
Avantazhet e k\u00ebtij m\u00ebnyre jan\u00eb reale. Ky \u00ebsht\u00eb tashm\u00eb nj\u00eb Persistent i v\u00ebrtet\u00eb, madje klasik. T\u00eb dh\u00ebnat tona do t\u00eb shkruhen n\u00eb disk n\u00eb nj\u00eb adres\u00eb t\u00eb caktuar. <\/p>\n
<\/p>\n
Ka there dhe disavantazhe. Kjo \u00ebsht\u00eb kompleksiteti i menaxhimit. Kubernetes-i yn\u00eb mund t\u00eb d\u00ebshiroj\u00eb t\u00eb l\u00ebviz\u00eb nj\u00eb Pod n\u00eb nj\u00eb nod\u00eb tjet\u00ebr fizike. Dhe k\u00ebtu hyn n\u00eb loj\u00eb DevOps. Ai duhet t\u00eb shpjegoj\u00eb sakt\u00eb t\u00eb gjith\u00eb sistemit se l\u00ebvizja e k\u00ebtyre pod'\u00ebve mund t\u00eb b\u00ebhet vet\u00ebm n\u00eb ato n\u00f3d\u00eb ku keni di\u00e7ka t\u00eb montuar dhe jo m\u00eb shum\u00eb se nj\u00eb nod\u00eb n\u00eb nj\u00eb koh\u00eb. Kjo \u00ebsht\u00eb mjaft e komplikuar. <\/p>\n
<\/p>\n
P\u00ebr k\u00ebto q\u00ebllime, ne si operator kemi krijuar shabllone p\u00ebr t\u00eb fshehur gjith\u00eb k\u00ebt\u00eb kompleksitet. Dhe do t\u00eb ishte e mjaftueshme t\u00eb thuash: 'Dua q\u00eb t\u00eb kem nj\u00eb instance ClickHouse p\u00ebr \u00e7do nod\u00eb fizike dhe n\u00eb k\u00ebt\u00eb rrug\u00eb'. <\/p>\n
<\/p>\n
<\/p>\n
Por kjo nevoj\u00eb nuk \u00ebsht\u00eb vet\u00ebm p\u00ebr ne, prandaj gentleman\u00ebt nga Kubernetes-i vet\u00eb e kuptojn\u00eb se njer\u00ebzit duan t\u00eb ken\u00eb akses n\u00eb disqet fizike, prandaj ata ofrojn\u00eb nj\u00eb nivel t\u00eb tret\u00eb.<\/p>\n
<\/p>\n
Ai quhet local. Diferenca me sliden e m\u00ebparshme praktikisht nuk ka. Vet\u00ebm se m\u00eb par\u00eb duhej t\u00eb b\u00ebnim me dor\u00eb q\u00eb k\u00ebto pod'\u00eb nuk mund t\u00eb l\u00ebvizeshin nga nj\u00eb nod\u00eb n\u00eb nj\u00eb tjet\u00ebr, sepse ata duhet t\u00eb ishin t\u00eb lidhur p\u00ebr nj\u00eb rrug\u00eb t\u00eb till\u00eb me disqin fizik lokal, dhe tani t\u00eb gjitha k\u00ebto njohuri inkapsulohen vet\u00eb n\u00eb Kubernetes. Dhe b\u00ebhet shum\u00eb m\u00eb e thjesht\u00eb p\u00ebr t'u konfiguruar.<\/p>\n
<\/p>\n
<\/p>\n
T\u00eb kthehemi n\u00eb detyr\u00ebn ton\u00eb praktike. T\u00eb kthehemi n\u00eb shabllonin YAML. K\u00ebtu kemi nj\u00eb storage t\u00eb v\u00ebrtet\u00eb. Jemi rikthyer n\u00eb k\u00ebt\u00eb. Ne p\u00ebrcaktojm\u00eb nj\u00eb shabllon klasike VolumeClaim si n\u00eb k8s. Dhe p\u00ebrshkruajm\u00eb se \u00e7far\u00eb storage-i duam.<\/p>\n
<\/p>\n
Pas k\u00ebsaj, k8s do t\u00eb k\u00ebrkoj\u00eb storage. Do ta ndaj\u00eb at\u00eb n\u00eb StatefulSet. Dhe n\u00eb fund do ta kemi n\u00eb dispozicion ClickHouse.<\/p>\n
<\/p>\n
<\/p>\n
Ishte nj\u00eb skem\u00eb e till\u00eb. Storage-i yn\u00eb i P\u00ebrhersh\u00ebm ishte e kuqe, q\u00eb si\u00e7 do t\u00eb na nxiste ta b\u00ebnim at\u00eb. <\/p>\n
<\/p>\n
<\/p>\n
Dhe ajo b\u00ebhet e gjelb\u00ebr. Tani skema e klasterit ClickHouse mbi k8s \u00ebsht\u00eb plot\u00ebsisht finalizuar. Kemi sharde, replika, ZooKeeper, kemi nj\u00eb Persistent t\u00eb v\u00ebrtet\u00eb, i cili realizohet n\u00eb nj\u00eb m\u00ebnyr\u00eb ose nj\u00eb tjet\u00ebr. Skema tashm\u00eb \u00ebsht\u00eb plot\u00ebsisht funksionale. <\/p>\n
<\/p>\n
<\/p>\n
Ne vazhdojm\u00eb t\u00eb jetojm\u00eb. Klasteri yn\u00eb po zhvillohet. Dhe \u0410\u043b\u0435\u043a\u0441\u0435\u0439 po p\u00ebrpiqet, duke l\u00ebshuar nj\u00eb version t\u00eb ri t\u00eb ClickHouse.<\/p>\n
<\/p>\n
Shkaktohet nj\u00eb detyr\u00eb praktike \u2013 t\u00eb testojm\u00eb versionin e ri t\u00eb ClickHouse n\u00eb klasterin ton\u00eb. Dhe, natyrisht, nuk d\u00ebshirojm\u00eb ta p\u00ebrdit\u00ebsojm\u00eb krejt, d\u00ebshirojm\u00eb ta vendosim nj\u00eb version t\u00eb ri n\u00eb nj\u00eb replika ndoshta n\u00eb nj\u00eb qoshe t\u00eb larg\u00ebt, dhe ndoshta jo nj\u00eb version t\u00eb ri, por dy menj\u00ebher\u00eb, pasi ato dalin shpesh. <\/p>\n
<\/p>\n
\u00c7far\u00eb mund t\u00eb themi p\u00ebr k\u00ebt\u00eb?<\/p>\n
<\/p>\n
<\/p>\n
K\u00ebtu kemi pik\u00ebrisht nj\u00eb mund\u00ebsi t\u00eb till\u00eb. K\u00ebto jan\u00eb shabllon\u00eb pod\u2019ash. Mund t\u00eb detajojm\u00eb, operatori yn\u00eb lejon plot\u00ebsisht nd\u00ebrtimin e nj\u00eb klasteri heterogjen. Dometh\u00ebn\u00eb, konfigurojm\u00eb nga t\u00eb gjitha replikat n\u00eb grumbull, deri te \u00e7do replik\u00eb individuale me versionin q\u00eb duam p\u00ebr ClickHouse, cilin version duam p\u00ebr storage. Mund t\u00eb konfigurojm\u00eb plot\u00ebsisht nj\u00eb klaster me konfigurimin q\u00eb na nevojitet. <\/p>\n
<\/p>\n
<\/p>\n
Tani do t\u00eb thellojm\u00eb pak m\u00eb shum\u00eb. Deri tani kemi folur se si funksionon ClickHouse-operatori n\u00eb lidhje me specifikat e ClickHouse.<\/p>\n
<\/p>\n
Tani do doja t\u00eb thosha disa fjal\u00eb mbi m\u00ebnyr\u00ebn se si funksionon \u00e7do operator, si dhe si bashk\u00ebvepron me K8s.<\/p>\n
<\/p>\n
<\/p>\n
Le t\u00eb shqyrtojm\u00eb bashk\u00ebveprimin me K8s p\u00ebr fillim. \u00c7far\u00eb ndodh kur b\u00ebjm\u00eb kubectl apply? Objekte tona shfaqen p\u00ebrmes API n\u00eb etcd. <\/p>\n
<\/p>\n
<\/p>\n
P\u00ebr shembull, objektet baz\u00eb t\u00eb Kubernetes: pod, StatefulSet, sh\u00ebrbim dhe k\u00ebshtu me radh\u00eb. <\/p>\n
<\/p>\n
Megjithat\u00eb, asgj\u00eb fizike nuk ndodh ende. K\u00ebto objekte duhet t\u00eb materializohen n\u00eb klaster. <\/p>\n
<\/p>\n
<\/p>\n
P\u00ebr k\u00ebt\u00eb, shfaqet kontrolluesi. Kontrolluesi \u00ebsht\u00eb nj\u00eb komponent i ve\u00e7ant\u00eb K8s q\u00eb di si t\u00eb materializoj\u00eb k\u00ebto p\u00ebrshkrime. Ai di se \u00e7far\u00eb dhe si duhet b\u00ebr\u00eb fizikisht. Ai di si t\u00eb aktivizoj\u00eb kontejner\u00ebt, \u00e7far\u00eb duhet t\u00eb konfigurohet n\u00eb m\u00ebnyr\u00eb q\u00eb serveri t\u00eb funksionoj\u00eb. <\/p>\n
<\/p>\n
<\/p>\n
Dhe ai materializon objektet tona n\u00eb K8s.<\/p>\n
<\/p>\n
Por ne duam t\u00eb operojm\u00eb jo vet\u00ebm me pod-a, StatefulSet-a, por duam t\u00eb krijojm\u00eb ClickHouseInstallation, dometh\u00ebn\u00eb, nj\u00eb objekt t\u00eb tipit ClickHouse, p\u00ebr ta operuar si nj\u00eb nj\u00ebsi t\u00eb vetme. Aktualisht, kjo mund\u00ebsi nuk ekziston. <\/p>\n
<\/p>\n
<\/p>\n
Por K8s ka di\u00e7ka tjet\u00ebr t\u00eb k\u00ebndshme. Ne duam q\u00eb t\u00eb kemi ndonj\u00ebher\u00eb nj\u00eb entitet t\u00eb till\u00eb t\u00eb komplikuar, n\u00eb t\u00eb cilin do t\u00eb ishte i grumbulluar klasteri yn\u00eb nga pod\u2019ash dhe StatefulSet. <\/p>\n
<\/p>\n
<\/p>\n
Dhe \u00e7far\u00eb duhet t\u00eb b\u00ebjm\u00eb p\u00ebr k\u00ebt\u00eb? S\u00eb pari, dalin p\u00ebrpara Definimi i Burimeve t\u00eb Personalizuara. \u00c7far\u00eb \u00ebsht\u00eb kjo? Ky \u00ebsht\u00eb nj\u00eb p\u00ebrshkrim p\u00ebr K8s q\u00eb do t\u00eb kemi nj\u00eb lloj t\u00eb dh\u00ebnash t\u00eb tjera, q\u00eb d\u00ebshirojm\u00eb t\u00eb shtojm\u00eb nj\u00eb burim t\u00eb personalizuar n\u00eb pod, StatefulSet, i cili do t\u00eb jet\u00eb kompleks brenda. Ky \u00ebsht\u00eb nj\u00eb p\u00ebrshkrim i struktur\u00ebs s\u00eb t\u00eb dh\u00ebnave. <\/p>\n
<\/p>\n
<\/p>\n
Ne e d\u00ebrgojm\u00eb gjithashtu at\u00eb p\u00ebrmes kubectl apply. Kubernetes e pranoi me g\u00ebzim. <\/p>\n
<\/p>\n
Dhe tani kemi n\u00eb ruajtje, te objekti n\u00eb etcd, mund\u00ebsin\u00eb p\u00ebr t\u00eb regjistruar nj\u00eb burim t\u00eb personalizuar me emrin ClickHouseInstallation.<\/p>\n
<\/p>\n
Por tani, asgj\u00eb m\u00eb tej nuk do t\u00eb ndodh\u00eb. Q\u00eb do t\u00eb thot\u00eb, n\u00ebse tani krijojm\u00eb nj\u00eb skedar YAML, i cili e kemi shqyrtuar me p\u00ebrshkrimin e shardit, replika dhe themi \"kubectl apply\", Kubernetes do ta pranoj\u00eb, do ta vendos\u00eb n\u00eb etcd dhe do t\u00eb thot\u00eb: \"Mir\u00eb, por nuk di \u00e7far\u00eb t\u00eb b\u00ebj me t\u00eb. Si ta menaxhoj ClickHouseInstallation nuk e di.\" <\/p>\n
<\/p>\n
<\/p>\n
Prandaj, na nevojitet dikush q\u00eb do t\u00eb ndihmoj\u00eb Kubernetes t\u00eb menaxhoj\u00eb nj\u00eb lloj t\u00eb ri t\u00eb dh\u00ebnash. Nga ana e majt\u00eb kemi nj\u00eb kontrollues t\u00eb rregullt t\u00eb Kubernetes, i cili punon me llojet e zakonshme t\u00eb t\u00eb dh\u00ebnave. Nd\u00ebrsa nga ana e djatht\u00eb duhet t\u00eb shfaqet nj\u00eb kontrollues personalizuar, i cili di t\u00eb punoj\u00eb me llojet e personalizuara t\u00eb t\u00eb dh\u00ebnave. <\/p>\n
<\/p>\n
Dhe ndryshe quhet operator. E kam nxjerr\u00eb k\u00ebtu jasht\u00eb Kubernetes, sepse ai mund t\u00eb ekzekutohet edhe jasht\u00eb K8s. N\u00eb shumic\u00ebn e rasteve, sigurisht, t\u00eb gjith\u00eb operator\u00ebt ekzekutohen n\u00eb Kubernetes, por asgj\u00eb nuk e pengon at\u00eb t\u00eb q\u00ebndroj\u00eb jasht\u00eb, prandaj k\u00ebtu \u00ebsht\u00eb nxjerr\u00eb ve\u00e7mas. <\/p>\n
<\/p>\n
<\/p>\n
Dhe tashm\u00eb kontrolluesi personalizuar, i njohur si operator, bashk\u00ebvepron me Kubernetes p\u00ebrmes API-s\u00eb. Ai tashm\u00eb di t\u00eb bashk\u00ebveproj\u00eb me API-n\u00eb. Dhe ai tashm\u00eb di si t\u00eb materializoj\u00eb nj\u00eb skem\u00eb t\u00eb komplikuar nga burimi personalizuar, q\u00eb d\u00ebshirojm\u00eb t\u00eb krijojm\u00eb. K\u00ebt\u00eb sakt\u00ebsisht b\u00ebn operatori. <\/p>\n
<\/p>\n
<\/p>\n
Si funksionon operatori? Le t\u00eb hedhim nj\u00eb sy n\u00eb an\u00ebn e djatht\u00eb p\u00ebr t\u00eb zbuluar se si e b\u00ebn k\u00ebt\u00eb. Do t\u00eb kuptojm\u00eb se si operatori materializon gjith\u00e7ka dhe si vazhdon bashk\u00ebveprimi me K8s.<\/p>\n
<\/p>\n
<\/p>\n
Operatori \u00ebsht\u00eb nj\u00eb program. Ai \u00ebsht\u00eb i orientuar nga ngjarjet. Operatorin me an\u00eb t\u00eb API-s\u00eb s\u00eb Kubernetes n\u00ebnshkruan p\u00ebr ngjarje. N\u00eb API-n\u00eb e Kubernetes ka pika hyr\u00ebse ku mund t\u00eb n\u00ebnshkruhen ngjarje. Dhe n\u00ebse di\u00e7ka ndryshon n\u00eb K8s, at\u00ebher\u00eb Kubernetes d\u00ebrgon ngjarje te t\u00eb gjith\u00eb ata q\u00eb e duan, dmth. ai q\u00eb \u00ebsht\u00eb n\u00ebnshkruar n\u00eb k\u00ebt\u00eb pik\u00eb API do t\u00eb marr\u00eb njoftime.<\/p>\n
<\/p>\n
Operatori n\u00ebnshkruhet p\u00ebr ngjarje dhe duhet t\u00eb b\u00ebj\u00eb ndonj\u00eb reagim. Detyra e tij \u00ebsht\u00eb t\u00eb reagoj\u00eb ndaj ngjarjeve q\u00eb shfaqen. <\/p>\n
<\/p>\n
<\/p>\n
Ngjarjet gjenerohen nga disa azhurnime. Vjen skedari yn\u00eb YAML me p\u00ebrshkrimin e ClickHouseInstallation. Ai shkoi n\u00eb etcd p\u00ebrmes kubectl apply. Aty ndodhi nj\u00eb ngjarje, dhe n\u00eb p\u00ebrfundim, kjo ngjarje erdhi n\u00eb ClickHouse-operator. Operatori mori k\u00ebt\u00eb p\u00ebrshkrim. Dhe ai duhet t\u00eb b\u00ebj\u00eb di\u00e7ka. N\u00ebse ka ardhur nj\u00eb azhurnim n\u00eb objektin ClickHouseInstallation, at\u00ebher\u00eb duhet t\u00eb azhurnojm\u00eb klasterin. Dhe detyra e operatorit \u00ebsht\u00eb t\u00eb azhurnoj\u00eb klasterin. <\/p>\n
<\/p>\n
<\/p>\n
\u00c7far\u00eb b\u00ebn ai? S\u00eb pari, duhet t\u00eb hartojm\u00eb nj\u00eb plan veprimi, se \u00e7far\u00eb do t\u00eb b\u00ebjm\u00eb me k\u00ebt\u00eb p\u00ebrdit\u00ebsim. P\u00ebrdit\u00ebsimet mund t\u00eb jen\u00eb shum\u00eb t\u00eb vogla, dmth, t\u00eb vogla n\u00eb aplikimin YAML, por mund t\u00eb sjellin ndryshime shum\u00eb t\u00eb m\u00ebdha n\u00eb klaster. Prandaj, operatori krijon nj\u00eb plan dhe m\u00eb pas e ndjek at\u00eb.<\/p>\n
<\/p>\n
<\/p>\n
Ai fillon sipas k\u00ebtij plani t\u00eb krijoj\u00eb k\u00ebt\u00eb struktur\u00eb brenda, p\u00ebr t\u00eb materializuar pod\u2019\u00ebt, sh\u00ebrbimet, dmth, t\u00eb b\u00ebj\u00eb at\u00eb q\u00eb \u00ebsht\u00eb detyra e tij kryesore. \u00cbsht\u00eb si nd\u00ebrtimi i nj\u00eb klasteri ClickHouse n\u00eb Kubernetes.<\/p>\n
<\/p>\n
<\/p>\n
Tani le t\u00eb prekim nj\u00eb gj\u00eb interesante. Ky \u00ebsht\u00eb ndarja e p\u00ebrgjegj\u00ebsis\u00eb midis Kubernetes dhe operatorit, dmth, \u00e7far\u00eb b\u00ebn Kubernetes, \u00e7far\u00eb b\u00ebn operatori dhe si interaktojn\u00eb ata me nj\u00ebri-tjetrin. <\/p>\n
<\/p>\n
Kubernetes \u00ebsht\u00eb p\u00ebrgjegj\u00ebs p\u00ebr gj\u00ebrat sistemore, dmth, p\u00ebr grupin baz\u00eb t\u00eb objekteve, q\u00eb mund t\u00eb interpretohen si sistem i gjer\u00eb. Kubernetes di si t\u00eb nis\u00eb pod\u2019\u00ebt, si t\u00eb rihap\u00eb konteiner\u00ebt, si t\u00eb b\u00ebj\u00eb mount volumes, si t\u00eb punoj\u00eb me ConfigMap, dmth, gjith\u00e7ka q\u00eb mund t\u00eb quhet sistem. <\/p>\n
<\/p>\n
Operator\u00ebt operojn\u00eb n\u00eb fushat tematike. \u00c7do operator b\u00ebhet p\u00ebr fush\u00ebn e tij tematike. Ne e b\u00ebm\u00eb p\u00ebr ClickHouse.<\/p>\n
<\/p>\n
Dhe operatori nd\u00ebrvepron pik\u00ebrisht n\u00eb terma t\u00eb fush\u00ebs tematike, si\u00e7 jan\u00eb shtimi i nj\u00eb kopjeje, krijimi i nj\u00eb skeme, konfigurimi i monitorimit. K\u00ebshtu krijohet nj\u00eb ndarje.<\/p>\n
<\/p>\n
<\/p>\n
Le t\u00eb shikojm\u00eb nj\u00eb shembull praktik, si ndodh kjo ndarje p\u00ebrgjegj\u00ebsish kur ne performojm\u00eb veprimin shto nj\u00eb kopje. <\/p>\n
<\/p>\n
N\u00eb operator vjen detyra \u2013 shto nj\u00eb kopje. \u00c7far\u00eb b\u00ebn operatori? Operatorit do t\u00eb llogaris\u00eb se duhet t\u00eb krijoj\u00eb nj\u00eb StatefulSet t\u00eb ri, n\u00eb t\u00eb cilin duhet t\u00eb p\u00ebrshkruaj\u00eb disa shabllone, k\u00ebrkes\u00ebn p\u00ebr volume. <\/p>\n
<\/p>\n
<\/p>\n
Ai e p\u00ebrgatit gjith\u00e7ka dhe e kalon m\u00eb tej n\u00eb K8s. I thot\u00eb se i nevojitet ConfigMap, StatefulSet, Volume. Kubernetes punon. Ai materializon nj\u00ebsit\u00eb baz\u00eb me t\u00eb cilat operon. <\/p>\n
<\/p>\n
<\/p>\n
Dhe m\u00eb pas p\u00ebrs\u00ebri nd\u00ebrhyn ClickHouse-operatori. Ai tashm\u00eb ka nj\u00eb pod fizik, n\u00eb t\u00eb cilin mund t\u00eb b\u00ebj\u00eb di\u00e7ka. Dhe ClickHouse-operatori punon p\u00ebrs\u00ebri n\u00eb terma t\u00eb fush\u00ebs tematike. Pra, konkretisht p\u00ebr ClickHouse, p\u00ebr t\u00eb p\u00ebrfshir\u00eb nj\u00eb kopje n\u00eb klaster, duhet, s\u00eb pari, t\u00eb konfigurohet skema e t\u00eb dh\u00ebnave q\u00eb ka ky klaster. Dhe s\u00eb dyti, kjo kopje duhet t\u00eb p\u00ebrfshihet n\u00eb monitorim, n\u00eb m\u00ebnyr\u00eb q\u00eb t\u00eb jet\u00eb e leht\u00eb p\u00ebr t'u ndjekur. Kjo tashm\u00eb e konfigurimin nga operatori. <\/p>\n
<\/p>\n
<\/p>\n
Dhe vet\u00ebm pas k\u00ebsaj merr pjes\u00eb vet\u00eb ClickHouse, pra nj\u00eb entitet tjet\u00ebr m\u00eb i lart\u00eb. Kjo \u00ebsht\u00eb tashm\u00eb nj\u00eb baz\u00eb t\u00eb dh\u00ebnash. Ajo ka instanc\u00ebn e saj, nj\u00eb replik\u00eb t\u00eb re konfiguruar, e cila \u00ebsht\u00eb e gatshme t\u00eb bashkohet me klasterin.<\/p>\n
<\/p>\n
Pra, krijohet nj\u00eb zinxhir p\u00ebr\u6267\u884c\u548c\u5206\u8d23\u4efb\u5728\u6dfb\u52a0\u590d\u5236\u54c1 \u00ebsht\u00eb mjaft i gjat\u00eb.<\/p>\n
<\/p>\n
<\/p>\n
T\u00eb vazhdojm\u00eb me detyrat tona praktike. N\u00ebse klasteri tashm\u00eb ekziston, mund t\u00eb kryhet migrimi i konfiguracionit. <\/p>\n
<\/p>\n
<\/p>\n
Ne e b\u00ebm\u00eb q\u00eb n\u00eb xml ekzistues, i cili kuptohet nga ClickHouse, mund t\u00eb kalojn\u00eb p\u00ebrmes.<\/p>\n
<\/p>\n
<\/p>\n
Mund t\u00eb b\u00ebhet nj\u00eb konfigurim i sakt\u00eb i ClickHouse. Pik\u00ebrisht implementimi me zona \u00ebsht\u00eb ajo p\u00ebr t\u00eb cil\u00ebn flasja gjat\u00eb shpjegimit t\u00eb hostPath, ruajtjes lokale. K\u00ebshtu \u00ebsht\u00eb si\u00e7 duhet t\u00eb b\u00ebhet implementimi me zona.<\/p>\n
<\/p>\n
<\/p>\n
Detyra e ardhshme praktike \u00ebsht\u00eb monitorimi.<\/p>\n
<\/p>\n
<\/p>\n
N\u00ebse klasteri yn\u00eb ndryshon, duhet t\u00eb p\u00ebrshtatni monitorimin periodikisht. <\/p>\n
<\/p>\n
Le t\u00eb shqyrtojm\u00eb skem\u00ebn. Ne kemi shqyrtuar tashm\u00eb \u0441\u0442\u0440\u0435\u043b\u043a\u0438\u0442\u0435 \u0437\u0435\u043b\u0435\u043d\u0435. Tani le t\u00eb shqyrtojm\u00eb \u0441\u0442\u0440\u0435\u043b\u043a\u0438\u0442\u0435 e kuqe. Ky \u00ebsht\u00eb m\u00ebnyra si duam t\u00eb monitorojm\u00eb klasterin ton\u00eb. Si metrikat nga klasteri ClickHouse kalojn\u00eb n\u00eb Prometheus dhe m\u00eb pas n\u00eb Grafana.<\/p>\n
<\/p>\n
<\/p>\n
Dhe cila \u00ebsht\u00eb v\u00ebshtir\u00ebsia me monitorimin? Pse ky proces nxirret si nj\u00eb arritje? V\u00ebshtir\u00ebsia \u00ebsht\u00eb pik\u00ebrisht n\u00eb dinamike. Kur kemi nj\u00eb klaster dhe ai \u00ebsht\u00eb static, mund t\u00eb konfigurojm\u00eb monitorimin nj\u00eb her\u00eb dhe m\u00eb pas t\u00eb mos shqet\u00ebsohemi m\u00eb.<\/p>\n
<\/p>\n
Por n\u00ebse kemi shum\u00eb klastere, ose gjithmon\u00eb di\u00e7ka ndryshon, procesi \u00ebsht\u00eb dinamik. Dhe t\u00eb b\u00ebsh rregullime t\u00eb vazhdueshme n\u00eb monitorim \u00ebsht\u00eb nj\u00eb humbje burimesh dhe kohe, pra madje \u00ebsht\u00eb vet\u00ebm m\u00ebndje. Kjo duhet automatizuar. V\u00ebshtir\u00ebsia \u00ebsht\u00eb pik\u00ebrisht n\u00eb dinamik\u00ebn e procesit. Dhe operatori e automatizon k\u00ebt\u00eb shum\u00eb mir\u00eb. <\/p>\n
<\/p>\n
<\/p>\n
Si u zhvillua klasteri yn\u00eb? N\u00eb fillim ai ishte k\u00ebshtu.<\/p>\n
<\/p>\n
<\/p>\n
Pastaj ai ishte k\u00ebshtu.<\/p>\n
<\/p>\n
<\/p>\n
N\u00eb fund, ai u b\u00eb k\u00ebshtu. <\/p>\n
<\/p>\n
Dhe monitorimi b\u00ebhet automatikisht nga operatori. Nj\u00eb pik\u00eb e vetme hyrjeje. <\/p>\n
<\/p>\n
<\/p>\n
Dhe ne vet\u00ebm shikojm\u00eb t\u00eb dh\u00ebnat n\u00eb Grafana dashboard, si po jeton klasteri yn\u00eb brenda. <\/p>\n
<\/p>\n
P\u00ebr m\u00eb tep\u00ebr, Grafana dashboard shp\u00ebrndahet gjithashtu me operatorin ton\u00eb direkt n\u00eb burimin. Mund ta lidhni dhe ta p\u00ebrdorni. Ky \u00ebsht\u00eb screenshot-i q\u00eb na dha DevOps-i yn\u00eb.<\/p>\n
<\/p>\n
<\/p>\n
Ku d\u00ebshirojm\u00eb t\u00eb shkojm\u00eb m\u00eb tej? Kjo \u00ebsht\u00eb:<\/p>\n
<\/p>\n
\nT\u00eb zhvillojm\u00eb automatizimin e testimit. Detyra kryesore \u00ebsht\u00eb testimi automatik i versioneve t\u00eb reja. <\/li>\n Ne duam shum\u00eb t\u00eb automatizojm\u00eb integrimin me ZooKeeper. Gjithashtu, kemi n\u00eb plan t\u00eb integrohemi me ZooKeeper-operator. Dometh\u00ebn\u00eb, p\u00ebr ZooKeeper \u00ebsht\u00eb shkruar nj\u00eb operator dhe \u00ebsht\u00eb logjike q\u00eb dy operator\u00eb t\u00eb fillojn\u00eb t\u00eb integrohen p\u00ebr t\u00eb nd\u00ebrtuar nj\u00eb zgjidhje m\u00eb t\u00eb p\u00ebrshtatshme. <\/li>\n Duam t\u00eb b\u00ebjm\u00eb verifikime m\u00eb t\u00eb komplikuara t\u00eb jet\u00ebgjat\u00ebsis\u00eb. <\/li>\n E theksova me gjelb\u00ebr at\u00eb q\u00eb na pret trash\u00ebgimi e Templates \u2013 PUN\u00cb E PLOT\u00cb, dometh\u00ebn\u00eb me versionin e ardhsh\u00ebm t\u00eb operatorit do t\u00eb kemi tashm\u00eb trash\u00ebgimi t\u00eb shabllon\u00ebve. Ky \u00ebsht\u00eb nj\u00eb mjet i fuqish\u00ebm q\u00eb lejon nd\u00ebrtimin e konfigurimeve t\u00eb komplikuara nga pjes\u00ebt. <\/li>\n Dhe ne duam automatizimin e detyrave komplekse. Kryesorja nga to \u00ebsht\u00eb Re-sharding. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Le t\u00eb b\u00ebjm\u00eb nj\u00eb p\u00ebrmbledhje nd\u00ebrmjet\u00ebs. <\/p>\n
<\/p>\n
<\/p>\n
\u00c7far\u00eb marrim n\u00eb fund? Dhe a ja vlen t\u00eb merremi me k\u00ebt\u00eb apo jo? A duhet t\u00eb p\u00ebrpiqemi t\u00eb t\u00ebrheqim baz\u00ebn e t\u00eb dh\u00ebnave n\u00eb Kubernetes dhe t\u00eb p\u00ebrdorim operatorin n\u00eb p\u00ebrgjith\u00ebsi dhe Alitnity-operatorin n\u00eb ve\u00e7anti.<\/p>\n
<\/p>\n
N\u00eb fund marrim:<\/p>\n
<\/p>\n
\nNj\u00eb thjeshtim dhe automatizim t\u00eb konsideruesh\u00ebm t\u00eb konfigurimit, zhvillimit, si dhe mb\u00ebshtetjes. <\/li>\n Monitoring i integruar menj\u00ebher\u00eb. <\/li>\n Dhe shabllone t\u00eb kodifikuara t\u00eb gatshme p\u00ebr situata komplekse. Veprime si t\u00eb shtosh nj\u00eb replik\u00eb nuk duhet t\u00eb b\u00ebhen me dor\u00eb. K\u00ebt\u00eb e b\u00ebn operatori. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Ka mbetur vet\u00ebm nj\u00eb pyetje e fundit. Ne tashm\u00eb kemi baz\u00ebn e t\u00eb dh\u00ebnave n\u00eb Kubernetes, virtualizim. Si \u00ebsht\u00eb performanca e nj\u00eb zgjidhjeje t\u00eb till\u00eb, duke marr\u00eb parasysh se ClickHouse \u00ebsht\u00eb optimizuar p\u00ebr performanc\u00eb?<\/p>\n
<\/p>\n
P\u00ebrgjigja \u00ebsht\u00eb \u2013 gjith\u00e7ka \u00ebsht\u00eb n\u00eb rregull! Nuk do e shpjegoj n\u00eb detaje, ky \u00ebsht\u00eb nj\u00eb tem\u00eb e nj\u00eb raporti tjet\u00ebr. <\/p>\n
<\/p>\n
<\/p>\n
Por ka nj\u00eb projekt t\u00eb till\u00eb si TSBS. Cila \u00ebsht\u00eb q\u00ebllimi i tij kryesor? Ky \u00ebsht\u00eb nj\u00eb test p\u00ebr performanc\u00ebn e bazave t\u00eb t\u00eb dh\u00ebnave. Kjo \u00ebsht\u00eb nj\u00eb p\u00ebrpjekje p\u00ebr t\u00eb krahasuar t\u00eb ngrohtat me t\u00eb ngrohta, t\u00eb butat me t\u00eb buta. <\/p>\n
<\/p>\n
Si funksionon ai? Gjenerohet nj\u00eb grup i dh\u00ebnash. Pastaj ky grup i dh\u00ebnash kalon n\u00eb teste t\u00eb nj\u00ebjta mbi baza t\u00eb ndryshme t\u00eb t\u00eb dh\u00ebnave. Dhe \u00e7do baz\u00eb t\u00eb dh\u00ebnash zgjidh nj\u00eb problem ashtu si\u00e7 di t\u00eb b\u00ebj\u00eb. M\u00eb pas mund t\u00eb krahasosh rezultatet. <\/p>\n
<\/p>\n
Ai tashm\u00eb mb\u00ebshtet nj\u00eb mori t\u00eb madhe bazash t\u00eb t\u00eb dh\u00ebnave. Kam theksuar tre kryesoret. K\u00ebto jan\u00eb:<\/p>\n
<\/p>\n
\nTimescaleDB.<\/li>\n InfluxDB.<\/li>\n ClickHouse.<\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Gjithashtu, \u00ebsht\u00eb b\u00ebr\u00eb nj\u00eb krahasim me nj\u00eb zgjidhje tjet\u00ebr t\u00eb ngjashme. Krahasimi me RedShift. Krahasimi \u00ebsht\u00eb b\u00ebr\u00eb n\u00eb Amazon. ClickHouse gjithashtu e tejkalon t\u00eb gjitha n\u00eb k\u00ebt\u00eb aspekt. <\/p>\n
<\/p>\n
<\/p>\n
Cilat p\u00ebrfundime mund t\u00eb nxirren nga ajo q\u00eb kam treguar?<\/p>\n
<\/p>\n
\nDB n\u00eb Kubernetes \u00ebsht\u00eb i mundur. M\u00eb vjen keq, ndoshta mund t\u00eb jet\u00eb \u00e7do lloj, por n\u00eb p\u00ebrgjith\u00ebsi duket se \u00ebsht\u00eb e mundur. ClickHouse n\u00eb Kubernetes me siguri \u00ebsht\u00eb e mundur fal\u00eb operatorit ton\u00eb. <\/li>\n Operatori ndihmon n\u00eb automatizimin e proceseve dhe v\u00ebrtet leht\u00ebson jet\u00ebn.<\/li>\n Performanca \u00ebsht\u00eb normale.<\/li>\n Dhe, na duket se kjo mund dhe duhet t\u00eb p\u00ebrdoret. <\/li>\n<\/ul>\n<\/p>\n
Open source \u2013 bashkohuni!<\/p>\n
<\/p>\n
Si\u00e7 kam th\u00ebn\u00eb m\u00eb par\u00eb, operatori \u00ebsht\u00eb nj\u00eb produkt plot\u00ebsisht open source, prandaj do t\u00eb ishte shum\u00eb e mir\u00eb n\u00ebse numri maksimal i njer\u00ebzve e p\u00ebrdor at\u00eb. Bashkohuni! Ne po ju presim ju t\u00eb gjith\u00eb!<\/p>\n
<\/p>\n
Faleminderit t\u00eb gjith\u00ebve!<\/p>\n
<\/p>\n
Pyetje<\/p>\n
<\/p>\n
<\/p>\n
Faleminderit p\u00ebr raportin! Un\u00eb quhem Anton. Jam nga kompania SEMrush. M\u00eb intereson \u00e7\u00ebshtja e logimit. P\u00ebr monitorimin ka informacion, por p\u00ebr logimin asgj\u00eb, n\u00ebse flasim p\u00ebr klasterin n\u00eb t\u00ebr\u00ebsi. Ne, p\u00ebr shembull, kemi ngritur nj\u00eb klaster n\u00eb pajisje. Dhe ne p\u00ebrdorim logimin qendror, mbledhim me mjete standarde n\u00eb nj\u00eb grumbull t\u00eb p\u00ebrbashk\u00ebt. Dhe pastaj e nxjerrim informacionin q\u00eb na intereson nga atje.<\/em> <\/p>\n<\/p>\n
Nj\u00eb pyetje e mir\u00eb, pra, logimi \u00ebsht\u00eb n\u00eb list\u00ebn e pun\u00ebve. Operator nuk e automatizon ende k\u00ebt\u00eb. Ai ende po zhvillohet, projekti \u00ebsht\u00eb ende mjaft i ri. Ne e kuptojm\u00eb domosdoshm\u00ebrin\u00eb e logimit. Kjo gjithashtu \u00ebsht\u00eb nj\u00eb tem\u00eb shum\u00eb e r\u00ebnd\u00ebsishme. Dhe ndoshta nuk \u00ebsht\u00eb m\u00eb pak e r\u00ebnd\u00ebsishme se monitorimi. Por e para n\u00eb list\u00ebn p\u00ebr realizim ka qen\u00eb monitorimi. Logimi do t\u00eb vij\u00eb. Ne, natyrisht, p\u00ebrpiqemi t\u00eb automatizojm\u00eb t\u00eb gjitha aspektet e jet\u00ebs s\u00eb klasterit. Prandaj p\u00ebrgjigjja \u2013 p\u00ebr momentin operatori, fatkeq\u00ebsisht, nuk e di k\u00ebt\u00eb, por \u00ebsht\u00eb n\u00eb planet tona, do ta b\u00ebjm\u00eb. N\u00ebse keni d\u00ebshir\u00eb t\u00eb bashkoheni, at\u00ebher\u00eb b\u00ebni nj\u00eb pull request, ju lutem.<\/p>\n
<\/p>\n
P\u00ebrsh\u00ebndetje! Faleminderit p\u00ebr raportin! Kam nj\u00eb pyetje standarde, t\u00eb lidhur me V\u00ebllimet e P\u00ebrhershme. Kur krijojm\u00eb nj\u00eb konfiguracion me k\u00ebt\u00eb operator, si e p\u00ebrcakton operatori se n\u00eb cilin nod\u00eb \u00ebsht\u00eb montuar ndonj\u00eb disk, ose dosje? A duhet ta sqarojm\u00eb paraprakisht se, ju lutem, vendosni ClickHouse ton\u00eb pik\u00ebrisht n\u00eb k\u00ebto nod\u00eb, n\u00eb t\u00eb cilat ka disk?<\/em><\/p>\n<\/p>\n
Sipas asaj q\u00eb kuptoj, kjo pyetje \u00ebsht\u00eb nj\u00eb vazhdim i ruajtjes lokale, ve\u00e7an\u00ebrisht pjes\u00ebs s\u00eb saj p\u00ebr hostPath. \u00cbsht\u00eb si t\u00eb shpjegosh gjith\u00eb sistemin se duhet q\u00eb pod-i t\u00eb jet\u00eb aktivizuar pik\u00ebrisht n\u00eb nj\u00eb nod\u00eb t\u00eb till\u00eb, n\u00eb t\u00eb cil\u00ebn kemi disk fizik t\u00eb lidhur, i cili \u00ebsht\u00eb montuar n\u00eb nj\u00eb rrug\u00eb t\u00eb till\u00eb. Kjo \u00ebsht\u00eb nj\u00eb seksion e t\u00ebr\u00eb, t\u00eb cilin e kam prekur shum\u00eb sip\u00ebrfaq\u00ebsisht, sepse p\u00ebrgjigjja \u00ebsht\u00eb mjaft e gjat\u00eb. <\/p>\n
<\/p>\n
N\u00eb thelb, kjo duket k\u00ebshtu. Natyrisht, na nevojitet t\u00eb b\u00ebjm\u00eb provisioning t\u00eb k\u00ebtyre volumes. Aktualisht, n\u00eb storage lokal nuk ka provisioning dinamik, prandaj DevOps duhet t\u00eb krijojn\u00eb vet\u00eb disk\u00ebt, k\u00ebto volumes. Ata duhet t\u00eb shpjegojn\u00eb Kubernetes provisioning, se do t\u00eb keni Persistent volumes t\u00eb nj\u00eb klase t\u00eb caktuar, t\u00eb cilat ndodhen n\u00eb node t\u00eb caktuar. M\u00eb pas, duhet t\u00eb shpjegohet Kubernetes, se pod\u2019\u00ebt q\u00eb k\u00ebrkojn\u00eb nj\u00eb klas\u00eb t\u00eb till\u00eb storage lokal, duhet t\u00eb planifikohen vet\u00ebm n\u00eb ato node, p\u00ebrmes labels. P\u00ebr k\u00ebto q\u00ebllime, operatori ka mund\u00ebsin\u00eb t\u00eb caktoj\u00eb nj\u00eb label dhe one per host instance. Dhe do t\u00eb rezultoj\u00eb se pod\u2019\u00ebt do t\u00eb rregullohen nga Kubernetes p\u00ebr t'u nisur vet\u00ebm n\u00eb node q\u00eb p\u00ebrmbushin k\u00ebrkesat e labels, duke folur n\u00eb terma t\u00eb thjesht\u00eb. Administrator\u00ebt caktojn\u00eb labels, b\u00ebjn\u00eb provisioning t\u00eb disk\u00ebve manualisht. Dhe at\u00ebher\u00eb kjo do t\u00eb shkall\u00ebzohet.<\/p>\n
<\/p>\n
Dhe pik\u00ebrisht opsioni i tret\u00eb lokal ndihmon ta leht\u00ebsoj\u00eb k\u00ebt\u00eb. Si\u00e7 e kam theksuar, \u00ebsht\u00eb nj\u00eb pun\u00eb e im\u00ebt e konfigurimit, q\u00eb n\u00eb fund ndihmon p\u00ebr t\u00eb arritur performanc\u00ebn maksimale.<\/p>\n
<\/p>\n
Kam nj\u00eb pyetje tjet\u00ebr, e lidhur me k\u00ebt\u00eb. Kubernetes \u00ebsht\u00eb menduar k\u00ebshtu, q\u00eb nuk ka r\u00ebnd\u00ebsi n\u00ebse humbim apo jo nj\u00eb node. \u00c7far\u00eb duhet t\u00eb b\u00ebjm\u00eb n\u00eb k\u00ebt\u00eb rast, n\u00ebse e humb\u00ebm node\u2019in ku ndodhet nj\u00eb shard?<\/em><\/p>\n<\/p>\n
Po, Kubernetes origjinalisht \u00ebsht\u00eb pozicionuar q\u00eb marr\u00ebdh\u00ebnia jon\u00eb me pod\u2019\u00ebt tan\u00eb \u00ebsht\u00eb si me bag\u00ebtit\u00eb, por k\u00ebtu \u00e7do disk b\u00ebhet si nj\u00eb kafsh\u00eb e dashur. Ka nj\u00eb problem, q\u00eb nuk mund t'i hedhim ata thjesht k\u00ebshtu. Dhe zhvillimi i Kubernetes shkon n\u00eb drejtimin q\u00eb nuk \u00ebsht\u00eb e mundur t\u00eb shohim gjith\u00e7ka filozofikisht si burime q\u00eb mund t\u00eb hidhen plot\u00ebsisht.<\/p>\n
<\/p>\n
Tani, nj\u00eb pyetje praktike. \u00c7far\u00eb t\u00eb b\u00ebni, n\u00ebse ju ka humbur nj\u00eb node, n\u00eb t\u00eb cilin ishte disk? K\u00ebtu, detyra zgjidhet n\u00eb nj\u00eb nivel m\u00eb t\u00eb lart\u00eb. N\u00eb rastin e ClickHouse, kemi replika q\u00eb punojn\u00eb n\u00eb nj\u00eb nivel m\u00eb t\u00eb lart\u00eb, pra n\u00eb nivelin e ClickHouse.<\/p>\n
<\/p>\n
Cila \u00ebsht\u00eb dispozita rezultuese? P\u00ebr t\u00eb siguruar q\u00eb t\u00eb dh\u00ebnat t\u00eb mos humbin \u00ebsht\u00eb p\u00ebrgjegj\u00ebsi e DevOps. Ai duhet ta konfiguronte si\u00e7 duhet replikimin dhe duhet t\u00eb p\u00ebrpiqet q\u00eb replikimi t\u00eb ekzekutohet. N\u00eb replik\u00ebn n\u00eb nivelin e ClickHouse, t\u00eb dh\u00ebnat duhet t\u00eb jen\u00eb t\u00eb duplikatuara. Kjo nuk \u00ebsht\u00eb nj\u00eb detyr\u00eb q\u00eb e zgjidh operatori. Dhe nuk \u00ebsht\u00eb nj\u00eb detyr\u00eb q\u00eb e zgjidh vet\u00eb Kubernetes. Kjo \u00ebsht\u00eb n\u00eb nivelin e ClickHouse.<\/p>\n
<\/p>\n
\u00c7far\u00eb duhet t\u00eb b\u00ebni n\u00ebse nj\u00eb nod\u00eb e fort\u00eb ka r\u00ebn\u00eb? Duket se do t\u00eb duhet t\u00eb vendosni nj\u00eb t\u00eb dyt\u00eb, ta konfiguroni si\u00e7 duhet diskun, dhe t\u00eb aplikoni etiketat. Pas k\u00ebsaj, ajo do t\u00eb p\u00ebrmbush\u00eb k\u00ebrkesat q\u00eb Kubernetes mund t\u00eb filloj\u00eb nj\u00eb instanc\u00eb pod-i mbi t\u00eb. Kubernetes do ta nis\u00eb at\u00eb. Numri juaj i pod-eve nuk \u00ebsht\u00eb i mjaftuesh\u00ebm sipas k\u00ebrkesave. Ajo do t\u00eb kaloj\u00eb n\u00ebp\u00ebr ciklin q\u00eb un\u00eb tregova. Dhe n\u00eb nivelin m\u00eb t\u00eb lart\u00eb, ClickHouse do t\u00eb kuptoj\u00eb q\u00eb kemi nj\u00eb replik\u00eb, ajo \u00ebsht\u00eb ende bosh dhe duhet t\u00eb fillojm\u00eb t\u00eb transferojm\u00eb t\u00eb dh\u00ebna mbi t\u00eb. Pra, ky proces \u00ebsht\u00eb ende pak i automatizuar. <\/p>\n
<\/p>\n
Faleminderit p\u00ebr elaborimin! Kur ndodhin disa gj\u00ebra t\u00eb k\u00ebqija, operatori bie dhe rilansohet, dhe n\u00eb k\u00ebt\u00eb moment ndodhin ngjarje, a e p\u00ebrpunoni ndonj\u00ebher\u00eb at\u00eb?<\/em><\/p>\n<\/p>\n
\u00c7far\u00eb do t\u00eb ndodh\u00eb n\u00ebse operatori ka r\u00ebn\u00eb dhe \u00ebsht\u00eb rilansuar, apo jo? <\/p>\n
<\/p>\n
Po. Dhe n\u00eb k\u00ebt\u00eb moment kan\u00eb ndodhur ngjarje.<\/em> <\/p>\n<\/p>\n
Detyra, \u00e7far\u00eb t\u00eb b\u00ebjm\u00eb n\u00eb k\u00ebt\u00eb rast, ndahen pjes\u00ebrisht midis operatorit dhe Kubernetes. Kubernetes ka mund\u00ebsin\u00eb t\u00eb riprodhoj\u00eb ngjarjen q\u00eb ndodhi. Ai e riprodhon. Dhe detyra e operatorit \u00ebsht\u00eb t\u00eb siguroj\u00eb q\u00eb kur i b\u00ebhet riprodhimi i logjeve t\u00eb ngjarjeve, k\u00ebto ngjarje t\u00eb jen\u00eb idempotente. Dhe p\u00ebr t\u00eb siguruar q\u00eb p\u00ebrs\u00ebritja e t\u00eb nj\u00ebjt\u00ebs ngjarje nuk shkakton d\u00ebme n\u00eb sistemin ton\u00eb. Dhe operatori yn\u00eb e kryen k\u00ebt\u00eb detyr\u00eb. <\/p>\n
<\/p>\n
P\u00ebrsh\u00ebndetje! Faleminderit p\u00ebr elaborimin! Dmitry Zavyalov, kompani<\/em> Smedova. A \u00ebsht\u00eb planifikuar shtimi i mund\u00ebsis\u00eb s\u00eb konfigurimit me haproxy n\u00eb operator? M\u00eb intereson ndonj\u00eb balancues tjet\u00ebr p\u00ebrve\u00e7 standardit, n\u00eb m\u00ebnyr\u00eb q\u00eb t\u00eb jet\u00eb inteligjent dhe t\u00eb kuptoj\u00eb se \u00e7far\u00eb \u00ebsht\u00eb realisht ClickHouse.<\/em> <\/p>\n<\/p>\n
A po flisni p\u00ebr Ingress?<\/p>\n
<\/p>\n
Po, z\u00ebvend\u00ebsoni Ingress me haproxy. N\u00eb haproxy mund t\u00eb specifikoni topologjin\u00eb e klasterit, ku ndodhen replikat.<\/em><\/p>\n<\/p>\n
Derisa ne nuk kemi menduar p\u00ebr k\u00ebt\u00eb. N\u00ebse ju nevojitet dhe mund t\u00eb shpjegoni pse \u00ebsht\u00eb e nevojshme, mund ta realizojm\u00eb, n\u00eb ve\u00e7anti n\u00ebse d\u00ebshironi t\u00eb merrni pjes\u00eb. Ne do ta shqyrtojm\u00eb me k\u00ebnaq\u00ebsi k\u00ebt\u00eb mund\u00ebsi. P\u00ebrgjigjja e shkurt\u00ebr \u2013 jo, p\u00ebr momentin nuk kemi nj\u00eb funksionalitet t\u00eb till\u00eb. Faleminderit p\u00ebr sugjerimin, ne do ta shqyrtojm\u00eb at\u00eb. N\u00ebse gjithashtu shpjegoni rastin e p\u00ebrdorimit dhe pse \u00ebsht\u00eb e nevojshme n\u00eb praktik\u00eb, p\u00ebr shembull, krijoni issues n\u00eb GitHub, do t\u00eb ishte mrekulli.<\/p>\n
<\/p>\n
Ajo ekziston tashm\u00eb.<\/em><\/p>\n<\/p>\n
Mir\u00eb. Ne jemi t\u00eb hapur p\u00ebr \u00e7do propozim. Dhe haproxy po shtohet n\u00eb list\u00ebn e pun\u00ebve p\u00ebr t'u b\u00ebr\u00eb. Lista e pun\u00ebve p\u00ebr t'u b\u00ebr\u00eb po rritet, dhe jo pak\u00ebsohet p\u00ebr momentin. Por kjo \u00ebsht\u00eb e mir\u00eb, do t\u00eb thot\u00eb q\u00eb produkti \u00ebsht\u00eb i k\u00ebrkuar.<\/p>\n
Burimi: 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
![\"Operatori](\"\/wp-content\/uploads\/2020\/10\/56e002c7408c4708e39ece867f84171e.jpeg\")
<\/p>\n