Esta página explica as quotas e os limites do Google Distributed Cloud (apenas software) em bare metal para Google Cloud projetos, clusters e nós.
Limites
As secções seguintes descrevem alguns limites básicos para os seus clusters. Tenha em conta estes limites ao criar as suas aplicações para execução no Google Distributed Cloud.
Número máximo de clusters de utilizadores por cluster de administrador
Os clusters de administrador gerem o ciclo de vida dos clusters de utilizadores e dos respetivos nós associados. Os clusters de administrador controlam as operações críticas do cluster de utilizadores, como a criação de clusters, as reposições de clusters ou nós, as atualizações de clusters e as atualizações de clusters. O número total de nós do cluster de utilizadores é um dos principais fatores que limitam o desempenho e a fiabilidade.
Com base nos testes contínuos, um cluster de administrador pode suportar de forma fiável um máximo de 100 clusters de utilizadores com 10 nós cada,o que dá um total de 1000 nós.
Número máximo de pods por cluster de utilizador
Recomendamos que limite o número de pods por cluster de utilizadores a 15 000 ou menos. Por exemplo, se o cluster tiver 200 nós, deve restringir o número de pods por nó a 75 ou menos. Da mesma forma, se quiser executar 110 pods por nó, deve restringir o número de nós no cluster a 136 ou menos. A tabela seguinte apresenta exemplos de configurações que são e não são recomendadas.
| Pods por nó | Nós por cluster | Agrupamentos por cluster | Resultado |
|---|---|---|---|
| 110 | 200 | 22 000 | Demasiados 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 agrupamentos por recomendação de cluster de utilizadores tem precedência sobre as recomendações de agrupamentos por nó e nós por cluster de utilizadores nas secções seguintes.
Número máximo de nós por cluster de utilizadores
Testamos o Google Distributed Cloud para executar cargas de trabalho com até 500 nós. No entanto, para garantir um desempenho e uma fiabilidade ideais, recomendamos que não exceda os 200 nós por cluster quando executar cargas de trabalho em produção.
| Tipo de cluster | Mínimo de nós | Nós máximos recomendados | Nós máximos absolutos |
|---|---|---|---|
| Utilizador, autónomo ou híbrido | 1 | 200 | 500 |
Para clusters de nó único, tem de remover a
indicação node-role.kubernetes.io/master:NoSchedule para executar cargas de trabalho no nó.
Para ver detalhes, consulte o artigo
Kubernetes taints and tolerations.
Número máximo de pods por nó
O Google Distributed Cloud suporta a configuração do número máximo de pods por nó na definição nodeConfig.PodDensity.MaxPodsPerNode do ficheiro de configuração do cluster. A tabela seguinte mostra os valores mínimo e máximo suportados para MaxPodsPerNode, que inclui agrupamentos que executam serviços suplementares:
| Tipo de cluster | Valor mínimo permitido | Valor máximo recomendado | Valor máximo permitido |
|---|---|---|---|
| Todos os clusters de HA e clusters de utilizadores não HA | 32 | 110 | 250 |
| Todos os outros clusters não de HA | 64 | 110 | 250 |
Número máximo de pontos finais
No Red Hat Enterprise Linux (RHEL), existe uma limitação ao nível do cluster de 100 000 pontos finais. Este 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, esta situação conta como dois conjuntos de pontos finais separados. A implementação subjacente no RHEL causa esta limitação. Não é uma limitação intrínseca do Google Distributed Cloud.nftable
Mitigação
Para o RHEL, não existem mitigações. Para sistemas Ubuntu e Debian, recomendamos que
mude da predefinição nftables para a versão antiga
iptables em clusters de grande escala.
GKE Dataplane V2
O Google Distributed Cloud usa o GKE Dataplane V2, um dataplane de cluster implementado com o Cilium e o eBPF, que está otimizado para a rede do Kubernetes.
Limites do GKE Dataplane V2 NetworkPolicy
O GKE Dataplane V2 usa o Cilium para gerir os recursos do Kubernetes NetworkPolicy. Os seguintes limites aplicam-se aos seus clusters:
| Dimensão | Limites suportados |
|---|---|
| Taxa de alteração máxima para etiquetas de espaço de nomes | No máximo, uma alteração por hora para cada espaço de nomes.
Na maioria dos casos, este limite não é necessário. Desde que as alterações não sejam frequentes, como a cada segundo, ou o número de identidades do Cilium (conjuntos de etiquetas únicos) não esteja próximo do limite: 16 000 conjuntos de etiquetas com políticas de rede permitir tudo ou 65 535 conjuntos de etiquetas por cluster. |
| Número máximo de pontos finais de serviço por cluster | 100 000 pontos finais é o limite testado e recomendado. O limite codificado para pontos finais 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, pode especificar 40 000 políticas de rede com duas regras cada ou 20 000 políticas com quatro regras cada. |
| Taxa de alteração máxima para políticas de rede | No máximo, 20 alterações (criações ou eliminações) por segundo. |
| Número máximo de conjuntos de etiquetas de agrupamentos únicos | 65 535 (216-1). Este é o limite de identidade de segurança do Cilium. |
| Número máximo de conjuntos de etiquetas de agrupamentos únicos selecionados por seletores de políticas | 16 000 (o tamanho fixo do mapa eBPF). Uma determinada entrada do mapa do seletor de políticas consiste no seguinte: identidade de segurança, porta e protocolo. |
Limite de eBPF do GKE Dataplane V2
O número máximo de entradas no BPF lbmap para o Dataplane V2 é 65 536. Os aumentos nas seguintes áreas podem fazer com que o número total de entradas aumente:
- Número de serviços
- Número de portas por serviço
- Número de back-ends por serviço
Recomendamos que monitorize o número real de entradas usadas pelo seu cluster para garantir que não excede o limite. Use o seguinte comando para obter 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 use o seu próprio pipeline de monitorização para recolher métricas do anetd DaemonSet. Monitorize as seguintes condições para identificar quando o número de entradas está a causar 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 de serviços LoadBalancer e NodePort
O limite de portas para os serviços LoadBalancer e NodePort é de 2768. O intervalo de portas predefinido é 30000-32767. Se exceder o limite, não pode criar novos serviços LoadBalancer ou NodePort, nem adicionar novas portas de nós para serviços existentes.
Por predefinição, o Kubernetes atribui portas de nós a serviços do tipo LoadBalancer.
Estas atribuições podem esgotar rapidamente as portas de nós disponíveis dos 2768 atribuídos ao seu cluster. Para guardar portas de nós, desative a atribuição de portas de nós do balanceador de carga definindo o campo allocateLoadBalancerNodePorts como false na especificação do serviço LoadBalancer. Esta definição impede que o Kubernetes atribua portas de nós a LoadBalancerserviços. Para mais informações, consulte o artigo
Desativar a atribuição de NodePort do equilibrador de carga
na documentação do Kubernetes.
Use o seguinte comando para verificar o número de portas atribuídas:
kubectl get svc -A | grep : | tr -s ' ' | cut -d ' ' -f6 | tr ',' '\n' | wc -l
Limites de ligação de nós do balanceador de carga agrupados
O número de ligações permitidas para cada nó usado para o equilíbrio de carga agrupado (MetalLB) é de 28 000. O intervalo de portas efémeras predefinido para estas ligações é 32768-60999. Se exceder o limite de ligações, os pedidos ao serviço LoadBalancer podem falhar.
Se precisar de expor um serviço de balanceamento de carga capaz de processar um número substancial de ligações (por exemplo, para o Ingress), recomendamos que considere um método de balanceamento de carga alternativo para evitar esta limitação com o MetalLB.
Quotas de clusters
Por predefinição, pode registar um máximo de 250 clusters com associações globais por frota. Para registar mais clusters no GKE Hub, pode enviar um pedido para aumentar a sua quota na Google Cloud consola:
Para mais informações sobre as quotas de clusters com base nas definições de associação, consulte o artigo Quotas de atribuição.
Informações de dimensionamento
As informações neste documento são relevantes para planear como dimensionar os seus clusters. Para mais informações, consulte o artigo Aumente a escala dos clusters do Google Distributed Cloud.
Não encontrou o que procurava? Clique em Enviar feedback e diga-nos o que está em falta.