Il rapporto è dedicato alle questioni pratiche relative allo sviluppo di un operatore in Kubernetes, alla progettazione della sua architettura e dei principi operativi di base.
Nella prima parte del rapporto considereremo:
- cos'è un operatore in Kubernetes e perché è necessario;
- come esattamente l'operatore semplifica la gestione di sistemi complessi;
- cosa l'operatore può e non può fare.
Passiamo ora alla discussione della struttura interna dell'operatore. Vediamo passo dopo passo l'architettura e il funzionamento dell'operatore. Vediamolo in dettaglio:
- interazione tra operatore e Kubernetes;
- quali funzioni assume l'operatore e quali funzioni delega a Kubernetes.
Diamo un'occhiata alla gestione degli shard e delle repliche di database in Kubernetes.
Successivamente, discuteremo i problemi di archiviazione dei dati:
- come lavorare con Persistent Storage dal punto di vista dell'operatore;
- insidie dell'utilizzo dell'archiviazione locale.
Nella parte finale del rapporto prenderemo in considerazione esempi pratici di applicazione da Amazon o Google Cloud Service. Il rapporto si basa sull'esempio dello sviluppo e dell'esperienza operativa di un operatore per ClickHouse.
Video:
Il mio nome è Vladislav Klimenko. Oggi volevo parlare della nostra esperienza nello sviluppo e nel funzionamento di un operatore, e questo è un operatore specializzato nella gestione dei cluster di database. Per esempio per gestire il cluster ClickHouse.
Perché abbiamo l'opportunità di parlare dell'operatore e di ClickHouse?
- Supportiamo e sviluppiamo ClickHouse.
- Al momento stiamo cercando di dare pian piano il nostro contributo allo sviluppo di ClickHouse. E siamo secondi dopo Yandex in termini di volume di modifiche apportate a ClickHouse.
- Stiamo cercando di creare ulteriori progetti per l'ecosistema ClickHouse.
Vorrei parlarvi di uno di questi progetti. Si tratta dell'operatore ClickHouse per Kubernetes.
Nella mia relazione vorrei toccare due argomenti:
- Il primo argomento riguarda il modo in cui funziona il nostro operatore di gestione del database ClickHouse in Kubernetes.
- Il secondo argomento riguarda il funzionamento di qualsiasi operatore, ovvero come interagisce con Kubernetes.
Tuttavia, queste due domande si intersecheranno nel corso della mia relazione.
Chi sarebbe interessato ad ascoltare quello che sto cercando di raccontare?
- Sarà di grande interesse per coloro che gestiscono gli operatori.
- Oppure per chi vuole crearne uno proprio per capire come funziona internamente, come l'operatore interagisce con Kubernetes e quali insidie possono apparire.
Per comprendere al meglio ciò di cui parleremo oggi, è una buona idea sapere come funziona Kubernetes e avere una formazione di base sul cloud.
Cos'è ClickHouse? Si tratta di un database a colonne con funzionalità specifiche per l'elaborazione online di query analitiche. Ed è completamente open source.
Ed è importante per noi sapere solo due cose. Devi sapere che questo è un database, quindi quello che ti dirò sarà applicabile a quasi tutti i database. E il fatto che il DBMS ClickHouse si adatti molto bene, offre una scalabilità quasi lineare. Pertanto, lo stato del cluster è uno stato naturale per ClickHouse. E siamo molto interessati a discutere su come servire il cluster ClickHouse in Kubernetes.
Perché è necessario lì? Perché non possiamo continuare a gestirlo da soli? E le risposte sono in parte tecniche e in parte organizzative.
- In pratica, ci troviamo sempre più spesso di fronte a una situazione in cui nelle grandi aziende quasi tutti i componenti sono già in Kubernetes. I database restano fuori.
- E sempre più spesso ci si chiede: “Si può mettere questo dentro?” Pertanto, le grandi aziende stanno cercando di raggiungere la massima unificazione gestionale per poter gestire rapidamente i propri data warehouse.
- E questo aiuta soprattutto se hai bisogno della massima opportunità di ripetere la stessa cosa in un posto nuovo, cioè della massima portabilità.
Quanto è facile o difficile? Questo, ovviamente, può essere fatto a mano. Ma non è così semplice, perché abbiamo la complessità aggiuntiva della gestione di Kubernetes stesso, ma allo stesso tempo si sovrappongono le specificità di ClickHouse. E tale aggregazione risulta.
E nel complesso ciò fornisce un insieme abbastanza ampio di tecnologie, che diventa piuttosto difficile da gestire, perché Kubernetes porta in funzione i propri problemi quotidiani e ClickHouse porta i propri problemi in operazioni quotidiane. Soprattutto se abbiamo diverse ClickHouse e dobbiamo costantemente fare qualcosa con loro.
Con una configurazione dinamica, ClickHouse presenta un numero abbastanza elevato di problemi che creano un carico costante su DevOps:
- Quando vogliamo cambiare qualcosa in ClickHouse, ad esempio aggiungere una replica o uno shard, dobbiamo gestire la configurazione.
- Quindi modifica lo schema dei dati, perché ClickHouse ha un metodo di sharding specifico. Lì è necessario disporre il diagramma dei dati, disporre le configurazioni.
- È necessario impostare il monitoraggio.
- Raccolta di log per nuovi frammenti, per nuove repliche.
- Occupatevi del restauro.
- E ricominciare.
Queste sono attività di routine che mi piacerebbe davvero rendere più facili da usare.
Kubernetes stesso aiuta bene nel funzionamento, ma sulle cose di sistema di base.
Kubernetes è bravo a facilitare e automatizzare cose come:
- Recupero.
- Ricomincia.
- Gestione del sistema di archiviazione.
Va bene, è la direzione giusta, ma non ha alcuna idea di come gestire un cluster di database.
Vogliamo di più, vogliamo che l'intero database funzioni in Kubernetes.
Vorrei ottenere qualcosa come un grande pulsante rosso magico che premi e un cluster con le attività quotidiane che devono essere risolte viene distribuito e mantenuto durante tutto il suo ciclo di vita. Cluster ClickHouse in Kubernetes.
E abbiamo provato a trovare una soluzione che aiutasse a semplificare il lavoro. Questo è un operatore ClickHouse per Kubernetes di Altinity.
Un operatore è un programma il cui compito principale è gestire altri programmi, ovvero è un manager.
E contiene modelli di comportamento. Puoi chiamare questa conoscenza codificata sull'area tematica.
E il suo compito principale è rendere la vita di DevOps più semplice e ridurre la microgestione, in modo che lui (DevOps) pensi già in termini di alto livello, cioè in modo che lui (DevOps) non si impegni nella microgestione, in modo da non configurare tutti i dettagli manualmente.
E proprio l'operatore è un assistente robotico che si occupa di microtask e aiuta DevOps.
Perché hai bisogno di un operatore? Si comporta particolarmente bene in due aree:
- Quando lo specialista che si occupa di ClickHouse non ha abbastanza esperienza, ma ha già bisogno di far funzionare ClickHouse, l'operatore facilita l'operazione e permette di gestire un cluster ClickHouse con una configurazione piuttosto complessa, senza entrare troppo nei dettagli su come funziona il tutto dentro. Gli dai semplicemente compiti di alto livello e funziona.
- E il secondo compito in cui dà i migliori risultati è quando è necessario automatizzare un gran numero di compiti tipici. Rimuove le microattività dagli amministratori di sistema.
Ciò è particolarmente necessario sia per coloro che hanno appena iniziato il loro viaggio, sia per coloro che hanno bisogno di fare molta automazione.
In cosa differisce l’approccio basato sull’operatore dagli altri sistemi? C'è Helm. Aiuta anche a installare ClickHouse; puoi disegnare grafici helm, che installeranno persino un intero cluster ClickHouse. Qual è allora la differenza tra l'operatore e lo stesso, ad esempio, Helm?
La principale differenza fondamentale è che Helm è la gestione dei pacchetti e Operator fa un ulteriore passo avanti. Questo è il supporto per l'intero ciclo di vita. Non si tratta solo di installazione, si tratta di attività quotidiane che includono ridimensionamento, sharding, ovvero tutto ciò che deve essere fatto durante il ciclo di vita (se necessario, quindi anche la cancellazione): tutto questo viene deciso dall'operatore. Tenta di automatizzare e mantenere l'intero ciclo di vita del software. Questa è la sua differenza fondamentale rispetto alle altre soluzioni presentate.
Questa era la parte introduttiva, andiamo avanti.
Come costruiamo il nostro operatore? Stiamo cercando di affrontare il problema per gestire il cluster ClickHouse come un'unica risorsa.
Qui abbiamo i dati di input sul lato sinistro dell'immagine. Si tratta di YAML con una specifica del cluster, che viene trasmessa a Kubernetes nel modo classico tramite kubectl. Lì il nostro operatore lo raccoglie e fa la sua magia. E in uscita otteniamo il seguente schema. Questa è un'implementazione di ClickHouse in Kubernetes.
E poi vedremo lentamente come funziona esattamente l'operatore, quali compiti tipici possono essere risolti. Considereremo solo i compiti tipici perché abbiamo tempo limitato. E non tutto ciò che l'operatore può decidere verrà discusso.
Partiamo dalla pratica. Il nostro progetto è completamente open source, quindi puoi vedere come funziona su GitHub. E puoi partire dalla considerazione che se vuoi semplicemente avviarlo, puoi iniziare con la Guida rapida.
Se vuoi capire in dettaglio, cerchiamo di mantenere la documentazione in una forma più o meno decente.
Cominciamo con un problema pratico. Il primo compito, da cui tutti vogliamo iniziare, è eseguire in qualche modo il primo esempio. Come posso avviare ClickHouse utilizzando l'operatore, anche se non so bene come funziona? Stiamo scrivendo un manifesto, perché... Tutta la comunicazione con K8 avviene tramite manifest.
Questo è un manifesto davvero complesso. Ciò che abbiamo evidenziato in rosso è ciò su cui dobbiamo concentrarci. Chiediamo all'operatore di creare un cluster denominato demo.
Questi sono esempi basilari per ora. L'archiviazione non è stata ancora descritta, ma torneremo sull'archiviazione un po' più tardi. Per ora osserveremo le dinamiche di sviluppo del cluster.
Abbiamo creato questo manifesto. Lo diamo in pasto al nostro operatore. Ha lavorato, ha fatto magie.
Guardiamo la console. Sono interessanti tre componenti: un pod, due servizi e uno StatefulSet.
L'operatore ha lavorato e possiamo vedere cosa ha creato esattamente.
Crea qualcosa del genere. Abbiamo uno StatefulSet, Pod, ConfigMap per ogni replica, ConfigMap per l'intero cluster. I servizi sono necessari come punti di ingresso nel cluster.
I servizi costituiscono il servizio di bilanciamento del carico centrale e possono essere utilizzati anche per ogni replica, per ogni shard.
Il nostro cluster di base assomiglia a questo. Proviene da un singolo nodo.
Andiamo oltre e complichiamo le cose. Dobbiamo frammentare il cluster.
I nostri compiti crescono, le dinamiche iniziano. Vogliamo aggiungere un frammento. Seguiamo lo sviluppo. Stiamo modificando le nostre specifiche. Indichiamo che vogliamo due frammenti.
Questo è lo stesso file che si sviluppa dinamicamente con la crescita del sistema. Archiviazione no, l'archiviazione verrà discussa ulteriormente, questo è un argomento separato.
Diamo in pasto l'operatore YAML e vediamo cosa succede.
L'operatore ha pensato e realizzato le seguenti entità. Abbiamo già due Pod, tre Servizi e, improvvisamente, 2 StatefulSet. Perché 2 StatefulSet?
Nel diagramma era così: questo è il nostro stato iniziale, quando avevamo un pod.
È diventato così. Finora tutto è semplice, è stato duplicato.
E perché sono diventati due StatefulSet? Qui dobbiamo fare una digressione e discutere la questione di come vengono gestiti i pod in Kubernetes.
Esiste un oggetto chiamato StatefulSet che ti consente di creare un set di pod da un modello. Il fattore chiave qui è il modello. Inoltre, puoi avviare molti pod utilizzando un modello in uno StatefulSet. E la frase chiave qui è "molti pod per un modello".
E c'era una grande tentazione di creare l'intero cluster, comprimendolo in un unico StatefulSet. Funzionerà, non ci sono problemi. Ma c'è un avvertimento. Se vogliamo assemblare un cluster eterogeneo, cioè da diverse versioni di ClickHouse, iniziano a sorgere delle domande. Sì, StatefulSet può eseguire un aggiornamento in sequenza e lì puoi implementare una nuova versione, spiegando che non devi provare più di tanti nodi contemporaneamente.
Ma se estrapoliamo il compito e diciamo che vogliamo creare un cluster completamente eterogeneo e non vogliamo passare dalla vecchia versione a una nuova utilizzando un rolling update, ma vogliamo semplicemente creare un cluster eterogeneo sia in termini di diverse versioni di ClickHouse e in termini di spazio di archiviazione diverso. Vogliamo, ad esempio, realizzare delle repliche su dischi separati, su quelli lenti, in generale, per costruire completamente un cluster eterogeneo. E poiché StatefulSet crea una soluzione standardizzata da un modello, non esiste alcun modo per farlo.
Dopo qualche riflessione, è stato deciso che avremmo fatto in questo modo. Abbiamo ciascuna replica nel proprio StatefulSet. Questa soluzione presenta alcuni inconvenienti, ma in pratica è tutta completamente incapsulata dall'operatore. E ci sono molti vantaggi. Possiamo costruire esattamente il cluster che desideriamo, ad esempio assolutamente eterogeneo. Pertanto, in un cluster in cui abbiamo due shard con una replica, avremo 2 StatefulSet e 2 Pod proprio perché abbiamo scelto questo approccio per i motivi sopra indicati per poter costruire un cluster eterogeneo.
Torniamo ai problemi pratici. Nel nostro cluster dobbiamo configurare gli utenti, ad es. devi eseguire alcune configurazioni di ClickHouse in Kubernetes. L'operatore offre tutte le possibilità per questo.
Possiamo scrivere quello che vogliamo direttamente in YAML. Tutte le opzioni di configurazione vengono mappate direttamente da questo YAML nelle configurazioni ClickHouse, che vengono poi distribuite in tutto il cluster.
Puoi scriverlo così. Questo è per esempio. La password può essere crittografata. Sono supportate assolutamente tutte le opzioni di configurazione di ClickHouse. Ecco solo un esempio.
La configurazione del cluster è distribuita come ConfigMap. In pratica, l'aggiornamento di ConfigMap non avviene istantaneamente, quindi se il cluster è grande, il processo di push della configurazione richiede del tempo. Ma tutto questo è molto comodo da usare.
Complichiamo il compito. Il cluster si sta sviluppando. Vogliamo replicare i dati. Cioè, abbiamo già due frammenti, una replica ciascuno e gli utenti sono configurati. Stiamo crescendo e vogliamo fare la replica.
Di cosa abbiamo bisogno per la replica?
Abbiamo bisogno di ZooKeeper. In ClickHouse, la replica viene creata utilizzando ZooKeeper. ZooKeeper è necessario affinché le diverse repliche di ClickHouse abbiano un consenso su quali blocchi di dati si trovano su quale ClickHouse.
ZooKeeper può essere utilizzato da chiunque. Se l'azienda dispone di uno ZooKeeper esterno, è possibile utilizzarlo. In caso contrario, puoi installarlo dal nostro repository. C'è un programma di installazione che rende tutto più semplice.
E il diagramma di interazione dell'intero sistema risulta così. Abbiamo Kubernetes come piattaforma. Esegue l'operatore ClickHouse. Ho immaginato ZooKeeper qui. E l'operatore interagisce sia con ClickHouse che con ZooKeeper. Cioè, i risultati dell'interazione.
E tutto ciò è necessario affinché ClickHouse possa replicare con successo i dati in k8s.
Esaminiamo ora l'attività stessa e come apparirà il manifest per la replica.
Stiamo aggiungendo due sezioni al nostro manifest. Il primo è dove trovare ZooKeeper, che può essere interno o esterno a Kubernetes. Questa è solo una descrizione. E ordiniamo repliche. Quelli. vogliamo due repliche. In totale, dovremmo avere 4 pod in uscita. Ricordiamo lo stoccaggio, tornerà un po 'più tardi. Lo stoccaggio è una storia a parte.
Era così.
Diventa così. Vengono aggiunte le repliche. Il 4° non si adattava, crediamo che potrebbero essercene molti lì. E ZooKeeper viene aggiunto a lato. Gli schemi stanno diventando più complessi.
Ed è ora di aggiungere l'attività successiva. Aggiungeremo l'archiviazione persistente.
Per l'archiviazione persistente abbiamo varie opzioni.
Se utilizziamo un fornitore di servizi cloud, ad esempio utilizzando Amazon, Google, allora c'è una grande tentazione di utilizzare l'archiviazione nel cloud. È molto conveniente, è buono.
E c'è una seconda opzione. Questo è per l'archiviazione locale, quando abbiamo dischi locali su ciascun nodo. Questa opzione è molto più difficile da implementare, ma allo stesso tempo è più produttiva.
Vediamo cosa abbiamo riguardo al cloud storage.
Ci sono vantaggi. È molto facile da configurare. Ordiniamo semplicemente al fornitore cloud che ci fornisca spazio di archiviazione di tale e tale capacità, di tale e tale classe. Le lezioni sono programmate dai fornitori in modo indipendente.
E c'è uno svantaggio. Per alcuni, questo è uno svantaggio non critico. Naturalmente, ci saranno alcuni problemi di prestazioni. È molto comodo da usare e affidabile, ma presenta alcuni potenziali inconvenienti in termini di prestazioni.
E perché ClickHouse si concentra specificamente sulla produttività, si potrebbe addirittura dire che spreme tutto ciò che può, motivo per cui molti clienti cercano di ottenere la massima produttività.
E per trarne il massimo, abbiamo bisogno di spazio di archiviazione locale.
Kubernetes fornisce tre astrazioni per l'utilizzo dell'archiviazione locale in Kubernetes. Questo:
- DirVuota
- Percorso host.
- Locali
Diamo un'occhiata a come differiscono e come sono simili.
Innanzitutto, in tutti e tre gli approcci abbiamo spazio di archiviazione: si tratta di dischi locali che si trovano sullo stesso nodo fisico k8s. Ma hanno alcune differenze.
Cominciamo con quello più semplice, ovvero emptyDir. Di cosa si tratta in pratica? Nelle nostre specifiche, chiediamo al sistema di containerizzazione (molto spesso Docker) di fornirci l'accesso a una cartella sul disco locale.
In pratica, Docker crea una cartella temporanea da qualche parte lungo i propri percorsi e la chiama hash lungo. E fornisce un'interfaccia per accedervi.
Come funzionerà dal punto di vista delle prestazioni? Funzionerà alla velocità del disco locale, ad es. Questo è l'accesso completo alla tua vite.
Ma questo caso ha il suo svantaggio. Persistente è piuttosto dubbioso in questa materia. La prima volta che Docker si sposta con i contenitori, Persistent viene perso. Se Kubernetes desidera spostare questo pod su un altro disco per qualche motivo, i dati andranno persi.
Questo approccio è utile per i test, perché mostra già la velocità normale, ma per qualcosa di serio questa opzione non è adatta.
Esiste quindi un secondo approccio. Questo è hostPath. Se guardi la diapositiva precedente e questa, puoi vedere solo una differenza. La nostra cartella è stata spostata da Docker direttamente al nodo Kubernetes. Qui è un po' più semplice. Specifichiamo direttamente il percorso sul file system locale in cui vorremmo archiviare i nostri dati.
Questo metodo presenta dei vantaggi. Questo è già un vero Persistent, e per di più un classico. Avremo i dati registrati sul disco a qualche indirizzo.
Ci sono anche degli svantaggi. Questa è la complessità della gestione. I nostri Kubernetes potrebbero voler spostare il Pod su un altro nodo fisico. Ed è qui che entra in gioco DevOps. Deve spiegare correttamente all'intero sistema che questi pod possono essere spostati solo su quei nodi su cui è montato qualcosa lungo questi percorsi e non più di un nodo alla volta. È abbastanza difficile.
Soprattutto per questi scopi, abbiamo creato dei modelli nel nostro operatore per nascondere tutta questa complessità. E potresti semplicemente dire: "Voglio avere un'istanza di ClickHouse per ogni nodo fisico e lungo questo o quel percorso".
Ma non siamo gli unici ad aver bisogno di questa esigenza, quindi anche i signori di Kubernetes capiscono che le persone vogliono avere accesso ai dischi fisici, quindi forniscono un terzo livello.
Si chiama locale. Non c'è praticamente alcuna differenza rispetto alla diapositiva precedente. Solo prima era necessario confermare manualmente che non possiamo trasferire questi pod da un nodo all'altro, perché devono essere collegati lungo un percorso a un disco fisico locale, ma ora tutta questa conoscenza è incapsulata nello stesso Kubernetes. E risulta essere molto più semplice da configurare.
Torniamo al nostro problema pratico. Torniamo al modello YAML. Qui abbiamo un vero e proprio spazio di archiviazione. Ci siamo tornati. Impostiamo il classico modello VolumeClaim come in k8s. E descriviamo che tipo di spazio di archiviazione desideriamo.
Successivamente, K8 richiederà l'archiviazione. Ce lo assegnerà nello StatefulSet. E alla fine sarà a disposizione di ClickHouse.
Avevamo questo schema. Il nostro archivio persistente era rosso, il che sembrava suggerire che fosse necessario farlo.
E diventa verde. Ora lo schema del cluster ClickHouse su k8s è completamente finalizzato. Abbiamo frammenti, repliche, ZooKeeper, abbiamo un vero e proprio Persistente, che viene implementato in un modo o nell'altro. Il sistema è già pienamente operativo.
Continuiamo a vivere. Il nostro cluster si sta sviluppando. E Alexey ci prova e rilascia una nuova versione di ClickHouse.
Si presenta un compito pratico: testare la nuova versione di ClickHouse sul nostro cluster. E, naturalmente, non vuoi distribuire tutto; vuoi mettere una nuova versione in una replica da qualche parte nell'angolo più lontano, e magari non una nuova versione, ma due contemporaneamente, perché escono spesso.
Cosa possiamo dire a riguardo?
Qui abbiamo proprio questa opportunità. Questi sono modelli di pod. Puoi scrivere che il nostro operatore ti consente completamente di costruire un cluster eterogeneo. Quelli. configurare, iniziando da tutte le repliche in un gruppo, finendo con ciascuna replica personale, quale versione vogliamo di ClickHouse, quale versione vogliamo che venga archiviata. Possiamo configurare completamente il cluster con la configurazione di cui abbiamo bisogno.
Andiamo un po' più in profondità. Prima di questo, abbiamo parlato di come funziona l'operatore ClickHouse in relazione alle specificità di ClickHouse.
Ora vorrei spendere alcune parole su come funziona qualsiasi operatore in generale e su come interagisce con i K8.
Diamo prima un'occhiata all'interazione con i K8. Cosa succede quando applichiamo kubectl? I nostri oggetti appaiono in etcd tramite l'API.
Ad esempio, oggetti Kubernetes di base: pod, StatefulSet, servizio e così via nell'elenco.
Tuttavia, non sta ancora accadendo nulla di fisico. Questi oggetti devono essere materializzati in un cluster.
A questo scopo appare un controller. Il controller è un componente speciale di K8 che può materializzare queste descrizioni. Sa come e cosa fare fisicamente. Sa come eseguire i contenitori, cosa deve essere configurato lì affinché il server funzioni.
E materializza i nostri oggetti in K8.
Ma non vogliamo operare solo con pod e StatefulSet, vogliamo creare una ClickHouseInstallation, cioè un oggetto di tipo ClickHouse, per poter operare con esso come un tutto unico. Finora non esiste tale possibilità.
Ma il K8 ha la seguente cosa bella. Vogliamo avere un posto come questa entità complessa in cui il nostro cluster verrebbe assemblato da pod e StatefulSet.
E cosa è necessario fare per questo? Innanzitutto, entra in gioco la definizione delle risorse personalizzate. Cos'è? Questa è una descrizione per K8, che avrai un altro tipo di dati, che vogliamo aggiungere una risorsa personalizzata al pod, StatefulSet, che sarà complessa al suo interno. Questa è una descrizione della struttura dei dati.
Lo inviamo anche lì tramite kubectl apply. Kubernetes l'ha accettato con gioia.
E ora nel nostro archivio, l'oggetto in etcd ha l'opportunità di registrare una risorsa personalizzata chiamata ClickHouseInstallation.
Ma per ora non accadrà altro. Cioè, se ora creiamo il file YAML che abbiamo guardato descrivendo shard e repliche e diciamo "kubectl apply", allora Kubernetes lo accetterà, lo inserirà in etcd e dirà: "Ottimo, ma non so cosa fare con esso. Non so come mantenere ClickHouseInstallation."
Di conseguenza, abbiamo bisogno di qualcuno che aiuti Kubernetes a servire il nuovo tipo di dati. A sinistra abbiamo un controller Kubernetes nativo che funziona con tipi di dati nativi. E sulla destra dovremmo avere un controller personalizzato che possa funzionare con tipi di dati personalizzati.
E in un altro modo si chiama operatore. L'ho incluso qui specificatamente come Kubernetes, perché può essere eseguito anche all'esterno di K8. Molto spesso, ovviamente, tutti gli operatori vengono eseguiti in Kubernetes, ma nulla impedisce che rimangano all'esterno, quindi qui vengono spostati appositamente all'esterno.
E a sua volta, il controller personalizzato, noto anche come operatore, interagisce con Kubernetes tramite l'API. Sa già come interagire con l'API. E sa già come materializzare il complesso circuito che vogliamo realizzare a partire da una risorsa personalizzata. Questo è esattamente ciò che fa l'operatore.
Come funziona l'operatore? Diamo un'occhiata al lato destro per vedere come lo fa. Scopriamo come l'operatore materializza tutto questo e come avviene l'ulteriore interazione con i K8.
Un operatore è un programma. È orientata agli eventi. L'operatore si iscrive agli eventi utilizzando l'API Kubernetes. L'API Kubernetes dispone di punti di ingresso in cui puoi iscriverti agli eventi. E se qualcosa cambia in K8, Kubernetes invia eventi a tutti, ad es. chi è iscritto a questo API point riceverà le notifiche.
L'operatore si iscrive agli eventi e deve fare una sorta di reazione. Il suo compito è rispondere agli eventi emergenti.
Gli eventi vengono generati da determinati aggiornamenti. Arriva il nostro file YAML con la descrizione di ClickHouseInstallation. È andato su etcd tramite kubectl apply. Lì è stato attivato un evento e di conseguenza questo evento è arrivato all'operatore ClickHouse. L'operatore ha ricevuto questa descrizione. E deve fare qualcosa. Se è arrivato un aggiornamento per l'oggetto ClickHouseInstallation, è necessario aggiornare il cluster. E il compito dell’operatore è aggiornare il cluster.
Cosa sta facendo? Innanzitutto dobbiamo elaborare un piano d'azione per ciò che faremo con questo aggiornamento. Gli aggiornamenti possono essere molto piccoli, ad es. piccolo nell'esecuzione YAML, ma può comportare modifiche molto grandi sul cluster. Pertanto l'operatore crea un piano e poi lo rispetta.
Secondo questo piano, inizia a cucinare questa struttura all'interno per materializzare baccelli, servizi, ad es. fare quello che è il suo compito principale. Ecco come creare un cluster ClickHouse in Kubernetes.
Ora tocchiamo una cosa così interessante. Si tratta di una divisione di responsabilità tra Kubernetes e l'operatore, vale a dire cosa fa Kubernetes, cosa fa l'operatore e come interagiscono tra loro.
Kubernetes è responsabile delle cose di sistema, ad es. per un insieme base di oggetti che possono essere interpretati come ambito di sistema. Kubernetes sa come avviare i pod, come riavviare i contenitori, come montare i volumi, come lavorare con ConfigMap, ad es. tutto ciò che può essere chiamato sistema.
Gli operatori operano nei domini. Ogni operatore è realizzato per la propria area tematica. Lo abbiamo fatto per ClickHouse.
E l'operatore interagisce proprio in termini di argomento, ad esempio aggiungendo una replica, creando un diagramma, impostando il monitoraggio. Ciò si traduce in una divisione.
Diamo un'occhiata a un esempio pratico di come avviene questa divisione di responsabilità quando eseguiamo l'azione di aggiunta replica.
L'operatore riceve un compito: aggiungere una replica. Cosa fa l'operatore? L'operatore calcolerà che è necessario creare un nuovo StatefulSet, in cui devono essere descritti questi o quei modelli, dichiarazione di volume.
Ha preparato tutto e lo trasmette ai K8. Dice che ha bisogno di ConfigMap, StatefulSet, Volume. Kubernetes funziona. Materializza le unità di base con cui opera.
E poi entra di nuovo in gioco l'operatore ClickHouse. Ha già un pod fisico su cui può già fare qualcosa. E l'operatore ClickHouse funziona ancora in termini di dominio. Quelli. Nello specifico ClickHouse, per includere una replica in un cluster, è necessario innanzitutto configurare lo schema dei dati esistente in questo cluster. E, in secondo luogo, questa replica deve essere inclusa nel monitoraggio in modo che possa essere chiaramente rintracciata. L'operatore lo configura già.
E solo dopo entra in gioco ClickHouse stessa, ad es. un'altra entità di livello superiore. Questo è già un database. Ha la propria istanza, un'altra replica configurata pronta per unirsi al cluster.
Si scopre che la catena di esecuzione e divisione delle responsabilità quando si aggiunge una replica è piuttosto lunga.
Continuiamo i nostri compiti pratici. Se hai già un cluster, puoi migrare la configurazione.
Abbiamo fatto in modo che tu possa incollarlo direttamente nell'xml esistente, che ClickHouse capisce.
Puoi ottimizzare ClickHouse. Solo la distribuzione a zone è ciò di cui ho parlato quando ho spiegato hostPath, l'archiviazione locale. Ecco come eseguire correttamente la distribuzione a zone.
Il prossimo compito pratico è il monitoraggio.
Se il nostro cluster cambia, dobbiamo configurare periodicamente il monitoraggio.
Diamo un'occhiata al diagramma. Abbiamo già visto le frecce verdi qui. Ora diamo un'occhiata alle frecce rosse. Ecco come vogliamo monitorare il nostro cluster. Come le metriche del cluster ClickHouse entrano in Prometheus e poi in Grafana.
Qual è la difficoltà nel monitorare? Perché questo viene presentato come una sorta di risultato? La difficoltà sta nella dinamica. Quando abbiamo un cluster ed è statico, possiamo impostare il monitoraggio una volta e non preoccuparci più.
Ma se abbiamo molti cluster o qualcosa cambia costantemente, allora il processo è dinamico. E riconfigurare costantemente il monitoraggio è uno spreco di risorse e tempo, ad es. anche solo pigrizia. Questo deve essere automatizzato. La difficoltà sta nella dinamica del processo. E l'operatore lo automatizza molto bene.
Come si è sviluppato il nostro cluster? All'inizio era così.
Allora era così.
Alla fine è diventato così.
E il monitoraggio viene eseguito automaticamente dall'operatore. Unico punto di ingresso.
E proprio all'uscita guardiamo la dashboard di Grafana per vedere come ribolle la vita del nostro cluster al suo interno.
A proposito, la dashboard Grafana viene distribuita anche con il nostro operatore direttamente nel codice sorgente. È possibile connettersi e utilizzare. Il nostro DevOps mi ha fornito questo screenshot.
Dove vorremmo andare dopo? Questo:
- Sviluppare l'automazione dei test. Il compito principale è il test automatizzato delle nuove versioni.
- Vogliamo anche automatizzare davvero l'integrazione con ZooKeeper. E ci sono piani per l'integrazione con ZooKeeper-operator. Quelli. È stato scritto un operatore per ZooKeeper ed è logico che i due operatori inizino a integrarsi per costruire una soluzione più conveniente.
- Vogliamo eseguire segni vitali più complessi.
- Ho evidenziato in verde che ci stiamo avvicinando all'ereditarietà dei Templates - DONE, cioè con il prossimo rilascio dell'operatore avremo già l'ereditarietà dei templates. Questo è un potente strumento che ti consente di costruire configurazioni complesse partendo da pezzi.
- E vogliamo l’automazione di compiti complessi. Il principale è il re-sharding.
Prendiamo alcuni risultati intermedi.
Cosa otteniamo di conseguenza? E vale la pena farlo oppure no? È addirittura necessario provare a trascinare il database in Kubernetes e utilizzare l'operatore in generale e l'operatore Alitnity in particolare?
In uscita otteniamo:
- Semplificazione e automazione significative di configurazione, distribuzione e manutenzione.
- Monitoraggio immediatamente integrato.
- E modelli codificati pronti all'uso per situazioni complesse. Non è necessario eseguire manualmente un'azione come l'aggiunta di una replica. L'operatore fa questo.
Resta solo un'ultima domanda. Abbiamo già un database in Kubernetes, virtualizzazione. Che dire delle prestazioni di una soluzione del genere, soprattutto perché ClickHouse è ottimizzato per le prestazioni?
La risposta è che va tutto bene! Non entrerò nei dettagli: questo sarà l'argomento di una relazione separata.
Ma esiste un progetto come TSBS. Qual è il suo compito principale? Questo è un test delle prestazioni del database. Questo è un tentativo di confrontare caldo con caldo, morbido con morbido.
Come lavora? Viene generato un set di dati. Quindi questo insieme di dati viene eseguito su database diversi utilizzando lo stesso insieme di test. E ogni database risolve un problema nel modo in cui sa come. E poi puoi confrontare i risultati.
Supporta già un gran numero di database. Ne ho individuati tre principali. Questo:
- TimescaleDB.
- DB di afflusso.
- Fare clic su Casa.
È stato effettuato anche un confronto con un'altra soluzione simile. Confronto con RedShift. Il confronto è stato fatto su Amazon. ClickHouse è molto più avanti di tutti anche in questo ambito.
Che conclusioni si possono trarre da quanto ho detto?
- Il DB in Kubernetes è possibile. Probabilmente tutto è possibile, ma nel complesso sembra che sia possibile. ClickHouse in Kubernetes è sicuramente possibile con l'aiuto del nostro operatore.
- L'operatore aiuta ad automatizzare i processi e semplifica davvero la vita.
- Le prestazioni sono normali.
- E ci sembra che questo possa e debba essere utilizzato.
Open source: unisciti a noi!
Come ho già detto, l'operatore è un prodotto completamente open source, quindi sarebbe molto positivo se fosse utilizzato dal numero massimo di persone. Unisciti a noi! Vi aspettiamo tutti!
Grazie a tutti!
domande
Grazie per la segnalazione! Mi chiamo Anton. Vengo da SEMrush. Mi chiedo cosa succede con la registrazione. Si sente parlare di monitoraggio, ma nulla di logging, se parliamo dell'intero cluster. Ad esempio, abbiamo creato un cluster sull'hardware. E utilizziamo la registrazione centralizzata, raccogliendoli in un mucchio comune utilizzando mezzi standard. E poi da lì otteniamo i dati che ci interessano.
Bella domanda, ovvero accedere a un elenco di cose da fare. Il nostro operatore non lo automatizza ancora. È ancora in fase di sviluppo, il progetto è ancora piuttosto giovane. Comprendiamo la necessità della registrazione. Anche questo è un argomento molto importante. E probabilmente non è meno importante del monitoraggio. Ma il primo punto sulla lista da implementare era il monitoraggio. Ci sarà la registrazione. Naturalmente cerchiamo di automatizzare tutti gli aspetti della vita del cluster. Quindi la risposta è che al momento l'operatore purtroppo non sa come fare, ma è nei piani, lo faremo. Se vuoi unirti, esegui la richiesta, per favore.
Ciao! Grazie per la segnalazione! Ho una domanda standard relativa ai volumi persistenti. Quando creiamo una configurazione con questo operatore, in che modo l'operatore determina su quale nodo abbiamo collegato un particolare disco o cartella? Dobbiamo prima spiegargli che per favore posizioniamo la nostra ClickHouse su questi nodi che hanno un disco?
Per quanto ho capito, questa domanda è una continuazione dell'archiviazione locale, in particolare della sua parte hostPath. È come spiegare all'intero sistema che il pod deve essere lanciato su questo o quel nodo, al quale abbiamo un disco fisicamente connesso, che è montato lungo questo o quel percorso. Questa è un'intera sezione che ho toccato molto superficialmente perché la risposta è piuttosto ampia.
In breve assomiglia a questo. Naturalmente, dobbiamo fornire questi volumi. Al momento, non esiste una fornitura dinamica nello storage locale, quindi DevOps deve tagliare i dischi stessi, questi volumi. E devono spiegare al provisioning di Kubernetes che avrai volumi persistenti di questa e quella classe, che si trovano su questi e quei nodi. Quindi dovrai spiegare a Kubernetes che i pod che richiedono questa o quella classe di archiviazione locale devono essere indirizzati solo a questo o quel nodo utilizzando le etichette. Per questi scopi, l'operatore ha la possibilità di assegnare un qualche tipo di etichetta e una per istanza host. E si scopre che i pod verranno instradati da Kubernetes per essere eseguiti solo su nodi che soddisfano i requisiti, le etichette, in termini semplici. Gli amministratori assegnano etichette ed effettuano il provisioning dei dischi manualmente. E poi si ridimensiona.
Ed è la terza opzione, locale, che aiuta a rendere il tutto un po’ più semplice. Come ho già sottolineato, si tratta di un minuzioso lavoro di messa a punto, che alla fine aiuta a ottenere le massime prestazioni.
Ho una seconda domanda relativa a questo. Kubernetes è stato progettato in modo tale che non ci importi se perdiamo o meno un nodo. Cosa dovremmo fare in questo caso se abbiamo perso il nodo su cui pende il nostro frammento?
Sì, Kubernetes inizialmente era posizionato in modo che il nostro rapporto con i nostri pod fosse come il bestiame, ma qui con noi ogni disco diventa qualcosa come un animale domestico. Il problema è tale che non possiamo semplicemente buttarli via. E lo sviluppo di Kubernetes va nella direzione che è impossibile trattarlo completamente in modo filosofico, come se fosse una risorsa completamente scartata.
Ora una questione pratica. Cosa fare se hai perso il nodo su cui si trovava il disco? Qui il problema viene risolto a un livello più alto. Nel caso di ClickHouse abbiamo repliche che funzionano a un livello superiore, ovvero a livello ClickHouse.
Qual è la disposizione risultante? DevOps ha la responsabilità di garantire che i dati non vadano persi. Deve impostare correttamente la replica e assicurarsi che sia in esecuzione. La replica a livello ClickHouse deve contenere dati duplicati. Questo non è il problema che l'operatore risolve. E non il problema che Kubernetes stesso risolve. Questo è a livello ClickHouse.
Cosa fare se il tuo nodo di ferro cade? E si scopre che dovrai installarne un secondo, effettuare correttamente il provisioning del disco su di esso e applicare le etichette. Successivamente, soddisferà i requisiti affinché Kubernetes possa avviare un pod di istanza su di esso. Kubernetes lo avvierà. Il tuo numero di pod non è sufficiente per soddisfare il numero specificato. Attraverserà il ciclo che ho mostrato. E al livello più alto, ClickHouse capirà che siamo entrati in una replica, è ancora vuota e dobbiamo iniziare a trasferire i dati su di essa. Quelli. Questo processo non è ancora ben automatizzato.
Grazie per la segnalazione! Quando succedono tutti i tipi di cose brutte, l'operatore si blocca e si riavvia, e in quel momento arrivano gli eventi, riesci a gestire la cosa in qualche modo?
Cosa succede se l'operatore si blocca e si riavvia, giusto?
SÌ. E in quel momento arrivarono gli eventi.
Il compito di cosa fare in questo caso è in parte condiviso tra l'operatore e Kubernetes. Kubernetes ha la capacità di riprodurre un evento che si è verificato. Riproduce. E il compito dell’operatore è quello di assicurarsi che quando gli viene riprodotto il registro degli eventi, questi eventi siano idempotenti. E affinché il ripetersi dello stesso evento non rompa il nostro sistema. E il nostro operatore affronta questo compito.
Ciao! Grazie per la segnalazione! Dmitry Zavyalov, compagnia Smedova. È prevista l'aggiunta di opzioni di personalizzazione con haproxy all'operatore? Mi interesserebbe qualche altro bilanciatore oltre a quello standard, in modo che sia intelligente e capisca che ClickHouse esiste davvero.
Stai parlando di Ingress?
Sì, sostituisci Ingress con haproxy. In haproxy è possibile specificare la topologia del cluster in cui sono presenti le repliche.
Non ci abbiamo ancora pensato. Se ne hai bisogno e puoi spiegare perché è necessario, allora sarà possibile implementarlo, soprattutto se vuoi partecipare. Saremo lieti di valutare l'opzione. La risposta breve è no, al momento non disponiamo di tale funzionalità. Grazie per il suggerimento, esamineremo la questione. E se spieghi anche il caso d'uso e perché è necessario nella pratica, ad esempio, crei problemi su GitHub, allora sarà fantastico.
Già.
Bene. Siamo aperti a qualsiasi suggerimento. E haproxy viene inserito nella lista delle cose da fare. L'elenco delle cose da fare sta crescendo, non ancora diminuendo. Ma questo va bene, significa che il prodotto è richiesto.
Fonte: habr.com