Local<\/li>\n<\/ul>\n<\/p>\n
Esaminiamo come si differenziano e come sono simili. <\/p>\n
<\/p>\n
In primo luogo, in tutti e tre gli approcci abbiamo storage \u2013 dischi locali che si trovano sullo stesso nodo fisico di k8s. Ma ci sono alcune differenze.<\/p>\n
<\/p>\n
<\/p>\n
Iniziamo con la cosa pi\u00f9 semplice, ovvero con emptyDir. Cosa significa questo in pratica? Chiediamo al nostro specifica di richiedere al sistema di containerizzazione (solitamente \u2013 Docker) di fornirci accesso a una cartella sul disco locale.<\/p>\n
<\/p>\n
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. <\/p>\n
<\/p>\n
Come funzioner\u00e0 in termini di prestazioni? Funzioner\u00e0 alla velocit\u00e0 del disco locale, quindi c'\u00e8 accesso completo al proprio disco. <\/p>\n
<\/p>\n
Ma questa operazione ha il suo svantaggio. La persistenza in questo caso \u00e8 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. <\/p>\n
<\/p>\n
Questo approccio \u00e8 buono per i test, perch\u00e9 mostra gi\u00e0 una velocit\u00e0 normale, ma per qualcosa di serio questa opzione non \u00e8 adatta. <\/p>\n
<\/p>\n
<\/p>\n
Ecco perch\u00e9 c'\u00e8 un secondo approccio. Si tratta di hostPath. Se si guarda alla diapositiva precedente e a questa, si pu\u00f2 vedere solo una differenza. La nostra cartella \u00e8 uscita dal Docker direttamente sul nodo Kubernetes. Qui \u00e8 un po' pi\u00f9 semplice. Scriviamo direttamente il percorso nel file system locale, dove vogliamo conservare i nostri dati. <\/p>\n
<\/p>\n
Ci sono vantaggi in questo metodo. Questo \u00e8 un vero Persistent, e anche classico. I dati saranno salvati su disco a un certo indirizzo. <\/p>\n
<\/p>\n
Ci sono anche degli svantaggi. C'\u00e8 la complessit\u00e0 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\u00f9 di un nodo alla volta. \u00c8 abbastanza complicato. <\/p>\n
<\/p>\n
Appositamente per questi scopi, abbiamo creato dei modelli nel nostro operatore per nascondere tutta questa complessit\u00e0. E sarebbe possibile semplicemente dire: \u00abVoglio un'istanza di ClickHouse su ogni nodo fisico e su un certo percorso\u00bb. <\/p>\n
<\/p>\n
<\/p>\n
Ma questa necessit\u00e0 non \u00e8 solo nostra, quindi i gentiluomini di Kubernetes capiscono anche che le persone vogliono avere accesso ai dischi fisici, quindi offrono un terzo livello.<\/p>\n
<\/p>\n
Si chiama local. Non c'\u00e8 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\u00e9 dovevano essere collegati a un certo percorso sul disco fisico locale, mentre ora tutta questa conoscenza \u00e8 incapsulata all'interno di Kubernetes stesso. Risulta molto pi\u00f9 semplice configurare.<\/p>\n
<\/p>\n
<\/p>\n
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.<\/p>\n
<\/p>\n
Dopo di che k8s richieder\u00e0 lo storage. Ce lo assegner\u00e0 nel StatefulSet. E alla fine diventer\u00e0 di pertinenza di ClickHouse.<\/p>\n
<\/p>\n
<\/p>\n
Avevamo uno schema del genere. Il nostro Persistent Storage era rosso, il che suggeriva che doveva essere realizzato. <\/p>\n
<\/p>\n
<\/p>\n
E diventa verde. Ora lo schema del cluster ClickHouse su k8s \u00e8 completamente finalizzato. Abbiamo shard, repliche, ZooKeeper, e c'\u00e8 un vero Persistent, che \u00e8 implementato in un modo o nell'altro. Lo schema \u00e8 gi\u00e0 completamente funzionante. <\/p>\n
<\/p>\n
<\/p>\n
Continuiamo a vivere. Il nostro cluster si sta sviluppando. E Alexey sta cercando di fare del suo meglio, rilasciando una nuova versione di ClickHouse.<\/p>\n
<\/p>\n
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\u00e9 escono piuttosto spesso. <\/p>\n
<\/p>\n
Cosa possiamo dire al riguardo?<\/p>\n
<\/p>\n
<\/p>\n
Abbiamo precisamente questa opportunit\u00e0. Sono i template dei pod. Possiamo scrivere, il nostro operatore consente completamente di costruire un cluster eterogeneo. Cio\u00e8, 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. <\/p>\n
<\/p>\n
<\/p>\n
Ci addentriamo un po' di pi\u00f9. Prima abbiamo parlato di come funziona ClickHouse-operator in relazione alle specificit\u00e0 di ClickHouse.<\/p>\n
<\/p>\n
Ora vorrei dire qualche parola su come funziona in generale qualsiasi operatore, e su come interagisce con K8s.<\/p>\n
<\/p>\n
<\/p>\n
Iniziamo con l'interazione con K8s. Cosa succede quando facciamo kubectl apply? I nostri oggetti appaiono in etcd tramite l'API. <\/p>\n
<\/p>\n
<\/p>\n
Per esempio, gli oggetti di base di Kubernetes: pod, StatefulSet, servizio e cos\u00ec via. <\/p>\n
<\/p>\n
In questo momento, nulla di fisico accade ancora. Questi oggetti devono essere materializzati nel cluster. <\/p>\n
<\/p>\n
<\/p>\n
Per farlo, appare un controller. Il controller \u00e8 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\u00e9 il server funzioni. <\/p>\n
<\/p>\n
<\/p>\n
E materializza i nostri oggetti in K8s.<\/p>\n
<\/p>\n
Ma vogliamo operare non solo con i pod e con gli StatefulSet, vogliamo creare ClickHouseInstallation, cio\u00e8 un oggetto di tipo ClickHouse, per operarlo come un'unit\u00e0 unica. Al momento, non c'\u00e8 tale possibilit\u00e0. <\/p>\n
<\/p>\n
<\/p>\n
Ma K8s ha una cosa piacevole. Vogliamo che appaia da qualche parte un'entit\u00e0 complessa come questa, in cui il nostro cluster sia raccolto da pod e StatefulSet. <\/p>\n
<\/p>\n
<\/p>\n
E cosa bisogna fare per questo? Innanzitutto, entra in gioco la Custom Resource Definition. Che cos'\u00e8? \u00c8 una descrizione per K8s, che indica che avrai un altro tipo di dato, che vogliamo aggiungere come risorsa personalizzata all'interno di pod, StatefulSet. \u00c8 una descrizione della struttura dei dati. <\/p>\n
<\/p>\n
<\/p>\n
Lo inviamo anche l\u00ec tramite kubectl apply. Kubernetes lo ha accolto con gioia. <\/p>\n
<\/p>\n
E ora nel nostro storage, l'oggetto in etcd ha la possibilit\u00e0 di registrare una risorsa personalizzata chiamata ClickHouseInstallation.<\/p>\n
<\/p>\n
Ma finora non succeder\u00e0 altro. Cio\u00e8, se ora creiamo un file YAML, che abbiamo esaminato, con la descrizione di shard, repliche e diciamo \"kubectl apply\", Kubernetes lo accetter\u00e0, lo metter\u00e0 in etcd e dir\u00e0: \"Ottimo, ma non so cosa farci. Come gestire ClickHouseInstallation non lo so.\" <\/p>\n
<\/p>\n
<\/p>\n
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. <\/p>\n
<\/p>\n
E con un nome diverso \u00e8 chiamato operatore. L'ho portato qui appositamente fuori da Kubernetes, perch\u00e9 pu\u00f2 essere eseguito anche esternamente a K8s. Di solito, tutti gli operatori vengono eseguiti in Kubernetes, ma nulla impedisce loro di operare esternamente; perci\u00f2 qui \u00e8 stato scelto di posizionarlo all'esterno. <\/p>\n
<\/p>\n
<\/p>\n
E il controller personalizzato, cio\u00e8 l'operatore, interagisce con Kubernetes tramite l'API. Sa gi\u00e0 come interagire con l'API. E sa gi\u00e0 come materializzare una complessa architettura a partire dalla risorsa personalizzata che vogliamo creare. Questo \u00e8 precisamente ci\u00f2 di cui si occupa l'operatore. <\/p>\n
<\/p>\n
<\/p>\n
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.<\/p>\n
<\/p>\n
<\/p>\n
L'operatore \u00e8 un programma. \u00c8 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\u00f2 iscrivere agli eventi. E se qualcosa cambia in K8s, Kubernetes invia eventi a tutti coloro che lo desiderano, cio\u00e8 chi si \u00e8 iscritto a questo punto API ricever\u00e0 notifiche.<\/p>\n
<\/p>\n
L'operatore si iscrive agli eventi e deve fare qualche reazione. Il suo compito \u00e8 reagire agli eventi che si presentano. <\/p>\n
<\/p>\n
<\/p>\n
Gli eventi vengono generati da alcuni aggiornamenti. Arriva il nostro file YAML con la descrizione di ClickHouseInstallation. \u00c8 passato attraverso kubectl apply in etcd. L\u00ec si \u00e8 attivato un evento, e alla fine questo evento \u00e8 arrivato al ClickHouse-operator. L'operatore ha ricevuto questa descrizione. E deve fare qualcosa. Se \u00e8 arrivato un aggiornamento per l'oggetto ClickHouseInstallation, allora bisogna aggiornare il cluster. E il compito dell'operatore \u00e8 aggiornare il cluster. <\/p>\n
<\/p>\n
<\/p>\n
Cosa fa? Innanzitutto, deve pianificare le azioni, cio\u00e8 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\u00f2 l'operatore crea un piano e poi lo segue.<\/p>\n
<\/p>\n
<\/p>\n
Inizia a elaborare questa struttura secondo il piano, per materializzare i pod, i servizi, cio\u00e8 fare ci\u00f2 che \u00e8 il suo compito principale. \u00c8 come costruire un cluster ClickHouse in Kubernetes.<\/p>\n
<\/p>\n
<\/p>\n
Ora parliamo di una cosa interessante. Questa \u00e8 la divisione delle responsabilit\u00e0 tra Kubernetes e l'operatore, cio\u00e8 cosa fa Kubernetes, cosa fa l'operatore e come interagiscono tra loro. <\/p>\n
<\/p>\n
Kubernetes si occupa di questioni sistemiche, cio\u00e8 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\u00e8 tutto ci\u00f2 che si pu\u00f2 definire sistema. <\/p>\n
<\/p>\n
Gli operatori operano in aree tematiche. Ogni operatore \u00e8 creato per la propria area di competenza. Noi abbiamo creato quello per ClickHouse.<\/p>\n
<\/p>\n
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.<\/p>\n
<\/p>\n
<\/p>\n
Esaminiamo un esempio pratico di come avviene questa divisione di responsabilit\u00e0 quando compiamo l'azione di aggiungere una replica. <\/p>\n
<\/p>\n
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. <\/p>\n
<\/p>\n
<\/p>\n
Ha preparato tutto questo e lo passa successivamente a K8s. Dice che ha bisogno di ConfigMap, StatefulSet, Volume. Kubernetes elabora. Materializza le unit\u00e0 di base con cui opera. <\/p>\n
<\/p>\n
<\/p>\n
E poi interviene di nuovo ClickHouse-operator. Ha gi\u00e0 a disposizione un pod fisico, su cui \u00e8 possibile lavorare. E ClickHouse-operator opera nuovamente in termini di dominio. Cio\u00e8, 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\u00e9 possa essere seguita correttamente. Gi\u00e0 l'operatore si occupa di questa configurazione. <\/p>\n
<\/p>\n
<\/p>\n
E solo dopo questo entra in gioco ClickHouse stesso, cio\u00e8 un'entit\u00e0 di livello superiore. Questo \u00e8 gi\u00e0 un database. Ha il suo instance, una replica configurata, pronta per unirsi al cluster.<\/p>\n
<\/p>\n
Si ottiene cos\u00ec una catena di esecuzione e divisione delle responsabilit\u00e0 per l'aggiunta di una replica piuttosto lunga.<\/p>\n
<\/p>\n
<\/p>\n
Procediamo con le nostre attivit\u00e0 pratiche. Se il cluster esiste gi\u00e0, si pu\u00f2 effettuare la migrazione della configurazione. <\/p>\n
<\/p>\n
<\/p>\n
Abbiamo fatto in modo che nel file xml esistente, che ClickHouse comprende, si possa trasmettere senza problemi.<\/p>\n
<\/p>\n
<\/p>\n
\u00c8 possibile effettuare un'assistenza fine di ClickHouse. Infatti, il zoned deployment \u00e8 ci\u00f2 di cui ho parlato durante la spiegazione di hostPath e local storage. \u00c8 il modo corretto per effettuare un zoned deployment.<\/p>\n
<\/p>\n
<\/p>\n
Il prossimo compito pratico riguarda il monitoraggio.<\/p>\n
<\/p>\n
<\/p>\n
Se il nostro cluster cambia, \u00e8 necessario configurare periodicamente il monitoraggio. <\/p>\n
<\/p>\n
Esaminiamo lo schema. Abbiamo gi\u00e0 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.<\/p>\n
<\/p>\n
<\/p>\n
Qual \u00e8 la complessit\u00e0 del monitoraggio? Perch\u00e9 \u00e8 considerato un risultato? La complessit\u00e0 riguarda proprio la dinamica. Quando abbiamo un cluster statico, \u00e8 possibile configurare il monitoraggio una volta e non pensarci pi\u00f9.<\/p>\n
<\/p>\n
Ma se abbiamo molti cluster, o se c'\u00e8 un costante cambiamento, il processo \u00e8 dinamico. E occuparsi continuamente di ripristinare il monitoraggio \u00e8 una perdita di risorse e tempo, cio\u00e8 anche semplicemente pigrizia. \u00c8 necessario automatizzare tutto questo. La complessit\u00e0 sta proprio nella dinamica del processo. E l'operatore automatizza tutto questo molto bene. <\/p>\n
<\/p>\n
<\/p>\n
Come \u00e8 evoluto il nostro cluster? All'inizio era cos\u00ec.<\/p>\n
<\/p>\n
<\/p>\n
Poi \u00e8 diventato cos\u00ec.<\/p>\n
<\/p>\n
<\/p>\n
Alla fine \u00e8 diventato cos\u00ec. <\/p>\n
<\/p>\n
E il monitoraggio viene eseguito automaticamente dall'operatore. Punto di ingresso unico. <\/p>\n
<\/p>\n
<\/p>\n
E noi guardiamo semplicemente, in uscita, nel dashboard di Grafana, come vive il nostro cluster. <\/p>\n
<\/p>\n
A proposito, il dashboard di Grafana \u00e8 distribuito insieme al nostro operatore direttamente nel codice sorgente. Puoi collegarlo e utilizzarlo. Questa \u00e8 uno screenshot fornito dai nostri DevOps.<\/p>\n
<\/p>\n
<\/p>\n
Dove vorremmo andare avanti? Questo \u00e8:<\/p>\n
<\/p>\n
\nSviluppare l'automazione dei test. L'obiettivo principale \u00e8 il test automatizzato delle nuove versioni. <\/li>\n Inoltre, desideriamo molto automatizzare l'integrazione con ZooKeeper. E nei piani c'\u00e8 l'integrazione con ZooKeeper-operator. Cio\u00e8, per ZooKeeper \u00e8 stato scritto un operatore e ha senso che due operatori comincino a integrarsi per costruire una soluzione pi\u00f9 comoda. <\/li>\n Vogliamo fare controlli di vitalit\u00e0 pi\u00f9 complessi. <\/li>\n In verde ho evidenziato ci\u00f2 che abbiamo in arrivo, l'ereditariet\u00e0 dei Templates \u2013 FATTO, cio\u00e8 con il prossimo rilascio dell'operatore avremo gi\u00e0 l'ereditariet\u00e0 dei modelli. Questo \u00e8 uno strumento potente che permette di costruire configurazioni complesse a pezzi. <\/li>\n E vogliamo automatizzare compiti complessi. Il principale di questi \u00e8 il Re-sharding. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Facciamo un bilancio intermedio. <\/p>\n
<\/p>\n
<\/p>\n
Cosa otteniamo in uscita? Vale la pena dedicarcisi o no? \u00c8 necessario provare a portare il database in Kubernetes e applicare l'operatore in generale e l'operatore Alitnity in particolare.<\/p>\n
<\/p>\n
In uscita otteniamo:<\/p>\n
<\/p>\n
\nUn notevole semplificazione e automazione della configurazione, del dispiego e anche della manutenzione. <\/li>\n Monitoraggio integrato immediato. <\/li>\n E modelli codificati gi\u00e0 pronti per situazioni complesse. Non \u00e8 pi\u00f9 necessario aggiungere una replica manualmente. Questo lo fa l'operatore. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Rimane solo l'ultima domanda. Abbiamo gi\u00e0 un database in Kubernetes, virtualizzazione. Qual \u00e8 la prestazione di questa soluzione, specialmente considerando che ClickHouse \u00e8 ottimizzato per le prestazioni?<\/p>\n
<\/p>\n
La risposta \u00e8 \u2013 tutto bene! Non entrer\u00f2 nei dettagli, \u00e8 un tema di una presentazione separata. <\/p>\n
<\/p>\n
<\/p>\n
Ma c'\u00e8 un progetto chiamato TSBS. Qual \u00e8 il suo obiettivo principale? \u00c8 un test di database per le prestazioni. \u00c8 un tentativo di confrontare il simile con il simile, il morbido con il morbido. <\/p>\n
<\/p>\n
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\u00f2. E poi i risultati possono essere confrontati. <\/p>\n
<\/p>\n
Supporta gi\u00e0 un gran numero di database. Ne ho evidenziati tre principali. Sono:<\/p>\n
<\/p>\n
\nTimescaleDB.<\/li>\n InfluxDB.<\/li>\n ClickHouse.<\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
\u00c8 stata inoltre effettuata un'analisi rispetto a un'altra soluzione simile. \u00c8 stato un confronto con RedShift. Il confronto \u00e8 stato effettuato su Amazon. ClickHouse supera anche in questo caso tutti gli altri. <\/p>\n
<\/p>\n
<\/p>\n
Quali conclusioni possiamo trarre da quanto ho raccontato?<\/p>\n
<\/p>\n
\nDB su Kubernetes \u00e8 possibile. Probabilmente qualsiasi DB \u00e8 utilizzabile, ma in generale sembra fattibile. ClickHouse su Kubernetes \u00e8 sicuramente utilizzabile con il nostro operatore. <\/li>\n L'operatore aiuta ad automatizzare i processi e semplifica realmente la vita.<\/li>\n Le prestazioni sono normali.<\/li>\n E ci sembra che questo possa e debba essere utilizzato. <\/li>\n<\/ul>\n<\/p>\n
Open source \u2013 unitevi!<\/p>\n
<\/p>\n
Come ho gi\u00e0 detto, l'operatore \u00e8 un prodotto completamente open source, quindi sarebbe davvero bello se il maggior numero possibile di persone lo utilizzasse. Unitevi a noi! Vi aspettiamo tutti!<\/p>\n
<\/p>\n
Grazie a tutti!<\/p>\n
<\/p>\n
Domande<\/p>\n
<\/p>\n
<\/p>\n
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\u00ec.<\/em> <\/p>\n<\/p>\n
Buona domanda, ossia il logging \u00e8 nella lista delle cose da fare. Il nostro operatore attualmente non lo automatizza. \u00c8 ancora in fase di sviluppo, il progetto \u00e8 ancora abbastanza giovane. Comprendiamo l'importanza del logging. \u00c8 un tema molto rilevante e probabilmente altrettanto importante quanto il monitoraggio. Ma il primo della lista per l'implementazione \u00e8 stato il monitoraggio. Il logging ci sar\u00e0. Naturalmente, ci sforziamo di automatizzare tutti gli aspetti della vita del cluster. Quindi, la risposta \u00e8: al momento l'operatore, sfortunatamente, non lo sa fare, ma \u00e8 nei nostri piani, lo faremo. Se desiderate unirvi, un pull request, per favore.<\/p>\n
<\/p>\n
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'\u00e8 un disco?<\/em><\/p>\n<\/p>\n
Per quanto ne so, questa domanda \u00e8 un'estensione dello storage locale, in particolare della sua parte riguardante il hostPath. \u00c8 come spiegare all'intero sistema che \u00e8 necessario far partire un pod su un nodo specifico, su cui abbiamo un disco fisicamente connesso, montato in un determinato percorso. \u00c8 un'intera sezione che ho toccato in modo molto superficiale, perch\u00e9 la risposta \u00e8 piuttosto ampia. <\/p>\n
<\/p>\n
In breve, si presenta cos\u00ec. Dobbiamo ovviamente fare il provisioning di questi volumi. Al momento, nel local storage non c'\u00e8 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\u00e0 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\u00e0 di assegnare alcune etichette e una per ogni istanza host. Cos\u00ec 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.<\/p>\n
<\/p>\n
E proprio la terza opzione locale aiuta un po' a semplificare la situazione. Come ho gi\u00e0 sottolineato, si tratta di un lavoro meticoloso di configurazione, che alla fine aiuta a ottenere massime prestazioni.<\/p>\n
<\/p>\n
Ho una seconda domanda correlata a questo. Kubernetes \u00e8 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?<\/em><\/p>\n<\/p>\n
S\u00ec, Kubernetes \u00e8 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 \u00e8 possibile considerare tutto filosoficamente come risorse completamente eliminabili.<\/p>\n
<\/p>\n
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\u00e8 a livello di ClickHouse.<\/p>\n
<\/p>\n
Qual \u00e8 la disposizione risultante? DevOps \u00e8 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 \u00e8 un'operazione che svolge l'operatore, n\u00e9 \u00e8 un compito che deve gestire Kubernetes. \u00c8 a livello di ClickHouse.<\/p>\n
<\/p>\n
Cosa fare se il nodo hardware si guasta? In questo caso, sar\u00e0 necessario installarne un secondo, configurare correttamente il disco e applicare le etichette. Dopo di che, dovr\u00e0 soddisfare i requisiti affinch\u00e9 Kubernetes possa avviare un'istanza del pod. Kubernetes lo avvier\u00e0. Non hai abbastanza pod rispetto a quanto richiesto. Essa passer\u00e0 attraverso un ciclo, come ho mostrato. E al livello pi\u00f9 alto, ClickHouse capir\u00e0 che \u00e8 stata aggiunta una replica, \u00e8 ancora vuota e bisogna iniziare a trasferirvi i dati. Cio\u00e8, questo processo \u00e8 ancora poco automatizzato. <\/p>\n
<\/p>\n
Grazie per la presentazione! Quando si verificano problemi e l'operatore si arresta e si riavvia, nel frattempo arrivano eventi, come gestisci la situazione?<\/em><\/p>\n<\/p>\n
Cosa succede se l'operatore si arresta e si riavvia? <\/p>\n
<\/p>\n
Esatto. E in quel momento sono arrivati eventi.<\/em> <\/p>\n<\/p>\n
Il compito di cosa fare in questo caso \u00e8 parzialmente suddiviso tra l'operatore e Kubernetes. Kubernetes ha la possibilit\u00e0 di riprodurre l'evento che \u00e8 accaduto. Lo riproduce. Il compito dell'operatore \u00e8 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. <\/p>\n
<\/p>\n
Buongiorno! Grazie per la presentazione! Dmitry Zavyalov, azienda<\/em> Smedova. \u00c8 prevista l'aggiunta all'operatore della possibilit\u00e0 di configurazione con haproxy? Sarei interessato a un altro bilanciatore oltre a quello standard, che sia intelligente e capisca che si tratta di ClickHouse.<\/em> <\/p>\n<\/p>\n
Stai parlando di Ingress?<\/p>\n
<\/p>\n
S\u00ec, sostituire Ingress con haproxy. In haproxy \u00e8 possibile specificare la topologia del cluster, dove ha le repliche.<\/em><\/p>\n<\/p>\n
Per ora non ci abbiamo pensato. Se avete bisogno di questo e potete spiegare perch\u00e9 sia necessario, possiamo implementarlo, soprattutto se volete partecipare. Siamo felici di considerare questa opzione. La risposta breve \u00e8: no, al momento non abbiamo questa funzionalit\u00e0. Grazie per il suggerimento, ci daremo un'occhiata. E se poteste anche spiegare il caso d'uso e perch\u00e9 sia utile nella pratica, per esempio creando issue su GitHub, sarebbe fantastico.<\/p>\n
<\/p>\n
C'\u00e8 gi\u00e0.<\/em><\/p>\n<\/p>\n
Va bene. Siamo aperti a qualsiasi proposta. E haproxy \u00e8 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 \u00e8 richiesto.<\/p>\n
Fonte: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0414\u043e\u043a\u043b\u0430\u0434 \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u043c \u0432\u043e\u043f\u0440\u043e\u0441\u0430\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440\u0430 \u0432 Kubernetes, \u043f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044e \u0435\u0433\u043e \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b \u0438 \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u0445 \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u043e\u0432 \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f. \u0412 \u043f\u0435\u0440\u0432\u043e\u0439 \u0447\u0430\u0441\u0442\u0438 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c: \u0447\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u0432 Kubernetes \u0438 \u0437\u0430\u0447\u0435\u043c \u043e\u043d \u043d\u0443\u0436\u0435\u043d; \u043a\u0430\u043a \u0438\u043c\u0435\u043d\u043d\u043e \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u0443\u043f\u0440\u043e\u0449\u0430\u0435\u0442 \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0435 \u0441\u043b\u043e\u0436\u043d\u044b\u043c\u0438 \u0441\u0438\u0441\u0442\u0435\u043c\u0430\u043c\u0438; \u0447\u0442\u043e \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u043c\u043e\u0436\u0435\u0442, \u0430 \u0447\u0442\u043e \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u043d\u0435 \u043c\u043e\u0436\u0435\u0442. \u0414\u0430\u043b\u0435\u0435, \u043f\u0435\u0440\u0435\u0439\u0434\u0451\u043c \u043a \u043e\u0431\u0441\u0443\u0436\u0434\u0435\u043d\u0438\u044e \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0433\u043e \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432\u0430 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440\u0430. \u0420\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0443 \u0438 \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":96966,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-96965","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Operatore](\"\/wp-content\/uploads\/2020\/10\/56e002c7408c4708e39ece867f84171e.jpeg\")
<\/p>\n