La presentazione è dedicata a questioni pratiche nello sviluppo dell'operatore in Kubernetes, progettazione della sua architettura e dei principi di funzionamento di base.
Nella prima parte della presentazione esamineremo:
- cos'è un operatore in Kubernetes e a cosa serve;
- come l'operatore semplifica la gestione di sistemi complessi;
- cosa può fare l'operatore e cosa non può fare.
Successivamente, passeremo a discutere della struttura interna dell'operatore. Esamineremo l'architettura e il funzionamento dell'operatore passo dopo passo. Analizzeremo in dettaglio:
- l'interazione tra l'operatore e Kubernetes;
- quali funzioni l'operatore si assume e quali delega a Kubernetes.
Esamineremo la gestione degli shard e delle repliche di database in Kubernetes.
Successivamente, discuteremo delle questioni relative alla memorizzazione dei dati:
- come lavorare con il Persistent Storage dal punto di vista dell'operatore;
- i problemi nell'utilizzo del Local Storage.
Nella parte finale della presentazione analizzeremo esempi pratici di applicazione con Amazon o Google Cloud Service. La presentazione si basa sull'esperienza di sviluppo e utilizzo dell'operatore per ClickHouse.
Video:
Mi chiamo Vladislav Klimenko. Oggi volevo parlare della nostra esperienza nello sviluppo e nell'uso dell'operatore, che è un operatore specializzato per la gestione dei cluster di database. Prendendo a esempio per la gestione del cluster ClickHouse.
Perché abbiamo la possibilità di parlare dell'operatore e di ClickHouse?
- Ci occupiamo del supporto e dello sviluppo di ClickHouse.
- Attualmente cerchiamo di contribuire gradualmente allo sviluppo di ClickHouse. E siamo secondi solo a Yandex per il volume di modifiche apportate a ClickHouse.
- Cerchiamo di sviluppare progetti aggiuntivi per l'ecosistema di ClickHouse.
Vorrei parlare di uno di questi progetti. Si tratta del ClickHouse-operator per Kubernetes.
Nella mia presentazione vorrei toccare due argomenti:
- Il primo argomento riguarda come funziona il nostro operatore per la gestione dei database ClickHouse in Kubernetes.
- Il secondo argomento è come funziona qualsiasi operatore, cioè come interagisce con Kubernetes.
Questi due temi si intersecheranno durante tutta la mia presentazione.
A chi potrebbe interessare ascoltare quello che cerco di presentare?
- Sarà particolarmente interessante per chi utilizza operatori.
- O a quelli che vogliono creare il proprio, per capire come funziona internamente, come interagisce l'operatore con Kubernetes e quali insidie possono sorgere.
Per comprendere al meglio ciò di cui discuteremo oggi, sarebbe utile sapere come funziona Kubernetes e avere una preparazione di base sulle tecnologie cloud.
Che cos'è ClickHouse? È un database colonnare con specificità nel trattamento online delle query analitiche. Ed è completamente open source.
E ci sono due cose di cui è importante essere a conoscenza. È necessario sapere che è un database, quindi ciò di cui parlerò sarà applicabile praticamente a qualsiasi database. E che il DBMS ClickHouse scala molto bene, offre praticamente scalabilità lineare. Inoltre, lo stato del cluster è uno stato naturale per ClickHouse. Ci interessa soprattutto discutere di come gestire un cluster ClickHouse in Kubernetes.
Perché è necessario? Perché non possiamo continuare a sfruttarlo autonomamente? Le risposte sono parzialmente tecniche e parzialmente organizzative.
- Nella pratica, ci troviamo sempre più spesso in situazioni in cui nelle grandi aziende praticamente tutti i componenti sono già in Kubernetes. I database rimangono al di fuori.
- E sempre più si pone la domanda: 'È possibile inserirli qui dentro?'. Pertanto, le grandi aziende cercano di massimizzare l'unificazione della gestione per poter gestire rapidamente i propri repository di dati.
- E questo è particolarmente utile se è necessaria la massima possibilità di ripetere la stessa cosa in un nuovo luogo, cioè la massima portabilità.
Quanto è semplice o complicato? Certamente si può fare manualmente. Ma non è così semplice, perché abbiamo la complessità della gestione di Kubernetes stessa, ma si sovrappone anche la specificità di ClickHouse. Si ottiene quindi una tale aggregazione.
E tutto questo porta a un insieme piuttosto ampio di tecnologie, la cui gestione diventa già piuttosto complessa, perché Kubernetes porta con sé domande quotidiane sull'esercizio, mentre ClickHouse porta le sue questioni quotidiane di gestione. Soprattutto, se abbiamo più istanze di ClickHouse e dobbiamo costantemente interagire con esse.
In ClickHouse, with dynamic configuration, there are a considerable number of issues that create a constant load on DevOps:
- When we want to change something in ClickHouse, for example, to add a replica or a shard, we need to manage the configuration.
- Then we need to change the data schema because ClickHouse has a specific way of sharding. The data schema needs to be deployed, and the configurations need to be arranged.
- Monitoring needs to be configured.
- Log collection for new shards, for new replicas.
- Worry about recovery.
- And restarting.
These are routine tasks that we would like to ease in operation.
Kubernetes itself helps well in operation but on basic system tasks.
Kubernetes simplifies and automates tasks such as:
- Recovery.
- Restarting.
- Managing the storage system.
This is good; it's the right direction, but it has no complete understanding of how to operate a database cluster.
We want more; we want our entire database to run on Kubernetes.
We want something like a big magical red button that you press, and it deploys and maintains a cluster with daily tasks that need to be solved. A ClickHouse cluster on Kubernetes.
And we tried to create a solution that would help ease operations. This is the ClickHouse operator for Kubernetes from Altinity.
The operator is a program whose main task is to manage other programs, i.e., it is a manager.
It contains behavior templates. This can be called codified knowledge about the subject area.
Its primary task is to make the life of DevOps easier and reduce micromanagement, so that he (DevOps) thinks in high-level terms, i.e., not engaging in micromanagement and not configuring all the details manually.
The operator is a helper robot that tackles micro-tasks and assists DevOps.
Why is an operator needed? It shows its strength especially in two areas:
- Quando uno specialista che si occupa di ClickHouse non ha abbastanza esperienza, ma è già necessario utilizzare ClickHouse, l'operatore semplifica l'uso e consente di gestire un cluster ClickHouse con una configurazione piuttosto complessa, senza approfondire troppo nei dettagli su come funziona internamente. Basta dargli compiti ad alto livello e funziona.
- La seconda attività in cui si distingue meglio è quando è necessario automatizzare un gran numero di compiti standard. Si occupa delle microattività degli amministratori di sistema.
Questo è particolarmente utile sia per coloro che stanno appena iniziando il loro percorso, sia per chi deve dedicarsi molto all'automazione.
Qual è quindi la differenza tra un approccio basato su operatori e altri sistemi? Esiste Helm. Anche lui aiuta a installare ClickHouse, si possono disegnare helm charts che possono anche installare un intero cluster ClickHouse. Qual è quindi la differenza tra un operatore e, ad esempio, Helm?
La principale differenza fondamentale è che Helm è una gestione dei pacchetti, mentre l'operatore va oltre. Si occupa dell'intero ciclo di vita. Non è solo installazione, ma anche attività quotidiane che includono scalabilità, sharding, cioè tutto ciò che deve essere eseguito nel corso del ciclo di vita (in caso di necessità, anche la rimozione) – questo è tutto compito dell'operatore. Si propone di automatizzare e gestire l'intero ciclo di vita del software. Questa è la sua fondamentale differenza rispetto ad altre soluzioni disponibili.
Questa era la parte introduttiva, andiamo avanti.
Come costruiamo il nostro operatore? Cerchiamo di gestire il cluster ClickHouse come una singola risorsa.
Qui sulla sinistra abbiamo i dati di input. Questo è un YAML con la specifica del cluster, che viene tradizionalmente passato a Kubernetes attraverso kubectl. Lì, il nostro operatore lo raccoglie e fa la sua magia. E all'uscita otteniamo uno schema come questo. Questa è l'implementazione di ClickHouse in Kubernetes.
E poi, vedremo gradualmente come funziona l'operatore e quali compiti standard possono essere risolti. Considereremo solo compiti standard, perché abbiamo tempo limitato. E non sarà trattato tutto ciò che l'operatore può risolvere.
Partiamo dalla pratica. Il nostro progetto è completamente open source, quindi è possibile dare un'occhiata a GitHub per vedere come funziona. E si può partire da considerazioni, se si vuole semplicemente avviarlo, si può cominciare con la Guida all'Inizio Veloce.
Se si desidera approfondire, cerchiamo di mantenere la documentazione in uno stato più o meno decente.
Iniziamo con un compito pratico. Il primo compito, da cui tutti vogliamo partire, è avviare il primo esempio in un modo o nell'altro. Come avviare ClickHouse tramite l'operatore, anche senza sapere esattamente come funziona? Scriviamo il manifesto, poiché tutta la comunicazione con k8s avviene tramite manifesti.
Ecco un manifesto piuttosto complesso. Ciò che abbiamo evidenziato in rosso è ciò su cui dobbiamo concentrarci. Chiediamo all'operatore di creare un cluster di nome demo.
Attualmente sono solo esempi di base. Lo storage non è ancora descritto, ma ci torneremo più avanti. Per ora, osserveremo lo sviluppo del cluster in dinamica.
Abbiamo creato questo manifesto. Lo forniamo al nostro operatore. Ha lavorato e fatto la sua magia.
Guardiamo nella console. Tre componenti ci attirano l'attenzione: Pod, due Service e StatefulSet.
L'operatore ha lavorato e possiamo vedere cosa ha creato.
Crea una schematizzazione simile a questa. Abbiamo StatefulSet, Pod, ConfigMap per ogni replica e un ConfigMap per l'intero cluster. I servizi sono indispensabili come punti di accesso al cluster.
I servizi comprendono il Load Balancer Service centrale e, per ogni replica, per ogni shard è possibile avere anche altri servizi.
Ecco come appare un cluster di base. È composto da una singola nodo.
Procediamo e rendiamo le cose più complesse. È necessario shardare il cluster.
Le nostre esigenze stanno aumentando, inizia la dinamica. Vogliamo aggiungere uno shard. Seguiamo lo sviluppo. Modifichiamo la nostra specifica. Indichiamo che vogliamo due shard.
Questo è lo stesso file che si sviluppa dinamicamente con la crescita del sistema. Non c'è storage, ma questo sarà trattato più avanti, è un argomento a parte.
Forniamo l'operatore YAML e vediamo cosa ne risulta.
L'operatore ha pensato e ha creato le seguenti entità. Abbiamo già due Pod, tre Service e, inaspettatamente, 2 StatefulSet. Perché 2 StatefulSet?
Nello schema era così - questo è il nostro stato iniziale, quando avevamo un solo pod.
È diventato così. Per ora, è tutto semplice, è stato duplicato.
E perché sono diventati due StatefulSet? Qui dobbiamo distoglierci e discutere come avviene la gestione dei Pod in Kubernetes.
C'è un oggetto chiamato StatefulSet, che consente di creare un insieme di Pod da un modello. Qui il fattore chiave è il Template. È possibile eseguire molti Pod da un unico StatefulSet utilizzando lo stesso modello. La frase chiave qui è «da un solo modello molti Pod».
C'era una forte tentazione di creare l'intero cluster, racchiudendo tutto in un unico StatefulSet. Questo funzionerebbe, non ci sono problemi in tal senso. Ma c'è un aspetto da considerare. Se vogliamo costruire un cluster eterogeneo, ovvero composto da diverse versioni di ClickHouse, qui iniziano i problemi. Sì, StatefulSet può eseguire un aggiornamento rolling, sì, è possibile aggiornare alla nuova versione, specificando che non si dovrebbero avere più di un certo numero di nodi contemporaneamente.
Ma se esponiamo il problema e diciamo che vogliamo creare un cluster completamente eterogeneo e non vogliamo passare da una vecchia versione a una nuova tramite un aggiornamento rolling, ma vogliamo semplicemente costruire un cluster eterogeneo sia in termini di diverse versioni di ClickHouse che di diversi tipi di storage. Vogliamo, ad esempio, che alcune repliche siano su dischi separati, su dischi lenti; in sostanza, costruire un cluster completamente eterogeneo. E poiché StatefulSet crea una soluzione standardizzata da un modello unico, non è possibile farlo.
Dopo qualche riflessione, è stata presa la decisione di procedere in questo modo. Ogni replica avrà il proprio StatefulSet. Ci sono alcuni svantaggi a questa soluzione, ma nella pratica tutto viene completamente incapsulato dall'operatore. E ci sono molti vantaggi. Possiamo costruire un cluster esattamente come vogliamo, ad esempio completamente eterogeneo. Pertanto, nel cluster in cui abbiamo due shard con una replica ciascuno, avremo 2 StatefulSet e 2 Pod proprio perché abbiamo scelto questo approccio per le ragioni sopra menzionate, al fine di costruire un cluster eterogeneo.
Torniamo alle questioni pratiche. Nel nostro cluster dobbiamo configurare gli utenti, cioè dobbiamo eseguire alcune configurazioni di ClickHouse in Kubernetes. L'operatore fornisce tutte le opzioni necessarie per questo.
Possiamo scrivere direttamente in YAML ciò che desideriamo. Tutte le opzioni di configurazione si mappano direttamente da questo YAML nei file di configurazione di ClickHouse, che poi vengono distribuiti in tutto il cluster.
Si può scrivere anche in questo modo. Questo è solo un esempio. È possibile impostare una password criptata. Tutte le opzioni di configurazione di ClickHouse sono assolutamente supportate. Qui c'è solo un esempio.
La configurazione del cluster viene distribuita come ConfigMap. Nella pratica, l'aggiornamento del ConfigMap non avviene immediatamente, quindi, se il cluster è grande, il processo di aggiornamento della configurazione richiede un certo tempo. Ma tutto ciò è molto conveniente nella gestione.
Complichiamo il compito. Il cluster si sta sviluppando. Vogliamo replicare i dati. Cioè, abbiamo già due shard, ciascuno con una replica, e gli utenti sono configurati. Cresciamo e vogliamo occuparci della replicazione.
Di cosa abbiamo bisogno per la replicazione?
Abbiamo bisogno di ZooKeeper. In ClickHouse, la replicazione è costruita utilizzando ZooKeeper. ZooKeeper è necessario affinché diverse repliche di ClickHouse abbiano consenso su quali blocchi di dati ci sono su ciascun ClickHouse.
Puoi usare qualsiasi ZooKeeper. Se l'impresa ha un ZooKeeper esterno, può essere utilizzato. Se non c'è, si può installare uno dal nostro repository. C'è un installer che semplifica tutto questo.
E lo schema di interazione dell'intero sistema risulta essere così. Abbiamo Kubernetes come piattaforma. Su di esso viene eseguito l'operatore ClickHouse. Ho rappresentato ZooKeeper qui. E l'operatore interagisce sia con ClickHouse che con ZooKeeper. Cioè, risulta un'interazione.
E tutto ciò è necessario affinché ClickHouse replichi con successo i dati in k8s.
Ora diamo un'occhiata al compito stesso, a come apparirà il manifesto per la replicazione.
Aggiungiamo due sezioni al nostro manifesto. La prima è dove prendere ZooKeeper, che può essere sia all'interno di Kubernetes sia esterno. Questo è solo una descrizione. E richiediamo repliche. Cioè, vogliamo due repliche. In totale, quindi, dovremmo avere 4 pod. Ricordiamo lo storage, tornerà più avanti. Lo storage è una questione a parte.
Era così.
Diventa così. Vengono aggiunte le repliche. La quarta non ci stava, ma crediamo che possano essercene molte. E a lato viene aggiunto ZooKeeper. Gli schemi si complicano.
È giunto il momento di aggiungere il compito successivo. Aggiungeremo lo Storage Persistente.
Per lo Storage Persistente abbiamo diverse opzioni di implementazione.
Nel caso in cui ci troviamo in un cloud provider, ad esempio, utilizzando Amazon o Google, c'è una grande tentazione di utilizzare lo storage cloud. È molto conveniente, è ottimo.
E c'è una seconda opzione. Questa è per il local storage, quando abbiamo dischi locali su ogni nodo. Questa opzione è molto più complessa da implementare, ma è anche più performante.
Diamo un'occhiata a cosa abbiamo riguardo al cloud storage.
Ci sono vantaggi. È molto semplice da configurare. Ordiniamo semplicemente al fornitore di cloud, che ci dia, per favore, uno storage di tale capacità, di tale classe. Le classi sono definite dai fornitori stessi.
E c'è uno svantaggio. Per qualcuno potrebbe non essere un problema critico. Ovviamente ci saranno alcune ripercussioni sulle prestazioni. È molto comodo lavorare, affidabile, ma ci sono alcune potenziali cadute di prestazioni.
Poiché ClickHouse si concentra proprio sulle prestazioni, si potrebbe dire che estrae tutto ciò che è possibile, quindi molti clienti cercano di ottenere il massimo delle prestazioni.
E per ottenere il massimo, abbiamo bisogno del local storage.
Kubernetes fornisce tre astrazioni per utilizzare il local storage in Kubernetes. Esse sono:
- EmptyDir
- HostPath.
- Local
Esaminiamo come si differenziano e come sono simili.
In primo luogo, in tutti e tre gli approcci abbiamo storage – dischi locali che si trovano sullo stesso nodo fisico di k8s. Ma ci sono alcune differenze.
Iniziamo con la cosa più semplice, ovvero con emptyDir. Cosa significa questo in pratica? Chiediamo al nostro specifica di richiedere al sistema di containerizzazione (solitamente – Docker) di fornirci accesso a una cartella sul disco locale.
In pratica, Docker crea da qualche parte i suoi percorsi propri una cartella temporanea, chiamandola con un lungo hash. E fornisce l'interfaccia di accesso ad essa.
Come funzionerà in termini di prestazioni? Funzionerà alla velocità del disco locale, quindi c'è accesso completo al proprio disco.
Ma questa operazione ha il suo svantaggio. La persistenza in questo caso è piuttosto dubbia. Alla prima movimentazione dei container da parte di Docker, la persistenza si perde. Se Kubernetes decidesse per qualche motivo di spostare questo Pod su un altro disco, i dati andranno persi.
Questo approccio è buono per i test, perché mostra già una velocità normale, ma per qualcosa di serio questa opzione non è adatta.
Ecco perché c'è un secondo approccio. Si tratta di hostPath. Se si guarda alla diapositiva precedente e a questa, si può vedere solo una differenza. La nostra cartella è uscita dal Docker direttamente sul nodo Kubernetes. Qui è un po' più semplice. Scriviamo direttamente il percorso nel file system locale, dove vogliamo conservare i nostri dati.
Ci sono vantaggi in questo metodo. Questo è un vero Persistent, e anche classico. I dati saranno salvati su disco a un certo indirizzo.
Ci sono anche degli svantaggi. C'è la complessità della gestione. Il nostro Kubernetes potrebbe voler spostare un Pod su un altro nodo fisico. E qui entra in gioco il DevOps. Deve spiegare correttamente all'intero sistema che questi pod possono essere spostati solo su nodi specifici, dove hai montato qualcosa lungo quei percorsi, e non più di un nodo alla volta. È abbastanza complicato.
Appositamente per questi scopi, abbiamo creato dei modelli nel nostro operatore per nascondere tutta questa complessità. E sarebbe possibile semplicemente dire: «Voglio un'istanza di ClickHouse su ogni nodo fisico e su un certo percorso».
Ma questa necessità non è solo nostra, quindi i gentiluomini di Kubernetes capiscono anche che le persone vogliono avere accesso ai dischi fisici, quindi offrono un terzo livello.
Si chiama local. Non c'è praticamente alcuna differenza rispetto alla diapositiva precedente. Solo in passato dovevamo gestire manualmente che non potevamo trasferire questi pod da un nodo all'altro, perché dovevano essere collegati a un certo percorso sul disco fisico locale, mentre ora tutta questa conoscenza è incapsulata all'interno di Kubernetes stesso. Risulta molto più semplice configurare.
Torniamo al nostro compito pratico. Torniamo al modello YAML. Qui abbiamo un vero storage. Siamo tornati a questo. Definiamo il modello VolumeClaim classico come in k8s. E descriviamo quale storage vogliamo.
Dopo di che k8s richiederà lo storage. Ce lo assegnerà nel StatefulSet. E alla fine diventerà di pertinenza di ClickHouse.
Avevamo uno schema del genere. Il nostro Persistent Storage era rosso, il che suggeriva che doveva essere realizzato.
E diventa verde. Ora lo schema del cluster ClickHouse su k8s è completamente finalizzato. Abbiamo shard, repliche, ZooKeeper, e c'è un vero Persistent, che è implementato in un modo o nell'altro. Lo schema è già completamente funzionante.
Continuiamo a vivere. Il nostro cluster si sta sviluppando. E Alexey sta cercando di fare del suo meglio, rilasciando una nuova versione di ClickHouse.
Si presenta un compito pratico: testare la nuova versione di ClickHouse sul nostro cluster. E naturalmente, non vogliamo installarla su tutto il cluster, vorremmo metterla in un angolo remoto, magari su una replica, oppure, forse, non solo su una nuova versione, ma addirittura su due, poiché escono piuttosto spesso.
Cosa possiamo dire al riguardo?
Abbiamo precisamente questa opportunità. Sono i template dei pod. Possiamo scrivere, il nostro operatore consente completamente di costruire un cluster eterogeneo. Cioè, configurare, partendo da tutte le repliche accumulate, fino ad ogni singola replica, indicando quale versione di ClickHouse vogliamo, quale versione di storage desideriamo. Possiamo configurare completamente il cluster nella configurazione di cui abbiamo bisogno.
Ci addentriamo un po' di più. Prima abbiamo parlato di come funziona ClickHouse-operator in relazione alle specificità di ClickHouse.
Ora vorrei dire qualche parola su come funziona in generale qualsiasi operatore, e su come interagisce con K8s.
Iniziamo con l'interazione con K8s. Cosa succede quando facciamo kubectl apply? I nostri oggetti appaiono in etcd tramite l'API.
Per esempio, gli oggetti di base di Kubernetes: pod, StatefulSet, servizio e così via.
In questo momento, nulla di fisico accade ancora. Questi oggetti devono essere materializzati nel cluster.
Per farlo, appare un controller. Il controller è un componente speciale di k8s, che sa come materializzare queste descrizioni. Sa come e cosa fare fisicamente. Sa come avviare i container, cosa deve essere configurato affinché il server funzioni.
E materializza i nostri oggetti in K8s.
Ma vogliamo operare non solo con i pod e con gli StatefulSet, vogliamo creare ClickHouseInstallation, cioè un oggetto di tipo ClickHouse, per operarlo come un'unità unica. Al momento, non c'è tale possibilità.
Ma K8s ha una cosa piacevole. Vogliamo che appaia da qualche parte un'entità complessa come questa, in cui il nostro cluster sia raccolto da pod e StatefulSet.
E cosa bisogna fare per questo? Innanzitutto, entra in gioco la Custom Resource Definition. Che cos'è? È una descrizione per K8s, che indica che avrai un altro tipo di dato, che vogliamo aggiungere come risorsa personalizzata all'interno di pod, StatefulSet. È una descrizione della struttura dei dati.
Lo inviamo anche lì tramite kubectl apply. Kubernetes lo ha accolto con gioia.
E ora nel nostro storage, l'oggetto in etcd ha la possibilità di registrare una risorsa personalizzata chiamata ClickHouseInstallation.
Ma finora non succederà altro. Cioè, se ora creiamo un file YAML, che abbiamo esaminato, con la descrizione di shard, repliche e diciamo "kubectl apply", Kubernetes lo accetterà, lo metterà in etcd e dirà: "Ottimo, ma non so cosa farci. Come gestire ClickHouseInstallation non lo so."
Di conseguenza, abbiamo bisogno di qualcuno che aiuti Kubernetes a gestire il nuovo tipo di dato. A sinistra abbiamo il controller standard di Kubernetes, che lavora con i tipi di dato standard. A destra deve apparire un controller personalizzato, che sa lavorare con i tipi di dato personalizzati.
E con un nome diverso è chiamato operatore. L'ho portato qui appositamente fuori da Kubernetes, perché può essere eseguito anche esternamente a K8s. Di solito, tutti gli operatori vengono eseguiti in Kubernetes, ma nulla impedisce loro di operare esternamente; perciò qui è stato scelto di posizionarlo all'esterno.
E il controller personalizzato, cioè l'operatore, interagisce con Kubernetes tramite l'API. Sa già come interagire con l'API. E sa già come materializzare una complessa architettura a partire dalla risorsa personalizzata che vogliamo creare. Questo è precisamente ciò di cui si occupa l'operatore.
Come funziona l'operatore? Diamo un'occhiata alla parte destra per scoprire come fa. Scopriamo come l'operatore materializza tutto questo e come avviene l'interazione con K8s.
L'operatore è un programma. È orientato agli eventi. L'operatore si iscrive agli eventi tramite l'API di Kubernetes. L'API di Kubernetes ha dei punti di accesso dove ci si può iscrivere agli eventi. E se qualcosa cambia in K8s, Kubernetes invia eventi a tutti coloro che lo desiderano, cioè chi si è iscritto a questo punto API riceverà notifiche.
L'operatore si iscrive agli eventi e deve fare qualche reazione. Il suo compito è reagire agli eventi che si presentano.
Gli eventi vengono generati da alcuni aggiornamenti. Arriva il nostro file YAML con la descrizione di ClickHouseInstallation. È passato attraverso kubectl apply in etcd. Lì si è attivato un evento, e alla fine questo evento è arrivato al ClickHouse-operator. L'operatore ha ricevuto questa descrizione. E deve fare qualcosa. Se è arrivato un aggiornamento per l'oggetto ClickHouseInstallation, allora bisogna aggiornare il cluster. E il compito dell'operatore è aggiornare il cluster.
Cosa fa? Innanzitutto, deve pianificare le azioni, cioè cosa faremo con questo aggiornamento. Gli aggiornamenti possono essere molto piccoli, quindi piccoli nell'esecuzione YAML, ma possono comportare cambiamenti molto grandi nel cluster. Perciò l'operatore crea un piano e poi lo segue.
Inizia a elaborare questa struttura secondo il piano, per materializzare i pod, i servizi, cioè fare ciò che è il suo compito principale. È come costruire un cluster ClickHouse in Kubernetes.
Ora parliamo di una cosa interessante. Questa è la divisione delle responsabilità tra Kubernetes e l'operatore, cioè cosa fa Kubernetes, cosa fa l'operatore e come interagiscono tra loro.
Kubernetes si occupa di questioni sistemiche, cioè dell'insieme di base di oggetti che possono essere interpretati come system-scope. Kubernetes sa come avviare i pod, come riavviare i container, come montare i volumi, come lavorare con ConfigMap, cioè tutto ciò che si può definire sistema.
Gli operatori operano in aree tematiche. Ogni operatore è creato per la propria area di competenza. Noi abbiamo creato quello per ClickHouse.
E l'operatore interagisce esattamente in termini di aree tematiche come aggiungere una replica, creare uno schema, configurare il monitoraggio. Si ottiene quindi questa divisione.
Esaminiamo un esempio pratico di come avviene questa divisione di responsabilità quando compiamo l'azione di aggiungere una replica.
All'operatore arriva un compito: aggiungere una replica. Cosa fa l'operatore? L'operatore calcola che deve creare un nuovo StatefulSet, in cui bisogna descrivere certi modelli e il reclamo del volume.
Ha preparato tutto questo e lo passa successivamente a K8s. Dice che ha bisogno di ConfigMap, StatefulSet, Volume. Kubernetes elabora. Materializza le unità di base con cui opera.
E poi interviene di nuovo ClickHouse-operator. Ha già a disposizione un pod fisico, su cui è possibile lavorare. E ClickHouse-operator opera nuovamente in termini di dominio. Cioè, specificamente ClickHouse, per includere una replica nel cluster, bisogna, prima di tutto, configurare lo schema dei dati presente in quel cluster. E, in secondo luogo, questa replica deve essere inclusa nel monitoraggio, affinché possa essere seguita correttamente. Già l'operatore si occupa di questa configurazione.
E solo dopo questo entra in gioco ClickHouse stesso, cioè un'entità di livello superiore. Questo è già un database. Ha il suo instance, una replica configurata, pronta per unirsi al cluster.
Si ottiene così una catena di esecuzione e divisione delle responsabilità per l'aggiunta di una replica piuttosto lunga.
Procediamo con le nostre attività pratiche. Se il cluster esiste già, si può effettuare la migrazione della configurazione.
Abbiamo fatto in modo che nel file xml esistente, che ClickHouse comprende, si possa trasmettere senza problemi.
È possibile effettuare un'assistenza fine di ClickHouse. Infatti, il zoned deployment è ciò di cui ho parlato durante la spiegazione di hostPath e local storage. È il modo corretto per effettuare un zoned deployment.
Il prossimo compito pratico riguarda il monitoraggio.
Se il nostro cluster cambia, è necessario configurare periodicamente il monitoraggio.
Esaminiamo lo schema. Abbiamo già considerato le frecce verdi. Ora esaminiamo le frecce rosse. Questo riguarda il modo in cui desideriamo monitorare il nostro cluster. Come le metriche dal cluster ClickHouse vengono trasferite a Prometheus e poi a Grafana.
Qual è la complessità del monitoraggio? Perché è considerato un risultato? La complessità riguarda proprio la dinamica. Quando abbiamo un cluster statico, è possibile configurare il monitoraggio una volta e non pensarci più.
Ma se abbiamo molti cluster, o se c'è un costante cambiamento, il processo è dinamico. E occuparsi continuamente di ripristinare il monitoraggio è una perdita di risorse e tempo, cioè anche semplicemente pigrizia. È necessario automatizzare tutto questo. La complessità sta proprio nella dinamica del processo. E l'operatore automatizza tutto questo molto bene.
Come è evoluto il nostro cluster? All'inizio era così.
Poi è diventato così.
Alla fine è diventato così.
E il monitoraggio viene eseguito automaticamente dall'operatore. Punto di ingresso unico.
E noi guardiamo semplicemente, in uscita, nel dashboard di Grafana, come vive il nostro cluster.
A proposito, il dashboard di Grafana è distribuito insieme al nostro operatore direttamente nel codice sorgente. Puoi collegarlo e utilizzarlo. Questa è uno screenshot fornito dai nostri DevOps.
Dove vorremmo andare avanti? Questo è:
- Sviluppare l'automazione dei test. L'obiettivo principale è il test automatizzato delle nuove versioni.
- Inoltre, desideriamo molto automatizzare l'integrazione con ZooKeeper. E nei piani c'è l'integrazione con ZooKeeper-operator. Cioè, per ZooKeeper è stato scritto un operatore e ha senso che due operatori comincino a integrarsi per costruire una soluzione più comoda.
- Vogliamo fare controlli di vitalità più complessi.
- In verde ho evidenziato ciò che abbiamo in arrivo, l'ereditarietà dei Templates – FATTO, cioè con il prossimo rilascio dell'operatore avremo già l'ereditarietà dei modelli. Questo è uno strumento potente che permette di costruire configurazioni complesse a pezzi.
- E vogliamo automatizzare compiti complessi. Il principale di questi è il Re-sharding.
Facciamo un bilancio intermedio.
Cosa otteniamo in uscita? Vale la pena dedicarcisi o no? È necessario provare a portare il database in Kubernetes e applicare l'operatore in generale e l'operatore Alitnity in particolare.
In uscita otteniamo:
- Un notevole semplificazione e automazione della configurazione, del dispiego e anche della manutenzione.
- Monitoraggio integrato immediato.
- E modelli codificati già pronti per situazioni complesse. Non è più necessario aggiungere una replica manualmente. Questo lo fa l'operatore.
Rimane solo l'ultima domanda. Abbiamo già un database in Kubernetes, virtualizzazione. Qual è la prestazione di questa soluzione, specialmente considerando che ClickHouse è ottimizzato per le prestazioni?
La risposta è – tutto bene! Non entrerò nei dettagli, è un tema di una presentazione separata.
Ma c'è un progetto chiamato TSBS. Qual è il suo obiettivo principale? È un test di database per le prestazioni. È un tentativo di confrontare il simile con il simile, il morbido con il morbido.
Come funziona? Viene generato un set di dati. Poi, questo set di dati viene testato su diversi database con gli stessi test. E ogni database risolve un compito come meglio può. E poi i risultati possono essere confrontati.
Supporta già un gran numero di database. Ne ho evidenziati tre principali. Sono:
- TimescaleDB.
- InfluxDB.
- ClickHouse.
È stata inoltre effettuata un'analisi rispetto a un'altra soluzione simile. È stato un confronto con RedShift. Il confronto è stato effettuato su Amazon. ClickHouse supera anche in questo caso tutti gli altri.
Quali conclusioni possiamo trarre da quanto ho raccontato?
- DB su Kubernetes è possibile. Probabilmente qualsiasi DB è utilizzabile, ma in generale sembra fattibile. ClickHouse su Kubernetes è sicuramente utilizzabile con il nostro operatore.
- L'operatore aiuta ad automatizzare i processi e semplifica realmente la vita.
- Le prestazioni sono normali.
- E ci sembra che questo possa e debba essere utilizzato.
Open source – unitevi!
Come ho già detto, l'operatore è un prodotto completamente open source, quindi sarebbe davvero bello se il maggior numero possibile di persone lo utilizzasse. Unitevi a noi! Vi aspettiamo tutti!
Grazie a tutti!
Domande
Grazie per la presentazione! Mi chiamo Anton. Vengo dall'azienda SEMrush. Sono curioso riguardo il logging. Si sente parlare di monitoraggio, ma non di logging, se parliamo dell'intero cluster. Noi, ad esempio, abbiamo un cluster montato su hardware. Utilizziamo logging centralizzato, raccogliendo standardamente in un'unica soluzione. Poi estraiamo i dati interessanti da lì.
Buona domanda, ossia il logging è nella lista delle cose da fare. Il nostro operatore attualmente non lo automatizza. È ancora in fase di sviluppo, il progetto è ancora abbastanza giovane. Comprendiamo l'importanza del logging. È un tema molto rilevante e probabilmente altrettanto importante quanto il monitoraggio. Ma il primo della lista per l'implementazione è stato il monitoraggio. Il logging ci sarà. Naturalmente, ci sforziamo di automatizzare tutti gli aspetti della vita del cluster. Quindi, la risposta è: al momento l'operatore, sfortunatamente, non lo sa fare, ma è nei nostri piani, lo faremo. Se desiderate unirvi, un pull request, per favore.
Buongiorno! Grazie per la presentazione! Ho una domanda standard riguardo i Persistent Volumes. Quando creiamo una configurazione con questo operatore, come fa l'operatore a determinare su quale nodo abbiamo montato un disco o una cartella? Dobbiamo spiegargli in anticipo che, per favore, posiziona il nostro ClickHouse esattamente su questi nodi, quelli dove c'è un disco?
Per quanto ne so, questa domanda è un'estensione dello storage locale, in particolare della sua parte riguardante il hostPath. È come spiegare all'intero sistema che è necessario far partire un pod su un nodo specifico, su cui abbiamo un disco fisicamente connesso, montato in un determinato percorso. È un'intera sezione che ho toccato in modo molto superficiale, perché la risposta è piuttosto ampia.
In breve, si presenta così. Dobbiamo ovviamente fare il provisioning di questi volumi. Al momento, nel local storage non c'è provisioning dinamico, quindi i DevOps devono creare i dischi, ovvero questi volumi, manualmente. Devono anche spiegare a Kubernetes il provisioning, specificando che avremo Persistent volumes di un certo tipo, situati su determinati nodi. Poi sarà necessario spiegare a Kubernetes che i pod che richiedono quella classe di storage locale devono essere schedulati solo su quei nodi, tramite le etichette. A questo scopo, l'operatore ha la possibilità di assegnare alcune etichette e una per ogni istanza host. Così i pod saranno instradati da Kubernetes per essere avviati solo su nodi che soddisfano i requisiti delle etichette, parlando in termini semplici. Gli amministratori assegnano le etichette e fanno il provisioning dei dischi manualmente. In questo modo, il tutto si scalda.
E proprio la terza opzione locale aiuta un po' a semplificare la situazione. Come ho già sottolineato, si tratta di un lavoro meticoloso di configurazione, che alla fine aiuta a ottenere massime prestazioni.
Ho una seconda domanda correlata a questo. Kubernetes è stato pensato in modo tale da non preoccuparsi se perdiamo un nodo o meno. Cosa dobbiamo fare in questo caso se perdiamo il nodo su cui si trova un shard?
Sì, Kubernetes è stato inizialmente posizionato in modo che il nostro rapporto con i pod fosse simile a quello degli animali da allevamento, mentre ora ogni disco diventa qualcosa di simile a un animale domestico. Esiste un problema: non possiamo semplicemente scartarli. Lo sviluppo di Kubernetes sta andando verso una direzione in cui non è possibile considerare tutto filosoficamente come risorse completamente eliminabili.
Ora una domanda pratica. Cosa fare se hai perso un nodo su cui si trovava un disco? Qui il problema deve essere affrontato a un livello superiore. Nel caso di ClickHouse, abbiamo repliche che funzionano a un livello superiore, cioè a livello di ClickHouse.
Qual è la disposizione risultante? DevOps è responsabile della conservazione dei dati. Deve configurare correttamente la replica e deve monitorare il suo svolgimento. I dati devono essere duplicati nella replica a livello di ClickHouse. Questa non è un'operazione che svolge l'operatore, né è un compito che deve gestire Kubernetes. È a livello di ClickHouse.
Cosa fare se il nodo hardware si guasta? In questo caso, sarà necessario installarne un secondo, configurare correttamente il disco e applicare le etichette. Dopo di che, dovrà soddisfare i requisiti affinché Kubernetes possa avviare un'istanza del pod. Kubernetes lo avvierà. Non hai abbastanza pod rispetto a quanto richiesto. Essa passerà attraverso un ciclo, come ho mostrato. E al livello più alto, ClickHouse capirà che è stata aggiunta una replica, è ancora vuota e bisogna iniziare a trasferirvi i dati. Cioè, questo processo è ancora poco automatizzato.
Grazie per la presentazione! Quando si verificano problemi e l'operatore si arresta e si riavvia, nel frattempo arrivano eventi, come gestisci la situazione?
Cosa succede se l'operatore si arresta e si riavvia?
Esatto. E in quel momento sono arrivati eventi.
Il compito di cosa fare in questo caso è parzialmente suddiviso tra l'operatore e Kubernetes. Kubernetes ha la possibilità di riprodurre l'evento che è accaduto. Lo riproduce. Il compito dell'operatore è assicurarsi che, quando viene fatto il replay del log degli eventi, questi siano idempotenti. E che l'ingresso ripetuto dello stesso evento non rompa il nostro sistema. E il nostro operatore gestisce questo compito.
Buongiorno! Grazie per la presentazione! Dmitry Zavyalov, azienda Smedova. È prevista l'aggiunta all'operatore della possibilità di configurazione con haproxy? Sarei interessato a un altro bilanciatore oltre a quello standard, che sia intelligente e capisca che si tratta di ClickHouse.
Stai parlando di Ingress?
Sì, sostituire Ingress con haproxy. In haproxy è possibile specificare la topologia del cluster, dove ha le repliche.
Per ora non ci abbiamo pensato. Se avete bisogno di questo e potete spiegare perché sia necessario, possiamo implementarlo, soprattutto se volete partecipare. Siamo felici di considerare questa opzione. La risposta breve è: no, al momento non abbiamo questa funzionalità. Grazie per il suggerimento, ci daremo un'occhiata. E se poteste anche spiegare il caso d'uso e perché sia utile nella pratica, per esempio creando issue su GitHub, sarebbe fantastico.
C'è già.
Va bene. Siamo aperti a qualsiasi proposta. E haproxy è nella lista delle cose da fare. La lista delle cose da fare sta crescendo e non diminuendo per ora. Ma va bene, significa che il prodotto è richiesto.
Fonte: habr.com
