Aumente a escala dos clusters do Google Distributed Cloud

Tal como qualquer cluster do Kubernetes, a escalabilidade do cluster do Google Distributed Cloud tem muitas dimensões interligadas. Este documento destina-se a ajudar a compreender as dimensões principais que pode ajustar para dimensionar os seus clusters sem interromper as cargas de trabalho.

Compreender os limites

O Google Distributed Cloud é um sistema complexo com uma grande superfície de integração. Existem muitas dimensões que afetam a escalabilidade do cluster. Por exemplo, o número de nós é apenas uma das muitas dimensões nas quais o Google Distributed Cloud pode ser dimensionado. Outras dimensões incluem o número total de pods e serviços. Muitas destas dimensões, como o número de pods por nó e o número de nós por cluster, estão interligadas. Para mais informações sobre as dimensões que têm um efeito na escalabilidade, consulte os limites de escalabilidade do Kubernetes na secção do grupo de interesse especial (SIG) de escalabilidade do repositório da comunidade do Kubernetes no GitHub.

Os limites de escalabilidade também são sensíveis à configuração de hardware e de nós na qual o cluster está a ser executado. Os limites descritos neste documento são validados num ambiente que provavelmente é diferente do seu. Por conseguinte, pode não reproduzir os mesmos números quando o ambiente subjacente é o fator limitativo.

Para mais informações sobre os limites aplicáveis aos seus clusters do Google Distributed Cloud, consulte Quotas e limites.

Prepare-se para a expansão

À medida que se prepara para dimensionar os seus clusters do Google Distributed Cloud, considere os requisitos e as limitações descritos nas secções seguintes.

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

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

Número de nós do cluster CPUs do plano de controlo recomendadas Memória do plano de controlo recomendada
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 pode ter nos seus clusters é controlado pelas seguintes definições:

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

O número total de endereços IP reservados para pods no seu cluster é um dos fatores limitativos para aumentar a escala do cluster. Esta definição, juntamente com a definição para o número máximo de agrupamentos por nó, determina o número máximo de nós que pode ter no cluster antes de correr o risco de esgotar os endereços IP para os seus agrupamentos.

Considere o seguinte:

  • O número total de endereços IP reservados para pods no seu 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 agrupamentos que podem ser executados num único nó é especificado com nodeConfig.podDensity.maxPodsPerNode.

  • Com base na definição do número máximo de agrupamentos por nó, o Google Distributed Cloud aprovisiona aproximadamente o dobro dos endereços IP para o nó. Os endereços IP adicionais ajudam a evitar a reutilização inadvertida dos IPs do pod num curto espaço de tempo.

  • Dividir o número total de endereços IP de agrupamentos pelo número de endereços IP de agrupamentos aprovisionados em cada nó dá-lhe o número total de nós que pode ter no seu cluster.

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

Ambos os parâmetros clusterNetwork.pods.cidrBlocks e nodeConfig.podDensity.maxPodsPerNode são imutáveis, por isso, planeie cuidadosamente o crescimento futuro do seu cluster para evitar ficar sem capacidade de nós. Para ver os máximos recomendados para agrupamentos por cluster, agrupamentos por nó e nós por cluster com base em testes, consulte os limites.

CIDR do serviço

O CIDR de serviço pode ser atualizado para adicionar mais serviços à medida que aumenta a escala do cluster. No entanto, não pode reduzir o intervalo CIDR do serviço. Para mais informações, consulte o artigo Aumente o alcance da rede de serviços.

Recursos reservados para daemons do sistema

Por predefinição, o Google Distributed Cloud reserva automaticamente recursos num nó para daemons do sistema, como sshd ou udev. Os recursos de CPU e memória são reservados num nó para os daemons do sistema, para que estes daemons tenham os recursos de que precisam. Sem esta funcionalidade, os pods podem consumir potencialmente a maioria dos recursos num nó, o que impossibilita que os daemons do sistema concluam as respetivas 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. Tenha em atenção que a unidade de CPU mCPU significa milésima parte de um núcleo e, por isso, 80/1000 ou 8% de um núcleo em cada nó está reservado 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 num nó pode desalojar Pods se a respetiva utilização de CPU ou memória exceder as quantidades que lhes foram atribuídas.

Redes com o MetalLB

Recomendamos que aumente o número de altifalantes do MetalLB para resolver os seguintes aspetos:

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

  • Tolerância a falhas: mais altifalantes reduzem o impacto geral de uma única falha do altifalante.

O MetalLB requer conetividades da camada 2 entre os nós de equilíbrio de carga. Neste caso, pode estar limitado ao número de nós com conetividade da camada 2 onde pode colocar altifalantes do MetalLB.

Planeie cuidadosamente quantos altifalantes MetalLB quer ter no cluster e determine quantos nós da camada 2 precisa. Para mais informações, consulte o artigo Problemas de escalabilidade do MetalLB.

Em alternativa, quando usar o modo de equilíbrio de carga integrado, os nós do plano de controlo também têm de estar na mesma rede de camada 2. O equilíbrio de carga manual não tem esta restrição. Para mais informações, consulte o modo de equilibrador de carga manual.

Executar muitos nós, pods e serviços

Adicionar nós, pods e serviços é uma forma de aumentar a escala do cluster. As secções seguintes abordam algumas definições e configurações adicionais que deve considerar quando aumenta o número de nós, pods e serviços no seu cluster. Para obter informações sobre os limites destas dimensões e a respetiva relação, consulte o artigo Limites.

Crie um cluster sem kube-proxy

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

Não pode desativar a utilização de kube-proxy para um cluster existente. Esta configuração tem de ser configurada quando o cluster é criado. Para ver instruções e mais informações, consulte o artigo Crie um cluster sem o kube-proxy.

Configuração do CoreDNS

Esta secção descreve aspetos do CoreDNS que afetam a escalabilidade dos seus clusters.

DNS do pod

Por predefinição, os clusters do Google Distributed Cloud injetam pods com um resolv.conf semelhante ao 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 anfitriões com menos de 5 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 anfitrião pedido originalmente, o que ordena as pesquisas da seguinte forma quando resolve 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 procuras é realizada para IPv4 (registo A) e IPv6 (registo AAAA), o que resulta em 12 pedidos DNS para cada consulta não FQDN, o que amplifica significativamente o tráfego DNS. Para mitigar este problema, recomendamos que declare o nome do anfitrião a procurar como um FQDN adicionando um ponto final (google.com.). Esta declaração tem de ser feita ao nível da carga de trabalho da aplicação. Para mais informações, consulte a página resolv.conf do manual.

IPv6

Se o cluster não estiver a usar o IPv6, é possível reduzir os pedidos DNS em metade eliminando a procura de registos AAAA no servidor DNS a montante. Se precisar de ajuda para desativar as pesquisas AAAA, contacte o Cloud Customer Care.

Node pool dedicado

Devido à natureza crítica das consultas DNS nos ciclos de vida das aplicações, recomendamos que use nós dedicados para a implementação.coredns Esta implementação enquadra-se num domínio de falha diferente das aplicações normais. Se precisar de ajuda para configurar nós dedicados para a implementação, contacte o apoio ao cliente da Google Cloud.coredns

Problemas de escalabilidade do MetalLB

O MetalLB é executado no modo ativo-passivo, o que significa que, em qualquer momento, existe apenas um único altifalante do MetalLB a servir um LoadBalancer VIP específico.

Failover

Antes do lançamento 1.28.0 do Google Distributed Cloud, em grande escala, a comutação por falha do MetalLB podia demorar muito tempo e apresentar um risco de fiabilidade para o cluster.

Limites de ligação

Se existir um LoadBalancerVIP específico, como um serviço de entrada, que espere ter perto de 30 mil ou mais ligações simultâneas, é provável que o nó do altifalante que processa o VIP possa esgotar as portas disponíveis. Devido a uma limitação da arquitetura, não existe mitigação para este problema por parte do MetalLB. Considere mudar para o equilíbrio de carga agrupado com BGP antes da criação do cluster ou usar uma classe de entrada diferente. Para mais informações, consulte o artigo Configuração de entrada.

Altifalantes com balanceador de carga

Por predefinição, o Google Distributed Cloud usa o mesmo conjunto de nós do balanceador de carga para o plano de controlo e o plano de dados. Se não especificar um node pool do balanceador de carga (loadBalancer.nodePoolSpec), é usado o node pool do plano de controlo (controlPlane.nodePoolSpec).

Para aumentar o número de altifalantes quando usa o conjunto de nós do plano de controlo para o equilíbrio de carga, tem de aumentar o número de máquinas do plano de controlo. Para implementações de produção, recomendamos que use três nós do plano de controlo para alta disponibilidade. Aumentar o número de nós do plano de controlo para além de três para acomodar altifalantes adicionais pode não ser uma boa utilização dos seus recursos.

Configuração de entrada

Se esperar perto de 30 mil ligações simultâneas a um único VIP de serviço LoadBalancer, o MetalLB pode não conseguir suportá-lo.

Pode considerar expor o VIP através de outros mecanismos, como o F5 BIG-IP. Em alternativa, pode criar um novo cluster através do equilíbrio de carga agrupado com BGP, que não tem a mesma limitação.

Ajuste os componentes do Cloud Logging e Cloud Monitoring

Em clusters grandes, consoante os perfis das aplicações e o padrão de tráfego, as configurações de recursos predefinidas para os componentes do Cloud Logging e do Cloud Monitoring podem não ser suficientes. Para obter instruções sobre como ajustar os pedidos e os limites de recursos para os componentes de observabilidade, consulte o artigo Configurar recursos de componentes do Stackdriver.

Em particular, o kube-state-metrics em clusters com um grande número de serviços e pontos finais pode causar uma utilização excessiva de memória no próprio kube-state-metrics e no gke-metrics-agent no mesmo nó. A utilização de recursos do metrics-server também pode ser dimensionada em termos de nós, pods e serviços. Se tiver problemas de recursos nestes componentes, contacte o apoio ao cliente do Google Cloud.

Use o sysctl para configurar o sistema operativo

Recomendamos que ajuste a configuração do sistema operativo dos seus nós para se adequar melhor ao seu exemplo de utilização 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 requerem frequentemente ajustes. Por exemplo, se vir mensagens de erro como as seguintes, pode querer verificar se estes parâmetros têm de 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...

Normalmente, a otimização varia consoante os tipos de carga de trabalho e a configuração de hardware. Pode consultar as práticas recomendadas específicas do SO junto do fornecedor do SO.

Práticas recomendadas

Esta secção descreve as práticas recomendadas para aumentar a escala do cluster.

Dimensione uma dimensão de cada vez

Para minimizar os problemas e facilitar o reverter das alterações, não ajuste mais do que uma dimensão de cada vez. O aumento de várias dimensões em simultâneo pode causar problemas, mesmo em clusters mais pequenos. Por exemplo, tentar aumentar o número de pods agendados por nó para 110 ao mesmo tempo que aumenta o número de nós no cluster para 250 provavelmente não vai ter êxito porque o número de pods, o número de pods por nó e o número de nós estão demasiado esticados.

Dimensione os clusters em fases

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

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

Se estiver a criar um cluster híbrido ou autónomo grande com mais de 50 nós de trabalho, é melhor criar primeiro um cluster de alta disponibilidade (HA) com nós do plano de controlo e, em seguida, aumentar gradualmente a escala. A operação de criação de clusters usa um cluster de arranque, que não é de alta disponibilidade e, por isso, é menos fiável. Depois de criar o cluster híbrido ou autónomo de HA, pode usá-lo para aumentar a escala até mais nós.

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

Se estiver a expandir um cluster para mais nós de trabalho, é melhor fazê-lo por fases. Recomendamos que não adicione mais de 20 nós de cada vez. Isto é particularmente verdade para clusters que estão a executar cargas de trabalho críticas.

Ative as obtenções de imagens em paralelo

Por predefinição, o kubelet extrai imagens em série, uma após a outra. Se tiver uma ligação a montante deficiente ao servidor de registo de imagens, uma obtenção de imagens deficiente pode paralisar toda a fila para um determinado conjunto de nós.

Para mitigar esta situação, recomendamos que defina serializeImagePulls como false na configuração kubelet personalizada. Para ver instruções e mais informações, consulte o artigo Configure as definições de obtenção de imagens do kubelet. A ativação das obtenções de imagens paralelas pode introduzir picos no consumo de largura de banda da rede ou de E/S de disco.

Ajuste os pedidos e os limites de recursos das aplicações

Em ambientes densamente preenchidos, as cargas de trabalho das aplicações podem ser desalojadas. O Kubernetes usa o mecanismo referenciado para classificar os pods em caso de despejo.

Uma prática recomendada para definir os recursos do contentor é usar a mesma quantidade de memória para pedidos e limites, e um limite de CPU maior ou ilimitado. Para mais informações, consulte o artigo Prepare aplicações Kubernetes baseadas na nuvem no Centro de arquitetura na nuvem.

Use um parceiro de armazenamento

Recomendamos que use um dos parceiros de armazenamento compatíveis com o GDC para implementações em grande escala. É importante confirmar as seguintes informações com o parceiro de armazenamento específico:

  • As implementações de armazenamento seguem as práticas recomendadas para aspetos de armazenamento, como alta disponibilidade, definição de prioridades, afinidades de nós e pedidos 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 suportar a grande escala que quer implementar.

Configure clusters para alta disponibilidade

É importante auditar a implementação de grande escala e certificar-se de que os componentes críticos estão configurados para HA sempre que possível. O Google Distributed Cloud suporta opções de implementação de HA para todos os tipos de clusters. Para mais informações, consulte o artigo Escolha um modelo de implementação. Por exemplo, para ver ficheiros de configuração de clusters de implementações de HA, consulte os Exemplos de configuração de clusters.

Também é importante auditar outros componentes, incluindo:

  • Fornecedor de armazenamento
  • Webhooks de cluster

Monitorizar a utilização de recursos

Esta secção fornece algumas recomendações básicas de monitorização para clusters de grande escala.

Monitorize atentamente as métricas de utilização

É fundamental monitorizar a utilização dos nós e dos componentes individuais do sistema e certificar-se de que têm uma margem confortavelmente segura. Para ver que capacidades de monitorização padrão estão disponíveis por predefinição, consulte o artigo Use painéis de controlo predefinidos.

Monitorize o consumo de largura de banda

Monitorize atentamente o consumo de largura de banda para garantir que a rede não está saturada, o que resulta na degradação do desempenho do cluster.

Melhore o desempenho do etcd

A velocidade do disco é fundamental para o desempenho e a estabilidade do etcd. Um disco lento aumenta a latência do pedido do etcd, o que pode originar problemas de estabilidade do cluster. Para melhorar o desempenho do cluster, o Google Distributed Cloud armazena objetos de eventos numa instância etcd separada e dedicada. A instância etcd padrão usa /var/lib/etcd como diretório de dados e a porta 2379 para pedidos de clientes. A instância etcd-events usa /var/lib/etcd-events como diretório de dados e a porta 2382 para pedidos de clientes.

Recomendamos que use um disco de estado sólido (SSD) para os seus armazenamentos etcd. Para um desempenho ideal, monte discos separados para /var/lib/etcd e /var/lib/etcd-events. A utilização de discos dedicados garante que as duas instâncias do etcd não partilham a E/S do disco.

A documentação do etcd fornece recomendações de hardware adicionais para garantir o melhor desempenho do etcd quando executa os seus clusters em produção.

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

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

Para mais informações sobre o desempenho do etcd, consulte os artigos O que significa o aviso do etcd "apply entries took too long"? e O que significa o aviso do etcd "failed to send out heartbeat on time"?.

Se precisar de assistência adicional, contacte o apoio ao cliente do Google Cloud. Também pode consultar o artigo Receber apoio técnico para mais informações sobre recursos de apoio técnico, incluindo o seguinte:

  • Requisitos para abrir um registo de apoio técnico.
  • Ferramentas para ajudar a resolver problemas, como a configuração do ambiente, os registos e as métricas.
  • Componentes suportados.

O que se segue?