Autoscaler de cluster

Cette page explique comment redimensionner automatiquement les pools de nœuds du cluster Google Kubernetes Engine (GKE) en fonction des demandes de vos charges de travail. Lorsque la demande est élevée, l'autoscaler de cluster ajoute des nœuds au pool de nœuds. Lorsque la demande est faible, l'autoscaler de cluster redimensionne les pools à la taille minimale que vous avez définie. Cela permet d'augmenter la disponibilité de vos charges de travail lorsque vous en avez besoin, tout en contrôlant les coûts. Vous pouvez également configurer l'autoscaler de cluster sur un cluster.

Présentation

L'autoscaler de cluster de GKE redimensionne automatiquement le nombre de nœuds dans un pool de nœuds donné, en fonction des demandes de vos charges de travail. Vous n'avez pas besoin d'ajouter ou de supprimer manuellement des nœuds, ni de surprovisionner vos pools de nœuds. À la place, il suffit de spécifier une taille minimale et maximale pour le pool de nœuds, et le reste est automatique.

Si des ressources sont supprimées ou déplacées lors de l'autoscaling de votre cluster, vos charges de travail peuvent être temporairement interrompues. Par exemple, si votre charge de travail comprend un contrôleur avec une seule instance dupliquée, le pod de cette instance dupliquée peut être reprogrammé sur un nœud différent si son nœud actuel est supprimé. Avant d'activer l'autoscaler de cluster, concevez vos charges de travail de manière à tolérer des perturbations potentielles ou assurez-vous que les pods critiques ne sont pas interrompus.

Comment fonctionne l'autoscaler de cluster

L'autoscaler de cluster fonctionne par pool de nœuds. Lorsque vous configurez un pool de nœuds avec l'autoscaler de cluster, vous spécifiez une taille minimale et maximale pour le pool de nœuds.

L'autoscaler de cluster augmente ou diminue automatiquement la taille du pool de nœuds, en fonction des demandes de ressources (plutôt qu'en fonction de l'utilisation réelle des ressources) des pods exécutés sur les nœuds de ce pool de nœuds. Il vérifie régulièrement l'état des pods et des nœuds, et prend les mesures suivantes :

  • Si les pods ne peuvent pas être programmés, car il n'y a pas assez de nœuds dans le pool de nœuds, l'autoscaler de cluster en ajoute, jusqu'à atteindre la taille maximale du pool de nœuds.
  • Si les nœuds sont sous-utilisés et que tous les pods peuvent être programmés, même avec moins de nœuds dans le pool, l'autoscaler de cluster supprime des nœuds, jusqu'à atteindre la taille minimale du pool de nœuds. Si le nœud ne peut pas être drainé correctement après un délai d'inactivité (actuellement de 10 minutes), il est automatiquement arrêté. Le délai de grâce n'est pas configurable pour les clusters GKE.

Si vos pods ont demandé trop peu de ressources (ou n'ont pas changé les valeurs par défaut qui pourraient être insuffisantes) et si vos nœuds connaissent des manques, l'autoscaler de cluster ne corrigera pas la situation. Vous pouvez vous assurer que l'autoscaler de cluster fonctionne aussi précisément que possible en effectuant des demandes de ressources explicites pour toutes vos charges de travail.

Critères d'exploitation

L'autoscaler de cluster repose sur les hypothèses suivantes lors du redimensionnement d'un pool de nœuds :

  • Tous les pods répliqués peuvent être démarrés sur un autre nœud, provoquant éventuellement une brève interruption. Si vos services ne tolèrent pas les pannes, il est déconseillé d'utiliser l'autoscaler de cluster.
  • Les utilisateurs ou les administrateurs ne gèrent pas manuellement les nœuds. L'autoscaling peut remplacer les opérations de gestion manuelle des nœuds que vous effectuez.
  • Tous les nœuds d'un pool de nœuds unique ont le même ensemble de libellés.
  • L'autoscaler de cluster prend en compte le coût relatif des types d'instances dans les différents pools, et tente de développer le pool de nœuds le moins coûteux possible. Le coût réduit des pools de nœuds contenant des VM préemptives est pris en compte.
  • Les libellés ajoutés manuellement après la création initiale du cluster ou du pool de nœuds ne font l'objet d'aucun suivi. Les nœuds créés par l'autoscaler de cluster se voient attribuer des libellés spécifiés avec --node-labels au moment de la création du pool de nœuds.

Équilibrer les zones

Si votre pool de nœuds contient plusieurs groupes d'instances gérées avec le même type d'instance, l'autoscaler de cluster tente de conserver la taille de ces groupes d'instances gérées lors de l'autoscaling. Cela peut contribuer à éviter une répartition inégale des nœuds entre les groupes d'instances gérés dans plusieurs zones d'un pool de nœuds.

Pour plus d'informations sur la manière dont l'autoscaler de cluster prend des décisions d'équilibrage, reportez-vous à la section Questions fréquentes sur l'autoscaling de la documentation Kubernetes.

Taille minimale et maximale du pool de nœuds

Vous pouvez spécifier la taille minimale et maximale de chaque pool de nœuds de votre cluster. L'autoscaler de cluster prend des décisions de redimensionnement dans le cadre de ces limites. Si la taille du pool de nœuds actuel est inférieure au minimum spécifié ou supérieure au maximum spécifié lorsque vous activez l'autoscaling, l'autoscaler attend qu'un nouveau nœud soit requis dans le pool de nœuds ou qu'un nœud puisse être supprimé du pool en toute sécurité pour s'exécuter.

Limites de l'autoscaling

Lorsque vous procédez à l'autoscaling des clusters, les limites de scaling du pool de nœuds sont déterminées par la disponibilité de la zone.

Par exemple, la commande suivante crée un cluster d'autoscaling multizones doté de six nœuds répartis sur trois zones, avec un minimum d'un nœud par zone et un maximum de quatre nœuds par zone :

gcloud container clusters create example-cluster \
  --zone us-central1-a \
  --node-locations us-central1-a,us-central1-b,us-central1-f \
  --num-nodes 2 --enable-autoscaling --min-nodes 1 --max-nodes 4

La taille totale de ce cluster est comprise entre trois et douze nœuds, répartis sur trois zones. Si l'une des zones échoue, la taille totale du cluster est comprise entre deux et huit nœuds.

Profils d'autoscaling

La décision de supprimer un nœud représente un compromis entre l'optimisation de l'utilisation et la disponibilité des ressources. Supprimer les nœuds sous-exploités améliore l'utilisation des clusters, mais les nouvelles charges de travail peuvent se trouver contraintes d'attendre le provisionnement de nouvelles ressources avant de pouvoir s'exécuter.

Vous pouvez spécifier le profil d'autoscaling à utiliser pour prendre de telles décisions. Les profils actuellement disponibles sont les suivants :

  • balanced : profil par défaut.
  • optimize-utilization : donne la priorité à l'optimisation de l'utilisation plutôt qu'à la mise en réserve de ressources dans le cluster. Lorsque cette option est activée, l'autoscaler est plus agressif lors des scalings à la baisse du cluster : il peut supprimer des nœuds plus rapidement et en plus grand nombre. Ce profil est optimisé pour l'utilisation avec des charges de travail par lots, qui ne sont pas sensibles à la latence de démarrage. À l'heure actuelle, il n'est pas recommandé d'utiliser ce profil pour la diffusion de charges de travail.

La commande suivante active le profil d'autoscaling optimize-utilization dans un cluster existant :

gcloud beta container clusters update example-cluster \
--autoscaling-profile optimize-utilization

Prendre en compte la planification et l'interruption des pods

Lors de la réduction, l'autoscaler de cluster respecte les règles de planification et d'éviction définies sur les pods. Ces restrictions peuvent empêcher la suppression d'un nœud par l'autoscaler. La suppression d'un nœud peut être empêchée si ce nœud contient un pod remplissant l'une des conditions suivantes :

  • Les règles d'affinité ou d'anti-affinité du pod empêchent la replanification.
  • Le pod dispose d'un stockage en local.
  • Le pod n'est pas géré par un contrôleur tel que Deployment, StatefulSet, Job ou ReplicaSet.

L'attribut PodDisruptionBudget d'une application peut également empêcher l'autoscaling. Si la suppression de nœuds entraîne un dépassement du budget, le cluster ne se réduit pas.

Pour en savoir plus sur l'autoscaler de cluster et éviter les interruptions, consultez la section Questions fréquentes sur l'autoscaler de cluster :

Informations supplémentaires

Vous pouvez trouver plus d'informations sur l'autoscaler de cluster dans la section Questions fréquentes sur l'autoscaling du projet Kubernetes Open source.

Limites

L'autoscaler de cluster présente les limites suivantes :

  • Objets PersistentVolume locaux.
  • Scaling à la hausse d'un groupe de nœuds de taille 0, pour les pods demandant des ressources au-delà du processeur, de la mémoire et du GPU (par exemple, stockage éphémère).
  • L'autoscaler de cluster accepte jusqu'à 5 000 nœuds exécutant 30 pods chacun. Pour plus de détails sur les garanties d'évolutivité, reportez-vous au rapport sur l'évolutivité.
  • Lorsque vous êtes en phase de scaling à la baisse, l'autoscaler de cluster respecte un délai de grâce de 10 minutes afin de replanifier les pods du nœud sur un autre nœud avant de mettre fin au processus de manière forcée.
  • Parfois, l'autoscaler de cluster ne peut pas effectuer un scaling à la baisse complet et un nœud supplémentaire demeure après cette opération. Cela peut se produire lorsque les pods système requis sont planifiés sur différents nœuds, car aucun déclencheur ne permet de transférer l'un de ces pods vers un autre nœud. Reportez-vous à la page J'ai quelques nœuds avec une faible utilisation, mais ils ne sont pas réduits. Pourquoi ? Pour contourner cette limitation, vous pouvez configurer un budget d'interruption de pod.
  • La programmation personnalisée avec des filtres modifiés n'est pas acceptée.

Étapes suivantes