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/using-cluster-autoscaler.md.

Redimensionner dynamiquement un cluster avec l'autoscaler de cluster

Voir en Markdown

Découvrez comment activer et gérer l'autoscaler de cluster sur votre cluster OVHcloud Managed Kubernetes

Objectif

OVHcloud Managed Kubernetes Service vous fournit des clusters Kubernetes sans que vous ayez à vous soucier de leur installation ou de leur exploitation.

Au fil de la vie de votre cluster, vous pouvez vouloir ajuster dynamiquement sa taille pour l'adapter à vos workloads. L'autoscaler de cluster simplifie cette tâche en augmentant ou en réduisant la taille de votre cluster OVHcloud Managed Kubernetes pour répondre à la demande de vos workloads.

Ce guide explique comment activer et gérer l'autoscaler de cluster sur votre cluster OVHcloud Managed Kubernetes.

Prérequis

En pratique

L'autoscaler de cluster

Mise à l'échelle horizontale des pods et mise à l'échelle du cluster

L'une des caractéristiques des environnements cloud natifs est qu'ils doivent s'adapter automatiquement aux fluctuations de charge. Ces fluctuations peuvent, pour la plupart, être régulières, comme des cycles jour-nuit ou semaine-week-end, ou plus ponctuelles, comme une situation de type Black Friday. Un système cloud natif bien conçu doit monter et descendre en charge pour s'adapter aux fluctuations de charge sans intervention humaine.

Kubernetes dispose d'un ensemble de fonctionnalités puissantes pour s'adapter à des workloads changeants, la mise à l'échelle horizontale des pods.

Info

Le Horizontal Pod Autoscaler ajuste automatiquement le nombre de pods d'un replication controller, d'un déploiement, d'un replica set ou d'un stateful set en fonction de l'utilisation CPU observée (ou, avec la prise en charge de métriques personnalisées, en fonction d'autres métriques fournies par l'application).

Mais la mise à l'échelle horizontale des pods a une limite stricte : le nombre de nœuds disponibles dans votre cluster Kubernetes. Elle ne peut ajouter des pods à un Replica Set que s'il y a suffisamment de ressources disponibles sur vos nœuds Kubernetes, et elle ne peut pas réduire la taille de votre cluster si vos nœuds sont sous-utilisés.

Pour aller plus loin dans la scalabilité, vous avez besoin d'un autoscaler de cluster. Le Cluster autoscaler ajoute ou supprime des nœuds dans un cluster en fonction des ressources demandées par l'ensemble des pods, sans intervention humaine.

L'autoscaler de pods horizontal et l'autoscaler de cluster fonctionnent mieux lorsqu'ils sont déployés ensemble dans le cluster, car l'autoscaler de pods horizontal se concentre sur la gestion des pods pour leur permettre de répondre à la demande, tandis que l'autoscaler gère le nombre de nœuds du cluster pour s'assurer que l'autoscaler de pods horizontal puisse remplir son rôle.

L'autoscaler de cluster et l'autoscaler de pods horizontal peuvent fonctionner ensemble, et sont souvent tous les deux déployés dans un cluster. Lorsqu'ils sont combinés, l'autoscaler de pods horizontal se concentre sur l'exécution du nombre de pods requis pour répondre à la demande de l'application. L'autoscaler de cluster se concentre sur l'exécution du nombre de nœuds requis pour prendre en charge les pods planifiés.

Montée et descente en charge

Pour effectuer une montée en charge d'un cluster, l'autoscaler de cluster surveille la charge sur vos nœuds et détecte quand votre cluster subit des contraintes de ressources (par exemple, il ne peut pas planifier de nœuds en raison d'un manque de ressources). Lorsqu'une telle situation survient, l'autoscaler de cluster ajoute des nœuds à vos pools de nœuds pour répondre à la demande.

L'autoscaler de cluster fonctionne également dans l'autre sens, en surveillant les nœuds sous-utilisés et en réduisant leur nombre, ce qui contribue à réduire vos coûts.

Info

La montée en charge est conceptuellement plus simple que la descente en charge. Lorsque l'autoscaler détecte des contraintes de ressources, il lui suffit simplement d'ajouter un nœud supplémentaire (à condition de rester sous la limite de nœuds définie par l'utilisateur). Mais pour effectuer une descente en charge, même si la plupart des nœuds sont sous-utilisés, il doit déplacer tous les pods hors d'un des nœuds avant de le supprimer.

Certains éléments doivent être pris en compte, comme les pods utilisant des node selectors, l'anti-affinité, ou un PodDisruptionBudget (PDB) restrictif.

Pour plus d'informations sur ces facteurs qui perturbent la descente en charge du cluster, consultez la page What types of pods can prevent CA from removing a node?.

Pour effectuer la montée et la descente en charge du cluster, l'autoscaler utilise des paramètres définis par l'utilisateur, tels que des limites (quelles sont les limites minimale et maximale du nombre de nœuds de votre cluster ?), des seuils de ressources des nœuds (à quel niveau de charge faut-il ajouter ou supprimer un nœud ?) ou des intervalles de temps (à quelle fréquence le cluster doit-il être mis à l'échelle ?). Ces paramètres sont décrits dans le guide Configurer l'autoscaler de cluster.

Activer l'autoscaler

Utiliser l'API Kubernetes

La façon la 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).

Pool de nœuds

L'autoscale se configure au niveau d'un pool de nœuds, c'est-à-dire que vous n'activez pas l'autoscaling sur un cluster entier, 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

Pour éviter des dépenses imprévues, veillez à ne pas activer l'autoscaling sur des pools de nœuds facturés au mois. Vous êtes toutefois toujours autorisé à le faire si vous savez ce que vous faites.

Une configuration courante consiste à utiliser des pools de nœuds non-autoscalés, facturés au mois, comme base pour votre workload statique, et des pools de nœuds autoscalés, facturés à l'heure, avec des flavors plus petites pour votre workload dynamique.

Lorsque vous créez votre cluster, vous pouvez y amorcer un pool de nœuds par défaut, et vous pouvez en ajouter d'autres dans la section Public Cloud de l' ou directement en utilisant l'API Kubernetes.

Pour lister les pools de nœuds, vous pouvez utiliser :

kubectl get nodepools

Dans mon cas, j'ai un pool de nœuds dans mon cluster, appelé nodepool-b2-7, avec 3 nœuds B2-7 :

$ kubectl get nodepools
NAME            FLAVOR   AUTO SCALED   MONTHLY BILLED   ANTI AFFINITY   DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   [...]
nodepool-b2-7   b2-7     false         false            false           3         3         3            3           [...]

Comme vous pouvez le voir, le champ AUTO SCALED est défini sur false. Voyons pourquoi en consultant la description du pool de nœuds.

Vous pouvez ensuite obtenir la description du pool de nœuds au format YAML en utilisant :

kubectl get nodepools <your_nodepool_name> -o yaml

Pour mon cluster d'exemple :

$ kubectl get nodepools nodepool-b2-7 -o yaml
apiVersion: kube.cloud.ovh.com/v1alpha1
kind: NodePool
metadata:
    [...]
  name: nodepool-b2-7
  resourceVersion: "22315717368"
  selfLink: /apis/kube.cloud.ovh.com/v1alpha1/nodepools/nodepool-b2-7
  uid: de606632-3948-46c0-ba91-e34a6de6a1aa
spec:
  antiAffinity: false
  autoscale: false
  autoscaling:
    scaleDownUnneededTimeSeconds: 600
    scaleDownUnreadyTimeSeconds: 1200
    scaleDownUtilizationThreshold: "0.5"
  desiredNodes: 3
  flavor: b2-7
  maxNodes: 100
  minNodes: 0
  monthlyBilled: false
status:
  availableNodes: 3
  conditions:
    [...]
  currentNodes: 3
  observedGeneration: 2
  upToDateNodes: 3

Dans la section spec, vous pouvez voir que le paramètre autoscale est défini sur false. Pour activer l'autoscaler, vous devez patcher le pool de nœuds afin de définir ce champ sur true.

kubectl patch nodepool <your_nodepool_name> --type="merge" --patch='{"spec": {"autoscale": true}}'

Comme vous pouvez le voir dans mon exemple, le fait de patcher la définition du pool de nœuds active l'autoscaler :

$ kubectl patch nodepool nodepool-b2-7 --type="merge" --patch='{"spec": {"autoscale": true}}'
nodepool.kube.cloud.ovh.com/nodepool-b2-7 patched

$ kubectl get nodepools
NAME            FLAVOR   AUTO SCALED   MONTHLY BILLED   ANTI AFFINITY   DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   [...]
nodepool-b2-7   b2-7     true          false            false           3         3         3            3           [...]

Lorsque l'autoscaler est activé sur un pool de nœuds, il utilise une configuration par défaut. Pour mieux comprendre cette configuration par défaut et ses paramètres, consultez le guide Configurer l'autoscaler de cluster.

Configurer l'autoscaler

Utiliser l'API Kubernetes

Lorsque l'autoscaler est activé sur un pool de nœuds, il utilise une configuration par défaut.

Vous pouvez modifier plusieurs valeurs de paramètres via la commande kubectl :

kubectl patch nodepool <your_nodepool_name> --type="merge" --patch='{"spec": {"autoscaling": {"scaleDownUnneededTimeSeconds": <a_value>, "scaleDownUnreadyTimeSeconds": <another_value>, "scaleDownUtilizationThreshold": "<and_another_one>"}}}'

Dans mon exemple de cluster :

$ kubectl get nodepool nodepool-b2-7 -o json | jq .spec
{
  "antiAffinity": false,
  "autoscale": true,
  "autoscaling": {
    "scaleDownUnneededTimeSeconds": 600,
    "scaleDownUnreadyTimeSeconds": 1200,
    "scaleDownUtilizationThreshold": "0.5"
  },
  "desiredNodes": 3,
  "flavor": "b2-7",
  "maxNodes": 100,
  "minNodes": 0,
  "monthlyBilled": false
}
$ kubectl patch nodepool nodepool-b2-7 --type="merge" --patch='{"spec": {"autoscaling": {"scaleDownUnneededTimeSeconds": 900, "scaleDownUnreadyTimeSeconds": 1500, "scaleDownUtilizationThreshold": "0.7"}}}'
nodepool.kube.cloud.ovh.com/nodepool-b2-7 patched
$ kubectl get nodepool nodepool-b2-7 -o json | jq .spec
{
  "antiAffinity": false,
  "autoscale": true,
  "autoscaling": {
    "scaleDownUnneededTimeSeconds": 900,
    "scaleDownUnreadyTimeSeconds": 1500,
    "scaleDownUtilizationThreshold": "0.7"
  },
  "desiredNodes": 3,
  "flavor": "b2-7",
  "maxNodes": 100,
  "minNodes": 0,
  "monthlyBilled": false
}

Pour le moment, seuls les paramètres suivants sont modifiables :

  • autoscale
  • autoscaling
  • desiredNodes
  • minNodes
  • maxNodes

Si vous pensez que nous devrions prioriser la possible personnalisation d'autres paramètres d'autoscaling, n'hésitez pas à créer un ticket sur notre roadmap publique.

Aller plus loin

Pour avoir une vue d'ensemble d'OVHcloud Managed Kubernetes Service, vous pouvez consulter la page OVHcloud Managed Kubernetes.

Sinon, pour l'ignorer et en savoir plus sur l'utilisation pratique de votre cluster Kubernetes, nous vous invitons à consulter nos tutoriels.

  • Pour une formation ou une assistance technique sur la mise en œuvre de nos solutions, contactez votre commercial ou consultez la page Professional Services pour obtenir un devis et faire analyser votre projet par nos experts.

  • Échangez avec notre communauté d'utilisateurs.

Cette page vous a-t-elle aidé ?