Escalonar clusters do Google Distributed Cloud

Como qualquer cluster do Kubernetes, a escalonabilidade do cluster do Google Distributed Cloud tem muitas dimensões relacionadas. Este documento tem como objetivo 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 entre muitas dimensões em que o Google Distributed Cloud pode ser escalonado. 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 relacionadas. Para mais informações sobre as dimensões que afetam a escalonabilidade, consulte Limites de escalonabilidade do Kubernetes na seção do grupo de interesse especial (SIG) de escalonabilidade do repositório da comunidade do Kubernetes no GitHub.

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

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

Preparar para escalonar

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

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

A tabela a seguir descreve a configuração recomendada de CPU e memória para nós de plano de controle em clusters que executam cargas de trabalho de produção:

Número de nós do cluster CPUs recomendadas para o 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 limitadores para aumentar o cluster. Essa configuração, juntamente com a configuração de pods máximos por nó, determina o número máximo de nós que você pode ter no cluster antes 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 predefinido 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 aproximadamente o dobro de endereços IP para o nó. Os endereços IP extras ajudam a evitar a reutilização acidental dos IPs do pod em um curto período.

  • Divida o número total de endereços IP do pod pelo número de endereços IP do pod provisionados em cada nó para saber o número total de nós que podem ser adicionados ao cluster.

Por exemplo, se o CIDR do 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. Planeje cuidadosamente o crescimento futuro do cluster para evitar a falta de capacidade do nó. Para os máximos recomendados de pods por cluster, pods por nó e nós por cluster com base nos testes, consulte Limites.

CIDR de Serviço

O CIDR de serviço pode ser atualizado para adicionar mais serviços conforme você escalonar verticalmente o cluster. No entanto, não é possível reduzir o intervalo de CIDR do serviço. Para mais informações, consulte Aumentar o intervalo da rede de serviços.

Recursos reservados para daemons do sistema

Por padrão, o Google Distributed Cloud reserva automaticamente recursos 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 daemons do sistema. Assim, eles terão os recursos necessários. Sem esse recurso, os pods podem consumir a maioria dos recursos em um nó, impossibilitando que daemons do sistema concluam as tarefas.

Especificamente, o Google Distributed Cloud reserva 80 milicores de CPU (80 mCPU) e 280 mebibytes (280 MiB) de memória em cada nó para daemons do sistema. A unidade de CPU mCPU significa milésimo de um núcleo. Portanto, 80/1.000 ou 8% de um núcleo em cada nó é reservado 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ó pode remover pods se o uso de CPU ou memória exceder os valores alocados a eles.

Rede com o MetalLB

Talvez seja necessário aumentar o número de alto-falantes do MetalLB para resolver os seguintes aspectos:

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

  • Tolerância a falhas: mais alto-falantes reduzem o impacto geral de uma única falha.

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

Planeje cuidadosamente quantos alto-falantes do 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 agrupado, 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 manual do balanceador de carga.

Como executar muitos nós, pods e serviços

Adicionar nós, pods e serviços é uma maneira de escalonar verticalmente o cluster. As seções a seguir abordam algumas configurações e configurações adicionais que você precisa considerar 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 elas 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. 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

Esta seção descreve os aspectos do CoreDNS que afetam a escalabilidade dos clusters.

DNS do pod

Por padrão, os clusters do Google Distributed Cloud injetam pods com um resolv.conf que se parece 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). O servidor DNS anexa todos os domínios de pesquisa especificados antes de procurar o nome do host solicitado originalmente, que ordena pesquisas como a seguinte 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 de DNS para cada consulta que não é FQDN, o que aumenta significativamente o tráfego de DNS. Para atenuar esse problema, recomendamos que você declare o nome do host a ser pesquisado como um FQDN, adicionando 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 o IPv6, será possível reduzir pela metade as solicitações de DNS eliminando a pesquisa de registro AAAA para o servidor DNS upstream. Se precisar de ajuda para desativar as pesquisas 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 do aplicativo, recomendamos que você use nós dedicados para a implantação 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 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 que atende 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 para o cluster.

Limites de conexão

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

Alto-falantes do 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 plano 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, é necessário aumentar o número de máquinas do plano de controle. Para implantações de produção, recomendamos que você use 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 alto-falantes adicionais pode não ser um bom uso dos recursos.

Configuração do Entrada

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

Você pode considerar expor o VIP por outros mecanismos, como o F5 BIG-IP. Como alternativa, crie um novo cluster usando o balanceamento de carga em pacote com o 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 recurso 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 de componentes do Stackdriver.

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

Usar o sysctl para configurar o sistema operacional

Recomendamos que você ajuste a configuração do sistema operacional dos nós para que eles se adaptem melhor ao caso de uso da carga de trabalho. Os parâmetros fs.inotify.max_user_watches e fs.inotify.max_user_instances que controlam o número de recursos inotify geralmente precisam ser ajustados. Por exemplo, se você receber mensagens de erro como a abaixo, tente 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. Você pode consultar as práticas recomendadas específicas do SO com o fornecedor.

Práticas recomendadas

Esta seção descreve as práticas recomendadas para dimensionar o cluster.

Dimensionar uma dimensão por vez

Para minimizar problemas e facilitar o reverter de alterações, não ajuste mais de uma dimensão por vez. O escalonamento de várias dimensões simultaneamente pode causar problemas mesmo em clusters menores. Por exemplo, tentar aumentar o número de pods programados por nó para 110 e o número de nós no cluster para 250 provavelmente não vai funcionar porque o número de pods, o número de pods por nó e o número de nós são muito estendidos.

Escalonar clusters em etapas

O escalonamento de um cluster pode consumir muitos recursos. Para reduzir o risco de falhas nas operações do cluster ou de interrupções nas cargas de trabalho, recomendamos não 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 cluster grande, híbrido ou autônomo com mais de 50 nós de trabalho, é melhor criar um cluster de alta disponibilidade (HA) 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 é de HA e, portanto, é menos confiável. Depois que o cluster híbrido ou autônomo de alta disponibilidade for criado, ele poderá ser usado para escalonar verticalmente a capacidade 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 fazer isso em etapas. Recomendamos que você adicione no máximo 20 nós por vez. Isso é especialmente verdadeiro para clusters que estão executando cargas de trabalho críticas.

Ativar pulls de imagem paralelos

Por padrão, o kubelet extrai imagens de forma serial, uma após a outra. Se você tiver uma conexão upstream incorreta para o servidor do registro de imagens, uma extração de imagem incorreta poderá interromper a fila inteira de um determinado pool de nós.

Para evitar isso, recomendamos definir serializeImagePulls como false na configuração personalizada do kubelet. Para instruções e mais informações, consulte Configurar as configurações de pull de imagem do kubelet. Ativar o download de imagens paralelas pode causar picos no consumo de largura de banda de rede ou E/S de disco.

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

Em ambientes com muitos pacotes, as cargas de trabalho do aplicativo podem ser removidas. O Kubernetes usa o mecanismo referenciado para classificar os pods em caso de expulsã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 em nuvem no Cloud Architecture Center.

Usar um parceiro de armazenamento

Recomendamos que você use um dos parceiros de armazenamento GDC 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ó, solicitações de recursos e limites.
  • A versão de armazenamento é qualificada com a versão específica do Google Distributed Cloud.
  • O fornecedor de armazenamento pode oferecer suporte à alta escala que você quer implantar.

Configurar clusters para alta disponibilidade

É importante auditar a implantação em grande escala e garantir que os componentes críticos sejam configurados para HA sempre que possível. O Google Distributed Cloud oferece suporte a opções de implantação de HA para todos os tipos de cluster. Para mais informações, consulte Escolher um modelo de implantação. Para exemplos de arquivos de configuração de cluster de implantações de HA, 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

Esta seção apresenta algumas recomendações básicas de monitoramento para clusters em grande escala.

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

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

Monitorar o consumo de largura de banda

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

Melhorar o desempenho 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 evento 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 a E/S do 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 do etcd "a aplicação de entradas levou muito tempo"? (em inglês) e O que significa o aviso "falha ao enviar sinal de funcionamento no horário" do etcd? (em inglês).

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

A seguir