Cette page décrit les quotas et limites d'Anthos sur Bare Metal 1.10 pour les projets, les clusters et les nœuds Google Cloud.
Limites
Notez les limites et recommandations suivantes pour vos clusters.
Nombre maximal de pods par cluster
Nous vous recommandons de ne pas dépasser 15 000 pods par cluster. Par exemple, si votre cluster comporte 200 nœuds, vous devez limiter le nombre de pods par nœud à 75 ou moins. De même, si vous souhaitez exécuter 110 pods par nœud, vous devez limiter le nombre de nœuds de votre cluster à 136 ou moins. Le tableau suivant fournit des exemples de configurations recommandées et non recommandées.
| Nombre de pods par nœud | Nœuds par cluster | Pods par cluster | Résultat |
|---|---|---|---|
| 110 | 200 | 22 000 | Trop de pods, non recommandé |
| 110 | 136 | 14 960 | Dans la limite |
| 100 | 150 | 15 000 | Dans la limite |
| 75 | 200 | 15 000 | Dans la limite |
Le nombre maximal de pods par cluster est prioritaire par rapport aux recommandations de pods par nœud et de nœuds par cluster dans les sections suivantes.
Nombre maximal de nœuds par cluster
Nous testons des clusters Anthos sur solution Bare Metal pour exécuter des charges de travail comprenant jusqu'à 500 nœuds. Toutefois, pour garantir des performances et une fiabilité optimales, nous vous recommandons de ne pas dépasser 200 nœuds par cluster lorsque vous exécutez des charges de travail en production.
| Type de cluster | Nombre minimal de nœuds | Nombre maximal de nœuds recommandé | Nombre maximal de nœuds absolu |
|---|---|---|---|
| Utilisateur, autonome ou hybride | 1 | 200 | 500 |
Pour les clusters à nœud unique, vous devez supprimer le rejet node-role.kubernetes.io/master:NoSchedule pour exécuter les charges de travail sur le nœud.
Pour plus d'informations, consultez la section Rejets et tolérances dans Kubernetes.
Nombre maximal de pods par nœud
Les clusters Anthos sur solution Bare Metal acceptent la configuration du nombre maximal de pods par nœud dans le paramètre nodeConfig.PodDensity.MaxPodsPerNode du fichier de configuration du cluster. Le tableau suivant indique les valeurs minimale et maximale acceptées pour MaxPodsPerNode, y compris les pods exécutant des services complémentaires:
| Type de cluster | Valeur minimale autorisée | Valeur maximale recommandée | Valeur maximale autorisée |
|---|---|---|---|
| Tous les clusters haute disponibilité et clusters d'utilisateur standards | 32 | 110 | 250 |
| Tous les autres clusters standards | 64 | 110 | 250 |
Nombre maximal de points de terminaison
Au niveau du cluster, RHEL et CentOS sont limités à 100 000 points de terminaison.
Ce nombre correspond à la somme de tous les pods référencés par un service Kubernetes.
Si deux services font référence au même ensemble de pods, cette situation compte comme deux ensembles de points de terminaison distincts. L'implémentation nftable sous-jacente sur RHEL et CentOS est à l'origine de cette limitation. Il ne s'agit pas d'une limitation intrinsèque des clusters Anthos sur solution Bare Metal.
Atténuation
Sur RHEL et CentOS, il n'y a pas d'atténuation. Pour les systèmes Ubuntu et Debian, nous vous recommandons de passer de iptables par défaut à l'ancien iptables sur les clusters à grande échelle.
Limite eBPF de Dataplane V2
Le nombre maximal d'entrées dans la BBF lbmap pour Dataplane V2 est de 65 536. L'augmentation dans les domaines suivants peut entraîner une augmentation du nombre total d'entrées:
- Nombre de services
- Nombre de ports par service
- Nombre de backends par service
Nous vous recommandons de surveiller le nombre réel d'entrées utilisées par votre cluster pour vous assurer de ne pas dépasser la limite. Utilisez la commande suivante pour obtenir les entrées actuelles:
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
Nous vous recommandons également d'utiliser votre propre pipeline de surveillance pour collecter des métriques à partir du DaemonSet anetd. Surveillez les conditions suivantes pour déterminer à quel moment le nombre d'entrées pose problème:
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 port des services LoadBalancer et NodePort
La limite de port pour les services LoadBalancer et NodePort est de 2 768. La plage de ports par défaut est 30000-32767. Si vous dépassez cette limite, vous ne pourrez plus créer de services LoadBalancer ou NodePort, et vous ne pourrez pas ajouter de ports de nœud pour les services existants.
Utilisez la commande suivante pour vérifier le nombre de ports actuellement alloués:
kubectl get svc -A | grep : | tr -s ' ' | cut -d ' ' -f6 | tr ',' '\n' | wc -l
Limites de connexion des nœuds pour l'équilibreur de charge groupé
Le nombre de connexions autorisées pour chaque nœud utilisé pour l'équilibrage de charge groupé est de 28 000. La plage de ports éphémères par défaut pour ces connexions est 32768-60999. Si vous dépassez la limite de connexion, les requêtes au service LoadBalancer risquent d'échouer.
Si vous devez exposer un service d'équilibrage de charge capable de gérer un nombre important de connexions (pour l'entrée, par exemple), nous vous recommandons d'envisager une autre méthode d'équilibrage de charge pour éviter cette limitation avec MetaLB.
Quotas des clusters
Par défaut, vous pouvez enregistrer 15 clusters d'utilisateur au maximum. Pour enregistrer davantage de clusters dans GKE Hub, vous pouvez envoyer une demande d'augmentation de quota dans la console Google Cloud:
Vous n'avez pas trouvé ce que vous cherchez ? Cliquez sur Envoyer des commentaires pour nous indiquer ce qu'il manque.