> ## Documentation Index > Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Configuração de infraestrutura > Configure balanceadores de carga, grupos de nós e outros componentes de infraestrutura do BYOC 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. | Tipo de balanceador de carga | VPC dedicada gerenciada pela ClickHouse | VPC gerenciada pelo cliente | | ---------------------------- | :-------------------------------------: | :-------------------------: | | **NLB público** | Ativado por padrão | Desativado por padrão | | **NLB privado** | Desativado por padrão | Ativado por padrão | **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 entrar em contato com o **ClickHouse Cloud Support** para ajustar quais endpoints ficam ativados com base nos seus requisitos.
### 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** ou **GCP Private Service Connect**. Essas opções permitem que seus aplicativos se conectem de forma privada aos serviços do ClickHouse Cloud sem exigir VPC 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](/docs/pt-BR/products/bring-your-own-cloud/onboarding/network).
## 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, mas o acesso é restrito por filtragem de IP para permitir apenas os IPs do NAT Gateway do ClickHouse. 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. Há duas opções de conexão privada disponíveis:
### 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](/docs/pt-BR/products/bring-your-own-cloud/reference/network-security#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](https://aws.amazon.com/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. **Entre em contato com o suporte do ClickHouse** para solicitar a configuração de um endpoint de API privada.
## 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.