Planeje cargas de trabalho grandes


Nesta página, você verá as práticas recomendadas para gerenciar cargas de trabalho grandes em vários clusters do GKE. Essas práticas abordam como distribuir cargas de trabalho em vários projetos e ajustar as cotas necessárias.

Práticas recomendadas para distribuir cargas de trabalho do GKE em vários projetos do Google Cloud

Para definir melhor a estrutura do projeto do Google Cloud e a distribuição das cargas de trabalho do GKE, com base nos seus requisitos de negócios, recomendamos as seguintes ações de design e planejamento:

  1. Siga as práticas recomendadas em Gerenciar recursos em nuvem para tomar decisões iniciais para a estrutura da sua organização para pastas e projetos. O Google Cloud recomenda o uso de elementos da hierarquia de recursos, como pastas e projetos, para dividir a carga de trabalho com base nos próprios limites organizacionais ou políticas de acesso.
  2. Considere se é necessário dividir as cargas de trabalho devido às cotas do projeto. O Google Cloud usa cotas por projeto para restringir o uso de recursos compartilhados. Você precisa seguir as recomendações descritas abaixo e ajustar as cotas do projeto para cargas de trabalho grandes. Para a maioria das cargas de trabalho, você precisa conseguir cotas maiores e necessárias em um único projeto. Isso significa que as cotas não podem ser o principal impulsionador para dividir a carga de trabalho entre vários projetos. Manter as cargas de trabalho em um número menor de projetos simplifica a administração das cotas e cargas de trabalho.
  3. Considere se você planeja executar cargas de trabalho muito grandes (escala de centenas de milhares de CPUs ou mais). Nesse caso, dividir sua carga de trabalho em vários projetos pode aumentar a disponibilidade de recursos da nuvem, como CPUs ou GPUs. Isso é possível devido ao uso da configuração otimizada da virtualização de zona. Nesses casos, entre em contato com o gerente de contas para receber suporte especial e recomendações.

Práticas recomendadas para ajustar cotas de grandes cargas de trabalho do GKE

Nesta seção, descrevemos as diretrizes para ajustar cotas de recursos do Google Cloud usadas pelas cargas de trabalho do GKE. Ajuste as cotas dos projetos com base nas diretrizes a seguir. Para saber como gerenciar sua cota usando o console do Google Cloud, consulte Como trabalhar com cotas.

Cotas e práticas recomendadas do Compute Engine

Os clusters do GKE, em execução no modo Autopilot e padrão, usam recursos do Compute Engine para executar suas cargas de trabalho. Ao contrário dos recursos do plano de controle do Kubernetes que são gerenciados internamente pelo Google Cloud, é possível gerenciar e avaliar as cotas do Compute Engine que seus fluxos de trabalho usam.

As cotas do Compute Engine, para recursos e APIs, são compartilhadas por todos os clusters do GKE hospedados no mesmo projeto e região. As mesmas cotas também são compartilhadas com outros recursos do Compute Engine (não relacionados ao GKE) (como instâncias de VM independentes ou grupos de instâncias).

Os valores de cota padrão oferecem suporte a várias centenas de nós de trabalho e exigem ajuste para cargas de trabalho maiores. No entanto, como administrador da plataforma, você pode ajustar proativamente as cotas do Compute Engine para garantir que seus clusters do GKE tenham recursos suficientes. Considere também as futuras necessidades de recursos ao avaliar ou ajustar os valores da cota.

Cotas para recursos do Compute Engine usados por nodes de trabalho do GKE

Veja na tabela a seguir as cotas de recursos mais comuns dos recursos do Compute Engine usados pelos nós de trabalho do GKE. Essas cotas são configuradas por projeto e por região. As cotas precisam cobrir o tamanho máximo combinado dos nós de trabalho do GKE usados pela carga de trabalho e também outros recursos do Compute Engine não relacionados ao GKE.

Cota de recursos Descrição
CPUs Número de CPUs usadas por todos os nodes de trabalho de todos os clusters.
Tipo de CPUs Número de cada tipo específico de CPU usada por todos os nodes de trabalho de todos os clusters.
Instâncias de VM Número de todos os nodes de trabalho. Essa cota é calculada automaticamente como 10 vezes o número de CPUs.
Instâncias por rede VPC Número de todos os nodes de trabalho conectados à rede VPC.
Disco permanente padrão (GB) Tamanho total dos discos de inicialização permanentes padrão anexados a todos os nodes de trabalho.
Persistent disk SSD (GB) Tamanho total dos discos de inicialização permanentes SSD anexados a todos os nodes de trabalho.
Local SSD (GB) Tamanho total dos discos temporários de SSD locais anexados a todos os nodes de trabalho.

Ajuste também as cotas usadas pelos recursos que sua carga de trabalho pode exigir, como GPUs, endereços IP ou recursos preventivos.

Cotas para chamadas da API Compute Engine

Clusters grandes ou escalonáveis exigem um número maior de chamadas da API Compute Engine. O GKE faz essas chamadas da API Compute Engine durante atividades como:

  • Verificar o estado dos recursos de computação.
  • Adicionar ou remover novos nós no cluster.
  • Adicionar ou remover novos pools de nodes.
  • Rotulação periódica de recursos.

Ao planejar a arquitetura de clusters de tamanho grande, recomendamos que você faça o seguinte:

  1. Observe o consumo de cota histórica.
  2. Ajuste as cotas conforme necessário e mantenha um buffer razoável. Consulte as recomendações de práticas recomendadas a seguir como ponto de partida e ajuste as cotas com base nas necessidades da carga de trabalho.
  3. Como as cotas são configuradas por região, ajuste-as somente nas regiões em que você planeja executar cargas de trabalho grandes.

Na tabela a seguir, listamos as cotas para chamadas da API Compute Engine. Essas cotas são configuradas por projeto, independentemente por região. As cotas são compartilhadas por todos os clusters do GKE hospedados no mesmo projeto e na mesma região.

Cota de API Descrição Práticas recomendadas
Consultas por minuto em cada região Essas chamadas são usadas pelo GKE para executar várias verificações no estado dos diversos recursos de computação.

Para projetos e regiões com centenas de nós dinâmicos, ajuste esse valor para 3.500.

Para projetos e regiões com milhares de nós altamente dinâmicos, ajuste esse valor para 6.000.

Solicitações de leitura por minuto e região Essas chamadas são usadas pelo GKE para monitorar o estado das instâncias de VM (nós).

Para projetos e regiões com várias centenas de nós, ajuste esse valor para 12.000.

Para projetos e regiões com milhares de nós, ajuste esse valor para 20.000.

Solicitações de lista por minuto e região Essas chamadas são usadas pelo GKE para monitorar o estado dos grupos de instâncias (pools de nós).

Para projetos e regiões com várias centenas de nós dinâmicos, não altere o valor padrão, porque ele é suficiente.

Para projetos e regiões com milhares de nós altamente dinâmicos, em vários pools de nós, ajuste esse valor para 2.500.

Solicitações do referenciador da lista de instâncias por minuto e região Essas chamadas são usadas pelo GKE para receber informações sobre a execução de instâncias de VM (nós).

Para projetos e regiões com milhares de nós altamente dinâmicos, ajuste esse valor para 6.000.

Solicitações de leitura por minuto por região Essas chamadas são usadas pelo GKE para receber informações sobre operações contínuas da API Compute Engine.

Para projetos e regiões com milhares de nós altamente dinâmicos, ajuste esse valor para 3.000.

Cotas e práticas recomendadas das APIs Cloud Logging e Cloud Monitoring

Dependendo da configuração do cluster, grandes cargas de trabalho em execução nos clusters do GKE podem gerar um grande volume de informações de diagnóstico. Ao exceder as cotas da API Cloud Logging ou da API Cloud Monitoring, os dados de registro e monitoramento podem ser perdidos. Recomendamos que você configure o nível de detalhes dos registros e ajuste as cotas da API Cloud Logging e da API Cloud Monitoring para capturar as informações de diagnóstico geradas. O Serviço gerenciado para o Prometheus consome cotas do Cloud Monitoring.

Como cada carga de trabalho é diferente, recomendamos o seguinte:

  1. Observe o consumo de cota histórica.
  2. Ajuste as cotas ou a configuração de geração de registros e monitoramento, conforme necessário. Mantenha um buffer razoável para problemas inesperados.

Confira na tabela a seguir as cotas das chamadas de APIs do Cloud Logging e do Cloud Monitoring. Essas cotas são configuradas por projeto e compartilhadas por todos os clusters do GKE hospedados no mesmo projeto.

Serviço Cota Descrição Práticas recomendadas
API Cloud Logging Solicitações de gravação por minuto O GKE usa essa cota ao adicionar entradas aos arquivos de registros armazenados no Cloud Logging.

A taxa de inserção de registro depende da quantidade de registros gerados pelos pods no cluster. Aumente sua cota com base no número de pods, no nível de detalhes da geração de registros de aplicativos e na configuração da geração de registros.

Para saber mais, consulte Como gerenciar registros do GKE.

API Cloud Monitoring Solicitações de ingestão de séries temporais por minuto

O GKE usa essa cota ao enviar métricas do Prometheus para o Cloud Monitoring:

  • As métricas do Prometheus consomem cerca de uma chamada por segundo para cada 200 amostras por segundo coletadas. Esse volume de ingestão depende da sua carga de trabalho e da configuração do GKE. Exportar mais séries temporais do Prometheus resultará em mais cota consumida.

Monitore e ajuste essa cota conforme apropriado.

Para saber mais, consulte Como gerenciar métricas do GKE.

Cota de nós do GKE e práticas recomendadas

O GKE aceita até 15.000 nós em um único cluster com a cota padrão definida como 5.000 nós. Essa cota é definida separadamente para cada cluster do GKE, e não por projeto, como outras cotas. Se você planeja escalonar seu cluster acima de 5.000 nós, siga estas etapas:

  1. Identifique o cluster que você quer escalonar além de 5.000 nós.
  2. Verifique se a carga de trabalho permanece dentro dos limites do cluster e das cotas do GKE após o escalonamento.
  3. Não se esqueça de aumentar as cotas do Compute Engine conforme necessário para a carga de trabalho escalonada.
  4. Verifique se o tipo de disponibilidade do cluster é regional e o isolamento da rede é privado.
  5. Solicite um aumento da cota para o número de nós por cluster criando um tíquete de suporte.

A equipe do GKE entrará em contato com você para garantir que sua carga de trabalho siga as práticas recomendadas de escalonabilidade e esteja pronta para escalonar além de 5.000 nós em um único cluster.

Práticas recomendadas para evitar outros limites para grandes cargas de trabalho

Limite para o número de clusters que usam peering de rede VPC por rede por local

É possível criar no máximo 75 clusters particulares que usam peering de rede VPC na mesma rede VPC para cada local. As zonas e regiões são tratadas como locais separados. As tentativas de criar mais clusters acima do limite falhariam com um erro semelhante a este:

CREATE operation failed. Could not trigger cluster creation:
Your network already has the maximum number of clusters: (75) in location us-central1.

Os clusters particulares do GKE usam o peering de rede VPC para fornecer comunicação interna entre o servidor da API Kubernetes (gerenciado pelo Google) e os nós particulares que têm apenas endereços internos.

Para resolver esse problema, use clusters que usem a conectividade Private Service Connect (PSC). Clusters com conectividade PSC oferecem o mesmo isolamento que um cluster particular sem a limitação de 75 clusters. Os clusters baseados em PSC não usam peering de rede VPC e não são afetados pelo limite do número de peerings de VPC.

Use as instruções fornecidas em Reutilização do peering de rede VPC para identificar se os clusters usam esse tipo de peering.

Para evitar atingir o limite ao criar novos clusters, siga estas etapas:

  1. Crie um cluster PSC usando o parâmetro no-enable-private-nodes durante a criação do cluster.
  2. Configure o isolamento para que os pools de nós se tornem particulares usando o parâmetro enable-private-nodes para cada pool de nós.
  3. Se quiser, configure o isolamento do plano de controle usando o parâmetro enable-private-endpoint no nível do cluster. Para saber mais, consulte Alterar isolamento de clusters.

Como alternativa, entre em contato com a equipe de suporte do Google Cloud para aumentar o limite de 75 clusters particulares usando o peering de rede VPC. Essas solicitações são avaliadas caso a caso e, quando é possível aumentar o limite, um aumento de um único dígito é aplicado.

A seguir