Cotas e limites


Veja neste documento as cotas e os limites do sistema que se aplicam ao Google Kubernetes Engine. As cotas especificam a quantidade de um recurso compartilhado e contável que pode ser usado e são definidas por serviços do Google Cloud, como o Google Kubernetes Engine. Os limites do sistema são valores fixos que não podem ser alterados.

O Google Cloud usa cotas para garantir a imparcialidade e reduzir picos no uso e na disponibilidade de recursos. Uma cota restringe quanto de um recurso do Google Cloud o projeto do Google Cloud pode usar. As cotas se aplicam a vários tipos de recursos, incluindo hardware, software e componentes de rede. Por exemplo, as cotas podem restringir o número de chamadas de API para um serviço, o número de balanceadores de carga usados simultaneamente pelo projeto ou o número de projetos que podem ser criados. As cotas protegem a comunidade de usuários do Google Cloud, impedindo a sobrecarga de serviços. As cotas também ajudam você a gerenciar seus próprios recursos do Google Cloud.

O sistema de cotas do Cloud faz o seguinte:

  • Monitora o consumo de produtos e serviços do Google Cloud.
  • Restringe o consumo desses recursos.
  • Fornece um meio de solicitar mudanças no valor da cota

Na maioria dos casos, quando você tenta consumir mais de um recurso do que a cota permite, o sistema bloqueia o acesso ao recurso e a tarefa que você está tentando executar falha.

As cotas geralmente se aplicam ao projeto do nível Google Cloud. O uso de um recurso em um projeto não afeta a cota disponível em outro. Em um projeto do Google Cloud, as cotas são compartilhadas entre todos os aplicativos e endereços IP.

Para ajustar a maioria das cotas, use o console do Google Cloud. Para mais informações, consulte Solicitar uma cota maior.

Também há limites de sistemas nos recursos do GKE. Esses limites de sistemas não estão relacionados ao sistema de cotas. Não é possível mudar os limites de sistemas, a menos que seja indicado o contrário.

Limites por projeto

Em um único projeto, é possível criar no máximo 100 clusters zonais por zona e 100 clusters regionais por região.

Observação: os clusters criados no modo de Autopilot são pré-configurados como clusters regionais.

Limites por cluster

As tabelas a seguir descrevem os limites por cluster do GKE.

Todas as versões do GKE especificadas na tabela a seguir se aplicam aos nós do cluster e ao plano de controle.

Limites Cluster do GKE Standard Cluster do GKE Autopilot
Nós por cluster 15.000 nós

Observação: se você planeja executar mais de 2.000 nós, use um cluster regional.

Observação : a execução de mais de 5.000 nós só está disponível para clusters regionais, particulares ou com Private Service Connect e com o GKE Dataplane V2 desativado. Entre em contato com o suporte para aumentar esse limite.

5.000 nós

Observação: se você planeja executar mais de 1.000 nós, use a versão 1.23 ou mais recente do GKE Autopilot.

Observação: a execução de mais de 400 nós pode exigir o aumento da cota de tamanho dos clusters criados em versões anteriores. Entre em contato com o suporte para receber ajuda.

Nós por pool de nós 1.000 nós por zona Não relevante
Nós em uma zona
  • Não há limitações de nós para o balanceamento de carga nativo de contêiner com entrada baseada no NEG, que é recomendado sempre que possível. No GKE 1.17 e versões posteriores, a entrada com base em NEG é o modo padrão.
  • 1.000 nós se você estiver usando uma entrada baseada em grupo de instâncias.
Não relevante
Pods por nó1 256 pods

Observação: para versões do GKE anteriores à 1.23.5-gke.1300, o limite é de 110 pods.

Defina dinamicamente para qualquer valor entre 8 e 256. O GKE considera o tamanho do cluster e o número de cargas de trabalho para provisionar o máximo de pods por nó.

  • Nas versões do GKE anteriores à 1.28, o limite é de 32 pods.
  • Para pods da classe acelerador e de desempenho, o limite é um pod por nó.
Pods por cluster2 200.000 pods1 200.000 Pods
Contêineres por cluster 400.000 contêineres 400.000 contêineres
Tamanho do banco de dados de Etcd 6 GB 6 GB

Como administrador da plataforma, é recomendado familiarizar-se com a forma como as cotas afetam as cargas de trabalho grandes executadas no GKE. Para conferir outras recomendações, práticas recomendadas, limites e cotas para cargas de trabalho grandes, consulte Diretrizes para criar clusters escalonáveis.

Limite para solicitações de API

A limitação de taxa padrão da API Kubernetes Engine é de 3.000 solicitações por minuto, aplicado a cada 100 segundos.

Cotas de recursos

Para clusters com menos de 100 nós, o GKE aplica a cota de recursos do Kubernetes a cada namespace. Essas cotas protegem o plano de controle do cluster contra a instabilidade causada por possíveis bugs nos aplicativos implantados no cluster. Não é possível remover essas cotas porque elas são aplicadas pelo GKE.

O GKE atualiza automaticamente os valores da cota de recursos proporcionalmente ao número de nós. Para clusters com mais de 100 nós, o GKE remove a cota de recursos.

Para examinar as cotas de recursos, use o comando a seguir:

kubectl get resourcequota gke-resource-quotas -o yaml

Para conferir os valores de um determinado namespace, especifique-o adicionando a opção --namespace.

Verificar sua cota

Console

  1. No Console do Google Cloud, acesse a página Cotas.

    Acesse Cotas

  2. A página Cotas exibe a lista de cotas pré-filtradas para as cotas do GKE.
  3. Para pesquisar a cota exata, use a tabela de filtros. Se você não souber o nome da cota, use os links da página Cotas.

gcloud

  1. Para verificar suas cotas, execute o seguinte comando:
    gcloud compute project-info describe --project PROJECT_ID

    Substitua PROJECT_ID pelo seu código do projeto:

  2. Para verificar a cota utilizada em uma região, execute o comando a seguir:
    gcloud compute regions describe example-region

Observações

  1. O número máximo de pods por cluster padrão do GKE inclui pods do sistema. O número de pods do sistema varia de acordo com a configuração do cluster e os recursos ativados.

  2. O número máximo de pods que podem caber em um nó depende do tamanho das solicitações de recursos do pod e da capacidade do nó. Talvez você não atinja todos os limites ao mesmo tempo. Como prática recomendada, carregue implantações de teste grandes.