Le chart Helm Cluster Autoscaler permet d'installer le Cluster Autoscaler de Kubernetes, qui ajoute des nœuds worker lorsque vos pods ne peuvent pas être planifiés et supprime les nœuds devenus inutiles. L'installation tient en une seule commande helm install, mais deux éléments déterminent en grande partie son bon fonctionnement : les paramètres que vous configurez et les requests de ressources de vos pods.
Ce guide couvre les deux, ainsi que la façon dont le Cluster Autoscaler prend ses décisions de scaling. Vous apprendrez comment le Cluster Autoscaler décide d'ajouter ou de supprimer des nœuds, quel chart installer, comment l'installer et le vérifier sur EKS, AKS et GKE, quelles valeurs Helm contrôlent son comportement, comment le régler pour les grands clusters et comment résoudre les problèmes de scaling les plus courants.
Qu'est-ce que le chart Helm Cluster Autoscaler ?
Le Cluster Autoscaler ajuste le nombre de nœuds de votre cluster en fonction des besoins de vos pods. Il ajoute des nœuds lorsque des pods ne peuvent pas être planifiés faute de capacité suffisante, et supprime les nœuds devenus inutiles lorsque leurs pods peuvent s'exécuter sur d'autres nœuds.
Pour cela, il modifie la taille des groupes de nœuds de votre fournisseur cloud, comme les Auto Scaling Groups (ASG) d'AWS, les Virtual Machine Scale Sets (VMSS) d'Azure ou les Managed Instance Groups (MIG) de Google Compute Engine.
Le chart Helm regroupe le Deployment du Cluster Autoscaler, ses permissions RBAC et sa configuration en une seule installation. Il devient ainsi plus simple à installer, à gérer et à mettre à niveau. Le Cluster Autoscaler met à l'échelle les nœuds, tandis que le HPA et KEDA mettent à l'échelle les pods.
Comment le Cluster Autoscaler décide-t-il d'ajouter ou de supprimer des nœuds ?
Voici les principaux facteurs sur lesquels le Cluster Autoscaler s'appuie pour décider quand ajouter ou supprimer des nœuds :
Les pods en attente déclenchent le scale-up
Toutes les 10 secondes, selon le paramètre --scan-interval, l'autoscaler recherche les pods bloqués en Pending parce qu'ils ne tiennent pas sur les nœuds existants. Il vérifie si un nouveau nœud de chaque groupe de nœuds pourrait exécuter ces pods, choisit un groupe adapté et augmente sa taille souhaitée pour que le fournisseur cloud ajoute un nœud. S'il n'y a aucun pod non planifiable, le Cluster Autoscaler n'ajoute pas de nœuds.
Une faible utilisation et un délai déclenchent le scale-down
Lorsqu'il n'est pas nécessaire d'ajouter des nœuds, l'autoscaler vérifie si certains peuvent être supprimés. Un nœud devient candidat lorsque les requests CPU et mémoire de ses pods passent sous le seuil --scale-down-utilization-threshold, fixé par défaut à 0,5 (50 %). Le nœud doit rester sous-utilisé pendant la durée définie par --scale-down-unneeded-time, soit 10 minutes par défaut. L'autoscaler attend également après un scale-up avant de supprimer des nœuds, selon --scale-down-delay-after-add, lui aussi fixé à 10 minutes par défaut. C'est pourquoi le scale-down est généralement plus lent que le scale-up.
Les groupes de nœuds et les expanders déterminent d'où viennent les nouveaux nœuds
L'autoscaler doit savoir quels groupes de nœuds il doit gérer. Il peut les découvrir automatiquement ou utiliser une liste explicite. Si plusieurs groupes de nœuds peuvent accueillir les pods en attente, le paramètre --expander détermine lequel agrandir. Les options sont random, most-pods, least-waste, price et priority.
Les requests de ressources pilotent les décisions de scaling
C'est l'un des points les plus importants à comprendre. Le Cluster Autoscaler se base sur les requests de ressources des pods, et non sur la consommation réelle de CPU et de mémoire. Il ajoute des nœuds lorsque les ressources demandées ne tiennent plus, et considère un nœud comme sous-utilisé en fonction des requests de ses pods. Par exemple, si des pods demandent 80 % de la capacité d'un nœud mais n'en utilisent que 20 %, l'autoscaler considère toujours le nœud comme utilisé à 80 % et peut ne pas le supprimer. Des requests surdimensionnées peuvent donc maintenir des nœuds superflus en activité et augmenter vos coûts cloud.
Quel chart Cluster Autoscaler installer ?
Pour les nouvelles installations, utilisez le chart officiel autoscaler/cluster-autoscaler du dépôt kubernetes/autoscaler.
Vous croiserez peut-être encore les anciens charts stable/aws-cluster-autoscaler et stable/cluster-autoscaler. Ils sont dépréciés et ne sont plus maintenus : évitez-les.
Helm n'est pas la seule option. Les services Kubernetes managés peuvent fournir le Cluster Autoscaler via leurs propres outils, et certaines équipes le gèrent avec Terraform. Le bon choix dépend de la façon dont vous gérez votre cluster.
Prérequis et compatibilité des versions
Avant l'installation, voici les deux points à vérifier :
Faire correspondre la version du Cluster Autoscaler à celle de Kubernetes
Utilisez le Cluster Autoscaler v1.30.x avec Kubernetes 1.30, la v1.31.x avec Kubernetes 1.31, et ainsi de suite. L'autoscaler utilise sa propre logique de scheduling pour vérifier si un pod peut tenir sur un nouveau nœud ; une version non alignée peut donc entraîner des décisions de scaling incorrectes. Vérifiez le tag d'image par défaut du chart et épinglez-le sur la bonne version si nécessaire.
Donner au Cluster Autoscaler accès à votre fournisseur cloud
L'autoscaler a besoin des permissions nécessaires pour modifier la taille de vos groupes de nœuds et doit savoir quels groupes il gère. Sur AWS, cela passe par les permissions IAM requises et des Auto Scaling Groups (ASG) correctement taggés. Sur Azure et GCE, il vous faut les permissions équivalentes et des VM Scale Sets (VMSS) ou Managed Instance Groups (MIG) correctement configurés.
Assurez-vous que ces permissions et paramètres de groupes de nœuds sont corrects avant l'installation. Le chart peut démarrer sans erreur même s'ils sont incorrects, mais le Cluster Autoscaler sera alors incapable de mettre les nœuds à l'échelle.
Installer le chart sur un cluster en fonctionnement
Commencez par ajouter le dépôt officiel :
helm repo add autoscaler https://kubernetes.github.io/autoscalerhelm repo updateAvant l'installation, vous devez indiquer au Cluster Autoscaler quels groupes de nœuds il doit gérer. La configuration dépend de votre fournisseur cloud.
Sur AKS et GKE managés, l'autoscaling des nœuds est déjà disponible nativement et s'active au niveau du pool de nœuds ; vous n'avez donc généralement pas besoin d'y installer ce chart Helm. Le chart est surtout utile pour Amazon EKS et les clusters autogérés.
Installation sur EKS
Sur EKS, l'auto-découverte est l'approche la plus simple. Commencez par tagger chaque Auto Scaling Group (ASG) que le Cluster Autoscaler doit gérer avec k8s.io/cluster-autoscaler/enabled et k8s.io/cluster-autoscaler/<your-cluster-name>.
Installez ensuite le chart :
helm install cluster-autoscaler autoscaler/cluster-autoscaler \ --namespace kube-system \ --set cloudProvider=aws \ --set autoDiscovery.clusterName=<your-cluster-name> \ --set awsRegion=<your-region>Installation sur un cluster Azure ou GCE autogéré
Pour un cluster Azure ou GCE autogéré, définissez cloudProvider=azure ou cloudProvider=gce et fournissez les informations des scale sets ou instance groups que le Cluster Autoscaler doit gérer.
Les paramètres exacts varient selon le fournisseur cloud, mais le principe reste le même : indiquer le fournisseur cloud, les groupes de nœuds et les identifiants ou l'identité que le Cluster Autoscaler doit utiliser.
Après l'installation, vérifiez que le pod du Cluster Autoscaler est en cours d'exécution :
kubectl get pods -n kube-system -l app.kubernetes.io/instance=cluster-autoscalerPuis vérifiez son statut :
kubectl describe configmap cluster-autoscaler-status -n kube-systemLe ConfigMap de statut affiche la taille de chaque groupe de nœuds ainsi que l'activité récente de scale-up ou de scale-down. Vous voyez ainsi rapidement si le Cluster Autoscaler fonctionne et prend des décisions de scaling.
Les valeurs Helm qui modifient le comportement de l'autoscaler
Voici les valeurs importantes :
cloudProvider et autoDiscovery
Elles indiquent au Cluster Autoscaler quel fournisseur cloud vous utilisez et comment trouver les groupes de nœuds à gérer. Si elles sont incorrectes, l'autoscaler n'a aucun groupe de nœuds à mettre à l'échelle.
Annotations du service account pour l'accès au cloud
Vous pouvez accorder au Cluster Autoscaler ses propres permissions cloud via son service account, plutôt que de donner des permissions étendues à tous les nœuds. Sur EKS, on utilise généralement IAM Roles for Service Accounts (IRSA). Sur Azure et GCE, Workload Identity peut être utilisé. Les annotations du service account se configurent avec rbac.serviceAccount.annotations.
extraArgs pour le comportement de scaling
extraArgs sert à définir les options du Cluster Autoscaler comme scan-interval, scale-down-utilization-threshold, scale-down-unneeded-time et expander. Vous pouvez aussi utiliser expendable-pods-priority-cutoff pour définir la priorité en dessous de laquelle les pods peuvent être considérés comme sacrifiables. Ces paramètres contrôlent la fréquence à laquelle l'autoscaler inspecte le cluster et la façon dont il choisit les nœuds à ajouter ou à supprimer.
Nombre de réplicas, élection de leader et ressources
Pour la haute disponibilité, vous pouvez exécuter plusieurs réplicas. Le Cluster Autoscaler utilise l'élection de leader : un seul réplica est actif à la fois, les autres restant prêts à prendre le relais. Définissez également des requests et limites CPU et mémoire pour l'autoscaler. Les grands clusters peuvent nécessiter plus de mémoire, car l'autoscaler conserve l'état du cluster en mémoire.
Vous pouvez définir ces valeurs dans un fichier values.yaml et installer le chart avec -f :
cloudProvider: awsautoDiscovery: clusterName: my-clusterawsRegion: us-east-1replicaCount: 2extraArgs: scan-interval: 10s scale-down-utilization-threshold: "0.5" expander: least-waste balance-similar-node-groups: "true"resources: requests: cpu: 100m memory: 300Mi limits: cpu: 200m memory: 500MiRégler le chart pour les grands clusters ou les clusters multi-tenants
Les grands clusters demandent un réglage supplémentaire, car le Cluster Autoscaler a davantage de pods, de nœuds et de groupes de nœuds à inspecter à chaque scan. Quelques paramètres et bonnes pratiques l'aident à rester performant à mesure que le cluster grandit :
Réduire le nombre de groupes de nœuds
Plus l'autoscaler gère de groupes de nœuds, plus chaque scan lui demande de travail. Dans la mesure du possible, limitez le nombre de groupes de nœuds et utilisez les tags d'auto-découverte pour n'inclure que les groupes qui ont besoin d'autoscaling.
Utiliser le sharding pour les très grands clusters
Vous pouvez exécuter plusieurs instances du Cluster Autoscaler, chacune gérant un ensemble différent de groupes de nœuds. Le travail est ainsi réparti entre plusieurs instances. En contrepartie, ces instances ne se coordonnent pas entre elles : deux d'entre elles peuvent réagir au même pod en attente et ajouter temporairement plus de nœuds que nécessaire. Ces nœuds superflus pourront être supprimés plus tard lors du scale-down.
Utiliser des nœuds Spot avec l'expander priority
Pour les clusters axés sur les coûts, vous pouvez associer des groupes de nœuds Spot à l'expander priority. L'autoscaler privilégie alors la capacité Spot, moins chère, et bascule sur des nœuds à la demande si nécessaire.
Utiliser l'overprovisioning pour un scaling plus rapide
L'overprovisioning utilise des pods de réservation à faible priorité pour réserver de la capacité supplémentaire dans le cluster. Lorsque de vrais workloads arrivent, ces pods de réservation sont évincés pour libérer de la place pendant que l'autoscaler ajoute de nouveaux nœuds.
Mettre à l'échelle les groupes de nœuds à partir de zéro
Un groupe de nœuds peut descendre à zéro lorsqu'il n'est pas utilisé. C'est particulièrement utile pour les groupes de nœuds GPU coûteux. Sur EKS, assurez-vous que le groupe de nœuds porte les labels et taints requis dans ses tags d'autoscaler, afin que le Cluster Autoscaler sache ce que les nœuds peuvent offrir même lorsque le groupe ne compte aucun nœud.
Diagnostiquer une installation qui ne déclenche aucun scaling
Lorsque le scaling ne se déclenche pas comme prévu, le ConfigMap de statut et les logs du pod sont les meilleurs points de départ. Voici les cas les plus courants :
Les pods restent en Pending et aucun nœud n'est ajouté
Commencez par kubectl describe pod <pod-name> et consultez les événements du pod. Vérifiez ensuite les logs du Cluster Autoscaler. Parmi les causes fréquentes : un groupe de nœuds déjà à sa taille maximale, aucun groupe de nœuds avec assez de capacité pour les requests de ressources du pod, ou un node selector ou une affinité du pod qui ne correspond à aucun groupe de nœuds disponible. Des permissions cloud ou des tags de groupes de nœuds manquants peuvent aussi empêcher l'autoscaler de trouver ou de modifier le groupe de nœuds.
Des nœuds restent sous-utilisés sans être supprimés
Le Cluster Autoscaler ignore certains nœuds par défaut. Par exemple, il ignore les nœuds exécutant des pods kube-system lorsque --skip-nodes-with-system-pods est activé, et les nœuds dont les pods utilisent du stockage local lorsque --skip-nodes-with-local-storage est activé. Il respecte aussi le délai avant scale-down. Surtout, rappelez-vous que le Cluster Autoscaler se base sur les requests de ressources, et non sur l'utilisation réelle. Si les requests maintiennent un nœud au-dessus du seuil d'utilisation, il ne deviendra pas candidat à la suppression, même si la consommation réelle de CPU et de mémoire est faible.
Des annotations et des PodDisruptionBudgets bloquent la suppression de nœuds
Le Cluster Autoscaler ne supprimera pas un nœud si cela violerait un PodDisruptionBudget (PDB). Il ignore aussi les pods portant cluster-autoscaler.kubernetes.io/safe-to-evict: "false" et les nœuds portant l'annotation scale-down-disabled. Ces réglages protègent les workloads contre les évictions indésirables, mais un paramètre obsolète ou superflu peut maintenir un nœud en activité plus longtemps que prévu. Consultez kubectl describe configmap cluster-autoscaler-status -n kube-system pour voir quels nœuds ne peuvent pas être supprimés, et pourquoi.
Les outils complémentaires du Cluster Autoscaler
Le Cluster Autoscaler gère le nombre de nœuds, mais les outils suivants peuvent vous aider sur le dimensionnement des pods et le provisionnement des nœuds.
PerfectScale
Le Cluster Autoscaler prend ses décisions de scaling en fonction des requests de ressources des pods, et non de la consommation réelle de CPU et de mémoire. Si les requests sont trop élevées, il peut ajouter des nœuds dont vous n'avez pas besoin et conserver des nœuds qui pourraient être supprimés. PerfectScale surveille l'utilisation réelle des workloads et fournit des recommandations de right-sizing automatisées pour rapprocher les requests CPU et mémoire de la consommation réelle. Le Cluster Autoscaler peut ainsi prendre de meilleures décisions de scaling. Vous pouvez l'essayer ou réserver une session technique.
Vertical Pod Autoscaler (VPA) et Goldilocks
Le VPA ajuste les requests de ressources des pods en fonction de l'utilisation observée. Goldilocks fournit un dashboard pour consulter les recommandations du VPA. Les deux aident à garder des requests proches de la consommation réelle, ce qui donne au Cluster Autoscaler de meilleures informations pour ses décisions de scaling.
Karpenter
Karpenter adopte une approche différente du scaling des nœuds. Au lieu de redimensionner des groupes de nœuds fixes, il peut provisionner des nœuds en fonction des besoins des pods en attente.
Bonnes pratiques pour exécuter le Cluster Autoscaler en production
Les pratiques suivantes aident à garder un autoscaling des nœuds efficace et sûr :
1. Dimensionner correctement les requests des pods avant de régler l'autoscaler
Le Cluster Autoscaler prend ses décisions à partir des requests de ressources des pods : des requests précises comptent donc plus que l'ajustement des paramètres de l'autoscaler. Corrigez d'abord les requests, puis réglez les délais et les expanders.
2. Garder des groupes de nœuds homogènes en CPU, mémoire et zone de disponibilité
Les nœuds d'un même groupe sont censés être similaires. Des types d'instances ou des zones de disponibilité différents peuvent fausser la simulation de scheduling de l'autoscaler. Les groupes de nœuds similaires peuvent être équilibrés avec balance-similar-node-groups.
3. Définir des PodDisruptionBudgets pour les workloads à ne pas interrompre
Un PodDisruptionBudget (PDB) définit combien de pods peuvent être indisponibles simultanément. Le Cluster Autoscaler peut ainsi supprimer des nœuds tout en conservant suffisamment de réplicas disponibles pour le workload.
4. Épingler la version du chart et tester les mises à niveau
La version du Cluster Autoscaler doit correspondre à celle de Kubernetes. Toute mise à niveau de Kubernetes doit donc être testée avec la version correspondante de l'autoscaler avant d'arriver en production.
5. Exporter les métriques de l'autoscaler vers Prometheus et alerter sur les scale-ups en échec
Le Cluster Autoscaler expose des métriques Prometheus qui montrent l'activité de scaling et les échecs. Des alertes sur les scale-ups en échec et les pods qui restent en Pending aident à détecter les problèmes avant qu'ils n'affectent durablement les workloads.
6. Confronter les seuils de scale-down aux économies réellement obtenues
Un scale-down agressif peut réduire les coûts, mais les workloads sujets à des pics de trafic soudains risquent de monter et descendre trop souvent. Le scale-down-utilization-threshold et les délais de scale-down peuvent être ajustés à vos schémas de trafic réels, plutôt que réglés uniquement pour réduire le nombre de nœuds.