L'informe està dedicat a les qüestions pràctiques del desenvolupament d'un operador a Kubernetes, el disseny de la seva arquitectura i els principis bàsics de funcionament.
En la primera part de l'informe tindrem en compte:
- què és un operador a Kubernetes i per què es necessita;
- com l'operador simplifica exactament la gestió de sistemes complexos;
- el que l'operador pot i no pot fer.
A continuació, passem a discutir l'estructura interna de l'operador. Vegem pas a pas l'arquitectura i el funcionament de l'operador. Vegem-ho amb detall:
- interacció entre l'operador i Kubernetes;
- quines funcions assumeix l'operador i quines funcions delega a Kubernetes.
Vegem com gestionar fragments i rèpliques de bases de dades a Kubernetes.
A continuació, parlarem dels problemes d'emmagatzematge de dades:
- com treballar amb l'emmagatzematge persistent des del punt de vista d'un operador;
- inconvenients d'utilitzar l'emmagatzematge local.
A la part final de l'informe, considerarem exemples pràctics d'aplicació amb Amazon o Google Cloud Service. L'informe es basa en l'exemple de desenvolupament i experiència operativa d'un operador de ClickHouse.
Vídeo:
Em dic Vladislav Klimenko. Avui volia parlar de la nostra experiència en el desenvolupament i operació d'un operador, i aquest és un operador especialitzat en la gestió de clústers de bases de dades. Per exemple per gestionar el clúster ClickHouse.
Per què tenim l'oportunitat de parlar de l'operador i de ClickHouse?
- Donem suport i desenvolupem ClickHouse.
- De moment, estem intentant contribuir a poc a poc al desenvolupament de ClickHouse. I estem segons Yandex pel que fa al volum de canvis fets a ClickHouse.
- Estem intentant crear projectes addicionals per a l'ecosistema ClickHouse.
M'agradaria parlar-vos d'un d'aquests projectes. Es tracta de l'operador ClickHouse per a Kubernetes.
En el meu informe m'agradaria tocar dos temes:
- El primer tema és com funciona el nostre operador de gestió de bases de dades ClickHouse a Kubernetes.
- El segon tema és com funciona qualsevol operador, és a dir, com interactua amb Kubernetes.
Tanmateix, aquestes dues preguntes es creuaran al llarg del meu informe.
A qui li interessaria escoltar el que estic intentant explicar?
- Serà del més interessant per a aquells que operen operadors.
- O per a aquells que vulguin fer el seu propi per entendre com funciona internament, com interactua l'operador amb Kubernetes i quins inconvenients poden aparèixer.
Per entendre millor què parlarem avui, és una bona idea saber com funciona Kubernetes i tenir una formació bàsica al núvol.
Què és ClickHouse? Es tracta d'una base de dades columnar amb característiques específiques per al processament en línia de consultes analítiques. I és completament de codi obert.
I és important que només sabem dues coses. Heu de saber que es tracta d'una base de dades, així que el que us diré serà aplicable a gairebé qualsevol base de dades. I el fet que el SGBD de ClickHouse s'escala molt bé, dóna una escalabilitat gairebé lineal. I, per tant, l'estat del clúster és un estat natural per a ClickHouse. I estem més interessats a debatre com servir el clúster ClickHouse a Kubernetes.
Per què es necessita allà? Per què no podem continuar operant-lo nosaltres mateixos? I les respostes són en part tècniques i en part organitzatives.
- A la pràctica, cada cop ens trobem més amb una situació en què a les grans empreses gairebé tots els components ja es troben a Kubernetes. Les bases de dades romanen fora.
- I la pregunta es fa cada cop més: "Això es pot posar a dins?" Per tant, les grans empreses intenten aconseguir la màxima unificació de la gestió per poder gestionar ràpidament els seus magatzems de dades.
- I això ajuda especialment si necessiteu la màxima oportunitat de repetir el mateix en un lloc nou, és a dir, la màxima portabilitat.
Què tan fàcil o difícil és? Això, per descomptat, es pot fer a mà. Però no és tan senzill, perquè tenim la complexitat afegida de gestionar Kubernetes en si, però al mateix temps es superposen les especificitats de ClickHouse. I aquesta agregació resulta.
I tot plegat dóna un conjunt bastant ampli de tecnologies, que esdevé força difícil de gestionar, perquè Kubernetes posa en funcionament els seus propis problemes quotidians i ClickHouse aporta els seus propis problemes al funcionament quotidià. Sobretot si tenim diverses ClickHouses i hem de fer alguna cosa constantment amb elles.
Amb una configuració dinàmica, ClickHouse té un nombre bastant gran de problemes que creen una càrrega constant a DevOps:
- Quan volem canviar alguna cosa a ClickHouse, per exemple, afegir una rèplica o fragment, llavors hem de gestionar la configuració.
- A continuació, canvieu l'esquema de dades, perquè ClickHouse té un mètode de fragmentació específic. Allà heu de dissenyar el diagrama de dades, establir les configuracions.
- Heu de configurar el control.
- Recollida de registres per a nous fragments, per a noves rèpliques.
- Cuida't de la restauració.
- I reiniciar.
Aquestes són tasques rutinàries que m'agradaria fer més fàcils d'utilitzar.
El propi Kubernetes ajuda bé en el funcionament, però en les coses bàsiques del sistema.
Kubernetes és bo per facilitar i automatitzar coses com:
- Recuperació.
- Reinicia.
- Gestió del sistema d'emmagatzematge.
Això està bé, aquesta és la direcció correcta, però no té ni idea de com operar un clúster de bases de dades.
Volem més, volem que tota la base de dades funcioni a Kubernetes.
M'agradaria obtenir una cosa així com un botó vermell màgic gran que premeu i un clúster amb tasques quotidianes que cal resoldre es desplega i es manté durant tot el seu cicle de vida. Clúster ClickHouse a Kubernetes.
I vam intentar fer una solució que ajudés a facilitar la feina. Aquest és un operador ClickHouse per a Kubernetes d'Altinity.
Un operador és un programa la tasca principal del qual és gestionar altres programes, és a dir, és un gestor.
I conté patrons de comportament. Podeu anomenar aquest coneixement codificat sobre l'àrea temàtica.
I la seva tasca principal és facilitar la vida de DevOps i reduir la microgestió, perquè ell (DevOps) ja pensi en termes d'alt nivell, és a dir, perquè ell (DevOps) no es dediqui a la microgestió, de manera que no es configura. tots els detalls manualment.
I només l'operador és un assistent robòtic que s'ocupa de les microtasques i ajuda a DevOps.
Per què necessites un operador? Té un bon rendiment en dues àrees:
- Quan l'especialista que s'ocupa de ClickHouse no té prou experiència, però ja necessita operar ClickHouse, l'operador facilita l'operació i permet operar un clúster ClickHouse amb una configuració força complexa, sense entrar en massa detalls sobre com funciona tot. dins. Només li doneu tasques d'alt nivell i funciona.
- I la segona tasca en què millor funciona és quan cal automatitzar un gran nombre de tasques típiques. Elimina les microtasques dels administradors del sistema.
Això ho necessiten més els que acaben de començar el seu viatge o els que necessiten fer molta automatització.
En què es diferencia l'enfocament basat en l'operador d'altres sistemes? Hi ha Helm. També ajuda a instal·lar ClickHouse; podeu dibuixar gràfics de timó, que fins i tot instal·laran un clúster de ClickHouse sencer. Quina diferència hi ha, doncs, entre l'operador i el mateix, per exemple, Helm?
La principal diferència fonamental és que Helm és la gestió de paquets i Operator fa un pas més enllà. Això és suport per a tot el cicle de vida. No només es tracta d'instal·lar, sinó que són tasques quotidianes que inclouen l'escalat, la fragmentació, és a dir, tot el que s'ha de fer durant el cicle de vida (si cal, després també la supressió), tot això ho decideix l'operador. Intenta automatitzar i mantenir tot el cicle de vida del programari. Aquesta és la seva diferència fonamental amb altres solucions que es presenten.
Aquesta va ser la part introductòria, continuem.
Com construïm el nostre operador? Estem intentant abordar el problema per gestionar el clúster ClickHouse com un sol recurs.
Aquí tenim les dades d'entrada a la part esquerra de la imatge. Es tracta de YAML amb una especificació de clúster, que es passa a Kubernetes de la manera clàssica mitjançant kubectl. Allà el nostre operador el recull i fa la seva màgia. I a la sortida obtenim el següent esquema. Aquesta és una implementació de ClickHouse a Kubernetes.
I després veurem lentament com funciona exactament l'operador, quines tasques típiques es poden resoldre. Només tindrem en compte les tasques típiques perquè tenim un temps limitat. I no es parlarà de tot el que pugui decidir l'operador.
Comencem per la pràctica. El nostre projecte és completament de codi obert, de manera que podeu veure com funciona a GitHub. I podeu procedir a partir de les consideracions que si només voleu llançar-lo, podeu començar amb la Guia d'inici ràpid.
Si voleu entendre-ho en detall, aleshores intentem mantenir la documentació d'una forma més o menys decent.
Comencem amb un problema pràctic. La primera tasca, on tots volem començar, és executar el primer exemple d'alguna manera. Com puc iniciar ClickHouse mitjançant l'operador, encara que no sé realment com funciona? Estem escrivint un manifest, perquè... Tota comunicació amb k8s és comunicació a través de manifests.
Aquest és un manifest tan complex. El que hem destacat en vermell és en què hem de centrar-nos. Demanem a l'operador que creï un clúster anomenat demo.
Aquests són exemples bàsics de moment. Encara no s'ha descrit l'emmagatzematge, però tornarem a l'emmagatzematge una mica més tard. De moment, observarem la dinàmica del desenvolupament del clúster.
Hem creat aquest manifest. L'alimentem al nostre operador. Va treballar, va fer màgia.
Mirem la consola. Hi ha tres components d'interès: un pod, dos serveis i un StatefulSet.
L'operador ha treballat, i podem veure què ha creat exactament.
Ell crea una cosa així. Tenim un StatefulSet, Pod, ConfigMap per a cada rèplica, ConfigMap per a tot el clúster. Els serveis són necessaris com a punts d'entrada al clúster.
Els serveis són el servei central de Load Balancer i també es poden utilitzar per a cada rèplica, per a cada fragment.
El nostre clúster bàsic s'assembla a això. És d'un sol node.
Anem més enllà i compliquem les coses. Hem de dividir el clúster.
Les nostres tasques creixen, comencen les dinàmiques. Volem afegir un fragment. Seguim el desenvolupament. Estem canviant les nostres especificacions. Indiquem que volem dos fragments.
Aquest és el mateix fitxer que es desenvolupa dinàmicament amb el creixement del sistema. Emmagatzematge no, l'emmagatzematge es tractarà més endavant, aquest és un tema a part.
Alimentem l'operador YAML i veiem què passa.
L'operador va pensar i va fer les següents entitats. Ja tenim dos Pods, tres Serveis i, de sobte, 2 StatefulSets. Per què 2 StatefulSets?
Al diagrama era així: aquest és el nostre estat inicial, quan teníem una beina.
Es va fer així. Fins ara tot és senzill, s'ha duplicat.
I per què es van convertir en dos StatefulSets? Aquí hem de digressar i discutir la qüestió de com es gestionen els pods a Kubernetes.
Hi ha un objecte anomenat StatefulSet que us permet crear un conjunt de pods a partir d'una plantilla. El factor clau aquí és la plantilla. I podeu llançar molts pods utilitzant una plantilla en un StatefulSet. I la frase clau aquí és "molts pods per a una plantilla".
I hi va haver una gran temptació de fer tot el clúster, empaquetant-lo en un StatefulSet. Funcionarà, no hi ha cap problema. Però hi ha una advertència. Si volem muntar un clúster heterogeni, és a dir, a partir de diverses versions de ClickHouse, comencen a sorgir preguntes. Sí, StatefulSet pot fer una actualització continuada, i allà podeu llançar una nova versió, explicant que no heu de provar més que tants nodes alhora.
Però si extrapolem la tasca i diem que volem fer un clúster completament heterogeni i no volem canviar de la versió antiga a una de nova mitjançant una actualització continua, sinó que simplement volem crear un clúster heterogeni tant en termes de diferents versions de ClickHouse i en termes d'emmagatzematge diferent. Volem, per exemple, fer algunes rèpliques en discs separats, en discos lents, en general, per construir completament un clúster heterogeni. I a causa del fet que StatefulSet fa una solució estandarditzada a partir d'una plantilla, no hi ha manera de fer-ho.
Després d'una reflexió, es va decidir que ho faríem d'aquesta manera. Tenim cada rèplica en el seu propi StatefulSet. Aquesta solució té alguns inconvenients, però a la pràctica tot està completament encapsulat per l'operador. I hi ha molts avantatges. Podem construir el clúster exacte que volem, per exemple, un d'absolutament heterogeni. Per tant, en un clúster en què tenim dos fragments amb una rèplica, tindrem 2 StatefulSets i 2 Pods precisament perquè hem escollit aquest enfocament pels motius indicats anteriorment per poder construir un clúster heterogeni.
Tornem als problemes pràctics. Al nostre clúster hem de configurar els usuaris, és a dir. heu de fer alguna configuració de ClickHouse a Kubernetes. L'operador ofereix totes les possibilitats per a això.
Podem escriure el que volem directament a YAML. Totes les opcions de configuració es mapegen directament des d'aquest YAML a les configuracions de ClickHouse, que després es distribueixen per tot el clúster.
Podeu escriure-ho així. Això és per exemple. La contrasenya es pot xifrar. Absolutament totes les opcions de configuració de ClickHouse són compatibles. Aquí només hi ha un exemple.
La configuració del clúster es distribueix com a ConfigMap. A la pràctica, l'actualització de ConfigMap no es produeix a l'instant, de manera que si el clúster és gran, el procés d'impulsar la configuració trigarà temps. Però tot això és molt còmode d'utilitzar.
Ens compliquem la tasca. El clúster s'està desenvolupant. Volem replicar dades. És a dir, ja tenim dos fragments, una rèplica cadascun, i els usuaris estan configurats. Estem creixent i volem fer replicacions.
Què necessitem per a la replicació?
Necessitem ZooKeeper. A ClickHouse, la replicació es crea amb ZooKeeper. ZooKeeper és necessari perquè diferents rèpliques de ClickHouse tinguin un consens sobre quins blocs de dades es troben en quin ClickHouse.
ZooKeeper pot ser utilitzat per qualsevol. Si l'empresa té un ZooKeeper extern, es pot utilitzar. Si no, podeu instal·lar-lo des del nostre repositori. Hi ha un instal·lador que facilita tot això.
I el diagrama d'interacció de tot el sistema resulta així. Tenim Kubernetes com a plataforma. Executa l'operador ClickHouse. Vaig fotografiar ZooKeeper aquí. I l'operador interactua tant amb ClickHouse com amb ZooKeeper. És a dir, els resultats de la interacció.
I tot això és necessari perquè ClickHouse repliqui dades amb èxit en k8s.
Vegem ara la tasca en si, com serà el manifest per a la replicació.
Estem afegint dues seccions al nostre manifest. El primer és on obtenir ZooKeeper, que pot ser dins de Kubernetes o extern. Això és només una descripció. I demanem rèpliques. Aquells. volem dues rèpliques. En total, hauríem de tenir 4 beines a la sortida. Recordem l'emmagatzematge, tornarà una mica més tard. L'emmagatzematge és una història a part.
Va ser així.
Esdevé així. S'afegeixen rèpliques. El 4t no encaixava, creiem que hi podria haver molts. I ZooKeeper s'afegeix al costat. Els esquemes són cada cop més complexos.
I és hora d'afegir la següent tasca. Afegirem l'emmagatzematge persistent.
Per a l'emmagatzematge persistent tenim diverses opcions.
Si estem executant en un proveïdor de núvol, per exemple, utilitzant Amazon, Google, hi ha una gran temptació d'utilitzar l'emmagatzematge en núvol. És molt convenient, és bo.
I hi ha una segona opció. Això és per a l'emmagatzematge local, quan tenim discs locals a cada node. Aquesta opció és molt més difícil d'implementar, però al mateix temps és més productiva.
Vegem què tenim pel que fa a l'emmagatzematge al núvol.
Hi ha avantatges. És molt fàcil de configurar. Simplement demanem al proveïdor del núvol que ens doni emmagatzematge de tal o tal capacitat, de tal o tal classe. Les classes les programen els proveïdors de manera independent.
I hi ha un inconvenient. Per a alguns, aquest és un inconvenient no crític. Per descomptat, hi haurà alguns problemes de rendiment. És molt còmode d'utilitzar i fiable, però hi ha alguns inconvenients potencials de rendiment.
I perquè ClickHouse se centra específicament en la productivitat, fins i tot es podria dir que extreu tot el que pot, per això molts clients intenten treure la màxima productivitat.
I per treure'n el màxim profit, necessitem emmagatzematge local.
Kubernetes ofereix tres abstraccions per utilitzar l'emmagatzematge local a Kubernetes. Això:
- EmptyDir
- HostPath.
- Local
Vegem com es diferencien i com s'assemblen.
En primer lloc, en els tres enfocaments tenim emmagatzematge: es tracta de discs locals que es troben al mateix node físic k8s. Però tenen algunes diferències.
Comencem amb el més senzill, és a dir, emptyDir. Què és això a la pràctica? A la nostra especificació, demanem al sistema de contenidors (la majoria de vegades Docker) que ens proporcioni accés a una carpeta del disc local.
A la pràctica, Docker crea una carpeta temporal en algun lloc dels seus propis camins i l'anomena hash llarg. I proporciona una interfície per accedir-hi.
Com funcionarà això pel que fa al rendiment? Això funcionarà a la velocitat del disc local, és a dir. Això és un accés complet al vostre cargol.
Però aquest cas té el seu inconvenient. Persistent és bastant dubtós en aquest tema. La primera vegada que Docker es mou amb contenidors, Persistent es perd. Si Kubernetes vol moure aquest Pod a un altre disc per algun motiu, les dades es perdran.
Aquest enfocament és bo per a les proves, perquè ja mostra una velocitat normal, però per a alguna cosa seriosa aquesta opció no és adequada.
Per tant, hi ha un segon enfocament. Això és hostPath. Si mireu la diapositiva anterior i aquesta, només podreu veure una diferència. La nostra carpeta s'ha mogut de Docker directament al node Kubernetes. Aquí és una mica més senzill. Especifiquem directament la ruta al sistema de fitxers local on voldríem emmagatzemar les nostres dades.
Aquest mètode té avantatges. Això ja és un autèntic persistent, i un clàssic. Tindrem dades gravades al disc en alguna adreça.
També hi ha desavantatges. Aquesta és la complexitat de la gestió. És possible que el nostre Kubernetes vulgui moure el pod a un altre node físic. I aquí és on entra en joc DevOps. Ha d'explicar correctament a tot el sistema que aquestes beines només es poden moure a aquells nodes en els quals tingueu alguna cosa muntada al llarg d'aquests camins, i no més d'un node alhora. És bastant difícil.
Especialment per a aquests propòsits, hem fet plantilles al nostre operador per tal d'amagar tota aquesta complexitat. I simplement podríeu dir: "Vull tenir una instància de ClickHouse per a cada node físic i per tal camí".
Però no som els únics que necessitem aquesta necessitat, per la qual cosa els propis senyors de Kubernetes també entenen que la gent vol tenir accés als discos físics, de manera que proporcionen una tercera capa.
Es diu local. No hi ha pràcticament cap diferència amb la diapositiva anterior. Només abans era necessari confirmar manualment que no podem transferir aquests pods d'un node a un altre, perquè s'han d'adjuntar per algun camí a un disc físic local, però ara tot aquest coneixement està encapsulat al mateix Kubernetes. I resulta que és molt més fàcil de configurar.
Tornem al nostre problema pràctic. Tornem a la plantilla YAML. Aquí tenim emmagatzematge real. Ja hi hem tornat. Configurem la plantilla clàssica de VolumeClaim com a k8s. I descrivim quin tipus d'emmagatzematge volem.
Després d'això, k8s sol·licitarà emmagatzematge. Ens l'assignarà al StatefulSet. I al final estarà a disposició de ClickHouse.
Teníem aquest esquema. El nostre emmagatzematge persistent era vermell, cosa que semblava indicar que calia fer-ho.
I es torna verd. Ara l'esquema de clúster ClickHouse on k8s està completament finalitzat. Tenim fragments, rèpliques, ZooKeeper, tenim un Autèntic Persistent, que s'implementa d'una manera o altra. L'esquema ja està en ple funcionament.
Seguim vivint. El nostre clúster s'està desenvolupant. I Alexey ho prova i llança una nova versió de ClickHouse.
Es planteja una tasca pràctica: provar la nova versió de ClickHouse al nostre clúster. I, naturalment, no voleu desplegar-ho tot; voleu posar una versió nova en una rèplica en algun lloc de l'extrem, i potser no una versió nova, sinó dues alhora, perquè surten sovint.
Què podem dir d'això?
Aquí tenim aquesta oportunitat. Aquestes són plantilles de pods. Podeu escriure que el nostre operador us permet completament construir un clúster heterogeni. Aquells. configurar, començant per totes les rèpliques en un grup, acabant amb cada rèplica personal, quina versió volem ClickHouse, quina versió volem emmagatzemar. Podem configurar completament el clúster amb la configuració que necessitem.
Anem una mica més endins. Abans d'això, vam parlar sobre com funciona l'operador ClickHouse en relació amb les especificitats de ClickHouse.
Ara m'agradaria dir algunes paraules sobre com funciona qualsevol operador en general, així com com interactua amb els K8.
Vegem primer la interacció amb els K8. Què passa quan apliquem kubectl? Els nostres objectes apareixen a etcd mitjançant l'API.
Per exemple, objectes bàsics de Kubernetes: pod, StatefulSet, servei i així successivament a la llista.
Al mateix temps, encara no passa res físic. Aquests objectes s'han de materialitzar al clúster.
Amb aquest propòsit, apareix un controlador. El controlador és un component especial k8s que pot materialitzar aquestes descripcions. Sap com i què fer físicament. Sap com executar contenidors, què cal configurar-hi perquè funcioni el servidor.
I materialitza els nostres objectes en K8.
Però no només volem operar amb pods i StatefulSets, sinó que volem crear una ClickHouseInstallation, és a dir, un objecte del tipus ClickHouse, per tal d'operar-hi com un tot únic. Fins ara no hi ha aquesta possibilitat.
Però K8s té la següent cosa agradable. Volem que tinguem un lloc com aquesta entitat complexa en què el nostre clúster es reuniria a partir de pods i StatefulSet.
I què cal fer per a això? En primer lloc, la definició de recursos personalitzada entra a la imatge. Què és això? Aquesta és una descripció per a K8s, que tindreu un tipus de dades més, que volem afegir un recurs personalitzat al pod, StatefulSet, que serà complex a l'interior. Aquesta és una descripció de l'estructura de dades.
També l'enviem allà mitjançant l'aplicació kubectl. Kubernetes s'ho va agafar feliçment.
I ara al nostre emmagatzematge, l'objecte a etcd té l'oportunitat de gravar un recurs personalitzat anomenat ClickHouseInstallation.
Però de moment no passarà res més. És a dir, si ara creem el fitxer YAML que hem mirat descrivint fragments i rèpliques i diem "s'aplica kubectl", llavors Kubernetes l'acceptarà, el posarà a etcd i dirà: "Genial, però no sé què fer. amb ell. No sé com mantenir ClickHouseInstallation".
En conseqüència, necessitem algú que ajudi Kubernetes a oferir el nou tipus de dades. A l'esquerra tenim un controlador de Kubernetes natiu que funciona amb tipus de dades nadius. I a la dreta hauríem de tenir un controlador personalitzat que pugui funcionar amb tipus de dades personalitzats.
I d'una altra manera s'anomena operador. El vaig incloure aquí específicament com a Kubernetes, perquè també es pot executar fora de K8. Molt sovint, per descomptat, tots els operadors s'executen a Kubernetes, però res no impedeix que es quedi fora, de manera que aquí es mou especialment a l'exterior.
I al seu torn, el controlador personalitzat, també conegut com a operador, interactua amb Kubernetes mitjançant l'API. Ja sap com interactuar amb l'API. I ja sap materialitzar el complex circuit que volem fer a partir d'un recurs personalitzat. Això és exactament el que fa l'operador.
Com funciona l'operador? Mirem el costat dret per veure com ho fa. Descobrim com l'operador materialitza tot això i com es produeix una interacció posterior amb els K8.
Un operador és un programa. Ella està orientada a esdeveniments. L'operador es subscriu als esdeveniments mitjançant l'API de Kubernetes. L'API de Kubernetes té punts d'entrada on us podeu subscriure als esdeveniments. I si alguna cosa canvia als K8, llavors Kubernetes envia esdeveniments a tothom, és a dir. qui s'hagi subscrit a aquest punt API rebrà notificacions.
L'operador es subscriu als esdeveniments i ha de fer algun tipus de reacció. La seva tasca és donar resposta als esdeveniments emergents.
Els esdeveniments es generen per determinades actualitzacions. Arriba el nostre fitxer YAML amb una descripció de ClickHouseInstallation. Va anar a etcd mitjançant kubectl apply. S'hi va desencadenar un esdeveniment i, com a resultat, aquest esdeveniment va arribar a l'operador de ClickHouse. L'operador va rebre aquesta descripció. I alguna cosa ha de fer. Si ha arribat una actualització per a l'objecte ClickHouseInstallation, haureu d'actualitzar el clúster. I la tasca de l'operador és actualitzar el clúster.
Què està fent? En primer lloc, hem d'elaborar un pla d'acció sobre què farem amb aquesta actualització. Les actualitzacions poden ser molt petites, és a dir. petit en l'execució de YAML, però pot comportar canvis molt grans al clúster. Per tant, l'operador crea un pla i després s'hi adhereix.
Segons aquest pla, comença a cuinar aquesta estructura per dins per tal de materialitzar beines, serveis, és a dir. fer quina és la seva tasca principal. Així és com es crea un clúster ClickHouse a Kubernetes.
Ara toquem una cosa tan interessant. Es tracta d'una divisió de responsabilitat entre Kubernetes i l'operador, és a dir. què fa Kubernetes, què fa l'operador i com interactuen entre ells.
Kubernetes és responsable de les coses del sistema, és a dir. per a un conjunt bàsic d'objectes que es poden interpretar com a àmbit del sistema. Kubernetes sap com llançar pods, com reiniciar contenidors, com muntar volums, com treballar amb ConfigMap, és a dir. tot allò que es pot anomenar sistema.
Els operadors operen en dominis. Cada operador està fet per a la seva pròpia àrea temàtica. Ho vam fer per ClickHouse.
I l'operador interactua precisament pel que fa a l'àrea temàtica, com ara afegir una rèplica, fer un diagrama, configurar el seguiment. Això dóna lloc a una divisió.
Vegem un exemple pràctic de com es produeix aquesta divisió de responsabilitat quan fem l'acció d'afegir rèplica.
L'operador rep una tasca: afegir una rèplica. Què fa l'operador? L'operador calcularà que s'ha de crear un nou StatefulSet, en el qual s'han de descriure tals plantilles, reclamació de volum.
Ho va preparar tot i ho passa als K8. Diu que necessita ConfigMap, StatefulSet, Volume. Kubernetes està funcionant. Materialitza les unitats bàsiques amb les quals opera.
I llavors l'operador ClickHouse torna a entrar en joc. Ja té una beina física sobre la qual ja pot fer alguna cosa. I ClickHouse-operator torna a funcionar en termes de domini. Aquells. Concretament ClickHouse, per incloure una rèplica en un clúster, primer heu de configurar l'esquema de dades que hi ha en aquest clúster. I, en segon lloc, aquesta rèplica s'ha d'incloure en el seguiment perquè es pugui traçar clarament. L'operador ja ho configura.
I només després que entri en joc el mateix ClickHouse, és a dir. una altra entitat de nivell superior. Això ja és una base de dades. Té la seva pròpia instància, una altra rèplica configurada que està preparada per unir-se al clúster.
Resulta que una cadena d'execució i divisió de responsabilitat en afegir una rèplica és força llarga.
Continuem amb les nostres tasques pràctiques. Si ja teniu un clúster, podeu migrar la configuració.
Ho hem fet perquè pugueu enganxar-lo directament al xml existent, que ClickHouse entén.
Podeu ajustar ClickHouse. Només el desplegament per zones és del que vaig parlar quan vaig explicar hostPath, emmagatzematge local. Així és com fer correctament el desplegament per zones.
La següent tasca pràctica és el seguiment.
Si el nostre clúster canvia, haurem de configurar el monitoratge periòdicament.
Mirem el diagrama. Ja hem mirat les fletxes verdes aquí. Ara mirem les fletxes vermelles. Així és com volem controlar el nostre clúster. Com les mètriques del clúster ClickHouse arriben a Prometheus i després a Grafana.
Quina és la dificultat del seguiment? Per què es presenta això com una mena d'assoliment? La dificultat rau en la dinàmica. Quan tenim un clúster i és estàtic, podem configurar la supervisió una vegada i no molestar-nos més.
Però si tenim molts clústers, o alguna cosa està canviant constantment, aleshores el procés és dinàmic. I reconfigurar constantment el seguiment és una pèrdua de recursos i temps, és a dir. fins i tot només mandra. Això s'ha d'automatitzar. La dificultat rau en la dinàmica del procés. I l'operador ho automatitza molt bé.
Com es va desenvolupar el nostre clúster? Al principi era així.
Llavors va ser així.
Al final, es va convertir així.
I la supervisió la fa l'operador automàticament. Punt únic d'entrada.
I just a la sortida mirem el tauler de Grafana per veure com la vida del nostre clúster bull a dins.
Per cert, el quadre de comandament de Grafana també es distribueix amb el nostre operador directament al codi font. Podeu connectar i utilitzar. El nostre DevOps em va donar aquesta captura de pantalla.
On ens agradaria anar a continuació? Això:
- Desenvolupar l'automatització de proves. La tasca principal és la prova automatitzada de noves versions.
- També volem automatitzar la integració amb ZooKeeper. I hi ha plans per integrar-se amb l'operador ZooKeeper. Aquells. S'ha escrit un operador per a ZooKeeper i és lògic que els dos operadors comencin a integrar-se per construir una solució més còmoda.
- Volem fer signes vitals més complexos.
- He destacat en verd que ens estem apropant a l'herència de plantilles - DONE, és a dir, amb la propera versió de l'operador ja tindrem l'herència de plantilles. Aquesta és una eina potent que us permet crear configuracions complexes a partir de peces.
- I volem l'automatització de tasques complexes. El principal és Re-sharding.
Prenem alguns resultats intermedis.
Què obtenim com a resultat? I val la pena fer-ho o no? Fins i tot és necessari intentar arrossegar la base de dades a Kubernetes i utilitzar l'operador en general i l'operador Alitnity en particular?
A la sortida obtenim:
- Simplificació i automatització significativa de la configuració, el desplegament i el manteniment.
- Supervisió immediata integrada.
- I plantilles codificades llestes per utilitzar per a situacions complexes. Una acció com afegir una rèplica no s'ha de fer manualment. L'operador fa això.
Només queda una última pregunta. Ja tenim una base de dades a Kubernetes, virtualització. Què passa amb el rendiment d'aquesta solució, sobretot perquè ClickHouse està optimitzat per al rendiment?
La resposta és que tot està bé! No entraré en detalls; aquest és el tema d'un informe a part.
Però hi ha un projecte com TSBS. Quina és la seva tasca principal? Aquesta és una prova de rendiment de la base de dades. Aquest és un intent de comparar càlid amb càlid, suau amb suau.
Com treballa? Es genera un conjunt de dades. A continuació, aquest conjunt de dades s'executa en diferents bases de dades utilitzant el mateix conjunt de proves. I cada base de dades resol un problema de la manera com sap fer-ho. I després podeu comparar els resultats.
Ja admet un gran munt de bases de dades. N'he identificat tres principals. Això:
- Escala de temps DB.
- InfluxDB.
- ClickHouse.
També es va fer una comparació amb una altra solució similar. Comparació amb RedShift. La comparació es va fer a Amazon. ClickHouse també està molt per davant de tothom en aquesta qüestió.
Quines conclusions es poden extreure del que he dit?
- La base de dades a Kubernetes és possible. Probablement qualsevol és possible, però en general sembla que és possible. ClickHouse a Kubernetes és definitivament possible amb l'ajuda del nostre operador.
- L'operador ajuda a automatitzar els processos i realment facilita la vida.
- El rendiment és normal.
- I ens sembla que això es pot i s'ha d'utilitzar.
Codi obert: uneix-te a nosaltres!
Com ja he dit, l'operador és un producte completament de codi obert, així que estaria molt bé que el nombre màxim de persones l'utilitzessin. Uneix-te a nosaltres! Us esperem a tots!
Gràcies a tots!
Les vostres preguntes
Gràcies pel reportatge! Em dic Anton. Sóc de SEMrush. Em pregunto què passa amb el registre. Sentim parlar de monitorització, però res de registre, si parlem de tot el clúster. Per exemple, hem creat un clúster de maquinari. I fem servir el registre centralitzat, recopilant-los en un munt comú mitjançant mitjans estàndard. I a partir d'aquí obtenim les dades que ens interessen.
Bona pregunta, és a dir, iniciar sessió en una llista de tasques. El nostre operador encara no ho automatitza. Encara està en desenvolupament, el projecte encara és força jove. Entenem la necessitat de registrar. Aquest també és un tema molt important. I probablement no és menys important que el seguiment. Però el primer a la llista per a la implementació va ser el seguiment. Hi haurà registre. Naturalment, intentem automatitzar tots els aspectes de la vida del clúster. Per tant, la resposta és que de moment l'operador, malauradament, no sap com fer-ho, però està en els plànols, ho farem. Si us voleu unir, feu una sol·licitud, si us plau.
Hola! Gràcies pel reportatge! Tinc una pregunta estàndard relacionada amb els volums persistents. Quan creem una configuració amb aquest operador, com determina l'operador en quin node tenim un disc o una carpeta en concret? Primer hem d'explicar-li que si us plau, col·loqueu el nostre ClickHouse en aquests nodes que tenen disc?
Pel que tinc entès, aquesta pregunta és una continuació de l'emmagatzematge local, especialment la part hostPath. Això és com explicar a tot el sistema que el pod s'ha de llançar en tal o tal node, al qual tenim un disc connectat físicament, que està muntat per tal camí. Aquest és tot un apartat que he tocat molt superficialment perquè la resposta allà és força àmplia.
Breument es veu així. Naturalment, hem de subministrar aquests volums. De moment, no hi ha cap disposició dinàmica a l'emmagatzematge local, de manera que DevOps ha de tallar els propis discs, aquests volums. I han d'explicar l'aprovisionament de Kubernetes que tindreu volums persistents de tal o tal classe, que es troben a tal o tal nodes. Aleshores, haureu d'explicar a Kubernetes que els pods que requereixen tal o tal classe d'emmagatzematge local només s'han de dirigir a tal o tal nodes mitjançant etiquetes. Amb aquests propòsits, l'operador té la capacitat d'assignar algun tipus d'etiqueta i una per instància d'amfitrió. I resulta que Kubernetes encaminarà els pods per executar-se només en nodes que compleixin els requisits, les etiquetes, en termes senzills. Els administradors assignen etiquetes i proveïxen els discos manualment. I després escala.
I és la tercera opció, local, que ajuda a fer-ho una mica més fàcil. Com ja he subratllat, es tracta d'un treball minuciós d'afinació, que en última instància ajuda a obtenir el màxim rendiment.
Tinc una segona pregunta relacionada amb això. Kubernetes es va dissenyar de tal manera que no ens importa si perdem un node o no. Què hem de fer en aquest cas si hem perdut el node on penja el nostre fragment?
Sí, Kubernetes es va posicionar inicialment que la nostra relació amb les nostres beines és com el bestiar, però aquí amb nosaltres cada disc es converteix en una cosa com una mascota. Hi ha un problema tal que no podem simplement llençar-los. I el desenvolupament de Kubernetes va en la direcció que és impossible tractar-lo completament filosòficament, com si fos un recurs completament rebutjat.
Ara per una pregunta pràctica. Què fer si heu perdut el node on es trobava el disc? Aquí el problema es resol a un nivell superior. En el cas de ClickHouse, tenim rèpliques que funcionen a un nivell superior, és a dir. al nivell de ClickHouse.
Quina és la disposició resultant? DevOps és responsable de garantir que les dades no es perdin. Ha de configurar correctament la rèplica i s'ha d'assegurar que la rèplica s'està executant. La rèplica a nivell de ClickHouse ha de tenir dades duplicades. Aquest no és el problema que resol l'operador. I no el problema que soluciona el mateix Kubernetes. Això és al nivell de ClickHouse.
Què fer si el vostre node de ferro cau? I resulta que n'haureu d'instal·lar-ne un segon, proveir-hi correctament el disc i aplicar-hi etiquetes. I després d'això, complirà els requisits perquè Kubernetes pugui llançar-hi un pod d'instància. Kubernetes el llançarà. El vostre nombre de beines no és suficient per assolir el nombre especificat. Passarà pel cicle que vaig mostrar. I al més alt nivell, ClickHouse entendrà que hem introduït una rèplica, que encara està buida i hem de començar a transferir-hi dades. Aquells. Aquest procés encara no està ben automatitzat.
Gràcies pel reportatge! Quan passen tota mena de coses desagradables, l'operador es bloqueja i es reinicia, i en aquest moment arriben els esdeveniments, ho gestiones d'alguna manera?
Què passa si l'operador s'estavella i es reinicia, oi?
Sí. I en aquell moment van arribar els esdeveniments.
La tasca de què fer en aquest cas es comparteix en part entre l'operador i Kubernetes. Kubernetes té la capacitat de reproduir un esdeveniment que s'ha produït. Ell repeteix. I la tasca de l'operador és assegurar-se que quan es reprodueix el registre d'esdeveniments, aquests esdeveniments són idempotents. I perquè la repetició d'un mateix esdeveniment no trenqui el nostre sistema. I el nostre operador s'encarrega d'aquesta tasca.
Hola! Gràcies pel reportatge! Dmitry Zavyalov, companyia Smedova. Hi ha plans per afegir la possibilitat de configurar amb haproxy a l'operador? M'interessaria algun altre equilibrador a més de l'estàndard, perquè sigui intel·ligent i entengui que ClickHouse hi és realment.
Esteu parlant d'Ingress?
Sí, substituïu Ingress per haproxy. A haproxy podeu especificar la topologia del clúster on té rèpliques.
Encara no ho hem pensat. Si el necessiteu i podeu explicar per què és necessari, llavors serà possible implementar-lo, sobretot si voleu participar. Estarem encantats de considerar l'opció. La resposta breu és no, actualment no tenim aquesta funcionalitat. Gràcies pel consell, estudiarem aquest tema. I si també expliqueu el cas d'ús i per què es necessita a la pràctica, per exemple, creeu problemes a GitHub, serà fantàstic.
Ja té.
Bé. Estem oberts a qualsevol suggeriment. I haproxy s'afegeix a la llista de tasques. La llista de tasques està creixent, encara no es redueix. Però això és bo, vol dir que el producte té demanda.
Font: www.habr.com