Escalonar clusters do Google Distributed Cloud

Como qualquer cluster do Kubernetes, a escalonabilidade do cluster do Google Distributed Cloud tem muitas dimensões inter-relacionadas. Este documento foi criado para 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 inter-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 escalonabilidade também são sensíveis à configuração de hardware e nós em que o cluster está sendo executado. Os limites descritos neste documento são 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 aplicados aos clusters do Google Distributed Cloud, consulte Cotas e limites.

Prepare-se para escalonar

Ao se preparar para escalonar os clusters do Google Distributed Cloud, considere os requisitos e 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 do plano de controle de 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 de 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 o escalonamento vertical. Essa configuração, juntamente com a configuração de número máximo de pods por nó, determina o número máximo de nós que você pode ter no cluster antes de correr o 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 especificado 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 de número máximo 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 inadvertida dos IPs de pod em um curto período.

  • Dividir o número total de endereços IP de pods pelo número de endereços IP de pods provisionados em cada nó dá o número total de nós que você pode ter no 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 vai 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 dividido 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, então planeje com cuidado o crescimento futuro do cluster para evitar ficar sem capacidade de nós. Para os máximos recomendados de 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 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 de 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ó são reservados para daemons do sistema. A quantidade de recursos reservados é pequena e não tem um impacto significativo na performance 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 MetalLB

Talvez seja necessário aumentar o número de speakers 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 exige mais alto-falantes.

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

O MetalLB exige conectividades de camada 2 entre os nós de balanceamento de carga. Nesse caso, você pode estar limitado ao número de nós com conectividade da camada 2 em que é possível colocar os anunciantes do MetalLB.

Planeje com cuidado quantos speakers 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.

Além disso, 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 de balanceador de carga manual.

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 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 alta performance 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 o 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 do 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

Esta seção descreve aspectos do CoreDNS que afetam a escalonabilidade dos seus clusters.

DNS do pod

Por padrão, os clusters do Google Distributed Cloud injetam pods com um resolv.conf que parece o seguinte:

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 originalmente solicitado, o que ordena as pesquisas da seguinte maneira 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 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 IPv6, será possível reduzir as solicitações de DNS pela metade eliminando a pesquisa de registro AAAA para o servidor DNS upstream. Se precisar de ajuda para desativar as pesquisas de 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 coredns. Esse Deployment se enquadra em um domínio de falha diferente dos aplicativos normais. Se 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 para o cluster.

Limites de conexão

Se houver um LoadBalancer VIP específico, como um serviço de entrada, que espere perto de 30 mil conexões simultâneas ou mais, é provável que o nó de speaker 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 do 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 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 usar três nós do plano de controle para alta disponibilidade. Aumentar o número de nós do plano de controle além de três para acomodar mais 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 em um único VIP de serviço LoadBalancer, talvez o MetalLB não consiga oferecer suporte a isso.

Você pode expor o VIP por outros mecanismos, como o F5 BIG-IP. Como alternativa, crie um 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 para os 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 próprio 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 Cloud Customer Care.

Usar sysctl para configurar o sistema operacional

Recomendamos que você ajuste a configuração do sistema operacional para seus nós e se adequar 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 de ajuste. Por exemplo, se você vir mensagens de erro como as seguintes, 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. Consulte o fornecedor do SO para saber mais sobre as práticas recomendadas específicas do SO.

Práticas recomendadas

Nesta seção, você vai encontrar as práticas recomendadas para aumentar a escala do cluster.

Dimensionar uma dimensão por vez

Para minimizar problemas e facilitar a reverter de mudanças, não ajuste mais de uma dimensão por vez. Aumentar 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 estão sendo muito estendidos.

Escalonar clusters em etapas

Aumentar a escala de um cluster pode exigir muitos recursos. Para reduzir o risco de falha nas operações ou interrupção das cargas de trabalho do cluster, não tente criar clusters grandes com muitos nós em uma única operação.

Criar clusters híbridos ou autônomos sem nós de trabalho

Se você estiver criando um cluster híbrido ou independente grande com mais de 50 nós de trabalho, é melhor criar primeiro um cluster de alta disponibilidade (HA) com nós do plano de controle e depois escalonar verticalmente gradualmente. A operação de criação de cluster usa um cluster de inicialização, que não é de 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 fazer isso em etapas. Recomendamos que você adicione no máximo 20 nós por vez. Isso é especialmente verdadeiro para clusters que executam cargas de trabalho críticas.

Ativar pulls de imagem paralelos

Por padrão, o kubelet extrai imagens em série, uma após a outra. Se você tiver uma conexão upstream ruim com o servidor de registro de imagens, uma extração de imagem ruim poderá paralisar toda a fila 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 Definir configurações de envio de imagem do kubelet. Ativar o pull de imagens paralelas pode causar picos no consumo de largura de banda da rede ou E/S de disco.

Ajustar solicitações e limites de recursos do aplicativo

Em ambientes densamente compactados, as cargas de trabalho de aplicativos podem ser removidas. O Kubernetes usa o mecanismo referenciado para classificar os 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 em nuvem na Central de arquitetura do Cloud.

Usar um parceiro de armazenamento

Recomendamos que você use um dos parceiros de armazenamento compatíveis com o GDC 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, definiçã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 pode oferecer suporte à alta escala que você quer implantar.

Configurar clusters para alta disponibilidade

É importante auditar sua implantação em grande 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 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 alta disponibilidade, consulte Exemplos 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 fornece 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 dos nós e dos componentes individuais do sistema e garantir que eles tenham uma margem 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 de largura de banda para garantir que a rede não esteja saturada, o que resulta em degradação da performance 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 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"? e O que significa o aviso "falha ao enviar sinal de funcionamento no horário" do etcd?.

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care. Consulte também Receber suporte para mais informações sobre recursos de suporte, incluindo:

  • Requisitos para abrir um caso de suporte.
  • Ferramentas para ajudar na solução de problemas, como configuração do ambiente, registros e métricas.
  • Componentes compatíveis.

A seguir