O informe está dedicado a cuestións prácticas de desenvolvemento dun operador en Kubernetes, deseño da súa arquitectura e principios básicos de funcionamento.
Na primeira parte do informe teremos en conta:
- que é un operador en Kubernetes e por que é necesario;
- como o operador simplifica exactamente a xestión de sistemas complexos;
- o que o operador pode e non pode facer.
A continuación, pasemos a discutir a estrutura interna do operador. Vexamos paso a paso a arquitectura e o funcionamento do operador. Vexámolo en detalle:
- interacción entre o operador e Kubernetes;
- que funcións asume o operador e que funcións delega en Kubernetes.
Vexamos a xestión de fragmentos e réplicas de bases de datos en Kubernetes.
A continuación, discutiremos problemas de almacenamento de datos:
- como traballar con Persistent Storage desde o punto de vista dun operador;
- trampas de usar o almacenamento local.
Na parte final do informe, consideraremos exemplos prácticos de aplicación con Amazon ou Google Cloud Service. O informe baséase no exemplo da experiencia de desenvolvemento e operación dun operador de ClickHouse.
Vídeo:
Chámome Vladislav Klimenko. Hoxe quería falar da nosa experiencia no desenvolvemento e explotación dun operador, e este é un operador especializado na xestión de clústeres de bases de datos. Por exemplo para xestionar o clúster ClickHouse.
Por que temos a oportunidade de falar do operador e de ClickHouse?
- Apoiamos e desenvolvemos ClickHouse.
- Polo momento, estamos tentando contribuír aos poucos ao desenvolvemento de ClickHouse. E somos segundos despois de Yandex en canto ao volume de cambios realizados en ClickHouse.
- Estamos tentando facer proxectos adicionais para o ecosistema ClickHouse.
Gustaríame falarvos dun destes proxectos. Trátase do operador ClickHouse para Kubernetes.
No meu informe gustaríame tocar dous temas:
- O primeiro tema é como funciona o noso operador de xestión de bases de datos ClickHouse en Kubernetes.
- O segundo tema é como funciona calquera operador, é dicir, como interactúa con Kubernetes.
Non obstante, estas dúas preguntas cruzaranse ao longo do meu informe.
Quen estaría interesado en escoitar o que estou tentando contar?
- Será de maior interese para aqueles que operan operadores.
- Ou para aqueles que queiran facer o seu propio para entender como funciona internamente, como interactúa o operador con Kubernetes e que trampas poden aparecer.
Para comprender mellor o que falaremos hoxe, é unha boa idea coñecer como funciona Kubernetes e ter un adestramento básico na nube.
Que é ClickHouse? Esta é unha base de datos en columnas con características específicas para o procesamento en liña de consultas analíticas. E é completamente de código aberto.
E é importante que só saibamos dúas cousas. Debes saber que esta é unha base de datos, polo que o que che vou dicir será aplicable a case calquera base de datos. E o feito de que o DBMS ClickHouse escala moi ben, dá unha escalabilidade case lineal. E polo tanto, o estado do clúster é un estado natural para ClickHouse. E estamos máis interesados en discutir como servir o clúster ClickHouse en Kubernetes.
Por que é necesario alí? Por que non podemos seguir operando nós mesmos? E as respostas son en parte técnicas e en parte organizativas.
- Na práctica, cada vez atopámonos máis cunha situación na que nas grandes empresas case todos os compoñentes xa están en Kubernetes. As bases de datos permanecen fóra.
- E a pregunta faise cada vez máis: "¿Pódese colocar isto dentro?" Por iso, as grandes empresas tratan de lograr a máxima unificación da xestión para poder xestionar rapidamente os seus almacéns de datos.
- E isto axuda especialmente se necesitas a máxima oportunidade de repetir o mesmo nun lugar novo, é dicir, a máxima portabilidade.
Que fácil ou difícil é? Isto, por suposto, pódese facer a man. Pero non é tan sinxelo, porque temos a complexidade engadida de xestionar o propio Kubernetes, pero ao mesmo tempo se superpoñen as especificidades de ClickHouse. E tal agregación resulta.
E todo isto dá un conxunto bastante grande de tecnoloxías, que se fai bastante difícil de xestionar, porque Kubernetes trae os seus propios problemas cotiáns ao funcionamento e ClickHouse trae os seus propios problemas ao funcionamento diario. Especialmente se temos varias ClickHouses e necesitamos facer algo constantemente con elas.
Cunha configuración dinámica, ClickHouse ten un número bastante grande de problemas que crean unha carga constante en DevOps:
- Cando queremos cambiar algo en ClickHouse, por exemplo, engadir unha réplica ou fragmento, entón necesitamos xestionar a configuración.
- A continuación, cambie o esquema de datos, porque ClickHouse ten un método de fragmentación específico. Alí cómpre establecer o diagrama de datos, establecer as configuracións.
- Debe configurar a vixilancia.
- Recopilación de rexistros para novos fragmentos, para novas réplicas.
- Coida a restauración.
- E reinicia.
Estas son tarefas rutineiras que realmente me gustaría facer máis fáciles de usar.
O propio Kubernetes axuda ben no funcionamento, pero nas cousas básicas do sistema.
Kubernetes é bo para facilitar e automatizar cousas como:
- Recuperación.
- Reiniciar.
- Xestión do sistema de almacenamento.
Iso é bo, esa é a dirección correcta, pero non ten idea de como operar un clúster de bases de datos.
Queremos máis, queremos que toda a base de datos funcione en Kubernetes.
Gustaríame conseguir algo así como un botón vermello máxico grande que premes e que se despregue e manteña un clúster con tarefas cotiás que hai que resolver durante todo o seu ciclo de vida. Clúster ClickHouse en Kubernetes.
E tentamos dar unha solución que axude a facilitar o traballo. Este é un operador ClickHouse para Kubernetes de Altinity.
Un operador é un programa cuxa tarefa principal é xestionar outros programas, é dicir, é un xestor.
E contén patróns de comportamento. Podes chamar a este coñecemento codificado sobre a área temática.
E a súa principal tarefa é facilitar a vida de DevOps e reducir a microxestión, para que el (DevOps) xa pense en termos de alto nivel, é dicir, para que el (DevOps) non se dedique á microxestión, para que non configure todos os detalles manualmente.
E só o operador é un asistente robótico que se ocupa de microtarefas e axuda a DevOps.
Por que necesitas un operador? Ten un bo desempeño en dúas áreas:
- Cando o especialista que se ocupa de ClickHouse non ten experiencia suficiente, pero xa precisa operar ClickHouse, o operador facilita a operación e permite operar un clúster de ClickHouse cunha configuración bastante complexa, sen entrar en demasiados detalles sobre como funciona todo. dentro. Só lle dás tarefas de alto nivel e funciona.
- E a segunda tarefa na que mellor se realiza é cando é necesario automatizar un gran número de tarefas típicas. Elimina microtarefas dos administradores do sistema.
Isto é o máis necesario tanto para aqueles que están comezando a súa viaxe, como para aqueles que precisan facer moita automatización.
En que se diferencia o enfoque baseado en operadores doutros sistemas? Hai Helm. Tamén axuda a instalar ClickHouse; podes debuxar gráficos de timón, que incluso instalarán un clúster de ClickHouse completo. Cal é entón a diferenza entre o operador e o mesmo, por exemplo, Helm?
A principal diferenza fundamental é que Helm é a xestión de paquetes e Operator vai un paso máis aló. Este é o apoio para todo o ciclo de vida. Esta non é só a instalación, son tarefas cotiás que inclúen a escala, a fragmentación, é dicir, todo o que hai que facer durante o ciclo de vida (se é necesario, despois tamén a eliminación) - todo isto o decide o operador. Intenta automatizar e manter todo o ciclo de vida do software. Esta é a súa diferenza fundamental con outras solucións que se presentan.
Esa foi a parte introdutoria, imos adiante.
Como construímos o noso operador? Estamos tentando abordar o problema para xestionar o clúster ClickHouse como un único recurso.
Aquí temos os datos de entrada no lado esquerdo da imaxe. Trátase de YAML cunha especificación de clúster, que se pasa a Kubernetes da forma clásica a través de kubectl. Alí o noso operador cólleo e fai a súa maxia. E na saída obtemos o seguinte esquema. Esta é unha implementación de ClickHouse en Kubernetes.
E despois veremos aos poucos como funciona exactamente o operador, que tarefas típicas se poden resolver. Só teremos en conta as tarefas típicas porque temos tempo limitado. E non se discutirá todo o que poida decidir o operador.
Comecemos pola práctica. O noso proxecto é completamente de código aberto, polo que podes ver como funciona en GitHub. E podes partir das consideracións de que se só queres lanzalo, podes comezar coa Guía de inicio rápido.
Se queres entender en detalle, tratamos de manter a documentación nunha forma máis ou menos decente.
Comecemos cun problema práctico. A primeira tarefa, onde todos queremos comezar, é executar o primeiro exemplo dalgún xeito. Como podo iniciar ClickHouse usando o operador, aínda que non sei realmente como funciona? Estamos escribindo un manifesto, porque... Toda comunicación con k8s é comunicación a través de manifestos.
Este é un manifesto tan complexo. O que destacamos en vermello é no que debemos centrarnos. Pedimos ao operador que cree un clúster chamado demo.
Estes son exemplos básicos polo momento. Aínda non se describiu o almacenamento, pero volveremos ao almacenamento un pouco máis tarde. De momento, observaremos a dinámica do desenvolvemento do clúster.
Creamos este manifesto. Aliméntámolo ao noso operador. Traballaba, facía maxia.
Miramos a consola. Tres compoñentes son de interese: un Pod, dous Servizos e un StatefulSet.
O operador traballou, e podemos ver o que creou exactamente.
El crea algo así. Temos un StatefulSet, Pod, ConfigMap para cada réplica, ConfigMap para todo o clúster. Os servizos son necesarios como puntos de entrada ao clúster.
Os servizos son o servizo central de equilibrador de carga e tamén se poden usar para cada réplica, para cada fragmento.
O noso clúster básico parece algo así. É dun só nodo.
Imos máis alá e complicamos as cousas. Necesitamos fragmentar o clúster.
As nosas tarefas medran, comezan as dinámicas. Queremos engadir un fragmento. Seguimos o desenvolvemento. Estamos cambiando a nosa especificación. Indicamos que queremos dous fragmentos.
Este é o mesmo ficheiro que se desenvolve dinámicamente co crecemento do sistema. Almacenamento non, o almacenamento será discutido máis adiante, este é un tema separado.
Alimentamos o operador YAML e vemos que pasa.
O operador pensou e fixo as seguintes entidades. Xa temos dous Pods, tres Servizos e, de súpeto, 2 StatefulSets. Por que 2 StatefulSets?
No diagrama era así: este é o noso estado inicial, cando tiñamos unha vaina.
Fíxose así. Ata agora todo é sinxelo, duplicouse.
E por que se converteron en dous StatefulSets? Aquí temos que divagar e discutir a cuestión de como se xestionan os Pods en Kubernetes.
Hai un obxecto chamado StatefulSet que che permite crear un conxunto de Pods a partir dun modelo. O factor clave aquí é o modelo. E podes lanzar moitos Pods usando un modelo nun StatefulSet. E a frase clave aquí é "moitos Pods para un modelo".
E houbo unha gran tentación de facer todo o clúster, embalándoo nun StatefulSet. Funcionará, non hai ningún problema. Pero hai unha advertencia. Se queremos montar un clúster heteroxéneo, é dicir, a partir de varias versións de ClickHouse, comezan a xurdir dúbidas. Si, StatefulSet pode facer unha actualización continua e alí podes lanzar unha nova versión, explicando que non necesitas probar máis de tantos nodos ao mesmo tempo.
Pero se extrapolamos a tarefa e dicimos que queremos facer un clúster completamente heteroxéneo e non queremos cambiar da versión antiga a outra nova mediante unha actualización continua, senón que simplemente queremos crear un clúster heteroxéneo tanto en termos. de diferentes versións de ClickHouse e en termos de almacenamento diferente. Queremos, por exemplo, facer algunhas réplicas en discos separados, en discos lentos, en xeral, para construír completamente un clúster heteroxéneo. E debido ao feito de que StatefulSet fai unha solución estandarizada a partir dun modelo, non hai forma de facelo.
Despois de pensar un pouco, decidiuse que o fariamos deste xeito. Temos cada réplica no seu propio StatefulSet. Esta solución ten algúns inconvenientes, pero na práctica está todo completamente encapsulado polo operador. E hai moitas vantaxes. Podemos construír o clúster exacto que queremos, por exemplo, un absolutamente heteroxéneo. Polo tanto, nun clúster no que dispoñemos de dous fragmentos cunha réplica, teremos 2 StatefulSets e 2 Pods precisamente porque escollemos este enfoque polas razóns expostas anteriormente para poder construír un clúster heteroxéneo.
Volvamos aos problemas prácticos. No noso clúster necesitamos configurar usuarios, é dicir. necesitas facer algunha configuración de ClickHouse en Kubernetes. O operador ofrece todas as posibilidades para iso.
Podemos escribir o que queiramos directamente en YAML. Todas as opcións de configuración son asignadas directamente desde este YAML ás configuracións de ClickHouse, que despois se distribúen por todo o clúster.
Podes escribilo así. Isto é por exemplo. O contrasinal pódese cifrar. Absolutamente todas as opcións de configuración de ClickHouse son compatibles. Aquí tes só un exemplo.
A configuración do clúster distribúese como un ConfigMap. Na práctica, a actualización de ConfigMap non se produce ao instante, polo que se o clúster é grande, o proceso de impulsar a configuración leva algún tempo. Pero todo isto é moi cómodo de usar.
Imos complicar a tarefa. O clúster está a desenvolverse. Queremos replicar datos. É dicir, xa temos dous fragmentos, unha réplica cada un, e os usuarios están configurados. Estamos crecendo e queremos facer a réplica.
Que necesitamos para replicar?
Necesitamos ZooKeeper. En ClickHouse, a replicación realízase mediante ZooKeeper. Necesítase ZooKeeper para que as diferentes réplicas de ClickHouse teñan un consenso sobre os bloques de datos en que ClickHouse.
ZooKeeper pode ser usado por calquera. Se a empresa ten un ZooKeeper externo, pódese usar. Se non, podes instalalo desde o noso repositorio. Hai un instalador que facilita todo isto.
E o diagrama de interacción de todo o sistema resulta así. Temos Kubernetes como plataforma. Executa o operador ClickHouse. Imaxinei a ZooKeeper aquí. E o operador interactúa tanto con ClickHouse como con ZooKeeper. É dicir, os resultados da interacción.
E todo isto é necesario para que ClickHouse replique con éxito os datos en k8s.
Vexamos agora a tarefa en si, como será o manifesto para a replicación.
Estamos engadindo dúas seccións ao noso manifesto. O primeiro é onde conseguir ZooKeeper, que pode estar dentro de Kubernetes ou externo. Esta é só unha descrición. E pedimos réplicas. Eses. queremos dúas réplicas. En total, deberíamos ter 4 vainas na saída. Lembramos sobre o almacenamento, volverá un pouco máis tarde. O almacenamento é unha historia separada.
Foi así.
Vólvese así. Engádense réplicas. O de 4o non cabía, cremos que alí poderían haber moitos. E ZooKeeper engádese ao lado. Os esquemas son cada vez máis complexos.
E é hora de engadir a seguinte tarefa. Engadiremos o almacenamento persistente.
Para o almacenamento persistente temos varias opcións.
Se estamos executando nun provedor de nube, por exemplo, usando Amazon, Google, entón hai unha gran tentación de usar o almacenamento na nube. É moi cómodo, é bo.
E hai unha segunda opción. Isto é para o almacenamento local, cando temos discos locais en cada nodo. Esta opción é moito máis difícil de implementar, pero ao mesmo tempo é máis produtiva.
Vexamos o que temos sobre o almacenamento na nube.
Hai vantaxes. É moi doado de configurar. Simplemente pedimos ao provedor da nube que nos dea almacenamento de tal ou cal capacidade, de tal ou cal clase. As clases son programadas por provedores de forma independente.
E hai un inconveniente. Para algúns, este é un inconveniente non crítico. Por suposto, haberá algúns problemas de rendemento. É moi cómodo de usar e fiable, pero hai algúns inconvenientes potenciais de rendemento.
E porque ClickHouse céntrase especificamente na produtividade, ata pódese dicir que espreme todo o que pode, polo que moitos clientes intentan espremer a máxima produtividade.
E para sacarlle o máximo proveito, necesitamos almacenamento local.
Kubernetes ofrece tres abstraccións para usar o almacenamento local en Kubernetes. Isto:
- EmptyDir
- HostPath.
- Local
Vexamos en que se diferencian e en que se parecen.
En primeiro lugar, nos tres enfoques temos almacenamento: estes son discos locais que están situados no mesmo nodo físico k8s. Pero teñen algunhas diferenzas.
Comecemos polo máis sinxelo, é dicir, emptyDir. Que é isto na práctica? Na nosa especificación, pedímoslle ao sistema de contenedores (a maioría das veces Docker) que nos proporcione acceso a un cartafol do disco local.
Na práctica, Docker crea un cartafol temporal nalgún lugar ao longo dos seus propios camiños e chámao un hash longo. E ofrece unha interface para acceder a ela.
Como funcionará isto en canto ao rendemento? Isto funcionará á velocidade do disco local, é dicir. Este é o acceso total ao teu parafuso.
Pero este caso ten o seu inconveniente. Persistente é bastante dubidoso neste asunto. A primeira vez que Docker se move con contedores, Persistente pérdese. Se Kubernetes quere mover este Pod a outro disco por algún motivo, perderanse os datos.
Este enfoque é bo para probas, porque xa mostra a velocidade normal, pero para algo serio esta opción non é adecuada.
Polo tanto, hai un segundo enfoque. Este é hostPath. Se miras a diapositiva anterior e esta, só podes ver unha diferenza. O noso cartafol moveuse de Docker directamente ao nodo de Kubernetes. Aquí é un pouco máis sinxelo. Especificamos directamente a ruta do sistema de ficheiros local onde queremos almacenar os nosos datos.
Este método ten vantaxes. Este xa é un Auténtico Persistente, e un clásico. Teremos datos gravados no disco nalgún enderezo.
Tamén hai desvantaxes. Esta é a complexidade da xestión. O noso Kubernetes pode querer mover o Pod a outro nodo físico. E aquí é onde DevOps entra en xogo. Debe explicar correctamente a todo o sistema que estas vainas só se poden mover a aqueles nodos nos que tes algo montado ao longo destes camiños, e non máis dun nodo á vez. É bastante difícil.
Especialmente para estes efectos, fixemos modelos no noso operador co fin de ocultar toda esta complexidade. E podes dicir simplemente: "Quero ter unha instancia de ClickHouse para cada nodo físico e por tal camiño".
Pero non somos os únicos que precisamos desta necesidade, polo que os propios señores de Kubernetes tamén entenden que a xente quere ter acceso a discos físicos, polo que proporcionan unha terceira capa.
Chámase local. Non hai practicamente ningunha diferenza coa diapositiva anterior. Só antes era necesario confirmar manualmente que non podemos transferir estes pods de nodo a nodo, porque deben estar conectados por algún camiño a un disco físico local, pero agora todo este coñecemento está encapsulado no propio Kubernetes. E resulta que é moito máis doado de configurar.
Volvamos ao noso problema práctico. Volvamos ao modelo YAML. Aquí temos almacenamento real. Voltamos. Establecemos o modelo clásico de VolumeClaim como en k8s. E describimos que tipo de almacenamento queremos.
Despois diso, k8s solicitará almacenamento. Asignaranos no StatefulSet. E ao final estará a disposición de ClickHouse.
Tiñamos este esquema. O noso almacenamento persistente era vermello, o que parecía indicar que había que facelo.
E vólvese verde. Agora o esquema de clúster ClickHouse en k8s está completamente finalizado. Temos fragmentos, réplicas, ZooKeeper, temos un Auténtico Persistente, que se implementa dun xeito ou doutro. O esquema xa está totalmente operativo.
Seguimos vivindo. O noso cluster está a desenvolverse. E Alexey intenta e lanza unha nova versión de ClickHouse.
Xorde unha tarefa práctica: probar a nova versión de ClickHouse no noso clúster. E, naturalmente, non quere lanzar todo; quere poñer unha nova versión nunha réplica nalgún lugar do recuncho máis afastado, e quizais non unha nova versión, senón dúas á vez, porque saen a miúdo.
Que podemos dicir sobre isto?
Aquí temos esa oportunidade. Estes son modelos de pod. Podes escribir que o noso operador permítelle por completo construír un clúster heteroxéneo. Eses. configurar, comezando por todas as réplicas nun grupo, rematando con cada réplica persoal, que versión queremos ClickHouse, que versión queremos almacenamento. Podemos configurar completamente o clúster coa configuración que necesitemos.
Afondemos un pouco máis dentro. Antes disto, falamos sobre como funciona o operador ClickHouse en relación coas características específicas de ClickHouse.
Agora gustaríame dicir algunhas palabras sobre como funciona calquera operador en xeral, así como sobre como interactúa cos K8.
Vexamos primeiro interactuar cos K8. Que pasa cando aplicamos kubectl? Os nosos obxectos aparecen en etcd a través da API.
Por exemplo, obxectos básicos de Kubernetes: pod, StatefulSet, service, etc. na lista.
Ao mesmo tempo, aínda non ocorre nada físico. Estes obxectos deben materializarse no clúster.
Para este fin, aparece un controlador. O controlador é un compoñente especial k8s que pode materializar estas descricións. El sabe como e que facer fisicamente. Sabe como executar contedores, o que hai que configurar alí para que o servidor funcione.
E materializa os nosos obxectos en K8.
Pero queremos operar non só con pods e StatefulSets, queremos crear unha ClickHouseInstallation, é dicir, un obxecto do tipo ClickHouse, para poder operar con el como un todo único. Polo de agora non existe tal posibilidade.
Pero K8s ten a seguinte cousa agradable. Queremos que teñamos un lugar como esta complexa entidade no que o noso clúster se reúna a partir de pods e StatefulSet.
E que hai que facer para iso? En primeiro lugar, aparece a definición personalizada de recursos. Que é? Esta é unha descrición para K8s, que terá un tipo de datos máis, que queremos engadir un recurso personalizado ao pod, StatefulSet, que será complexo no interior. Esta é unha descrición da estrutura de datos.
Tamén o enviamos alí a través de kubectl apply. Kubernetes levouno feliz.
E agora no noso almacenamento, o obxecto en etcd ten a oportunidade de gravar un recurso personalizado chamado ClickHouseInstallation.
Pero de momento non pasará nada máis. É dicir, se agora creamos o ficheiro YAML que analizamos describindo fragmentos e réplicas e dicimos "aplícase kubectl", entón Kubernetes aceptarao, colocarao en etcd e dirá: "Xenial, pero non sei que facer. con. Non sei como manter ClickHouseInstallation".
En consecuencia, necesitamos alguén que axude a Kubernetes a ofrecer o novo tipo de datos. Á esquerda temos un controlador Kubernetes nativo que funciona con tipos de datos nativos. E á dereita deberíamos ter un controlador personalizado que poida funcionar con tipos de datos personalizados.
E doutro xeito chámase operador. Incluíno especificamente aquí como Kubernetes, porque tamén se pode executar fóra de K8. Na maioría das veces, por suposto, todos os operadores execútanse en Kubernetes, pero nada impide que estea fóra, polo que aquí móvese especialmente fóra.
E á súa vez, o controlador personalizado, tamén coñecido como operador, interactúa con Kubernetes a través da API. Xa sabe como interactuar coa API. E xa sabe materializar o complexo circuíto que queremos facer a partir dun recurso personalizado. Isto é exactamente o que fai o operador.
Como traballa o operador? Vexamos o lado dereito para ver como o fai. Descubramos como o operador materializa todo isto e como se produce unha maior interacción con K8.
Un operador é un programa. Está orientada aos eventos. O operador subscríbese aos eventos mediante a API de Kubernetes. A API de Kubernetes ten puntos de entrada onde podes subscribirte a eventos. E se algo cambia en K8s, entón Kubernetes envía eventos a todos, é dicir. quen estea subscrito a este punto API recibirá notificacións.
O operador subscríbese aos eventos e debe facer algún tipo de reacción. A súa tarefa é responder aos acontecementos emerxentes.
Os eventos son xerados por certas actualizacións. Chega o noso ficheiro YAML cunha descrición de ClickHouseInstallation. Foi a etcd a través de kubectl apply. Alí desencadeouse un evento e, como resultado, este evento chegou ao operador ClickHouse. O operador recibiu esta descrición. E debe facer algo. Se chegou unha actualización para o obxecto ClickHouseInstallation, cómpre actualizar o clúster. E a tarefa do operador é actualizar o clúster.
Que está facendo? En primeiro lugar, temos que elaborar un plan de acción sobre o que faremos con esta actualización. As actualizacións poden ser moi pequenas, é dicir. pequena na execución de YAML, pero pode implicar cambios moi grandes no clúster. Polo tanto, o operador crea un plan e, a continuación, cómpre a el.
Segundo este plan, comeza a cociñar esta estrutura no seu interior para materializar vainas, servizos, i.e. facer o que é a súa tarefa principal. Así é como crear un clúster ClickHouse en Kubernetes.
Agora imos tocar unha cousa tan interesante. Trátase dunha división de responsabilidade entre Kubernetes e o operador, é dicir. que fai Kubernetes, que fai o operador e como interactúan entre eles.
Kubernetes é responsable das cousas do sistema, é dicir. para un conxunto básico de obxectos que se poden interpretar como ámbito de sistema. Kubernetes sabe como lanzar pods, como reiniciar contedores, como montar volumes, como traballar con ConfigMap, é dicir. todo o que se pode chamar sistema.
Os operadores operan en dominios. Cada operador está feito para a súa propia área temática. Fixémolo para ClickHouse.
E o operador interactúa precisamente en canto á área temática, como engadir unha réplica, facer un diagrama, configurar o seguimento. Isto dá lugar a unha división.
Vexamos un exemplo práctico de como se produce esta división de responsabilidade cando facemos a acción de engadir réplica.
O operador recibe unha tarefa: engadir unha réplica. Que fai o operador? O operador calculará que é necesario crear un novo StatefulSet, no que tales modelos, reclamación de volume, deben ser descritos.
Preparouno todo e pásao aos K8. El di que necesita ConfigMap, StatefulSet, Volume. Kubernetes está funcionando. Materializa as unidades básicas coas que opera.
E entón ClickHouse-operator entra en xogo de novo. Xa ten unha vaina física na que xa pode facer algo. E ClickHouse-operator volve traballar en termos de dominio. Eses. En concreto, ClickHouse, para incluír unha réplica nun clúster, primeiro debes configurar o esquema de datos que existe neste clúster. E, en segundo lugar, esta réplica debe incluírse no seguimento para que se poida rastrexar con claridade. O operador xa o configura.
E só despois de que o propio ClickHouse entre en xogo, é dicir. outra entidade de nivel superior. Esta xa é unha base de datos. Ten a súa propia instancia, outra réplica configurada que está lista para unirse ao clúster.
Resulta que unha cadea de execución e división de responsabilidade ao engadir unha réplica é bastante longa.
Continuamos coas nosas tarefas prácticas. Se xa tes un clúster, podes migrar a configuración.
Fixémolo para que poidas pegar directamente no xml existente, que ClickHouse entende.
Podes afinar ClickHouse. Só o despregamento por zonas é do que falei ao explicar hostPath, o almacenamento local. Así é como facer a implantación por zonas correctamente.
A seguinte tarefa práctica é o seguimento.
Se o noso clúster cambia, necesitamos configurar periodicamente a monitorización.
Vexamos o diagrama. Xa miramos aquí as frechas verdes. Agora vexamos as frechas vermellas. Así é como queremos supervisar o noso clúster. Como as métricas do clúster ClickHouse entran en Prometheus e despois en Grafana.
Cal é a dificultade do seguimento? Por que se presenta isto como algún tipo de logro? A dificultade está na dinámica. Cando temos un clúster e é estático, podemos configurar a supervisión unha vez e non preocuparnos máis.
Pero se temos moitos clústeres, ou algo está a cambiar constantemente, entón o proceso é dinámico. E reconfigurar constantemente o seguimento é unha perda de recursos e tempo, é dicir. incluso só preguiza. Isto debe ser automatizado. A dificultade reside na dinámica do proceso. E o operador automatiza isto moi ben.
Como se desenvolveu o noso cluster? Ao principio era así.
Entón estaba así.
Ao final, volveuse así.
E o control realízao automaticamente o operador. Punto único de entrada.
E xusto á saída miramos o cadro de mando de Grafana para ver como a vida do noso clúster está a ferver dentro.
Por certo, o panel de Grafana tamén se distribúe co noso operador directamente no código fonte. Podes conectar e usar. O noso DevOps deume esta captura de pantalla.
A onde nos gustaría ir a continuación? Isto:
- Desenvolver a automatización de probas. A tarefa principal é a proba automatizada de novas versións.
- Tamén queremos automatizar a integración con ZooKeeper. E hai plans para integrarse co operador ZooKeeper. Eses. Escribiuse un operador para ZooKeeper e é lóxico que os dous operadores comecen a integrarse para construír unha solución máis cómoda.
- Queremos facer signos vitais máis complexos.
- Destaquei en verde que estamos achegando a herdanza de modelos - DONE, é dicir, coa próxima versión do operador xa teremos herdanza de modelos. Esta é unha poderosa ferramenta que che permite crear configuracións complexas a partir de pezas.
- E queremos automatización de tarefas complexas. O principal é Re-sharding.
Tomemos algúns resultados intermedios.
Que obtemos como resultado? E paga a pena facelo ou non? Sequera é necesario tentar arrastrar a base de datos a Kubernetes e usar o operador en xeral e o operador Alitnity en particular?
Na saída obtemos:
- Simplificación e automatización significativas da configuración, implantación e mantemento.
- Monitorización integrada inmediatamente.
- E modelos codificados listos para usar para situacións complexas. Non é necesario facer unha acción como engadir unha réplica manualmente. O operador fai isto.
Só queda unha última pregunta. Xa temos unha base de datos en Kubernetes, virtualización. Que pasa co rendemento desta solución, especialmente porque ClickHouse está optimizado para o rendemento?
A resposta é que todo está ben! Non vou entrar en detalles; este é o tema dun informe separado.
Pero hai un proxecto como TSBS. Cal é a súa tarefa principal? Esta é unha proba de rendemento da base de datos. Este é un intento de comparar cálido con cálido, suave con suave.
Como traballa? Xérase un conxunto de datos. A continuación, este conxunto de datos execútase en diferentes bases de datos utilizando o mesmo conxunto de probas. E cada base de datos resolve un problema do xeito que sabe facer. E entón podes comparar os resultados.
Xa admite unha gran cantidade de bases de datos. Identifiquei tres principais. Isto:
- TimecaleDB.
- InfluxDB.
- ClickHouse.
Tamén se fixo unha comparación con outra solución similar. Comparación con RedShift. A comparación foi feita en Amazon. ClickHouse tamén está moi por diante de todos neste asunto.
Que conclusións se poden sacar do que dixen?
- DB en Kubernetes é posible. Probablemente calquera sexa posible, pero en xeral parece que é posible. ClickHouse en Kubernetes definitivamente é posible coa axuda do noso operador.
- O operador axuda a automatizar os procesos e realmente facilita a vida.
- O rendemento é normal.
- E parécenos que isto pode e debe ser usado.
Código aberto: únete a nós!
Como xa dixen, a operadora é un produto completamente de código aberto, polo que estaría moi ben que o utilizase o máximo número de persoas. Únete a nós! Agardámosvos a todos!
Grazas a todos!
preguntas
Grazas polo informe! Chámome Antón. Eu son de SEMrush. Pregúntome que pasa co rexistro. Escoitamos falar de monitorización, pero nada de rexistro, se falamos de todo o clúster. Por exemplo, creamos un clúster sobre hardware. E usamos o rexistro centralizado, recompilándoos nun montón común utilizando medios estándar. E despois de aí saímos os datos que nos interesan.
Boa pregunta, é dicir, iniciar sesión nunha lista de tarefas. O noso operador aínda non automatiza isto. Aínda está en desenvolvemento, o proxecto aínda é bastante novo. Entendemos a necesidade de rexistrar. Este tamén é un tema moi importante. E probablemente non sexa menos importante que o seguimento. Pero o primeiro na lista para a implementación foi o seguimento. Haberá rexistro. Por suposto, intentamos automatizar todos os aspectos da vida do clúster. Polo tanto, a resposta é que de momento o operador, por desgraza, non sabe como facelo, pero está nos planos, imos facelo. Se queres unirte, retira a solicitude, por favor.
Ola! Grazas polo informe! Teño unha pregunta estándar relacionada cos volumes persistentes. Cando creamos unha configuración con este operador, como determina o operador en que nodo temos un disco ou cartafol en particular? Primeiro debemos explicarlle que por favor coloque o noso ClickHouse nestes nodos que teñen un disco?
Polo que entendo, esta pregunta é unha continuación do almacenamento local, especialmente a parte hostPath. Isto é como explicarlle a todo o sistema que hai que lanzar o pod en tal ou cal nodo, ao que temos un disco conectado fisicamente, que está montado por tal camiño. Este é todo un apartado que toquei moi superficialmente porque a resposta alí é bastante grande.
Brevemente, parece así. Por suposto, necesitamos proporcionar estes volumes. Polo momento, non hai provisión dinámica no almacenamento local, polo que DevOps debe cortar os propios discos, estes volumes. E deben explicar o aprovisionamento de Kubernetes que terá volumes persistentes de tal ou cal clase, que están situados en tal ou cal nodos. Entón terás que explicarlle a Kubernetes que os pods que requiren tal ou tal clase de almacenamento local só deben dirixirse a tal ou tal nodos mediante etiquetas. Para estes efectos, o operador ten a capacidade de asignar algún tipo de etiqueta e unha por instancia de host. E resulta que Kubernetes encamiñará os pods para que se executen só en nós que cumpran os requisitos, as etiquetas, en termos sinxelos. Os administradores asignan etiquetas e aprovisiona os discos manualmente. E despois escala.
E é a terceira opción, local, que axuda a facilitar isto un pouco. Como xa subliñei, trátase dun traballo minucioso de afinación, que finalmente axuda a obter o máximo rendemento.
Teño unha segunda pregunta relacionada con isto. Kubernetes foi deseñado de tal xeito que non nos importa se perdemos un nodo ou non. Que debemos facer neste caso se perdemos o nodo onde colga o noso fragmento?
Si, Kubernetes estaba inicialmente posicionado de que a nosa relación coas nosas vainas é como o gando, pero aquí con nós cada disco convértese en algo así como unha mascota. Hai tal problema que non podemos simplemente tiralos. E o desenvolvemento de Kubernetes vai na dirección de que é imposible tratalo completamente filosóficamente, coma se fose un recurso completamente descartado.
Agora para unha pregunta práctica. Que facer se perdeu o nodo no que estaba o disco? Aquí o problema estase solucionando a un nivel superior. No caso de ClickHouse, temos réplicas que funcionan a un nivel superior, é dicir. a nivel de ClickHouse.
Cal é a disposición resultante? DevOps é responsable de garantir que os datos non se perdan. Debe configurar a replicación correctamente e debe asegurarse de que a replicación se está a executar. A réplica no nivel de ClickHouse debe ter datos duplicados. Esta non é a tarefa que resolve o operador. E non o problema que soluciona o propio Kubernetes. Isto é no nivel ClickHouse.
Que facer se o teu nó de ferro cae? E resulta que terás que instalar un segundo, aprovisionar correctamente o disco e aplicar etiquetas. E despois diso, cumprirá os requisitos de que Kubernetes poida lanzar un pod de instancia nel. Kubernetes lanzarao. O teu número de pods non é suficiente para cumprir o número especificado. Pasará polo ciclo que mostrei. E no máis alto nivel, ClickHouse entenderá que introducimos unha réplica, aínda está baleira e necesitamos comezar a transferir datos a ela. Eses. Este proceso aínda non está ben automatizado.
Grazas polo informe! Cando suceden todo tipo de cousas desagradables, o operador falla e reinicia e, nese momento, chegan os eventos, xestionas isto dalgún xeito?
Que pasa se o operador falla e reinicia, non?
Si. E nese momento chegaron os acontecementos.
A tarefa de que facer neste caso compártese en parte entre o operador e Kubernetes. Kubernetes ten a capacidade de reproducir un evento que ocorreu. El repite. E a tarefa do operador é asegurarse de que cando se lle reproduce o rexistro de eventos, estes eventos son idempotentes. E para que a repetición do mesmo suceso non rompa o noso sistema. E o noso operador enfróntase a esta tarefa.
Ola! Grazas polo informe! Dmitry Zavyalov, compañía Smedova. Hai plans para engadir ao operador a posibilidade de configurar con haproxy? Estaría interesado nalgún outro equilibrador ademais do estándar, para que sexa intelixente e entenda que ClickHouse está realmente aí.
Estás a falar de Ingress?
Si, substitúe Ingress por haproxy. En haproxy podes especificar a topoloxía do clúster onde ten réplicas.
Aínda non o pensamos. Se o precisa e pode explicar por que é necesario, entón será posible implementalo, especialmente se quere participar. Estaremos encantados de considerar a opción. A resposta curta é non, actualmente non temos esa funcionalidade. Grazas polo consello, investigaremos este asunto. E se tamén explicas o caso de uso e por que é necesario na práctica, por exemplo, crea problemas en GitHub, será xenial.
Xa ten.
Ben. Estamos abertos a calquera suxestión. E haproxy engádese á lista de tarefas. A lista de tarefas está crecendo, aínda non diminuíndo. Pero isto é bo, significa que o produto está en demanda.
Fonte: www.habr.com