U rapportu hè dedicatu à prublemi pratichi di sviluppà un operatore in Kubernetes, cuncependu a so architettura è i principii di funziunamentu di basa.
In a prima parte di u rapportu avemu da cunsiderà:
- ciò chì hè un operatore in Kubernetes è perchè hè necessariu;
- quantu esattamente l'operatore simplifica a gestione di sistemi cumplessi;
- ciò chì l'operatore pò è ùn pò micca fà.
Dopu, andemu à discutiri di a struttura interna di l'operatore. Fighjemu l'architettura è u funziunamentu di l'operatore passu à passu. Fighjemu in u dettu:
- interazzione trà l'operatore è Kubernetes;
- quali funzioni assume l'operatore è quali funzioni delegate à Kubernetes.
Fighjemu a gestione di frammenti è ripliche di basa di dati in Kubernetes.
In seguitu, discuteremu i prublemi di almacenamiento di dati:
- cumu travaglià cù u Persistent Storage da u puntu di vista di l'operatore;
- trappule di usu Local Storage.
In a parte finale di u rapportu, cunsideremu esempi pratichi di applicazione cù Amazon o Google Cloud Service. U rapportu hè basatu annantu à l'esempiu di u sviluppu è l'esperienza operativa di un operatore per ClickHouse.
Video:
Mi chjamu Vladislav Klimenko. Oghje vulia parlà di a nostra sperienza in u sviluppu è l'operazione di un operatore, è questu hè un operatore specializatu per a gestione di clusters di basa di dati. Per esempiu per gestisce u cluster ClickHouse.
Perchè avemu l'uppurtunità di parlà di l'operatore è ClickHouse?
- Supportemu è sviluppemu ClickHouse.
- À u mumentu, circhemu di fà lentamente a nostra cuntribuzione à u sviluppu di ClickHouse. È simu secondu Yandex in quantu à u voluminu di cambiamenti fatti à ClickHouse.
- Pruvemu di fà prughjetti supplementari per l'ecosistema ClickHouse.
Vogliu parlà di unu di sti prughjetti. Si tratta di l'operatore ClickHouse per Kubernetes.
In u mo rapportu vogliu tuccà dui temi:
- U primu tema hè cumu u nostru operatore di gestione di basa di dati ClickHouse travaglia in Kubernetes.
- U sicondu tema hè cumu funziona qualsiasi operatore, vale à dì cumu interagisce cù Kubernetes.
Tuttavia, sti dui dumande s'interseceranu in tuttu u mo rapportu.
Quale saria interessatu à sente ciò ch'e aghju pruvatu à dì ?
- Serà di più interessu à quelli chì operanu operatori.
- O per quelli chì volenu fà u so propiu per capiscenu cumu si funziona internamente, cumu l'operatore interagisce cù Kubernetes, è chì trappule ponu appare.
Per capisce megliu ciò chì discutemu oghje, hè una bona idea di sapè cumu funziona Kubernetes è avè qualchì furmazione di basa in nuvola.
Cosa hè ClickHouse? Questa hè una basa di dati di colonna cù caratteristiche specifiche per u processu in linea di e dumande analitiche. È hè cumplettamente open source.
È hè impurtante per noi di sapè solu duie cose. Avete bisognu di sapè chì questu hè una basa di dati, cusì ciò chì vi diceraghju serà applicabile à quasi ogni basa di dati. È u fattu chì u ClickHouse DBMS scala assai bè, dà una scalabilità quasi lineale. È dunque, u statu di cluster hè un statu naturali per ClickHouse. È simu più interessati à discutiri cumu serve u cluster ClickHouse in Kubernetes.
Perchè ci hè bisognu? Perchè ùn pudemu micca cuntinuà à uperà noi stessu? E e risposte sò in parte tecniche è in parte urganisazione.
- In pratica, avemu sempre più scontru una situazione induve in e grande cumpagnie quasi tutti i cumpunenti sò digià in Kubernetes. E basa di dati restanu fora.
- È a quistione hè sempre più dumandata: "Puderà esse piazzatu à l'internu?" Per quessa, e grande cumpagnie cercanu di ottene a massima unificazione di a gestione per pudè rapidamente gestisce i so magazzini di dati.
- È questu soprattuttu aiuta s'ellu avete bisognu di l'uppurtunità massima di ripetiri a stessa cosa in un novu locu, vale à dì a massima portabilità.
Quantu hè faciule o difficiule? Questu, sicuru, pò esse fattu a manu. Ma ùn hè micca cusì simplice, perchè avemu a cumplessità aghjunta di a gestione di Kubernetes stessu, ma à u stessu tempu i specifichi di ClickHouse sò superposti. È una tale aggregazione risultati.
È tuttu inseme dà un inseme abbastanza grande di tecnulugii, chì diventa abbastanza difficiuli di gestisce, perchè Kubernetes porta i so propiu prublemi di ogni ghjornu à l'operazione, è ClickHouse porta i so prublemi à l'operazione di ogni ghjornu. In particulare s'ellu avemu parechje ClickHouses, è avemu bisognu di fà sempre qualcosa cun elli.
Cù una cunfigurazione dinamica, ClickHouse hà un numeru abbastanza grande di prublemi chì creanu una carica constante nantu à DevOps:
- Quandu vulemu cambià qualcosa in ClickHouse, per esempiu, aghjunghje una replica o shard, allora avemu bisognu di gestisce a cunfigurazione.
- Allora cambia u schema di dati, perchè ClickHouse hà un metudu di sharding specificu. Ci hè bisognu di mette u diagramma di dati, mette e cunfigurazioni.
- Avete bisognu di stallà u monitoraghju.
- Raccolta di logs per novi frammenti, per novi repliche.
- A cura di a risturazione.
- È ripigliate.
Quessi sò travaglii di rutina chì mi piacerebbe fà fà più faciule d'utilizà.
Kubernetes stessu aiuta bè in u funziunamentu, ma nantu à e cose basi di u sistema.
Kubernetes hè bonu per facilità è automatizà cose cum'è:
- Ripresa.
- Riavvia.
- Gestione di u sistema di almacenamiento.
Hè bonu, questu hè a direzzione ghjusta, ma ùn hè cumplettamente clueless quantu à uperà un cluster di basa di dati.
Vulemu più, vulemu chì tutta a basa di dati per travaglià in Kubernetes.
Mi piacerebbe ottene qualcosa cum'è un grande buttone magicu rossu chì appughjà è un cluster cù i travaglii di ogni ghjornu chì deve esse risoltu hè implementatu è mantinutu in tuttu u so ciclu di vita. ClickHouse cluster in Kubernetes.
E avemu pruvatu à fà una suluzione chì aiutava à fà u travagliu più faciule. Questu hè un operatore ClickHouse per Kubernetes da Altinity.
Un operatore hè un prugramma chì u so compitu principale hè di gestisce altri prugrammi, vale à dì hè un manager.
È cuntene mudelli di cumpurtamentu. Pudete chjamà sta cunniscenza codificata nantu à u sughjettu.
È u so compitu principalu hè di fà a vita di DevOps più faciule è di riduce a microgestione, perchè ellu (DevOps) pensa digià in termini d'altu livellu, vale à dì, per chì ellu (DevOps) ùn sia micca impegnatu in a microgestione, per ùn cunfigurà micca. tutti i dettagli manualmente.
È solu l'operatore hè un assistente roboticu chì tratta di microtasks è aiuta DevOps.
Perchè avete bisognu di un operatore? Si comporta particularmente bè in dui duminii:
- Quandu u specialista chì tratta di ClickHouse ùn hà micca abbastanza sperienza, ma hà digià bisognu di uperà ClickHouse, l'operatore facilita l'operazione è permette di uperà un cluster ClickHouse cù una cunfigurazione piuttostu cumplessa, senza entre in troppu dettagli nantu à cumu si travaglia. dentru. Basta à dà li compiti di altu livellu, è travaglia.
- È u sicondu compitu in quale si cumporta megliu hè quandu hè necessariu d'automatizà un gran numaru di attività tipiche. Elimina microtasks da l'amministratori di u sistema.
Questu hè u più necessariu sia da quelli chì sò appena principiatu u so viaghju, o da quelli chì anu bisognu di fà assai automatizazione.
Cumu l'approcciu basatu in l'operatore difiere da altri sistemi? Ci hè Helm. Aiuta ancu à installà ClickHouse; pudete disegnà grafici di timone, chì ancu installà un cluster ClickHouse interu. Chì ghjè allora a diffarenza trà l'operatore è u listessu, per esempiu, Helm?
A principal diferenza fundamentale hè chì Helm hè a gestione di pacchetti è Operatore va un passu più. Questu hè un supportu per tuttu u ciclu di vita. Questu ùn hè micca solu a stallazione, questi sò i travaglii di ogni ghjornu chì includenu scaling, sharding, vale à dì tuttu ciò chì deve esse fattu durante u ciclu di vita (se necessariu, allora sguassà ancu) - questu hè tuttu decisu da l'operatore. Pruvate di automatizà è mantene tuttu u ciclu di vita di u software. Questa hè a so diferenza fundamentale da l'altri suluzioni chì sò presentati.
Hè stata a parte introduttiva, andemu avanti.
Cumu custruemu u nostru operatore? Pruvemu di avvicinà u prublema per gestisce u cluster ClickHouse cum'è una sola risorsa.
Quì avemu dati input nant'à u latu manca di u ritrattu. Questu hè YAML cù una specificazione di cluster, chì hè passatu à Kubernetes in u modu classicu via kubectl. Quì u nostru operatore piglia è face a so magia. È à a pruduzzioni avemu u schema seguente. Questa hè una implementazione di ClickHouse in Kubernetes.
E poi fighjuleremu lentamente cumu funziona esattamente l'operatore, quali travaglii tipici ponu esse risolti. Avemu da cunsiderà solu i travaglii tipici perchè avemu un tempu limitatu. È micca tuttu ciò chì l'operatore pò decide serà discutitu.
Partemu da a pratica. U nostru prughjettu hè cumplettamente open source, cusì pudete vede cumu funziona in GitHub. È pudete prucede da e cunsiderazioni chì, sè vo vulete solu lancià, pudete inizià cù a Guida Quick Start.
Se vulete capisce in detail, allora pruvemu di mantene a documentazione in una forma più o menu decente.
Cuminciamu cù un prublema pratica. U primu compitu, induve tutti vulemu principià, hè di eseguisce u primu esempiu di qualchì manera. Cumu possu lancià ClickHouse cù l'operatore, ancu s'ellu ùn sò micca veramente sapè cumu funziona? Scrivemu un manifestu, perchè... Tutte e cumunicazioni cù k8s hè cumunicazione attraversu manifesti.
Questu hè un manifestu cusì cumplessu. Ciò chì avemu evidenziatu in rossu hè ciò chì avemu bisognu di fucalizza. Avemu dumandatu à l'operatore di creà un cluster chjamatu demo.
Quessi sò esempi basi per avà. L'almacenamiento ùn hè ancu statu descrittu, ma torneremu à u almacenamiento un pocu dopu. Per avà, observeremu a dinamica di u sviluppu di u cluster.
Avemu criatu stu manifestu. L'alimentemu à u nostru operatore. Hà travagliatu, hà fattu a magia.
Fighjemu a cunsola. Trè cumpunenti sò d'interessu: un Pod, dui servizii, è un StatefulSet.
L'operatore hà travagliatu, è pudemu vede esattamente ciò chì hà creatu.
Ellu crea qualcosa cusì. Avemu un StatefulSet, Pod, ConfigMap per ogni replica, ConfigMap per tuttu u cluster. I servizii sò richiesti cum'è punti d'entrata in u cluster.
I servizii sò u serviziu di Load Balancer centrale è ponu ancu esse usatu per ogni replica, per ogni shard.
U nostru cluster di basa s'assumiglia à questu. Hè da un unicu node.
Andemu più in là è complicate e cose. Avemu bisognu di sparghje u cluster.
I nostri compiti sò in crescita, a dinamica principia. Vulemu aghjunghje un frammentu. Seguimu u sviluppu. Avemu cambiatu a nostra specificazione. Indichemu chì vulemu dui shards.
Questu hè u stessu schedariu chì si sviluppa dinamicamente cù a crescita di u sistema. U almacenamentu no, u almacenamentu serà discututu in più, questu hè un tema separatu.
Alimentamu l'operatore YAML è vede ciò chì succede.
L'operatore hà pensatu è hà fattu e seguenti entità. Avemu digià dui Pods, trè Servizi è, di colpu, 2 StatefulSets. Perchè 2 StatefulSets?
In u diagramma era cusì - questu hè u nostru statu iniziale, quandu avemu avutu un pod.
Hè diventatu cusì. Finu a ora tuttu hè simplice, hè stata duplicata.
E perchè sò diventati dui StatefulSets? Quì avemu bisognu di digressà è discute a quistione di cumu i Pods sò amministrati in Kubernetes.
Ci hè un oggettu chjamatu StatefulSet chì permette di creà un settore di Pods da un mudellu. U fattore chjave quì hè Template. È pudete lancià parechji Pods cù un mudellu in un StatefulSet. È a frasa chjave quì hè "assai Pods per un mudellu".
È ci era una grande tentazione di fà tuttu u cluster, imballendu in un StatefulSet. Funcionerà, ùn ci hè micca prublema. Ma ci hè una caveat. Se vulemu assemblà un cluster eterogeneu, vale à dì da parechje versioni di ClickHouse, allora e dumande cumincianu à nasce. Iè, StatefulSet pò fà una aghjurnazione rolling, è quì pudete lancià una nova versione, spiegà chì avete bisognu di pruvà micca più di tanti nodi à u stessu tempu.
Ma s'ellu extrapolamu u compitu è dicemu chì vulemu fà un cluster completamente eterogeneu è ùn vulemu micca cambià da a vechja versione à una nova utilizendu un aghjurnamentu rolling, ma vulemu solu creà un cluster eterogeneu sia in termini. di diverse versioni di ClickHouse è in termini di almacenamentu differente. Vulemu, per esempiu, per fà qualchi rèpliche nantu à dischi separati, in lenti, in generale, per custruisce cumplettamente un cluster heterogeneo. È per u fattu chì StatefulSet faci una suluzione standardizzata da un mudellu, ùn ci hè micca manera di fà questu.
Dopu qualchì pensamentu, hè statu decisu chì l'avemu da fà cusì. Avemu ogni replica in u so propiu StatefulSet. Ci sò qualchi svantaghji à sta suluzione, ma in pràtica hè tuttu cumplettamente incapsulated da l 'operatore. È ci sò assai vantaghji. Pudemu custruisce u cluster exactu chì vulemu, per esempiu, un assolutamente eterogeneu. Dunque, in un cluster in quale avemu dui shards cù una replica, averemu 2 StatefulSets è 2 Pods precisamente perchè avemu sceltu stu approcciu per i motivi dichjarati sopra per pudè custruisce un cluster eterogeneu.
Riturnemu à i prublemi pratichi. In u nostru cluster avemu bisognu di cunfigurà l'utilizatori, i.e. avete bisognu di fà qualchì cunfigurazione di ClickHouse in Kubernetes. L'operatore furnisce tutte e pussibilità per questu.
Pudemu scrive ciò chì vulemu direttamente in YAML. Tutte l'opzioni di cunfigurazione sò mappate direttamente da questu YAML in i cunfigurazioni di ClickHouse, chì sò poi distribuiti in tuttu u cluster.
Pudete scrive cusì. Questu hè per esempiu. A password pò esse criptata. Assolutamente tutte l'opzioni di cunfigurazione di ClickHouse sò supportate. Eccu solu un esempiu.
A cunfigurazione di u cluster hè distribuitu cum'è ConfigMap. In pratica, l'aghjurnamentu di ConfigMap ùn hè micca istantaneamente, perchè se u cluster hè grande, allora u prucessu di spinghje a cunfigurazione dura un pocu di tempu. Ma tuttu questu hè assai còmuda à aduprà.
Cumplichemu u compitu. U cluster si sviluppa. Vulemu riplicà e dati. Vale à dì, avemu digià dui shards, una replica ognunu, è l'utilizatori sò cunfigurati. Crescemu è vulemu fà a replicazione.
Chì avemu bisognu per a replicazione?
Avemu bisognu di ZooKeeper. In ClickHouse, a replicazione hè custruita cù ZooKeeper. ZooKeeper hè necessariu per chì e diverse rèpliche di ClickHouse anu un cunsensu nantu à quale blocchi di dati sò nantu à quale ClickHouse.
ZooKeeper pò esse usatu da qualcunu. Se l'impresa hà un ZooKeeper esternu, pò esse usatu. Se no, pudete installà da u nostru repository. Ci hè un installatore chì rende tuttu questu più faciule.
È u diagramma di l'interazzione di tuttu u sistema hè cusì cusì. Avemu Kubernetes cum'è una piattaforma. Esegue l'operatore ClickHouse. Aghju imaginatu ZooKeeper quì. È l'operatore interagisce cù ClickHouse è ZooKeeper. Hè, i risultati di l'interazzione.
È tuttu questu hè necessariu per ClickHouse per riplicà bè i dati in k8s.
Fighjemu avà à u compitu stessu, à ciò chì u manifestu per a replicazione serà.
Avemu aghjunghje duie sezioni à u nostru manifestu. U primu hè induve uttene ZooKeeper, chì pò esse sia in Kubernetes sia esterni. Questu hè solu una descrizzione. È urdinemu repliche. Quelli. vulemu duie ripliche. In totale, duvemu avè 4 pods à l'output. Ricordemu di u almacenamentu, tornerà un pocu dopu. U almacenamentu hè una storia separata.
Era cusì.
Diventa cusì. Repliche sò aghjuntu. U 4 ùn hè micca adattatu, credemu chì ci pudianu esse assai di elli. È ZooKeeper hè aghjuntu à u latu. I schemi sò diventati più cumplessi.
È hè ora di aghjunghje u prossimu compitu. Avemu da aghjunghje Storage persistente.
Per Persistent Storage avemu diverse opzioni.
Se simu in un fornitore di nuvola, per esempiu, utilizendu Amazon, Google, allora ci hè una grande tentazione di utilizà l'almacenamiento in nuvola. Hè assai cunvene, hè bonu.
È ci hè una seconda opzione. Questu hè per l'almacenamiento lucale, quandu avemu dischi lucali nantu à ogni node. Questa opzione hè assai più difficiuli di implementà, ma à u stessu tempu hè più pruduttivu.
Videmu ciò chì avemu in quantu à u almacenamentu in nuvola.
Ci sò vantaghji. Hè assai faciule di cunfigurà. Simplemente urdinemu da u fornitore di nuvola chì per piacè ci dessi u almacenamentu di tale è tale capacità, di tale è tale classe. E classi sò pianificate da i fornituri in modu indipendenti.
È ci hè un inconveniente. Per alcuni, questu hè un inconveniente micca criticu. Di sicuru, ci saranu qualchi prublemi di rendiment. Hè assai còmuda d'utilizà è affidabile, ma ci sò qualchi svantaghji potenziali di rendiment.
È perchè ClickHouse si focalizeghja specificamente nantu à a produtividade, si pò ancu dì chì sprime tuttu ciò chì pò, per quessa chì parechji clienti pruvate à strincà a produtividade massima.
È per ottene u massimu, avemu bisognu di almacenamiento locale.
Kubernetes furnisce trè astrazioni per utilizà l'almacenamiento locale in Kubernetes. Questu:
- EmptyDir
- HostPath.
- Local
Fighjemu cumu si sò diffirenti è cumu sò simili.
Prima, in tutti i trè approcci avemu u almacenamentu - questi sò dischi lucali chì si trovanu nantu à u stessu node fisicu k8s. Ma anu qualchì differenza.
Cuminciamu cù u più simplice, vale à dì emptyDir. Cosa hè questu in pratica? In a nostra specificazione, dumandemu à u sistema di containerizazione (a più spessu Docker) per furnisce l'accessu à un cartulare nantu à u discu locale.
In pratica, Docker crea un cartulare tempuranee in qualchì locu longu i so propri camini è u chjama un hash longu. È furnisce una interfaccia per accede.
Cumu serà questu travagliu in u rendiment? Questu hà da travaglià à a velocità di u discu locale, i.e. Questu hè un accessu sanu à u vostru viti.
Ma stu casu hà u so inconveniente. Persistente hè abbastanza dubbitu in questa materia. A prima volta chì Docker si move cù cuntenituri, Persistente hè persu. Se Kubernetes vole spustà stu Pod à un altru discu per una certa ragione, i dati seranu persi.
Stu approcciu hè bonu per i testi, perchè digià mostra a velocità normale, ma per qualcosa seriu sta opzione ùn hè micca adattata.
Per quessa, ci hè un secondu approcciu. Questu hè hostPath. Se guardate a slide precedente è questu, pudete vede solu una diferenza. U nostru cartulare spustatu da Docker direttamente à u node Kubernetes. Hè un pocu più simplice quì. Specificemu direttamente u percorsu nantu à u sistema di schedari locale induve vulemu guardà i nostri dati.
Stu metudu hà vantaghji. Questu hè digià un veru Persistente, è un classicu in questu. Averemu dati arregistrati nantu à u discu à qualchì indirizzu.
Ci sò ancu disadvantages. Questa hè a cumplessità di a gestione. U nostru Kubernetes pò vulerà spustà u Pod à un altru node fisicu. È questu hè induve DevOps entra in ghjocu. Deve spiegà currettamente à u sistema sanu chì questi podi ponu esse spustati solu à quelli nodi nantu à quale avete qualcosa muntatu nantu à sti camini, è micca più di un nodu à u tempu. Hè abbastanza difficiule.
In particulare per questi scopi, avemu fattu mudelli in u nostru operatore per ammuccià tutta sta cumplessità. È puderebbe dì solu: "Vogliu avè una istanza di ClickHouse per ogni nodu fisicu è longu à una tale strada".
Ma ùn simu micca l'unichi chì anu bisognu di sta necessità, cusì i signori da Kubernetes stessu capiscenu ancu chì a ghjente vole avè accessu à i dischi fisichi, perchè furnisce una terza capa.
Si chjama lucale. Ùn ci hè praticamente nisuna differenza da a slide precedente. Solu prima era necessariu di cunfirmà manualmente chì ùn pudemu micca trasfirià sti pods da u node à u node, perchè deve esse attaccati longu un percorsu à un discu fisicu lucale, ma avà tuttu questu sapè hè incapsulatu in Kubernetes stessu. È risulta esse assai più faciule da cunfigurà.
Riturnemu à u nostru prublema pratica. Riturnemu à u mudellu YAML. Quì avemu un veru almacenamentu. Semu di ritornu. Avemu stabilitu u mudellu VolumeClaim classicu cum'è in k8s. E discrimu chì tipu di almacenamentu vulemu.
Dopu questu, k8s dumandà u almacenamentu. L'assignerà à noi in u StatefulSet. È à a fine serà à a disposizione di ClickHouse.
Avemu avutu stu schema. U nostru Storage Persistente era rossu, chì pareva insinuà chì ci vole à fà.
È diventa verde. Avà u schema di cluster ClickHouse in k8s hè cumplettamente finalizatu. Avemu shards, replicas, ZooKeeper, avemu un veru Persistente, chì hè implementatu in un modu o un altru. U schema hè digià cumplettamente operativu.
Continuemu à campà. U nostru cluster si sviluppa. E Alexey prova, è libera una nova versione di ClickHouse.
Un compitu praticu nasce - per pruvà a nova versione di ClickHouse nantu à u nostru cluster. È, naturalmente, ùn vulete micca sparghje tuttu; vulete mette una nova versione in una replica in un locu in u cantonu luntanu, è forse micca una nova versione, ma duie à una volta, perchè esce spessu.
Chì pudemu dì di questu?
Quì avemu solu una tale opportunità. Quessi sò mudelli di pod. Pudete scrive chì u nostru operatore permette cumplettamente di custruisce un cluster eterogeneu. Quelli. cunfigurà, partendu da tutte e rèpliche in una mansa, finiscinu cù ogni replica persunale, chì versione vulemu ClickHouse, chì versione vulemu almacenamiento. Pudemu cunfigurà cumplettamente u cluster cù a cunfigurazione chì avemu bisognu.
Andemu un pocu più in fondu. Prima di questu, avemu parlatu cumu u travagliu di l'operatore ClickHouse in relazione à e specifiche di ClickHouse.
Avà vogliu dì uni pochi di parolle nantu à cumu travaglia ogni operatore in generale, è cumu si interagisce cù K8s.
Fighjemu prima interagisce cù i K8s. Chì succede quandu facemu u kubectl? I nostri ogetti appariscenu in etcd attraversu l'API.
Per esempiu, l'uggetti basi Kubernetes: pod, StatefulSet, serviziu, è cusì in a lista.
À u listessu tempu, nunda di fisicu succede ancu. Questi ogetti devenu esse materializzati in u cluster.
Per questu scopu, appare un controller. U controller hè un cumpunente speciale k8s chì pò materializà queste descrizzioni. Sapi cumu è ciò chì fà fisicamenti. Ellu sà cumu curriri cuntenituri, ciò chì deve esse cunfiguratu quì per u servitore per travaglià.
È materializeghja i nostri ogetti in K8s.
Ma vulemu operà micca solu cù pods è StatefulSets, vulemu creà una ClickHouseInstallation, vale à dì un ughjettu di u tippu ClickHouse, per uperà cun ellu cum'è un unicu tutale. Finu a ora ùn ci hè micca tali pussibilità.
Ma K8s hà a seguente cosa bella. Vulemu avè un locu cum'è questa entità cumplessa in quale u nostru cluster seria assemblatu da pods è StatefulSet.
È ciò chì deve esse fattu per questu? Prima, a Definizione di Risorsa Personalizata vene in a stampa. Chì ghjè ? Questa hè una descrizzione per K8s, chì avete un altru tipu di dati, chì vulemu aghjunghje una risorsa persunalizata à u pod, StatefulSet, chì serà cumplessu in l'internu. Questa hè una descrizzione di a struttura di dati.
Mandemu ancu quì via kubectl applica. Kubernetes hà pigliatu cun piacè.
È avà in u nostru almacenamentu, l'ughjettu in etcd hà l'uppurtunità di registrà una risorsa persunalizata chjamata ClickHouseInstallation.
Ma per avà ùn succede più nunda. Vale à dì, s'ellu avemu avà criatu u schedariu YAML chì avemu guardatu à descrizzione di frammenti è repliche è dicemu "kubectl applica", allora Kubernetes l'accetta, u mette in etcd è dicenu: "Grande, ma ùn sò micca ciò chì fà. cun ella. Ùn sò micca sapè cumu mantene ClickHouseInstallation ".
Per quessa, avemu bisognu di qualchissia per aiutà Kubernetes à serve u novu tipu di dati. A manca avemu un controller nativu Kubernetes chì travaglia cù tipi di dati nativi. È à a diritta duvemu avè un controller persunalizatu chì pò travaglià cù tipi di dati persunalizati.
È in un altru modu hè chjamatu operatore. L'aghju specificamente inclusu quì cum'è Kubernetes, perchè pò ancu esse eseguitu fora di K8s. A maiò spessu, sicuru, tutti l'operatori sò eseguiti in Kubernetes, ma nunda ùn impedisce di stà fora, cusì quì hè spicialmente spustatu fora.
È à u turnu, u cuntrollu persunalizatu, cunnisciutu ancu l'operatore, interagisce cù Kubernetes via l'API. Sapi digià cumu interagisce cù l'API. È sà digià cumu materializà u circuitu cumplessu chì vulemu fà da una risorsa persunalizata. Questu hè esattamente ciò chì l'operatore faci.
Cumu travaglia l'operatore? Fighjemu à u latu drittu per vede cumu si faci. Scupritemu cumu l'operatore materializeghja tuttu questu è cumu si faci più interazzione cù K8s.
Un operatore hè un prugramma. Hè orientata à l'avvenimenti. L'operatore s'abbona à l'avvenimenti utilizendu l'API Kubernetes. L'API Kubernetes hà punti di ingressu induve pudete subscribe à l'avvenimenti. E se qualcosa cambia in K8s, allora Kubernetes manda avvenimenti à tutti, i.e. quellu chì hà abbonatu à stu puntu API riceverà notificazioni.
L'operatore s'abbona à l'avvenimenti è deve fà qualchì tipu di reazione. U so compitu hè di risponde à l'eventi emergenti.
L'avvenimenti sò generati da certi aghjurnamenti. Arriva u nostru schedariu YAML cù una descrizzione di ClickHouseInstallation. Andò à etcd attraversu kubectl applica. Un avvenimentu hè statu attivatu quì, è in u risultatu questu avvenimentu hè ghjuntu à l'operatore ClickHouse. L'operatore hà ricevutu sta descrizzione. È deve fà qualcosa. Se un aghjurnamentu hè ghjuntu per l'ughjettu ClickHouseInstallation, allora avete bisognu di aghjurnà u cluster. È u compitu di l'operatore hè di aghjurnà u cluster.
Chì faci ? Prima, avemu bisognu di scrive un pianu d'azzione per ciò chì faremu cù questa aghjurnazione. L'aghjurnamenti ponu esse assai chjuchi, i.e. chjuca in l'esekzione YAML, ma pò implicà cambiamenti assai grandi in u cluster. Dunque, l'operatore crea un pianu, è poi si ferma.
Sicondu stu pianu, cumencia à cocilu sta struttura in l'internu per materializà pods, servizii, i.e. fà ciò chì hè u so compitu principale. Questu hè cumu custruisce un cluster ClickHouse in Kubernetes.
Avà tocca à una cosa cusì interessante. Questa hè una divisione di rispunsabilità trà Kubernetes è l'operatore, i.e. ciò chì Kubernetes faci, ciò chì l'operatore faci, è cumu si interagiscenu cù l'altri.
Kubernetes hè rispunsevule per e cose di u sistema, i.e. per un inseme basi di l'uggetti chì ponu esse interpretati cum'è sistema-scopu. Kubernetes sà cumu lancià pods, cumu riavvià i cuntenituri, cumu si muntanu volumi, cumu travaglià cù ConfigMap, i.e. tuttu ciò chì pò esse chjamatu sistema.
L'operatori operanu in i duminii. Ogni operatore hè fattu per u so propiu sughjettu. Avemu fattu per ClickHouse.
È l'operatore interagisce precisamente in quantu à l'area di u sughjettu, cum'è l'aghjunghje una replica, fà un diagramma, stabilisce u monitoraghju. Questu risultatu in una divisione.
Fighjemu un esempiu praticu di cumu si face sta divisione di rispunsabilità quandu facemu l'azzione di replica.
L'operatore riceve un compitu - per aghjunghje una replica. Chì faci l'operatore? L'operatore hà da calculà chì un novu StatefulSet deve esse creatu, in quale tali mudelli, richieste di volumi, deve esse discrittu.
Hà preparatu tuttu è trasmette à K8s. Dice chì hà bisognu di ConfigMap, StatefulSet, Volume. Kubernetes hè travagliatu. Materializeghja l'unità basi cù quale opera.
E poi ClickHouse-operatore torna in ghjocu. Hà digià un pod fisicu nantu à quale pò digià fà qualcosa. È ClickHouse-operatore torna torna in termini di duminiu. Quelli. Specificamenti ClickHouse, per include una replica in un cluster, deve, prima, cunfigurà u schema di dati chì esiste in questu cluster. È, in segundu, sta replica deve esse inclusa in u monitoraghju per ch'ella pò esse chjaramente tracciata. L'operatore hà digià configuratu questu.
È solu dopu chì ClickHouse stessu entra in ghjocu, i.e. un'altra entità di livellu più altu. Questu hè digià una basa di dati. Hà a so propria istanza, una altra replica cunfigurata chì hè pronta per unisce à u cluster.
Ci hè chì una catena d'esekzione è a divisione di rispunsabilità quandu aghjunghje una replica hè abbastanza longa.
Cuntinuemu i nostri travaglii pratichi. Se avete digià un cluster, pudete migrate a cunfigurazione.
Avemu fattu in modu chì pudete incollà ghjustu in xml esistenti, chì ClickHouse capisce.
Pudete fine-tune ClickHouse. Appena l'implementazione in zona hè ciò chì aghju parlatu quandu spiegà hostPath, almacenamiento locale. Questu hè cumu fà una implementazione zonata currettamente.
U prossimu compitu praticu hè u monitoraghju.
Se u nostru cluster cambia, allora avemu bisognu di cunfigurà periodicamente u monitoraghju.
Fighjemu u schema. Avemu digià guardatu e frecce verdi quì. Avà guardemu à e frecce rosse. Questu hè cumu vulemu monitorizà u nostru cluster. Cumu e metriche da u cluster ClickHouse entranu in Prometheus, è dopu in Grafana.
Chì ci hè a difficultà cù u monitoraghju? Perchè questu hè presentatu cum'è un tipu di successu? A difficultà si trova in a dinamica. Quandu avemu un cluster è hè staticu, allora pudemu stallà u monitoraghju una volta è ùn ci preoccupa più.
Ma s'ellu avemu assai clusters, o qualcosa hè cambiatu constantemente, allura u prucessu hè dinamicu. E cunfigurà constantemente u monitoraghju hè una perdita di risorse è di tempu, i.e. ancu solu pigrizia. Questu deve esse automatizatu. A difficultà si trova in a dinamica di u prucessu. È l'operatore automatizeghja assai bè.
Cumu hà sviluppatu u nostru cluster? In principiu era cusì.
Allora era cusì.
In fine, hè diventatu cusì.
È u monitoraghju hè fattu automaticamente da l'operatore. Puntu unicu di entrata.
È ghjustu à a surtita guardemu à u dashboard di Grafana per vede cumu a vita di u nostru cluster hè bollendu in l'internu.
A strada, Grafana dashboard hè ancu distribuitu cù u nostru operatore direttamente in u codice fonte. Pudete cunnette è aduprà. U nostru DevOps m'hà datu sta screenshot.
Induve vulemu andà dopu ? Questu:
- Sviluppà l'automatizazione di teste. U compitu principale hè a prova automatizata di novi versioni.
- Vulemu ancu veramente automatizà l'integrazione cù ZooKeeper. E ci sò piani per integrà cù ZooKeeper-operatore. Quelli. Un operatore hè statu scrittu per ZooKeeper è hè logicu chì i dui operatori cumincianu à integrà per custruisce una suluzione più còmuda.
- Vulemu fà signali vitali più cumplessi.
- Aghju evidenziatu in verde chì avemu avvicinatu l'eredità di i Templates - DONE, vale à dì cù a prossima versione di l'operatore avemu digià eredità di mudelli. Questu hè un strumentu putente chì permette di custruisce cunfigurazioni cumplessi da pezzi.
- È vulemu l'automatizazione di i travaglii cumplessi. U principale hè Re-sharding.
Pigliemu qualchi risultati intermedi.
Chì avemu u risultatu? È vale a pena di fà o micca ? Hè ancu necessariu di pruvà à arrastà a basa di dati in Kubernetes è aduprà l'operatore in generale è l'operatore Alitnity in particulare?
À l'output avemu:
- Semplificazione significativa è automatizazione di cunfigurazione, implementazione è mantenimentu.
- Immediatamente un monitoraghju integratu.
- E mudelli codificati pronti per l'usu per situazioni cumplessi. Un'azzione cum'è aghjunghje una replica ùn deve esse fatta manualmente. L'operatore face questu.
Ci hè solu una ultima dumanda. Avemu digià una basa di dati in Kubernetes, virtualizazione. Chì ci hè di u rendiment di una tale suluzione, soprattuttu chì ClickHouse hè ottimizatu per u rendiment?
A risposta hè tuttu bè! Ùn entreraghju micca in dettagliu; questu hè u tema di un rapportu separatu.
Ma ci hè un tali prughjettu cum'è TSBS. Chì ghjè u so compitu principale? Questu hè un test di rendiment di basa di dati. Questu hè un tentativu di paragunà u caldu cù u caldu, u dolce cù u soffiu.
Cumu travaglia ? Un set di dati hè generatu. Allora stu settore di dati hè gestitu nantu à diverse basa di dati utilizendu u stessu gruppu di teste. È ogni basa di dati risolve un prublema in a manera chì sà. È dopu pudete paragunà i risultati.
Supporta digià una grande quantità di basa di dati. Aghju identificatu trè principali. Questu:
- TimecaleDB.
- InfluxDB.
- Clicca House.
Un paragone hè statu ancu fattu cù una altra suluzione simili. Comparazione cù RedShift. A comparazione hè stata fatta nantu à Amazon. ClickHouse hè ancu assai avanti di tutti in questa materia.
Chì cunclusioni pò esse trattu da ciò chì aghju dettu?
- DB in Kubernetes hè pussibule. Probabilmente qualsiasi hè pussibule, ma in generale pare chì hè pussibule. ClickHouse in Kubernetes hè certamente pussibule cù l'aiutu di u nostru operatore.
- L'operatore aiuta à automatizà i prucessi è rende veramente a vita più faciule.
- U rendiment hè normale.
- È ci pari chì questu pò è deve esse usatu.
Open source - unisciti à noi!
Cum'è l'aghju digià dettu, l'operatore hè un pruduttu completamente apertu, cusì saria assai bonu se u massimu di persone l'utilizanu. Unisciti à noi! Vi aspittemu tutti !
Grazie à tutti!
I vostri dumanni
Grazie per u rapportu! Mi chjamu Anton. Sò di SEMrush. Mi dumandu ciò chì succede cù u logu. Avemu intesu parlà di u monitoraghju, ma nunda di logging, se parlemu di tuttu u cluster. Per esempiu, avemu criatu un cluster in hardware. È avemu aduprà logging centralizatu, cullighjenduli in un munzeddu cumunu cù i mezi standard. E poi da quì avemu i dati chì ci interessanu.
Una bona dumanda, vale à dì chì accede à una lista di tuttu. U nostru operatore ùn hà ancu automatizatu questu. Si sviluppa sempre, u prugettu hè sempre abbastanza ghjovanu. Capemu a necessità di logging. Questu hè ancu un tema assai impurtante. È probabilmente ùn hè micca menu impurtante ch'è u monitoraghju. Ma prima nantu à a lista per l'implementazione era u monitoraghju. Ci sarà logging. Naturalmente, pruvemu di automatizà tutti l'aspetti di a vita di u cluster. Dunque, a risposta hè chì in u mumentu l'operatore, sfurtunatamenti, ùn sapi micca cumu fà questu, ma hè in i piani, avemu da fà. Se vulete unisce, allora tira a dumanda, per piacè.
Bonghjornu! Grazie per u rapportu! Aghju una quistione standard ligata à i volumi persistenti. Quandu creemu una cunfigurazione cù questu operatore, cumu l'operatore determina nantu à quale node avemu un discu o cartulare particulari attaccatu? Avemu da spiegà prima à ellu chì per piacè mette u nostru ClickHouse nantu à questi nodi chì anu un discu?
In quantu capiscu, sta quistione hè una continuazione di l'almacenamiento lucale, in particulare a parte hostPath di questu. Questu hè cum'è spiegà à u sistema tutale chì u pod deve esse lanciatu nantu à un tali è un node, à quale avemu un discu fisicamente cunnessu, chì hè muntatu longu à una tale strada. Questa hè una sezione sana chì aghju toccu assai superficialmente perchè a risposta hè abbastanza grande.
In breve, pare cusì. Naturalmente, avemu bisognu di furnisce questi volumi. À u mumentu, ùn ci hè micca pruvista dinamica in u almacenamentu lucale, cusì DevOps deve cutà i dischi stessi, sti volumi. È anu da spiegà Kubernetes pruvisione chì vi averete volumi persistenti di tali classi, chì si trovanu nantu à tali nodi. Allora avete bisognu di spiegà à Kubernetes chì i baccelli chì necessitanu una tale classa di almacenamento lucale deve esse diretta solu à tali nodi chì utilizanu etichette. Per questi scopi, l'operatore hà a capacità di assignà un tipu d'etichetta è una per esempiu di l'ospite. È risulta chì i pods seranu instradati da Kubernetes per eseguisce solu nantu à i nodi chì rispondenu à i requisiti, etichette, in termini simplici. L'amministratori assignanu etichette è furnisce i dischi manualmente. È poi scala.
È hè a terza opzione, lucale, chì aiuta à fà questu un pocu più faciule. Cum'è l'aghju digià enfatizatu, questu hè un travagliu minuciosu nantu à l'accordu, chì aiuta in ultimamente à ottene u massimu rendiment.
Aghju una seconda quistione ligata à questu. Kubernetes hè statu cuncepitu in tale manera chì ùn importa micca per noi chì perdemu un node o micca. Chì duvemu fà in questu casu si avemu persu u node induve u nostru shard pende?
Iè, Kubernetes era inizialmente posizionatu chì a nostra rilazioni cù i nostri baccelli hè cum'è u vacche, ma quì cun noi ogni discu diventa qualcosa cum'è una mascota. Ci hè un prublema cusì chì ùn pudemu micca solu scaccià. È u sviluppu di Kubernetes và in a direzzione chì hè impussibile di trattà cumplitamenti filusuficu, cum'è s'ellu era una risorsa completamente scartata.
Avà per una quistione pratica. Cosa da fà si avete persu u node nantu à quale era u discu? Quì u prublema hè risolta à un livellu più altu. In u casu di ClickHouse, avemu repliche chì travaglianu à un livellu più altu, i.e. à u livellu ClickHouse.
Chì ghjè a dispusizione risultatu? DevOps hè rispunsevule per assicurà chì e dati ùn sò micca persi. Deve stabilisce a replicazione currettamente è deve assicurà chì a replicazione hè in esecuzione. A replica à u livellu ClickHouse deve avè dati duplicati. Questu hè micca u compitu chì l'operatore risolve. È micca u prublema chì Kubernetes stessu risolve. Questu hè à u livellu ClickHouse.
Cosa da fà se u vostru nodu di ferru cascà? È risulta chì avete bisognu di stallà una seconda, furnisce bè u discu nantu à questu, è applicà etichette. È dopu, risponde à i requisiti chì Kubernetes pò lancià un pod d'istanza nantu à questu. Kubernetes u lanciarà. U vostru numeru di pods ùn hè micca abbastanza per scuntrà u numeru specificatu. Passerà per u ciculu chì aghju dimustratu. È à u più altu livellu, ClickHouse capisce chì avemu intrutu in una replica, hè sempre viotu è avemu bisognu di cumincià à trasfiriri dati à questu. Quelli. Stu prucessu ùn hè ancu bè automatizatu.
Grazie per u rapportu! Quandu succede ogni tipu di cose disgraziate, l'operatore crashes è riavvia, è in quellu mumentu ghjunghjenu l'avvenimenti, in qualche modu gestite questu?
Chì succede se l'operatore s'hè lampatu è riavviatu, nò?
Iè. È in quellu mumentu l'avvenimenti sò ghjunti.
U compitu di ciò chì fà in questu casu hè in parte spartutu trà l'operatore è Kubernetes. Kubernetes hà a capacità di ripiglià un avvenimentu chì hè accadutu. Ripeti. È u compitu di l'operatore hè di assicurà chì quandu u logu di l'eventi hè riprodottu nantu à ellu, questi avvenimenti sò idempotenti. È cusì chì l'occurrence ripetuta di u stessu avvenimentu ùn rompe u nostru sistema. È u nostru operatore copre stu compitu.
Bonghjornu! Grazie per u rapportu! Dmitry Zavyalov, cumpagnia Smedova. Ci hè un pianu di aghjunghje l'abilità di cunfigurà cù haproxy à l'operatore? Saria interessatu à qualchì altru balancer in più di u standard, cusì chì hè intelligente è capisce chì ClickHouse hè veramente quì.
Parli di Ingress ?
Iè, rimpiazzà Ingress cù haproxy. In haproxy pudete specificà a topologia di u cluster induve hà repliche.
Ùn avemu micca pensatu ancu. Se avete bisognu è pudete spiegà perchè hè necessariu, allora serà pussibule implementà, soprattuttu se vulete participà. Seremu felici di cunsiderà l'opzione. A risposta corta hè micca, attualmente ùn avemu micca tali funziunalità. Grazie per a punta, esamineremu sta materia. E se spiegà ancu u casu d'usu è perchè hè necessariu in a pratica, per esempiu, creanu prublemi nantu à GitHub, allora sarà grande.
Hà digià.
Va bè. Semu aperti à ogni suggerimentu. È haproxy hè aghjuntu à a lista di tuttu. A lista di tuttu hè in crescita, ùn si riduce ancu. Ma questu hè bonu, significa chì u pruduttu hè in dumanda.
Source: www.habr.com