Planeje clusters grandes do GKE

Nesta página, descrevemos as práticas recomendadas para planejar e projetar clusters muito grandes.

Por que fazer o planejamento para grandes clusters do GKE

Todo sistema de computação, incluindo o Kubernetes, tem alguns limites de arquitetura. Exceder os limites pode afetar o desempenho do cluster ou, em alguns casos, até mesmo causar inatividade. Siga as práticas recomendadas e execute as ações recomendadas para garantir que os clusters executem as cargas de trabalho de maneira confiável em escala.

Limitações de clusters grandes do GKE

Quando o GKE escalona um cluster para um grande número de nós, ele tenta mudar a quantidade de recursos disponíveis para corresponder às necessidades do sistema, mantendo os objetivos de nível de serviço (SLOs). OGoogle Cloud oferece suporte a clusters grandes. No entanto, com base no seu caso de uso, é necessário considerar as limitações de clusters grandes para responder melhor aos requisitos de escalonamento da infraestrutura.

Esta seção descreve as limitações e considerações ao projetar clusters grandes do GKE com base no número esperado de nós.

Clusters com até 5.000 nós

Ao projetar a arquitetura do cluster para escalonar até 5.000 nós, considere as seguintes condições:

Se você pretende aumentar o cluster para mais de 5.000 nós, entre em contato com o atendimento ao cliente do Cloud para aumentar o tamanho do cluster e o limite de cota.

Clusters com mais de 5.000 nós

O GKE é compatível com clusters padrão grandes de até 15.000 nós. Na versão 1.31 e mais recentes, o GKE oferece suporte a clusters grandes de até 65.000 nós. O limite de 65.000 é usado para executar cargas de trabalho de IA em grande escala.

Se você planeja escalonar o cluster para 15.000 ou 65.000 nós, conclua as seguintes tarefas:

  1. Considere as seguintes limitações:

  2. Entre em contato com o atendimento ao cliente do Cloud para aumentar o tamanho do cluster e o limite de cota para 15.000 ou 65.000 nós, dependendo das suas necessidades de escalonamento.

Práticas recomendadas para dividir cargas de trabalho entre vários clusters

É possível executar suas cargas de trabalho em um cluster grande e único. Essa abordagem é mais fácil de gerenciar, mais econômica e fornece melhor utilização de recursos do que vários clusters. No entanto, em alguns casos, é preciso dividir a carga de trabalho em vários clusters:

  • Consulte Casos de uso de vários clusters para saber mais sobre os requisitos gerais e cenários para usar vários clusters.
  • Além disso, do ponto de vista da escalonabilidade, divida seu cluster quando ele puder exceder um dos limites descritos na seção abaixo ou uma das cotas do GKE. Reduzir qualquer risco para atingir os limites do GKE, reduz o risco de inatividade ou outros problemas de confiabilidade.

Se você decidir dividir o cluster, use o gerenciamento de frotas para simplificar o gerenciamento de uma frota com vários clusters.

Limites e práticas recomendadas

Para garantir que sua arquitetura seja compatível com clusters de grande escala do GKE, analise os seguintes limites e práticas recomendadas relacionadas. Ultrapassar esses limites pode causar uma degradação no desempenho do cluster ou problemas de confiabilidade.

Essas práticas recomendadas se aplicam a qualquer cluster padrão do Kubernetes sem extensões instaladas. A extensão de clusters do Kubernetes com webhooks ou definições de recursos personalizados (CRDs, na sigla em inglês) é comum, mas pode restringir sua capacidade de escalonar o cluster.

A tabela a seguir estende as principais cotas e limites do GKE. Você também precisa se familiarizar com os limites do Kubernetes de código aberto para clusters de grande escala.

Os requisitos de versão do GKE mencionados na tabela se aplicam aos nós e ao plano de controle.

Limite do GKE Descrição Práticas recomendadas
O tamanho do banco de dados etcd O tamanho máximo do banco de dados etcd é de 6 GB. Se você estiver executando um cluster muito grande com dezenas de milhares de recursos, as instâncias do etcd poderão exceder esse limite. É possível verificar o nível de utilização dos clusters no console do Google Cloud. Se você ultrapassar esse limite, o GKE poderá marcar as instâncias do etcd como não íntegras. Isso faz com que o plano de controle dos clusters não responda.

Se você ultrapassar esse limite, entre em contato com o suporte doGoogle Cloud .
Tamanho total dos objetos etcd por tipo O tamanho total de todos os objetos do tipo de recurso fornecido não pode exceder 800 MB. Por exemplo, é possível criar 750 MB de instâncias de pod e 750 MB de Secrets, mas não 850 MB de Secrets. Se você criar mais de 800 MB de objetos, isso pode fazer com que o Kubernetes ou os controladores personalizados não inicializem e causem interrupções.

Mantenha o tamanho total de todos os objetos de cada tipo armazenados no etcd abaixo de 800 MB. Isso se aplica especialmente a clusters que usam muitos Secrets ou ConfigMaps de tamanho grande ou um grande volume de CRDs.
Número de serviços para clusters em que o GKE Dataplane V2 não está ativado O desempenho de iptables usado pelo kube-proxy será afetado se alguma das seguintes situações ocorrer:
  • Há Serviços demais.
  • O número de back-ends por trás de um serviço é alto.

Esse limite é eliminado quando o GKE Dataplane V2 está ativado.

Mantenha o número de serviços no cluster abaixo de 10.000.

Para saber mais, consulte Como expor aplicativos usando serviços.
Número de serviços por namespace O número de variáveis de ambiente geradas para os Serviços pode ultrapassar os limites do shell. Isso pode causar falhas nos pods na inicialização.

Mantenha o número de serviços por namespace abaixo de 5.000.

É possível desativar o preenchimento dessas variáveis de ambiente. Consulte a documentação para saber como definir enableServiceLinks no PodSpec como falso.

Saiba mais em Como expor aplicativos usando os serviços.
Número de pods por trás de um único serviço para clusters em que o GKE Dataplane V2 não está ativado

Cada nó executa um kube-proxy que usa relógios para monitorar qualquer alteração de serviço. Quanto maior for o cluster, mais dados relacionados a alterações serão processados pelo agente. Isso é especialmente visível em clusters com mais de 500 nodes.

As informações sobre os endpoints são divididas entre EndpointSlices separados. Isso reduz a quantidade de dados transferidos em cada alteração.

Os objetos de endpoint ainda estão disponíveis para componentes, mas qualquer endpoint com mais de mil pods é truncado automaticamente.

Mantenha o número de pods protegidos por um serviço menor que 10 mil.

Saiba mais em Como expor aplicativos usando serviços.
Número de pods por trás de um único serviço para clusters em que o GKE Dataplane V2 está ativado

O GKE Dataplane V2 contém limites para o número de pods expostos por um único serviço.

O mesmo limite é aplicável aos clusters do Autopilot que usam o GKE Dataplane V2.

No GKE 1.23 e versões anteriores, mantenha o número de pods por trás de um único serviço menor que 1.000.

No GKE 1.24 e posterior, mantenha o número de pods por trás de um único serviço menor que 10.000.

Para saber mais, consulte Como expor aplicativos usando serviços.
Registros DNS por serviço sem comando

O número de registros DNS por serviço headless é limitado para kube-dns e Cloud DNS.

Mantenha o número de registros DNS por serviço headless abaixo de 1.000 para kube-dns e 3.500/2.000 (IPv4/IPv6) para Cloud DNS.
Número de todos os endpoints de serviço O número de endpoints em todos os Serviços pode atingir os limites. Isso pode aumentar a latência da programação ou resultar em uma impossibilidade de programar novos endpoints.

Mantenha o número de endpoints em todos os serviços abaixo de 260.000.

O GKE Dataplane V2, que é o plano de dados padrão do GKE Autopilot, depende de mapas eBPF que estão atualmente limitados a 260.000 endpoints em todos os Serviços.
Número de objetos do escalonador automático horizontal de pods por cluster

Cada escalonador automático de pod horizontal (HPA) é processado a cada 15 segundos.

Ter mais de 300 objetos de HPA pode causar degradação linear do desempenho.

Mantenha o número de objetos de HPA dentro do limite. Caso contrário, você poderá notar uma degradação linear da frequência de processamento de HPA. Por exemplo,no GKE 1.22 com 2.000 HPAs, um único HPA será reprocessado a cada 1 minuto e 40 segundos.

Para saber mais, consulte Escalonamento automático com base no uso de recursos e escalonamento automático horizontal do pod horizontal.
Número de pods por nó O GKE tem um limite absoluto de 256 pods por node. Isso pressupõe uma média de dois ou menos contêineres por pod. Se você aumentar o número de contêineres por pod, esse limite poderá ser menor porque o GKE aloca mais recursos por contêiner.

Recomendamos o uso de nodes de trabalho com pelo menos uma vCPU a cada 10 pods.

Para saber mais, consulte Como fazer upgrade manual de um cluster ou pool de nodes.
Taxa de alterações no pod.

O Kubernetes tem limites internos que afetam a taxa de criação ou exclusão de pods (desligamento de pods) em resposta ao escalonamento de solicitações. Outros fatores, como exclusão de um pod que faz parte de um Serviço, também podem afetar essa taxa de desligamento de pods.

Nos clusters com até 500 nós, a taxa média é de 20 pods criados por segundo e 10 pods excluídos por segundo.

Para clusters com mais de 500 nós, a taxa média é de 100 pods criados por segundo e 50 pods excluídos por segundo.

Considere a limitação da taxa de criação e exclusão de pods ao planejar como escalonar as cargas de trabalho.

Os pods compartilham a mesma capacidade de exclusão com outros tipos de recursos (por exemplo, EndpointSlices). É possível reduzir a capacidade de exclusão ao definir pods como parte de um serviço.

Para permitir que o escalonador automático de cluster remova efetivamente os pods de nós subutilizados, evite PodDisruptionBudgets muito restritivos e períodos de carência de encerramento longos.

As tolerâncias de caracteres curinga também não são recomendadas, porque podem fazer com que as cargas de trabalho sejam programadas em nós que estão em processo de remoção.
Número de relógios abertos

Os nodes criam um relógio para cada Secret e ConfigMaps que você configura para pods. A quantidade combinada de relógios criados por todos os nodes pode gerar uma carga significativa no plano de controle do cluster.

Ter mais de 200 mil visualizações por cluster pode afetar o tempo de inicialização do cluster. Esse problema pode fazer com que o plano de controle seja reiniciado com frequência.

Definir nós maiores para diminuir a probabilidade e a gravidade dos problemas causados por um grande número de relógios. Uma densidade de pods mais alta (menos nodes de tamanho grande) pode reduzir o número de verificações e reduzir a gravidade do problema.

Para saber mais, consulte a comparação de séries de máquina.
Número de secrets por cluster se a criptografia de secrets na camada de aplicativos estiver ativada Um cluster precisa descriptografar todos os secrets durante a inicialização quando a criptografia de secrets da camada de aplicativos está ativada. Se você armazenar mais de 30.000 secrets, o cluster poderá ficar instável durante a inicialização ou upgrades, causando falhas temporárias de carga de trabalho.

Armazene menos de 30.000 secrets ao usar a criptografia de secrets na camada de aplicativos.

Para saber mais, consulte Criptografar secrets na camada do aplicativo.
Largura de banda de registro por nó

Há um limite na quantidade máxima de registros enviados por cada node para a API Cloud Logging. O limite padrão varia entre 100 Kbps e 500 Kbps, dependendo da carga. É possível elevar o limite para 10 Mbps implantando uma configuração de agente do Logging de alta capacidade de processamento. Se você ultrapassar esse limite, as entradas de registro poderão ser descartadas.

Configure a geração de registros para permanecer dentro dos limites padrão ou configure um agente do Logging de alta capacidade.

Para saber mais, consulte Como aumentar a capacidade do agente do Logging.

Limites do Backup para GKE

É possível usar o Backup para GKE para fazer backup e restaurar as cargas de trabalho do GKE.

O Backup para GKE está sujeito a limites que precisam ser considerados ao definir os planos de backup.

Analise os limites do Backup para GKE.

Se for possível que sua carga de trabalho exceda esses limites, recomendamos criar vários planos de backup para particionar o backup e permanecer dentro dos limites.
Limites do Config Connector

É possível usar o Config Connector para gerenciar Google Cloud recursos no Kubernetes. O Config Connector tem dois modos de operação:

  • Modo Cluster, em que há uma única instância do Config Connector por cluster do GKE.

    Nesse modo, uma única instância do Config Connector carrega todos os recursos.

  • Modo de namespace, em que cada namespace em um cluster tem uma instância do Config Connector separada.

    Nesse modo, é possível particionar recursos gerenciados por namespaces. Essa configuração reduz a quantidade de recursos que uma única instância do Config Connector precisa gerenciar, reduzindo o uso de CPU e memória.

Cada modo tem características e limitações de escalonabilidade diferentes.

Para detalhes sobre os limites de recursos, consulte as diretrizes de escalonabilidade do Config Controller. Para informações sobre como gerenciar um grande número de recursos, consulte Práticas recomendadas do Config Connector.

A seguir