Escalonar verticalmente os clusters do Google Distributed Cloud

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

Noções básicas sobre os limites

O Google Distributed Cloud é um sistema complexo com uma grande plataforma 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 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 (em inglês) 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 são verificados em um ambiente que provavelmente é diferente do seu. Portanto, talvez não seja possível reproduzir os mesmos números quando o ambiente for o fator limitante.

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

Prepare-se para escalonar

Ao se preparar para escalonar seus 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

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 do plano de controle recomendadas 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 é possível ter nos clusters é controlado pelas configurações a seguir:

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 de limitação para o escalonamento vertical do cluster. Em conjunto com a definição do número máximo de pods por nó, você 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 seus 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 aproximadamente o dobro de endereços IP para o nó. Os endereços IP extras ajudam a impedir a reutilização inadvertida 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 obter o número total de nós que é possível ter no seu cluster.

Por exemplo, se o CIDR do pod for 192.168.0.0/17, você tem 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 provisiona 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 é de 64 (215 endereços/cluster dividido por 29 endereços/nó = 2(15-9) nós/cluster = 26 = 64 nós/cluster.

Tanto clusterNetwork.pods.cidrBlocks quanto nodeConfig.podDensity.maxPodsPerNode são imutáveis. Portanto, planeje cuidadosamente o crescimento futuro do cluster para evitar a falta de capacidade do nó. Para saber os 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 o cluster. No entanto, não é possível reduzir o intervalo CIDR de serviço. Para mais informações, consulte Aumentar o intervalo de rede do serviço.

Recursos reservados para daemons do sistema

Por padrão, o Google Distributed Cloud reserva automaticamente os 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 para que esses daemons tenham os recursos necessários. Sem esse recurso, os pods podem consumir a maioria dos recursos em um nó, impossibilitando que os 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. Observe que a unidade de CPU mCPU representa o milésimo de um núcleo. Portanto, 80/1.000 ou 8% de um núcleo em cada nó são reservados para os 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á eliminar pods se o uso de CPU ou memória exceder os valores alocados a eles.

Rede com o MetalLB

Você pode aumentar o número de alto-falantes do MetalLB para atender aos 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ó de alto-falante. Um aumento no 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 de um único alto-falante.

O MetalLB exige conexões 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 da Camada 2 em que é possível colocar alto-falantes do 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 da 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 forma de escalonar verticalmente o cluster. As seções a seguir abrangem algumas definiçõ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 eles se relacionam entre si, 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 criar 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 de iptables.

Não é possível desativar o uso de kube-proxy para 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 semelhante a 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 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 DNS para cada consulta não FQDN, o que amplifica significativamente o tráfego DNS. Para atenuar esse problema, recomendamos que você declare o nome do host para pesquisar como um FQDN adicionando um ponto à direita (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 do resolv.conf.

IPv6

Se o cluster não estiver usando IPv6, é possível reduzir pela metade as solicitações de DNS, eliminando a pesquisa de 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 coredns. Essa Implantação está em um domínio de falha diferente do domínio 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 único 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 receber quase 30 mil conexões simultâneas ou mais, é 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 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 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, aumente 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 mais alto-falantes pode não ser um bom uso dos recursos.

Configuração de entrada

Se você espera quase 30 mil conexões simultâneas em um único VIP de serviço LoadBalancer, o MetalLB pode não oferecer suporte a ele.

Você pode considerar a exposição do VIP por meio de outros mecanismos, como o F5 BIG-IP. Como alternativa, é possível 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 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 os recursos dos componentes do Stackdriver.

Especificamente, 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 Cloud Customer Care.

Use sysctl para configurar o sistema operacional

Recomendamos que você ajuste a configuração do sistema operacional para seus nós de acordo com o 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 de inotify geralmente precisam ser ajustados. Por exemplo, caso você veja mensagens de erro como as abaixo, tente ver 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 do hardware. Consulte as práticas recomendadas específicas do SO com seu fornecedor.

Práticas recomendadas

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

Dimensionar uma dimensão por vez

Para minimizar os problemas e facilitar a reverter de alterações, não ajuste mais de uma dimensão por vez. Escalonar 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, 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 ampliados demais.

Escalonar clusters em etapas

O escalonamento vertical de um cluster pode consumir muitos recursos. Para reduzir o risco de falhas nas operações do cluster ou das cargas de trabalho do cluster serem interrompidas, 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 grande cluster híbrido ou independente 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 alta disponibilidade e, portanto, é menos confiável. Depois que o cluster híbrido ou independente de alta disponibilidade tiver sido criado, será possível usá-lo 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ê não adicione mais de 20 nós por vez. Isso é especialmente verdadeiro para clusters que estão executando cargas de trabalho críticas.

Ativar pull de imagens paralelas

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, um pull de imagem incorreto poderá interromper 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 Definir configurações de extração 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 solicitações e limites de recursos de aplicativos

Em ambientes muito cheios, 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 em 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, definição de prioridade, afinidades de nó 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 tem suporte para a grande escala que você quer implantar.

Configurar clusters para alta disponibilidade

É importante auditar sua implantação em alta escala e garantir que os componentes essenciais 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 conferir 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 confortável. Para saber quais recursos de monitoramento padrão estão disponíveis por padrão, consulte Usar painéis predefinidos.

Monitorar o consumo da largura de banda

Monitore o consumo da largura de banda de perto para garantir que a rede não esteja saturada, o que resulta em 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 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 ver mais informações sobre o desempenho do etcd, consulte O que significa o aviso "as entradas demorou demais" do etcd? e O que significa o aviso "Falha ao enviar o sinal de funcionamento no horário" do etcd?.

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

A seguir