Cette page explique les quotas et limites de la version 1.30 de Google Distributed Cloud pour les projets, clusters et nœuds Google Cloud.
Limites
Les sections suivantes décrivent certaines limites de base pour vos clusters. Tenez compte de ces limites lorsque vous concevez vos applications pour qu'elles s'exécutent sur Google Distributed Cloud.
Nombre maximal de clusters d'utilisateurs par cluster d'administrateur
Les clusters d'administrateur gèrent le cycle de vie des clusters d'utilisateurs et de leurs nœuds associés. Les clusters d'administrateur contrôlent les opérations critiques des clusters d'utilisateurs, telles que la création de clusters, la réinitialisation de clusters ou de nœuds, la mise à niveau et la mise à jour des clusters. Le nombre total de nœuds de cluster utilisateur est l'un des principaux facteurs limitant les performances et la fiabilité.
D'après les tests en cours, un cluster d'administrateur peut gérer de manière fiable un maximum de 100 clusters d'utilisateurs comportant 10 nœuds chacun, soit un total de 1 000 nœuds.
Nombre maximal de pods par cluster d'utilisateur
Nous vous recommandons de limiter le nombre de pods par cluster d'utilisateur à un maximum de 15 000. Par exemple, si votre cluster comporte 200 nœuds, vous devez limiter le nombre de pods par nœud à un maximum de 75. De même, si vous souhaitez exécuter 110 pods par nœud, vous devez limiter le nombre de nœuds de votre cluster à un maximum de 136. Le tableau suivant fournit des exemples de configurations recommandées et non recommandées.
| Nombre de pods par nœud | Nœuds par cluster | Nombre de pods par cluster | Résultat |
|---|---|---|---|
| 110 | 200 | 22 000 | Trop de pods, non recommandé |
| 110 | 136 | 14 960 | Compris dans la limite |
| 100 | 150 | 15 000 | Compris dans la limite |
| 75 | 200 | 15 000 | Compris dans la limite |
Le nombre maximal recommandé de pods par cluster d'utilisateur est prioritaire par rapport aux recommandations de pods par nœud et de nœuds par cluster d'utilisateur dans les sections suivantes.
Nombre maximal de nœuds par cluster d'utilisateur
Nous testons Google Distributed Cloud pour exécuter des charges de travail comportant 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 absolu de nœuds |
|---|---|---|---|
| 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 des 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
Google Distributed Cloud accepte 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 minimales et maximales acceptées pour MaxPodsPerNode, ce qui inclut 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
Sur Red Hat Enterprise Linux (RHEL), la limite au niveau du cluster est de 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 est comptabilisée comme deux ensembles de points de terminaison distincts. Cette limite est due à l'implémentation sous-jacente de nftable sur RHEL. Il ne s'agit pas d'une limite intrinsèque de Google Distributed Cloud.
Atténuation
Pour RHEL, il n'y a pas d'atténuation. Sur les systèmes Ubuntu et Debian, nous vous recommandons de passer de la version par défaut de nftables à l'ancienne version de iptables sur les clusters à grande échelle.
GKE Dataplane V2
Google Distributed Cloud utilise GKE Dataplane V2, un plan de données de cluster implémenté avec Cilium et eBPF, qui est optimisé pour la mise en réseau Kubernetes.
Limites de NetworkPolicy GKE Dataplane V2
GKE Dataplane V2 utilise Cilium pour gérer les ressources NetworkPolicy de Kubernetes. Les limites suivantes s'appliquent à vos clusters Google Distributed Cloud:
| Dimension | Limites compatibles |
|---|---|
| Taux de modification maximal pour les libellés d'espace de noms | Au maximum, une modification par heure pour chaque espace de noms.
Dans la plupart des cas, cette limite n'est pas nécessaire. Tant que les modifications ne sont pas fréquentes, par exemple toutes les secondes, ou que le nombre d'identités Cilium (ensembles de libellés uniques) n'est pas proche de la limite (16 000 ensembles de libellés avec la stratégie réseau Autoriser tout ou 65 535 ensembles de libellés par cluster). |
| Nombre maximal de points de terminaison de service par cluster | La limite testée et recommandée est de 100 000 points de terminaison. La limite codée en dur pour les points de terminaison de service est de 262 000. |
| Nombre maximal de règles et de stratégies réseau | 40 000 stratégies réseau et 80 000 règles au maximum. Par exemple, vous pouvez spécifier 40 000 stratégies réseau avec deux règles chacune ou 20 000 stratégies avec quatre règles chacune. |
| Taux de modification maximal pour les stratégies réseau | Au maximum, 20 modifications (créations ou suppressions) par seconde. |
| Nombre maximal d'ensembles d'étiquettes de pod uniques | 65,535 (216-1). Il s'agit de la limite de l'identité de sécurité Cilium. |
| Nombre maximal d'ensembles d'étiquettes de pod uniques sélectionnés par les sélecteurs de règles | 16 000 (taille fixe de la carte eBPF). Une entrée de mappage de sélecteur de règles donnée se compose des éléments suivants: sécurité-identité, port et protocole. |
Limite eBPF pour GKE Dataplane V2
Le nombre maximal d'entrées dans lbmap BPF pour Dataplane V2 est de 65 536. L'augmentation des éléments 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 afin de vous assurez que vous ne dépassez pas 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 de vous servir de votre propre pipeline de surveillance pour collecter des métriques à partir du DaemonSet anetd. Surveillez les conditions suivantes pour identifier le moment où 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 ports pour les services LoadBalancer et NodePort
La limite de ports pour les services LoadBalancer et NodePort est de 2 768. La plage de ports par défaut est 30000-32767. Si vous dépassez la limite, vous ne pouvez pas créer de services LoadBalancer ou NodePort, et vous ne pouvez pas ajouter de nouveaux ports de nœud pour les services existants.
Par défaut, Kubernetes alloue des ports de nœud aux services de type LoadBalancer.
Ces allocations peuvent rapidement épuiser les ports de nœud disponibles parmi les 2 768 attribués à votre cluster. Pour économiser les ports de nœud, désactivez l'allocation de ports de nœud de l'équilibreur de charge en définissant le champ allocateLoadBalancerNodePorts sur false dans la spécification du service LoadBalancer. Ce paramètre empêche Kubernetes d'allouer des ports de nœud aux services LoadBalancer. Pour en savoir plus, consultez la section Désactiver l'allocation de NodePort pour l'équilibrage de charge dans la documentation Kubernetes.
Exécutez la commande suivante pour vérifier le nombre de ports alloués :
kubectl get svc -A | grep : | tr -s ' ' | cut -d ' ' -f6 | tr ',' '\n' | wc -l
Limites de connexion des nœuds d'équilibreur de charge groupé
Le nombre de connexions autorisées pour chaque nœud utilisé pour l'équilibrage de charge groupé (MetalLB) est de 28 000. La plage de ports éphémères par défaut pour ces connexions est de 32 768 à 60 999. Si vous dépassez la limite de connexion, les requêtes adressées au service LoadBalancer peuvent échouer.
Si vous devez exposer un service d'équilibrage de charge capable de gérer un nombre important de connexions (par exemple pour Ingress), nous vous recommandons d'envisager une autre méthode d'équilibrage de charge pour éviter cette limite avec MetalLB.
Quotas des clusters
Par défaut, vous pouvez enregistrer jusqu'à 250 clusters avec des adhésions globales par flotte. Si vous souhaitez enregistrer davantage de clusters dans GKE Hub, vous pouvez demander une augmentation de quota dans la console Google Cloud :
Pour en savoir plus sur les quotas de cluster basés sur les paramètres d'appartenance, consultez la section Quotas d'allocation.
Informations sur le scaling
Les informations de ce document sont utiles pour planifier l'extension de vos clusters. Pour en savoir plus, consultez Mettre à l'échelle des clusters Google Distributed Cloud.
Vous n'avez pas trouvé ce que vous cherchez ? Cliquez sur Envoyer des commentaires et indiquez-nous ce qui manque.