Skip to main content
Esta página descreve as várias opções de configuração de infraestrutura disponíveis para sua implantação BYOC. Essas configurações permitem personalizar a rede, a segurança e os recursos de computação para atender às suas necessidades específicas.

​
Balanceadores de carga

As implantações BYOC usam Network Load Balancers (NLBs) para gerenciar e direcionar o tráfego para seus serviços ClickHouse. Você pode escolher entre endpoints de balanceador de carga públicos e privados, de acordo com o seu modelo de rede. Balanceador de carga público:
  • Fornece acesso público (voltado para a internet) aos seus serviços ClickHouse.
  • Normalmente é ativado por padrão ao usar uma VPC dedicada gerenciada pela ClickHouse.
  • Fica desativado por padrão ao usar uma VPC gerenciada pelo cliente, para maior segurança.
Balanceador de carga privado:
  • Fornece acesso privado (interno), acessível somente de dentro das redes conectadas.
  • Normalmente é ativado por padrão ao usar uma VPC gerenciada pelo cliente.
  • Fica desativado por padrão ao usar uma VPC dedicada gerenciada pela ClickHouse.
Você pode ativar o balanceador de carga privado para sua infraestrutura BYOC diretamente no ClickHouse Cloud console. Para outros ajustes de endpoint (por exemplo, remover o balanceador de carga público), entre em contato com o ClickHouse Cloud Support.

​
Security Group do balanceador de carga privado para AWS

Se você optar por usar um balanceador de carga privado na sua implantação BYOC, deverá garantir que as regras apropriadas de Security Group estejam em vigor para permitir o acesso a partir das suas redes privadas pretendidas (como VPCs emparelhadas). Por padrão, o Security Group só permite tráfego dentro da VPC. Para configurar o Security Group do seu balanceador de carga privado: Entre em contato com o suporte do ClickHouse para solicitar alterações nas regras de entrada do Security Group, permitindo tráfego das suas redes de origem específicas:
  • VPC Peering: Solicite regras para permitir tráfego dos intervalos CIDR das suas VPCs emparelhadas.
  • PrivateLink: Nenhuma alteração no Security Group é necessária, pois o tráfego não é controlado pelo Security Group do balanceador de carga.
  • Outras configurações de rede: Especifique seu cenário para que o suporte possa orientar você adequadamente.
Todas as alterações nos Security Groups de balanceadores de carga privados devem ser realizadas pelo suporte do ClickHouse. Isso garante a consistência da configuração e evita conflitos no ambiente gerenciado pelo ClickHouse Cloud.
Para máximo isolamento e segurança de rede, as implantações BYOC podem usar AWS PrivateLink, GCP Private Service Connect ou Azure Private Link. Essas opções permitem que seus aplicativos se conectem de forma privada aos serviços do ClickHouse Cloud sem exigir VPC/VNet peering nem expor endpoints à internet pública. Para ver instruções de configuração passo a passo, consulte o guia de configuração de rede privada.

​
Conexão privada com a API do Kubernetes

Por padrão, o endpoint do servidor da API do Kubernetes do seu cluster BYOC fica acessível pela internet pública. Na AWS, o acesso é restrito por filtragem de IP para permitir apenas os IPs do NAT Gateway do ClickHouse; no GCP e no Azure, ele é controlado pelo IAM da nuvem (consulte Exposição do servidor da API do Kubernetes). Para maior segurança, você pode restringir o servidor da API do Kubernetes para que ele fique acessível exclusivamente por conexões de rede privadas. As opções de conexão privada disponíveis dependem do seu provedor de nuvem:

​
Tailscale (padrão)

Quando um endpoint privado da API está habilitado, os serviços de gerenciamento do ClickHouse se conectam ao servidor da API do Kubernetes pela mesma rede Tailscale de confiança zero usada para acesso para solução de problemas. Consulte Tailscale Private Network para saber como essa conexão funciona.
Se você depender exclusivamente do Tailscale para conectividade privada, há o risco de que o suporte do ClickHouse perca o acesso ao seu ambiente caso o agente do Tailscale fique indisponível. Isso pode atrasar a solução de problemas ou o tempo de resposta do suporte.

​
AWS VPC Lattice

A conectividade do VPC Lattice está atualmente em prévia privada. Entre em contato com o suporte do ClickHouse para habilitá-la na sua implantação.
Para implantações na AWS, o servidor da API do Kubernetes também pode ser acessado de forma privada por meio do AWS VPC Lattice, sem o envolvimento de componentes de terceiros:
  • O ClickHouse Cloud provisiona automaticamente um VPC Lattice Resource Gateway e uma Resource Configuration direcionada ao endpoint do servidor de API do EKS dentro da sua BYOC VPC, e compartilha a Resource Configuration com a conta de gerenciamento do ClickHouse Cloud por meio do AWS Resource Access Manager (RAM).
  • O tráfego entre os serviços de gerenciamento do ClickHouse e o seu servidor da API do Kubernetes permanece inteiramente na rede privada da AWS.
  • O compartilhamento no RAM é criado a partir da sua conta e fica limitado a um único cluster BYOC; excluí-lo revoga imediatamente o caminho de acesso privado.
  • Como o acesso não depende de um agente em execução dentro do seu cluster do Kubernetes, o suporte do ClickHouse mantém o acesso para solução de problemas mesmo que os componentes no cluster não estejam disponíveis.

​
Endpoint privado do control plane no GCP

Em implantações no GCP, o endpoint do control plane baseado em IP do cluster GKE pode ser desabilitado, deixando de ser acessível pela internet pública. Com isso, os serviços de gerenciamento do ClickHouse passam a acessar o control plane pelo endpoint baseado em DNS (*.gke.goog), cuja autorização é feita pela permissão IAM container.clusters.connect na service account que o ClickHouse personifica no seu projeto, e não por uma allow list de IPs de origem.
  • O acesso é controlado inteiramente pelo IAM de nuvem do seu projeto; portanto, revogar essa permissão revoga esse caminho de acesso.
  • A requisição termina no frontend do Google, e não dentro da sua rede VPC; portanto, avalie-a como um caminho de acesso ao seu control plane, e não como um link de rede privado.
  • O acesso de solução de problemas dos engenheiros do ClickHouse continua sendo feito pelo Tailscale.

​
Azure Private Link

Para implantações no Azure, o servidor de API do AKS pode ser acessado de forma privada por meio do Azure Private Link:
  • O cluster é criado como um cluster privado com API Server VNet Integration, e seu FQDN público fica desabilitado.
  • O ClickHouse Cloud provisiona um Private Link Service na sua assinatura, na frente do balanceador de carga interno do servidor de API, junto com um private endpoint correspondente na VNet de gerenciamento do ClickHouse Cloud. A conexão é aprovada automaticamente somente para a assinatura de gerenciamento do ClickHouse Cloud.
  • O tráfego entre os serviços de gerenciamento do ClickHouse e o seu servidor de API permanece no backbone do Azure.
  • O acesso dos engenheiros do ClickHouse para solução de problemas continua sendo feito pelo Tailscale.
Entre em contato com o suporte do ClickHouse para solicitar a configuração de um endpoint de API privado.

​
Grupos de nós

Os grupos de nós do Kubernetes são conjuntos de instâncias de computação que fornecem os recursos necessários para executar seus serviços ClickHouse em uma implantação BYOC. O ClickHouse Cloud gerencia esses grupos de nós, cuidando automaticamente tanto da configuração quanto do escalonamento.

​
Configuração padrão

Os clusters BYOC são provisionados com dois tipos principais de grupos de nós:
  • Grupo de Nós do Sistema Hospeda cargas de trabalho essenciais do sistema, como o ClickHouse Operator, o Istio (para malha de serviços), componentes de monitoramento (Prometheus, Grafana, AlertManager), o cluster autoscaler e outros serviços centrais. Esses nós normalmente usam tipos de instância x86 padrão.
  • Grupos de Nós de Carga de Trabalho Dedicados às cargas de trabalho de dados do ClickHouse, incluindo servidores e serviços Keeper. Por padrão, os nós de carga de trabalho são executados em instâncias baseadas em ARM, oferecendo um equilíbrio eficiente entre desempenho e custo. No entanto, eles também podem ser configurados com perfis alternativos de CPU/memória ou alterados para a arquitetura x86 mediante solicitação.

​
Personalizando grupos de nós

Precisa de recursos ou arquiteturas específicas? As seguintes personalizações estão disponíveis — entre em contato com o suporte do ClickHouse para discutir e implementar:
  • Seleção de tipos de instância Escolha tipos de instância específicos para atender a requisitos como desempenho, conformidade, alta capacidade de memória/CPU ou uso de recursos reservados.
  • Proporções de CPU/Memória Ajuste o perfil de computação dos grupos de nós de carga de trabalho conforme necessário.
  • Arquitetura Altere os grupos de nós de carga de trabalho de ARM para x86, se necessário.
Observação: instâncias Spot (preemptíveis) não são compatíveis; todos os grupos de nós BYOC são executados em instâncias sob demanda por padrão.
Todas as personalizações de grupos de nós e alterações de configuração devem ser coordenadas por meio do suporte do ClickHouse. Isso garante compatibilidade, estabilidade e desempenho ideal.

​
Escalonamento automático

Os grupos de nós do cluster são escalonados automaticamente por meio do cluster autoscaler, de acordo com:
  • Solicitações e limites de recursos dos pods do Kubernetes
  • Capacidade e utilização gerais do cluster
  • Necessidades de escalonamento do serviço ClickHouse
Nenhuma intervenção manual é necessária. O ClickHouse Cloud gerencia continuamente os recursos e o escalonamento da sua implantação.
Última modificação em 26 de setembro de 2026