Cette page décrit les quotas et limites de GKE sur Bare Metal 1.14 pour les projets, clusters et nœuds Google Cloud.
Limites
Notez les limites et recommandations suivantes pour vos clusters.
Nombre maximal de pods par cluster
Nous vous recommandons de limiter le nombre de pods par cluster à 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 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 GKE sur une solution Bare Metal 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
GKE sur Bare Metal est compatible avec 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 RHEL et CentOS, 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. L'implémentation de nftable sous-jacente sur RHEL et CentOS entraîne cette limitation. Il ne s'agit pas d'une limitation intrinsèque de GKE sur 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 la valeur par défaut nftables à l'ancienne version de iptables sur les clusters à grande échelle.
Limite eBPF pour 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 de 30 000 à 32 767. 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œuds aux services de type LoadBalancer.
Ces allocations peuvent rapidement épuiser les ports de nœud disponibles sur les 2 768 ports alloués à votre cluster. Pour enregistrer les ports de nœud, désactivez l'allocation de ports des nœuds 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 NodePort de l'équilibreur de charge dans la documentation de Kubernetes.
Exécutez 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 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 15 clusters d'utilisateur au maximum. Si vous souhaitez enregistrer davantage de clusters dans GKE Hub, vous pouvez demander une augmentation de quota dans la console Google Cloud :
Problèmes de scaling
Cette section décrit certains problèmes à prendre en compte lors du scaling des clusters.
Ressources réservées aux daemons système
À partir de la version 1.14, GKE sur Bare Metal réserve automatiquement des ressources sur un nœud pour les daemons système tels que sshd ou udev. Les ressources de processeur et de mémoire sont réservées sur un nœud pour les daemons système afin que ces daemons disposent des ressources dont ils ont besoin. Sans cette fonctionnalité, qui est activée par défaut, les pods peuvent potentiellement consommer la plupart des ressources d'un nœud, ce qui empêche les daemons système d'effectuer leurs tâches.
Plus précisément, GKE sur Bare Metal réserve 50 millicores de processeur (50 mCPU) et 280 mébioctets (280 Mio) de mémoire sur chaque nœud aux daemons système. Notez que l'unité de processeur "mCPU" signifie "millième d'un cœur". Ainsi, 50/1 000, soit 5% d'un cœur sur chaque nœud, sont réservés aux daemons système. Le nombre de ressources réservées est faible et n'a pas d'impact significatif sur les performances des pods. Cependant, le kubelet d'un nœud peut évincer les pods si l'utilisation du processeur ou de la mémoire dépasse les quantités qui leur ont été allouées.
Performances etcd
La vitesse du disque est essentielle à la performance et à la stabilité d'etcd. Un disque lent augmente la latence des requêtes etcd, ce qui peut entraîner des problèmes de stabilité du cluster. Nous vous recommandons d'utiliser un disque dur SSD pour votre espace de stockage etcd. La documentation d'etcd fournit des recommandations matérielles pour garantir les meilleures performances etcd lors de l'exécution de vos clusters en production.
Pour vérifier les performances de votre etcd et de votre disque, utilisez les métriques de latence des E/S etcd suivantes dans l'explorateur de métriques :
etcd_disk_backend_commit_duration_seconds: la durée doit être inférieure à 25 millisecondes pour le 99e centile (p99).etcd_disk_wal_fsync_duration_seconds: la durée doit être inférieure à 10 millisecondes pour le 99e centile (p99).
Pour en savoir plus sur les performances de l'etcd, consultez la page Que signifie l'avertissement etcd "Appliquer les entrées a pris trop de temps" ? et Que signifie l'avertissement etcd "Échec de l'envoi de pulsations dans les temps" ?.
Vous n'avez pas trouvé ce que vous cherchez ? Cliquez sur Envoyer des commentaires pour nous informer des éléments manquants.