Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Présentation
Le Kubernetes Cluster Autoscaler.DesiredReplicas champ de vos groupes EC2 Auto Scaling.
Ce guide fournit un modèle mental pour configurer le Cluster Autoscaler et choisir le meilleur ensemble de compromis pour répondre aux exigences de votre organisation. Bien qu'il n'existe pas de meilleure configuration, il existe un ensemble d'options de configuration qui vous permettent de trouver un compromis entre performances, évolutivité, coût et disponibilité. En outre, ce guide fournit des conseils et des bonnes pratiques pour optimiser votre configuration pour AWS.
Glossaire
La terminologie suivante sera fréquemment utilisée dans ce document. Ces termes peuvent avoir un sens large, mais sont limités aux définitions ci-dessous aux fins du présent document.
L'évolutivité fait référence aux performances du Cluster Autoscaler lorsque le nombre de pods et de nœuds de votre cluster Kubernetes augmente. Lorsque les limites d'évolutivité sont atteintes, les performances et les fonctionnalités du Cluster Autoscaler se dégradent. Lorsque le Cluster Autoscaler dépasse ses limites d'évolutivité, il ne peut plus ajouter ou supprimer de nœuds dans votre cluster.
Les performances font référence à la rapidité avec laquelle le Cluster Autoscaler est capable de prendre et d'exécuter des décisions de dimensionnement. Un Cluster Autoscaler parfaitement performant prendrait instantanément une décision et déclencherait une action de mise à l'échelle en réponse à des stimuli, tels qu'un module devenant imprévisible.
La disponibilité signifie que les pods peuvent être programmés rapidement et sans interruption. Cela inclut les cas où les pods nouvellement créés doivent être planifiés et lorsqu'un nœud réduit met fin à tous les pods restants planifiés pour celui-ci.
Le coût est déterminé par la décision qui sous-tend la mise à l'échelle et à l'échelle des événements. Les ressources sont gaspillées si un nœud existant est sous-utilisé ou si un nouveau nœud trop grand est ajouté pour les pods entrants. Selon le cas d'utilisation, l'arrêt prématuré des pods peut entraîner des coûts en raison d'une décision agressive de réduction de la taille.
Les groupes de nœuds sont un concept Kubernetes abstrait désignant un groupe de nœuds au sein d'un cluster. Il ne s'agit pas d'une véritable ressource Kubernetes, mais elle existe sous forme d'abstraction dans le Cluster Autoscaler, l'API Cluster et d'autres composants. Les nœuds d'un groupe de nœuds partagent des propriétés telles que des étiquettes et des taches, mais peuvent être constitués de plusieurs zones de disponibilité ou types d'instances.
EC2 Auto Scaling Groups peut être utilisé comme implémentation de Node Groups sur EC2. EC2 Les groupes Auto Scaling sont configurés pour lancer des instances qui rejoignent automatiquement leurs clusters Kubernetes et appliquent des étiquettes et des modifications à la ressource Node correspondante dans l'API Kubernetes.
EC2 Les groupes de nœuds gérés sont une autre implémentation des groupes de nœuds surEC2. Ils simplifient la configuration manuelle des groupes de EC2 scalage automatique et fournissent des fonctionnalités de gestion supplémentaires, telles que la mise à niveau de la version des nœuds et la terminaison progressive des nœuds.
Utilisation du Cluster Autoscaler
Le Cluster Autoscaler est généralement installé en tant que Déploiement
Assurez-vous que :
-
La version du Cluster Autoscaler correspond à la version du Cluster. La compatibilité entre versions n'est ni testée ni prise en charge
. -
La découverte automatique
est activée, sauf si vous avez des cas d'utilisation avancés spécifiques qui empêchent l'utilisation de ce mode.
Utiliser l'accès le moins privilégié au rôle IAM
Lorsque l'Auto Discoveryautoscaling:SetDesiredCapacity et autoscaling:TerminateInstanceInAutoScalingGroup aux groupes Auto Scaling dont le périmètre est limité au cluster actuel.
Cela empêchera un cluster Autoscaler exécuté dans un cluster de modifier les groupes de nœuds d'un autre cluster même si l'--node-group-auto-discoveryargument n'était pas limité aux groupes de nœuds du cluster à l'aide de balises (par exemple). k8s.io/cluster-autoscaler/<cluster-name>
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"autoscaling:SetDesiredCapacity",
"autoscaling:TerminateInstanceInAutoScalingGroup"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/k8s.io/cluster-autoscaler/enabled": "true",
"aws:ResourceTag/k8s.io/cluster-autoscaler/<my-cluster>": "owned"
}
}
},
{
"Effect": "Allow",
"Action": [
"autoscaling:DescribeAutoScalingGroups",
"autoscaling:DescribeAutoScalingInstances",
"autoscaling:DescribeLaunchConfigurations",
"autoscaling:DescribeScalingActivities",
"autoscaling:DescribeTags",
"ec2:DescribeImages",
"ec2:DescribeInstanceTypes",
"ec2:DescribeLaunchTemplateVersions",
"ec2:GetInstanceTypesFromInstanceRequirements",
"eks:DescribeNodegroup"
],
"Resource": "*"
}
]
}Configuration de vos groupes de nœuds
Une mise à l'échelle automatique efficace commence par la configuration correcte d'un ensemble de groupes de nœuds pour votre cluster. Il est essentiel de sélectionner le bon ensemble de groupes de nœuds pour optimiser la disponibilité et réduire les coûts liés à vos charges de travail. AWS implémente des groupes de nœuds à l'aide des groupes EC2 Auto Scaling, qui sont flexibles pour un grand nombre de cas d'utilisation. Cependant, le Cluster Autoscaler émet certaines hypothèses concernant vos groupes de nœuds. En maintenant la cohérence des configurations de votre groupe EC2 Auto Scaling avec ces hypothèses, vous minimiserez les comportements indésirables.
Assurez-vous que :
-
Chaque nœud d'un groupe de nœuds possède des propriétés de planification identiques, telles que les étiquettes, les taches et les ressources.
-
En MixedInstancePolicies effet, les types d'instance doivent avoir la même forme pour le processeur, la mémoire et le processeur graphique
-
Le premier type d'instance spécifié dans la politique sera utilisé pour simuler la planification.
-
Si votre politique prévoit des types d'instances supplémentaires dotés de plus de ressources, les ressources risquent d'être gaspillées en cas de mise à l'échelle.
-
Si votre politique prévoit des types d'instances supplémentaires avec moins de ressources, les pods risquent de ne pas être planifiés sur les instances.
-
-
Les groupes de nœuds avec de nombreux nœuds sont préférés à de nombreux groupes de nœuds avec moins de nœuds. Cela aura le plus grand impact sur l'évolutivité.
-
Dans la mesure du possible, privilégiez les EC2 fonctionnalités lorsque les deux systèmes fournissent un support (par exemple, les régions, MixedInstancePolicy)
Remarque : Nous vous recommandons d'utiliser des groupes de nœuds gérés par EKS. Les groupes de nœuds gérés sont dotés de puissantes fonctionnalités de gestion, notamment des fonctionnalités pour Cluster Autoscaler, telles que la découverte automatique des groupes par EC2 Auto Scaling et la terminaison progressive des nœuds.
Optimisation des performances et de l'évolutivité
Les principaux boutons permettant de régler l'évolutivité du Cluster Autoscaler sont les ressources fournies au processus, l'intervalle d'analyse de l'algorithme et le nombre de groupes de nœuds dans le cluster. D'autres facteurs interviennent dans la véritable complexité d'exécution de cet algorithme, tels que la complexité des plugins de planification et le nombre de pods. Ces paramètres sont considérés comme non configurables car ils sont naturels à la charge de travail du cluster et ne peuvent pas être facilement ajustés.
Le Cluster Autoscaler charge l'état complet du cluster en mémoire, y compris les pods, les nœuds et les groupes de nœuds. À chaque intervalle d'analyse, l'algorithme identifie les pods non planifiables et simule la planification pour chaque groupe de nœuds. Le réglage de ces facteurs s'accompagne de différents compromis qui doivent être soigneusement pris en compte pour votre cas d'utilisation.
Mise à l'échelle automatique verticale du cluster Autoscaler
Le moyen le plus simple de faire évoluer le Cluster Autoscaler vers des clusters plus importants consiste à augmenter le nombre de demandes de ressources pour son déploiement. La mémoire et le processeur doivent être augmentés pour les clusters de grande taille, bien que cela varie considérablement en fonction de la taille du cluster. L'algorithme de mise à l'échelle automatique stocke tous les pods et nœuds en mémoire, ce qui peut entraîner une empreinte mémoire supérieure à un gigaoctet dans certains cas. L'augmentation des ressources se fait généralement manuellement. Si vous constatez que le réglage constant des ressources crée une charge opérationnelle, pensez à utiliser l'Addon Resizer
Réduction du nombre de groupes de nœuds
Minimiser le nombre de groupes de nœuds est un moyen de garantir que le Cluster Autoscaler continuera à fonctionner correctement sur les clusters de grande taille. Cela peut s'avérer difficile pour certaines organisations qui structurent leurs groupes de nœuds par équipe ou par application. Bien que cela soit entièrement pris en charge par l'API Kubernetes, cela est considéré comme un anti-modèle Cluster Autoscaler ayant des répercussions sur l'évolutivité. Il existe de nombreuses raisons d'utiliser plusieurs groupes de nœuds (par exemple, Spot ou GPUs), mais dans de nombreux cas, il existe d'autres conceptions qui permettent d'obtenir le même effet tout en utilisant un petit nombre de groupes.
Assurez-vous que :
-
L'isolation des pods est effectuée à l'aide d'espaces de noms plutôt que de groupes de nœuds.
-
Cela peut ne pas être possible dans les clusters multilocataires à faible niveau de confiance.
-
Pod ResourceRequests et ResourceLimits sont correctement réglés pour éviter les problèmes de ressources.
-
Des types d'instances plus importants permettront d'optimiser l'emballage des bacs et de réduire la surcharge du module système.
-
-
NodeTaints ou NodeSelectors sont utilisés pour planifier les pods comme exception, et non comme règle.
-
Les ressources régionales sont définies comme un seul groupe EC2 Auto Scaling avec plusieurs zones de disponibilité.
Réduction de l'intervalle entre les scans
Un faible intervalle de numérisation (10 secondes, par exemple) permettra au Cluster Autoscaler de répondre le plus rapidement possible lorsque les pods ne sont pas programmables. Cependant, chaque analyse entraîne de nombreux appels d'API vers l'API Kubernetes et EC2 Auto Scaling Group ou EKS Managed Node Group. APIs Ces appels d'API peuvent entraîner une limitation du débit ou même une indisponibilité du service pour votre plan de contrôle Kubernetes.
L'intervalle d'analyse par défaut est de 10 secondes, mais sur AWS, le lancement d'un nœud prend beaucoup plus de temps pour lancer une nouvelle instance. Cela signifie qu'il est possible d'augmenter l'intervalle sans augmenter significativement le temps de mise à l'échelle globale. Par exemple, si le lancement d'un nœud prend 2 minutes, la modification de l'intervalle à 1 minute permettra de réduire de 6 fois le nombre d'appels d'API contre des mises à l'échelle 38 % plus lentes.
Partage entre groupes de nœuds
Le Cluster Autoscaler peut être configuré pour fonctionner sur un ensemble spécifique de groupes de nœuds. Grâce à cette fonctionnalité, il est possible de déployer plusieurs instances du Cluster Autoscaler, chacune étant configurée pour fonctionner sur un ensemble différent de groupes de nœuds. Cette stratégie vous permet d'utiliser un nombre arbitrairement important de groupes de nœuds, en échangeant les coûts contre l'évolutivité. Nous recommandons de ne l'utiliser qu'en dernier recours pour améliorer les performances.
Le Cluster Autoscaler n'a pas été conçu à l'origine pour cette configuration, il présente donc certains effets secondaires. Comme les partitions ne communiquent pas, il est possible que plusieurs autoscalers tentent de planifier un pod non planifiable. Cela peut entraîner une mise à l'échelle inutile de plusieurs groupes de nœuds. Ces nœuds supplémentaires seront réduits après lescale-down-delay.
metadata:
name: cluster-autoscaler
namespace: cluster-autoscaler-1
...
--nodes=1:10:k8s-worker-asg-1
--nodes=1:10:k8s-worker-asg-2
---
metadata:
name: cluster-autoscaler
namespace: cluster-autoscaler-2
...
--nodes=1:10:k8s-worker-asg-3
--nodes=1:10:k8s-worker-asg-4Assurez-vous que :
-
Chaque partition est configurée pour pointer vers un ensemble unique de groupes EC2 Auto Scaling
-
Chaque partition est déployée dans un espace de noms distinct afin d'éviter les conflits liés à l'élection du leader
Optimisation des coûts et de la disponibilité
Instances Spot
Vous pouvez utiliser des instances Spot dans vos groupes de nœuds et économiser jusqu'à 90 % sur le prix à la demande. En contrepartie, les instances Spot peuvent être interrompues à tout moment lorsque vous avez EC2 besoin de récupérer de la capacité. Des erreurs de capacité insuffisante se produiront lorsque votre groupe EC2 Auto Scaling ne pourra pas évoluer en raison d'un manque de capacité disponible. En optimisant la diversité en sélectionnant de nombreuses familles d'instances, vous pouvez augmenter vos chances d'atteindre l'échelle souhaitée en exploitant de nombreux pools de capacité Spot et en réduisant l'impact des interruptions des instances ponctuelles sur la disponibilité de votre cluster. Les politiques d'instance mixte avec les instances Spot sont un excellent moyen d'augmenter la diversité sans augmenter le nombre de groupes de nœuds. N'oubliez pas que si vous avez besoin de ressources garanties, utilisez des instances à la demande plutôt que des instances ponctuelles.
Il est essentiel que tous les types d'instances disposent d'une capacité de ressources similaire lors de la configuration des politiques d'instance mixtes. Le simulateur de planification de l'autoscaler utilise le premier InstanceType du. MixedInstancePolicy Si les types d'instances suivants sont plus importants, les ressources risquent d'être gaspillées après une mise à l'échelle. S'ils sont plus petits, vos pods risquent de ne pas être programmés pour les nouvelles instances en raison d'une capacité insuffisante. Par exemple, les instances M4, M5, M5a et M5n ont toutes des quantités similaires de processeur et de mémoire et sont d'excellentes candidates pour un. MixedInstancePolicy L'outil EC2 Instance Selector
Il est recommandé d'isoler les capacités On-Demand et Spot dans des groupes EC2 Auto Scaling distincts. Cela est préférable à l'utilisation d'une stratégie de capacité de base car les propriétés de planification sont fondamentalement différentes. Étant donné que les instances Spot peuvent être interrompues à tout moment (lorsqu'elles ont EC2 besoin de récupérer de la capacité), les utilisateurs altèrent souvent leurs nœuds préemptables, ce qui nécessite une tolérance explicite des pods quant au comportement de préemption. Ces altérations se traduisent par des propriétés de planification différentes pour les nœuds. Ils doivent donc être séparés en plusieurs groupes EC2 Auto Scaling.
Le Cluster Autoscaler utilise un concept d'extenseurs--expander=least-waste est une bonne stratégie par défaut à usage général, et si vous comptez utiliser plusieurs groupes de nœuds pour diversifier les instances Spot (comme décrit dans l'image ci-dessus), cela pourrait contribuer à optimiser davantage les coûts des groupes de nœuds en redimensionnant le groupe qui serait le mieux utilisé après l'activité de dimensionnement.
Prioriser un groupe de nœuds/ASG
Vous pouvez également configurer le dimensionnement automatique basé sur les priorités à l'aide de l'extenseur Priority. --expander=prioritypermet à votre cluster de donner la priorité à un groupe de nœuds /ASG, et s'il n'est pas en mesure d'évoluer pour une raison quelconque, il choisira le groupe de nœuds suivant dans la liste des priorités. Cela est utile dans les situations où, par exemple, vous souhaitez utiliser des types d'instances P3 car leur GPU fournit des performances optimales pour votre charge de travail, mais comme deuxième option, vous pouvez également utiliser des types d'instances P2.
apiVersion: v1
kind: ConfigMap
metadata:
name: cluster-autoscaler-priority-expander
namespace: kube-system
data:
priorities: |-
10:
- .*p2-node-group.*
50:
- .*p3-node-group.*Cluster Autoscaler essaiera d'augmenter le groupe EC2 Auto Scaling correspondant au nom p3-node-group. Si cette opération échoue dans le délai imparti--max-node-provision-time, elle tentera de redimensionner un groupe EC2 Auto Scaling portant le nom p2-node-group. Cette valeur par défaut est de 15 minutes et peut être réduite pour une sélection plus réactive des groupes de nœuds. Toutefois, si la valeur est trop faible, cela peut entraîner des redimensionnements inutiles.
Surapprovisionnement
Le Cluster Autoscaler minimise les coûts en garantissant que les nœuds ne sont ajoutés au cluster que lorsque cela est nécessaire et qu'ils sont supprimés lorsqu'ils ne sont pas utilisés. Cela a un impact significatif sur la latence du déploiement, car de nombreux pods seront obligés d'attendre qu'un nœud augmente avant de pouvoir être planifiés. Les nœuds peuvent prendre plusieurs minutes pour devenir disponibles, ce qui peut augmenter la latence de planification des pods d'un certain ordre de grandeur.
Cela peut être atténué par un surapprovisionnement
Le surprovisionnement présente d'autres avantages moins évidents. Sans surprovisionnement, l'un des effets secondaires d'un cluster très utilisé est que les pods prendront des décisions de planification moins optimales en utilisant la preferredDuringSchedulingIgnoredDuringExecution règle de l'affinité des pods ou des nœuds. Un cas d'utilisation courant consiste à séparer les pods d'une application hautement disponible entre les zones de disponibilité à l'aide de AntiAffinity. Le surprovisionnement peut augmenter de manière significative les chances qu'un nœud de la bonne zone soit disponible.
La quantité de capacité surprovisionnée est une décision commerciale prudente pour votre entreprise. Il s'agit essentiellement d'un compromis entre performance et coût. L'une des façons de prendre cette décision consiste à déterminer votre fréquence de mise à l'échelle moyenne et à la diviser par le temps nécessaire pour augmenter la capacité d'un nouveau nœud. Par exemple, si, en moyenne, vous avez besoin d'un nouveau nœud toutes les 30 secondes et qu'il EC2 faut 30 secondes pour approvisionner un nouveau nœud, un seul nœud de surprovisionnement garantira la disponibilité d'un nœud supplémentaire, réduisant ainsi le temps de latence de planification de 30 secondes au prix d'une seule instance supplémentaire EC2 . Pour améliorer les décisions de planification zonale, surapprovisionnez un nombre de nœuds égal au nombre de zones de disponibilité de votre groupe EC2 Auto Scaling afin que le planificateur puisse sélectionner la meilleure zone pour les pods entrants.
Empêcher la réduction des expulsions
L'expulsion de certaines applications est coûteuse. L'analyse des mégadonnées, les tâches d'apprentissage automatique et les tests finiront par être terminés, mais devront être redémarrés en cas d'interruption. Le Cluster Autoscaler tentera de réduire la taille de tout nœud situé sous le scale-down-utilization-threshold, ce qui interrompra tous les pods restants sur le nœud. Cela peut être évité en veillant à ce que les pods dont l'expulsion coûte cher soient protégés par une étiquette reconnue par le Cluster Autoscaler.
Assurez-vous que :
-
Coûteux à expulser, les pods ont l'annotation
cluster-autoscaler.kubernetes.io/safe-to-evict=false
Cas d’utilisation avancés
Volumes EBS
Le stockage permanent est essentiel pour créer des applications dynamiques, telles que des bases de données ou des caches distribués. Les volumes EBS
Assurez-vous que :
-
L'équilibrage des groupes de nœuds est activé en définissant
balance-similar-node-groups=true. -
Les groupes de nœuds sont configurés avec des paramètres identiques, à l'exception des différentes zones de disponibilité et des volumes EBS.
Co-planification
Les tâches d'entraînement distribué de machine learning bénéficient de manière significative de la latence réduite des configurations de nœuds de même zone. Ces charges de travail déploient plusieurs pods dans une zone spécifique. Cela peut être réalisé en définissant l'affinité des pods pour tous les pods co-planifiés ou en utilisant l'affinité des nœuds à l'aide topologyKey: failure-domain.beta.kubernetes.io/zone de. Le Cluster Autoscaler va ensuite redimensionner une zone spécifique pour répondre aux demandes. Vous souhaiterez peut-être allouer plusieurs groupes EC2 Auto Scaling, un par zone de disponibilité, afin de permettre le basculement sur incident pour l'ensemble de la charge de travail co-planifiée.
Assurez-vous que :
-
L'équilibrage des groupes de nœuds est activé en configurant
balance-similar-node-groups=false -
L'affinité des nœuds
et/ou la préemption des pods sont utilisées lorsque les clusters incluent à la fois des groupes de nœuds régionaux et zonaux. -
Utilisez l'affinité des nœuds
pour forcer ou encourager les groupes régionaux à éviter les groupes de nœuds zonaux, et vice versa. -
Si les modules zonaux sont programmés sur des groupes de nœuds régionaux, cela entraînera un déséquilibre de capacité pour vos modules régionaux.
-
Si vos charges de travail zonales peuvent tolérer des perturbations et des relocalisations, configurez Pod Preemption pour permettre aux pods répartis
à l'échelle régionale de forcer la préemption et la replanification sur une zone moins disputée.
-
Accélérateurs
Certains clusters tirent parti d'accélérateurs matériels spécialisés tels que le GPU. Lors de la mise à l'échelle, le plug-in du dispositif accélérateur peut prendre plusieurs minutes pour annoncer la ressource au cluster. Le Cluster Autoscaler a simulé que ce nœud serait doté de l'accélérateur, mais tant que l'accélérateur ne sera pas prêt et ne mettra pas à jour les ressources disponibles du nœud, les pods en attente ne peuvent pas être planifiés sur le nœud. Cela peut entraîner une Répétition inutile de la montée en puissance
En outre, les nœuds dotés d'accélérateurs et d'une utilisation élevée du processeur ou de la mémoire ne seront pas pris en compte pour la réduction, même si l'accélérateur n'est pas utilisé. Ce comportement peut être coûteux en raison du coût relatif des accélérateurs. Au lieu de cela, le Cluster Autoscaler peut appliquer des règles spéciales pour considérer les nœuds à réduire s'ils ont des accélérateurs inoccupés.
Pour garantir le comportement correct dans ces cas, vous pouvez configurer le kubelet sur vos nœuds d'accélérateur pour étiqueter le nœud avant qu'il ne rejoigne le cluster. Le Cluster Autoscaler utilisera ce sélecteur d'étiquette pour déclencher le comportement optimisé de l'accélérateur.
Assurez-vous que :
-
Le Kubelet pour les nœuds GPU est configuré avec
--node-labels k8s.amazonaws.com/accelerator=$ACCELERATOR_TYPE -
Les nœuds dotés d'accélérateurs respectent la même règle de propriétés de planification mentionnée ci-dessus.
Échelle à partir de 0
Cluster Autoscaler est capable de redimensionner les groupes de nœuds jusqu'à zéro, ce qui peut permettre de réaliser d'importantes économies. Il détecte les ressources du processeur, de la mémoire et du processeur graphique d'un Auto Scaling Group en inspectant les informations InstanceType spécifiées dans son LaunchConfiguration ou LaunchTemplate. Certains pods nécessitent des ressources supplémentaires, telles que WindowsENI PrivateIPv4Address NodeSelectors ou des souillures spécifiques, qui ne peuvent pas être découvertes à partir du LaunchConfiguration. Le Cluster Autoscaler peut prendre en compte ces facteurs en les découvrant à partir des balises du groupe EC2 Auto Scaling. Par exemple :
Key: k8s.io/cluster-autoscaler/node-template/resources/$RESOURCE_NAME
Value: 5
Key: k8s.io/cluster-autoscaler/node-template/label/$LABEL_KEY
Value: $LABEL_VALUE
Key: k8s.io/cluster-autoscaler/node-template/taint/$TAINT_KEY
Value: NoScheduleRemarque : N'oubliez pas que lorsque vous passez à zéro, votre capacité est rétablie EC2 et peut être indisponible à l'avenir.
Paramètres supplémentaires
Il existe de nombreuses options de configuration qui peuvent être utilisées pour régler le comportement et les performances du Cluster Autoscaler. La liste complète des paramètres est disponible sur GitHub
| Paramètre | Description | Par défaut |
|---|---|---|
|
intervalle de numérisation |
À quelle fréquence le cluster est-il réévalué en vue d'une augmentation ou d'une réduction |
10 secondes |
|
max-empty-bulk-delete |
Nombre maximum de nœuds vides pouvant être supprimés simultanément. |
10 |
|
scale-down-delay-after-ajouter |
Combien de temps après l'augmentation de cette réduction reprendra l'évaluation ? |
10 minutes |
|
scale-down-delay-after-supprimer |
Combien de temps après la suppression du nœud, l'évaluation à l'échelle réduite reprend, valeur par défaut : scan-interval |
intervalle de numérisation |
|
scale-down-delay-after-échec |
Combien de temps après l'échec de la réduction, cette évaluation reprendra ? |
3 minutes |
|
scale-down-unneeded-time |
Pendant combien de temps un nœud doit-il être inutile avant de pouvoir être réduit ? |
10 minutes |
|
scale-down-unready-time |
Pendant combien de temps un nœud non prêt devrait-il être inutile avant de pouvoir être réduit |
20 minutes |
|
scale-down-utilization-threshold |
Niveau d'utilisation du nœud, défini comme la somme des ressources demandées divisée par la capacité, en dessous duquel un nœud peut être envisagé pour une réduction |
0.5 |
|
scale-down-non-empty-décompte des candidats |
Nombre maximum de nœuds non vides considérés au cours d'une itération comme candidats à une réduction avec drain. Une valeur inférieure signifie une meilleure réactivité de l'autorité de certification, mais une réduction plus lente de la latence est possible. Une valeur plus élevée peut affecter les performances de l'autorité de certification avec de grands clusters (des centaines de nœuds). Réglez cette valeur sur une valeur non positive pour désactiver cette heuristique. CA ne limitera pas le nombre de nœuds pris en compte. » |
30 |
|
scale-down-candidates-pool-ratio |
Un ratio de nœuds considérés comme des candidats non vides supplémentaires à réduire lorsque certains candidats de l'itération précédente ne sont plus valides. Une valeur inférieure signifie une meilleure réactivité de l'autorité de certification, mais une réduction plus lente de la latence est possible. Une valeur plus élevée peut affecter les performances de l'autorité de certification avec de grands clusters (des centaines de nœuds). Réglez cette valeur sur 1.0 pour désactiver cette heuristique. CA considérera tous les nœuds comme candidats supplémentaires. |
0.1 |
|
scale-down-candidates-pool-nombre minimum |
Nombre minimal de nœuds considérés comme des candidats non vides supplémentaires à réduire lorsque certains candidats de l'itération précédente ne sont plus valides. Lors du calcul de la taille du pool pour les candidats supplémentaires, nous prenons |
50 |
Ressources supplémentaires
Cette page contient une liste de présentations et de démonstrations de Cluster Autoscaler. Si vous souhaitez ajouter une présentation ou une démonstration ici, veuillez envoyer une pull request.
| Présentation/Démo | Présentateurs |
|---|---|
|
Autoscaling et optimisation des coûts sur Kubernetes : de 0 à 100 |
Guy Templeton, Skyscanner et Jiaxin Shan, Amazon |
|
Maciek Pytel et Marcin Wielgus |
Références
