Locale<\/li>\n<\/ul>\n<\/p>\n
Esaminiamo in che modo si differenziano e in cosa sono simili. <\/p>\n
<\/p>\n
Innanzitutto, in tutti e tre gli approcci, lo storage si basa su dischi locali che si trovano sulla stessa nodo fisica di k8s. Tuttavia, ci sono alcune differenze.<\/p>\n
<\/p>\n
<\/p>\n
Iniziamo con il pi\u00f9 semplice, ovvero emptyDir. Di cosa si tratta nella pratica? In sostanza, chiediamo al nostro specifica al sistema di containerizzazione (che pi\u00f9 spesso \u00e8 Docker) di fornirci accesso a una cartella sul disco locale.<\/p>\n
<\/p>\n
In pratica, Docker crea una cartella temporanea da qualche parte, assegnandole un lungo hash come nome. E fornisce un'interfaccia per accedervi. <\/p>\n
<\/p>\n
Come funzioner\u00e0 in termini di prestazioni? Funzioner\u00e0 alla velocit\u00e0 del disco locale, quindi si tratta di un accesso completo al proprio hardware. <\/p>\n
<\/p>\n
Tuttavia, questa modalit\u00e0 presenta uno svantaggio. Persistent \u00e8 piuttosto discutibile in questo caso. Alla prima azione del docker con i container, Persistent si perde. Se a Kubernetes venisse in mente di spostare questo Pod su un altro disco per qualche motivo, i dati andrebbero perduti. <\/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 soluzione non \u00e8 adatta. <\/p>\n
<\/p>\n
<\/p>\n
Ecco quindi un secondo approccio. Si tratta di hostPath. Se guardiamo il diapositiva precedente e questa, possiamo notare una sola differenza. La nostra cartella \u00e8 uscita dal docker direttamente sulla nodi Kubernetes. \u00c8 un po' pi\u00f9 semplice. Scriviamo direttamente il percorso nel file system locale, dove vorremmo memorizzare i nostri dati. <\/p>\n
<\/p>\n
Questo metodo ha i suoi vantaggi. \u00c8 gi\u00e0 un vero Persistent, e per di pi\u00f9 classico. I dati saranno registrati su disco in un certo indirizzo. <\/p>\n
<\/p>\n
Ci sono anche degli svantaggi. La complessit\u00e0 nella gestione \u00e8 uno di essi. Il nostro Kubernetes potrebbe decidere di spostare un Pod su un'altra nodo fisica. Qui entra in gioco il DevOps. Deve spiegare correttamente all'intero sistema che questi pod possono essere spostati solo su nodi in cui hai qualcosa montato lungo quei percorsi, e non pi\u00f9 di un nodo alla volta. \u00c8 piuttosto complesso. <\/p>\n
<\/p>\n
Proprio per questi scopi, noi come operatori abbiamo creato dei modelli per nascondere tutta questa complessit\u00e0. Cos\u00ec si potrebbe semplicemente dire: \u00abVoglio avere un'istanza di ClickHouse su ogni nodo fisico e su un determinato percorso\u00bb. <\/p>\n
<\/p>\n
<\/p>\n
Ma questa necessit\u00e0 non \u00e8 solo nostra, quindi i gentiluomini di Kubernetes capiscono anche che gli utenti vogliono avere accesso ai dischi fisici, e per questo forniscono un terzo livello.<\/p>\n
<\/p>\n
Si chiama local. Le differenze rispetto alla diapositiva precedente sono praticamente nulle. Prima era necessario gestire manualmente il trasferimento dei pod da un nodo all'altro, poich\u00e9 dovevano essere collegati in un percorso specifico a un disco fisico locale, mentre ora tutte queste conoscenze sono incorporate in Kubernetes stesso. Risulta quindi molto pi\u00f9 semplice configurare.<\/p>\n
<\/p>\n
<\/p>\n
Torniamo al nostro compito pratico. Torniamo al template YAML. Qui abbiamo un vero storage. Siamo tornati su questo. Stiamo impostando un template di VolumeClaim classico come in k8s. E descriviamo quale storage vogliamo.<\/p>\n
<\/p>\n
Dopo di ci\u00f2, k8s richieder\u00e0 storage. Ce ne fornir\u00e0 uno in StatefulSet. E alla fine questo sar\u00e0 a disposizione di ClickHouse.<\/p>\n
<\/p>\n
<\/p>\n
Avevamo questo schema. Il nostro Persistent Storage era rosso, il che lasciava intendere che dovesse essere reso. <\/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 un vero Persistent, realizzato in un modo o nell'altro. Lo schema \u00e8 gi\u00e0 completamente funzionante. <\/p>\n
<\/p>\n
<\/p>\n
Continuiamo a progredire. Il nostro cluster si evolve. E Alexey si impegna e rilascia una nuova versione di ClickHouse.<\/p>\n
<\/p>\n
Si presenta un compito pratico: testare la nuova versione di ClickHouse sul nostro cluster. Naturalmente, non vogliamo aggiornare tutto, ma preferiremmo installare la nuova versione in un angolo remoto, e magari anche non solo una nuova versione, ma ben due, visto che escono frequentemente. <\/p>\n
<\/p>\n
Cosa possiamo dire al riguardo?<\/p>\n
<\/p>\n
<\/p>\n
Abbiamo proprio questa opportunit\u00e0. Ci sono dei modelli di pod. Possiamo elaborare la configurazione poich\u00e9 il nostro operatore consente di costruire un cluster eterogeneo. Cio\u00e8, possiamo configurarlo a partire da tutte le repliche insieme, fino a ogni singola replica specificando quale versione di ClickHouse vogliamo e quale versione di storage desideriamo. Possiamo configurare completamente il cluster secondo le nostre necessit\u00e0. <\/p>\n
<\/p>\n
<\/p>\n
Adesso ci addentriamo un po' di pi\u00f9. Prima abbiamo parlato di come funziona ClickHouse-Operator in relazione alle specifiche di ClickHouse.<\/p>\n
<\/p>\n
Ora vorrei dire alcune parole su come funziona generalmente qualsiasi operatore, e su come interagisce con K8s.<\/p>\n
<\/p>\n
<\/p>\n
Iniziamo esaminando l'interazione con K8s. Cosa succede quando eseguiamo kubectl apply? I nostri oggetti appaiono in etcd tramite l'API. <\/p>\n
<\/p>\n
<\/p>\n
Ad esempio, i componenti di base di Kubernetes: pod, StatefulSet, servizio e cos\u00ec via. <\/p>\n
<\/p>\n
Tuttavia, non sta ancora accadendo nulla di fisico. Questi oggetti devono essere materializzati nel cluster. <\/p>\n
<\/p>\n
<\/p>\n
A questo serve il controller. Il controller \u00e8 un componente speciale di k8s che sa come materializzare queste descrizioni. Sa come fare fisicamente e 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 non vogliamo operare solo con pod e StatefulSet, vogliamo creare un ClickHouseInstallation, cio\u00e8 un oggetto di tipo ClickHouse, per operarlo come un'unica entit\u00e0. Al momento, questa possibilit\u00e0 non esiste. <\/p>\n
<\/p>\n
<\/p>\n
Ma K8s ha una cosa piacevole. Vogliamo che emerga un'entit\u00e0 complessa da qualche parte, che integri pod e StatefulSet nel nostro cluster. <\/p>\n
<\/p>\n
<\/p>\n
E cosa bisogna fare per questo? Innanzitutto, entra in scena la Custom Resource Definition. Cos'\u00e8? \u00c8 una descrizione per K8s, che stabilisce che avremo un ulteriore tipo di dati, e che vogliamo aggiungere una risorsa personalizzata che sar\u00e0 complessa all'interno di pod e StatefulSet. Questa \u00e8 la descrizione della struttura dei dati. <\/p>\n
<\/p>\n
<\/p>\n
Lo inviamo anche noi tramite kubectl apply. Kubernetes lo ha accolto con gioia. <\/p>\n
<\/p>\n
E ora nella nostra archiviazione, l'oggetto in etcd ha la possibilit\u00e0 di registrare una risorsa personalizzata chiamata ClickHouseInstallation.<\/p>\n
<\/p>\n
Ma fino ad ora non succeder\u00e0 niente di pi\u00f9. Cio\u00e8, se adesso creiamo un file YAML, come abbiamo visto, descrivendo shard, repliche e diciamo 'kubectl apply', Kubernetes lo accetter\u00e0, lo metter\u00e0 in etcd e dir\u00e0: 'Ottimo, ma non so cosa farne. Non so come gestire ClickHouseInstallation'. <\/p>\n
<\/p>\n
<\/p>\n
Pertanto, abbiamo bisogno di qualcuno che aiuti Kubernetes a gestire un nuovo tipo di dati. A sinistra abbiamo un controller Kubernetes predefinito che lavora con i tipi di dati standard. E a destra deve comparire un controller personalizzato che sa lavorare con i tipi di dati personalizzati. <\/p>\n
<\/p>\n
E in un altro modo si chiama operatore. L'ho messo qui appositamente al di fuori di Kubernetes perch\u00e9 pu\u00f2 essere eseguito anche esternamente a K8s. Spesso, naturalmente, tutti gli operatori vengono eseguiti in Kubernetes, ma niente impedisce di posizionarlo all'esterno, quindi qui \u00e8 stato appositamente spostato all'esterno. <\/p>\n
<\/p>\n
<\/p>\n
E nel suo turno, il controller personalizzato, noto anche come operatore, interagisce con Kubernetes attraverso l'API. Sa gi\u00e0 come interagire con l'API e conosce gi\u00e0 come materializzare uno schema complesso a partire da una risorsa personalizzata, ci\u00f2 che vogliamo realizzare. \u00c8 proprio di questo che 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 ulteriormente l'interazione con K8s.<\/p>\n
<\/p>\n
<\/p>\n
L'operatore \u00e8 un programma. \u00c8 orientato agli eventi. Utilizzando l'API di Kubernetes, l'operatore si iscrive agli eventi. Nell'API di Kubernetes ci sono punti di entrata dove ci si pu\u00f2 iscrivere agli eventi. E se qualcosa cambia in K8s, Kubernetes invia eventi a tutti gli interessati, ovvero chi si \u00e8 iscritto a quel punto dell'API ricever\u00e0 notifiche.<\/p>\n
<\/p>\n
L'operatore si iscrive agli eventi e deve reagire in qualche modo. 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. Questo \u00e8 passato a etcd tramite kubectl apply. Qui si \u00e8 attivato un evento, che \u00e8 arrivato al ClickHouse-operator. L'operatore ha ricevuto questa descrizione. E ora ha qualcosa da fare. Se \u00e8 arrivato un aggiornamento per l'oggetto ClickHouseInstallation, bisogna aggiornare il cluster. Il compito dell'operatore \u00e8 quello di aggiornare il cluster. <\/p>\n
<\/p>\n
<\/p>\n
Cosa fa? In primo luogo, deve elaborare un piano d'azione per gestire questo aggiornamento. Gli aggiornamenti possono essere molto piccoli, cio\u00e8 ridotti 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 lavorare su questa struttura secondo il piano, per materializzare i pod, i servizi, cio\u00e8 per 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 un aspetto interessante. Questa \u00e8 la suddivisione 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 delle operazioni di sistema, ovvero del set base di oggetti che pu\u00f2 essere interpretato come ambito di sistema. Kubernetes sa come avviare pod, riavviare container, montare volumi e gestire ConfigMap, cio\u00e8 tutto ci\u00f2 che pu\u00f2 essere definito come sistema. <\/p>\n
<\/p>\n
Gli operatori operano in settori specifici. Ogni operatore \u00e8 creato per il proprio settore. Ne abbiamo realizzato uno per ClickHouse.<\/p>\n
<\/p>\n
E l'operatore interagisce precisamente in termini del settore, come aggiungere una replica, creare uno schema, configurare il monitoraggio. Questo porta a una chiara distinzione.<\/p>\n
<\/p>\n
<\/p>\n
Vediamo un esempio pratico di come avviene questa suddivisione delle responsabilit\u00e0 quando eseguiamo l'azione di aggiungere una replica. <\/p>\n
<\/p>\n
L'operatore riceve la richiesta di aggiungere una replica. Cosa fa l'operatore? Calcola che deve creare un nuovo StatefulSet, in cui deve descrivere determinati modelli e richieste di volume. <\/p>\n
<\/p>\n
<\/p>\n
Ha preparato tutto questo e lo passa a K8s. Dice che ha bisogno di ConfigMap, StatefulSet e Volume. Kubernetes elabora la richiesta. Materializza le unit\u00e0 fondamentali con cui opera. <\/p>\n
<\/p>\n
<\/p>\n
E cos\u00ec entra in gioco di nuovo il ClickHouse-operator. Ha gi\u00e0 un pod fisico su cui pu\u00f2 iniziare a lavorare. E il ClickHouse-operator opera di nuovo in termini della specifica del dominio. Cio\u00e8, specificamente per ClickHouse, per includere una replica nel cluster \u00e8 necessario, prima di tutto, configurare lo schema dei dati presente in quel cluster. In secondo luogo, questa replica deve essere inclusa nel monitoraggio per garantirne un buon tracciamento. L'operatore si occupa di questa configurazione. <\/p>\n
<\/p>\n
<\/p>\n
E solo dopo questo entra in gioco il ClickHouse stesso, cio\u00e8 un'entit\u00e0 di livello superiore. Questa \u00e8 gi\u00e0 un database. Ha il proprio instance, un'altra replica configurata, pronta per entrare nel cluster.<\/p>\n
<\/p>\n
Si ha cos\u00ec una catena di esecuzione e divisione delle responsabilit\u00e0 piuttosto lunga quando si aggiunge una replica.<\/p>\n
<\/p>\n
<\/p>\n
Continuiamo con i nostri esercizi pratici. Se il cluster \u00e8 gi\u00e0 esistente, si pu\u00f2 procedere con la migrazione della configurazione. <\/p>\n
<\/p>\n
<\/p>\n
Abbiamo fatto in modo che nel file xml esistente, che ClickHouse comprende, si possa passare attraverso.<\/p>\n
<\/p>\n
<\/p>\n
\u00c8 possibile effettuare un fine-tuning di ClickHouse. Proprio il zoned deployment \u00e8 ci\u00f2 di cui parlavo spiegando il hostPath e lo storage locale. \u00c8 come configurare correttamente il zoned deployment.<\/p>\n
<\/p>\n
<\/p>\n
Il prossimo compito pratico \u00e8 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 analizzato le frecce verdi. Ora consideriamo le frecce rosse. Questo \u00e8 come vogliamo monitorare il nostro cluster. Come le metriche dal cluster ClickHouse arrivano a Prometheus e poi a Grafana.<\/p>\n
<\/p>\n
<\/p>\n
Qual \u00e8 la difficolt\u00e0 nel monitoraggio? Perch\u00e9 \u00e8 considerato un risultato? La difficolt\u00e0 risiede nella dinamica. Quando abbiamo un cluster singolo e statico, possiamo configurare il monitoraggio una volta e non pensarci pi\u00f9.<\/p>\n
<\/p>\n
Ma se abbiamo molti cluster, o se qualcosa cambia continuamente, il processo diventa dinamico. E occuparsi costantemente della riconfigurazione del monitoraggio \u00e8 uno spreco di risorse e tempo, ovvero anche solo una fonte di pigrizia. Questo deve essere automatizzato. La difficolt\u00e0 sta nella dinamicit\u00e0 del processo. E l'operatore lo automatizza molto bene. <\/p>\n
<\/p>\n
<\/p>\n
Come si \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 in questo modo. <\/p>\n
<\/p>\n
Il monitoraggio \u00e8 fatto automaticamente dall'operatore. Unico punto di accesso. <\/p>\n
<\/p>\n
<\/p>\n
E noi guardiamo solo il dashboard Grafana, osservando la vita pulsante del nostro cluster. <\/p>\n
<\/p>\n
A proposito, anche il dashboard Grafana viene fornito con il nostro operatore direttamente nel codice sorgente. \u00c8 possibile collegarlo e utilizzarlo. Questo screenshot \u00e8 stato fornito dai nostri DevOps.<\/p>\n
<\/p>\n
<\/p>\n
Qual \u00e8 la nostra prossima direzione? Questo \u00e8:<\/p>\n
<\/p>\n
\nSviluppare l'automazione dei test. L'obiettivo principale \u00e8 il test automatizzato delle nuove versioni. <\/li>\n Vogliamo anche automatizzare l'integrazione con ZooKeeper. Abbiamo in programma di integrarci con lo ZooKeeper-operator. Cio\u00e8, per ZooKeeper \u00e8 stato scritto un operatore, ed \u00e8 logico che i due operatori inizino a integrarsi per costruire una soluzione pi\u00f9 comoda. <\/li>\n Vogliamo implementare controlli pi\u00f9 complessi per la vitalit\u00e0. <\/li>\n In verde ho evidenziato ci\u00f2 che ha gi\u00e0 raggiunto l'eredit\u00e0 dei Templates \u2013 FATTO, cio\u00e8 con il prossimo rilascio dell'operatore avremo gi\u00e0 l'eredit\u00e0 dei template. Questo \u00e8 uno strumento potente che consente di costruire configurazioni complesse da pezzi. <\/li>\n E vogliamo l'automazione di compiti complessi. Il principale di cui stiamo parlando \u00e8 la Re-sharding. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Facciamo un riepilogo intermedio. <\/p>\n
<\/p>\n
<\/p>\n
Cosa otteniamo alla fine? \u00c8 conveniente farlo o no? \u00c8 necessario tentare di portare un database in Kubernetes e applicare l'operatore in generale e l'operatore Alitnity in particolare?<\/p>\n
<\/p>\n
Alla fine otteniamo:<\/p>\n
<\/p>\n
\nUna significativa semplificazione e automazione della configurazione, del deployment e della manutenzione. <\/li>\n Monitoraggio integrato fin da subito. <\/li>\n E modelli codificati pronti all'uso per situazioni complesse. Non \u00e8 pi\u00f9 necessario aggiungere manualmente una replica. Questo \u00e8 compito dell'operatore. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Rimane solo un'ultima domanda. Abbiamo gi\u00e0 un database in Kubernetes, virtualizzazione. Qual \u00e8 la performance di tale soluzione, specialmente considerando che ClickHouse \u00e8 ottimizzato per le performance?<\/p>\n
<\/p>\n
La risposta \u00e8: tutto funziona bene! Non entrer\u00f2 nei dettagli, \u00e8 un argomento di un intervento separato. <\/p>\n
<\/p>\n
<\/p>\n
Ma esiste un progetto chiamato TSBS. Qual \u00e8 il suo obiettivo principale? \u00c8 un test per valutare le performance dei database. \u00c8 un tentativo di confrontare il caldo con il caldo, il morbido con il morbido. <\/p>\n
<\/p>\n
Come funziona? Viene generato un insieme di dati. Successivamente, questo set di dati viene eseguito su un insieme di test identico su diverse basi di dati. E ogni database risolve un compito secondo le proprie capacit\u00e0. Poi \u00e8 possibile confrontare i risultati. <\/p>\n
<\/p>\n
Supporta gi\u00e0 un ampio numero di database. Ne ho evidenziati tre principali. Questi sono:<\/p>\n
<\/p>\n
\nTimescaleDB.<\/li>\n InfluxDB.<\/li>\n ClickHouse.<\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
\u00c8 stato inoltre effettuato un confronto con un'altra soluzione simile. Il confronto con RedShift. L'analisi \u00e8 stata condotta su Amazon. Anche ClickHouse supera tutti in questo ambito. <\/p>\n
<\/p>\n
<\/p>\n
Quali conclusioni possiamo trarre da quanto ho detto?<\/p>\n
<\/p>\n
\nDB pu\u00f2 essere utilizzato in Kubernetes. Probabilmente, si possono utilizzare tutti, ma in generale sembra che sia possibile. ClickHouse in Kubernetes \u00e8 certamente utilizzabile tramite il nostro operatore. <\/li>\n L'operatore aiuta ad automatizzare i processi e semplifica davvero la vita.<\/li>\n Le performance sono buone.<\/li>\n E, riteniamo, che sia possibile e necessario utilizzarlo. <\/li>\n<\/ul>\n<\/p>\n
Open source \u2013 unitevi a noi!<\/p>\n
<\/p>\n
Come ho gi\u00e0 detto, l'operatore \u00e8 un prodotto completamente open source, quindi sarebbe davvero fantastico 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 e vengo dall'azienda SEMrush. Sono curioso riguardo al logging. Sento parlare di monitoraggio, ma riguardo al logging non si dice nulla, parlando del cluster nel suo insieme. Noi, ad esempio, abbiamo sollevato un cluster sull'hardware. E utilizziamo il logging centralizzato, raccogliendo standardmente in un unico luogo. E poi da l\u00ec estraiamo i dati che ci interessano.<\/em> <\/p>\n<\/p>\n
Ottima domanda, cio\u00e8 il logging \u00e8 nella lista delle cose da fare. Il nostro operatore per ora non lo automatizza. \u00c8 ancora in fase di sviluppo, il progetto \u00e8 abbastanza giovane. Comprendiamo l'importanza del logging. \u00c8 un tema molto rilevante. E probabilmente \u00e8 almeno importante quanto il monitoraggio. Ma il monitoraggio \u00e8 stato il primo in lista per l'implementazione. 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 purtroppo non \u00e8 in grado di farlo, ma \u00e8 nei nostri piani, lo faremo. Se c'\u00e8 interesse a partecipare, per favore fai un pull request.<\/p>\n
<\/p>\n
Ciao! Grazie per la presentazione! Ho una domanda standard riguardante i Persistent Volumes. Quando creiamo una configurazione con quest'operatore, come fa l'operatore a determinare su quale nodo abbiamo montato un disco o una cartella? Dobbiamo spiegarli in anticipo che, per favore, posizioni il nostro ClickHouse precisamente su quei nodi dove c'\u00e8 un disco?<\/em><\/p>\n<\/p>\n
Se non erro, questa domanda \u00e8 un proseguimento dello storage locale, in particolare della parte relativa a hostPath. \u00c8 come spiegare all'intero sistema che vogliamo che un pod venga eseguito su un determinato nodo, sul quale abbiamo un disco fisicamente collegato, montato in un determinato percorso. \u00c8 un'intera sezione che ho toccato in modo molto superficiale, perch\u00e9 la risposta \u00e8 piuttosto complessa. <\/p>\n
<\/p>\n
In breve, funziona in questo modo. Naturalmente, dobbiamo fare il provisioning di questi volumi. Attualmente, non c'\u00e8 provisioning dinamico nello storage locale, quindi i DevOps devono creare manualmente i dischi, ossia questi volumi. Devono anche spiegare a Kubernetes il provisioning, indicando che ci saranno Persistent volumes di un certo tipo, localizzati su specifici nodi. Dopodich\u00e9, sar\u00e0 necessario spiegare a Kubernetes che i pod che richiedono un certo tipo di storage locale devono essere schedulati solo su determinati nodi mediante labels. A tal fine, l'operatore ha la possibilit\u00e0 di assegnare etichette specifiche e una per istanza host. Di conseguenza, i pod verranno instradati da Kubernetes per avviarsi solo su nodi che soddisfano i requisiti delle etichette, per dirla in termini semplici. Gli amministratori assegnano le labels e fanno il provisioning dei dischi manualmente. In questo modo, si riesce a scalare.<\/p>\n
<\/p>\n
E infatti, la terza opzione locale aiuta un po' a semplificare questo lavoro. Come ho gi\u00e0 sottolineato, si tratta di un lavoro meticoloso di configurazione che, alla fine, contribuisce a ottenere la massima performance.<\/p>\n
<\/p>\n
Ho una seconda domanda relativa a questo. Kubernetes \u00e8 stato progettato in modo che non ci importi se perdiamo un nodo o meno. Cosa dobbiamo fare in questo caso, se perdiamo il nodo in cui \u00e8 ospitato uno shard?<\/em><\/p>\n<\/p>\n
S\u00ec, Kubernetes \u00e8 stato inizialmente concepito con l'idea che il nostro rapporto con i nostri pod sia simile a quello con il bestiame, mentre ogni disco diventa qualcosa di simile a un animale domestico. C'\u00e8 un problema: non possiamo semplicemente buttarli via. Lo sviluppo di Kubernetes sta andando verso la direzione in cui non \u00e8 possibile considerare tutto questo in modo puramente filosofico, come risorse completamente usa e getta.<\/p>\n
<\/p>\n
Ora, una domanda pratica. Cosa fare se hai perso un nodo su cui si trovava un disco? Qui la questione viene risolta a un livello pi\u00f9 alto. Nel caso di ClickHouse, abbiamo delle repliche che operano a un livello superiore, cio\u00e8 a livello di ClickHouse.<\/p>\n
<\/p>\n
Qual \u00e8 la disposizione finale? \u00c8 responsabilit\u00e0 del DevOps assicurarsi che i dati non vengano persi. Deve configurare correttamente la replica e deve monitorare che essa funzioni. I dati devono essere duplicati nella replica a livello di ClickHouse. Non \u00e8 un compito che risolve l'operatore e nemmeno Kubernetes. \u00c8 una questione a livello di ClickHouse.<\/p>\n
<\/p>\n
Cosa fare se il tuo nodo fisico \u00e8 andato gi\u00f9? Dobbiamo quindi installare un secondo nodo, configurare correttamente il disco e applicare le etichette. Solo cos\u00ec potr\u00e0 soddisfare i requisiti affinch\u00e9 Kubernetes possa avviare un'istanza del pod. Kubernetes lo avvier\u00e0. Hai un numero insufficiente di pod rispetto a quello richiesto. Passer\u00e0 attraverso il ciclo che ti ho mostrato. A un livello superiore, ClickHouse capir\u00e0 che \u00e8 stata aggiunta una replica, che \u00e8 ancora vuota e da cui iniziare a trasferire i dati. Questo processo, per\u00f2, \u00e8 ancora poco automatizzato. <\/p>\n
<\/p>\n
Grazie per la presentazione! Quando accadono inconvenienti e l'operatore si blocca e si riavvia, nel frattempo arrivano eventi. Come gestisci questa situazione?<\/em><\/p>\n<\/p>\n
Cosa succede se l'operatore si blocca e si riavvia, giusto? <\/p>\n
<\/p>\n
Esatto. E in quel momento sono arrivati eventi.<\/em> <\/p>\n<\/p>\n
Il compito di gestire questa situazione \u00e8 parzialmente suddiviso tra l'operatore e Kubernetes. Kubernetes ha la capacit\u00e0 di riprodurre l'evento che si \u00e8 verificato. Lo riproduce. Compito dell'operatore \u00e8 garantire che, quando viene eseguito un replay del log degli eventi, questi eventi siano idempotenti. Questo significa che la ripetizione dello stesso evento non deve danneggiare il nostro sistema. E il nostro operatore gestisce bene questo compito. <\/p>\n
<\/p>\n
Buongiorno! Grazie per la presentazione! Dmitrij Zavjalov, azienda<\/em> Smedova. \u00c8 prevista l'aggiunta di funzionalit\u00e0 di configurazione dell'operatore con haproxy? Sarei interessato a un altro bilanciatore oltre a quello standard, che sia intelligente e comprenda che si tratta di ClickHouse.<\/em> <\/p>\n<\/p>\n
Stai parlando di Ingress?<\/p>\n
<\/p>\n
S\u00ec, sostituisci Ingress con haproxy. In haproxy puoi specificare la topologia del cluster, dove ha le repliche.<\/em><\/p>\n<\/p>\n
Per ora non ci abbiamo pensato. Se hai bisogno di questa funzione e puoi spiegare perch\u00e9 ti serve, possiamo implementarla, soprattutto se desideri partecipare. Saremmo felici di considerare questa opzione. In breve, no, al momento non abbiamo questa funzionalit\u00e0. Grazie per il suggerimento, ci daremo un'occhiata. Se puoi anche spiegare il caso d'uso e perch\u00e9 \u00e8 necessario nella pratica, ad esempio creando dei problemi su GitHub, sarebbe ottimo.<\/p>\n
<\/p>\n
Esiste gi\u00e0.<\/em><\/p>\n<\/p>\n
Va bene. Siamo aperti a qualsiasi proposta. E haproxy \u00e8 inserito nella lista todo. La lista todo cresce, e non diminuisce 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