Local<\/li>\n<\/ul>\n<\/p>\n
Veamos en qu\u00e9 se diferencian y en qu\u00e9 se parecen. <\/p>\n
<\/p>\n
En primer lugar, en los tres enfoques tenemos almacenamiento: son discos locales que est\u00e1n en el mismo nodo f\u00edsico de k8s. Pero tienen algunas diferencias.<\/p>\n
<\/p>\n
<\/p>\n
Empecemos con lo m\u00e1s simple, es decir, con emptyDir. \u00bfQu\u00e9 es esto en la pr\u00e1ctica? Es cuando pedimos a nuestra especificaci\u00f3n que el sistema de contenedorizaci\u00f3n (la mayor\u00eda de las veces, Docker) nos proporcione acceso a una carpeta en el disco local.<\/p>\n
<\/p>\n
En la pr\u00e1ctica, Docker crea en alg\u00fan lugar de su propio camino una carpeta temporal, la llama con un hash largo y proporciona una interfaz de acceso a ella. <\/p>\n
<\/p>\n
\u00bfC\u00f3mo funcionar\u00e1 esto en t\u00e9rminos de rendimiento? Funcionar\u00e1 a la velocidad del disco local, es decir, hay acceso completo a su disco duro. <\/p>\n
<\/p>\n
Pero esta opci\u00f3n tiene una desventaja. La persistencia en este caso es bastante dudosa. Al primer movimiento de Docker con los contenedores, la persistencia se pierde. Si Kubernetes decidiera por alguna raz\u00f3n mover este Pod a otro disco, los datos se perder\u00edan. <\/p>\n
<\/p>\n
Este enfoque es bueno para pruebas, porque ya muestra una velocidad normal, pero no es adecuado para algo serio. <\/p>\n
<\/p>\n
<\/p>\n
Por eso hay un segundo enfoque. Este es hostPath. Si miras la diapositiva anterior y esta, puedes ver una sola diferencia. Nuestra carpeta ha salido de Docker directamente a la nodo de Kubernetes. Aqu\u00ed es un poco m\u00e1s simple. Simplemente especificamos el camino en el sistema de archivos local donde nos gustar\u00eda almacenar nuestros datos. <\/p>\n
<\/p>\n
Las ventajas de este m\u00e9todo son claras. Es un verdadero almacenamiento persistente, de hecho, cl\u00e1sico. Los datos se registrar\u00e1n en el disco en una direcci\u00f3n espec\u00edfica. <\/p>\n
<\/p>\n
Tambi\u00e9n hay desventajas. La complejidad de gesti\u00f3n. Nuestro Kubernetes puede querer mover un Pod a otro nodo f\u00edsico. Y aqu\u00ed es donde entra en juego DevOps. Debe explicar correctamente a todo el sistema que estos pods solo se pueden mover a nodos en los que tengas algo montado por estos caminos, y no m\u00e1s de un nodo a la vez. Esto es bastante complicado. <\/p>\n
<\/p>\n
Con este prop\u00f3sito, hemos creado plantillas en nuestro operador para ocultar toda esta complejidad. Y podr\u00eda simplemente decir: \"Quiero que tenga una instancia de ClickHouse en cada nodo f\u00edsico y en tal ruta\". <\/p>\n
<\/p>\n
<\/p>\n
Pero esta necesidad no solo nos concierne a nosotros, por lo que los caballeros de Kubernetes tambi\u00e9n comprenden que a la gente le gustar\u00eda tener acceso a discos f\u00edsicos, y por eso proporcionan un tercer nivel.<\/p>\n
<\/p>\n
Se llama local. La diferencia con la diapositiva anterior es pr\u00e1cticamente ninguna. Solo que antes hab\u00eda que realizar manualmente el proceso, que no se pod\u00edan mover estos pods de nodo a nodo porque deb\u00edan estar conectados a un disco f\u00edsico local en una ruta espec\u00edfica, y ahora todo ese conocimiento se encapsula en Kubernetes. Y resulta mucho m\u00e1s f\u00e1cil de configurar.<\/p>\n
<\/p>\n
<\/p>\n
Regresamos a nuestra tarea pr\u00e1ctica. Volvamos a la plantilla YAML. Aqu\u00ed tenemos un almacenamiento real. Hemos regresado a esto. Estamos definiendo un cl\u00e1sico VolumeClaim template como en k8s. Y describimos qu\u00e9 almacenamiento queremos.<\/p>\n
<\/p>\n
Despu\u00e9s de esto, k8s solicitar\u00e1 almacenamiento. Nos lo asignar\u00e1 en StatefulSet. Y al final esto quedar\u00e1 a disposici\u00f3n de ClickHouse.<\/p>\n
<\/p>\n
<\/p>\n
Ten\u00eda un esquema como este. Nuestro Almacenamiento Persistente estaba en rojo, lo que indicaba que deber\u00eda hacerse. <\/p>\n
<\/p>\n
<\/p>\n
Y ahora se vuelve verde. Ahora el esquema del cl\u00faster ClickHouse en k8s est\u00e1 completamente finalizado. Tenemos shards, r\u00e9plicas, ZooKeeper, hay un verdadero Persistente, que se implementa de una forma u otra. El esquema ya es completamente funcional. <\/p>\n
<\/p>\n
<\/p>\n
Seguimos avanzando. Nuestro cl\u00faster est\u00e1 en desarrollo. Y Alexey se esfuerza, lanzando una nueva versi\u00f3n de ClickHouse.<\/p>\n
<\/p>\n
Surge la tarea pr\u00e1ctica: probar la nueva versi\u00f3n de ClickHouse en nuestro cl\u00faster. Y, por supuesto, no queremos implementarla en su totalidad, quisi\u00e9ramos instalar una nueva versi\u00f3n en alg\u00fan rinc\u00f3n lejano, o tal vez no solo una nueva versi\u00f3n, sino dos a la vez, porque salen con frecuencia. <\/p>\n
<\/p>\n
\u00bfQu\u00e9 podemos decir al respecto?<\/p>\n
<\/p>\n
<\/p>\n
Aqu\u00ed tenemos la oportunidad justa. Son plantillas de pod. Se puede detallar, nuestro operador permite construir un cl\u00faster heterog\u00e9neo. Es decir, configurando desde todas las r\u00e9plicas en grupo, hasta cada r\u00e9plica personal en la versi\u00f3n de ClickHouse que queremos, y la versi\u00f3n de almacenamiento que deseamos. Podremos configurar completamente un cl\u00faster de la manera que nos necesite. <\/p>\n
<\/p>\n
<\/p>\n
Ahora nos adentraremos un poco m\u00e1s. Hasta ahora, hemos hablado de c\u00f3mo funciona el ClickHouse-operator en relaci\u00f3n a la especificidad de ClickHouse.<\/p>\n
<\/p>\n
Ahora me gustar\u00eda hablar brevemente sobre c\u00f3mo funciona cualquier operador en general, as\u00ed como de c\u00f3mo interact\u00faa con K8s.<\/p>\n
<\/p>\n
<\/p>\n
Comencemos con la interacci\u00f3n con K8s. \u00bfQu\u00e9 sucede cuando hacemos kubectl apply? A trav\u00e9s de la API en etcd aparecen nuestros objetos. <\/p>\n
<\/p>\n
<\/p>\n
Por ejemplo, los objetos b\u00e1sicos de Kubernetes: pod, StatefulSet, servicio, y as\u00ed sucesivamente. <\/p>\n
<\/p>\n
Sin embargo, a\u00fan no ocurre nada f\u00edsico. Estos objetos deben materializarse en el cl\u00faster. <\/p>\n
<\/p>\n
<\/p>\n
Para esto, aparece el controlador. El controlador es un componente especial de k8s que puede materializar estas descripciones. Sabe c\u00f3mo y qu\u00e9 hacer f\u00edsicamente. Sabe c\u00f3mo iniciar contenedores y qu\u00e9 debe configurarse para que el servidor funcione. <\/p>\n
<\/p>\n
<\/p>\n
Y materializa nuestros objetos en K8s.<\/p>\n
<\/p>\n
Pero queremos operar no solo con pods y StatefulSets, sino que queremos crear un ClickHouseInstallation, es decir, un objeto del tipo ClickHouse, para operarlo como un todo. Hasta ahora, esa posibilidad no existe. <\/p>\n
<\/p>\n
<\/p>\n
Pero K8s tiene algo muy agradable. Queremos que haya una entidad compleja que re\u00fana nuestro cl\u00faster formado por pods y StatefulSets. <\/p>\n
<\/p>\n
<\/p>\n
\u00bfY qu\u00e9 debemos hacer para esto? En primer lugar, entra en escena la Custom Resource Definition. \u00bfQu\u00e9 es esto? Es una descripci\u00f3n para K8s de que tendr\u00e1s otro tipo de datos, que queremos agregar un recurso personalizado que ser\u00e1 complejo dentro de pods y StatefulSets. Esta es la descripci\u00f3n de la estructura de datos. <\/p>\n
<\/p>\n
<\/p>\n
Tambi\u00e9n lo enviamos all\u00ed a trav\u00e9s de kubectl apply. Kubernetes lo recibi\u00f3 con gusto. <\/p>\n
<\/p>\n
Y ahora tenemos la posibilidad de registrar un recurso personalizado llamado ClickHouseInstallation en el almacenamiento del objeto en etcd.<\/p>\n
<\/p>\n
Pero por el momento no suceder\u00e1 nada m\u00e1s. Es decir, si ahora creamos un archivo YAML que hemos discutido con la descripci\u00f3n de shards, r\u00e9plicas y decimos \"kubectl apply\", Kubernetes lo aceptar\u00e1, lo colocar\u00e1 en etcd y dir\u00e1: \"Perfecto, pero no s\u00e9 qu\u00e9 hacer con \u00e9l. No s\u00e9 c\u00f3mo gestionar ClickHouseInstallation\". <\/p>\n
<\/p>\n
<\/p>\n
Por lo tanto, necesitamos a alguien que ayude a Kubernetes a gestionar un nuevo tipo de datos. A la izquierda tenemos un controlador integrado de Kubernetes que trabaja con tipos de datos est\u00e1ndar. A la derecha debe aparecer un controlador personalizado que sabe trabajar con tipos de datos personalizados. <\/p>\n
<\/p>\n
Y su nombre alternativo es operador. Lo he destacado aqu\u00ed fuera de Kubernetes porque puede ejecutarse fuera de K8s. La mayor\u00eda de las veces, por supuesto, todos los operadores se ejecutan en Kubernetes, pero nada impide que se ejecute externamente, por eso aqu\u00ed se ha presentado fuera. <\/p>\n
<\/p>\n
<\/p>\n
Y, por su parte, el controlador personalizado, tambi\u00e9n conocido como operador, interact\u00faa con Kubernetes a trav\u00e9s de la API. Ya sabe c\u00f3mo interactuar con la API. Y ya sabe c\u00f3mo materializar un esquema complejo a partir de un recurso personalizado que deseamos crear. Precisamente para eso sirve el operador. <\/p>\n
<\/p>\n
<\/p>\n
\u00bfC\u00f3mo funciona el operador? Vamos a echar un vistazo al lado derecho para descubrir c\u00f3mo lo hace. Vamos a averiguar c\u00f3mo el operador materializa todo esto y c\u00f3mo contin\u00faa la interacci\u00f3n con K8s.<\/p>\n
<\/p>\n
<\/p>\n
El operador es un programa. Su enfoque es basado en eventos. El operador, a trav\u00e9s de la API de Kubernetes, se suscribe a eventos. En la API de Kubernetes hay puntos de entrada donde se puede suscribir a eventos. Y si algo cambia en K8s, Kubernetes env\u00eda eventos a todos los interesados, es decir, quien est\u00e9 suscrito a ese punto de API recibir\u00e1 las notificaciones.<\/p>\n
<\/p>\n
El operador se suscribe a eventos y debe realizar alguna reacci\u00f3n. Su tarea es reaccionar a los eventos que aparecen. <\/p>\n
<\/p>\n
<\/p>\n
Los eventos se generan a trav\u00e9s de ciertas actualizaciones. Nuestro archivo YAML con la descripci\u00f3n de ClickHouseInstallation llega. A trav\u00e9s de kubectl apply, fue a etcd. All\u00ed se activ\u00f3 un evento, y este evento lleg\u00f3 al operador de ClickHouse. El operador recibi\u00f3 esta descripci\u00f3n. Y debe hacer algo al respecto. Si ha llegado una actualizaci\u00f3n al objeto ClickHouseInstallation, entonces es necesario actualizar el cl\u00faster. Y la tarea del operador es actualizar el cl\u00faster. <\/p>\n
<\/p>\n
<\/p>\n
\u00bfQu\u00e9 hace? Primero, es necesario elaborar un plan de acci\u00f3n sobre qu\u00e9 haremos con esta actualizaci\u00f3n. Las actualizaciones pueden ser muy peque\u00f1as, es decir, peque\u00f1as en la ejecuci\u00f3n de YAML, pero pueden llevar a grandes cambios en el cl\u00faster. Por lo tanto, el operador crea un plan y luego se adhiere a \u00e9l.<\/p>\n
<\/p>\n
<\/p>\n
\u00c9l comienza a implementar esta estructura seg\u00fan el plan, para materializar pods, servicios, es decir, hacer lo que es su tarea principal. Es como construir un cl\u00faster de ClickHouse en Kubernetes.<\/p>\n
<\/p>\n
<\/p>\n
Ahora, hablemos de algo interesante. Esta es la divisi\u00f3n de responsabilidades entre Kubernetes y el operador, es decir, qu\u00e9 hace Kubernetes, qu\u00e9 hace el operador y c\u00f3mo interact\u00faan entre s\u00ed. <\/p>\n
<\/p>\n
Kubernetes se encarga de las cosas del sistema, es decir, de un conjunto b\u00e1sico de objetos que se puede interpretar como de \u00e1mbito del sistema. Kubernetes sabe c\u00f3mo iniciar pods, c\u00f3mo reiniciar contenedores, c\u00f3mo montar vol\u00famenes, c\u00f3mo trabajar con ConfigMap, es decir, todo lo que se puede denominar sistema. <\/p>\n
<\/p>\n
Los operadores operan en dominios espec\u00edficos. Cada operador se crea para su propio dominio espec\u00edfico. Nosotros hicimos uno para ClickHouse.<\/p>\n
<\/p>\n
Y el operador interact\u00faa precisamente en t\u00e9rminos del dominio espec\u00edfico, como agregar una r\u00e9plica, crear un esquema, configurar la supervisi\u00f3n. As\u00ed se produce esta divisi\u00f3n.<\/p>\n
<\/p>\n
<\/p>\n
Veamos un ejemplo pr\u00e1ctico de c\u00f3mo ocurre esta divisi\u00f3n de responsabilidades cuando realizamos la acci\u00f3n de agregar una r\u00e9plica. <\/p>\n
<\/p>\n
Al operador llega la tarea: agregar una r\u00e9plica. \u00bfQu\u00e9 hace el operador? El operador calcular\u00e1 que necesita crear un nuevo StatefulSet, en el que se deben describir ciertas plantillas, reclamos de volumen. <\/p>\n
<\/p>\n
<\/p>\n
\u00c9l prepara todo esto y lo pasa a K8s. Indica que necesita ConfigMap, StatefulSet, Volumen. Kubernetes lo procesa. Materializa las unidades b\u00e1sicas con las que operaci\u00f3n. <\/p>\n
<\/p>\n
<\/p>\n
Y luego entra nuevamente en juego el ClickHouse-operator. Ya tiene un pod f\u00edsico, sobre el cual se puede trabajar. Y ClickHouse-operator nuevamente trabaja en t\u00e9rminos del dominio espec\u00edfico. Es decir, para incluir una r\u00e9plica en el cl\u00faster, primero hay que configurar el esquema de datos que existe en este cl\u00faster. Y, en segundo lugar, esta r\u00e9plica debe incluirse en la supervisi\u00f3n para que sea monitoreada de manera efectiva. Esto lo configura el operador. <\/p>\n
<\/p>\n
<\/p>\n
Y solo despu\u00e9s de eso, entra en juego ClickHouse, es decir, otra entidad de nivel superior. Esta ya es una base de datos. Tiene su propia instancia, una r\u00e9plica configurada, que est\u00e1 lista para unirse al cl\u00faster.<\/p>\n
<\/p>\n
La cadena de ejecuci\u00f3n y separaci\u00f3n de responsabilidades al agregar una r\u00e9plica es bastante larga.<\/p>\n
<\/p>\n
<\/p>\n
Continuamos con nuestras tareas pr\u00e1cticas. Si ya existe un cl\u00faster, podemos llevar a cabo la migraci\u00f3n de la configuraci\u00f3n. <\/p>\n
<\/p>\n
<\/p>\n
Hicimos que en el XML existente, que ClickHouse entiende, se pueda trasmitir a trav\u00e9s.<\/p>\n
<\/p>\n
<\/p>\n
Se puede hacer un ajuste fino de ClickHouse. Justo el despliegue zonificado es de lo que habl\u00e9 al explicar hostPath y almacenamiento local. Es c\u00f3mo hacer correctamente un despliegue zonificado.<\/p>\n
<\/p>\n
<\/p>\n
La siguiente tarea pr\u00e1ctica es la monitorizaci\u00f3n.<\/p>\n
<\/p>\n
<\/p>\n
Si nuestro cl\u00faster cambia, debemos ajustar peri\u00f3dicamente la monitorizaci\u00f3n. <\/p>\n
<\/p>\n
Veamos el esquema. Ya hemos revisado las flechas verdes. Ahora veamos las flechas rojas. As\u00ed es como queremos monitorizar nuestro cl\u00faster. C\u00f3mo las m\u00e9tricas del cl\u00faster de ClickHouse llegan a Prometheus y luego a Grafana.<\/p>\n
<\/p>\n
<\/p>\n
\u00bfY cu\u00e1l es la dificultad con la monitorizaci\u00f3n? \u00bfPor qu\u00e9 se considera un logro? La complejidad radica en la din\u00e1mica. Cuando tenemos un solo cl\u00faster y es est\u00e1tico, se puede configurar la monitorizaci\u00f3n una vez y no volver a preocuparse.<\/p>\n
<\/p>\n
Pero si tenemos muchos cl\u00fasteres, o si algo cambia constantemente, el proceso es din\u00e1mico. Y estar continuamente reconfigurando la monitorizaci\u00f3n es una p\u00e9rdida de recursos y tiempo, es decir, simplemente pereza. Esto debe automatizarse. La dificultad est\u00e1 precisamente en la din\u00e1mica del proceso. Y el operador lo automatiza muy bien. <\/p>\n
<\/p>\n
<\/p>\n
\u00bfC\u00f3mo ha evolucionado nuestro cl\u00faster? Al principio era as\u00ed.<\/p>\n
<\/p>\n
<\/p>\n
Luego fue as\u00ed.<\/p>\n
<\/p>\n
<\/p>\n
Al final, se convirti\u00f3 en esto. <\/p>\n
<\/p>\n
Y la monitorizaci\u00f3n se realiza autom\u00e1ticamente por el operador. Un \u00fanico punto de entrada. <\/p>\n
<\/p>\n
<\/p>\n
Y solo miramos en el panel de Grafana c\u00f3mo est\u00e1 la vida interna de nuestro cl\u00faster. <\/p>\n
<\/p>\n
Por cierto, el panel de Grafana tambi\u00e9n se distribuye con nuestro operador directamente en los fuentes. Se puede conectar y usar. Este pantallazo me lo dieron nuestros DevOps.<\/p>\n
<\/p>\n
<\/p>\n
\u00bfA d\u00f3nde nos gustar\u00eda avanzar? Esto es:<\/p>\n
<\/p>\n
\nDesarrollar la automatizaci\u00f3n de pruebas. La tarea principal es la prueba automatizada de nuevas versiones. <\/li>\n Tambi\u00e9n queremos automatizar la integraci\u00f3n con ZooKeeper. Y est\u00e1 en nuestros planes integrarnos con ZooKeeper-operator. Es decir, para ZooKeeper se ha escrito un operador y tiene sentido que ambos operadores comiencen a integrarse para construir una soluci\u00f3n m\u00e1s conveniente. <\/li>\n Queremos hacer comprobaciones de vida m\u00e1s complejas. <\/li>\n He destacado en verde lo que se aproxima: la herencia de Templates - LISTO, es decir, con la pr\u00f3xima versi\u00f3n del operador ya tendremos herencia de plantillas. Esta es una herramienta poderosa que permite construir configuraciones complejas a partir de fragmentos. <\/li>\n Y queremos la automatizaci\u00f3n de tareas complejas. La principal de ellas es el Re-sharding. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Hagamos un resumen intermedio. <\/p>\n
<\/p>\n
<\/p>\n
\u00bfQu\u00e9 obtenemos al final? \u00bfVale la pena o no? \u00bfEs necesario intentar llevar la base de datos a Kubernetes y aplicar el operador en general y el operador Alitnity en particular?<\/p>\n
<\/p>\n
Al final obtenemos:<\/p>\n
<\/p>\n
\nUna simplificaci\u00f3n y automatizaci\u00f3n significativas de la configuraci\u00f3n, despliegue y mantenimiento. <\/li>\n Monitoreo incorporado de inmediato. <\/li>\n Y plantillas codificadas listas para usar en situaciones complejas. Ya no es necesario hacer manualmente acciones como agregar una r\u00e9plica. Esto lo hace el operador. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Solo queda una \u00faltima pregunta. Ya tenemos la base de datos en Kubernetes, virtualizaci\u00f3n. \u00bfQu\u00e9 pasa con el rendimiento de esta soluci\u00f3n, especialmente considerando que ClickHouse est\u00e1 optimizado para el rendimiento?<\/p>\n
<\/p>\n
La respuesta es: \u00a1todo est\u00e1 bien! No entrar\u00e9 en detalles, este es un tema para otra presentaci\u00f3n. <\/p>\n
<\/p>\n
<\/p>\n
Pero existe un proyecto como TSBS. \u00bfCu\u00e1l es su tarea principal? Es una prueba de bases de datos para medir el rendimiento. Es un intento de comparar lo similar con lo similar. <\/p>\n
<\/p>\n
\u00bfC\u00f3mo funciona? Se genera un conjunto de datos. Luego, este conjunto de datos se ejecuta en diferentes bases de datos utilizando el mismo conjunto de pruebas. Cada base de datos resuelve un problema de la manera que puede. Y despu\u00e9s se pueden comparar los resultados. <\/p>\n
<\/p>\n
Ya admite una gran cantidad de bases de datos. He destacado tres principales. Son:<\/p>\n
<\/p>\n
\nTimescaleDB.<\/li>\n InfluxDB.<\/li>\n ClickHouse.<\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Tambi\u00e9n se realiz\u00f3 una comparaci\u00f3n con otra soluci\u00f3n similar. La comparaci\u00f3n fue con RedShift. Se realiz\u00f3 la comparaci\u00f3n en Amazon. ClickHouse tambi\u00e9n supera a todos en este aspecto. <\/p>\n
<\/p>\n
<\/p>\n
\u00bfQu\u00e9 conclusiones se pueden extraer de lo que he contado?<\/p>\n
<\/p>\n
\nEs posible usar bases de datos en Kubernetes. Probablemente se puedan usar cualquier tipo de base de datos, pero en general parece que s\u00ed se puede. Definitivamente se puede usar ClickHouse en Kubernetes con la ayuda de nuestro operador. <\/li>\n El operador ayuda a automatizar procesos y realmente simplifica la vida.<\/li>\n El rendimiento es normal.<\/li>\n Y nos parece que esto es algo que se puede y se debe utilizar. <\/li>\n<\/ul>\n<\/p>\n
\u00a1C\u00f3digo abierto \u2013 \u00fananse!<\/p>\n
<\/p>\n
Como ya mencion\u00e9, el operador es un producto completamente de c\u00f3digo abierto, por lo que ser\u00eda muy bueno que la mayor cantidad posible de personas lo utilizara. \u00a1\u00dananse! \u00a1Los esperamos a todos!<\/p>\n
<\/p>\n
\u00a1Gracias a todos!<\/p>\n
<\/p>\n
Preguntas<\/p>\n
<\/p>\n
<\/p>\n
\u00a1Gracias por la presentaci\u00f3n! Me llamo Anton. Soy de la empresa SEMrush. Estoy interesado en el tema del registro. Se escucha sobre monitoreo, pero no sobre registro, si hablamos del cl\u00faster en su totalidad. Nosotros, por ejemplo, tenemos un cl\u00faster montado en hardware. Y utilizamos registro centralizado, recolectamos datos est\u00e1ndar en un solo lugar. Y luego sacamos de ah\u00ed los datos que nos interesan.<\/em> <\/p>\n<\/p>\n
Buena pregunta, es decir, el registro est\u00e1 en la lista de tareas pendientes. Nuestro operador a\u00fan no lo automatiza. A\u00fan est\u00e1 en desarrollo, el proyecto es bastante joven. Entendemos la necesidad del registro. Este tambi\u00e9n es un tema muy importante. Y probablemente no es menos importante que el monitoreo. Pero lo primero en la lista para su implementaci\u00f3n fue el monitoreo. El registro vendr\u00e1. Naturalmente, estamos tratando de automatizar todos los aspectos de la vida del cl\u00faster. Por lo tanto, la respuesta es que en este momento el operador, desafortunadamente, no puede hacerlo, pero est\u00e1 en nuestros planes, lo haremos. Si hay deseos de unirse, por favor, un pull request.<\/p>\n
<\/p>\n
\u00a1Hola! \u00a1Gracias por la presentaci\u00f3n! Tengo una pregunta est\u00e1ndar relacionada con los Vol\u00famenes Persistentes. Cuando creamos una configuraci\u00f3n con este operador, \u00bfc\u00f3mo determina el operador en qu\u00e9 nodo se ha montado un disco o carpeta en particular? \u00bfDebemos explicarle que, por favor, coloque nuestro ClickHouse solo en esos nodos donde hay un disco?<\/em><\/p>\n<\/p>\n
Hasta donde entiendo, esta pregunta es una continuaci\u00f3n del almacenamiento local, especialmente la parte relacionada con hostPath. Se trata de c\u00f3mo explicarle a todo el sistema que el pod debe ejecutarse espec\u00edficamente en un nodo determinado, donde tenemos un disco f\u00edsico conectado, que est\u00e1 montado en una ruta espec\u00edfica. Esta es toda una secci\u00f3n que toqu\u00e9 de manera muy superficial, porque la respuesta es bastante extensa. <\/p>\n
<\/p>\n
En resumen, se ve as\u00ed. Necesitamos, por supuesto, hacer el aprovisionamiento de estos vol\u00famenes. En este momento, no hay aprovisionamiento din\u00e1mico en el almacenamiento local, por lo que los DevOps deben crear los discos, es decir, estos vol\u00famenes. Y deben explicarle a Kubernetes sobre el aprovisionamiento, que tendr\u00e1s vol\u00famenes persistentes de tal clase, que est\u00e1n en tales nodos. Luego, ser\u00e1 necesario explicarle a Kubernetes que los pods que requieren tal clase de almacenamiento local deben ser programados solo en esos nodos, bas\u00e1ndose en las etiquetas. Para estos fines, el operador tiene la posibilidad de asignar alguna etiqueta y una por instancia de host. Y resultar\u00e1 que los pods ser\u00e1n enrutados por Kubernetes para ejecutarse solo en nodos que cumplen con los requisitos de las etiquetas, dicho de manera simple. Los administradores asignan etiquetas y hacen el aprovisionamiento de discos manualmente. Y entonces se escala.<\/p>\n
<\/p>\n
Y precisamente la tercera opci\u00f3n local ayuda a facilitar esto un poco. Como ya hice \u00e9nfasis, es un trabajo detallado de configuraci\u00f3n, que al final ayuda a obtener el rendimiento m\u00e1ximo.<\/p>\n
<\/p>\n
Tengo una segunda pregunta relacionada con esto. Kubernetes fue dise\u00f1ado de tal manera que no nos importa si perdemos un nodo o no. \u00bfQu\u00e9 debemos hacer en este caso si hemos perdido el nodo donde tenemos un shard?<\/em><\/p>\n<\/p>\n
S\u00ed, Kubernetes fue inicialmente posicionado con la idea de que nuestra relaci\u00f3n con nuestros pods es como la de ganado, pero aqu\u00ed cada disco se convierte en algo as\u00ed como una mascota. Hay un problema en que no podemos simplemente desecharlos. Y el desarrollo de Kubernetes va en la direcci\u00f3n de que no es posible tratar esto completamente de manera filos\u00f3fica, como si fueran recursos totalmente desechables.<\/p>\n
<\/p>\n
Ahora una pregunta pr\u00e1ctica. \u00bfQu\u00e9 hacer si has perdido un nodo en el que estaba el disco? Aqu\u00ed la tarea se resuelve a un nivel m\u00e1s alto. En el caso de ClickHouse, tenemos r\u00e9plicas que operan a un nivel superior, es decir, al nivel de ClickHouse.<\/p>\n
<\/p>\n
\u00bfCu\u00e1l es la disposici\u00f3n resultante? DevOps es responsable de que no se pierdan los datos. Debe configurar correctamente la replicaci\u00f3n y debe asegurarse de que la replicaci\u00f3n se ejecute. En la r\u00e9plica a nivel de ClickHouse, los datos deben estar duplicados. Esta no es la tarea que resuelve el operador. Y no es la tarea que resuelve Kubernetes mismo. Esto es a nivel de ClickHouse.<\/p>\n
<\/p>\n
\u00bfQu\u00e9 hacer si se ha ca\u00eddo un nodo f\u00edsico? Entonces, ser\u00e1 necesario instalar uno nuevo, correctamente provisionar el disco en \u00e9l y aplicar las etiquetas. Despu\u00e9s de eso, cumplir\u00e1 con los requisitos para que Kubernetes pueda ejecutar una instancia de pod en \u00e9l. Kubernetes lo iniciar\u00e1. De hecho, no tienes suficientes pods para el requerido. Pasar\u00e1 por el ciclo que te mostr\u00e9. Y en el nivel m\u00e1s alto, ClickHouse entender\u00e1 que ha entrado una r\u00e9plica que a\u00fan est\u00e1 vac\u00eda y a la que hay que empezar a transferir datos. Es decir, este proceso todav\u00eda est\u00e1 mal automatizado. <\/p>\n
<\/p>\n
\u00a1Gracias por la presentaci\u00f3n! Cuando ocurren problemas, se cae el operador y se reinicia, y en ese momento llegan eventos, \u00bfc\u00f3mo los manejas?<\/em><\/p>\n<\/p>\n
\u00bfQu\u00e9 suceder\u00e1 si el operador se ha ca\u00eddo y se reinici\u00f3? <\/p>\n
<\/p>\n
S\u00ed. Y en ese momento llegaron eventos.<\/em> <\/p>\n<\/p>\n
La tarea de qu\u00e9 hacer en este caso se divide parcialmente entre el operador y Kubernetes. Kubernetes tiene la capacidad de reproducir el evento que ocurri\u00f3. Lo reproduce. Y la tarea del operador es asegurarse de que, cuando se le haga replay del registro de eventos, esos eventos sean idempotentes. Y que la entrada repetida del mismo evento no rompa nuestro sistema. Y nuestro operador cumple con esta tarea. <\/p>\n
<\/p>\n
\u00a1Hola! \u00a1Gracias por la presentaci\u00f3n! Dmitry Zavyalov, de la empresa<\/em> Sm\u00e9dova. \u00bfEst\u00e1 prevista la adici\u00f3n a la operaci\u00f3n de la capacidad de configuraci\u00f3n con haproxy? Me interesa alg\u00fan otro balanceador adem\u00e1s del est\u00e1ndar, que sea inteligente y entienda que all\u00ed realmente est\u00e1 ClickHouse.<\/em> <\/p>\n<\/p>\n
\u00bfEst\u00e1s hablando de Ingress?<\/p>\n
<\/p>\n
S\u00ed, reemplaza Ingress por haproxy. En haproxy se puede especificar la topolog\u00eda del cl\u00faster, donde est\u00e1n las r\u00e9plicas.<\/em><\/p>\n<\/p>\n
Por el momento no hemos pensado en ello. Si lo necesitas y puedes explicar por qu\u00e9 es necesario, se podr\u00eda implementar, especialmente si decides participar. Con mucho gusto considerar\u00edamos la opci\u00f3n. Respuesta breve: no, actualmente no tenemos esa funcionalidad. Gracias por la sugerencia, lo evaluaremos. Y si adem\u00e1s explicas el caso de uso y por qu\u00e9 es necesario en la pr\u00e1ctica, por ejemplo, creas issues en GitHub, ser\u00eda genial.<\/p>\n
<\/p>\n
Ya existe.<\/em><\/p>\n<\/p>\n
Bien. Estamos abiertos a cualquier propuesta. Y haproxy se a\u00f1ade a la lista de tareas pendientes. La lista de tareas pendientes sigue creciendo, no disminuye por ahora. Pero eso es bueno, significa que el producto es demandado.<\/p>\n
Fuente: 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
![\"Operador](\"\/wp-content\/uploads\/2020\/10\/56e002c7408c4708e39ece867f84171e.jpeg\")
<\/p>\n