Raportul este dedicat problemelor practice ale dezvoltării unui operator în Kubernetes, proiectării arhitecturii și principiilor de funcționare de bază.
În prima parte a raportului vom lua în considerare:
- ce este un operator în Kubernetes și de ce este necesar;
- modul exact în care operatorul simplifică gestionarea sistemelor complexe;
- ce poate și nu poate face operatorul.
În continuare, să trecem la discutarea structurii interne a operatorului. Să ne uităm la arhitectura și funcționarea operatorului pas cu pas. Să ne uităm la asta în detaliu:
- interacțiunea dintre operator și Kubernetes;
- ce funcții preia operatorul și ce funcții le delegă lui Kubernetes.
Să ne uităm la gestionarea fragmentelor și a replicilor bazei de date în Kubernetes.
În continuare, vom discuta problemele legate de stocarea datelor:
- cum să lucrezi cu Persistent Storage din punctul de vedere al unui operator;
- capcanele utilizării stocării locale.
În partea finală a raportului, vom lua în considerare exemple practice de aplicare de la Amazon sau Google Cloud Service. Raportul se bazează pe exemplul experienței de dezvoltare și operare a unui operator pentru ClickHouse.
video:
Numele meu este Vladislav Klimenko. Astăzi am vrut să vă vorbesc despre experiența noastră în dezvoltarea și operarea unui operator, acesta fiind un operator specializat în gestionarea clusterelor de baze de date. De exemplu pentru a gestiona clusterul ClickHouse.
De ce avem ocazia să vorbim despre operator și ClickHouse?
- Susținem și dezvoltăm ClickHouse.
- În acest moment, încercăm să ne aducem încet contribuția la dezvoltarea ClickHouse. Și suntem pe locul doi după Yandex în ceea ce privește volumul de modificări aduse ClickHouse.
- Încercăm să creăm proiecte suplimentare pentru ecosistemul ClickHouse.
Aș vrea să vă povestesc despre unul dintre aceste proiecte. Este vorba despre ClickHouse-operator pentru Kubernetes.
În raportul meu, aș dori să abordez două subiecte:
- Primul subiect este cum funcționează operatorul nostru de gestionare a bazei de date ClickHouse în Kubernetes.
- Al doilea subiect este modul în care funcționează orice operator, adică modul în care interacționează cu Kubernetes.
Cu toate acestea, aceste două întrebări se vor intersecta pe parcursul raportului meu.
Cine ar fi interesat să asculte ceea ce încerc să spun?
- Va fi de cel mai mare interes pentru cei care operează operatori.
- Sau pentru cei care doresc să-și creeze propriile lor pentru a înțelege cum funcționează intern, cum interacționează operatorul cu Kubernetes și ce capcane pot apărea.
Pentru a înțelege cel mai bine despre ce vom discuta astăzi, este o idee bună să știți cum funcționează Kubernetes și să aveți o pregătire de bază în cloud.
Ce este ClickHouse? Aceasta este o bază de date coloană cu caracteristici specifice pentru procesarea online a interogărilor analitice. Și este complet open source.
Și este important pentru noi să știm doar două lucruri. Trebuie să știți că aceasta este o bază de date, așa că ceea ce vă voi spune va fi aplicabil aproape oricărei baze de date. Și faptul că DBMS ClickHouse se scalează foarte bine, oferă scalabilitate aproape liniară. Și, prin urmare, starea cluster este o stare naturală pentru ClickHouse. Și suntem cel mai interesați să discutăm despre cum să servim clusterul ClickHouse în Kubernetes.
De ce este nevoie de el acolo? De ce nu putem continua să o operam singuri? Iar răspunsurile sunt parțial tehnice și parțial organizatorice.
- În practică, ne confruntăm din ce în ce mai mult cu o situație în care în companiile mari aproape toate componentele sunt deja în Kubernetes. Bazele de date rămân în afara.
- Și se pune din ce în ce mai mult întrebarea: „Se poate pune asta înăuntru?” Prin urmare, companiile mari încearcă să realizeze unificarea maximă a managementului pentru a-și putea gestiona rapid depozitele de date.
- Și acest lucru vă ajută mai ales dacă aveți nevoie de oportunitatea maximă de a repeta același lucru într-un loc nou, adică de portabilitate maximă.
Cât de ușor sau greu este? Acest lucru, desigur, se poate face manual. Dar nu este atât de simplu, pentru că avem complexitatea suplimentară a gestionării Kubernetes în sine, dar în același timp specificul ClickHouse este suprapus. Și rezultă o astfel de agregare.
Și toate acestea oferă un set destul de mare de tehnologii, care devine destul de dificil de gestionat, deoarece Kubernetes își aduce propriile probleme de zi cu zi în funcțiune, iar ClickHouse aduce propriile probleme în funcționarea de zi cu zi. Mai ales dacă avem mai multe ClickHouses și trebuie să facem constant ceva cu ele.
Cu o configurație dinamică, ClickHouse are un număr destul de mare de probleme care creează o încărcare constantă a DevOps:
- Când vrem să schimbăm ceva în ClickHouse, de exemplu, să adăugăm o replică sau un fragment, atunci trebuie să gestionăm configurația.
- Apoi modificați schema de date, deoarece ClickHouse are o metodă specifică de sharding. Acolo trebuie să așezați diagrama de date, să stabiliți configurațiile.
- Trebuie să configurați monitorizarea.
- Colectarea jurnalelor pentru noi cioburi, pentru noi replici.
- Ai grijă de restaurare.
- Și reporniți.
Acestea sunt sarcini de rutină pe care mi-aș dori foarte mult să le fac mai ușor de utilizat.
Kubernetes în sine ajută bine în funcționare, dar în ceea ce privește lucrurile de bază ale sistemului.
Kubernetes este bun la facilitarea și automatizarea lucrurilor precum:
- Recuperare.
- Repornire.
- Managementul sistemului de stocare.
Asta e bine, asta este direcția corectă, dar nu are nicio idee despre cum să opereze un cluster de baze de date.
Vrem mai mult, vrem ca întreaga bază de date să funcționeze în Kubernetes.
Aș dori să obțin ceva ca un buton roșu magic mare pe care îl apăsați și un grup cu sarcini de zi cu zi care trebuie rezolvate este desfășurat și menținut pe parcursul întregului său ciclu de viață. Cluster ClickHouse în Kubernetes.
Și am încercat să facem o soluție care să faciliteze munca. Acesta este un operator ClickHouse pentru Kubernetes de la Altinity.
Un operator este un program a cărui sarcină principală este de a gestiona alte programe, adică este un manager.
Și conține modele de comportament. Puteți numi aceste cunoștințe codificate despre domeniul subiectului.
Iar sarcina lui principală este de a face viața DevOps mai ușoară și de a reduce micromanagementul, astfel încât el (DevOps) să gândească deja în termeni la nivel înalt, adică astfel încât el (DevOps) să nu se angajeze în micromanagement, astfel încât să nu configureze toate detaliile manual.
Și doar operatorul este un asistent robotic care se ocupă de microsarcini și ajută DevOps.
De ce ai nevoie de un operator? Are performanțe deosebit de bune în două domenii:
- Atunci când specialistul care se ocupă de ClickHouse nu are suficientă experiență, dar are deja nevoie să opereze ClickHouse, operatorul facilitează operarea și vă permite să operați un cluster ClickHouse cu o configurație destul de complexă, fără a intra în prea multe detalii despre cum funcționează totul. interior. Îi dai doar sarcini de nivel înalt și funcționează.
- Iar a doua sarcină în care funcționează cel mai bine este atunci când este necesară automatizarea unui număr mare de sarcini tipice. Elimină microtask-urile de la administratorii de sistem.
Acest lucru este cel mai necesar fie pentru cei care abia încep călătoria, fie pentru cei care trebuie să facă multă automatizare.
Cum diferă abordarea bazată pe operator de alte sisteme? Există Helm. De asemenea, ajută la instalarea ClickHouse; puteți desena diagrame de conducere, care vor instala chiar și un întreg cluster ClickHouse. Care este atunci diferența dintre operator și același, de exemplu, Helm?
Principala diferență fundamentală este că Helm este gestionarea pachetelor, iar Operator face un pas mai departe. Acesta este suport pentru întregul ciclu de viață. Aceasta nu este doar instalare, acestea sunt sarcini de zi cu zi care includ scalarea, fragmentarea, adică tot ceea ce trebuie făcut în timpul ciclului de viață (dacă este necesar, apoi ștergerea) - totul este decis de operator. Încearcă să automatizeze și să mențină întregul ciclu de viață al software-ului. Aceasta este diferența sa fundamentală față de alte soluții care sunt prezentate.
Asta a fost partea introductivă, să mergem mai departe.
Cum ne construim operatorul? Încercăm să abordăm problema pentru a gestiona clusterul ClickHouse ca o singură resursă.
Aici avem date de intrare în partea stângă a imaginii. Acesta este YAML cu o specificație de cluster, care este transmisă Kubernetes în mod clasic prin kubectl. Acolo operatorul nostru îl ridică și își face magia. Și la ieșire obținem următoarea schemă. Aceasta este o implementare a ClickHouse în Kubernetes.
Și apoi ne vom uita încet la modul exact în care funcționează operatorul, ce sarcini tipice pot fi rezolvate. Vom lua în considerare doar sarcinile tipice, deoarece avem timp limitat. Și nu tot ce poate decide operatorul va fi discutat.
Să începem de la practică. Proiectul nostru este complet open source, așa că puteți vedea cum funcționează pe GitHub. Și puteți porni de la considerentele că, dacă doriți doar să-l lansați, atunci puteți începe cu Ghidul de pornire rapidă.
Dacă doriți să înțelegeți în detaliu, atunci încercăm să menținem documentația într-o formă mai mult sau mai puțin decentă.
Să începem cu o problemă practică. Prima sarcină, de unde vrem cu toții să începem, este să rulăm primul exemplu cumva. Cum pot lansa ClickHouse folosind operatorul, chiar dacă nu știu cu adevărat cum funcționează? Scriem un manifest, pentru că... Orice comunicare cu k8s este comunicare prin manifeste.
Acesta este un manifest atât de complex. Ceea ce am evidențiat cu roșu este pe ce trebuie să ne concentrăm. Solicităm operatorului să creeze un cluster numit demo.
Acestea sunt exemple de bază pentru moment. Depozitarea nu a fost încă descrisă, dar vom reveni la stocare puțin mai târziu. Pentru moment, vom observa dinamica dezvoltării clusterului.
Am creat acest manifest. Îl hrănim operatorului nostru. A muncit, a făcut magie.
Ne uităm la consolă. Trei componente sunt de interes: un Pod, două Servicii și un StatefulSet.
Operatorul a funcționat și putem vedea exact ce a creat.
El creează așa ceva. Avem un StatefulSet, Pod, ConfigMap pentru fiecare replică, ConfigMap pentru întregul cluster. Serviciile sunt necesare ca puncte de intrare în cluster.
Serviciile sunt serviciul central Load Balancer și pot fi utilizate și pentru fiecare replică, pentru fiecare fragment.
Clusterul nostru de bază arată cam așa. Este de la un singur nod.
Să mergem mai departe și să complicăm lucrurile. Trebuie să fragmentăm clusterul.
Sarcinile noastre cresc, începe dinamica. Vrem să adăugăm un ciob. Urmărim evoluția. Ne schimbăm specificațiile. Indicăm că vrem două cioburi.
Acesta este același fișier care se dezvoltă dinamic odată cu creșterea sistemului. Stocarea nu, stocarea va fi discutată în continuare, acesta este un subiect separat.
Hrănim operatorul YAML și vedem ce se întâmplă.
Operatorul a gândit și a făcut următoarele entități. Avem deja două Pod-uri, trei Servicii și, brusc, 2 StatefulSets. De ce 2 StatefulSets?
Pe diagramă era așa - aceasta este starea noastră inițială, când aveam un singur pod.
A devenit așa. Până acum totul este simplu, a fost duplicat.
Și de ce au devenit două StatefulSets? Aici trebuie să ne divagăm și să discutăm despre modul în care podurile sunt gestionate în Kubernetes.
Există un obiect numit StatefulSet care vă permite să creați un set de Pod-uri dintr-un șablon. Factorul cheie aici este șablonul. Și puteți lansa mai multe Pod-uri folosind un șablon într-un StatefulSet. Și expresia cheie aici este „multe Pod-uri pentru un șablon”.
Și a existat o mare tentație de a crea întregul cluster, împachetându-l într-un StatefulSet. Va funcționa, nu este nicio problemă. Dar există o avertizare. Dacă vrem să asamblam un cluster eterogen, adică din mai multe versiuni de ClickHouse, atunci încep să apară întrebări. Da, StatefulSet poate face o actualizare continuă și acolo puteți lansa o nouă versiune, explicați că nu trebuie să încercați mai mult de atâtea noduri în același timp.
Dar dacă extrapolăm sarcina și spunem că vrem să facem un cluster complet eterogen și nu vrem să trecem de la versiunea veche la una nouă folosind o actualizare continuă, ci pur și simplu vrem să creăm un cluster eterogen atât în termeni a diferitelor versiuni de ClickHouse și în ceea ce privește stocarea diferită. Vrem, de exemplu, să facem niște replici pe discuri separate, pe cele lente, în general, pentru a construi complet un cluster eterogen. Și datorită faptului că StatefulSet realizează o soluție standardizată dintr-un șablon, nu există nicio modalitate de a face acest lucru.
După câteva gânduri, s-a decis că vom proceda astfel. Avem fiecare replică în propriul set StatefulSet. Există câteva dezavantaje ale acestei soluții, dar în practică, totul este complet încapsulat de către operator. Și există o mulțime de avantaje. Putem construi exact clusterul pe care îl dorim, de exemplu, unul absolut eterogen. Prin urmare, într-un cluster în care avem două shard-uri cu o singură replică, vom avea 2 StatefulSets și 2 Pod-uri tocmai pentru că am ales această abordare din motivele expuse mai sus pentru a putea construi un cluster eterogen.
Să revenim la problemele practice. În clusterul nostru trebuie să configuram utilizatorii, de ex. trebuie să configurați ClickHouse în Kubernetes. Operatorul oferă toate posibilitățile pentru aceasta.
Putem scrie ceea ce vrem direct în YAML. Toate opțiunile de configurare sunt mapate direct din acest YAML în configurațiile ClickHouse, care sunt apoi distribuite în cluster.
Puteți scrie așa. Acesta este de exemplu. Parola poate fi criptată. Absolut toate opțiunile de configurare ClickHouse sunt acceptate. Iată doar un exemplu.
Configurația clusterului este distribuită ca ConfigMap. În practică, actualizarea ConfigMap nu are loc instantaneu, așa că dacă clusterul este mare, procesul de împingere a configurației durează ceva timp. Dar toate acestea sunt foarte convenabile de utilizat.
Să complicăm sarcina. Clusterul se dezvoltă. Vrem să replicăm datele. Adică avem deja două fragmente, câte o replică fiecare, iar utilizatorii sunt configurați. Suntem în creștere și vrem să facem replicare.
De ce avem nevoie pentru replicare?
Avem nevoie de ZooKeeper. În ClickHouse, replicarea este construită folosind ZooKeeper. ZooKeeper este necesar pentru ca diferitele replici ClickHouse să aibă un consens cu privire la blocurile de date pe care ClickHouse.
ZooKeeper poate fi folosit de oricine. Dacă întreprinderea are un ZooKeeper extern, atunci acesta poate fi utilizat. Dacă nu, îl puteți instala din depozitul nostru. Există un program de instalare care face acest lucru mai ușor.
Și diagrama de interacțiune a întregului sistem se dovedește așa. Avem Kubernetes ca platformă. Acesta execută operatorul ClickHouse. Mi-am imaginat ZooKeeper aici. Iar operatorul interacționează atât cu ClickHouse, cât și cu ZooKeeper. Adică rezultă interacțiunea.
Și toate acestea sunt necesare pentru ca ClickHouse să reproducă cu succes datele în k8s.
Să ne uităm acum la sarcina în sine, la cum va arăta manifestul pentru replicare.
Adăugăm două secțiuni la manifestul nostru. Primul este de unde să obțineți ZooKeeper, care poate fi fie în interiorul Kubernetes, fie extern. Aceasta este doar o descriere. Și comandăm replici. Acestea. vrem două replici. În total, ar trebui să avem 4 poduri la ieșire. Ne amintim despre stocare, va reveni puțin mai târziu. Depozitarea este o poveste separată.
A fost așa.
Devine așa. Se adaugă replici. Al 4-lea nu s-a potrivit, credem că ar putea fi mulți acolo. Și ZooKeeper este adăugat în lateral. Schemele devin din ce în ce mai complexe.
Și este timpul să adăugați următoarea sarcină. Vom adăuga stocare persistentă.
Pentru stocarea persistentă avem diverse opțiuni.
Dacă rulăm într-un furnizor de cloud, de exemplu, folosind Amazon, Google, atunci există o mare tentație de a folosi stocarea în cloud. Este foarte convenabil, e bun.
Și există o a doua opțiune. Aceasta este pentru stocarea locală, când avem discuri locale pe fiecare nod. Această opțiune este mult mai dificil de implementat, dar în același timp este mai productivă.
Să vedem ce avem în ceea ce privește stocarea în cloud.
Sunt avantaje. Este foarte ușor de configurat. Pur și simplu comandăm de la furnizorul de cloud, vă rugăm să ne acordați stocare cu așa și cutare capacitate, cu așa și cutare clasă. Cursurile sunt programate de furnizori în mod independent.
Și există un dezavantaj. Pentru unii, acesta este un dezavantaj necritic. Desigur, vor exista unele probleme de performanță. Este foarte convenabil de utilizat și fiabil, dar există unele dezavantaje potențiale de performanță.
Și pentru că ClickHouse se concentrează în mod special pe productivitate, s-ar putea spune chiar că stoarce tot ce poate, motiv pentru care mulți clienți încearcă să stoarce productivitatea maximă.
Și pentru a profita la maximum, avem nevoie de stocare locală.
Kubernetes oferă trei abstracții pentru utilizarea stocării locale în Kubernetes. Acest:
- EmptyDir
- HostPath.
- Local
Să vedem cum diferă și cum se aseamănă.
În primul rând, în toate cele trei abordări avem stocare - acestea sunt discuri locale care sunt situate pe același nod fizic k8s. Dar au unele diferențe.
Să începem cu cel mai simplu, adică emptyDir. Ce este asta în practică? În specificația noastră, solicităm sistemului de containerizare (cel mai adesea Docker) să ne ofere acces la un folder de pe discul local.
În practică, Docker creează un folder temporar undeva pe propriile căi și îl numește hash lung. Și oferă o interfață pentru a-l accesa.
Cum va funcționa acest lucru din punct de vedere al performanței? Acest lucru va funcționa la viteza discului local, de ex. Acesta este acces complet la șurubul tău.
Dar acest caz are un dezavantaj. Persistent este destul de dubios în această chestiune. Prima dată când Docker se mută cu containere, Persistent este pierdut. Dacă Kubernetes dorește să mute acest Pod pe alt disc dintr-un motiv oarecare, datele se vor pierde.
Această abordare este bună pentru teste, deoarece arată deja viteza normală, dar pentru ceva serios această opțiune nu este potrivită.
Prin urmare, există o a doua abordare. Acesta este hostPath. Dacă te uiți la diapozitivul anterior și pe acesta, poți vedea o singură diferență. Dosarul nostru a fost mutat din Docker direct în nodul Kubernetes. Aici e puțin mai simplu. Specificăm direct calea pe sistemul de fișiere local în care dorim să stocăm datele noastre.
Această metodă are avantaje. Acesta este deja un adevărat Persistent și unul clasic în același timp. Vom avea date înregistrate pe disc la o anumită adresă.
Există și dezavantaje. Aceasta este complexitatea managementului. Kubernetes-ul nostru poate dori să mute Pod-ul într-un alt nod fizic. Și aici intervine DevOps. El trebuie să explice corect întregului sistem că aceste poduri pot fi mutate doar în acele noduri pe care aveți ceva montat de-a lungul acestor căi și nu mai mult de un nod la un moment dat. Este destul de dificil.
În special în aceste scopuri, am realizat șabloane în operatorul nostru pentru a ascunde toată această complexitate. Și ați putea spune pur și simplu: „Vreau să am o instanță de ClickHouse pentru fiecare nod fizic și de-a lungul unei astfel de căi.”
Dar nu suntem singurii care au nevoie de această nevoie, așa că însuși domnii de la Kubernetes înțeleg și că oamenii vor să aibă acces la discuri fizice, așa că oferă un al treilea strat.
Se numește local. Practic nu există nicio diferență față de slide-ul anterior. Abia înainte a fost necesar să confirmăm manual că nu putem transfera aceste poduri de la nod la nod, deoarece acestea trebuie atașate de-a lungul unei căi către un disc fizic local, dar acum toate aceste cunoștințe sunt încapsulate în Kubernetes însuși. Și se dovedește a fi mult mai ușor de configurat.
Să revenim la problema noastră practică. Să revenim la șablonul YAML. Aici avem stocare reală. Ne-am întors la asta. Am stabilit șablonul clasic VolumeClaim ca în k8s. Și descriem ce fel de stocare dorim.
După aceasta, k8s va solicita stocare. Ni-l va aloca în StatefulSet. Și în final va fi la dispoziția ClickHouse.
Aveam această schemă. Stocarea noastră persistentă era roșie, ceea ce părea să sugereze că trebuie făcută.
Și devine verde. Acum, schema de cluster ClickHouse pe k8s este complet finalizată. Avem cioburi, replici, ZooKeeper, avem un adevărat Persistent, care este implementat într-un fel sau altul. Schema este deja pe deplin operațională.
Continuăm să trăim. Clusterul nostru se dezvoltă. Și Alexey încearcă și lansează o nouă versiune de ClickHouse.
Apare o sarcină practică - să testăm noua versiune a ClickHouse pe clusterul nostru. Și, firește, nu doriți să le difuzați pe toate; doriți să puneți o versiune nouă într-o replică undeva în colțul îndepărtat și poate nu o versiune nouă, ci două deodată, pentru că apar des.
Ce putem spune despre asta?
Aici avem o astfel de oportunitate. Acestea sunt șabloane de pod. Puteți scrie că operatorul nostru vă permite complet să construiți un cluster eterogen. Acestea. configurați, pornind de la toate replicile într-o grămadă, terminând cu fiecare replică personală, ce versiune dorim ClickHouse, ce versiune dorim stocare. Putem configura complet clusterul cu configurația de care avem nevoie.
Să intrăm puțin mai adânc în interior. Înainte de aceasta, am vorbit despre cum funcționează ClickHouse-operator în raport cu specificul ClickHouse.
Acum aș dori să spun câteva cuvinte despre modul în care funcționează orice operator în general, precum și despre modul în care interacționează cu K8-urile.
Să ne uităm mai întâi la interacțiunea cu K8-urile. Ce se întâmplă când aplicăm kubectl? Obiectele noastre apar în etcd prin intermediul API-ului.
De exemplu, obiecte Kubernetes de bază: pod, StatefulSet, service și așa mai departe în listă.
În același timp, încă nu sa întâmplat nimic fizic. Aceste obiecte trebuie materializate în cluster.
În acest scop, apare un controler. Controlerul este o componentă specială k8s care poate materializa aceste descrieri. Știe cum și ce să facă fizic. Știe cum să ruleze containere, ce trebuie configurat acolo pentru ca serverul să funcționeze.
Și materializează obiectele noastre în K8-uri.
Dar dorim să operam nu numai cu pod-uri și StatefulSets, vrem să creăm o ClickHouseInstallation, adică un obiect de tip ClickHouse, pentru a opera cu el ca un întreg. Până acum nu există o astfel de posibilitate.
Dar K8s are următorul lucru frumos. Vrem să avem undeva ca această entitate complexă în care clusterul nostru ar fi asamblat din poduri și StatefulSet.
Și ce trebuie făcut pentru asta? În primul rând, definiția personalizată a resurselor intră în imagine. Ce este? Aceasta este o descriere pentru K8s, că veți avea încă un tip de date, că vrem să adăugăm o resursă personalizată la pod, StatefulSet, care va fi complexă în interior. Aceasta este o descriere a structurii datelor.
De asemenea, îl trimitem acolo prin aplicația kubectl. Kubernetes a luat-o cu bucurie.
Și acum în stocarea noastră, obiectul din etcd are posibilitatea de a înregistra o resursă personalizată numită ClickHouseInstallation.
Dar deocamdată nu se va mai întâmpla nimic. Adică, dacă acum creăm fișierul YAML la care ne-am uitat descriind fragmente și replici și spunem „kubectl apply”, atunci Kubernetes îl va accepta, îl va pune în etcd și va spune: „Grozabil, dar nu știu ce să fac. Cu acesta. Nu știu cum să întrețin ClickHouseInstallation.”
În consecință, avem nevoie de cineva care să ajute Kubernetes să servească noul tip de date. În stânga avem un controler nativ Kubernetes care funcționează cu tipuri de date native. Și în dreapta ar trebui să avem un controler personalizat care poate funcționa cu tipuri de date personalizate.
Și într-un alt fel se numește operator. L-am inclus aici în mod special ca Kubernetes, deoarece poate fi executat și în afara K8-urilor. Cel mai adesea, desigur, toți operatorii sunt executați în Kubernetes, dar nimic nu-l împiedică să stea afară, așa că aici este mutat special în exterior.
Și, la rândul său, controlerul personalizat, cunoscut și sub numele de operator, interacționează cu Kubernetes prin intermediul API-ului. Știe deja cum să interacționeze cu API-ul. Și știe deja să materializeze circuitul complex pe care vrem să-l facem dintr-o resursă personalizată. Este exact ceea ce face operatorul.
Cum funcționează operatorul? Să ne uităm în partea dreaptă pentru a vedea cum o face. Să aflăm cum materializează operatorul toate acestea și cum are loc interacțiunea ulterioară cu K8-urile.
Un operator este un program. Ea este orientată spre evenimente. Operatorul se abonează la evenimente folosind API-ul Kubernetes. API-ul Kubernetes are puncte de intrare unde vă puteți abona la evenimente. Și dacă ceva se schimbă în K8s, atunci Kubernetes trimite evenimente tuturor, adică. oricine s-a abonat la acest punct API va primi notificări.
Operatorul se abona la evenimente și trebuie să facă un fel de reacție. Sarcina sa este de a răspunde la evenimentele emergente.
Evenimentele sunt generate de anumite actualizări. Sosește fișierul nostru YAML cu o descriere a ClickHouseInstallation. A mers la etcd prin kubectl apply. Un eveniment a fost declanșat acolo și, ca urmare, acest eveniment a ajuns la operatorul ClickHouse. Operatorul a primit această descriere. Și trebuie să facă ceva. Dacă a sosit o actualizare pentru obiectul ClickHouseInstallation, atunci trebuie să actualizați clusterul. Și sarcina operatorului este să actualizeze clusterul.
Ce face? În primul rând, trebuie să elaborăm un plan de acțiune pentru ceea ce vom face cu această actualizare. Actualizările pot fi foarte mici, de ex. mic în execuția YAML, dar poate implica schimbări foarte mari asupra clusterului. Prin urmare, operatorul creează un plan și apoi se ține de el.
Conform acestui plan, el începe să gătească această structură în interior pentru a materializa păstăi, servicii, i.e. face care este sarcina lui principală. Iată cum se construiește un cluster ClickHouse în Kubernetes.
Acum să ne referim la un lucru atât de interesant. Aceasta este o împărțire a responsabilității între Kubernetes și operator, adică. ce face Kubernetes, ce face operatorul și cum interacționează unul cu celălalt.
Kubernetes este responsabil pentru lucrurile de sistem, de ex. pentru un set de bază de obiecte care pot fi interpretate ca domeniu-sistem. Kubernetes știe cum să lanseze pod-uri, cum să repornească containerele, cum să monteze volume, cum să lucreze cu ConfigMap, de ex. tot ceea ce poate fi numit sistem.
Operatorii operează în domenii. Fiecare operator este creat pentru domeniul său propriu. Am făcut-o pentru ClickHouse.
Iar operatorul interacționează exact în ceea ce privește domeniul subiectului, cum ar fi adăugarea unei replici, realizarea unei diagrame, configurarea monitorizării. Aceasta are ca rezultat o divizare.
Să ne uităm la un exemplu practic al modului în care apare această împărțire a responsabilităților atunci când facem acțiunea de adăugare a replică.
Operatorul primește o sarcină - să adauge o replică. Ce face operatorul? Operatorul va calcula că trebuie creat un nou StatefulSet, în care astfel de șabloane, revendicarea volumului, trebuie descrise.
Le-a pregătit pe toate și le transmite K8-urilor. El spune că are nevoie de ConfigMap, StatefulSet, Volume. Kubernetes funcționează. El materializează unitățile de bază cu care operează.
Și apoi ClickHouse-operator intră din nou în joc. Are deja un pod fizic pe care deja poate face ceva. Și ClickHouse-operator funcționează din nou în termeni de domeniu. Acestea. În mod specific ClickHouse, pentru a include o replică într-un cluster, trebuie, mai întâi, să configurați schema de date care există în acest cluster. Și, în al doilea rând, această replică trebuie inclusă în monitorizare pentru a putea fi urmărită clar. Operatorul configurează deja acest lucru.
Și numai după aceea ClickHouse în sine intră în joc, adică. o altă entitate de nivel superior. Aceasta este deja o bază de date. Are propria instanță, o altă replică configurată care este gata să se alăture clusterului.
Se pare că un lanț de execuție și împărțire a responsabilităților atunci când adăugați o replică este destul de lung.
Ne continuăm sarcinile practice. Dacă aveți deja un cluster, puteți migra configurația.
Am făcut-o astfel încât să puteți lipi direct în xml existent, pe care ClickHouse îl înțelege.
Puteți regla fin ClickHouse. Doar implementarea zonelor este ceea ce am vorbit când am explicat hostPath, stocarea locală. Acesta este modul în care se efectuează corect implementarea zonelor.
Următoarea sarcină practică este monitorizarea.
Dacă clusterul nostru se modifică, atunci trebuie să configuram periodic monitorizarea.
Să ne uităm la diagramă. Ne-am uitat deja la săgețile verzi aici. Acum să ne uităm la săgețile roșii. Acesta este modul în care dorim să ne monitorizăm clusterul. Cum intră valorile din clusterul ClickHouse în Prometheus și apoi în Grafana.
Care este dificultatea monitorizării? De ce este prezentat asta ca un fel de realizare? Dificultatea constă în dinamică. Când avem un cluster și este static, atunci putem configura monitorizarea o dată și nu ne mai deranjam.
Dar dacă avem o mulțime de clustere sau ceva se schimbă constant, atunci procesul este dinamic. Și reconfigurarea constantă a monitorizării este o risipă de resurse și timp, adică. chiar și doar lenea. Acest lucru trebuie automatizat. Dificultatea constă în dinamica procesului. Iar operatorul automatizează acest lucru foarte bine.
Cum s-a dezvoltat clusterul nostru? La început a fost așa.
Apoi a fost așa.
Până la urmă, a devenit așa.
Iar monitorizarea se face automat de către operator. Punct unic de intrare.
Și chiar la ieșire ne uităm la tabloul de bord Grafana pentru a vedea cum se fierbe viața grupului nostru înăuntru.
Apropo, tabloul de bord Grafana este distribuit și cu operatorul nostru direct în codul sursă. Vă puteți conecta și utiliza. DevOps-ul nostru mi-a oferit această captură de ecran.
Unde am vrea să mergem mai departe? Acest:
- Dezvoltați automatizarea testelor. Sarcina principală este testarea automată a noilor versiuni.
- De asemenea, vrem să automatizăm integrarea cu ZooKeeper. Și există planuri de integrare cu ZooKeeper-operator. Acestea. A fost scris un operator pentru ZooKeeper și este logic ca cei doi operatori să înceapă să se integreze pentru a construi o soluție mai convenabilă.
- Vrem să facem semne vitale mai complexe.
- Am evidențiat cu verde că ne apropiem de moștenirea șabloanelor - DONE, adică cu următoarea lansare a operatorului vom avea deja moștenirea șabloanelor. Acesta este un instrument puternic care vă permite să construiți configurații complexe din piese.
- Și dorim automatizarea sarcinilor complexe. Principalul este Re-sharding.
Să luăm câteva rezultate intermediare.
Ce obținem ca rezultat? Și merită sau nu? Este chiar necesar să încercăm să trageți baza de date în Kubernetes și să folosiți operatorul în general și operatorul Alitnity în special?
La ieșire obținem:
- Simplificare și automatizare semnificativă a configurației, implementării și întreținerii.
- Monitorizare încorporată imediat.
- Și șabloane codificate gata de utilizare pentru situații complexe. O acțiune precum adăugarea unei replici nu trebuie făcută manual. Operatorul face asta.
A mai rămas doar o ultimă întrebare. Avem deja o bază de date în Kubernetes, virtualizare. Dar performanța unei astfel de soluții, mai ales că ClickHouse este optimizat pentru performanță?
Răspunsul este totul în regulă! Nu voi intra în detalii; acesta este subiectul unui raport separat.
Dar există un proiect precum TSBS. Care este sarcina sa principală? Acesta este un test de performanță a bazei de date. Aceasta este o încercare de a compara cald cu cald, moale cu moale.
Cum lucrează? Se generează un set de date. Apoi, acest set de date este rulat pe baze de date diferite folosind același set de teste. Și fiecare bază de date rezolvă o problemă în modul în care știe cum. Și apoi puteți compara rezultatele.
Acceptă deja o mulțime mare de baze de date. Am identificat trei principale. Acest:
- TimecaleDB.
- InfluxDB.
- ClickHouse.
S-a făcut și o comparație cu o altă soluție similară. Comparație cu RedShift. Comparația a fost făcută pe Amazon. ClickHouse este, de asemenea, cu mult înaintea tuturor în această chestiune.
Ce concluzii se pot trage din ceea ce am spus?
- DB în Kubernetes este posibil. Probabil orice este posibil, dar în general se pare că este posibil. ClickHouse în Kubernetes este cu siguranță posibil cu ajutorul operatorului nostru.
- Operatorul ajută la automatizarea proceselor și face cu adevărat viața mai ușoară.
- Performanța este normală.
- Și ni se pare că acest lucru poate și trebuie folosit.
Open source - alăturați-vă nouă!
După cum am spus deja, operatorul este un produs complet open source, așa că ar fi foarte bine dacă numărul maxim de persoane l-ar folosi. Alăturaţi-ne! Vă așteptăm pe toți!
Va multumesc tuturor!
întrebări
Multumesc pentru raport! Numele meu este Anton. Sunt de la SEMrush. Mă întreb ce e cu înregistrarea. Auzim despre monitorizare, dar nimic despre logare, dacă vorbim despre întreg clusterul. De exemplu, am creat un cluster pe hardware. Și folosim înregistrarea centralizată, adunându-le într-o grămadă comună folosind mijloace standard. Și apoi de acolo obținem datele care ne interesează.
Bună întrebare, adică conectarea la o listă de lucruri de făcut. Operatorul nostru nu automatizează încă acest lucru. Este încă în curs de dezvoltare, proiectul este încă destul de tânăr. Înțelegem necesitatea logării. Acesta este, de asemenea, un subiect foarte important. Și probabil că nu este mai puțin important decât monitorizarea. Dar primul pe listă pentru implementare a fost monitorizarea. Va fi logare. Desigur, încercăm să automatizăm toate aspectele vieții clusterului. Prin urmare, răspunsul este că momentan operatorul, din păcate, nu știe cum să facă acest lucru, dar este în planuri, o vom face. Dacă doriți să vă alăturați, atunci trageți cererea, vă rugăm.
Buna ziua! Multumesc pentru raport! Am o întrebare standard legată de volume persistente. Când creăm o configurație cu acest operator, cum stabilește operatorul pe ce nod avem atașat un anumit disc sau folder? Mai întâi trebuie să-i explicăm că vă rugăm să plasați ClickHouse-ul nostru pe aceste noduri care au un disc?
Din câte am înțeles, această întrebare este o continuare a stocării locale, în special partea hostPath a acesteia. Este ca și cum am explica întregului sistem că pod-ul trebuie lansat pe un astfel de nod, la care avem un disc conectat fizic, care este montat de-a lungul unei astfel de căi. Aceasta este o secțiune întreagă pe care am atins-o foarte superficial pentru că răspunsul acolo este destul de mare.
Pe scurt, așa arată. Desigur, trebuie să furnizăm aceste volume. Momentan, nu există o prevedere dinamică în stocarea locală, așa că DevOps trebuie să taie singuri discurile, aceste volume. Și ei trebuie să explice furnizarea Kubernetes că veți avea volume persistente de așa sau atare clasă, care sunt situate pe astfel de noduri. Apoi va trebui să explicați lui Kubernetes că pod-urile care necesită o astfel de clasă de stocare locală trebuie direcționate numai către astfel de noduri folosind etichete. În aceste scopuri, operatorul are capacitatea de a atribui un fel de etichetă și una pentru fiecare instanță gazdă. Și se dovedește că pod-urile vor fi direcționate de Kubernetes pentru a rula doar pe noduri care îndeplinesc cerințele, etichetele, în termeni simpli. Administratorii atribuie etichete și furnizează discurile manual. Și apoi se scalează.
Și este a treia opțiune, locală, care ajută la ușurarea acestui lucru. După cum am subliniat deja, aceasta este o muncă minuțioasă asupra reglajului, care în cele din urmă ajută la obținerea performanței maxime.
Am o a doua întrebare legată de asta. Kubernetes a fost proiectat în așa fel încât nu contează pentru noi dacă pierdem un nod sau nu. Ce ar trebui să facem în acest caz dacă am pierdut nodul în care se blochează ciobul nostru?
Da, Kubernetes a fost poziționat inițial că relația noastră cu păstăile noastre este ca vitele, dar aici la noi fiecare disc devine ceva ca un animal de companie. Există o astfel de problemă încât nu le putem arunca. Iar dezvoltarea Kubernetes merge în direcția în care este imposibil să-l tratezi complet filozofic, ca și cum ar fi o resursă complet aruncată.
Acum pentru o întrebare practică. Ce să faci dacă ai pierdut nodul pe care se afla discul? Aici problema este rezolvată la un nivel superior. În cazul ClickHouse, avem replici care funcționează la un nivel superior, adică. la nivelul ClickHouse.
Care este dispoziția rezultată? DevOps este responsabil pentru a se asigura că datele nu se pierd. El trebuie să configureze corect replicarea și trebuie să se asigure că replica rulează. Replica la nivelul ClickHouse trebuie să aibă date duplicate. Aceasta nu este sarcina pe care o rezolvă operatorul. Și nu problema pe care Kubernetes însuși o rezolvă. Acesta este la nivelul ClickHouse.
Ce să faci dacă îți cade nodul de fier? Și se pare că va trebui să instalați al doilea, să furnizați corect discul pe el și să aplicați etichete. Și după aceea, va îndeplini cerințele conform cărora Kubernetes poate lansa un pod de instanță pe el. Kubernetes îl va lansa. Numărul dvs. de poduri nu este suficient pentru a atinge numărul specificat. Va trece prin ciclul pe care l-am arătat. Și la cel mai înalt nivel, ClickHouse va înțelege că am introdus o replică, este încă goală și trebuie să începem să transferăm date către ea. Acestea. Acest proces nu este încă bine automatizat.
Multumesc pentru raport! Când se întâmplă tot felul de lucruri urâte, operatorul se prăbușește și repornește, iar în acel moment apar evenimente, te descurci cumva cu asta?
Ce se întâmplă dacă operatorul s-a prăbușit și a repornit, nu?
Da. Și în acel moment au venit evenimentele.
Sarcina de a face în acest caz este parțial împărțită între operator și Kubernetes. Kubernetes are capacitatea de a reda un eveniment care a avut loc. El reda. Iar sarcina operatorului este să se asigure că atunci când jurnalul de evenimente este redat pe el, aceste evenimente sunt idempotente. Și pentru ca apariția repetată a aceluiași eveniment să nu rupă sistemul nostru. Și operatorul nostru face față acestei sarcini.
Buna ziua! Multumesc pentru raport! Dmitri Zavyalov, companie Smedova. Există planuri de a adăuga operatorului posibilitatea de a configura cu haproxy? M-ar interesa și un alt echilibrator în afară de cel standard, astfel încât să fie inteligent și să înțeleagă că ClickHouse este cu adevărat acolo.
Vorbești despre Ingress?
Da, înlocuiți Ingress cu haproxy. În haproxy puteți specifica topologia clusterului unde are replici.
Încă nu ne-am gândit la asta. Dacă aveți nevoie de el și puteți explica de ce este necesar, atunci va fi posibil să îl implementați, mai ales dacă doriți să participați. Vom fi bucuroși să luăm în considerare opțiunea. Răspunsul scurt este nu, momentan nu avem o astfel de funcționalitate. Mulțumim pentru sfat, vom analiza această problemă. Și dacă explicați și cazul de utilizare și de ce este necesar în practică, de exemplu, creați probleme pe GitHub, atunci asta va fi grozav.
Are deja.
Amenda. Suntem deschiși la orice sugestii. Și haproxy este adăugat la lista de activități. Lista de lucruri este în creștere, nu se micșorează încă. Dar acest lucru este bun, înseamnă că produsul este la cerere.
Sursa: www.habr.com