Local<\/li>\n<\/ul>\n<\/p>\n
Vamos considerar como eles diferem e em que s\u00e3o semelhantes. <\/p>\n
<\/p>\n
Primeiro, em todas as tr\u00eas abordagens, nosso armazenamento \u00e9 composto por discos locais, que est\u00e3o na mesma n\u00f3 f\u00edsica do k8s. Mas eles t\u00eam algumas diferen\u00e7as.<\/p>\n
<\/p>\n
<\/p>\n
Come\u00e7aremos com o mais simples, ou seja, com o emptyDir. O que \u00e9 isso na pr\u00e1tica? \u00c9 quando pedimos ao nosso sistema de especifica\u00e7\u00e3o que o sistema de cont\u00eainer (na maioria das vezes, isso \u00e9 o Docker) nos forne\u00e7a acesso a uma pasta no disco local.<\/p>\n
<\/p>\n
Na pr\u00e1tica, o Docker cria temporariamente uma pasta em seus pr\u00f3prios caminhos, chamando-a de um longo hash. E fornece uma interface de acesso a ela. <\/p>\n
<\/p>\n
Como isso funcionar\u00e1 em termos de desempenho? Funcionar\u00e1 na velocidade do disco local, ou seja, \u00e9 acesso total ao seu disco. <\/p>\n
<\/p>\n
Mas esse m\u00e9todo tem sua desvantagem. O Persistent \u00e9 um tanto duvidoso nesse caso. Na primeira movimenta\u00e7\u00e3o dos cont\u00eaineres pelo Docker, o Persistent se perde. Se o Kubernetes quiser, por algum motivo, mover esse Pod para outro disco, os dados ser\u00e3o perdidos. <\/p>\n
<\/p>\n
Essa abordagem \u00e9 boa para testes, pois j\u00e1 apresenta uma velocidade normal, mas para algo s\u00e9rio, essa op\u00e7\u00e3o n\u00e3o \u00e9 adequada. <\/p>\n
<\/p>\n
<\/p>\n
Portanto, h\u00e1 uma segunda abordagem. \u00c9 o hostPath. Se olharmos o slide anterior e este, podemos ver uma \u00fanica diferen\u00e7a. Temos a pasta saindo do Docker diretamente para o n\u00f3 do Kubernetes. Aqui \u00e9 um pouco mais simples. Definimos diretamente o caminho no sistema de arquivos local onde gostar\u00edamos de armazenar nossos dados. <\/p>\n
<\/p>\n
Os benef\u00edcios desse m\u00e9todo existem. Agora temos um verdadeiro Persistent, e \u00e9 cl\u00e1ssico. Os dados ser\u00e3o gravados em um endere\u00e7o espec\u00edfico no disco. <\/p>\n
<\/p>\n
H\u00e1 tamb\u00e9m desvantagens. A complexidade de gerenciamento. Nosso Kubernetes pode querer mover um Pod para outro n\u00f3 f\u00edsico. E \u00e9 aqui que o DevOps entra em a\u00e7\u00e3o. Ele deve explicar corretamente a todo o sistema que esses pods s\u00f3 podem ser movidos para n\u00f3s nos quais voc\u00ea tem algo montado nesses caminhos, e n\u00e3o mais de um n\u00f3 por vez. Isso \u00e9 bastante complicado. <\/p>\n
<\/p>\n
Para esses fins, n\u00f3s, como operadores, criamos modelos para ocultar toda essa complexidade. E poder\u00edamos simplesmente dizer: 'Eu quero que haja uma inst\u00e2ncia do ClickHouse em cada n\u00f3 f\u00edsico e neste caminho espec\u00edfico.' <\/p>\n
<\/p>\n
<\/p>\n
Mas essa necessidade n\u00e3o \u00e9 s\u00f3 nossa, portanto, os senhores do pr\u00f3prio Kubernetes tamb\u00e9m entendem que as pessoas gostariam de ter acesso a discos f\u00edsicos, por isso eles fornecem um terceiro n\u00edvel.<\/p>\n
<\/p>\n
Ele \u00e9 chamado de local. N\u00e3o h\u00e1 praticamente nenhuma diferen\u00e7a em rela\u00e7\u00e3o ao slide anterior. Antes, era necess\u00e1rio fazer manualmente, que n\u00e3o podemos mover esses pods de um n\u00f3 para outro, porque eles devem estar ligados a um disco f\u00edsico local em tal caminho, e agora todo esse conhecimento \u00e9 encapsulado no pr\u00f3prio Kubernetes. E fica muito mais f\u00e1cil configurar.<\/p>\n
<\/p>\n
<\/p>\n
Voltemos \u00e0 nossa tarefa pr\u00e1tica. Vamos voltar ao modelo YAML. Aqui temos um verdadeiro storage. N\u00f3s retornamos a isso. Definimos um cl\u00e1ssico modelo de VolumeClaim como no k8s. E descrevemos qual storage queremos.<\/p>\n
<\/p>\n
Ap\u00f3s isso, o k8s solicitar\u00e1 o storage. Ele nos alocar\u00e1 dentro do StatefulSet. E, no final, isso ficar\u00e1 \u00e0 disposi\u00e7\u00e3o do ClickHouse.<\/p>\n
<\/p>\n
<\/p>\n
T\u00ednhamos esse esquema. Nosso Persistent Storage estava em vermelho, o que sugeria que deveria ser feito. <\/p>\n
<\/p>\n
<\/p>\n
E ele fica verde. Agora o esquema do cluster ClickHouse no k8s est\u00e1 completamente finalizado. Temos shards, r\u00e9plicas, ZooKeeper, h\u00e1 um verdadeiro Persistent, que \u00e9 implementado de uma forma ou de outra. O esquema j\u00e1 est\u00e1 totalmente funcional. <\/p>\n
<\/p>\n
<\/p>\n
Continuamos vivendo. Nosso cluster est\u00e1 se desenvolvendo. E Alexey se esfor\u00e7a e lan\u00e7a uma nova vers\u00e3o do ClickHouse.<\/p>\n
<\/p>\n
Surge uma tarefa pr\u00e1tica \u2013 testar a nova vers\u00e3o do ClickHouse em nosso cluster. E, naturalmente, n\u00e3o queremos atualizar tudo, queremos talvez colocar uma nova vers\u00e3o em uma r\u00e9plica em um canto distante, ou talvez n\u00e3o uma nova vers\u00e3o, mas duas de uma vez, pois elas saem com frequ\u00eancia. <\/p>\n
<\/p>\n
O que podemos dizer sobre isso?<\/p>\n
<\/p>\n
<\/p>\n
Aqui temos exatamente essa oportunidade. S\u00e3o os templates de pods. Podemos detalhar, nosso operador permite construir um cluster heterog\u00eaneo. Ou seja, podemos configurar desde todas as r\u00e9plicas em conjunto at\u00e9 cada r\u00e9plica individual, definindo qual vers\u00e3o do ClickHouse desejamos e qual vers\u00e3o de armazenamento. Podemos configurar completamente o cluster da maneira que precisamos. <\/p>\n
<\/p>\n
<\/p>\n
Vamos nos aprofundar um pouco mais. Antes, falamos sobre como o ClickHouse-operator funciona em rela\u00e7\u00e3o \u00e0s especificidades do ClickHouse.<\/p>\n
<\/p>\n
Agora, gostaria de dizer algumas palavras sobre como qualquer operador funciona e como interage com o K8s.<\/p>\n
<\/p>\n
<\/p>\n
Vamos considerar a intera\u00e7\u00e3o com o K8s primeiramente. O que acontece quando fazemos kubectl apply? Nossos objetos aparecem em etcd atrav\u00e9s da API. <\/p>\n
<\/p>\n
<\/p>\n
Por exemplo, os objetos b\u00e1sicos do Kubernetes: pod, StatefulSet, service e assim por diante. <\/p>\n
<\/p>\n
Neste momento, nada f\u00edsico acontece ainda. Esses objetos precisam ser materializados no cluster. <\/p>\n
<\/p>\n
<\/p>\n
Para isso, aparece o controlador. O controlador \u00e9 um componente especial do k8s que consegue materializar essas descri\u00e7\u00f5es. Ele sabe como e o que deve ser feito fisicamente. Ele sabe como iniciar cont\u00eaineres e o que deve ser configurado para que o servidor funcione. <\/p>\n
<\/p>\n
<\/p>\n
E ele materializa nossos objetos no K8s.<\/p>\n
<\/p>\n
Mas queremos operar n\u00e3o apenas com pods e StatefulSets, queremos criar ClickHouseInstallation, ou seja, um objeto do tipo ClickHouse, para oper\u00e1-lo como um todo. At\u00e9 agora, essa possibilidade n\u00e3o existe. <\/p>\n
<\/p>\n
<\/p>\n
Mas o K8s tem uma outra coisa agrad\u00e1vel. Queremos que exista uma entidade complexa, que seja composta de pods e StatefulSets do nosso cluster. <\/p>\n
<\/p>\n
<\/p>\n
E o que \u00e9 necess\u00e1rio para isso? Primeiro, surge a Custom Resource Definition. O que \u00e9 isso? \u00c9 uma descri\u00e7\u00e3o para o K8s que informa que voc\u00ea ter\u00e1 mais um tipo de dado, que queremos adicionar um recurso personalizado ao pod, StatefulSet, que ser\u00e1 complexo internamente. \u00c9 uma descri\u00e7\u00e3o da estrutura de dados. <\/p>\n
<\/p>\n
<\/p>\n
Tamb\u00e9m o enviamos para l\u00e1 atrav\u00e9s do kubectl apply. O Kubernetes o aceitou com prazer. <\/p>\n
<\/p>\n
E agora temos, no armazenamento, a possibilidade de registrar um recurso personalizado chamado ClickHouseInstallation no objeto em etcd.<\/p>\n
<\/p>\n
Mas at\u00e9 agora, nada mais acontecer\u00e1. Ou seja, se criarmos agora um arquivo YAML, que discutimos contendo a descri\u00e7\u00e3o de shards, r\u00e9plicas e dissermos 'kubectl apply', o Kubernetes o aceitar\u00e1, colocar\u00e1 no etcd e dir\u00e1: '\u00d3timo, mas n\u00e3o sei o que fazer com isso. N\u00e3o sei como gerenciar ClickHouseInstallation.' <\/p>\n
<\/p>\n
<\/p>\n
Portanto, precisamos de algu\u00e9m que ajude o Kubernetes a gerenciar um novo tipo de dados. \u00c0 esquerda, temos o controlador padr\u00e3o do Kubernetes, que trabalha com tipos de dados padr\u00e3o. E \u00e0 direita, devemos ter um controlador personalizado, que pode lidar com tipos de dados personalizados. <\/p>\n
<\/p>\n
E de outra forma, ele \u00e9 chamado de operador. Eu o destaquei aqui fora do Kubernetes, porque ele pode ser executado fora do K8s. Na maioria das vezes, claro, todos os operadores s\u00e3o executados no Kubernetes, mas nada impede que ele funcione fora, por isso foi especificamente destacado aqui. <\/p>\n
<\/p>\n
<\/p>\n
E, por sua vez, o controlador personalizado, tamb\u00e9m conhecido como operador, interage com o Kubernetes atrav\u00e9s da API. Ele j\u00e1 sabe como interagir com a API. E ele j\u00e1 sabe como materializar um esquema complexo a partir do recurso personalizado que queremos criar. \u00c9 exatamente isso que o operador faz. <\/p>\n
<\/p>\n
<\/p>\n
Como funciona o operador? Vamos dar uma olhada na parte direita, para entender como ele faz isso. Descobriremos como o operador materializa tudo isso e como a intera\u00e7\u00e3o com o K8s acontece a seguir.<\/p>\n
<\/p>\n
<\/p>\n
O operador \u00e9 um programa. Ele \u00e9 orientado a eventos. O operador, atrav\u00e9s da API do Kubernetes, se inscreve em eventos. Na API do Kubernetes, existem pontos de entrada onde voc\u00ea pode se inscrever em eventos. E se algo mudar no K8s, o Kubernetes enviar\u00e1 eventos a todos que quiserem, ou seja, quem se inscreveu naquele ponto da API receber\u00e1 notifica\u00e7\u00f5es.<\/p>\n
<\/p>\n
O operador se inscreve em eventos e deve fazer alguma rea\u00e7\u00e3o. Sua tarefa \u00e9 reagir a eventos que surgem. <\/p>\n
<\/p>\n
<\/p>\n
Os eventos s\u00e3o gerados por algumas atualiza\u00e7\u00f5es. Chega nosso arquivo YAML com a descri\u00e7\u00e3o do ClickHouseInstallation. Ele foi para o etcd atrav\u00e9s do kubectl apply. L\u00e1, um evento foi acionado, e esse evento chegou ao ClickHouse-operator. O operador recebeu essa descri\u00e7\u00e3o. E ele deve fazer algo. Se uma atualiza\u00e7\u00e3o para o objeto ClickHouseInstallation chegou, ent\u00e3o \u00e9 necess\u00e1rio atualizar o cluster. E a tarefa do operador \u00e9 atualizar o cluster. <\/p>\n
<\/p>\n
<\/p>\n
O que ele faz? Primeiro, \u00e9 necess\u00e1rio elaborar um plano de a\u00e7\u00e3o sobre o que faremos com essa atualiza\u00e7\u00e3o. As atualiza\u00e7\u00f5es podem ser muito pequenas, ou seja, pequenas na execu\u00e7\u00e3o do YAML, mas podem resultar em mudan\u00e7as muito grandes no cluster. Portanto, o operador cria um plano e o segue.<\/p>\n
<\/p>\n
<\/p>\n
Ele come\u00e7a a trabalhar de acordo com esse plano, para construir essa estrutura internamente, a fim de materializar pods, servi\u00e7os, ou seja, fazer o que \u00e9 sua tarefa principal. Isso \u00e9 como construir um cluster ClickHouse no Kubernetes.<\/p>\n
<\/p>\n
<\/p>\n
Agora, vamos abordar algo interessante. Esta \u00e9 a divis\u00e3o de responsabilidades entre o Kubernetes e o operador, ou seja, o que o Kubernetes faz, o que o operador faz e como eles interagem entre si. <\/p>\n
<\/p>\n
O Kubernetes \u00e9 respons\u00e1vel pelas coisas do sistema, ou seja, pelo conjunto b\u00e1sico de objetos que pode ser interpretado como de escopo sist\u00eamico. O Kubernetes sabe como iniciar pods, reiniciar cont\u00eaineres, fazer o mount de volumes, trabalhar com ConfigMap, ou seja, tudo que pode ser chamado de sistema. <\/p>\n
<\/p>\n
Os operadores operam em \u00e1reas tem\u00e1ticas. Cada operador \u00e9 feito para sua \u00e1rea tem\u00e1tica. N\u00f3s fizemos um para o ClickHouse.<\/p>\n
<\/p>\n
E o operador interage precisamente em termos da \u00e1rea tem\u00e1tica, como adicionar uma r\u00e9plica, criar um esquema, configurar monitora\u00e7\u00e3o. H\u00e1, portanto, essa divis\u00e3o.<\/p>\n
<\/p>\n
<\/p>\n
Vamos considerar um exemplo pr\u00e1tico de como essa divis\u00e3o de responsabilidades ocorre quando realizamos a a\u00e7\u00e3o de adicionar uma r\u00e9plica. <\/p>\n
<\/p>\n
O operador recebe a tarefa de adicionar uma r\u00e9plica. O que o operador faz? O operador calcular\u00e1 que \u00e9 necess\u00e1rio criar um novo StatefulSet, no qual \u00e9 preciso descrever determinados modelos, volume claim. <\/p>\n
<\/p>\n
<\/p>\n
Ele preparou tudo isso e passa adiante para o K8s. Diz que precisa de ConfigMap, StatefulSet, Volume. O Kubernetes processa. Ele materializa as unidades b\u00e1sicas com as quais opera. <\/p>\n
<\/p>\n
<\/p>\n
E em seguida, entra em a\u00e7\u00e3o novamente o ClickHouse-operator. Ele j\u00e1 tem um pod f\u00edsico, no qual j\u00e1 \u00e9 poss\u00edvel fazer algo. E o ClickHouse-operator novamente trabalha em termos da \u00e1rea tem\u00e1tica. Ou seja, para incluir uma r\u00e9plica no cluster, \u00e9 necess\u00e1rio, primeiro, configurar o esquema de dados que existe nesse cluster. E, em segundo lugar, essa r\u00e9plica deve ser inclu\u00edda na monitora\u00e7\u00e3o, para que seja bem rastreada. J\u00e1 \u00e9 o operador que configura isso. <\/p>\n
<\/p>\n
<\/p>\n
E somente depois disso \u00e9 que o pr\u00f3prio ClickHouse entra em cena, ou seja, mais uma entidade de n\u00edvel superior. Isso j\u00e1 \u00e9 um banco de dados. Ele possui sua pr\u00f3pria inst\u00e2ncia, uma r\u00e9plica configurada, pronta para entrar no cluster.<\/p>\n
<\/p>\n
Consequentemente, a cadeia de execu\u00e7\u00e3o e divis\u00e3o de responsabilidades ao adicionar uma r\u00e9plica \u00e9 bastante longa.<\/p>\n
<\/p>\n
<\/p>\n
Vamos continuar com nossas tarefas pr\u00e1ticas. Se o cluster j\u00e1 existe, \u00e9 poss\u00edvel realizar a migra\u00e7\u00e3o da configura\u00e7\u00e3o. <\/p>\n
<\/p>\n
<\/p>\n
Fizemos de modo que no XML existente, que o ClickHouse entende, se possa passar adiante.<\/p>\n
<\/p>\n
<\/p>\n
\u00c9 poss\u00edvel fazer um ajuste fino do ClickHouse. O deployment zonado \u00e9 exatamente o que eu mencionei ao explicar o hostPath e o armazenamento local. \u00c9 como fazer corretamente um deployment zonado.<\/p>\n
<\/p>\n
<\/p>\n
A pr\u00f3xima tarefa pr\u00e1tica \u00e9 o monitoramento.<\/p>\n
<\/p>\n
<\/p>\n
Se temos altera\u00e7\u00e3o no cluster, precisamos configurar o monitoramento periodicamente. <\/p>\n
<\/p>\n
Vamos analisar o diagrama. J\u00e1 revisamos as setas verdes. Agora vamos considerar as setas vermelhas. Isso mostra como queremos monitorar nosso cluster. Como as m\u00e9tricas do cluster ClickHouse v\u00e3o para o Prometheus e depois para o Grafana.<\/p>\n
<\/p>\n
<\/p>\n
E qual \u00e9 a dificuldade com o monitoramento? Por que isso \u00e9 considerado uma conquista? A dificuldade est\u00e1 na din\u00e2mica. Quando temos um \u00fanico cluster e ele \u00e9 est\u00e1tico, \u00e9 poss\u00edvel configurar o monitoramento uma vez e depois n\u00e3o se preocupar mais com isso.<\/p>\n
<\/p>\n
Mas se temos muitos clusters ou se algo est\u00e1 constantemente mudando, o processo \u00e9 din\u00e2mico. E estar sempre configurando o monitoramento novamente consome recursos e tempo, ou seja, \u00e9 um trabalho que pode ser tedioso. Isso precisa ser automatizado. A dificuldade realmente est\u00e1 na din\u00e2mica do processo. E o operador consegue automatizar isso muito bem. <\/p>\n
<\/p>\n
<\/p>\n
Como o nosso cluster se desenvolveu? No in\u00edcio ele era assim.<\/p>\n
<\/p>\n
<\/p>\n
Depois ele ficou assim.<\/p>\n
<\/p>\n
<\/p>\n
E, por fim, tornou-se assim. <\/p>\n
<\/p>\n
O monitoramento \u00e9 feito automaticamente pelo operador. Um \u00fanico ponto de entrada. <\/p>\n
<\/p>\n
<\/p>\n
E n\u00f3s apenas olhamos no painel do Grafana, observando como a vida do nosso cluster flui internamente. <\/p>\n
<\/p>\n
Ali\u00e1s, o painel do Grafana tamb\u00e9m \u00e9 distribu\u00eddo com nosso operador diretamente nos fontes. \u00c9 poss\u00edvel conectar e utilizar. Este screenshot foi fornecido pelos nossos DevOps.<\/p>\n
<\/p>\n
<\/p>\n
Para onde gostar\u00edamos de avan\u00e7ar a partir daqui? Isso \u00e9:<\/p>\n
<\/p>\n
\nDesenvolver a automa\u00e7\u00e3o dos testes. A principal tarefa \u00e9 o teste automatizado de novas vers\u00f5es. <\/li>\n Al\u00e9m disso, queremos muito automatizar a integra\u00e7\u00e3o com o ZooKeeper. E estamos planejando nos integrar com o ZooKeeper-operator. Ou seja, foi escrito um operador para o ZooKeeper, e \u00e9 l\u00f3gico que dois operadores comecem a se integrar para construir uma solu\u00e7\u00e3o mais conveniente. <\/li>\n Queremos realizar verifica\u00e7\u00f5es de sa\u00fade mais complexas. <\/li>\n Eu destaquei em verde que estamos prestes a implementar a heran\u00e7a de Templates \u2013 CONCLU\u00cdDO, ou seja, com o pr\u00f3ximo lan\u00e7amento do operador, j\u00e1 teremos a heran\u00e7a de templates. \u00c9 uma ferramenta poderosa, que permite construir configura\u00e7\u00f5es complexas a partir de partes. <\/li>\n E queremos a automa\u00e7\u00e3o de tarefas complexas. A principal delas \u00e9 o Re-sharding. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Vamos fazer um resumo intermedi\u00e1rio. <\/p>\n
<\/p>\n
<\/p>\n
O que estamos obtendo no final? E vale a pena ou n\u00e3o? Dever\u00edamos mesmo tentar trazer o banco de dados para o Kubernetes e aplicar o operador em geral e o operador Alitnity em particular.<\/p>\n
<\/p>\n
No final, obtemos:<\/p>\n
<\/p>\n
\nUma simplifica\u00e7\u00e3o e automa\u00e7\u00e3o significativas da configura\u00e7\u00e3o, deployment e tamb\u00e9m da manuten\u00e7\u00e3o. <\/li>\n Monitoramento integrado desde o in\u00edcio. <\/li>\n E templates codificados prontos para uso em situa\u00e7\u00f5es complexas. N\u00e3o precisamos mais fazer manualmente a\u00e7\u00f5es como adicionar uma r\u00e9plica. Isso \u00e9 feito pelo operador. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Ainda resta apenas uma \u00faltima pergunta. J\u00e1 temos um banco de dados no Kubernetes, virtualiza\u00e7\u00e3o. Como fica o desempenho dessa solu\u00e7\u00e3o, principalmente considerando que o ClickHouse \u00e9 otimizado para desempenho?<\/p>\n
<\/p>\n
A resposta \u00e9 \u2013 tudo certo! N\u00e3o vou me aprofundar, isso \u00e9 um assunto para uma palestra separada. <\/p>\n
<\/p>\n
<\/p>\n
Mas existe um projeto chamado TSBS. Qual \u00e9 o seu principal objetivo? \u00c9 um teste de bancos de dados para desempenho. \u00c9 uma tentativa de comparar coisas semelhantes. <\/p>\n
<\/p>\n
Como funciona? Um conjunto de dados \u00e9 gerado. Depois, esse conjunto de dados \u00e9 testado em diferentes bancos de dados com um conjunto id\u00eantico de testes. E cada banco de dados resolve uma tarefa da forma que consegue. Assim, os resultados podem ser comparados. <\/p>\n
<\/p>\n
Ele j\u00e1 suporta uma grande variedade de bancos de dados. Eu destaquei tr\u00eas principais. S\u00e3o eles:<\/p>\n
<\/p>\n
\nTimescaleDB.<\/li>\n InfluxDB.<\/li>\n ClickHouse.<\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Tamb\u00e9m foi feita uma compara\u00e7\u00e3o com outra solu\u00e7\u00e3o semelhante. A compara\u00e7\u00e3o com o RedShift foi realizada na Amazon. O ClickHouse tamb\u00e9m superou todos nesse aspecto. <\/p>\n
<\/p>\n
<\/p>\n
Que conclus\u00f5es podemos tirar do que eu apresentei?<\/p>\n
<\/p>\n
\nDB no Kubernetes \u00e9 poss\u00edvel. Provavelmente, \u00e9 poss\u00edvel qualquer um, mas, em geral, parece que \u00e9 vi\u00e1vel. ClickHouse no Kubernetes com certeza \u00e9 poss\u00edvel com o suporte do nosso operador. <\/li>\n O operador ajuda a automatizar processos e realmente facilita a vida.<\/li>\n O desempenho \u00e9 normal.<\/li>\n E, nos parece, que isso pode e deve ser utilizado. <\/li>\n<\/ul>\n<\/p>\n
C\u00f3digo aberto \u2013 junte-se a n\u00f3s!<\/p>\n
<\/p>\n
Como j\u00e1 mencionei, o operador \u00e9 um produto totalmente de c\u00f3digo aberto, ent\u00e3o seria \u00f3timo se o maior n\u00famero poss\u00edvel de pessoas o utilizasse. Junte-se a n\u00f3s! Estamos esperando por todos voc\u00eas!<\/p>\n
<\/p>\n
Muito obrigado a todos!<\/p>\n
<\/p>\n
Perguntas<\/p>\n
<\/p>\n
<\/p>\n
Obrigado pela apresenta\u00e7\u00e3o! Meu nome \u00e9 Anton. Eu sou da empresa SEMrush. Estou curioso sobre a parte de logging. Sobre monitoramento estamos cientes, mas sobre logging n\u00e3o sei nada, se falamos sobre o cluster como um todo. Por exemplo, n\u00f3s levantamos um cluster em hardware. E usamos logging centralizado, coletando dados com ferramentas padr\u00e3o em um \u00fanico local. E depois extra\u00edmos os dados interessantes.<\/em> <\/p>\n<\/p>\n
Boa pergunta, ou seja, logging est\u00e1 na lista de tarefas. Nosso operador ainda n\u00e3o automatiza isso. Ele ainda est\u00e1 em desenvolvimento, o projeto \u00e9 bastante jovem. N\u00f3s entendemos a necessidade de logging. Este \u00e9 tamb\u00e9m um tema muito importante. E provavelmente n\u00e3o \u00e9 menos importante que o monitoramento. Mas o monitoramento foi o primeiro na lista de implementa\u00e7\u00f5es. O logging vir\u00e1. Estamos, naturalmente, tentando automatizar todos os aspectos da vida do cluster. Portanto, a resposta \u00e9: no momento, o operador, infelizmente, n\u00e3o faz isso, mas est\u00e1 nos planos, faremos isso. Se houver interesse em se juntar, por favor, enviem pull requests.<\/p>\n
<\/p>\n
Ol\u00e1! Obrigado pela apresenta\u00e7\u00e3o! Tenho uma pergunta padr\u00e3o relacionada a Persistent Volumes. Quando criamos uma configura\u00e7\u00e3o com esse operador, como o operador determina em qual n\u00f3 um disco ou pasta est\u00e1 montado? Precisamos explicar a ele que, por favor, coloque nosso ClickHouse exatamente nesses n\u00f3s onde o disco est\u00e1 dispon\u00edvel?<\/em><\/p>\n<\/p>\n
Pelo que eu entendo, essa pergunta \u00e9 uma extens\u00e3o do armazenamento local, especialmente na parte sobre hostPath. \u00c9 como explicar ao sistema que \u00e9 necess\u00e1rio que o pod seja executado exatamente naquele n\u00f3, onde temos um disco fisicamente conectado, que est\u00e1 montado em tal caminho. \u00c9 uma se\u00e7\u00e3o inteira, que eu abordei de forma muito superficial, pois a resposta \u00e9 bastante extensa. <\/p>\n
<\/p>\n
De forma resumida, isso funciona assim. Naturalmente, precisamos provisionar esses volumes. No momento, n\u00e3o h\u00e1 provisionamento din\u00e2mico em armazenamento local, ent\u00e3o os DevOps devem criar os discos manualmente, esses volumes. E devem explicar ao Kubernetes o seguinte: que voc\u00ea ter\u00e1 Persistent volumes de um certo tipo, localizados em determinados n\u00f3s. Em seguida, precisamos explicar ao Kubernetes que os pods que requerem esse tipo de armazenamento local devem ser agendados apenas em certos n\u00f3s, com base em labels. Para isso, o operador tem a possibilidade de atribuir algum label e um por inst\u00e2ncia do host. Assim, os pods ser\u00e3o roteados pelo Kubernetes para serem executados apenas em n\u00f3s que atendem aos requisitos dos labels, falando de forma simples. Os administradores atribuem labels, criam os discos manualmente. E assim, se torna escal\u00e1vel.<\/p>\n
<\/p>\n
E \u00e9 exatamente essa terceira op\u00e7\u00e3o de armazenamento local que ajuda a facilitar um pouco isso. Como j\u00e1 destaquei, \u00e9 um trabalho meticuloso de configura\u00e7\u00e3o que, ao final, ajuda a obter o m\u00e1ximo desempenho.<\/p>\n
<\/p>\n
Tenho uma segunda pergunta relacionada a isso. O Kubernetes foi concebido para que n\u00e3o importasse se perd\u00eassemos um n\u00f3 ou n\u00e3o. O que devemos fazer, nesse caso, se perdermos um n\u00f3 onde est\u00e1 o nosso shard?<\/em><\/p>\n<\/p>\n
Sim, o Kubernetes foi inicialmente posicionado de forma que nossa rela\u00e7\u00e3o com os pods \u00e9 como a de gado, mas aqui cada disco se torna algo como um animal de estima\u00e7\u00e3o. H\u00e1 um problema em que n\u00e3o podemos simplesmente descart\u00e1-los. E o desenvolvimento do Kubernetes est\u00e1 indo na dire\u00e7\u00e3o de que n\u00e3o \u00e9 poss\u00edvel trat\u00e1-los completamente de forma filos\u00f3fica, como recursos totalmente descart\u00e1veis.<\/p>\n
<\/p>\n
Agora, uma pergunta pr\u00e1tica. O que fazer se voc\u00ea perder um n\u00f3 onde o disco estava? Aqui, a tarefa \u00e9 resolvida em um n\u00edvel mais alto. No caso do ClickHouse, temos r\u00e9plicas que funcionam em um n\u00edvel superior, ou seja, no n\u00edvel do ClickHouse.<\/p>\n
<\/p>\n
Qual \u00e9 a disposi\u00e7\u00e3o? A responsabilidade por n\u00e3o perder dados cabe ao DevOps. Ele deve configurar corretamente a replica\u00e7\u00e3o e deve monitorar se a replica\u00e7\u00e3o est\u00e1 sendo executada. Na r\u00e9plica, no n\u00edvel do ClickHouse, os dados devem ser duplicados. Essa n\u00e3o \u00e9 uma tarefa que o operador resolve. E n\u00e3o \u00e9 uma tarefa que o pr\u00f3prio Kubernetes resolve. Isso est\u00e1 no n\u00edvel do ClickHouse.<\/p>\n
<\/p>\n
O que fazer se voc\u00ea tiver um n\u00f3 f\u00edsico falhando? E parece que teremos que instalar um segundo, corretamente provisionar o disco nele, aplicar labels. E, ap\u00f3s isso, ele atender\u00e1 aos requisitos para que o Kubernetes possa iniciar uma inst\u00e2ncia do pod. O Kubernetes o iniciar\u00e1. Voc\u00ea n\u00e3o tem o n\u00famero suficiente de pods at\u00e9 o especificado. Ele passar\u00e1 pelo ciclo que eu mostrei. E no n\u00edvel mais alto, o ClickHouse entender\u00e1 que uma r\u00e9plica entrou, ela ainda est\u00e1 vazia e precisamos come\u00e7ar a transferir dados para ela. Ou seja, esse processo ainda est\u00e1 pouco automatizado. <\/p>\n
<\/p>\n
Obrigado pela apresenta\u00e7\u00e3o! Quando acontecem v\u00e1rias coisas ruins, o operador falha e reinicia, e nesse momento eventos chegam, voc\u00ea de alguma forma os processa?<\/em><\/p>\n<\/p>\n
O que acontece se o operador falhar e reiniciar, certo? <\/p>\n
<\/p>\n
Sim. E nesse momento eventos chegaram.<\/em> <\/p>\n<\/p>\n
A tarefa do que fazer nesse caso \u00e9 parcialmente dividida entre o operador e o Kubernetes. O Kubernetes tem a capacidade de reproduzir o evento que ocorreu. Ele o reproduz. E a tarefa do operador \u00e9 garantir que, quando um replay do log de eventos for feito, esses eventos sejam idempotentes. E que a reinser\u00e7\u00e3o do mesmo evento n\u00e3o quebre nosso sistema. E nosso operador lida bem com essa tarefa. <\/p>\n
<\/p>\n
Ol\u00e1! Obrigado pela apresenta\u00e7\u00e3o! Dmitry Zavyalov, empresa<\/em> Smidova. Est\u00e1 planejada a adi\u00e7\u00e3o de configura\u00e7\u00e3o no operador com haproxy? Estou interessado em algum outro balanceador al\u00e9m do padr\u00e3o, que seja inteligente e entenda que realmente existe ClickHouse.<\/em> <\/p>\n<\/p>\n
Voc\u00ea est\u00e1 falando sobre Ingress?<\/p>\n
<\/p>\n
Sim, substituir Ingress por haproxy. No haproxy, \u00e9 poss\u00edvel especificar a topologia do cluster, onde est\u00e3o suas r\u00e9plicas.<\/em><\/p>\n<\/p>\n
Por enquanto, n\u00e3o pensamos sobre isso. Se voc\u00ea precisar e puder explicar por que isso \u00e9 necess\u00e1rio, podemos implementar, especialmente se voc\u00ea quiser participar. Teremos prazer em considerar essa op\u00e7\u00e3o. Resumindo, n\u00e3o, n\u00e3o temos essa funcionalidade no momento. Obrigado pela sugest\u00e3o, vamos analisar isso. E se voc\u00ea ainda explicar o caso de uso e por que isso \u00e9 necess\u00e1rio na pr\u00e1tica, por exemplo, criando issues no GitHub, ser\u00e1 \u00f3timo.<\/p>\n
<\/p>\n
J\u00e1 existe.<\/em><\/p>\n<\/p>\n
Certo. Estamos abertos a quaisquer propostas. E haproxy est\u00e1 na lista de tarefas. A lista de tarefas est\u00e1 crescendo e n\u00e3o diminuindo por enquanto. Mas isso \u00e9 bom, significa que o produto \u00e9 solicitado.<\/p>\n
Fonte: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0414\u043e\u043a\u043b\u0430\u0434 \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u043c \u0432\u043e\u043f\u0440\u043e\u0441\u0430\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440\u0430 \u0432 Kubernetes, \u043f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044e \u0435\u0433\u043e \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b \u0438 \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u0445 \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u043e\u0432 \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f. \u0412 \u043f\u0435\u0440\u0432\u043e\u0439 \u0447\u0430\u0441\u0442\u0438 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c: \u0447\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u0432 Kubernetes \u0438 \u0437\u0430\u0447\u0435\u043c \u043e\u043d \u043d\u0443\u0436\u0435\u043d; \u043a\u0430\u043a \u0438\u043c\u0435\u043d\u043d\u043e \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u0443\u043f\u0440\u043e\u0449\u0430\u0435\u0442 \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0435 \u0441\u043b\u043e\u0436\u043d\u044b\u043c\u0438 \u0441\u0438\u0441\u0442\u0435\u043c\u0430\u043c\u0438; \u0447\u0442\u043e \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u043c\u043e\u0436\u0435\u0442, \u0430 \u0447\u0442\u043e \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u043d\u0435 \u043c\u043e\u0436\u0435\u0442. \u0414\u0430\u043b\u0435\u0435, \u043f\u0435\u0440\u0435\u0439\u0434\u0451\u043c \u043a \u043e\u0431\u0441\u0443\u0436\u0434\u0435\u043d\u0438\u044e \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0433\u043e \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432\u0430 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440\u0430. \u0420\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0443 \u0438 \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":96966,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-96965","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Operador](\"\/wp-content\/uploads\/2020\/10\/56e002c7408c4708e39ece867f84171e.jpeg\")
<\/p>\n