Nesta página, explicamos as cotas e os limites da versão 1.30 do Google Distributed Cloud para projetos, clusters e nós do Google Cloud.
Limites
Nas seções a seguir, descrevemos alguns limites básicos para os clusters. Leve esses limites em consideração ao projetar seus aplicativos para execução no Google Distributed Cloud.
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 Google Distributed Cloud na execução de cargas de trabalho com até 500 nós. No entanto, 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 Google Distributed Cloud oferece suporte à configuração do número máximo de pods por nó
na configuração nodeConfig.PodDensity.MaxPodsPerNode do arquivo de configuração do
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 Red Hat Enterprise Linux (RHEL), 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
do nftable no RHEL causa essa limitação, que não é intrínseca do
Google Distributed Cloud.
Mitigação
Para o RHEL, não há mitigações. Para os sistemas Ubuntu e Debian,
é recomendável
alternar do nftables padrão para o iptables legado
em clusters de grande escala.
GKE Dataplane V2
O Google Distributed Cloud usa o GKE Dataplane V2, um plano de dados de cluster implementado com o Cilium e o eBPF, otimizado para a rede do Kubernetes.
Limites de NetworkPolicy do GKE Dataplane V2
O GKE Dataplane V2 usa o Cilium para gerenciar os recursos NetworkPolicy do Kubernetes. Os
limites a seguir se aplicam aos seus clusters do Google Distributed Cloud:
| Dimensão | Limites aceitos |
|---|---|
| Taxa de mudança máxima para rótulos de namespace | No máximo, uma alteração por hora para cada namespace.
Na maioria dos casos, esse limite não é necessário. Desde que as mudanças não sejam frequentes, como a cada segundo, ou o número de identidades do Cilium (conjuntos de rótulos exclusivos) não esteja perto do limite: 16.000 conjuntos de rótulos com permitir todas as políticas de rede ou 65.535 conjuntos de rótulos por cluster. |
| Número máximo de endpoints de serviço por cluster | O limite testado e recomendado é de 100.000 endpoints. O limite fixado no código para endpoints de serviço é de 262.000. |
| Número máximo de políticas e regras de rede | No máximo, 40.000 políticas de rede e 80.000 regras. Por exemplo, você pode especificar 40.000 políticas de rede com duas regras cada ou 20.000 políticas com quatro regras cada. |
| Taxa de mudança máxima para políticas de rede | No máximo 20 mudanças (criações ou exclusões) por segundo. |
| Número máximo de conjuntos de rótulos de pods exclusivos | 65.535 (216-1). Esse é o limite de identidade de segurança do Cilium. |
| Número máximo de conjuntos de rótulos de pods únicos selecionados por seletores de política | 16.000 (o tamanho fixo do mapa eBPF). Uma determinada entrada do mapa do seletor de política consiste no seguinte: segurança-identidade, porta e protocolo. |
Limite de eBPF do GKE 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 poderá criar novos
serviços LoadBalancer ou NodePort nem adicionar novas portas de nó para
os serviços atuais.
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
Por padrão, é possível registrar no máximo 250 clusters com associações globais por frota. Para registrar mais clusters no Hub do GKE, envie uma solicitação para aumentar a cota no console do Google Cloud:
Para mais informações sobre as cotas de cluster com base nas configurações de associação, consulte Cotas de alocação.
Informações de escalonamento
As informações neste documento são relevantes para planejar o escalonamento vertical dos seus clusters. Para mais informações, consulte Escalonar verticalmente os clusters do Google Distributed Cloud.
Não encontrou o que estava procurando? Clique em Enviar feedback e conte o que está faltando.