Qu'est-ce que le Cluster Autoscaler de Kubernetes ?
Le Cluster Autoscaler de Kubernetes est un composant open source conçu pour ajuster automatiquement la taille d'un cluster Kubernetes en fonction des besoins actuels des workloads. Il surveille les pods qui ne peuvent pas être planifiés faute de ressources suffisantes, puis agrandit le cluster en ajoutant des nœuds lorsque c'est nécessaire. À l'inverse, il identifie les nœuds sous-utilisés et réduit la taille du cluster en supprimant les nœuds superflus, garantissant ainsi une utilisation optimale des ressources et une meilleure maîtrise des coûts.
Ce dimensionnement dynamique permet de maintenir une haute disponibilité et de bonnes performances sans intervention manuelle. Le Cluster Autoscaler prend en charge plusieurs fournisseurs cloud, dont AWS, Azure et Google Cloud, et s'intègre parfaitement à leurs offres Kubernetes managées. Il s'appuie sur les API propres à chaque fournisseur pour provisionner et retirer des nœuds selon les besoins, ce qui permet aux organisations de réagir en temps réel aux variations de trafic.
Cet article fait partie d'une série consacrée à l'autoscaling Kubernetes
Dans cet article :
- Que sont les charts Helm ?
- Tutoriel : premiers pas avec le Cluster Autoscaler via un chart Helm
- Bonnes pratiques pour le chart Helm du Cluster Autoscaler
Que sont les charts Helm ?
Les charts Helm sont des packages standardisés pour les applications Kubernetes, contenant tous les manifestes YAML et les templates nécessaires pour définir, configurer et déployer des workloads complexes. Ils simplifient le processus de déploiement en regroupant les ressources applicatives, les dépendances et les valeurs de configuration dans un artefact unique et réutilisable. Les charts Helm peuvent être :
- Versionnés
- Partagés
- Stockés dans des dépôts
Grâce aux charts Helm, les équipes peuvent automatiser l'installation, la mise à niveau et le rollback des applications, réduisant ainsi le risque d'erreur humaine et garantissant la cohérence entre les environnements. Le moteur de templating de Helm permet de personnaliser les déploiements, les utilisateurs pouvant remplacer les valeurs par défaut via un fichier de valeurs ou des arguments en ligne de commande.
Démarrage rapide : exécuter le Cluster Autoscaler avec un chart Helm
Prérequis du chart Helm Cluster Autoscaler
Avant d'installer le chart Cluster Autoscaler, assurez-vous d'utiliser Helm 3+ et Kubernetes 1.35.x ou une version ultérieure. Azure AKS requiert Kubernetes 1.10 ou une version ultérieure avec RBAC activé.
Le Cluster Autoscaler simule en interne le comportement du scheduler Kubernetes. Bien que d'autres versions de Kubernetes puissent fonctionner en remplaçant l'image de conteneur, des versions non alignées peuvent introduire des problèmes de planification subtils. Le chart actuel utilise la version v2 de l'API des charts Helm ; les versions de Helm antérieures à la 3 ne sont donc pas prises en charge.
Si vous migrez depuis une version 1.X de cluster-autoscaler-chart, désinstallez cette release avant d'installer cluster-autoscaler en version 9.0.0 ou ultérieure. Les anciennes releases 1.X du chart sont obsolètes.
Étape 1 : ajouter le dépôt Helm du Cluster Autoscaler
Le chart Cluster Autoscaler s'installe depuis le chemin autoscaler/cluster-autoscaler. Avant l'installation, vérifiez que le dépôt contenant ce chart est bien configuré dans votre environnement Helm.
Le chart ne crée pas de déploiement d'autoscaling fonctionnel avec ses seules valeurs par défaut. Lors de l'installation, vous devez configurer soit l'auto-discovery des groupes de nœuds, soit des groupes de nœuds statiques. Il est déconseillé de combiner les deux approches.
Avec l'auto-discovery, définissez autoDiscovery.clusterName ainsi que les valeurs spécifiques au fournisseur requises. Pour une configuration statique, définissez un ou plusieurs groupes via autoscalingGroups ou autoscalingGroupsnamePrefix.
Étape 2 : installer le Cluster Autoscaler avec Helm
Installez le chart avec helm install, en fournissant la configuration requise par votre fournisseur cloud. Pour les configurations stockées dans un fichier de valeurs, utilisez :
helm install my-release autoscaler/cluster-autoscaler -f myvalues.yaml
Vos valeurs doivent identifier les groupes de nœuds que l'autoscaler peut gérer. Vous pouvez configurer l'auto-discovery avec autoDiscovery.clusterName, ou définir explicitement les groupes ainsi que leurs tailles minimale et maximale.
Après l'installation, consultez les logs de l'autoscaler pour confirmer que sa boucle principale s'exécute. Si ce n'est pas le cas, inspectez le pod généré et vérifiez les arguments passés à la commande cluster-autoscaler.
Étape 3 : installer le Cluster Autoscaler sur AWS avec Helm
Sur AWS, le Cluster Autoscaler peut découvrir automatiquement les Auto Scaling Groups (ASG). Ajoutez à chaque ASG géré les clés de tag k8s.io/cluster-autoscaler/enabled et k8s.io/cluster-autoscaler/<CLUSTER NAME>. Seules les clés des tags sont prises en compte.
Installez ensuite le chart avec le nom du cluster et la région AWS :
helm install my-release autoscaler/cluster-autoscaler \
--set autoDiscovery.clusterName=<CLUSTER NAME> \
--set awsRegion=<YOUR AWS REGION>
Vous pouvez également fournir awsAccessKeyID et awsSecretAccessKey lors de l'installation. Pour Amazon EKS, une alternative consiste à associer le compte de service de l'autoscaler à un rôle IAM et à transmettre son ARN via l'annotation du compte de service.
Si vous ne souhaitez pas utiliser l'auto-discovery, spécifiez les ASG manuellement :
helm install my-release autoscaler/cluster-autoscaler \
--set "autoscalingGroups[0].name=your-asg-name" \
--set "autoscalingGroups[0].maxSize=10" \
--set "autoscalingGroups[0].minSize=1"
Le worker exécutant l'autoscaler doit disposer des permissions IAM requises pour inspecter et modifier les ressources AWS Auto Scaling concernées.
Contenu associé : consultez notre comparatif entre Karpenter et Cluster Autoscaler
Étape 4 : mettre à niveau le chart Helm du Cluster Autoscaler
Lors de la mise à niveau d'installations plus anciennes, tenez compte des changements de version du chart. À partir de la version 9.0.0, les releases utilisent le nom de chart cluster-autoscaler. Pour migrer depuis une release obsolète 1.X de cluster-autoscaler-chart, désinstallez d'abord l'installation 1.X existante, puis installez la version 9.0.0 ou ultérieure.
La version 9.1.0 modifie également la signification d'envFromConfigMap. Ce paramètre doit contenir le nom d'un ConfigMap référencé par envFrom. Les configurations qui dépendent de l'ancien comportement d'envFromConfigMap doivent renommer ce paramètre en extraEnvConfigMaps.
Pour référence, une release peut être supprimée avec :
helm uninstall my-release
Cette commande supprime les composants Kubernetes associés à cette release Helm. Avant de changer de version, passez en revue les valeurs de configuration susceptibles d'avoir évolué entre la version installée et la version cible du chart.
Bonnes pratiques pour le chart Helm du Cluster Autoscaler
Voici quelques pratiques importantes à garder à l'esprit lorsque vous travaillez avec le Cluster Autoscaler via des charts Helm.
1. Appliquer le right-sizing aux requests CPU et mémoire
Le right-sizing des requests CPU et mémoire de vos workloads est essentiel lorsque vous utilisez le Cluster Autoscaler. Si les requests sont trop élevées, le scheduler risque de sur-provisionner les nœuds, entraînant un gaspillage de ressources et des coûts accrus. À l'inverse, des requests trop basses exposent à de la contention de ressources et à une instabilité potentielle des applications.
Actions clés :
- Analysez l'utilisation historique des ressources et définissez les requests et limits en fonction des besoins réels plutôt que de valeurs par défaut ou d'estimations.
- Passez régulièrement en revue et ajustez ces paramètres à mesure que les workloads évoluent.
- Utilisez les outils de monitoring Kubernetes pour observer la consommation de ressources en temps réel et identifier les opportunités d'optimisation.
Des requests de ressources précises améliorent l'efficacité de l'autoscaler : de nouveaux nœuds ne sont ajoutés que lorsque c'est réellement nécessaire, et les ressources existantes sont exploitées efficacement.
2. Traiter le right-sizing des workloads et l'autoscaling des nœuds comme un seul système
Le right-sizing des workloads et l'autoscaling des nœuds ne doivent pas être gérés isolément. Les modifications des requests de ressources des applications influent directement sur la façon dont l'autoscaler fait évoluer le cluster. Si les workloads sont systématiquement sur-provisionnés, l'autoscaler ajoutera des nœuds inutilement, tandis qu'un sous-provisionnement peut entraîner des pods non planifiables et des performances dégradées. Coordonner ces processus aide à maintenir l'équilibre entre disponibilité des ressources et coûts.
Actions clés :
- Mettez en place des outils ou des politiques automatisés qui ajustent conjointement les requests des workloads et la taille des groupes de nœuds.
- Assurez une communication régulière entre les équipes de développement et d'exploitation afin que les décisions de scaling reflètent les besoins réels des applications.
En considérant le right-sizing et l'autoscaling comme interdépendants, vous obtenez une meilleure utilisation des ressources, une plus grande stabilité applicative et une meilleure maîtrise des coûts.
Contenu associé : consultez notre guide sur le Kubernetes Vertical Pod Autoscaler
3. Suivre l'utilisation des ressources en continu
Le monitoring continu de l'utilisation des ressources est essentiel pour maintenir une configuration d'autoscaling efficace. Les allocations de ressources statiques deviennent rapidement obsolètes à mesure que les besoins applicatifs évoluent, ce qui entraîne des inefficacités ou des problèmes de performance. L'analyse régulière des données d'utilisation vous permet d'ajuster en connaissance de cause les requests des workloads et les paramètres de l'autoscaler.
Actions clés :
- Utilisez les dashboards Kubernetes et les plateformes de monitoring pour suivre dans le temps l'utilisation du CPU, de la mémoire et des nœuds.
- Établissez un processus de revue périodique, par exemple des audits mensuels ou des alertes automatisées en cas de schémas d'utilisation anormaux.
- Réagissez rapidement aux variations de consommation des ressources pour éviter le sur-provisionnement et garantir un scaling approprié du cluster.
Cette revue continue favorise une approche proactive, réduit les coûts opérationnels et maintient un environnement réactif.
4. Concevoir les groupes de nœuds pour un bin packing efficace
Un bin packing efficace consiste à répartir les workloads sur les nœuds de manière à maximiser l'utilisation des ressources et à minimiser le gaspillage. Lors de la conception des groupes de nœuds, il est important de sélectionner des types et des tailles d'instances adaptés aux profils de vos workloads.
Actions clés :
- Évitez les nœuds trop grands ou trop petits, sources de fragmentation ou de sous-utilisation des ressources.
- Regroupez les workloads similaires pour favoriser des schémas d'utilisation plus prévisibles et simplifier la configuration de l'autoscaler.
- Ajustez la configuration des groupes de nœuds à mesure que vos applications évoluent.
- Surveillez la répartition des workloads et identifiez les opportunités de consolider ou de scinder des groupes de nœuds pour un meilleur packing.
Un bin packing efficace réduit le nombre total de nœuds nécessaires, optimise les performances de l'autoscaler et diminue les coûts d'infrastructure en tirant le meilleur parti des ressources disponibles.
5. S'assurer que le HPA et le Cluster Autoscaler fonctionnent de concert
L'Horizontal Pod Autoscaler (HPA) et le Cluster Autoscaler doivent être configurés pour fonctionner en harmonie afin de garantir un scaling optimal. Le HPA ajuste le nombre de pods en fonction des métriques des workloads, tandis que le Cluster Autoscaler gère les nœuds sous-jacents. Si le HPA fait croître le nombre de pods au-delà de la capacité disponible des nœuds, le Cluster Autoscaler doit pouvoir ajouter des nœuds suffisamment vite pour les accueillir. Des configurations mal alignées peuvent entraîner des échecs de planification de pods ou une allocation de ressources inutile.
Actions clés :
- Coordonnez les politiques et les seuils de scaling entre le HPA et le Cluster Autoscaler.
- Surveillez l'interaction entre les deux, en vous appuyant sur les métriques et les logs pour identifier les goulets d'étranglement ou les retards dans les actions de scaling.
- Ajustez les cibles du HPA et les paramètres du Cluster Autoscaler pour obtenir un scaling équilibré et réactif.
Faire fonctionner ces deux composants de concert réduit les interruptions, améliore la disponibilité des applications et favorise une utilisation efficace des ressources.
Maximisez l'efficacité du Cluster Autoscaler avec PerfectScale
Les autoscalers de nœuds comme le Cluster Autoscaler et Karpenter ajustent le nombre de nœuds à la hausse ou à la baisse selon la demande, améliorant la disponibilité du cluster et réduisant les coûts liés aux ressources inactives. Mais même un autoscaler bien configuré atteint ses limites lorsque les workloads sous-jacents sont mal configurés : des conteneurs sur-provisionnés gaspillent de la capacité et contraignent l'autoscaler à ajouter plus de nœuds que nécessaire, des conteneurs sous-provisionnés provoquent des évictions de pods et une pression sur les nœuds, et un bin packing inefficace laisse des ressources sous-utilisées tout en déclenchant des événements de scaling superflus. PerfectScale traite ces problèmes au niveau des workloads et des nœuds, afin que votre configuration d'autoscaling tienne réellement ses promesses en matière d'efficacité.
Principales capacités de PerfectScale pour l'autoscaling Kubernetes :
- Détection proactive des erreurs de configuration : analyse en continu les workloads pour identifier et corriger les erreurs de configuration telles que CPU Request Not Set, Memory Request Not Set et Memory Limit Not Set, évitant ainsi les évictions imprévisibles, la surallocation des nœuds et un autoscaling inefficace.
- Right-sizing autonome des workloads : ajuste instantanément les ressources des workloads en fonction de l'utilisation réelle et améliore le bin packing des pods pour renforcer l'efficacité de l'autoscaling, sans intervention manuelle.
- Visibilité sur les groupes d'autoscaling et les pools de nœuds : offre une visibilité sur les coûts et l'utilisation de vos groupes d'autoscaling et de vos pools de nœuds, afin de repérer précisément les inefficacités à l'échelle du cluster.
- Sélection optimale des types de nœuds : vous aide à choisir des types de nœuds qui améliorent l'utilisation, assurent une répartition précise des ressources et maximisent la rentabilité.
- Large compatibilité avec les autoscalers : fonctionne aux côtés de Karpenter, du Cluster Autoscaler et du Node Auto Provisioning, en combinant optimisation au niveau des nœuds et right-sizing au niveau des pods pour un meilleur bin packing et des décisions de scaling plus rapides.
Découvrez comment maximiser l'autoscaling de vos nœuds Kubernetes avec PerfectScale