Autoscaling horizontal des pods

Cette page présente l'autoscaling horizontal des pods et son fonctionnement. Vous pouvez également découvrir comment configurer et utiliser l'autoscaling horizontal des pods sur vos clusters.

L'autoscaler horizontal de pods modifie la forme de votre charge de travail Kubernetes en augmentant ou en diminuant automatiquement le nombre de pods en fonction de la consommation du processeur ou de la mémoire de la charge de travail, ou en fonction de métriques personnalisées figurant dans Kubernetes ou de métriques externes provenant de sources externes à votre cluster.

Les clusters GKE avec provisionnement automatique des nœuds évoluent automatiquement le nombre de nœuds du cluster en fonction des modifications du nombre de pods. Pour cette raison, nous vous recommandons d'utiliser l'autoscaling horizontal des pods pour tous les clusters.

Pourquoi utiliser l'autoscaling horizontal des pods

Lorsque vous déployez votre charge de travail pour la première fois sur un cluster Kubernetes, vous ne connaissez peut-être pas ses besoins en ressources et la façon dont ces besoins peuvent évoluer en fonction des modes d'utilisation, des dépendances externes ou d'autres facteurs. L'autoscaling horizontal des pods permet de s'assurer que votre charge de travail fonctionne de manière cohérente dans différentes situations et vous permet de contrôler les coûts en ne payant que la capacité supplémentaire dont vous avez besoin.

Il n'est pas toujours facile de prédire les indicateurs qui montrent si votre charge de travail manque de ressources ou si elle est sous-utilisée. L'autoscaler horizontal de pods peut adapter automatiquement le nombre de pods de votre charge de travail en fonction d'une ou de plusieurs métriques des types suivants :

  • Utilisation réelle des ressources : lorsque l'utilisation du processeur ou de la mémoire d'un pod donné dépasse un certain seuil. Cela peut être exprimé sous la forme d'une valeur brute ou d'un pourcentage du montant demandé par le pod pour cette ressource.

  • Métriques personnalisées : basées sur les métriques indiquées par un objet Kubernetes dans un cluster, telles que le taux de requêtes client par seconde ou les écritures d'E/S par seconde.

    Cela peut être utile si votre application est sujette aux goulots d'étranglement du réseau, et non au processeur ou à la mémoire.

  • Métriques externes : basées sur une métrique provenant d'une application ou d'un service externe à votre cluster.

    Par exemple, votre charge de travail peut nécessiter plus de capacité de processeur lors de l'ingestion d'un grand nombre de requêtes provenant d'un pipeline tel que Pub/Sub. Vous pouvez créer une métrique externe pour la taille de la file d'attente et configurer l'autoscaler horizontal de pods pour augmenter automatiquement le nombre de pods lorsque la file atteint un seuil donné, et réduire le nombre de pods lorsque la taille de la file d'attente diminue.

Vous pouvez combiner un autoscaler horizontal de pods avec un autoscaler vertical de pods, avec certaines limitations.

Fonctionnement de l'autoscaling horizontal des pods

Chaque autoscaler de pods horizontaux configuré utilise une boucle de contrôle. Un autoscaler de pods horizontaux existe pour chaque workflow. Chaque autoscaler de pods horizontaux vérifie régulièrement les métriques d'une charge de travail donnée par rapport aux seuils cibles que vous configurez, et modifie automatiquement la forme de la charge de travail.

Ressources par pod

Pour les ressources allouées par Pod, telles que le processeur, le contrôleur interroge l'API Metrics des ressources pour chaque conteneur exécuté dans le pod.

  • Si vous spécifiez une valeur brute pour le processeur ou la mémoire, cette valeur est utilisée.
  • Si vous spécifiez un pourcentage pour le processeur ou la mémoire, l'autoscaler de pods horizontaux calcule le pourcentage moyen d'utilisation des requêtes du processeur ou de la mémoire de ce pod.
  • Les métriques personnalisées et externes sont exprimées sous forme de valeurs brutes ou de valeurs moyennes.

Le contrôleur utilise la valeur brute ou moyenne d'une métrique donnée afin de produire un taux, et de l'utiliser pour réaliser l'autoscaling la charge de travail. Vous pouvez lire une description de l'algorithme de l'autoscaler horizontal de pods dans la documentation du projet Kubernetes.

Répondre à plusieurs métriques

Si vous configurez une charge de travail en fonction de plusieurs métriques, l'autoscaler de pods horizontaux évalue chaque métrique séparément et utilise l'algorithme de scaling pour déterminer la nouvelle taille de la charge de travail pour chacune d'elles. La plus grande taille est sélectionnée pour l'action d'autoscaling.

Si une ou plusieurs des métriques sont indisponibles pour une raison quelconque, l'autoscaler de pods horizontaux évolue toujours à la hausse en fonction de la plus grande taille calculée. Il n'effectue pas un scaling à la baisse.

Éviter le thrashing

Le thrashing (emballement) fait référence à une situation où l'autoscaler de pods horizontaux tente d'effectuer des actions d'autoscaling avant que la charge de travail ne finisse de répondre aux précédentes actions d'autoscaling. Pour éviter le thrashing, l'autoscaler de pods horizontaux choisit la plus grande recommandation basée sur les cinq dernières minutes.

Limites

  • N'utilisez pas l'autoscaler de pods horizontaux conjointement avec l'autoscaler de pods verticaux sur le processeur ou la mémoire. Vous pouvez utiliser l'autoscaler de pods horizontaux avec l'autoscaler de pods verticaux pour d'autres métriques.
  • Si vous effectuez un déploiement, ne configurez pas l'autoscaling des pods horizontaux sur ReplicaSet ou le contrôleur de réplication de sauvegarde. Lorsque vous effectuez une mise à jour progressive sur le contrôleur de déploiement ou de réplication, il est remplacé par un nouveau contrôleur de réplication. Configurez plutôt l'autoscaling de pods horizontaux sur le déploiement lui-même.
  • Vous ne pouvez pas utiliser l'autoscaling horizontal des pods pour les charges de travail qui ne peuvent pas être mises à l'échelle, telles que les DaemonSets.
  • Vous ne pouvez pas utiliser de métriques personnalisées ou externes avec l'autoscaling horizontal des pods pour réduire à zéro le nombre de pods puis effectuer un scaling à la hausse.

Évolutivité

L'autoscaler horizontal de pods n'a pas de limite stricte sur le nombre d'objets AHP pris en charge. Toutefois, au-delà d'un certain nombre d'objets AHP, la période entre les nouveaux calculs de l'AHP peut dépasser les 15 secondes standards.

  • Version mineure de GKE 1.21 ou antérieure : la période entre les nouveaux calculs doit rester inférieure à 15 secondes avec un maximum de 100 objets AHP.
  • Version mineure de GKE 1.22 ou ultérieure : la période entre les nouveaux calculs doit rester inférieure à 15 secondes avec un maximum de 300 objets AHP.

Les facteurs suivants peuvent également affecter les performances :

  • Nombre de métriques utilisées pour la mise à l'échelle : chaque métrique ajoute un appel de récupération pour les calculs de recommandations, ce qui affecte la période entre les nouveaux calculs.
  • Latence de la pile de métriques personnalisées : des temps de réponse supérieurs à 50 millisecondes sont supérieurs aux délais normalement observés avec les métriques Kubernetes standards, ce qui affecte la période entre les nouveaux calculs.

Interagir avec les objets HorizontalPodAutoscaler

Vous pouvez configurer un autoscaler horizontal de pods pour une charge de travail et obtenir des informations sur les événements d'autoscaling et leurs causes en consultant la page Charges de travail dans la console Google Cloud.

Chaque autoscaler de pods horizontaux existe dans le cluster en tant qu'objet HorizontalPodAutoscaler. Vous pouvez utiliser des commandes telles que kubectl get hpa ou kubectl describe hpa HPA_NAME pour interagir avec ces objets.

Vous pouvez également créer des objets HorizontalPodAutoscaler à l'aide de la commande kubectl autoscale.

Étape suivante