Comprendre les décisions des autoscalers

---

L'autoscaling ajoute automatiquement des VM (scaling horizontal) ou en supprime (scaling vertical) de votre groupe d'instances géré (MIG). Ce document explique comment un autoscaler détermine à quel moment faire évoluer vos MIG.

Calcul de la taille recommandée et affectation de la taille cible par les autoscalers

Lorsque vous configurez un autoscaler pour un MIG, il surveille en permanence le groupe et définit sa taille recommandée sur le nombre d'instances de machines virtuelles (VM) requises pour absorber le pic de charge lors de la période de stabilisation.

La taille recommandée est limitée par le nombre minimal et maximal d'instances que vous définissez dans la règle d'autoscaling.

Si votre règle d'autoscaling inclut des contrôles d'évolutivité, la taille recommandée est davantage limitée par vos contrôles de scaling vertical.

Si vous activez l'autoscaling prédictif, l'autoscaler utilise les modèles historiques d'utilisation du processeur pour prévoir la charge future et définit la taille recommandée du groupe en fonction de sa prédiction.

La réponse du groupe d'instances géré à la taille recommandée par l'autoscaler dépend de la configuration du mode :

• ON. Le groupe d'instances géré définit sa taille cible sur la taille recommandée, puis Compute Engine augmente automatiquement la taille du groupe d'instances géré pour atteindre cette taille cible.
• ONLY_SCALE_OUT. La taille cible du groupe d'instances géré ne peut être augmentée qu'en réponse à une hausse de la taille recommandée.
• OFF. La taille cible n'est pas affectée par la taille recommandée. Toutefois, la taille recommandée est quand même calculée.

Si la configuration de l'autoscaler est supprimée, aucune taille recommandée n'est calculée.

Écarts entre les métriques d'utilisation cibles et réels

Lorsque vous utilisez une règle d'autoscaling avec des signaux basés sur les métriques, vous pouvez remarquer une différence importante entre l'utilisation réelle et l'utilisation cible des plus petits groupes d'instances. En effet, un autoscaler agit toujours prudemment en arrondissant à l'unité supérieure ou inférieure les données d'utilisation qu'il interprète pour déterminer le nombre d'instances à ajouter ou à supprimer. Ainsi, l'autoscaler ne peut pas ajouter un nombre insuffisant de ressources ou en supprimer trop.

Par exemple, si vous définissez un objectif d'utilisation de 0,7 et que votre application dépasse cet objectif, l'autoscaler peut déterminer qu'il faut ajouter 1,5 instance de machine virtuelle (VM) pour se rapprocher de l'objectif de 0,7. Étant donné qu'il n'est pas possible d'ajouter 1,5 instance de VM, l'autoscaler arrondit la valeur à l'unité supérieure et ajoute deux instances. Cela peut entraîner une diminution de l'utilisation moyenne du processeur à une valeur inférieure à 0,7, mais garantit que votre application dispose de suffisamment de ressources pour la prendre en charge.

De même, si l'autoscaler détermine que la suppression de 1,5 instances de machine virtuelle peut augmenter votre utilisation à près de 0,7, il ne supprime qu'une seule instance.

Pour les groupes plus importants qui disposent de plus d'instances de machines virtuelles, l'utilisation est répartie sur un plus grand nombre d'instances. L'ajout ou la suppression d'instances de machine virtuelle réduit l'écart entre l'utilisation réelle et l'utilisation cible.

Si vous utilisez l'autoscaling basé sur la planification avec un autre signal d'autoscaling, une planification active peut nécessiter plus de VM que nécessaire. Dans ces situations, votre utilisation réelle est inférieure à votre utilisation cible, car la planification d'autoscaling détermine la taille recommandée du groupe d'instances.

Groupes d'instances gérés régionaux et distribution inégale des VM

Si le nombre d'instances d'une région est déséquilibré entre les zones en raison d'une défaillance zonale ou d'une charge de travail inégalement répartie, l'autoscaling veille à ce que davantage d'instances s'exécutent dans les zones dont l'utilisation réelle est supérieure à la moyenne. Compute Engine prend cette mesure de précaution afin de garantir une haute disponibilité dans l'ensemble de la région ainsi que dans chaque zone individuelle, même si certaines des zones sont soumises à des charges plus importantes que d'autres.

Retards lors du scaling horizontal

Lorsque vous configurez l'autoscaling, vous spécifiez une période d'initialisation qui reflète la durée nécessaire à l'initialisation de vos VM. L'autoscaler ne recommande un scaling horizontal que si l'utilisation moyenne des instances qui ne se sont pas initialisées est supérieure à l'utilisation cible.

Si vous définissez une période d'initialisation nettement plus longue que le délai d'initialisation d'une instance, votre autoscaler risque d'ignorer les données d'utilisation légitimes et de sous-estimer la taille requise pour le groupe.

Retards lors du scaling vertical

Pour effectuer le scaling vertical, l'autoscaler calcule la taille cible recommandée du groupe en fonction de la charge maximale au cours des 10 dernières minutes ou de la période d'initialisation que vous avez définie, selon la durée la plus longue. Cette durée constitue ce que l'on appelle la "période de stabilisation".

L'observation de l'utilisation pendant la période de stabilisation permet à l'autoscaler d'effectuer les opérations suivantes :

• Vérifier que les informations d'utilisation recueillies à partir du groupe d'instances sont stables.
• Empêcher un comportement où un autoscaler ajoute ou supprime en permanence des instances à un rythme excessif.
• Supprimer les instances en toute sécurité en déterminant que la taille du groupe est suffisante pour supporter le pic de charge de la période de stabilisation.
• Si l'initialisation de votre application prend plus de 10 minutes sur une nouvelle VM, le groupe utilise la période d'initialisation comme période de stabilisation. Cela garantit que la suppression de la VM par l'autoscaler prend en compte le temps nécessaire à la restauration de la capacité de diffusion.

La période de stabilisation peut être perçue comme un retard de scaling vertical, mais il s'agit en fait d'une fonction d'autoscaling intégrée. La période de stabilisation garantit également que si une nouvelle instance est ajoutée au groupe d'instances géré, l'instance termine sa période d'initialisation ou s'exécute pendant au moins 10 minutes avant de pouvoir être supprimée.

Les périodes d'initialisation des nouvelles instances sont ignorées lors de la décision d'application d'un scaling vertical sur un groupe.

Retards engendrés par le drainage de connexion

Si le groupe fait partie d'un service de backend sur lequel le drainage de connexion est activé, le retrait ou la suppression de l'instance de VM peut prendre jusqu'à 60 secondes après la fin de la période de drainage.

Contrôles de scaling vertical

Lorsque vous configurez les contrôles de scaling vertical de l'autoscaler, vous contrôlez la vitesse du scaling vertical. L'autoscaler n'effectue jamais un scaling vertical plus vite que votre vitesse configurée :

1. Lorsque la charge diminue, l'autoscaler conserve la taille du groupe au niveau requis pour absorber le pic de charge enregistré (pendant la période de stabilisation). Le fonctionnement est le même avec et sans contrôles de scaling vertical.
2. Un autoscaler sans contrôles de scaling vertical ne conserve que le nombre suffisant d'instances nécessaires pour absorber la charge récemment observée. Après la période de stabilisation, l'autoscaler supprime toutes les instances inutiles en une seule étape. La baisse soudaine de la charge peut entraîner une réduction spectaculaire de la taille du groupe d'instances.
3. Un autoscaler avec des contrôles de scaling vertical limite le nombre d'instances de VM pouvant être supprimées pendant une période configurée (ici 10 VM en 20 minutes). Cela permet de ralentir le taux de réduction des instances.
4. Lors d'un nouveau pic de charge, l'autoscaler ajoute de nouvelles instances pour pouvoir gérer la charge. Cependant, en raison d'un long délai d'initialisation, les nouvelles VM ne sont pas prêtes à absorber la charge. Grâce aux contrôles de scaling vertical, la capacité précédente est conservée, ce qui permet aux VM existantes d'absorber le pic.

Vous pouvez contrôler le taux de scaling vertical en configurant la réduction maximale autorisée de l'autoscaler dans une fenêtre temporelle continue, en particulier :

• Réduction maximale autorisée (maxScaledInReplicas : nombre ou pourcentage d'instances de VM). Nombre d'instances que votre charge de travail peut se permettre de perdre (par rapport à la taille maximale du groupe) pendant la fenêtre temporelle continue spécifiée. Définissez ce paramètre pour contraindre le scaling vertical de votre groupe de façon à pouvoir continuer à absorber le pic de charge attendu jusqu'à ce que d'autres instances se joignent à la diffusion. Plus la réduction maximale autorisée est faible, plus le taux de scaling vertical est faible.
• Fenêtre temporelle continue (timeWindowSec : secondes). Durée pendant laquelle un pic de charge est susceptible de connaître une baisse temporaire et pendant laquelle vous ne souhaitez pas que le scaling vertical de la taille de votre groupe dépasse la réduction maximale autorisée. Utilisez ce paramètre pour définir la période pendant laquelle l'autoscaler recherchera la taille maximale suffisante pour absorber la charge historique. L'autoscaler ne réduit pas le nombre d'instances en dessous de la valeur de réduction maximale autorisée déduite de la taille maximale enregistrée au cours de la fenêtre temporelle continue. Avec une fenêtre temporelle plus longue, l'autoscaler prend en compte davantage de pics dans l'historique, de sorte que le scaling vertical s'effectue de manière plus prudente et plus stable.

Lorsque vous définissez des contrôles de scaling vertical, l'autoscaler limite les opérations de scaling vertical selon la réduction maximale autorisée et en fonction de la taille maximale observée dans la fenêtre temporelle continue. L'autoscaler procède comme suit :

1. Il surveille en permanence la taille maximale dans l'historique, constatée au cours de la fenêtre temporelle continue.
2. Il utilise la réduction maximale autorisée pour calculer la limite de taille du scaling vertical (taille maximale : maxScaledInReplicas)
3. Il définit la taille recommandée du groupe selon la limite de taille du scaling vertical. Par exemple, si un autoscaler redimensionne un groupe d'instances à 20 VM, mais que les contraintes de scaling vertical autorisent un scaling à 40 VM, la taille recommandée est définie sur 40 VM.

Avec les contrôles de scaling vertical, l'autoscaler surveille en permanence la taille maximale d'un groupe d'instances dans la fenêtre temporelle continue configurée, afin d'identifier la taille suffisante pour absorber la charge historique. L'autoscaler n'effectue pas de scaling vertical au-delà de la réduction maximale autorisée, mesurée à partir de la taille de pic constatée :

Par exemple, dans le schéma ci-dessus, les contrôles de scaling vertical sont configurés pour une réduction maximale autorisée de 20 VM dans une fenêtre temporelle continue d'une durée de 30 minutes :

1. Lorsque la charge diminue, l'autoscaler supprime 20 VM, ce qui correspond à la réduction maximale autorisée configurée dans les contrôles de scaling vertical.
2. Au fur et à mesure que la charge augmente et diminue, l'autoscaler surveille en permanence la fenêtre temporelle continue des 30 dernières minutes afin de déterminer la taille maximale suffisante pour absorber la charge historique. Cette taille maximale est utilisée comme base pour les contrôles de scaling vertical afin de limiter le taux de scaling vertical. Si, au cours des 30 dernières minutes, la taille maximale était de 70 VM et que la réduction maximale autorisée était définie sur 20 VM, l'autoscaler peut effectuer un scaling vertical pour revenir à 50 VM. Si la taille actuelle est de 65 VM, l'autoscaler ne peut supprimer que 15 VM.
3. À mesure que la charge diminue, l'autoscaler continue de supprimer les instances de VM, mais limite le taux de réduction à 20 VM au maximum, en fonction de la taille maximale du groupe d'instances mesurée au cours des 30 dernières minutes.

La réduction maximale autorisée de la taille du groupe peut avoir lieu en une seule fois. Vous devez donc configurer la réduction maximale autorisée de sorte que votre application puisse se permettre de perdre autant d'instances en une seule fois. Utilisez le paramètre de réduction maximale autorisée pour indiquer la réduction d'absorption de charge que votre application peut tolérer.

En limitant le nombre d'instances de VM que l'autoscaling peut supprimer et en augmentant la fenêtre temporelle continue constatée, les applications présentant des pics de charge et des temps d'initialisation longs devraient bénéficier d'une meilleure disponibilité. En particulier, la taille du groupe d'instances ne diminue pas brusquement en réponse à une baisse significative de la charge, mais diminue progressivement au fil du temps. Si des pics de charge se produisent peu après un scaling vertical, le nombre de VM restantes devrait pouvoir absorber le pic de charge en fonction de votre seuil de tolérance. De plus, une absorption suffisante du pic nécessite moins de VM.

Vous pouvez configurer des contrôles de scaling vertical pour l'autoscaling des MIG zonaux et régionaux. La configuration est la même dans les deux cas. Les contrôles de scaling vertical s'appliquent à n'importe quelle taille de groupe.

Comparaison des contrôles de scaling vertical et de la stabilisation de l'autoscaler

La configuration de contrôles de scaling vertical ne signifie pas que vous devez désactiver le mécanisme de stabilisation intégré à l'autoscaler. L'autoscaler maintient toujours la taille du groupe d'instances au niveau requis pour absorber le pic de charge, observé pendant la période de stabilisation. Les contrôles de scaling vertical fournissent un mécanisme supplémentaire pour contrôler le taux de redimensionnement d'un groupe d'instances.

	Autoscaler intégré : Période de stabilisation	Contrôles de scaling vertical : Fenêtre temporelle continue
Configurable ?	Non, non configurable	Oui, configurable
Quelles sont les métriques surveillées ?	Surveille les pics de charge des 10 dernières minutes ou de la période d'initialisation, selon la durée la plus longue.	Surveille la taille maximale du groupe d'instances au cours de la période précédente définie par la fenêtre temporelle continue.
En quoi est-ce utile ?	Vous permet de vous assurer que la taille du groupe d'instances reste suffisante pour absorber la charge maximale observée pendant les 10 dernières minutes ou la période d'initialisation, selon la durée la plus longue.	Veille à ce que la taille du groupe d'instances ne diminue pas en dessous du nombre d'instances de VM que votre charge de travail peut tolérer lors de la gestion des pics de charge sur une période donnée.

Contrôles de scaling vertical avec le mode de l'autoscaler

Lorsque votre MIG n'évolue pas automatiquement et que vous souhaitez activer l'autoscaling, il existe deux scénarios similaires, mais légèrement différents. Tout dépend si vous configurez l'autoscaling pour la première fois ou si l'autoscaling est configuré, mais temporairement limité ou désactivé.

Configurer l'autoscaler pour la première fois

Lorsque vous disposez d'un MIG sans autoscaling et que vous configurez entièrement l'autoscaling, l'autoscaler utilise la taille actuelle du MIG comme point de départ. Avant de procéder au scaling vertical, l'autoscaler utilise la période de stabilisation, puis des contrôles de scaling vertical pour limiter le taux de scaling vertical :

Modifier le mode de l'autoscaler

Le mode d'autoscaling vous permet de désactiver temporairement ou de restreindre les activités d'autoscaling. La configuration de l'autoscaler persiste et l'autoscaler continue à effectuer des calculs en arrière-plan, même lorsque l'autoscaler est désactivé ou restreint. L'autoscaler prend en compte les contrôles de scaling vertical dans ses calculs en arrière-plan en mode désactivé ou restreint. Toutes les activités d'autoscaling reprennent en se basant sur les calculs les plus récents, dès lors que vous réactivez l'autoscaling ou que vous levez la restriction :

1. L'autoscaler est activé comme d'habitude (avec des contrôles de scaling vertical dans ce cas).
2. Lorsque vous désactivez l'autoscaler, il calcule toujours la taille recommandée du groupe d'instances en fonction de la charge. Les calculs de l'autoscaler tiennent toujours compte des contrôles de scaling vertical. Toutefois, l'autoscaler n'applique pas de calculs de taille lorsque l'autoscaler est désactivé. La taille du groupe d'instances reste constante jusqu'à ce que l'autoscaler soit réactivé.
3. Lorsque vous l'activez à nouveau, il applique immédiatement la taille précédemment calculée. Cela permet un scaling plus rapide à la bonne taille. La réactivation de l'autoscaler peut entraîner un scaling vertical soudain et significatif (dans le cas présent, passage de 80 à 40 instances de VM). Cette méthode est sûre, car les calculs en arrière-plan tiennent déjà compte des contrôles de scaling vertical.

Autoscaling prédictif

Pour en savoir plus sur l'autoscaling prédictif, y compris son fonctionnement, consultez la page Effectuer un scaling basé sur des prédictions.

Préparer l'arrêt des instances

Lorsque l'autoscaler effectue un scaling vertical, il détermine le nombre d'instances de VM à supprimer. L'autoscaler hiérarchise les instances de VM à supprimer en fonction de plusieurs facteurs, dont les suivants :

• VM qui ne s'exécutent pas pour une raison quelconque.
• VM en cours ou planifiées pour effectuer des modifications perturbatrices (par exemple, actualisation, redémarrage ou remplacement).
• VM qui ne sont pas encore mises à jour vers la version prévue du modèle d'instance.
• VM présentant le signal d'autoscaling le plus faible. Par exemple, si vous configurez votre MIG pour qu'il effectue un scaling en fonction de l'utilisation du processeur et que le groupe doit effectuer un scaling vertical, l'autoscaler tente de supprimer les VM qui présentent le niveau d'utilisation du processeur le plus faible.

Avant d'arrêter des instances, vous souhaitez peut-être vous assurer qu'elles effectuent certaines tâches, telles que la fermeture de toutes les connexions existantes, l'arrêt optimal des applications ou des serveurs d'applications, l'importation des journaux, etc. Vous pouvez demander à votre instance d'effectuer ces tâches à l'aide d'un script d'arrêt. Un script d'arrêt s'exécute de la façon la plus optimale possible dans un bref délai entre le moment où la requête d'arrêt est effectuée et le moment où l'instance est réellement arrêtée. Au cours de cette période, Compute Engine tente d'exécuter votre script d'arrêt pour effectuer toutes les tâches que vous fournissez dans le script.

Ceci est particulièrement utile si vous utilisez l'équilibrage de charge avec votre groupe d'instances géré. Si votre instance est défectueuse, l'équilibreur de charge peut mettre un certain temps à reconnaître que l'instance est en panne. Il continue donc à envoyer de nouvelles requêtes à l'instance. Grâce à un script d'arrêt, l'instance peut signaler qu'elle est défectueuse lors de sa fermeture afin que l'équilibreur de charge puisse cesser de lui envoyer du trafic. Pour en savoir plus sur les vérifications de l'état de l'équilibrage de charge, consultez la section Présentation des vérifications d'état.

Pour plus d'informations sur les scripts d'arrêt, consultez la section Scripts d'arrêt.

Pour en savoir plus sur l'arrêt des instances, consultez la documentation sur l'arrêt ou la suppression d'une instance.

Surveiller les graphiques et les journaux d'autoscaling

Compute Engine fournit plusieurs graphiques et journaux vous permettant de surveiller le comportement de votre groupe d'instances géré à tout moment.

Vous pouvez accéder aux graphiques et aux journaux dans la console Google Cloud.

1. Dans Google Cloud Console, accédez à la page Groupes d'instances.

   Accéder à la page "Groupes d'instances"

2. Cliquez sur le nom du groupe d'instances géré que vous souhaitez afficher.
3. Sur la page "Groupe d'instances géré", sélectionnez l'onglet Surveillance.

Les graphiques de surveillance affichent l'évolution des métriques suivantes :

• Taille du groupe
• Utilisation de l'autoscaler
• Utilisation du processeur
• E/S du disque (octets)
• E/S du disque (opérations)
• Octets réseau
• Paquets réseau

Une info-bulle à côté du titre de chaque graphique fournit des informations contextuelles supplémentaires concernant la métrique affichée.

Un panneau Journaux est disponible en bas de la page, où vous trouverez une liste des journaux d'événements pour votre groupe d'instances géré. Pour afficher les journaux, cliquez sur la flèche de développement.

Tous les graphiques et journaux sont associés à une période unique que vous pouvez personnaliser à l'aide du sélecteur de période. En cliquant sur un graphique et en le faisant glisser, vous pouvez effectuer un zoom avant sur un événement spécifique, et analyser les graphiques et les journaux sur la période sélectionnée.

Surveiller l'autoscaling prédictif

Compute Engine fournit un graphique permettant de surveiller les prédictions de l'autoscaler. Pour afficher ce graphique, cliquez sur le titre Group size (Taille du groupe) dans le premier graphique, puis sélectionnez Predictive autoscaling (Autoscaling prédictif).

Si l'autoscaling est activé, vous pouvez voir comment les prédictions de l'autoscaler déterminent la taille de votre groupe d'instances. Si l'autoscaling n'est pas activé, vous pouvez toujours consulter les prédictions de l'autoscaler et vous en servir pour prendre des décisions concernant la taille de votre groupe.

Utilisez les informations suivantes pour comprendre ce graphique.

• La ligne bleue indique le nombre d'instances du groupe d'instances géré.
• La ligne verte indique le nombre d'instances prédites par l'autoscaler.
  • Si la ligne verte se situe en dessous de la ligne bleue, cela signifie que vous disposez d'une capacité importante et que vos instances de VM sont probablement sous-exploitées.
  • Si la ligne verte se situe au-dessus de la ligne bleue, la capacité restante est faible, voire inexistante, et vous devez ajouter davantage d'instances au groupe.
• Les lignes horizontales en pointillés indiquent le nombre minimal et maximal d'instances autorisées dans votre groupe d'instances.

Afficher les messages d'état

Lorsque l'autoscaler rencontre un problème de scaling, il renvoie un message d'avertissement ou d'erreur. Vous pouvez passer en revue ces messages d'état de deux manières différentes.

Afficher les messages d'état sur la page "Groupes d'instances"

Vous pouvez afficher les messages d'état directement sur la page Groupes d'instances de Google Cloud Console.

1. Dans Google Cloud Console, accédez à la page Groupes d'instances.

   Accéder à la page "Groupes d'instances"

2. Recherchez tous les groupes d'instances comportant une icône d'avertissement avant leur nom.

   Par exemple :

   

3. Maintenez le pointeur de la souris sur une icône d'état pour obtenir des détails sur le message d'état.

Afficher les messages d'état sur la page de présentation du groupe d'instances

Vous pouvez accéder directement à la page de présentation d'un groupe d'instances spécifique pour afficher les messages d'état pertinents.

1. Dans Google Cloud Console, accédez à la page Groupes d'instances.

   Accéder à la page "Groupes d'instances"

2. Cliquez sur le groupe d'instances pour lequel vous souhaitez afficher les messages d'état.
3. Sur la page du groupe d'instances, affichez le message d'état sous le nom du groupe d'instances.

Messages d'état fréquemment affichés

Lorsque l'autoscaler rencontre un problème de scaling, il renvoie un message d'avertissement ou d'erreur. Voici quelques messages fréquemment affichés et leur signification.

All instances in the instance group are unhealthy (not in RUNNING state). If this is an error, check the instances.

Toutes les instances du groupe d'instances ont un état autre que RUNNING. Si cela est intentionnel, vous pouvez ignorer ce message. Dans le cas contraire, vous devez résoudre le problème du groupe d'instances.

The number of instances has reached the maxNumReplicas. The autoscaler cannot add more instances.

Lors de la création de l'autoscaler, vous avez indiqué le nombre maximal d'instances que le groupe peut compter. L'autoscaler tente actuellement d'effectuer un scaling horizontal du groupe d'instances pour répondre à la demande, mais il a atteint la valeur maxNumReplicas. Pour plus d'informations sur la mise à jour de maxNumReplicas sur une valeur plus élevée, consultez la section Mettre à jour un autoscaler.

The monitoring metric that was specified does not exist or does not have the required labels. Check the metric.

Vous procédez à un autoscaling à l'aide d'une métrique Cloud Monitoring, mais la métrique que vous avez fournie n'existe pas, ne possède pas les libellés nécessaires ou n'est pas accessible à l'agent de service de Compute Engine.

• Des libellés différents sont requis en fonction de la nature de la métrique (standard ou personnalisée). Pour plus d'informations, consultez la documentation relative au Scaling basé sur une métrique Monitoring .

• Vérifiez que l'agent de service de Compute Engine dispose du rôle IAM compute.serviceAgent. Pour l'ajouter, consultez la section Conditions préalables pour l'autoscaler.

Quota for some resources is exceeded. Increase the quota or delete resources to free up more quota.

Vous pouvez obtenir des informations sur votre quota disponible sur la page Quotas de Google Cloud Console.

Autoscaling does not work with an HTTP/S load balancer configured for maxRate.

Le groupe d'instances est soumis à un équilibrage de charge à l'aide de la configuration maxRate, mais l'autoscaler ne prend pas en charge ce mode. Modifiez la configuration ou désactivez l'autoscaling. Pour en savoir plus sur maxRate, consultez les restrictions et directives dans la documentation sur l'équilibrage de charge.

The autoscaler is configured to scale based on a load balancing signal but the instance group has not received any queries from the load balancer. Check that the load balancing configuration is working.

Le groupe d'instances est soumis à un équilibrage de charge, mais ne reçoit aucune requête. Le service rencontre peut-être une période d'inactivité, auquel cas il n'y a rien à craindre. Toutefois, ce message peut aussi être causé par une mauvaise configuration. Par exemple, un groupe d'instances avec autoscaling peut être la cible de plusieurs équilibreurs de charge, ce qui n'est pas accepté. Pour obtenir la liste complète des consignes, consultez les restrictions et directives dans la documentation sur l'équilibrage de charge.