Cotas e limites

Version 1.16 

• Mais recente
• Versão 1.16
• Versões anteriores (sem suporte)

Nesta página, explicamos as cotas e limites da versão 1.16 do GKE em Bare Metal e limites para projetos, clusters e nós do Google Cloud.

Limites

Nas seções a seguir, descrevemos alguns limites básicos para os clusters. Considere esses limites ao projetar seus aplicativos para execução no GKE em Bare Metal.

Número máximo de clusters de usuário por cluster de administrador

Os clusters de administrador gerenciam o ciclo de vida dos clusters de usuário e dos nós associados. Os clusters de administrador controlam operações críticas de cluster de usuário, como criação de cluster, redefinições de cluster ou de nós, upgrades de cluster e atualizações de cluster. O número total de nós de cluster de usuário é um dos principais fatores que limitam o desempenho e a confiabilidade.

Com base em testes em andamento, um cluster de administrador pode oferecer suporte confiável a, no máximo, 100 clusters de usuário com 10 nós cada, totalizando 1.000 nós.

Número máximo de pods por cluster de usuário

Recomendamos limitar o número de pods por cluster de usuário a 15.000 ou menos. Por exemplo, se o cluster tiver 200 nós, restrinja o número de pods por nó a 75 ou menos. Da mesma forma, se você quiser executar 110 pods por nó, restrinja o número de nós no cluster a 136 ou menos. A tabela a seguir mostra exemplos de configurações que são ou não recomendadas.

Pods por nó	Nós por cluster	Pods por cluster	Resultado
110	200	22.000	Excesso de pods, não recomendado
110	136	14.960	Dentro do limite
100	150	15.000	Dentro do limite
75	200	15.000	Dentro do limite

O número máximo de pods por recomendação de cluster de usuário tem precedência sobre as recomendações de pods por nó e nós por cluster de usuário nas seções a seguir.

Número máximo de nós por cluster de usuário

Testamos o GKE em bare metal para executar cargas de trabalho com até 500 nós. Porém, para garantir desempenho e confiabilidade ideais, recomendamos que você não exceda 200 nós por cluster ao executar cargas de trabalho em produção.

Tipo de cluster	Mínimo de nós	Máximo de nós recomendado	Número máximo absoluto de nós
Usuário, independente ou híbrido	1	200	500

Para clusters de nó único, remova o taint node-role.kubernetes.io/master:NoSchedule para executar cargas de trabalho no nó. Para mais detalhes, consulte Taints e tolerâncias do Kubernetes;

Número máximo de pods por nó

O GKE em bare metal é compatível com a definição do máximo de pods por nó na configuração nodeConfig.PodDensity.MaxPodsPerNode do arquivo de configuração de cluster. Na tabela a seguir, mostramos os valores mínimos e máximos compatíveis com MaxPodsPerNode, incluindo pods que executam serviços complementares:

Tipo de cluster	Valor mínimo permitido	Valor máximo recomendado	Valor máximo permitido
Todos os clusters de alta disponibilidade e clusters de usuários que não são de alta disponibilidade	32	110	250
Todos os outros clusters que não são de alta disponibilidade	64	110	250

Número máximo de endpoints

No RHEL e no CentOS, há uma limitação no nível do cluster de 100.000 endpoints. Esse número é a soma de todos os pods referenciados por um serviço do Kubernetes. Se dois serviços fizerem referência ao mesmo conjunto de pods, essa situação vai contar como dois conjuntos separados de endpoints. A implementação subjacente de nftable no RHEL e no CentOS causa essa limitação. A limitação não é intrínseca do GKE em bare metal.

Mitigação

Para o RHEL e o CentOS, não há mitigações. Para os sistemas Ubuntu e Debian, é recomendável alternar do nftables padrão para iptables legado em clusters de grande escala.

Limite do eBPF do Dataplane V2

O número máximo de entradas no lbmap BPF do Dataplane V2 é 65.536. Os aumentos nas áreas a seguir podem aumentar o número total de entradas:

• Número de serviços
• Número de portas por serviço
• Número de back-ends por serviço

Recomendamos que você monitore o número real de entradas usadas pelo cluster para garantir que não exceda o limite. Use o comando a seguir para ver as entradas atuais:

kubectl get po -n kube-system -l k8s-app=cilium | cut -d " " -f1 | grep anetd | head -n1 | \
    xargs -I % kubectl -n kube-system exec % -- cilium bpf lb list | wc -l

Também recomendamos que você use seu próprio pipeline de monitoramento para coletar métricas do DaemonSet anetd. Monitore as condições a seguir para identificar quando o número de entradas está causando problemas:

cilium_bpf_map_ops_total{map_name="lb4_services_v2",operation="update",outcome="fail" } > 0

cilium_bpf_map_ops_total{map_name="lb4_backends_v2",operation="update",outcome="fail" } > 0

Limite de portas dos serviços LoadBalancer e NodePort

O limite de portas para os serviços do LoadBalancer e do NodePort é de 2.768. O intervalo de portas padrão é 30000-32767. Se você exceder o limite, não será possível criar novos serviços LoadBalancer ou NodePort nem adicionar novas portas de nó para serviços existentes.

Por padrão, o Kubernetes aloca portas de nó para serviços do tipo LoadBalancer. Essas alocações podem esgotar rapidamente as portas de nó disponíveis das 2.768 alocadas para o cluster. Para salvar portas de nó, desative a alocação de porta de nó do balanceador de carga definindo o campo allocateLoadBalancerNodePorts como false na especificação do serviço LoadBalancer. Essa configuração impede que o Kubernetes aloque portas de nó para serviços LoadBalancer. Para mais informações, consulte Como desativar a alocação de NodePort do balanceador de carga na documentação do Kubernetes.

Use o comando a seguir para verificar o número de portas alocadas:

kubectl get svc -A | grep : | tr -s ' ' | cut -d ' '  -f6 | tr ',' '\n' | wc -l

Limites de conexão de nós do balanceador de carga em pacote

O número de conexões permitidas para cada nó usado para balanceamento de carga em pacote (MetalLB) é 28.000. O intervalo de portas temporário padrão para essas conexões é 32768-60999. Se você exceder o limite de conexões, as solicitações para o serviço LoadBalancer poderão falhar.

Se você precisar expor um serviço de balanceador de carga capaz de processar um número substancial de conexões (para Entrada, por exemplo), recomendamos considerar um método alternativo de balanceamento de carga para evitar essa limitação com MetalLB.

Cotas de cluster

É possível registrar no máximo 15 clusters por padrão. Para registrar mais clusters no Hub do GKE, envie uma solicitação para aumentar a cota no console do Google Cloud:

Acesse Cotas

Observação: cada cluster de usuário precisa ter um nome exclusivo em todos os clusters de administrador que estejam dentro de um único projeto do Google Cloud.

Problemas de escalonamento

Nesta seção, descrevemos alguns problemas a serem considerados ao escalonar os clusters.

Recursos reservados para daemons do sistema

A partir da versão 1.14, o GKE em bare metal reserva automaticamente 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. Assim, eles terão os recursos necessários. Sem esse recurso, que é ativado por padrão, os pods podem consumir a maioria dos recursos de um nó, impossibilitando que daemons do sistema concluam as tarefas.

Especificamente, o GKE em bare metal reserva 50 milicores de CPU (50 mCPU) e 280 mebibytes (280 MiB) de memória de cada nó para daemons do sistema. A unidade de CPU "mCPU" significa "milésimo de um núcleo". Portanto, 50/1.000 ou 5% de um núcleo de cada nó são reservados para 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ó pode remover pods se o uso de CPU ou memória exceder os valores alocados a eles.

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 GKE em Bare Metal armazena objetos de evento em uma instância do etcd separada e dedicada. 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 a E/S do disco.

Observação: quando você faz upgrade de um cluster de uma versão que não tem uma instância etcd separada para eventos, todos os objetos de evento são perdidos. No entanto, como os objetos de evento têm um time to live (TTL) de uma hora e os upgrades geralmente levam mais de uma hora, a perda não é perceptível. Além disso, a perda de objetos de evento não afeta a operação do cluster. Os eventos precisam ser tratados como apenas dados informativos, complementares e de melhor esforço.

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 mais informações sobre o desempenho do etcd, consulte O que significa o aviso do etcd "a aplicação de entradas levou muito tempo"? e O que significa o aviso "falha ao enviar sinal de funcionamento no horário" do etcd?.

Não encontrou o que estava procurando? Clique em Enviar feedback e conte o que está faltando.