For AI agents: the complete documentation index is available at https://docs.ovhcloud.com/fr/llms.txt, the full documentation bundle is available at https://docs.ovhcloud.com/fr/llms-full.txt, and this page is available as Markdown at https://docs.ovhcloud.com/fr/guides/public-cloud/containers-orchestration/managed-kubernetes/cluster-autoscaler-example.md.
Découvrez à travers un exemple concret comment activer et tester le cluster autoscaler sur un pool de nœuds OVHcloud Managed Kubernetes.
Le service OVHcloud Managed Kubernetes vous fournit des clusters Kubernetes sans les contraintes liées à leur installation ou à leur exploitation.
Au cours de la vie quotidienne de votre cluster, vous pouvez souhaiter ajuster dynamiquement sa taille pour vous adapter à vos workloads. Le cluster autoscaler simplifie cette tâche en redimensionnant automatiquement votre cluster OVHcloud Managed Kubernetes à la hausse ou à la baisse, en fonction de la demande de vos workloads.
Avant de commencer
Ce tutoriel suppose que vous disposez déjà d'un cluster OVHcloud Managed Kubernetes fonctionnel et de connaissances de base sur son fonctionnement. Pour en savoir plus sur ces sujets, consultez le guide de démarrage rapide d'OVHcloud Managed Kubernetes Service.
Le moyen le plus simple d'activer l'autoscaler consiste à utiliser l'API Kubernetes, par exemple via kubectl.
Comme expliqué dans le guide Fonctionnement des nœuds et des pools de nœuds, dans votre cluster OVHcloud Managed Kubernetes, les nœuds sont regroupés en pools de nœuds (groupes de nœuds partageant la même configuration).
L'autoscaling se configure au niveau d'un pool de nœuds, c'est-à-dire que vous ne l'activez pas sur l'ensemble du cluster, mais sur un ou plusieurs de vos pools de nœuds.
Vous pouvez activer l'autoscaler sur plusieurs pools de nœuds, chacun pouvant avoir un type d'instance différent ainsi que des limites de nombre de nœuds minimum et maximum différentes.
Info
Afin d'éviter des dépenses inattendues, vous devez veiller à ne pas activer l'autoscaling sur des pools de nœuds facturés au mois. Vous êtes toutefois autorisé à le faire si vous savez ce que vous faites.
Une configuration courante consiste à utiliser des pools de nœuds non autoscalés et facturés au mois comme base pour votre workload statique, et des pools de nœuds autoscalés et facturés à l'heure, avec des flavors plus petites, pour votre workload dynamique.
Info
Le code source de l'exemple suivant est disponible dans le dépôt GitHub public public-cloud-examples
Lorsque vous créez votre cluster, vous pouvez y démarrer un pool de nœuds par défaut, et vous pouvez en ajouter d'autres dans la section Public Cloud de l' ou directement via l'API Kubernetes.
Déployer un workload de test
Supposons que vous avez créé un cluster MKS avec un pool de nœuds dont le minimum est fixé à 1 et le maximum à 3.
Pour tester l'autoscaler, nous vous proposons d'installer un déploiement Python heavy CPU load qui déploie plusieurs instances de pods Python CPU load. L'objectif du pod Python CPU load est de consommer tout le CPU qui lui est alloué. C'est une opération intensive en CPU, mais elle utilise une quantité minimale de mémoire.
Créez un manifeste cpu-load.yaml pour le déploiement python-cpu-load :
Comme vous pouvez le voir, nous allons commencer par déployer 3 réplicas du pod. Chaque réplica consomme 150m de CPU (0,150 CPU), et nous utilisons des instances D2-4, disposant de 2000m de CPU (2 cœurs CPU). Dans ce tutoriel, nous allons augmenter le nombre de réplicas à 12 puis à 24, afin d'observer comment l'autoscaler fait croître le pool de nœuds à 2 puis à 3 nœuds.
Comme vous pouvez le voir avec kubectl get nodepools, l'autoscaler détecte que la capacité est atteinte et demande un nouveau nœud :
$ kubectl get nodepoolsNAME FLAVOR AUTOSCALED MONTHLYBILLED ANTIAFFINITY DESIRED CURRENT UP-TO-DATE AVAILABLE MIN MAX nodepool-d2-4 d2-4 true false false 2 1 1 1 0 10
Et en quelques instants, le nouveau nœud est créé et actif, et tous les pods sont en cours d'exécution :
L'autoscaler détectera que les nœuds sont en dessous de la valeur du paramètre scale-down-utilization-threshold (le 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 considéré comme éligible à la réduction, 0,5 par défaut), et marquera les nœuds 2 et 3 comme inutiles.
Après quelques minutes, selon la valeur de scale-down-unneeded-time (paramètre qui définit la durée pendant laquelle un nœud doit être inutile avant d'être éligible à la réduction, 10 minutes par défaut), le nœud sera supprimé et le cluster sera réduit.
Après 10 minutes, nous revenons à 2 nœuds :
$ kubectl get nodepoolsNAME FLAVOR AUTOSCALED MONTHLYBILLED ANTIAFFINITY DESIRED CURRENT UP-TO-DATE AVAILABLE MIN MAXnodepool-d24 d2-4 true false false 2 2 2 2 1 10
Et 10 minutes plus tard, il ne reste qu'un seul nœud :
$ kubectl get nodepoolsNAME FLAVOR AUTOSCALED MONTHLYBILLED ANTIAFFINITY DESIRED CURRENT UP-TO-DATE AVAILABLE MIN MAXnodepool-d24 d2-4 true false false 1 1 1 1 1 10
Suppression (nettoyage)
Pour nettoyer votre cluster, supprimez simplement votre déploiement python-cpu-load :
Dans ce tutoriel, nous avons vu comment activer l'autoscaler sur un pool de nœuds de votre cluster OVHcloud Managed Kubernetes, et comment utiliser un workload d'exemple pour tester son fonctionnement.
Sinon, pour passer directement à l'utilisation pratique de votre cluster Kubernetes, nous vous invitons à consulter nos tutoriels.
Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en oeuvre de nos solutions, contactez votre commercial ou cliquez sur ce lien pour obtenir un devis et demander une analyse personnalisée de votre projet à nos experts de l’équipe Professional Services.
