Autoscaling des instances de conteneur

Dans Knative serving, chaque révision est automatiquement adaptée au nombre d'instances de conteneur nécessaires pour traiter toutes les requêtes entrantes. Lorsqu'une révision ne reçoit aucun trafic, un scaling à zéro instance de conteneur est effectué par défaut. Toutefois, si vous le souhaitez, vous pouvez modifier cette valeur par défaut pour spécifier qu'une instance doit rester inactive ou en attente à l'aide du paramètre nombre minimal d'instances.

Les facteurs suivants influent sur le nombre d'instances programmées :

Dans certains cas, vous voudrez peut-être limiter le nombre total d'instances de conteneur pouvant être démarrées, pour des raisons de contrôle des coûts ou pour une meilleure compatibilité avec d'autres ressources utilisées par votre service. C'est par exemple le cas si votre service Knative serving interagit avec une base de données qui ne peut gérer qu'un certain nombre de connexions ouvertes simultanément.

Nombre maximal d'instances de conteneur

Le nombre maximal d'instances de conteneur est un paramètre permettant de limiter le nombre total d'instances pouvant être démarrées en parallèle, comme indiqué sur la page Définir un nombre maximal d'instances de conteneur.

Dépassement du nombre maximal d'instances

En temps normal, votre révision effectue un scaling horizontal en créant des instances afin de gérer la charge de trafic entrant. Toutefois, lorsque vous définissez une limite maximale du nombre d'instances, le nombre d'instances sera dans certains cas insuffisant pour répondre à cette charge de trafic. Dans ce cas, les requêtes entrantes sont mises en file d'attente pendant une période maximale de 60 secondes. Pendant ce laps de temps, si une instance termine le traitement de requêtes, elle devient disponible pour traiter les requêtes en file d'attente. Si aucune instance ne devient disponible pendant ces 60 secondes, la requête échoue dans Cloud Run avec le code d'erreur 429.

Garanties relatives au scaling

Le nombre maximal d'instances constitue une limite supérieure. Si vous définissez une limite élevée, cela ne veut pas dire que votre révision effectuera un scaling horizontal de façon à atteindre le nombre d'instances de conteneur spécifié. Cela signifie simplement que le nombre d'instances de conteneur à tout moment ne doit pas dépasser la limite.

Pics de trafic

Dans certains cas (comme lors d'une augmentation soudaine du trafic), Knative serving peut créer, pendant une courte durée, un nombre d'instances de conteneur légèrement supérieur à la limite maximale spécifiée. Si votre service ne peut pas tolérer ce comportement temporaire, vous pouvez appliquer une marge de sécurité et définir une valeur maximale d'instances inférieure.

Déploiements

Lorsque vous déployez une nouvelle révision, Knative serving migre progressivement le trafic de l'ancienne révision vers la nouvelle. Comme le nombre maximal d'instances est défini pour chaque révision, vous pouvez temporairement dépasser la limite spécifiée pendant la période qui suit le déploiement.

Instances inactives et minimisation des démarrages à froid

Les ressources Kubernetes ne sont utilisées que lorsqu'une instance traite une requête, mais cela ne signifie pas que Knative serving arrête immédiatement les instances une fois que toutes les requêtes ont été traitées. Pour minimiser l'impact des démarrages à froid, Knative serving peut conserver certaines instances inactives. Ces instances sont prêtes à traiter les requêtes en cas d'augmentation soudaine du trafic.

Par exemple, lorsqu'une instance de conteneur a fini de traiter des requêtes, elle peut rester inactive pendant un certain temps au cas où une autre requête devrait être traitée. Une instance de conteneur inactive peut conserver des ressources, telles que des connexions de base de données ouvertes. Cependant, pour Cloud Run, le processeur ne sera pas disponible.

Pour vous assurer que les instances inactives restent disponibles de façon permanente, utilisez le paramètre min-instance.

Étape suivante