Nesta página, explicamos os clusters do Anthos na versão 1.10 do bare metal em relação às cotas e aos limites para projetos, clusters e nós do Google Cloud.
Limites
Observe os limites e as recomendações a seguir para os clusters.
Número máximo de pods por cluster
Recomendamos limitar o número de pods por cluster 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 tem precedência sobre as recomendações de pods por nó e nós por cluster nas seções a seguir.
Número máximo de nós por cluster
Testamos os clusters do Anthos 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ó
Os clusters do Anthos em bare metal são compatíveis com a configuraçã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 dos
Clusters do Anthos 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 iptables 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 LoadBalancer e NodePort é 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.
Use o comando a seguir para verificar o número de portas alocadas no momento:
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:
Não encontrou o que estava procurando? Clique em Enviar feedback e conte-nos do que sentiu falta.