Autoscaling horizontal des pods

Cette page présente l'autoscaling horizontal des pods et explique son fonctionnement dans Google Kubernetes Engine (GKE). 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 de processeur ou de mémoire de la charge de travail, ou en fonction de métriques personnalisées signalées depuis Kubernetes ou de métriques externes provenant de sources en dehors de votre cluster.

L'autoscaling horizontal des pods ne modifie pas le nombre de nœuds dans un cluster GKE. Pour adapter automatiquement le nombre de nœuds du cluster en fonction des modifications du nombre de pods, vous pouvez utiliser l'autoscaler de cluster.

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. Ces exigences peuvent également évoluer au fil du temps 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 qu'il augmente automatiquement le nombre de pods lorsque la taille de la file d'attente atteint un seuil donné, et qu'il réduise 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 limites.

Fonctionnement de l'autoscaling horizontal des pods

Chaque autoscaler horizontal de pods configuré fonctionne à l'aide d'une boucle de contrôle. Un autoscaler de pods horizontaux distinct existe pour chaque charge de travail. 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 une valeur en pourcentage pour le processeur ou la mémoire, l'autoscaler horizontal de pods calcule la valeur d'utilisation moyenne en pourcentage des demandes de processeur ou de 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 moyenne ou brute d'une métrique signalée pour produire un ratio, et utilise ce ratio pour effectuer l'autoscaling de la charge de travail. Vous trouverez une description de l'algorithme d'autoscaling horizontal des 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 horizontal des pods é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 horizontal des pods é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 horizontal des pods choisit la plus grande recommandation basée sur une fenêtre de stabilisation spécifiée. Ce comportement est contrôlé par le champ scaleDown.stabilizationWindowSeconds dans la spécification behavior AHP, qui est défini par défaut sur 300 secondes (cinq minutes) dans GKE.

Pour éviter que de légères fluctuations ne provoquent des événements de scaling inutiles, l'autoscaler horizontal de pods utilise une valeur de tolérance de 10%. Pour une cible donnée, aucune action de scaling n'est effectuée si le ratio entre la valeur actuelle de la métrique et la valeur cible de la métrique est à moins de 10% de 1.

Scaling à zéro instance et inversement

Dans GKE 1.37 ou version ultérieure, vous pouvez configurer l'autoscaler horizontal des pods pour réduire une charge de travail à 0 répliques en l'absence de demande, puis la redimensionner automatiquement à la hausse lorsque la demande reprend. La mise à l'échelle vers et depuis zéro inclut les comportements suivants :

  • Contournement de la tolérance : lorsqu'une charge de travail comporte 0 réplicas, GKE contourne la vérification standard de la tolérance des métriques (ratio de 0,9 à 1,1). Toute valeur de métrique supérieure à zéro, comme un seul message dans une file d'attente, déclenche immédiatement un scale-up à au moins 1 réplicas sans attendre de dépasser un seuil de tolérance.
  • Périodes de stabilisation : le scaling à la hausse est défini par défaut sur 0 secondes (scaleUp.stabilizationWindowSeconds: 0) pour une activation immédiate, tandis que le scaling à la baisse est défini par défaut sur 300 secondes (scaleDown.stabilizationWindowSeconds: 300) pour garantir cinq minutes continues de demande nulle avant de passer à 0 instances répliquées.
  • Conditions d'état : lorsque le AHP met à l'échelle la charge de travail à 0 répliques, le contrôleur signale la condition ScaledToZero: True tout en restant actif (ScalingActive: True). Si une charge de travail est mise à l'échelle manuellement à 0 répliques en dehors du AHP (par exemple, avec la commande kubectl scale), l'autoscaling est mis en pause (ScalingActive: False) jusqu'à ce que la charge de travail soit remise à l'échelle à 1 répliques ou plus.

Pour obtenir des instructions détaillées, consultez Mettre à l'échelle les charges de travail GKE vers et depuis zéro à l'aide de HPA.

Limites

  • Sauf si vous utilisez le dimensionnement approprié de l'autoscaler horizontal de pods avec l'autoscaler vertical de pods (aperçu), n'utilisez pas l'autoscaler horizontal de pods conjointement avec l'autoscaler vertical de pods standard sur le processeur ou la mémoire. Vous pouvez utiliser l'autoscaler horizontal de pods avec l'autoscaler vertical de pods pour d'autres métriques, ou configurer l'autoscaling multidimensionnel des pods pour effectuer un scaling horizontal sur le processeur et un scaling vertical sur la mémoire en même temps.
  • Si vous avez un déploiement, ne configurez pas l'autoscaling horizontal des pods sur le ReplicaSet ou le contrôleur de réplication qui le prend en charge. 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 horizontal des pods 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.
  • L'autoscaling horizontal des pods expose les métriques en tant que ressources Kubernetes, ce qui impose des limites sur les noms de métriques, comme l'absence de majuscules ou de caractères "/". Votre adaptateur de métriques peut autoriser le renommage. Par exemple, consultez l'opérateur as prometheus-adapter.
  • L'autoscaler de pods horizontaux n'effectue pas de scaling à la baisse si l'une des métriques qu'il est configuré pour surveiller n'est pas disponible. Pour vérifier si vous avez des métriques indisponibles, consultez Afficher les détails d'un autoscaler horizontal de pods.

Évolutivité

Bien que l'autoscaler horizontal de pods n'ait pas de limite stricte sur le nombre d'objets AHP pris en charge, ses performances peuvent être affectées à mesure que ce nombre augmente. Plus précisément, la période entre les nouveaux calculs de AHP peut dépasser les 15 secondes standards.

  • Dans la version mineure 1.31 ou 1.32 de GKE, si le profil HPA de performances est configuré, la période entre les nouveaux calculs doit rester inférieure à 15 secondes avec un maximum de 1 000 AHP HPA. Découvrez comment configurer le profil HPA des performances.
  • Dans la version mineure de GKE 1.33 ou ultérieure, si le profil HPA de performances est configuré, la période entre les nouveaux calculs doit rester inférieure à 15 secondes avec un maximum de 5 000 AHP HPA. Le profil HPA de performances est activé par défaut sur tous les clusters qui répondent aux exigences.
  • Si le profil HPA de performances n'est pas configuré, la période entre les nouveaux calculs doit rester inférieure à 15 secondes avec un maximum de 300 AHP HPA.

Les facteurs suivants peuvent également affecter les performances :

  • Mise à l'échelle sur plusieurs métriques : 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.

Étapes suivantes