O relatório é dedicado a questões práticas de desenvolvimento de um operador em Kubernetes, projetando sua arquitetura e princípios básicos de operação.
Na primeira parte do relatório consideraremos:
- o que é um operador no Kubernetes e por que ele é necessário;
- como exatamente o operador simplifica o gerenciamento de sistemas complexos;
- o que o operador pode e não pode fazer.
A seguir, vamos discutir a estrutura interna da operadora. Vejamos passo a passo a arquitetura e a operação do operador. Vejamos isso em detalhes:
- interação entre a operadora e o Kubernetes;
- quais funções o operador assume e quais funções ele delega ao Kubernetes.
Vejamos o gerenciamento de fragmentos e réplicas de banco de dados no Kubernetes.
A seguir, discutiremos questões de armazenamento de dados:
- como trabalhar com Armazenamento Persistente do ponto de vista de um operador;
- armadilhas do uso do armazenamento local.
Na parte final do relatório, consideraremos exemplos práticos de aplicação com Amazon ou Google Cloud Service. O relatório é baseado no exemplo da experiência de desenvolvimento e operação de uma operadora da ClickHouse.
Vídeo:
Meu nome é Vladislav Klimenko. Hoje queria falar sobre nossa experiência no desenvolvimento e operação de uma operadora, e esta é uma operadora especializada em gerenciamento de clusters de banco de dados. Por exemplo para gerenciar o cluster ClickHouse.
Por que temos a oportunidade de falar sobre a operadora e a ClickHouse?
- Apoiamos e desenvolvemos ClickHouse.
- No momento, estamos tentando aos poucos dar nossa contribuição para o desenvolvimento do ClickHouse. E estamos em segundo lugar depois do Yandex em termos de volume de alterações feitas no ClickHouse.
- Estamos tentando criar projetos adicionais para o ecossistema ClickHouse.
Gostaria de falar sobre um desses projetos. Trata-se do operador ClickHouse para Kubernetes.
No meu relatório gostaria de abordar dois tópicos:
- O primeiro tópico é como nosso operador de gerenciamento de banco de dados ClickHouse funciona no Kubernetes.
- O segundo tópico é como funciona qualquer operador, ou seja, como ele interage com o Kubernetes.
No entanto, estas duas questões irão cruzar-se ao longo do meu relatório.
Quem estaria interessado em ouvir o que estou tentando contar?
- Será de maior interesse para aqueles que operam operadoras.
- Ou para quem quer fazer o seu próprio para entender como funciona internamente, como o operador interage com o Kubernetes e quais armadilhas podem aparecer.
Para entender melhor o que discutiremos hoje, é uma boa ideia saber como funciona o Kubernetes e ter algum treinamento básico em nuvem.
O que é ClickHouse? Trata-se de uma base de dados colunar com funcionalidades específicas para processamento online de consultas analíticas. E é totalmente de código aberto.
E é importante que saibamos apenas duas coisas. Você precisa saber que este é um banco de dados, então o que direi será aplicável a quase qualquer banco de dados. E o fato de o ClickHouse DBMS ser muito bem dimensionado oferece escalabilidade quase linear. E, portanto, o estado do cluster é um estado natural para ClickHouse. E estamos mais interessados em discutir como servir o cluster ClickHouse no Kubernetes.
Por que ele é necessário lá? Por que não podemos continuar a operá-lo nós mesmos? E as respostas são em parte técnicas e em parte organizacionais.
- Na prática, cada vez mais nos deparamos com uma situação em que nas grandes empresas quase todos os componentes já estão no Kubernetes. Os bancos de dados permanecem do lado de fora.
- E a questão é cada vez mais colocada: “Isso pode ser colocado dentro?” Portanto, as grandes empresas estão tentando alcançar a máxima unificação de gestão para poder gerenciar rapidamente seus data warehouses.
- E isso ajuda especialmente se você precisar do máximo de oportunidade para repetir a mesma coisa em um novo local, ou seja, máxima portabilidade.
Quão fácil ou difícil é? É claro que isso pode ser feito manualmente. Mas não é tão simples, porque temos a complexidade adicional de gerenciar o próprio Kubernetes, mas ao mesmo tempo as especificidades do ClickHouse se sobrepõem. E tal agregação resulta.
E tudo junto, isso dá um conjunto bastante grande de tecnologias, que se torna bastante difícil de gerenciar, porque o Kubernetes traz seus próprios problemas diários para a operação, e o ClickHouse traz seus próprios problemas para a operação diária. Principalmente se tivermos vários ClickHouses e precisarmos fazer algo constantemente com eles.
Com uma configuração dinâmica, ClickHouse apresenta um número bastante grande de problemas que criam uma carga constante no DevOps:
- Quando queremos alterar algo no ClickHouse, por exemplo, adicionar uma réplica ou shard, então precisamos gerenciar a configuração.
- Em seguida, altere o esquema de dados, pois ClickHouse possui um método de fragmentação específico. Lá você precisa definir o diagrama de dados, definir as configurações.
- Você precisa configurar o monitoramento.
- Coletando logs para novos fragmentos, para novas réplicas.
- Cuide da restauração.
- E reinicie.
Estas são tarefas rotineiras que eu realmente gostaria de tornar mais fáceis de usar.
O próprio Kubernetes ajuda bem na operação, mas em coisas básicas do sistema.
Kubernetes é bom para facilitar e automatizar coisas como:
- Recuperação.
- Reiniciar.
- Gerenciamento do sistema de armazenamento.
Isso é bom, essa é a direção certa, mas ele não tem a menor ideia de como operar um cluster de banco de dados.
Queremos mais, queremos que todo o banco de dados funcione no Kubernetes.
Eu gostaria de obter algo como um grande botão vermelho mágico que você pressiona e um cluster com tarefas diárias que precisam ser resolvidas é implantado e mantido durante todo o seu ciclo de vida. Cluster ClickHouse no Kubernetes.
E tentamos fazer uma solução que ajudasse a facilitar o trabalho. Este é um operador ClickHouse para Kubernetes da Altinity.
Um operador é um programa cuja principal tarefa é gerenciar outros programas, ou seja, é um gerenciador.
E contém padrões de comportamento. Você pode chamar isso de conhecimento codificado sobre a área temática.
E a principal tarefa dele é facilitar a vida do DevOps e diminuir o microgerenciamento, para que ele (DevOps) já pense em termos de alto nível, ou seja, para que ele (DevOps) não se envolva em microgerenciamento, para que ele não configure todos os detalhes manualmente.
E apenas o operador é um assistente robótico que lida com microtarefas e auxilia DevOps.
Por que você precisa de uma operadora? Ele tem um desempenho particularmente bom em duas áreas:
- Quando o especialista que lida com ClickHouse não tem experiência suficiente, mas já precisa operar o ClickHouse, a operadora facilita a operação e permite operar um cluster ClickHouse com uma configuração bastante complexa, sem entrar em muitos detalhes sobre como tudo funciona dentro. Você simplesmente atribui a ele tarefas de alto nível e funciona.
- E a segunda tarefa em que tem melhor desempenho é quando é necessário automatizar um grande número de tarefas típicas. Remove microtarefas dos administradores do sistema.
Isso é mais necessário tanto para quem está começando sua jornada, quanto para quem precisa fazer muita automação.
Como a abordagem baseada no operador difere de outros sistemas? Existe Helm. Também ajuda a instalar o ClickHouse; você pode desenhar gráficos de leme, que instalarão até mesmo um cluster inteiro do ClickHouse. Qual é então a diferença entre o operador e o mesmo, por exemplo, Helm?
A principal diferença fundamental é que o Helm é o gerenciamento de pacotes e o Operator vai um passo além. Este é um suporte para todo o ciclo de vida. Não se trata apenas de instalação, são tarefas cotidianas que incluem dimensionamento, fragmentação, ou seja, tudo o que precisa ser feito durante o ciclo de vida (se necessário, então exclusão também) - tudo isso é decidido pelo operador. Ele tenta automatizar e manter todo o ciclo de vida do software. Esta é a sua diferença fundamental em relação a outras soluções apresentadas.
Essa foi a parte introdutória, vamos em frente.
Como construímos nosso operador? Estamos tentando abordar a questão de gerenciar o cluster ClickHouse como um único recurso.
Aqui temos dados de entrada no lado esquerdo da imagem. Este é o YAML com uma especificação de cluster, que é passada para o Kubernetes da maneira clássica via kubectl. Lá nosso operador pega e faz sua mágica. E na saída obtemos o seguinte esquema. Esta é uma implementação do ClickHouse no Kubernetes.
E então veremos lentamente como exatamente o operador funciona, quais tarefas típicas podem ser resolvidas. Consideraremos apenas tarefas típicas porque temos tempo limitado. E nem tudo o que a operadora pode decidir será discutido.
Vamos começar com a prática. Nosso projeto é totalmente open source, então você pode ver como funciona no GitHub. E você pode partir da consideração de que, se quiser apenas iniciá-lo, poderá começar com o Guia de início rápido.
Se você quiser entender em detalhes, tentamos manter a documentação de uma forma mais ou menos decente.
Vamos começar com um problema prático. A primeira tarefa, onde todos queremos começar, é executar o primeiro exemplo de alguma forma. Como posso iniciar o ClickHouse usando a operadora, mesmo que não saiba bem como funciona? Estamos escrevendo um manifesto, porque... Toda comunicação com k8s é feita por meio de manifestos.
Este é um manifesto muito complexo. O que destacamos em vermelho é o que precisamos focar. Pedimos ao operador para criar um cluster denominado demo.
Estes são exemplos básicos por enquanto. O armazenamento ainda não foi descrito, mas voltaremos ao armazenamento um pouco mais tarde. Por enquanto, observaremos a dinâmica de desenvolvimento do cluster.
Criamos este manifesto. Nós alimentamos nosso operador. Ele trabalhou, ele fez mágica.
Nós olhamos para o console. Três componentes são de interesse: um Pod, dois Serviços e um StatefulSet.
O operador funcionou e podemos ver exatamente o que ele criou.
Ele cria algo assim. Temos um StatefulSet, Pod, ConfigMap para cada réplica, ConfigMap para todo o cluster. Os serviços são necessários como pontos de entrada no cluster.
Os serviços são o serviço central do balanceador de carga e também podem ser usados para cada réplica, para cada fragmento.
Nosso cluster básico se parece com isto. É de um único nó.
Vamos mais longe e complicar as coisas. Precisamos fragmentar o cluster.
Nossas tarefas estão crescendo, a dinâmica está começando. Queremos adicionar um fragmento. Acompanhamos o desenvolvimento. Estamos mudando nossa especificação. Indicamos que queremos dois fragmentos.
Este é o mesmo arquivo que se desenvolve dinamicamente com o crescimento do sistema. Armazenamento não, o armazenamento será discutido mais adiante, este é um tópico separado.
Alimentamos o operador YAML e vemos o que acontece.
O operador pensou e fez as seguintes entidades. Já temos dois Pods, três Serviços e, de repente, 2 StatefulSets. Por que 2 StatefulSets?
No diagrama era assim - este é o nosso estado inicial, quando tínhamos um pod.
Ficou assim. Até agora tudo é simples, foi duplicado.
E por que surgiram dois StatefulSets? Aqui precisamos fazer uma digressão e discutir a questão de como os pods são gerenciados no Kubernetes.
Existe um objeto chamado StatefulSet que permite criar um conjunto de Pods a partir de um modelo. O fator chave aqui é o modelo. E você pode iniciar vários pods usando um modelo em um StatefulSet. E a frase-chave aqui é “muitos pods para um modelo”.
E houve uma grande tentação de criar o cluster inteiro, agrupando-o em um StatefulSet. Vai funcionar, não há problema com isso. Mas há uma ressalva. Se quisermos montar um cluster heterogêneo, ou seja, a partir de diversas versões do ClickHouse, então começam a surgir dúvidas. Sim, StatefulSet pode fazer uma atualização contínua e aí você pode lançar uma nova versão, explicar que não precisa tentar mais do que tantos nós ao mesmo tempo.
Mas se extrapolarmos a tarefa e dissermos que queremos fazer um cluster completamente heterogêneo e não queremos mudar da versão antiga para uma nova usando uma atualização contínua, mas simplesmente queremos criar um cluster heterogêneo tanto em termos de diferentes versões do ClickHouse e em termos de armazenamento diferente. Queremos, por exemplo, fazer algumas réplicas em discos separados, em discos lentos, em geral, para construir completamente um cluster heterogêneo. E devido ao fato de StatefulSet criar uma solução padronizada a partir de um modelo, não há como fazer isso.
Depois de pensar um pouco, foi decidido que faríamos desta forma. Temos cada réplica em seu próprio StatefulSet. Existem algumas desvantagens nesta solução, mas na prática tudo é completamente encapsulado pelo operador. E há muitas vantagens. Podemos construir o cluster exato que desejamos, por exemplo, um cluster absolutamente heterogêneo. Portanto, em um cluster em que temos dois shards com uma réplica, teremos 2 StatefulSets e 2 Pods justamente porque escolhemos esta abordagem pelos motivos expostos acima para podermos construir um cluster heterogêneo.
Voltemos aos problemas práticos. Em nosso cluster, precisamos configurar usuários, ou seja, você precisa fazer alguma configuração do ClickHouse no Kubernetes. A operadora oferece todas as possibilidades para isso.
Podemos escrever o que quisermos diretamente em YAML. Todas as opções de configuração são mapeadas diretamente deste YAML nas configurações do ClickHouse, que são então distribuídas por todo o cluster.
Você pode escrever assim. Isto é, por exemplo. A senha pode ser criptografada. Absolutamente todas as opções de configuração do ClickHouse são suportadas. Aqui está apenas um exemplo.
A configuração do cluster é distribuída como um ConfigMap. Na prática, a atualização do ConfigMap não ocorre instantaneamente, portanto, se o cluster for grande, o processo de envio da configuração levará algum tempo. Mas tudo isso é muito conveniente de usar.
Vamos complicar a tarefa. O cluster está se desenvolvendo. Queremos replicar dados. Ou seja, já temos dois shards, uma réplica cada, e os usuários estão configurados. Estamos crescendo e queremos fazer replicação.
O que precisamos para replicação?
Precisamos do ZooKeeper. No ClickHouse, a replicação é construída usando ZooKeeper. O ZooKeeper é necessário para que diferentes réplicas do ClickHouse tenham um consenso sobre quais blocos de dados estão em qual ClickHouse.
ZooKeeper pode ser usado por qualquer pessoa. Se a empresa tiver um ZooKeeper externo, ele poderá ser usado. Caso contrário, você pode instalá-lo de nosso repositório. Existe um instalador que facilita tudo isso.
E o diagrama de interação de todo o sistema fica assim. Temos o Kubernetes como plataforma. Ele executa o operador ClickHouse. Imaginei o ZooKeeper aqui. E o operador interage com ClickHouse e ZooKeeper. Ou seja, resultados de interação.
E tudo isso é necessário para que o ClickHouse replique os dados no k8s com sucesso.
Vejamos agora a tarefa em si, como será o manifesto para replicação.
Estamos adicionando duas seções ao nosso manifesto. A primeira é onde obter o ZooKeeper, que pode ser dentro do Kubernetes ou externo. Esta é apenas uma descrição. E encomendamos réplicas. Aqueles. queremos duas réplicas. No total, devemos ter 4 pods na saída. Lembramos do armazenamento, ele voltará um pouco mais tarde. O armazenamento é uma história separada.
Foi assim.
Fica assim. Réplicas são adicionadas. O 4º não coube, acreditamos que poderia haver muitos deles ali. E o ZooKeeper é adicionado ao lado. Os esquemas estão se tornando mais complexos.
E é hora de adicionar a próxima tarefa. Adicionaremos armazenamento persistente.
Para armazenamento persistente temos várias opções.
Se estivermos rodando em um provedor de nuvem, por exemplo, usando Amazon, Google, então há uma grande tentação de usar armazenamento em nuvem. É muito conveniente, é bom.
E há uma segunda opção. Isto é para armazenamento local, quando temos discos locais em cada nó. Esta opção é muito mais difícil de implementar, mas ao mesmo tempo é mais produtiva.
Vamos ver o que temos em relação ao armazenamento em nuvem.
Existem vantagens. É muito fácil de configurar. Simplesmente solicitamos ao provedor de nuvem que nos forneça armazenamento de tal e tal capacidade, de tal ou tal classe. As aulas são agendadas pelos provedores de forma independente.
E há uma desvantagem. Para alguns, esta é uma desvantagem não crítica. Claro, haverá alguns problemas de desempenho. É muito conveniente de usar e confiável, mas existem algumas desvantagens potenciais de desempenho.
E porque ClickHouse foca especificamente na produtividade, pode-se até dizer que extrai tudo o que pode, e é por isso que muitos clientes tentam extrair o máximo de produtividade.
E para aproveitar ao máximo, precisamos de armazenamento local.
O Kubernetes fornece três abstrações para usar o armazenamento local no Kubernetes. Esse:
- VazioDir
- HostPath.
- Locais de
Vejamos como eles diferem e como são semelhantes.
Em primeiro lugar, em todas as três abordagens temos armazenamento - são discos locais localizados no mesmo nó físico k8s. Mas eles têm algumas diferenças.
Vamos começar com o mais simples, ou seja, vazioDir. O que é isso na prática? Em nossa especificação, pedimos ao sistema de conteinerização (geralmente Docker) que nos forneça acesso a uma pasta no disco local.
Na prática, o Docker cria uma pasta temporária em algum lugar ao longo de seus próprios caminhos e a chama de hash longo. E fornece uma interface para acessá-lo.
Como isso funcionará em termos de desempenho? Isso funcionará na velocidade do disco local, ou seja, Este é o acesso total ao seu parafuso.
Mas este caso tem a sua desvantagem. Persistente é bastante duvidoso neste assunto. Na primeira vez que o Docker move-se com contêineres, o Persistent é perdido. Se o Kubernetes quiser mover este pod para outro disco por algum motivo, os dados serão perdidos.
Essa abordagem é boa para testes, pois já mostra velocidade normal, mas para algo sério essa opção não é adequada.
Portanto, há uma segunda abordagem. Este é hostPath. Se você olhar o slide anterior e este, verá apenas uma diferença. Nossa pasta foi movida do Docker diretamente para o nó do Kubernetes. É um pouco mais simples aqui. Especificamos diretamente o caminho no sistema de arquivos local onde gostaríamos de armazenar nossos dados.
Este método tem vantagens. Este já é um verdadeiro Persistent e clássico. Teremos dados gravados no disco em algum endereço.
Também existem desvantagens. Essa é a complexidade da gestão. Nosso Kubernetes pode querer mover o pod para outro nó físico. E é aqui que o DevOps entra em ação. Ele deve explicar corretamente a todo o sistema que esses pods só podem ser movidos para os nós nos quais você tem algo montado ao longo desses caminhos, e não mais do que um nó por vez. É muito difícil.
Especialmente para esses fins, criamos templates em nossa operadora para esconder toda essa complexidade. E você poderia simplesmente dizer: “Quero ter uma instância do ClickHouse para cada nó físico e ao longo de tal e tal caminho”.
Mas não somos os únicos que precisam dessa necessidade, então os senhores do próprio Kubernetes também entendem que as pessoas querem ter acesso a discos físicos, por isso fornecem uma terceira camada.
Chama-se local. Praticamente não há diferença em relação ao slide anterior. Só antes era necessário confirmar manualmente que não podemos transferir esses pods de nó para nó, pois eles devem ser anexados ao longo de algum caminho para um disco físico local, mas agora todo esse conhecimento está encapsulado no próprio Kubernetes. E acaba sendo muito mais fácil de configurar.
Voltemos ao nosso problema prático. Voltemos ao modelo YAML. Aqui temos armazenamento real. Estamos de volta. Definimos o modelo clássico VolumeClaim como em k8s. E descrevemos que tipo de armazenamento queremos.
Depois disso, o k8s solicitará armazenamento. Irá alocá-lo para nós no StatefulSet. E no final ficará à disposição da ClickHouse.
Nós tínhamos esse esquema. Nosso armazenamento persistente estava vermelho, o que parecia sugerir que isso precisava ser feito.
E fica verde. Agora o esquema de cluster ClickHouse no k8s está completamente finalizado. Temos shards, réplicas, ZooKeeper, temos um Persistent real, que é implementado de uma forma ou de outra. O esquema já está totalmente operacional.
Continuamos a viver. Nosso cluster está se desenvolvendo. E Alexey tenta e lança uma nova versão do ClickHouse.
Surge uma tarefa prática - testar a nova versão do ClickHouse em nosso cluster. E, naturalmente, você não quer lançar tudo; você quer colocar uma nova versão em uma réplica em algum lugar no canto mais distante, e talvez não uma nova versão, mas duas de uma vez, porque elas são lançadas com frequência.
O que podemos dizer sobre isso?
Aqui temos exatamente essa oportunidade. Estes são modelos de pod. Você pode escrever que nosso operador permite construir completamente um cluster heterogêneo. Aqueles. configurar, começando com todas as réplicas em um grupo, terminando com cada réplica pessoal, qual versão queremos ClickHouse, qual versão queremos armazenamento. Podemos configurar totalmente o cluster com a configuração que precisamos.
Vamos um pouco mais fundo. Antes disso, falamos sobre como funciona o operador ClickHouse em relação às especificidades do ClickHouse.
Agora gostaria de dizer algumas palavras sobre como qualquer operador funciona em geral, bem como como ele interage com os K8s.
Vejamos primeiro como interagir com os K8s. O que acontece quando aplicamos o kubectl? Nossos objetos aparecem no etcd através da API.
Por exemplo, objetos básicos do Kubernetes: pod, StatefulSet, serviço e assim por diante na lista.
Ao mesmo tempo, nada físico acontece ainda. Esses objetos devem ser materializados no cluster.
Para isso, aparece um controlador. O controlador é um componente especial do k8s que pode materializar essas descrições. Ele sabe como e o que fazer fisicamente. Ele sabe rodar containers, o que precisa ser configurado ali para que o servidor funcione.
E materializa nossos objetos em K8s.
Mas queremos operar não apenas com pods e StatefulSets, queremos criar um ClickHouseInstallation, ou seja, um objeto do tipo ClickHouse, para operar com ele como um todo. Até agora não existe essa possibilidade.
Mas o K8s tem a seguinte coisa legal. Queremos que tenhamos uma entidade tão complexa em algum lugar, na qual nosso cluster seja montado a partir de pods e StatefulSet.
E o que precisa ser feito para isso? Primeiro, a definição de recursos personalizados entra em cena. O que é isso? Esta é uma descrição para K8s, que você terá mais um tipo de dados, que queremos adicionar um recurso customizado ao pod, StatefulSet, que será complexo por dentro. Esta é uma descrição da estrutura de dados.
Também enviamos para lá via kubectl apply. Kubernetes aceitou alegremente.
E agora em nosso armazenamento, o objeto no etcd tem a oportunidade de gravar um recurso customizado chamado ClickHouseInstallation.
Mas por enquanto nada mais acontecerá. Ou seja, se agora criarmos o arquivo YAML que vimos descrevendo shards e réplicas e dissermos “kubectl apply”, então o Kubernetes irá aceitá-lo, colocá-lo no etcd e dizer: “Ótimo, mas não sei o que fazer com isso. Não sei como manter o ClickHouseInstallation.”
Conseqüentemente, precisamos de alguém para ajudar o Kubernetes a servir o novo tipo de dados. À esquerda temos um controlador nativo do Kubernetes que funciona com tipos de dados nativos. E à direita devemos ter um controlador personalizado que possa funcionar com tipos de dados personalizados.
E por outro lado é chamado de operador. Incluí-o aqui especificamente como Kubernetes, porque também pode ser executado fora do K8s. Na maioria das vezes, é claro, todos os operadores são executados no Kubernetes, mas nada impede que ele fique do lado de fora, então aqui ele é movido especialmente para fora.
E por sua vez, o controlador customizado, também conhecido como operador, interage com o Kubernetes por meio da API. Já sabe interagir com a API. E ele já sabe materializar o circuito complexo que queremos fazer a partir de um recurso customizado. Isso é exatamente o que o operador faz.
Como funciona a operadora? Vamos olhar para o lado direito para ver como ele faz isso. Vamos descobrir como o operador materializa tudo isso e como ocorre a interação posterior com os K8s.
Um operador é um programa. Ela é voltada para eventos. O operador assina eventos usando a API Kubernetes. A API Kubernetes possui pontos de entrada onde você pode assinar eventos. E se algo mudar no K8s, o Kubernetes envia eventos para todos, ou seja, quem se inscreveu neste ponto da API receberá notificações.
O operador assina eventos e deve fazer algum tipo de reação. Sua tarefa é responder a eventos emergentes.
Os eventos são gerados por determinadas atualizações. Nosso arquivo YAML com uma descrição de ClickHouseInstallation chega. Ele foi para o etcd através do kubectl apply. Um evento foi acionado lá e, como resultado, esse evento chegou ao operador ClickHouse. A operadora recebeu esta descrição. E ele deve fazer alguma coisa. Se uma atualização chegou para o objeto ClickHouseInstallation, você precisará atualizar o cluster. E a tarefa do operador é atualizar o cluster.
O que ele está fazendo? Primeiro, precisamos traçar um plano de ação sobre o que faremos com esta atualização. As atualizações podem ser muito pequenas, ou seja, pequeno na execução YAML, mas pode acarretar mudanças muito grandes no cluster. Portanto, o operador cria um plano e depois o cumpre.
De acordo com esse plano, ele começa a cozinhar essa estrutura por dentro para materializar vagens, serviços, ou seja, fazer qual é sua tarefa principal. Veja como construir um cluster ClickHouse no Kubernetes.
Agora vamos abordar um assunto tão interessante. Esta é uma divisão de responsabilidade entre o Kubernetes e o operador, ou seja, o que o Kubernetes faz, o que o operador faz e como eles interagem entre si.
Kubernetes é responsável pelas coisas do sistema, ou seja, para um conjunto básico de objetos que podem ser interpretados como escopo do sistema. Kubernetes sabe como iniciar pods, como reiniciar contêineres, como montar volumes, como trabalhar com ConfigMap, ou seja, tudo o que pode ser chamado de sistema.
Os operadores operam em domínios. Cada operador é feito para sua própria área de assunto. Fizemos isso para ClickHouse.
E o operador interage justamente na área temática, como adicionar uma réplica, fazer um diagrama, configurar o monitoramento. Isso resulta em uma divisão.
Vejamos um exemplo prático de como ocorre essa divisão de responsabilidades quando realizamos a ação adicionar réplica.
O operador recebe uma tarefa - adicionar uma réplica. O que a operadora faz? O operador calculará que um novo StatefulSet precisa ser criado, no qual tais e tais modelos, declaração de volume, devem ser descritos.
Ele preparou tudo e repassa para K8s. Ele diz que precisa de ConfigMap, StatefulSet, Volume. Kubernetes está funcionando. Ele materializa as unidades básicas com as quais opera.
E então o operador ClickHouse entra em ação novamente. Ele já tem um pod físico no qual já pode fazer alguma coisa. E o operador ClickHouse funciona novamente em termos de domínio. Aqueles. Especificamente ClickHouse, para incluir uma réplica em um cluster, você deve, primeiro, configurar o esquema de dados que existe neste cluster. E, em segundo lugar, esta réplica deve ser incluída na monitorização para que possa ser claramente rastreada. A operadora já configura isso.
E só depois disso o próprio ClickHouse entra em ação, ou seja, outra entidade de nível superior. Este já é um banco de dados. Possui sua própria instância, outra réplica configurada e pronta para ingressar no cluster.
Acontece que a cadeia de execução e divisão de responsabilidades ao adicionar uma réplica é bastante longa.
Continuamos nossas tarefas práticas. Se você já possui um cluster, poderá migrar a configuração.
Fizemos isso para que você possa colar diretamente no xml existente, que o ClickHouse entende.
Você pode ajustar o ClickHouse. Implantação apenas zoneada é o que falei ao explicar hostPath, armazenamento local. Veja como fazer a implantação zoneada corretamente.
A próxima tarefa prática é o monitoramento.
Se nosso cluster mudar, precisaremos configurar o monitoramento periodicamente.
Vejamos o diagrama. Já vimos as setas verdes aqui. Agora vamos dar uma olhada nas setas vermelhas. É assim que queremos monitorar nosso cluster. Como as métricas do cluster ClickHouse chegam ao Prometheus e depois ao Grafana.
Qual é a dificuldade de monitorar? Por que isso é apresentado como algum tipo de conquista? A dificuldade está na dinâmica. Quando temos um cluster e ele é estático, podemos configurar o monitoramento uma vez e não nos preocupar mais.
Mas se tivermos muitos clusters ou se algo estiver mudando constantemente, o processo será dinâmico. E reconfigurar constantemente o monitoramento é uma perda de recursos e de tempo, ou seja, mesmo apenas preguiça. Isso precisa ser automatizado. A dificuldade está na dinâmica do processo. E o operador automatiza isso muito bem.
Como nosso cluster se desenvolveu? No começo ele era assim.
Então ele ficou assim.
No final, ele ficou assim.
E o monitoramento é feito automaticamente pelo operador. Ponto único de entrada.
E logo na saída olhamos o painel do Grafana para ver como a vida do nosso cluster está fervendo por dentro.
A propósito, o painel do Grafana também é distribuído com nossa operadora diretamente no código-fonte. Você pode conectar e usar. Nosso DevOps me deu esta captura de tela.
Para onde gostaríamos de ir a seguir? Esse:
- Desenvolva automação de testes. A principal tarefa é o teste automatizado de novas versões.
- Também queremos automatizar a integração com o ZooKeeper. E há planos de integração com o operador ZooKeeper. Aqueles. Um operador foi escrito para o ZooKeeper e é lógico que os dois operadores comecem a se integrar para construir uma solução mais conveniente.
- Queremos fazer sinais vitais mais complexos.
- Destaquei em verde que estamos nos aproximando da herança de Templates - CONCLUÍDO, ou seja, com a próxima versão da operadora já teremos herança de templates. Esta é uma ferramenta poderosa que permite construir configurações complexas a partir de peças.
- E queremos automação de tarefas complexas. O principal é o Re-sharding.
Vejamos alguns resultados intermediários.
O que obtemos como resultado? E vale a pena fazer ou não? É mesmo necessário tentar arrastar o banco de dados para o Kubernetes e usar o operador em geral e o operador Alitnity em particular?
Na saída obtemos:
- Simplificação e automação significativas de configuração, implantação e manutenção.
- Monitoramento integrado imediatamente.
- E modelos codificados prontos para uso para situações complexas. Uma ação como adicionar uma réplica não precisa ser feita manualmente. A operadora faz isso.
Resta apenas uma última pergunta. Já temos banco de dados em Kubernetes, virtualização. E quanto ao desempenho de tal solução, especialmente porque o ClickHouse é otimizado para desempenho?
A resposta é que está tudo bem! Não entrarei em detalhes; este é o tema de um relatório separado.
Mas existe um projeto como o TSBS. Qual é a sua principal tarefa? Este é um teste de desempenho do banco de dados. Esta é uma tentativa de comparar quente com quente, suave com macio.
Como ele funciona? Um conjunto de dados é gerado. Em seguida, esse conjunto de dados é executado em bancos de dados diferentes usando o mesmo conjunto de testes. E cada banco de dados resolve um problema da maneira que sabe. E então você pode comparar os resultados.
Ele já suporta um grande número de bancos de dados. Identifiquei três principais. Esse:
- Escala de tempoDB.
- InfluxoDB.
- Clique em Casa.
Também foi feita uma comparação com outra solução semelhante. Comparação com RedShift. A comparação foi feita na Amazon. ClickHouse também está bem à frente de todos nesse assunto.
Que conclusões podem ser tiradas do que eu disse?
- Banco de dados no Kubernetes é possível. Provavelmente qualquer coisa é possível, mas no geral parece que é possível. ClickHouse no Kubernetes é definitivamente possível com a ajuda de nossa operadora.
- O operador ajuda a automatizar processos e facilita muito a vida.
- O desempenho é normal.
- E parece-nos que isso pode e deve ser aproveitado.
Código aberto - junte-se a nós!
Como já disse, a operadora é um produto totalmente open source, então seria muito bom se o máximo de pessoas o utilizasse. Junte-se a nós! Esperamos por todos vocês!
Obrigado a todos!
perguntas
Obrigado pelo relatório! Meu nome é Anton. Eu sou do SEMrush. Estou me perguntando o que há com o registro. Ouvimos falar de monitoramento, mas nada de registro, se falarmos de todo o cluster. Por exemplo, criamos um cluster em hardware. E usamos o registro centralizado, coletando-os em uma pilha comum usando meios padrão. E a partir daí obtemos os dados que nos interessam.
Boa pergunta, ou seja, fazer login em uma lista de tarefas. Nosso operador ainda não automatiza isso. Ainda está em desenvolvimento, o projeto ainda é bastante jovem. Compreendemos a necessidade de registro. Este também é um tema muito importante. E provavelmente não é menos importante que o monitoramento. Mas o primeiro item da lista de implementação foi o monitoramento. Haverá registro. Naturalmente, tentamos automatizar todos os aspectos da vida do cluster. Portanto, a resposta é que no momento a operadora, infelizmente, não sabe como fazer isso, mas está nos planos, nós faremos. Se você quiser participar, faça a solicitação, por favor.
Olá! Obrigado pelo relatório! Tenho uma pergunta padrão relacionada a volumes persistentes. Quando criamos uma configuração com este operador, como o operador determina em qual nó temos um determinado disco ou pasta anexado? Devemos primeiro explicar a ele que por favor coloque nosso ClickHouse nesses nós que possuem disco?
Pelo que entendi, esta questão é uma continuação do armazenamento local, especialmente a parte hostPath dele. É como explicar a todo o sistema que o pod precisa ser iniciado em tal ou tal nó, ao qual temos um disco conectado fisicamente, que é montado ao longo de tal ou tal caminho. Esta é uma seção inteira que mencionei muito superficialmente porque a resposta é bastante ampla.
Resumidamente, é assim. Naturalmente, precisamos provisionar esses volumes. No momento, não há provisão dinâmica no armazenamento local, então o DevOps deve cortar os próprios discos, esses volumes. E eles devem explicar o provisionamento do Kubernetes que você terá volumes persistentes de tal e tal classe, que estão localizados em tais e tais nós. Em seguida, você precisará explicar ao Kubernetes que os pods que exigem tal e tal classe de armazenamento local precisam ser direcionados apenas para tais nós usando rótulos. Para isso, o operador tem a capacidade de atribuir algum tipo de rótulo e um por instância de host. E acontece que os pods serão roteados pelo Kubernetes para serem executados apenas em nós que atendam aos requisitos, rótulos, em termos simples. Os administradores atribuem rótulos e provisionam discos manualmente. E então ele aumenta.
E é a terceira opção, local, que ajuda a tornar isso um pouco mais fácil. Como já enfatizei, é um trabalho árduo de ajuste, que acaba ajudando a obter o máximo desempenho.
Tenho uma segunda pergunta relacionada a isso. O Kubernetes foi projetado de tal forma que não nos importa se perdemos um nó ou não. O que devemos fazer neste caso se perdemos o nó onde nosso fragmento está pendurado?
Sim, o Kubernetes foi inicialmente posicionado de que nosso relacionamento com nossos pods é como gado, mas aqui conosco cada disco se torna algo como um animal de estimação. O problema é tão grande que não podemos simplesmente jogá-los fora. E o desenvolvimento do Kubernetes vai na direção de que é impossível tratá-lo completamente filosoficamente, como se fosse um recurso completamente descartado.
Agora, uma questão prática. O que fazer se você perder o nó onde estava o disco? Aqui o problema está sendo resolvido em um nível superior. No caso do ClickHouse, temos réplicas que funcionam em um nível superior, ou seja, no nível ClickHouse.
Qual é a disposição resultante? O DevOps é responsável por garantir que os dados não sejam perdidos. Ele deve configurar a replicação corretamente e garantir que a replicação esteja em execução. A réplica no nível ClickHouse deve ter dados duplicados. Este não é o problema que o operador resolve. E não o problema que o próprio Kubernetes resolve. Isso está no nível ClickHouse.
O que fazer se o seu nó de ferro cair? E acontece que você precisará instalar um segundo, provisionar adequadamente o disco nele e aplicar etiquetas. E depois disso, ele atenderá aos requisitos para que o Kubernetes possa iniciar um pod de instância nele. Kubernetes irá lançá-lo. Seu número de pods não é suficiente para atender ao número especificado. Vai passar pelo ciclo que mostrei. E no nível mais alto, o ClickHouse entenderá que inserimos uma réplica, ela ainda está vazia e precisamos começar a transferir dados para ela. Aqueles. Este processo ainda não está bem automatizado.
Obrigado pelo relatório! Quando todo tipo de coisa desagradável acontece, o operador trava e reinicia, e nesse momento os eventos chegam, você de alguma forma lida com isso?
O que acontece se a operadora travar e reiniciar, certo?
Sim. E nesse momento os acontecimentos chegaram.
A tarefa sobre o que fazer neste caso é parcialmente compartilhada entre o operador e o Kubernetes. O Kubernetes tem a capacidade de reproduzir um evento que ocorreu. Ele repete. E a tarefa do operador é garantir que, quando o log de eventos for reproduzido nele, esses eventos sejam idempotentes. E para que a ocorrência repetida do mesmo evento não quebre nosso sistema. E nosso operador dá conta dessa tarefa.
Olá! Obrigado pelo relatório! Dmitry Zavyalov, empresa Smedova. Existem planos para adicionar a capacidade de configuração com haproxy à operadora? Eu estaria interessado em algum outro balanceador além do padrão, para que seja inteligente e entenda que o ClickHouse realmente existe.
Você está falando sobre o Ingress?
Sim, substitua o Ingress por haproxy. No haproxy você pode especificar a topologia do cluster onde possui réplicas.
Ainda não pensamos nisso. Se você precisar e puder explicar por que é necessário, então será possível implementá-lo, principalmente se você quiser participar. Teremos o maior prazer em considerar a opção. A resposta curta é não, atualmente não temos essa funcionalidade. Obrigado pela dica, vamos analisar esse assunto. E se você também explicar o caso de uso e por que ele é necessário na prática, por exemplo, criar problemas no GitHub, então será ótimo.
Já tem.
Multar. Estamos abertos a qualquer sugestão. E o haproxy é adicionado à lista de tarefas. A lista de tarefas está crescendo, não diminuindo ainda. Mas isso é bom, significa que o produto está em demanda.
Fonte: habr.com