Local<\/li>\n<\/ul>\n<\/p>\n
S\u0103 vedem \u00een ce se diferen\u021biaz\u0103 \u0219i \u00een ce se aseam\u0103n\u0103. <\/p>\n
<\/p>\n
\u00cen primul r\u00e2nd, \u00een toate cele trei abord\u0103ri avem stocare \u2013 acestea sunt discurile locale care se afl\u0103 pe aceea\u0219i nod\u0103 fizic\u0103 k8s. Dar exist\u0103 unele diferen\u021be.<\/p>\n
<\/p>\n
<\/p>\n
S\u0103 \u00eencepem cu cel mai simplu, adic\u0103 cu emptyDir. Ce \u00eenseamn\u0103 acest lucru \u00een practic\u0103? Cerem sistemului de containerizare (cel mai adesea \u2013 Docker) s\u0103 ne ofere acces la un folder de pe discul local.<\/p>\n
<\/p>\n
\u00cen practic\u0103, Docker creeaz\u0103 undeva, pe c\u0103ile sale proprii, un folder temporar, numit cu un hash lung. \u0218i ofer\u0103 un interfa\u021b\u0103 de acces la acesta. <\/p>\n
<\/p>\n
Cum va func\u021biona aceasta \u00een ceea ce prive\u0219te performan\u021ba? Va func\u021biona cu viteza discului local, adic\u0103 este acces complet la propriul sistem de stocare. <\/p>\n
<\/p>\n
Dar acest lucru are un dezavantaj. Persistent \u00een aceast\u0103 situa\u021bie este destul de suspect. La prima mi\u0219care a Docker-ului cu containerele, Persistent se pierde. Dac\u0103 Kubernetes dore\u0219te dintr-un anumit motiv s\u0103 mute acest Pod pe un alt disc, datele se vor pierde. <\/p>\n
<\/p>\n
Aceast\u0103 abordare este bun\u0103 pentru teste, deoarece viteza este deja decent\u0103, dar pentru ceva serios, aceast\u0103 variant\u0103 nu se potrive\u0219te. <\/p>\n
<\/p>\n
<\/p>\n
Prin urmare, exist\u0103 a doua abordare. Aceasta este hostPath. Dac\u0103 ne uit\u0103m la diapozitivul anterior \u0219i la acesta, putem observa o singur\u0103 diferen\u021b\u0103. Folderul a ie\u0219it din Docker direct pe nodul Kubernetes. Aici e pu\u021bin mai simplu. Specific\u0103m direct calea pe sistemul de fi\u0219iere local, unde am dori s\u0103 ne stoc\u0103m datele. <\/p>\n
<\/p>\n
Avantajele acestei metode exist\u0103. Acesta este un adev\u0103rat Persistent, \u00een plus, clasic. Datele noastre vor fi scrise pe disc la o anumit\u0103 adres\u0103. <\/p>\n
<\/p>\n
Exist\u0103 \u0219i dezavantaje. Acesta este complexitatea gestion\u0103rii. Kubernetes-ul nostru poate dori s\u0103 mute un Pod pe un alt nod fizic. Aici intervine DevOps. El trebuie s\u0103 explice corect \u00eentregului sistem c\u0103 aceste pod-uri pot fi mutate doar pe acele noduri pe care ai ceva montat pe acele c\u0103i, \u0219i nu mai mult de un nod pe dat\u0103. Acest lucru este destul de complicat. <\/p>\n
<\/p>\n
Special pentru aceste scopuri, la noi, \u00een operator, am creat \u0219abloane pentru a ascunde toat\u0103 aceast\u0103 complexitate. \u0218i s-ar putea pur \u0219i simplu s\u0103 spunem: \u201eVreau s\u0103 am un instance ClickHouse pe fiecare nod fizic \u0219i pe un anumit drum.\u201d <\/p>\n
<\/p>\n
<\/p>\n
Dar aceast\u0103 necesitate nu este doar a noastr\u0103, de aceea domnii din Kubernetes \u00een\u021beleg \u0219i ele c\u0103 oamenii doresc acces la discurile fizice, a\u0219a c\u0103 ofer\u0103 un al treilea nivel.<\/p>\n
<\/p>\n
Se nume\u0219te local. Practic, nu exist\u0103 nicio diferen\u021b\u0103 fa\u021b\u0103 de diapozitivul anterior. Doar c\u0103 \u00eenainte trebuia s\u0103 facem manual ceea ce nu permitea mutarea acestor pod-uri de la un nod la altul, deoarece acestea trebuiau s\u0103 fie ata\u0219ate pe o anumit\u0103 cale la un disc fizic local, iar acum toate aceste cuno\u0219tin\u021be sunt \u00eencapsulate \u00een Kubernetes. \u0218i devine mult mai simplu de configurat.<\/p>\n
<\/p>\n
<\/p>\n
S\u0103 ne \u00eentoarcem la sarcina noastr\u0103 practic\u0103. S\u0103 ne \u00eentoarcem la \u0219ablonul YAML. Aici ne-a ap\u0103rut un adev\u0103rat storage. Ne-am \u00eentors la acest lucru. Definim un \u0219ablon clasic de VolumeClaim ca \u00een k8s. \u0218i descriem ce storage dorim.<\/p>\n
<\/p>\n
Dup\u0103 aceasta, k8s va solicita storage. Ne va aloca \u00een StatefulSet. Iar \u00een cele din urm\u0103, acesta va fi la dispozi\u021bia ClickHouse.<\/p>\n
<\/p>\n
<\/p>\n
A avut o schem\u0103 de acest fel. Storage-ul nostru Persistent a fost ro\u0219u, ceea ce sugera c\u0103 ar trebui s\u0103-l cre\u0103m. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i devine verde. Acum schema cluster-ului ClickHouse pe k8s este complet finalizat\u0103. Avem sharde, replici, ZooKeeper, exist\u0103 un Persistent adev\u0103rat, care este realizat \u00eentr-un mod sau altul. Schema este deja complet func\u021bional\u0103. <\/p>\n
<\/p>\n
<\/p>\n
Continu\u0103m s\u0103 tr\u0103im mai departe. Cluster-ul nostru se dezvolt\u0103. \u0218i Alexey se str\u0103duie\u0219te \u0219i lanseaz\u0103 o nou\u0103 versiune a ClickHouse.<\/p>\n
<\/p>\n
Se ridic\u0103 o sarcin\u0103 practic\u0103 \u2013 s\u0103 test\u0103m noua versiune a ClickHouse pe cluster-ul nostru. \u0218i, desigur, nu vrem s\u0103 o aplic\u0103m \u00een \u00eentregime, vrem s\u0103 punem o nou\u0103 versiune undeva \u00eentr-un col\u021b \u00eendep\u0103rtat, poate chiar dou\u0103 versiuni noi, pentru c\u0103 acestea apar destul de des. <\/p>\n
<\/p>\n
Ce putem spune despre asta?<\/p>\n
<\/p>\n
<\/p>\n
Aici avem exact aceast\u0103 oportunitate. Sunt \u0219abloanele de pod-uri. Putem detalia, operatorul nostru permite complet construirea unui cluster heterogen. Adic\u0103, configur\u00e2nd, \u00eencep\u00e2nd de la toate replicile ca un \u00eentreg, p\u00e2n\u0103 la fiecare replic\u0103 personalizat\u0103 pentru a alege ce versiune de ClickHouse dorim, ce versiune de stocare dorim. Putem configura complet un cluster cu aceast\u0103 configura\u021bie, a\u0219a cum avem nevoie. <\/p>\n
<\/p>\n
<\/p>\n
Vom p\u0103trunde pu\u021bin mai profund. P\u00e2n\u0103 acum am vorbit despre cum func\u021bioneaz\u0103 ClickHouse-operator \u00een raport cu specificitatea ClickHouse.<\/p>\n
<\/p>\n
Acum a\u0219 dori s\u0103 spun c\u00e2teva cuvinte despre cum func\u021bioneaz\u0103 de fapt orice operator, precum \u0219i despre cum interac\u021bioneaz\u0103 cu K8s.<\/p>\n
<\/p>\n
<\/p>\n
S\u0103 analiz\u0103m interac\u021biunea cu K8s la \u00eenceput. Ce se \u00eent\u00e2mpl\u0103 c\u00e2nd facem kubectl apply? Obiectele noastre apar \u00een etcd prin API. <\/p>\n
<\/p>\n
<\/p>\n
De exemplu, obiectele de baz\u0103 Kubernetes: pod, StatefulSet, service \u0219i a\u0219a mai departe. <\/p>\n
<\/p>\n
\u00cen acest moment, nimic fizic nu se \u00eent\u00e2mpl\u0103 \u00eenc\u0103. Aceste obiecte trebuie materializate \u00een cluster. <\/p>\n
<\/p>\n
<\/p>\n
Pentru aceasta, apare un controller. Controller-ul este un component special K8s, care \u0219tie s\u0103 materializeze aceste descrieri. \u0218tie cum \u0219i ce trebuie f\u0103cut fizic. \u0218tie cum s\u0103 lanseze containere, ce trebuie configurat pentru ca serverul s\u0103 func\u021bioneze. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i el materializeaz\u0103 obiectele noastre \u00een K8s.<\/p>\n
<\/p>\n
Dar vrem s\u0103 oper\u0103m nu doar cu pod-uri, StatefulSet-uri, vrem s\u0103 cre\u0103m ClickHouseInstallation, adic\u0103 un obiect de tip ClickHouse, pentru a opera cu acesta ca un \u00eentreg. Deocamdat\u0103, nu exist\u0103 aceast\u0103 posibilitate. <\/p>\n
<\/p>\n
<\/p>\n
Dar K8s are urm\u0103toarea caracteristic\u0103 pl\u0103cut\u0103. Vrem s\u0103 avem un fel de entitate complex\u0103 acolo, care s\u0103 fie alc\u0103tuit\u0103 din pod-uri \u0219i StatefulSet, form\u00e2nd clusterul nostru. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i ce trebuie f\u0103cut pentru aceasta? \u00cen primul r\u00e2nd, intr\u0103 \u00een scen\u0103 Custom Resource Definition. Ce este aceasta? Este o descriere pentru K8s, c\u0103 vei avea un alt tip de date, c\u0103 vrem s\u0103 ad\u0103ug\u0103m un resurs\u0103 personalizat\u0103 la pod, StatefulSet, care va fi complex\u0103 \u00een interior. Este o descriere a structurii datelor. <\/p>\n
<\/p>\n
<\/p>\n
De asemenea, o trimitem acolo prin kubectl apply. Kubernetes a preluat-o cu bucurie. <\/p>\n
<\/p>\n
\u0218i acum avem \u00een stocare, la obiectul din etcd, posibilitatea de a \u00eenregistra o resurs\u0103 personalizat\u0103 numit\u0103 ClickHouseInstallation.<\/p>\n
<\/p>\n
\u00cens\u0103, p\u00e2n\u0103 acum, nu se va \u00eent\u00e2mpla nimic. Adic\u0103, dac\u0103 acum cre\u0103m un fi\u0219ier YAML, pe care l-am discutat, cu descrierea shard-urilor, replicatelor \u0219i spunem \u201ekubectl apply\u201d, Kubernetes \u00eel va accepta, \u00eel va pune \u00een etcd \u0219i va spune: \u201eExcelent, dar nu \u0219tiu ce s\u0103 fac cu el. Nu \u0219tiu cum s\u0103 \u00eentre\u021bin ClickHouseInstallation.\u201d <\/p>\n
<\/p>\n
<\/p>\n
Prin urmare, avem nevoie de cineva care s\u0103 ajute Kubernetes s\u0103 \u00eentre\u021bin\u0103 un nou tip de date. \u00cen st\u00e2nga avem un controler Kubernetes standard care lucreaz\u0103 cu tipuri de date standard. Iar \u00een dreapta ar trebui s\u0103 apar\u0103 un controler personalizat, care \u0219tie s\u0103 lucreze cu tipuri de date personalizate. <\/p>\n
<\/p>\n
\u0218i, pe scurt, acesta se nume\u0219te operator. L-am scos aici din Kubernetes, deoarece poate fi executat \u0219i \u00een afara K8s. Cel mai adesea, bine\u00een\u021beles, to\u021bi operatorii ruleaz\u0103 \u00een Kubernetes, dar nimic nu \u00eei \u00eempiedic\u0103 s\u0103 func\u021bioneze din exterior, a\u0219a c\u0103 l-am scos special afar\u0103. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i, la r\u00e2ndul s\u0103u, controlerul personalizat, adic\u0103 operatorul, interac\u021bioneaz\u0103 cu Kubernetes prin API. Acesta deja \u0219tie cum s\u0103 interac\u021bioneze cu API-ul \u0219i \u0219tie cum s\u0103 materializeze o schem\u0103 complex\u0103 din resursa personalizat\u0103 pe care dorim s\u0103 o realiz\u0103m. Aceasta este exact ceea ce face operatorul. <\/p>\n
<\/p>\n
<\/p>\n
Cum func\u021bioneaz\u0103 operatorul? Haide\u021bi s\u0103 ne uit\u0103m \u00een partea dreapt\u0103 pentru a descoperi cum face acest lucru. Vom \u00eenv\u0103\u021ba cum operatorul materializeaz\u0103 totul \u0219i cum continu\u0103 interac\u021biunea cu K8s.<\/p>\n
<\/p>\n
<\/p>\n
Operatorul este un program. Este orientat pe evenimente. Operatorul, cu ajutorul API-ului Kubernetes, se aboneaz\u0103 la evenimente. \u00cen API-ul Kubernetes exist\u0103 puncte de intrare la care se poate abona pentru evenimente. \u0218i dac\u0103 ceva se schimb\u0103 \u00een K8s, Kubernetes trimite evenimente tuturor celor care doresc, adic\u0103 cine s-a abonat la acest punct API va primi notific\u0103ri.<\/p>\n
<\/p>\n
Operatorul se aboneaz\u0103 la evenimente \u0219i trebuie s\u0103 fac\u0103 o reac\u021bie. Sarcina sa este s\u0103 reac\u021bioneze la evenimentele care apar. <\/p>\n
<\/p>\n
<\/p>\n
Evenimentele sunt generate de anumite actualiz\u0103ri. Vine fi\u0219ierul nostru YAML cu descrierea ClickHouseInstallation. Acesta, prin kubectl apply, a fost trimis \u00een etcd. Acolo s-a activat un eveniment, iar acest eveniment a ajuns la ClickHouse-operator. Operatorul a primit aceast\u0103 descriere \u0219i trebuie s\u0103 fac\u0103 ceva. Dac\u0103 s-a primit o actualizare pentru obiectul ClickHouseInstallation, trebuie s\u0103 actualiz\u0103m clusterul. Sarcina operatorului este s\u0103 actualizeze clusterul. <\/p>\n
<\/p>\n
<\/p>\n
Ce face el? \u00cen primul r\u00e2nd, trebuie s\u0103 elabor\u0103m un plan de ac\u021biune pentru ceea ce vom face cu aceast\u0103 actualizare. Actualiz\u0103rile pot fi foarte mici, adic\u0103 mici \u00een execu\u021bia YAML, dar pot aduce modific\u0103ri foarte mari \u00een cluster. De aceea, operatorul creeaz\u0103 un plan \u0219i apoi se \u021bine de el.<\/p>\n
<\/p>\n
<\/p>\n
El \u00eencepe, conform acestui plan, s\u0103 construiasc\u0103 aceast\u0103 structur\u0103 \u00een interior pentru a materializa podurile, serviciile, adic\u0103 pentru a face ceea ce este sarcina sa principal\u0103. Este ca \u0219i cum ai construi un cluster ClickHouse \u00een Kubernetes.<\/p>\n
<\/p>\n
<\/p>\n
Acum s\u0103 discut\u0103m despre un aspect interesant. Aceasta este \u00eemp\u0103r\u021birea responsabilit\u0103\u021bilor \u00eentre Kubernetes \u0219i operator, adic\u0103 ce face Kubernetes, ce face operatorul \u0219i cum interac\u021bioneaz\u0103 \u00eentre ei. <\/p>\n
<\/p>\n
Kubernetes se ocup\u0103 de lucruri de sistem, adic\u0103 de un set de obiecte de baz\u0103 care pot fi interpretate ca av\u00e2nd un domeniu de sistem. Kubernetes \u0219tie cum s\u0103 ruleze poduri, cum s\u0103 reporneasc\u0103 containere, cum s\u0103 monteze volume, cum s\u0103 lucreze cu ConfigMap, adic\u0103 tot ce poate fi numit sistem. <\/p>\n
<\/p>\n
Operatorii opereaz\u0103 \u00een domenii specifice. Fiecare operator este creat pentru domeniul s\u0103u specific. Noi am realizat unul pentru ClickHouse.<\/p>\n
<\/p>\n
\u0218i operatorul interac\u021bioneaz\u0103 exact \u00een termenii domeniului, cum ar fi ad\u0103ugarea unei replici, crearea unui schem\u0103, configurarea monitoriz\u0103rii. Astfel se realizeaz\u0103 aceast\u0103 \u00eemp\u0103r\u021bire.<\/p>\n
<\/p>\n
<\/p>\n
Haide\u021bi s\u0103 analiz\u0103m un exemplu practic, cum are loc aceast\u0103 \u00eemp\u0103r\u021bire a responsabilit\u0103\u021bilor atunci c\u00e2nd execut\u0103m ac\u021biunea de a ad\u0103uga o replic\u0103. <\/p>\n
<\/p>\n
La operator vine o solicitare \u2013 ad\u0103ugarea unei replici. Ce face operatorul? Operatorul va calcula c\u0103 trebuie s\u0103 creeze un nou StatefulSet, \u00een care trebuie s\u0103 descrie anumite \u0219abloane \u0219i cerin\u021be de volum. <\/p>\n
<\/p>\n
<\/p>\n
El preg\u0103te\u0219te totul \u0219i transmite mai departe \u00een K8s. Spune c\u0103 are nevoie de ConfigMap, StatefulSet, Volume. Kubernetes \u00ee\u0219i \u00eendepline\u0219te sarcinile. El materializeaz\u0103 unit\u0103\u021bile de baz\u0103 cu care opereaz\u0103. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i apoi intervine din nou ClickHouse-operator. Acesta are deja un pod fizic, pe care se poate lucra. Iar ClickHouse-operator lucreaz\u0103 din nou \u00een termenii domeniului. Adic\u0103, \u00een cazul specific al ClickHouse, pentru a activa o replic\u0103 \u00een cluster, trebuie, \u00een primul r\u00e2nd, s\u0103 configureze schema de date care exist\u0103 \u00een acest cluster. Iar, \u00een al doilea r\u00e2nd, aceast\u0103 replic\u0103 trebuie s\u0103 fie inclus\u0103 \u00een monitorizare, pentru a fi bine urm\u0103rit\u0103. Aceste set\u0103ri le face operatorul. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i doar dup\u0103 aceea intervine ClickHouse, adic\u0103 o entitate de nivel superior. Aceasta este deja o baz\u0103 de date. Are propria instan\u021b\u0103, o replic\u0103 configurat\u0103, care este preg\u0103tit\u0103 s\u0103 intre \u00een cluster.<\/p>\n
<\/p>\n
A\u0219adar, lan\u021bul de execu\u021bie \u0219i separarea responsabilit\u0103\u021bilor la ad\u0103ugarea unei replici este destul de lung.<\/p>\n
<\/p>\n
<\/p>\n
Continu\u0103m cu sarcinile noastre practice. Dac\u0103 clusterul exist\u0103 deja, se poate efectua migrarea configura\u021biei. <\/p>\n
<\/p>\n
<\/p>\n
Am realizat astfel \u00eenc\u00e2t \u00een XML-ul existent, pe care ClickHouse \u00eel \u00een\u021belege, s\u0103 putem introduce date direct.<\/p>\n
<\/p>\n
<\/p>\n
Se poate face o ajustare fin\u0103 a ClickHouse. Implementarea zonat\u0103 este exact ceea ce am explicat c\u00e2nd am vorbit despre hostPath, stocare local\u0103. Este modul corect de a face o implementare zonat\u0103.<\/p>\n
<\/p>\n
<\/p>\n
Urm\u0103toarea sarcin\u0103 practic\u0103 este monitorizarea.<\/p>\n
<\/p>\n
<\/p>\n
Dac\u0103 clusterul nostru se schimb\u0103, trebuie s\u0103 configur\u0103m periodic monitorizarea. <\/p>\n
<\/p>\n
S\u0103 examin\u0103m schema. S\u0103 zicem c\u0103 s\u0103ge\u021bile verzi le-am discutat deja. Acum s\u0103 analiz\u0103m s\u0103ge\u021bile ro\u0219ii. Acestea arat\u0103 cum dorim s\u0103 monitoriz\u0103m clusterul nostru. Cum metricile din clusterul ClickHouse ajung \u00een Prometheus, iar apoi \u00een Grafana.<\/p>\n
<\/p>\n
<\/p>\n
Care este dificultatea asociat\u0103 cu monitorizarea? De ce este considerat\u0103 o realizare? Dificultatea const\u0103 \u00een dinamic\u0103. C\u00e2nd avem un cluster static, putem configura o dat\u0103 monitorizarea \u0219i apoi s\u0103 nu mai avem griji.<\/p>\n
<\/p>\n
Dar dac\u0103 avem multe clustere sau se schimb\u0103 constant ceva, procesul devine dinamic. A\u0219adar, a reconfigura constant monitorizarea consum\u0103 resurse \u0219i timp, adic\u0103 devine pur \u0219i simplu o povar\u0103. Trebuie s\u0103 automatiz\u0103m acest lucru. Dificultatea rezid\u0103 \u00een dinamica procesului. Iar operatorul automatizeaz\u0103 foarte bine acest lucru. <\/p>\n
<\/p>\n
<\/p>\n
Cum s-a dezvoltat clusterul nostru? La \u00eenceput a fost a\u0219a.<\/p>\n
<\/p>\n
<\/p>\n
Apoi a fost a\u0219a.<\/p>\n
<\/p>\n
<\/p>\n
\u00cen final, a ajuns s\u0103 fie astfel. <\/p>\n
<\/p>\n
Iar monitorizarea se face automat de c\u0103tre operator. Exist\u0103 un punct unic de acces. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i noi doar ne uit\u0103m la tabloul de bord Grafana, observ\u00e2nd cum via\u021ba din interiorul clusterului nostru se desf\u0103\u0219oar\u0103. <\/p>\n
<\/p>\n
Apropo, tabloul de bord Grafana este de asemenea distribuit cu operatorul nostru direct \u00een surs\u0103. Poate fi conectat \u0219i utilizat. Aceast\u0103 captur\u0103 de ecran mi-a fost oferit\u0103 de echipa noastr\u0103 DevOps.<\/p>\n
<\/p>\n
<\/p>\n
\u00cencotro ne dorim s\u0103 mergem mai departe? Este:<\/p>\n
<\/p>\n
\nS\u0103 dezvolt\u0103m automatizarea test\u0103rii. Obiectivul principal este testarea automat\u0103 a noilor versiuni. <\/li>\n De asemenea, dorim foarte mult s\u0103 automatiz\u0103m integrarea cu ZooKeeper. \u00cen plan este integrarea cu ZooKeeper-operator. Adic\u0103, pentru ZooKeeper a fost scris un operator \u0219i este logic ca cele dou\u0103 opera\u021bii s\u0103 \u00eenceap\u0103 s\u0103 se integreze pentru a construi o solu\u021bie mai convenabil\u0103. <\/li>\n Dorim s\u0103 facem verific\u0103ri de s\u0103n\u0103tate mai complexe. <\/li>\n Am eviden\u021biat \u00een verde ceea ce ne apropie de mo\u0219tenirea Templates \u2013 GATA, adic\u0103, cu urm\u0103toarea versiune a operatorului vom avea deja mo\u0219tenirea \u0219abloanelor. Acesta este un instrument puternic care permite construirea de configura\u021bii complexe din fragmente. <\/li>\n \u0218i dorim automatizarea sarcinilor complexe. Principal\u0103 dintre acestea este Re-sharding. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
S\u0103 facem un bilan\u021b intermediar. <\/p>\n
<\/p>\n
<\/p>\n
Ce ob\u021binem la sf\u00e2r\u0219it? \u0218i merit\u0103 s\u0103 ne ocup\u0103m de asta sau nu? Trebuie s\u0103 \u00eencerc\u0103m s\u0103 aducem baza de date \u00een Kubernetes \u0219i s\u0103 aplic\u0103m operatorul \u00een general \u0219i operatorul Alitnity \u00een special.<\/p>\n
<\/p>\n
La sf\u00e2r\u0219it ob\u021binem:<\/p>\n
<\/p>\n
\nO substan\u021bial\u0103 simplificare \u0219i automatizare a configur\u0103rii, desf\u0103\u0219ur\u0103rii, precum \u0219i \u00eentre\u021binerii. <\/li>\n Monitorizare \u00eencorporat\u0103 imediat. <\/li>\n \u0218i \u0219abloane codificate gata de utilizare pentru situa\u021bii complexe. Acum, ac\u021biune de tipul ad\u0103ug\u0103rii unei replici nu trebuie efectuat\u0103 manual. Asta face operatorul. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
A r\u0103mas doar o ultim\u0103 \u00eentrebare. Avem deja baza de date \u00een Kubernetes, virtualizare. Ce este cu performan\u021ba unei astfel de solu\u021bii, mai ales av\u00e2nd \u00een vedere c\u0103 ClickHouse este optimizat pentru performan\u021b\u0103?<\/p>\n
<\/p>\n
R\u0103spunsul \u2013 totul este \u00een regul\u0103! Nu voi detalia asta, este un subiect pentru o alt\u0103 prezentare. <\/p>\n
<\/p>\n
<\/p>\n
Dar exist\u0103 un proiect numit TSBS. Care este principalul s\u0103u obiectiv? Este un test de performan\u021b\u0103 al bazelor de date. O \u00eencercare de a compara c\u0103ldura cu c\u0103ldura, moale cu moale. <\/p>\n
<\/p>\n
Cum func\u021bioneaz\u0103? Este generat un singur set de date. Apoi, acest set de date este rulat pe acela\u0219i set de teste pe diferite baze de date. \u0218i fiecare baz\u0103 de date rezolv\u0103 o problem\u0103 a\u0219a cum \u0219tie. Apoi, rezultatele pot fi comparate. <\/p>\n
<\/p>\n
Deja suport\u0103 o mul\u021bime mare de baze de date. Am eviden\u021biat trei principale. Acestea sunt:<\/p>\n
<\/p>\n
\nTimescaleDB.<\/li>\n InfluxDB.<\/li>\n ClickHouse.<\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
De asemenea, a fost efectuat\u0103 o compara\u021bie cu o alt\u0103 solu\u021bie similar\u0103. Compara\u021bia cu RedShift. Comparatia a fost realizat\u0103 pe Amazon. ClickHouse, de asemenea, dep\u0103\u0219e\u0219te pe to\u021bi \u00een aceast\u0103 privin\u021b\u0103. <\/p>\n
<\/p>\n
<\/p>\n
Ce concluzii se pot trasa din ceea ce am spus?<\/p>\n
<\/p>\n
\nBaza de date \u00een Kubernetes este posibil\u0103. Probabil, orice baz\u0103 de date ar putea fi utilizat\u0103, dar \u00een general, se pare c\u0103 este posibil. ClickHouse \u00een Kubernetes este cu siguran\u021b\u0103 posibil cu ajutorul operatorului nostru. <\/li>\n Operatorul ajut\u0103 la automatizarea proceselor \u0219i realmente simplific\u0103 via\u021ba.<\/li>\n Performan\u021ba este normal\u0103.<\/li>\n \u0218i, ni se pare c\u0103 aceasta poate \u0219i trebuie folosit\u0103. <\/li>\n<\/ul>\n<\/p>\n
Open source \u2013 al\u0103tura\u021bi-v\u0103!<\/p>\n
<\/p>\n
A\u0219a cum am spus, operatorul este un produs complet open source, a\u0219a c\u0103 ar fi foarte bine dac\u0103 un num\u0103r maxim de oameni l-ar folosi. Al\u0103tura\u021bi-v\u0103! V\u0103 a\u0219tept\u0103m pe to\u021bi!<\/p>\n
<\/p>\n
Mul\u021bumesc tuturor!<\/p>\n
<\/p>\n
\u00centreb\u0103ri<\/p>\n
<\/p>\n
<\/p>\n
Mul\u021bumesc pentru prezentare! M\u0103 numesc Anton. Sunt din compania SEMrush. M\u0103 intereseaz\u0103 ce se \u00eent\u00e2mpl\u0103 cu logarea. Se aude despre monitorizare, dar nimic despre logare, dac\u0103 vorbim despre \u00eentregul cluster. De exemplu, noi avem un cluster pe hardware. \u0218i folosim logare centralizat\u0103, adun\u00e2nd datele \u00een mod standard \u00een totalitate. \u0218i apoi extragem datele care ne intereseaz\u0103.<\/em> <\/p>\n<\/p>\n
\u00centrebare bun\u0103, adic\u0103 logarea este pe lista de sarcini. Operatorul nostru \u00een prezent nu automatizeaz\u0103 acest proces. \u00cenc\u0103 se dezvolt\u0103, proiectul este \u00eenc\u0103 destul de t\u00e2n\u0103r. \u00cen\u021belegem necesitatea log\u0103rii. Este, de asemenea, o tem\u0103 foarte important\u0103. \u0218i probabil c\u0103 nu este mai pu\u021bin important\u0103 dec\u00e2t monitorizarea. Dar primul pe lista de implementare a fost monitorizarea. Logarea va fi. Evident, ne str\u0103duim s\u0103 automatiz\u0103m toate aspectele legate de func\u021bionarea cluster-ului. Prin urmare, r\u0103spunsul este \u2013 \u00een prezent, operatorul, din p\u0103cate, nu \u0219tie s\u0103 fac\u0103 asta, dar este \u00een planuri, vom face asta. Dac\u0103 ave\u021bi dorin\u021ba de a v\u0103 al\u0103tura, v\u0103 rog, trimite\u021bi un pull request.<\/p>\n
<\/p>\n
Bun\u0103! Mul\u021bumesc pentru prezentare! Am o \u00eentrebare standard, legat\u0103 de Volume Persistente. C\u00e2nd cre\u0103m o configura\u021bie cu ajutorul acestui operator, cum determin\u0103 operatorul pe ce nod este montat un anumit disc sau folder? Trebuie s\u0103-i explic\u0103m dinainte c\u0103, v\u0103 rog, a\u0219eaz\u0103 ClickHouse-ul nostru exact pe acele noduri pe care exist\u0103 un disc?<\/em><\/p>\n<\/p>\n
Din c\u00e2te \u00een\u021beleg, aceast\u0103 \u00eentrebare este o continuare a stoc\u0103rii locale, \u00een special partea sa referitoare la hostPath. Este ca \u0219i cum ai explica \u00eentregului sistem ceea ce trebuie s\u0103 faci pentru ca pod-ul s\u0103 fie lansat exact pe un anumit nod, pe care avem un disc fizic conectat, care este montat pe un anumit parcurs. Este o \u00eentreag\u0103 sec\u021biune, pe care am acoperit-o foarte superficial, deoarece r\u0103spunsul este destul de mare. <\/p>\n
<\/p>\n
\u00cen esen\u021b\u0103, asta arat\u0103 a\u0219a. Este evident c\u0103 trebuie s\u0103 realiz\u0103m provisioning pentru aceste volume. Momentan, \u00een stocarea local\u0103 nu exist\u0103 provisioning dinamic, a\u0219a c\u0103 DevOps trebuie s\u0103 taie manual discurile, aceste volume. De asemenea, trebuie s\u0103 explic\u0103m Kubernetes provisioning-ului c\u0103 vor exista volume persistente de un anumit tip, situate pe anumite noduri. Apoi, va trebui s\u0103 explic\u0103m Kubernetes c\u0103 podurile care necesit\u0103 un anumit tip de stocare local\u0103 trebuie programate doar pe acele noduri specifice, conform etichetelor. \u00cen acest scop, operatorul are posibilitatea de a atribui anumite etichete \u0219i o instan\u021b\u0103 per gazd\u0103. Astfel, podurile vor fi rutate de Kubernetes pentru a fi lansate doar pe nodurile care \u00eendeplinesc cerin\u021bele etichetelor, vorbind pe \u00een\u021belesul tuturor. Administratorii atribuie etichete, fac provisioning pentru discuri manual. \u0218i atunci se poate scala.<\/p>\n
<\/p>\n
Iar cea de-a treia variant\u0103 local\u0103 ajut\u0103 s\u0103 u\u0219ur\u0103m pu\u021bin aceast\u0103 problem\u0103. A\u0219a cum am subliniat anterior, este o munc\u0103 minu\u021bioas\u0103 de configurare, care la final ajut\u0103 s\u0103 ob\u021binem performan\u021ba optim\u0103.<\/p>\n
<\/p>\n
Am o a doua \u00eentrebare legat\u0103 de acest subiect. Kubernetes a fost g\u00e2ndit astfel \u00eenc\u00e2t s\u0103 nu ne pese dac\u0103 pierdem un nod sau nu. Ce ar trebui s\u0103 facem \u00een cazul \u00een care pierdem nodul care g\u0103zduie\u0219te un shard?<\/em><\/p>\n<\/p>\n
Da, Kubernetes a fost ini\u021bial pozi\u021bionat astfel \u00eenc\u00e2t rela\u021bia noastr\u0103 cu podurile s\u0103 fie asem\u0103n\u0103toare cu cea dintre cresc\u0103torii de animale, dar aici fiecare disc devine ceva similar cu un animal de companie. Exist\u0103 aceast\u0103 problem\u0103 c\u0103 nu \u00eei putem aruncate pur \u0219i simplu. Dezvoltarea Kubernetes merge \u00een direc\u021bia \u00een care nu se poate aborda complet aceast\u0103 filozofie, consider\u00e2ndu-le resurse complet eliminabile.<\/p>\n
<\/p>\n
Acum o \u00eentrebare practic\u0103. Ce s\u0103 facem dac\u0103 a\u021bi pierdut un nod pe care era un disc? Aici problema se rezolv\u0103 la un nivel mai \u00eenalt. \u00cen cazul ClickHouse, avem replici care func\u021bioneaz\u0103 la un nivel superior, adic\u0103 la nivelul ClickHouse.<\/p>\n
<\/p>\n
Care este dispozi\u021bia, p\u00e2n\u0103 la urm\u0103? DevOps este responsabil pentru a se asigura c\u0103 datele nu se pierd. Trebuie s\u0103 configureze corect replicarea \u0219i s\u0103 se asigure c\u0103 replicarea se desf\u0103\u0219oar\u0103. \u00cen replic\u0103, la nivelul ClickHouse, datele trebuie s\u0103 fie duplicate. Aceasta nu este o sarcin\u0103 atribuit\u0103 operatorului. \u0218i nu este o sarcin\u0103 pe care o rezolv\u0103 Kubernetes. Aceasta se rezolv\u0103 la nivelul ClickHouse.<\/p>\n
<\/p>\n
Ce s\u0103 faci dac\u0103 ai o nod\u0103 hardware care a c\u0103zut? A\u0219adar, va trebui s\u0103 instalezi una secundar\u0103, corect, s\u0103 configurezi discul pe aceasta, s\u0103 aplici etichete. Dup\u0103 aceea, aceasta va \u00eendeplini cerin\u021bele, astfel \u00eenc\u00e2t Kubernetes s\u0103 poat\u0103 lansa un instantaneu al pod-ului. Kubernetes \u00eel va lansa. Totu\u0219i, nu ai suficient num\u0103r de pod-uri conform cerin\u021belor stabilite. Aceasta va trece prin ciclul pe care l-am ar\u0103tat. \u0218i la cel mai \u00eenalt nivel, ClickHouse va \u00een\u021belege c\u0103 a intrat o replic\u0103, este \u00eenc\u0103 goal\u0103 \u0219i trebuie s\u0103 \u00eencepem s\u0103 transfer\u0103m date c\u0103tre aceasta. Adic\u0103, acest proces este \u00eenc\u0103 prost automatizat. <\/p>\n
<\/p>\n
Mul\u021bumesc pentru prezentare! C\u00e2nd se \u00eent\u00e2mpl\u0103 tot felul de nepl\u0103ceri, operatorul pic\u0103 \u0219i se reporne\u0219te, iar \u00een acel moment sosesc evenimente, cum le gestionezi?<\/em><\/p>\n<\/p>\n
Ce se va \u00eent\u00e2mpla dac\u0103 operatorul a picat \u0219i s-a repornit, nu-i a\u0219a? <\/p>\n
<\/p>\n
Da. \u0218i \u00een acel moment au sosit evenimente.<\/em> <\/p>\n<\/p>\n
Sarcina, ce s\u0103 faci \u00een acest caz, se \u00eemparte par\u021bial \u00eentre operator \u0219i Kubernetes. Kubernetes are capacitatea de a reintegra evenimentele care s-au \u00eent\u00e2mplat. El le reintegreaz\u0103. Sarcina operatorului este de a se asigura c\u0103, atunci c\u00e2nd s-a realizat reintregratea jurnalului de evenimente, aceste evenimente sunt idempotente. \u0218i ca reapari\u021bia aceluia\u0219i eveniment s\u0103 nu ne distrug\u0103 sistemul. \u0218i operatorul nostru se descurc\u0103 cu aceast\u0103 sarcin\u0103. <\/p>\n
<\/p>\n
Bun\u0103 ziua! Mul\u021bumesc pentru prezentare! Dmitri Zavyalov, compania<\/em> Smedova. Se preconizeaz\u0103 ad\u0103ugarea \u00een operator a posibilit\u0103\u021bii de configurare cu haproxy? Ne-ar interesa un alt echilibrator pe l\u00e2ng\u0103 cel standard, care s\u0103 fie inteligent \u0219i s\u0103 \u00een\u021beleag\u0103 c\u0103 exist\u0103 de fapt ClickHouse.<\/em> <\/p>\n<\/p>\n
Vorbe\u0219ti despre Ingress?<\/p>\n
<\/p>\n
Da, \u00eenlocuie\u0219te Ingress cu haproxy. \u00cen haproxy po\u021bi s\u0103 specifici topologia cluster-ului, unde sunt replicile.<\/em><\/p>\n<\/p>\n
Deocamdat\u0103 nu ne-am g\u00e2ndit la asta. Dac\u0103 \u00ee\u021bi este necesar \u0219i po\u021bi explica de ce este nevoie, atunci poate fi implementat, mai ales dac\u0103 vrei s\u0103 participi. Cu pl\u0103cere vom analiza op\u021biunea. R\u0103spunsul scurt \u2013 nu, \u00een acest moment nu avem aceast\u0103 func\u021bionalitate. Mul\u021bumesc pentru sugestie, ne vom uita la asta. \u0218i dac\u0103 ne explici use case-ul \u0219i de ce este necesar \u00een practic\u0103, de exemplu, s\u0103 creezi issues pe GitHub, va fi minunat.<\/p>\n
<\/p>\n
Deja exist\u0103.<\/em><\/p>\n<\/p>\n
Bine. Suntem deschi\u0219i la orice sugestii. \u0218i haproxy se adaug\u0103 pe lista de to-do. Lista de to-do cre\u0219te, nu scade deocamdat\u0103. Dar este bine, asta \u00eenseamn\u0103 c\u0103 produsul este c\u0103utat.<\/p>\n
Sursa: 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
![\"Operator](\"\/wp-content\/uploads\/2020\/10\/56e002c7408c4708e39ece867f84171e.jpeg\")
<\/p>\n