Container Service for Kubernetes:Activer la mise à l'échelle automatique pour absorber les fluctuations de trafic

Algorithme de mise à l'échelle

Le KPA calcule le nombre cible de pods à l'aide de la formule suivante :

Number of pods = Number of concurrent requests / (Pod maximum concurrency × Target utilization)

Exemple : Avec containerConcurrency défini sur 10 et une utilisation cible de 70 %, 100 requêtes simultanées produisent : 100 / (10 × 0,7) = 15 pods (arrondi supérieur).

Modes stable et panique

Le KPA utilise deux modes pour répondre aux variations de trafic :

Mode stable — mode par défaut. Le KPA fait la moyenne de la concurrence sur tous les pods pendant la fenêtre stable (par défaut : 60 s) et ajuste le nombre de pods en conséquence.

Mode panique — déclenché lors de pics de trafic. Le KPA utilise une fenêtre de panique plus courte (par défaut : 6 s ; stable window × panic-window-percentage) pour détecter les pics. Lorsque le nombre de pods en mode panique ≥ panic-threshold-percentage / 100 × pods prêts (par défaut : 2×), le KPA utilise le compte de panique au lieu du compte stable.

kubectl -n knative-serving describe cm config-autoscaler

Métrique de concurrence (par défaut)

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/metric: "concurrency"

Métrique RPS

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/metric: "rps"

Métrique CPU

La mise à l'échelle basée sur le CPU nécessite la classe d'autoscaler HPA.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/class: "hpa.autoscaling.knative.dev"
        autoscaling.knative.dev/metric: "cpu"

Métrique de mémoire

La mise à l'échelle basée sur la mémoire nécessite également la classe d'autoscaler HPA.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/class: "hpa.autoscaling.knative.dev"
        autoscaling.knative.dev/metric: "memory"

Cible de concurrence

Par révision — utilisez autoscaling.knative.dev/target :

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target: "50"

Globalement — mettez à jour la ConfigMap config-autoscaler :

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-autoscaler
  namespace: knative-serving
data:
  container-concurrency-target-default: "200"

Cible RPS

Par révision :

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target: "150"
        autoscaling.knative.dev/metric: "rps"
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56

Globalement :

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-autoscaler
  namespace: knative-serving
data:
  requests-per-second-target-default: "150"

Limite de concurrence souple

Une limite souple est la cible vers laquelle le KPA effectue la mise à l'échelle. Elle n'est pas strictement appliquée : les bursts peuvent la dépasser momentanément.

Par révision :

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target: "200"

Globalement :

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-autoscaler
  namespace: knative-serving
data:
  container-concurrency-target-default: "200"

Limite de concurrence stricte

Une limite stricte est appliquée rigoureusement : les requêtes excédentaires sont mises en tampon. Définissez une limite stricte uniquement lorsque votre application possède une limite supérieure ferme en matière de concurrence ; des valeurs faibles réduisent le débit et augmentent la latence.

Par révision — utilisez le champ de spécification containerConcurrency (et non une annotation) :

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    spec:
      containerConcurrency: 50

Utilisation cible

L'utilisation cible contrôle le niveau de remplissage des pods avant que le KPA n'effectue une montée en charge. À 70 % d'utilisation avec containerConcurrency: 10, le KPA crée un nouveau pod lorsque la concurrence moyenne sur les pods existants atteint 7. Des valeurs plus faibles incitent le KPA à effectuer une montée en charge plus tôt, réduisant ainsi la latence de démarrage à froid.

Par révision :

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target-utilization-percentage: "70"
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56

Globalement :

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-autoscaler
  namespace: knative-serving
data:
  container-concurrency-target-percentage: "70"

Activer ou désactiver la réduction à zéro globalement

Définissez enable-scale-to-zero sur "false" pour maintenir au moins un pod en cours d'exécution lorsqu'un service est inactif :

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-autoscaler
  namespace: knative-serving
data:
  enable-scale-to-zero: "false"

Configurer la période de grâce de réduction à zéro

scale-to-zero-grace-period limite la durée pendant laquelle la programmation réseau peut avoir lieu lors de la réduction à zéro.

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-autoscaler
  namespace: knative-serving
data:
  scale-to-zero-grace-period: "40s"

Configurer la période de rétention des pods

scale-to-zero-pod-retention-period conserve le dernier pod pendant une durée minimale après l'arrêt du trafic, évitant ainsi les démarrages à froid sur les services au trafic intermittent.

Par révision :

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/scale-to-zero-pod-retention-period: "1m5s"
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56

Globalement :

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-autoscaler
  namespace: knative-serving
data:
  scale-to-zero-pod-retention-period: "42s"

Exemple 1 : Mise à l'échelle par cible de concurrence

Déployez une application avec mise à l'échelle automatique avec une cible de concurrence de 10 et testez avec 50 requêtes simultanées.

1. Déployez Knative dans un cluster ACK ou un cluster ACK Serverless.

2. Créez autoscale-go.yaml avec le contenu suivant :

   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"  # Concurrency target: 10 requests per pod
       spec:
         containers:
           - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/autoscale-go:0.1

3. Appliquez le manifeste :

   kubectl apply -f autoscale-go.yaml

4. Obtenez l'adresse de la passerelle Ingress. ALB :

   kubectl get albconfig knative-internet

   Sortie attendue :

   NAME               ALBID                    DNSNAME                                              PORT&PROTOCOL   CERTID   AGE
   knative-internet   alb-hvd8nngl0lsdra15g0   alb-hvd8nng******.cn-beijing.alb.aliyuncs.com                            2

   MSE :

   kubectl -n knative-serving get ing stats-ingress

   Sortie attendue :

   NAME            CLASS                  HOSTS   ADDRESS                         PORTS   AGE
   stats-ingress   knative-ingressclass   *       101.201.XX.XX,192.168.XX.XX   80      15d

   ASM :

   kubectl get svc istio-ingressgateway --namespace istio-system --output jsonpath="{.status.loadBalancer.ingress[*]['ip']}"

   Sortie attendue :

   121.XX.XX.XX

   Kourier :

   kubectl -n knative-serving get svc kourier

   Sortie attendue :

   NAME      TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)                      AGE
   kourier   LoadBalancer   10.0.XX.XX    39.104.XX.XX     80:31133/TCP,443:32515/TCP   49m

5. Envoyez 50 requêtes simultanées pendant 30 secondes avec hey :

   hey -z 30s -c 50 \
     -host "autoscale-go.default.example.com" \
     "http://121.199.XXX.XXX"  # Replace with your Ingress gateway address

   Sortie attendue : le KPA ajoute 5 pods : 50 requêtes simultanées ÷ cible de 10 = 5 pods.

   

Exemple 2 : Mise à l'échelle avec limites

Ajoutez min-scale: 1 et max-scale: 3 pour maintenir un pod en cours d'exécution et limiter le déploiement à trois pods.

1. Déployez Knative dans un cluster ACK ou un cluster ACK Serverless.

2. Créez autoscale-go.yaml avec le contenu suivant :

   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/min-scale: "1"  # Keep at least 1 pod running
           autoscaling.knative.dev/max-scale: "3"  # Cap at 3 pods
       spec:
         containers:
           - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/autoscale-go:0.1

3. Appliquez le manifeste :

   kubectl apply -f autoscale-go.yaml

4. Obtenez l'adresse de la passerelle Ingress (Exemple 1, étape 4).

5. Envoyez 50 requêtes simultanées pendant 30 secondes :

   hey -z 30s -c 50 \
     -host "autoscale-go.default.example.com" \
     "http://121.199.XXX.XXX"  # Replace with your Ingress gateway address

   Sortie attendue : le KPA passe à 3 pods (maximum) pendant la charge, puis revient à 1 pod (minimum) — aucun démarrage à froid lors de la prochaine requête.