Autoscale Knative services based on the number of requests - Alibaba Cloud Service Mesh

Knative on ASM intègre le Knative Pod Autoscaler (KPA), une fonctionnalité prête à l'emploi qui met automatiquement à l'échelle les services selon le trafic de requêtes. Si votre service subit une instabilité des performances ou un gaspillage de ressources dus aux fluctuations du trafic, utilisez KPA pour automatiser sa mise à l'échelle. En surveillant et analysant les données de trafic en temps réel, KPA ajuste dynamiquement le nombre d'instances de service. Cette approche garantit la qualité de service lors des pics d'activité et économise les ressources pendant les périodes creuses, améliorant ainsi l'efficacité du système et réduisant les coûts.

Prérequis

Vous avez créé un service Knative dans Knative on ASM. Pour plus d'informations, consultez Déployer une application serverless à l'aide de Knative on ASM.

Remarque

Cette rubrique utilise le nom de domaine par défaut example.com à des fins de démonstration. Pour utiliser un nom de domaine personnalisé, consultez Utiliser un nom de domaine personnalisé dans Knative on ASM.

Fonctionnement de la mise à l'échelle automatique

Knative Serving injecte un conteneur Queue Proxy (queue-proxy) dans chaque pod. Ce conteneur transmet les métriques de concurrence du conteneur d'application à l'autoscaler. Celui-ci ajuste ensuite le nombre de pods du déploiement en fonction du nombre de requêtes simultanées et de l'algorithme de mise à l'échelle, permettant ainsi l'ajustement automatique de la capacité.

扩缩容

Concurrence et QPS

La concurrence correspond au nombre de requêtes simultanées traitées par un pod. Le QPS (requêtes par seconde) indique le nombre de requêtes traitées par un pod chaque seconde, représentant ainsi son débit maximal.

Sous forte charge, une concurrence élevée peut saturer le système. Cela accroît la consommation de CPU et de mémoire, ce qui risque de dégrader les performances, d'augmenter la latence des réponses et de faire chuter le QPS.

Algorithme

L'autoscaler de pods Knative (KPA) ajuste le nombre de pods selon la moyenne des requêtes simultanées par pod. Par défaut, Knative privilégie une mise à l'échelle basée sur la concurrence, avec une cible de 100 requêtes simultanées par pod. KPA se sert également d'un pourcentage d'utilisation cible pour déclencher la mise à l'échelle.

Pour la mise à l'échelle basée sur la concurrence, le calcul du nombre de pods est le suivant : desired pods = Total Concurrent Requests / (Target Concurrency * Target Utilization)

Par exemple, avec une concurrence cible de 10 et une utilisation cible de 0,7 (70 %), l'arrivée de 100 requêtes simultanées pousse l'autoscaler à passer à 15 pods (100 / (10 * 0,7) ≈ 15).

KPA alterne entre deux modes, Stable et Panic, pour s'adapter tant aux variations progressives qu'aux pics soudains de trafic.

Mode Stable

En mode Stable, KPA calcule la concurrence moyenne sur une fenêtre stable de 60 secondes et ajuste le nombre de pods en conséquence.
Mode Panic

Le mode Panic s'active lors d'une augmentation brutale du trafic. Il calcule la concurrence moyenne sur une fenêtre de panique beaucoup plus courte, fixée par défaut à 6 secondes. Cette fenêtre se calcule ainsi : stable window * panic-window-percentage. Le pourcentage de fenêtre de panique par défaut est de 10 % (0,1). Lorsque le trafic observé dépasse un seuil de panique, KPA augmente rapidement le nombre de pods pour répondre à la demande immédiate.

KPA choisit entre le calcul en mode Stable et celui en mode Panic selon le seuil de panique. Ce seuil se calcule comme suit : panic-threshold-percentage / 100. Le pourcentage de seuil de panique par défaut étant de 200, le seuil de panique par défaut s'élève à 2.

Si le nombre de pods souhaité calculé en mode Panic est au moins le double du nombre actuel de pods prêts, KPA applique le calcul du mode Panic. Sinon, il retient celui du mode Stable.

Configuration de KPA

La configuration globale de KPA réside dans la ConfigMap config-autoscaler, située dans le namespace knative-serving. Exécutez la commande suivante pour afficher la configuration par défaut. Les paramètres clés sont détaillés ci-dessous.

kubectl -n knative-serving get cm config-autoscaler -o yaml

Sortie attendue (les commentaires du code sont omis) :

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-autoscaler
  namespace: knative-serving
data:
  _example:
    container-concurrency-target-default: "100"
    container-concurrency-target-percentage: "0.7"
    enable-scale-to-zero: "true"
    max-scale-up-rate: "1000"
    max-scale-down-rate: "2"
    panic-window-percentage: "10"
    panic-threshold-percentage: "200"
    scale-to-zero-grace-period: "30s"
    scale-to-zero-pod-retention-period: "0s"
    stable-window: "60s"
    target-burst-capacity: "200"
    requests-per-second-target-default: "200"

Les paramètres sous le champ _example indiquent les valeurs par défaut. Pour modifier un paramètre, copiez-le du champ _example vers le champ data puis modifiez sa valeur.

Remarque

Les modifications apportées à la ConfigMap config-autoscaler s'appliquent globalement à tous les services Knative. Pour configurer un service Knative spécifique, utilisez des annotations. Pour plus d'informations, consultez Cas d'utilisation 1 : Définir une cible de concurrence pour la mise à l'échelle automatique et Cas d'utilisation 2 : Définir des limites de mise à l'échelle.

Configurer la mise à l'échelle à zéro

Paramètre	Description	Valeur d'exemple
scale-to-zero-grace-period	Durée d'exécution d'une Revision inactive avant sa mise à l'échelle à zéro. La valeur minimale est de 30 s.	30s
stable-window	En mode Stable, l'Autoscaler se base sur la concurrence moyenne au sein de la fenêtre stable. Vous pouvez aussi configurer la fenêtre stable via une annotation de Revision, par exemple `autoscaling.knative.dev/window: 60s`.	60s
enable-scale-to-zero	Définissez le champ sur `true`.	true

Configurer la concurrence de l'autoscaler

Paramètre	Description	Valeur d'exemple
container-concurrency-target-default	Définit le nombre souhaité de requêtes simultanées (une limite souple). Il s'agit de la configuration recommandée pour l'autoscaler dans Knative. La cible de concurrence par défaut dans la ConfigMap est de 100. De plus, la valeur de ce champ peut être modifiée avec l'annotation `autoscaling.knative.dev/target` dans la Revision, par exemple `autoscaling.knative.dev/target: 50`.	100
containerConcurrency	Limite le nombre de requêtes simultanées autorisées à un instant donné (une limite stricte) pour la Revision donnée. 1 : Garantit qu'une seule requête est traitée à la fois par une instance de conteneur. 2-N : Limite la concurrence à 2 requêtes ou plus. 0 : Aucune limite. Le système détermine la concurrence.	0
container-concurrency-target-percentage	Le pourcentage de concurrence, aussi appelé facteur de concurrence, sert à calculer la cible de concurrence effective pour la mise à l'échelle.Cible de concurrence effective = cible (ou containerConcurrency) * container-concurrency-target-percentage. Par exemple, si `target` ou `containerConcurrency` est défini sur `100` et que `container-concurrency-target-percentage` vaut `0.7`, une opération de mise à l'échelle horizontale se déclenche lorsque la concurrence réelle atteint 70 (100 × 0,7).	0.7

Configurer les limites de mise à l'échelle

Utilisez minScale et maxScale pour configurer le nombre minimum et maximum de pods pour votre application. Cela permet de maîtriser les démarrages à froid et les coûts de calcul.

Remarque

Si l'annotation minScale n'est pas définie, le service peut réduire son échelle jusqu'à zéro pod.
Si l'annotation maxScale n'est pas définie, aucune limite supérieure ne s'applique au nombre de pods créés.
Si vous définissez enable-scale-to-zero sur false dans la ConfigMap config-autoscaler, le service réduit sa capacité à un seul pod.

Configurez minScale et maxScale dans le modèle de Revision comme suit :

spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: "2"
        autoscaling.knative.dev/maxScale: "10"

Cas d'utilisation 1 : Définir une cible de concurrence

Ce cas d'utilisation illustre le déploiement d'une application autoscale-go dans un cluster et l'utilisation de KPA pour sa mise à l'échelle automatique via la définition d'une cible de concurrence.

Remarque

Pour plus d'informations sur la création d'un service Knative, consultez Déployer une application serverless à l'aide de Knative on ASM.

Créez le fichier autoscale-go.yaml et définissez la cible de concurrence sur 10, c'est-à-dire la valeur de autoscaling.knative.dev/target sur 10.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: autoscale-go
  namespace: default
spec:
  template:
    metadata:
      labels:
        app: autoscale-go
      annotations:
        autoscaling.knative.dev/target: "10"
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/autoscale-go:0.1

Connectez-vous à votre cluster avec kubectl et exécutez la commande suivante pour déployer l'application autoscale-go.
```
kubectl apply -f autoscale-go.yaml
```
Connectez-vous à la console ASM. Dans le volet de navigation de gauche, cliquez sur le nom de l'instance cible. Choisissez ASM Gateways > Ingress Gateway et récupérez l'adresse IP dans la section Service address.

Utilisez l'outil de test de charge Hey pour envoyer du trafic avec 50 requêtes simultanées pendant 30 secondes.

Pour savoir comment installer et utiliser l'outil Hey, consultez le dépôt officiel Hey.

Remarque

Remplacez xxx.xxx.xxx.xxx par l'adresse réelle de votre passerelle d'accès. Pour plus d'informations, consultez Obtenir l'adresse de la passerelle d'accès.

hey -z 30s -c 50   -host "autoscale-go.default.example.com"   "http://xxx.xxx.xxx.xxx?sleep=100&prime=10000&bloat=5"

(base) xxx .kube % kubectl get deploy -w
NAME                              READY   UP-TO-DATE   AVAILABLE   AGE
autoscale-go-00001-deployment     0/0     0            0           7m5s
autoscale-go-00001-deployment     0/1     0            0           7m17s
autoscale-go-00001-deployment     0/1     0            0           7m17s
autoscale-go-00001-deployment     0/1     0            0           7m17s
autoscale-go-00001-deployment     0/1     1            0           7m17s
autoscale-go-00001-deployment     0/7     1            0           7m18s
autoscale-go-00001-deployment     0/7     1            0           7m18s
autoscale-go-00001-deployment     0/7     1            0           7m18s
autoscale-go-00001-deployment     0/7     7            0           7m18s
autoscale-go-00001-deployment     1/7     7            1           7m19s
autoscale-go-00001-deployment     2/7     7            2           7m20s
autoscale-go-00001-deployment     3/7     7            3           7m20s
autoscale-go-00001-deployment     4/7     7            4           7m21s
autoscale-go-00001-deployment     5/7     7            5           7m23s
autoscale-go-00001-deployment     6/7     7            6           7m23s
autoscale-go-00001-deployment     7/7     7            7           7m23s
autoscale-go-00001-deployment     7/3     7            7           8m20s
autoscale-go-00001-deployment     7/3     7            7           8m20s
autoscale-go-00001-deployment     7/3     7            7           8m20s
autoscale-go-00001-deployment     3/3     3            3           8m20s
autoscale-go-00001-deployment     3/2     3            3           8m26s
autoscale-go-00001-deployment     3/2     3            3           8m26s
autoscale-go-00001-deployment     2/2     2            2           8m26s
autoscale-go-00001-deployment     2/1     2            2           8m36s
autoscale-go-00001-deployment     2/1     2            2           8m36s
autoscale-go-00001-deployment     1/1     1            1           8m36s
autoscale-go-00001-deployment     1/0     1            1           9m48s
autoscale-go-00001-deployment     1/0     1            1           9m48s
autoscale-go-00001-deployment     0/0     0            0           9m48s

La sortie indique que le service monte en puissance jusqu'à 7 pods. En effet, Knative crée proactivement davantage de pods lorsque la concurrence des conteneurs dépasse un certain pourcentage de la cible (70 % par défaut). Cela empêche le dépassement de la cible si la concurrence continue d'augmenter.

Cas d'utilisation 2 : Définir des limites de mise à l'échelle

Les limites de mise à l'échelle définissent le nombre minimum et maximum de pods pour une application. Ce cas d'utilisation montre comment déployer une application autoscale-go et la mettre à l'échelle automatiquement en définissant ces limites.

Remarque

Pour plus d'informations sur la création d'un service Knative, consultez Déployer une application serverless à l'aide de Knative on ASM.

Créez un fichier nommé autoscale-go.yaml. Définissez la cible de concurrence sur 10, le nombre minimal d'instances (minScale) sur 1 et le nombre maximal d'instances (maxScale) sur 3.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: autoscale-go
  namespace: default
spec:
  template:
    metadata:
      labels:
        app: autoscale-go
      annotations:
        autoscaling.knative.dev/target: "10"
        autoscaling.knative.dev/minScale: "1"
        autoscaling.knative.dev/maxScale: "3"
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/autoscale-go:0.1

Connectez-vous à votre cluster avec kubectl et exécutez la commande suivante pour déployer l'application autoscale-go.
```
kubectl apply -f autoscale-go.yaml
```
Connectez-vous à la console ASM. Dans le volet de navigation de gauche, cliquez sur le nom de l'instance cible. Choisissez ASM Gateways > Ingress Gateway et récupérez l'adresse IP dans la section Service address.

Utilisez l'outil de test de charge Hey pour envoyer du trafic avec 50 requêtes simultanées pendant 30 secondes.

Pour savoir comment installer et utiliser l'outil Hey, consultez le dépôt officiel Hey.

Remarque

Remplacez xxx.xxx.xxx.xxx par l'adresse réelle de votre passerelle d'accès. Pour plus d'informations, consultez Obtenir l'adresse de la passerelle d'accès.

hey -z 30s -c 50   -host "autoscale-go.default.example.com"   "http://xxx.xxx.xxx.xxx?sleep=100&prime=10000&bloat=5"

kubectl get deploy -w

Expected output:
text
NAME                              READY   UP-TO-DATE   AVAILABLE   AGE
autoscale-go-00001-deployment     1/1     1            1           115s
autoscale-go-00001-deployment     1/2     1            1           2m4s
autoscale-go-00001-deployment     1/2     1            1           2m4s
autoscale-go-00001-deployment     1/2     1            1           2m4s
autoscale-go-00001-deployment     1/2     2            1           2m4s
autoscale-go-00001-deployment     2/2     2            2           2m6s
autoscale-go-00001-deployment     2/3     2            2           2m6s
autoscale-go-00001-deployment     2/3     2            2           2m6s
autoscale-go-00001-deployment     2/3     2            2           2m6s
autoscale-go-00001-deployment     2/3     3            2           2m6s
autoscale-go-00001-deployment     3/3     3            3           2m8s
autoscale-go-00001-deployment     3/1     3            3           3m34s
autoscale-go-00001-deployment     3/1     3            3           3m34s
autoscale-go-00001-deployment     1/1     1            1           3m34s

La sortie montre que le service monte en puissance jusqu'à un maximum de 3 pods. En l'absence de trafic de requêtes, le service redescend à un minimum d'un pod. Cela confirme le bon fonctionnement de la mise à l'échelle automatique.

Documentation connexe

Pour accéder et gérer en toute sécurité les microservices construits avec Knative, vous pouvez utiliser une passerelle ASM pour activer l'accès HTTPS. Le chiffrement du trafic vers les endpoints de service protège la communication et améliore la sécurité et la fiabilité de votre architecture. Pour plus d'informations, consultez Accéder à un service Knative via HTTPS à l'aide d'une passerelle ASM.
Face aux défis de compatibilité et de stabilité lors des mises à niveau d'applications, vous pouvez effectuer un déploiement canari pour votre service Knative dans Knative on ASM. Pour plus d'informations, consultez Effectuer un déploiement canari pour un service Knative dans Knative on ASM.
Vous pouvez définir un seuil de métrique CPU pour un service Knative afin de mettre automatiquement à l'échelle les ressources en réponse à des pics soudains de charge. Pour plus d'informations, consultez Utiliser HPA dans Knative.