Skip to main content
Este guia explica como configurar clusters do ClickHouse e do Keeper usando o operador.

Configuração do ClickHouseCluster

Configuração básica

Réplicas e shards

  • Réplicas: Número de instâncias do ClickHouse em cada shard (para alta disponibilidade)
  • Shards: Número de partições horizontais (para escalabilidade)
Um cluster com replicas: 3 e shards: 2 criará 6 pods do ClickHouse ao todo.

Integração com o Keeper

Todo cluster do ClickHouse deve fazer referência a um KeeperCluster para coordenação:
Quando keeperClusterRef.namespace estiver definido, o operador deverá monitorar ambos os espaços de nomes. Se WATCH_NAMESPACE estiver configurado, inclua os espaços de nomes do ClickHouse e do Keeper nessa lista.

Configuração do KeeperCluster

Configuração de armazenamento

Configure o armazenamento persistente:
O Operator só pode modificar um PVC existente se a classe de armazenamento subjacente oferecer suporte à expansão de volume.

Configuração do pod do Kubernetes

Distribuição automática por topologia e afinidade

Distribua os pods entre zonas de disponibilidade:
Garanta que seu cluster do Kubernetes tenha nós suficientes em zonas diferentes para atender às restrições de distribuição.

Configuração manual

É possível especificar regras arbitrárias de afinidade/anti-afinidade entre pods do Kubernetes e restrições de distribuição de topologia.

Consulte a Referência da API para ver todas as opções de template de pod do Kubernetes compatíveis.

Orçamentos de interrupção de pods

O operador cria um PodDisruptionBudget (PDB) para cada cluster, para que interrupções voluntárias — drenagens de nós, atualizações graduais e evicções do autoscaler — não possam derrubar pods suficientes a ponto de causar perda de quórum ou comprometer a disponibilidade. Para clusters do ClickHouse com mais de um shard, é criado um PDB por shard para que uma interrupção em um shard não seja contabilizada contra outro.

Valores padrão

O operador escolhe valores padrão seguros com base no tamanho do cluster para que um novo apply já proteja contra perda acidental de quórum. Para um ClickHouseCluster com 3 shards e replicas: 3, o operador cria três PDBs, um por shard, cada um com minAvailable: 1.

Substituindo os padrões

Use spec.podDisruptionBudget para substituir minAvailable ou maxUnavailable (exatamente um):
Ou no formato maxUnavailable, com uma porcentagem:
Definir minAvailable e maxUnavailable ao mesmo tempo é rejeitado pelo webhook de validação. Escolha um deles — o próprio Kubernetes também não permite os dois.
Você também pode passar o campo unhealthyPodEvictionPolicy para o PDB gerado — útil quando precisar permitir a evicção de pods que ainda estão em NotReady:

Políticas

spec.podDisruptionBudget.policy permite escolher com que nível de rigor o operador gerencia os PDBs: Exemplo — desative completamente o gerenciamento de PDBs em um cluster de desenvolvimento:
Exemplo — mantenha seu PDB criado manualmente junto ao cluster e impeça que o operador interfira nele:

Desativação em nível de cluster

O gerenciamento de PDB também pode ser desativado em nível de cluster por meio da variável de ambiente ENABLE_PDB do operator. Com ENABLE_PDB=false, o operator ignora a etapa de reconciliação de PDB para todos os ClickHouseCluster e KeeperCluster, independentemente de spec.podDisruptionBudget.policy, e não monitora recursos PodDisruptionBudget de forma alguma. Portanto, o ServiceAccount do operator não precisa de permissões de RBAC em poddisruptionbudgets.policy/v1, o que é útil ao executar o operator com um ServiceAccount restrito que omite essas permissões intencionalmente.
Isto se destina a ambientes que implementam suas próprias políticas de interrupção (por exemplo, por meio do Gatekeeper / Kyverno) e querem deixar o operator totalmente fora desse processo.

Configuração do contêiner

Imagem personalizada

Use uma imagem específica do ClickHouse:

Recursos de contêiner

Configure CPU e memória para os contêineres do ClickHouse:

Variáveis de ambiente

Adicione variáveis de ambiente personalizadas:

Montagem de volumes

Adicione montagens adicionais de volumes:
É permitido especificar várias montagens de volume no mesmo mountPath. O Operator criará um volume projetado com todas as montagens especificadas.

Consulte a Referência da API para ver todas as opções de template de contêiner suportadas.

Configuração de TLS/SSL

Configure endpoints seguros

Passe uma referência a um Secret do Kubernetes que contenha certificados TLS para ativar endpoints seguros

Formato do Secret de certificado SSL

Espera-se que o Secret contenha as seguintes chaves:
  • tls.crt - certificado do servidor codificado em PEM
  • tls.key - chave privada codificada em PEM
  • ca.crt - cadeia de certificados da CA codificada em PEM
Esse formato é compatível com certificados gerados pelo cert-manager.

Comunicação entre ClickHouse e Keeper via TLS

Se o KeeperCluster tiver TLS habilitado, o ClickHouseCluster usará automaticamente uma conexão segura com os nós do Keeper. O ClickHouseCluster deve conseguir verificar os certificados dos nós do Keeper. Se o ClickHouseCluster tiver TLS habilitado, ele usará o bundle ca.crt para a verificação. Caso contrário, será usado o bundle de CA padrão. O usuário pode fornecer uma referência para um bundle de CA personalizado:

Configurações do ClickHouse

Senha padrão do usuário

Defina a senha do usuário padrão:
Não é recomendável usar ConfigMap para armazenar senhas em texto simples.
Crie o Secret:

Usando ConfigMap para senhas de usuários

Você também pode usar o ConfigMap para senhas padrão não sensíveis:

Usuários personalizados na configuração

Configure usuários adicionais em arquivos de configuração. Crie um ConfigMap e um Secret para o usuário:
Adicione uma configuração personalizada ao ClickHouseCluster:

Sincronização do banco de dados

Ative a sincronização automática do banco de dados para novas réplicas:
Quando ativado, o operator sincroniza as tabelas Replicated e de integração para novas réplicas.

Configuração personalizada

Configuração adicional embutida

Em vez de montar arquivos de configuração personalizados, você pode especificar diretamente opções adicionais de configuração do ClickHouse. Adicione uma configuração personalizada do ClickHouse usando extraConfig:

Configuração embutida de usuários adicionais

Você também pode especificar uma configuração adicional de usuários do ClickHouse usando extraUsersConfig. Isso é útil para definir usuários, perfis, quotas e permissões diretamente na especificação do cluster.
O extraUsersConfig é armazenado em um objeto ConfigMap do k8s. Evite armazenar segredos em texto puro nele.

Consulte a documentação para ver todas as opções de configuração de usuários do ClickHouse suportadas.

Exemplo de configuração

Exemplo completo de configuração:
Última modificação em 12 de junho de 2026