Escalonar verticalmente os clusters do Google Distributed Cloud

Como qualquer cluster do Kubernetes, a escalonabilidade do cluster do Google Distributed Cloud tem muitas dimensões inter-relacionadas. O objetivo deste documento é ajudar você a entender as principais dimensões que podem ser ajustadas para escalonar verticalmente os clusters sem interromper as cargas de trabalho.

Noções básicas sobre os limites

O Google Distributed Cloud é um sistema complexo com uma grande superfície de integração. Há muitas dimensões que afetam a escalonabilidade do cluster. Por exemplo, o número de nós é apenas uma das muitas dimensões em que o Google Distributed Cloud pode escalonar. Outras dimensões incluem o número total de pods e serviços. Muitas dessas dimensões, como o número de pods por nó e o número de nós por cluster, estão inter-relacionadas. Para mais informações sobre as dimensões que afetam a escalonabilidade, consulte Limites de escalonabilidade do Kubernetes na seção "Grupo de interesse especial de escalonabilidade" (SIG, na sigla em inglês) do repositório da comunidade do Kubernetes no GitHub.

Os limites de escalonabilidade também são sensíveis ao hardware e à configuração do nó em que o cluster está sendo executado. Os limites descritos neste documento foram verificados em um ambiente que provavelmente é diferente do seu. Portanto, não é possível reproduzir os mesmos números quando o ambiente subjacente é o fator limitante.

Para mais informações sobre os limites que se aplicam aos seus clusters do Google Distributed Cloud, consulte Cotas e limites.

Prepare-se para o escalonamento

Ao se preparar para escalonar seus clusters do Google Distributed Cloud, considere os requisitos e as limitações descritos nas seções a seguir.

Requisitos de memória e CPU do nó do plano de controle

Na tabela a seguir, descrevemos a configuração recomendada de CPU e memória para nós do plano de controle para clusters que executam cargas de trabalho de produção:

Número de nós do cluster CPUs recomendadas do plano de controle Memória recomendada do plano de controle
1-50 8 núcleos 32 GiB
51-100 16 núcleos 64 GiB

Número de pods e serviços

O número de pods e serviços que você pode ter nos clusters é controlado pelas seguintes configurações:

CIDR do pod e número máximo de nós

O número total de endereços IP reservados para pods no cluster é um dos fatores limitantes para escalonar verticalmente o cluster. Essa configuração, em conjunto com a configuração do máximo de pods por nó, determina o número máximo de nós que é possível ter no cluster antes do risco de esgotar os endereços IP dos pods.

Considere o seguinte:

  • O número total de endereços IP reservados para pods no cluster é especificado com clusterNetwork.pods.cidrBlocks, que usa um intervalo de endereços IP especificados na notação CIDR. Por exemplo, o valor pré-preenchido 192.168.0.0/16 especifica um intervalo de 65.536 endereços IP de 192.168.0.0 a 192.168.255.255.

  • O número máximo de pods que podem ser executados em um único nó é especificado com nodeConfig.podDensity.maxPodsPerNode.

  • Com base na configuração máxima de pods por nó, o Google Distributed Cloud provisiona cerca de duas vezes mais endereços IP para o nó. Os endereços IP extras ajudam a impedir a reutilização inadvertida dos IPs de pod em um curto período.

  • Dividir o número total de endereços IP do pod pelo número de endereços IP do pod provisionados em cada nó resulta no número total de nós que podem ser incluídos no cluster.

Por exemplo, se o CIDR do seu pod for 192.168.0.0/17, você terá um total de 32.768 endereços IP (2(32-17) = 215 = 32.768). Se você definir o número máximo de pods por nó como 250, o Google Distributed Cloud provisionará um intervalo de aproximadamente 500 endereços IP, o que é aproximadamente equivalente a um bloco CIDR /23 (2(32-23) = 29 = 512). Portanto, o número máximo de nós nesse caso é 64 (215 endereços/cluster divididos por 29 endereços/nó = 2(15-9) nós/cluster = 26 = 64 nós/cluster.

clusterNetwork.pods.cidrBlocks e nodeConfig.podDensity.maxPodsPerNode são imutáveis. Portanto, planeje cuidadosamente o crescimento futuro do cluster para evitar a falta da capacidade do nó. Para saber os limites máximos recomendados para pods por cluster, pods por nó e nós por cluster com base em testes, consulte Limites.

CIDR de serviço

O CIDR de serviço pode ser atualizado para adicionar mais serviços à medida que você escalonar verticalmente seu cluster. Não é possível, no entanto, reduzir o intervalo CIDR de serviço. Para mais informações, consulte Aumentar o intervalo da rede de serviço.

Recursos reservados para daemons do sistema

Por padrão, o Google Distributed Cloud reserva recursos automaticamente em um nó para daemons do sistema, como sshd ou udev. Os recursos de CPU e memória são reservados em um nó para que os daemons do sistema tenham os recursos necessários. Sem esse recurso, os pods podem consumir potencialmente a maioria dos recursos em um nó, impossibilitando que os daemons do sistema concluam suas tarefas.

Especificamente, o Google Distributed Cloud reserva 80 millicores de CPU (80 mCPU) e 280 mebibytes (280 MiB) de memória em cada nó para daemons do sistema. Observe que a unidade de CPU mCPU significa milésimo de um núcleo. Portanto, 80/1000 ou 8% de um núcleo em cada nó são reservados para daemons do sistema. A quantidade de recursos reservados é pequena e não tem um impacto significativo no desempenho do pod. No entanto, o kubelet em um nó poderá remover pods se o uso de CPU ou memória exceder as quantidades alocadas para eles.

Rede com o MetalLB

Convém aumentar o número de alto-falantes MetalLB para abordar os seguintes aspectos:

  • Largura de banda: toda a largura de banda do cluster para serviços de balanceamento de carga depende do número de alto-falantes e da largura de banda de cada nó. O aumento do tráfego de rede requer mais alto-falantes.

  • Tolerância a falhas: um número maior de alto-falantes reduz o impacto geral de uma falha nos alto-falantes.

O MetalLB exige conectividade da camada 2 entre os nós de balanceamento de carga. Nesse caso, você pode ser limitado pelo número de nós com conectividade de Camada 2 em que é possível colocar alto-falantes MetalLB.

Planeje cuidadosamente quantos alto-falantes MetalLB você quer ter no cluster e determine quantos nós da camada 2 são necessários. Para mais informações, consulte Problemas de escalonabilidade do MetalLB.

Separadamente, ao usar o modo de balanceamento de carga em pacote, os nós do plano de controle também precisam estar na mesma rede de camada 2. O balanceamento de carga manual não tem essa restrição. Para mais informações, consulte Modo do balanceador de carga manual.

Execução de muitos nós, pods e serviços

Adicionar nós, pods e serviços é uma maneira de escalonar verticalmente o cluster verticalmente. As seções a seguir abordam algumas definições adicionais e configurações que precisam ser consideradas ao aumentar o número de nós, pods e serviços no cluster. Para mais informações sobre os limites dessas dimensões e como eles se relacionam, consulte Limites.

Criar um cluster sem kube-proxy

Para criar um cluster de alto desempenho que possa ser escalonar verticalmente para usar um grande número de serviços e endpoints, recomendamos que você crie o cluster sem kube-proxy. Sem kube-proxy, o cluster usa o GKE Dataplane V2 no modo kube-proxy-replacement. Esse modo evita o consumo de recursos necessário para manter um grande conjunto de regras iptables.

Não é possível desativar o uso de kube-proxy em um cluster atual. Essa configuração precisa ser definida quando o cluster é criado. Para instruções e mais informações, consulte Criar um cluster sem kube-proxy.

Configuração do CoreDNS

Nesta seção, descrevemos aspectos do CoreDNS que afetam a escalonabilidade dos clusters.

DNS do pod

Por padrão, os clusters do Google Distributed Cloud injetam pods com um resolv.conf parecido com este:

nameserver KUBEDNS_CLUSTER_IP
search <NAMESPACE>.svc.cluster.local svc.cluster.local cluster.local c.PROJECT_ID.internal google.internal
options ndots:5

A opção ndots:5 significa que os nomes de host com menos de cinco pontos não são considerados um nome de domínio totalmente qualificado (FQDN, na sigla em inglês). O servidor DNS anexa todos os domínios de pesquisa especificados antes de pesquisar o nome do host solicitado originalmente, que ordena a busca da seguinte forma ao resolver google.com:

  1. google.com.NAMESPACE.svc.cluster.local
  2. google.com.svc.cluster.local
  3. google.com.cluster.local
  4. google.com.c.PROJECT_ID.internal
  5. google.com.google.internal
  6. google.com

Cada uma das pesquisas é realizada para IPv4 (registro A) e IPv6 (registro AAAA), resultando em 12 solicitações DNS para cada consulta não FQDN, o que amplifica significativamente o tráfego DNS. Para atenuar esse problema, recomendamos declarar o nome do host a ser pesquisado como FQDN. Para isso, adicione um ponto final (google.com.). Essa declaração precisa ser feita no nível da carga de trabalho do aplicativo. Para mais informações, consulte a página do manual resolv.conf.

IPv6

Se o cluster não estiver usando IPv6, será possível reduzir as solicitações de DNS pela metade, eliminando a pesquisa do registro AAAA para o servidor DNS upstream. Se você precisar de ajuda para desativar as pesquisas do AAAA, entre em contato com o Cloud Customer Care.

Pool de nós dedicado

Devido à natureza crítica das consultas DNS nos ciclos de vida dos aplicativos, recomendamos que você use nós dedicados para a implantação de coredns. Essa implantação se enquadra em um domínio de falha diferente dos aplicativos normais. Se você precisar de ajuda para configurar nós dedicados para a implantação do coredns, entre em contato com o Cloud Customer Care.

Problemas de escalonabilidade do MetalLB

O MetalLB é executado no modo ativo-passivo, o que significa que, a qualquer momento, há apenas um alto-falante do MetalLB atendendo a um VIP LoadBalancer específico.

Failover

Antes da versão 1.28.0 do Google Distributed Cloud, em grande escala, o failover do MetalLB podia levar muito tempo e apresentar um risco de confiabilidade ao cluster.

Limites de conexão

Se houver um VIP LoadBalancer específico, como um serviço de entrada, que espera ter próximas ou mais de 30 mil conexões simultâneas, é provável que o nó do alto-falante que processa o VIP esgote as portas disponíveis. Devido a uma limitação de arquitetura, não há mitigação para esse problema do MetalLB. Considere mudar para o balanceamento de carga em pacote com BGP antes da criação do cluster ou usar uma classe de entrada diferente. Para mais informações, consulte Configuração do Ingress.

Alto-falantes com balanceador de carga

Por padrão, o Google Distributed Cloud usa o mesmo pool de nós do balanceador de carga para o plano de controle e o de dados. Se você não especificar um pool de nós do balanceador de carga (loadBalancer.nodePoolSpec), o pool de nós do plano de controle (controlPlane.nodePoolSpec) será usado.

Para aumentar o número de alto-falantes ao usar o pool de nós do plano de controle para balanceamento de carga, é preciso aumentar o número de máquinas do plano de controle. Para implantações de produção, recomendamos usar três nós do plano de controle para alta disponibilidade. Aumentar o número de nós do plano de controle para mais de três para acomodar outros alto-falantes pode não ser um bom uso dos seus recursos.

Configuração de entrada

Se você espera cerca de 30 mil conexões simultâneas chegando a um único VIP de serviço LoadBalancer, o MetalLB talvez não ofereça suporte a ele.

Você pode considerar a exposição do VIP por outros mecanismos, como F5 BIG-IP. Como alternativa, você pode criar um novo cluster usando o balanceamento de carga em pacote com BGP, que não tem a mesma limitação.

Ajustar os componentes do Cloud Logging e do Cloud Monitoring

Em clusters grandes, dependendo dos perfis de aplicativo e do padrão de tráfego, as configurações de recursos padrão dos componentes do Cloud Logging e do Cloud Monitoring podem não ser suficientes. Para instruções sobre como ajustar as solicitações e os limites de recursos dos componentes de observabilidade, consulte Como configurar recursos do componente Stackdriver.

Em particular, o kube-state-metrics em clusters com um grande número de serviços e endpoints podem causar uso excessivo de memória no próprio kube-state-metrics e no gke-metrics-agent no mesmo nó. O uso de recursos do metrics-server também pode serreduzir escalonamento horizontalm termos de nós, pods e serviços. Se você tiver problemas com recursos nesses componentes, entre em contato com o Cloud Customer Care.

Usar sysctl para configurar seu sistema operacional

Recomendamos que você ajuste a configuração do sistema operacional para que seus nós se adaptem melhor ao seu caso de uso de carga de trabalho. Os parâmetros fs.inotify.max_user_watches e fs.inotify.max_user_instances que controlam o número de recursos do inotify geralmente precisam de ajustes. Por exemplo, se forem exibidas mensagens de erro como as seguintes, convém verificar se esses parâmetros precisam ser ajustados:

The configured user limit (128) on the number of inotify instances has been reached

ENOSPC: System limit for number of file watchers reached...

O ajuste geralmente varia de acordo com os tipos de carga de trabalho e a configuração de hardware. Consulte o seu fornecedor de SO sobre as práticas recomendadas específicas para SO.

Práticas recomendadas

Nesta seção, descrevemos as práticas recomendadas para escalonar verticalmente o cluster.

Dimensionar uma dimensão de cada vez

Para minimizar os problemas e facilitar a reverter das alterações, não ajuste mais de uma dimensão por vez. O escalonamento vertical de várias dimensões simultaneamente pode causar problemas até em clusters menores. Por exemplo, tentar aumentar o número de pods programados por nó para 110 e, ao mesmo tempo, aumentar o número de nós no cluster para 250, provavelmente não será bem-sucedido porque o número de pods, o número de pods por nó e o número de nós estão muito distantes.

Escalonar clusters em etapas

O escalonamento vertical de um cluster pode consumir muitos recursos. Para reduzir o risco de falha das operações de cluster ou de interrupções das cargas de trabalho do cluster, não recomendamos tentar criar clusters grandes com muitos nós em uma única operação.

Criar clusters híbridos ou independentes sem nós de trabalho

Se você estiver criando um grande cluster híbrido ou autônomo com mais de 50 nós de trabalho, é melhor criar um cluster de alta disponibilidade (HA, na sigla em inglês) com nós do plano de controle primeiro e depois escalonar verticalmente gradualmente. A operação de criação de cluster usa um cluster de inicialização, que não tem alta disponibilidade e, portanto, é menos confiável. Depois que o cluster híbrido ou autônomo de alta disponibilidade for criado, use-o para escalonar verticalmente para mais nós.

Aumentar o número de nós de trabalho em lotes

Se você estiver expandindo um cluster para mais nós de trabalho, é melhor expandir por etapas. Recomendamos que você não adicione mais do que 20 nós por vez. Isso é especialmente verdadeiro para clusters que estão executando cargas de trabalho críticas.

Ativar pulls paralelos de imagens

Por padrão, o kubelet extrai imagens em série, uma após a outra. Se você tiver uma conexão upstream inválida com o servidor de registro de imagem, um pull de imagem incorreto poderá paralisar toda a fila de um determinado pool de nós.

Para atenuar isso, recomendamos que você defina serializeImagePulls como false na configuração personalizada do kubelet. Para instruções e mais informações, consulte Configurar configurações de pull de imagem do kubelet. A ativação de pulls de imagens paralelas pode introduzir picos no consumo de largura de banda da rede ou de E/S de disco.

Ajustar as solicitações e os limites dos recursos do aplicativo

Em ambientes densamente empacotados, as cargas de trabalho de aplicativos podem ser despejadas. O Kubernetes usa o mecanismo referenciado para classificar pods em caso de remoção.

Uma boa prática para definir os recursos de contêiner é usar a mesma quantidade de memória para solicitações e limites e um limite de CPU maior ou ilimitado. Para mais informações, consulte Preparar aplicativos do Kubernetes baseados na nuvem no Centro de arquitetura do Cloud.

Usar um parceiro de armazenamento

Recomendamos que você use um dos parceiros de armazenamento GDCV Ready para implantações em grande escala. É importante confirmar as seguintes informações com o parceiro de armazenamento específico:

  • As implantações de armazenamento seguem as práticas recomendadas para aspectos de armazenamento, como alta disponibilidade, configuração de prioridade, afinidades de nós e solicitações e limites de recursos.
  • A versão de armazenamento é qualificada com a versão específica do Google Distributed Cloud.
  • O fornecedor de armazenamento oferece suporte à alta escala que você quer implantar.

Configurar clusters para alta disponibilidade

É importante auditar sua implantação de alta escala e garantir que os componentes críticos estejam configurados para alta disponibilidade sempre que possível. O Google Distributed Cloud oferece suporte a opções de implantação de alta disponibilidade para Para mais informações, consulte Escolher um modelo de implantação. Para ver exemplos de arquivos de configuração de cluster de implantações de alta disponibilidade, consulte Amostras de configuração de cluster.

Também é importante auditar outros componentes, incluindo:

  • Fornecedor de armazenamento
  • Webhooks de cluster

Como monitorar o uso de recursos

Nesta seção, fornecemos algumas recomendações básicas de monitoramento para clusters de grande escala.

Monitore de perto as métricas de utilização

É fundamental monitorar a utilização de nós e componentes individuais do sistema e garantir que eles tenham uma margem confortavelmente segura. Para saber quais recursos de monitoramento padrão estão disponíveis por padrão, consulte Usar painéis predefinidos.

Monitorar o consumo de largura de banda

Monitore de perto o consumo da largura de banda para garantir que a rede não esteja sendo saturada, o que resulta na degradação do desempenho do cluster.

Melhorar a performance do etcd

A velocidade do disco é fundamental para o desempenho e a estabilidade do etcd. Um disco lento aumenta a latência da solicitação de etcd, o que pode levar a problemas de estabilidade do cluster. Para melhorar o desempenho do cluster, o Google Distributed Cloud armazena objetos de eventos em uma instância separada e dedicada do etcd. A instância padrão do etcd usa /var/lib/etcd como diretório de dados e a porta 2379 para solicitações de cliente. A instância etcd-events usa /var/lib/etcd-events como diretório de dados e a porta 2382 para solicitações do cliente.

Recomendamos que você use um disco de estado sólido (SSD) para os armazenamentos etcd. Para um desempenho ideal, ative discos separados em /var/lib/etcd e /var/lib/etcd-events. O uso de discos dedicados garante que as duas instâncias do etcd não compartilhem E/S de disco.

A documentação do etcd fornece recomendações de hardware adicionais para garantir o melhor desempenho do etcd ao executar seus clusters na produção.

Para verificar o desempenho do disco e do etcd, use as seguintes métricas de latência de E/S no etcd no Metrics Explorer:

  • etcd_disk_backend_commit_duration_seconds: a duração precisa ser inferior a 25 milissegundos para o 99o percentil (p99).
  • etcd_disk_wal_fsync_duration_seconds: a duração precisa ser inferior a 10 milissegundos para o 99o percentil (p99).

Para mais informações sobre o desempenho do etcd, consulte O que significa o aviso "Aplicar entradas levou muito tempo"? e O que significa o aviso do etcd "falha ao enviar o batimento de funcionamento no horário"?.

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.

A seguir