Container Service for Kubernetes:Scale multiple applications with NGINX Ingress traffic metrics

Prérequis

Assurez-vous que :

• Alibaba Cloud Prometheus est déployé dans votre cluster.

• Le module complémentaire ack-alibaba-cloud-metrics-adapter est déployé avec prometheus.url configuré.

  Comment configurer prometheus.url

  1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.

  2. Sur la page Clusters, localisez le cluster souhaité et cliquez sur son nom. Dans le volet de gauche, choisissez Applications > Helm.

  3. Sur la page Helm, recherchez ack-alibaba-cloud-metrics-adapter et cliquez sur Update dans la colonne Actions.

  4. Dans le panneau Update Release, définissez alibabaCloudMetricsAdapter.prometheus.url sur l’URL de requête de données de votre Prometheus, puis cliquez sur OK.

  Consultez Comment récupérer l’URL de requête de données Prometheus et Référence de configuration ack-alibaba-cloud-metrics-adapter .

• Apache Benchmark (ab) est installé.

  Exemples de commandes

  Installez ab avec le gestionnaire de packages de votre système d’exploitation :

  • macOS (Homebrew) : bash brew install httpd

  • Windows : Téléchargez la version Windows depuis Apache Lounge. Extrayez l’archive, accédez au dossier bin et exécutez ab.exe.

  • Ubuntu ou Debian : shell sudo apt update sudo apt install apache2-utils

  • CentOS 8 ou RHEL : shell sudo yum install httpd-tools

  Vérifiez l’installation :

  ab -V

Fonctionnement

Un Ingress transfère les requêtes externes vers un Service, qui les achemine vers le pod correspondant. Le contrôleur d’entrée NGINX enregistre le nombre de requêtes par service dans la métrique Prometheus nginx_ingress_controller_requests.

Le HPA ne peut pas consommer directement les métriques Prometheus ; il nécessite des métriques exposées via l’API de métriques externes de Kubernetes. L’adaptateur ack-alibaba-cloud-metrics-adapter comble cette lacune en traitant nginx_ingress_controller_requests en quatre étapes :

L’adaptateur remplit ces variables de modèle metricsQuery au moment de la requête :

• <<.Series>> — remplacé par le nom de la série Prometheus correspondante (nginx_ingress_controller_requests)

• <<.LabelMatchers>> — remplacé par les sélecteurs d’étiquettes issus de la spécification HPA (par exemple, service="sample-app")

Chaque HPA utilise selector.matchLabels.service pour filtrer cette métrique sur une seule application, garantissant ainsi que la mise à l’échelle de sample-app et de test-app reste indépendante.

Étape 1 : Créer les applications et les services

Créez deux déploiements et leurs services correspondants.

1. Créez nginx1.yaml avec le contenu suivant :

   Exemple YAML

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: test-app
     namespace: default
     labels:
       app: test-app
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: test-app
     template:
       metadata:
         labels:
           app: test-app
       spec:
         containers:
         - image: registry-cn-hangzhou.ack.aliyuncs.com/acs/sample-app:v1-b070784-aliyun
           name: metrics-provider
           ports:
           - name: http
             containerPort: 8080
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: test-app
     namespace: default
     labels:
       app: test-app
   spec:
     ports:
       - port: 8080
         name: http
         protocol: TCP
         targetPort: 8080
     selector:
       app: test-app
     type: ClusterIP

   Appliquez le manifeste :

   kubectl apply -f nginx1.yaml

2. Créez nginx2.yaml avec le contenu suivant :

   Exemple YAML

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: sample-app
     namespace: default
     labels:
       app: sample-app
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: sample-app
     template:
       metadata:
         labels:
           app: sample-app
       spec:
         containers:
         - image: registry-cn-hangzhou.ack.aliyuncs.com/acs/sample-app:v1-b070784-aliyun
           name: metrics-provider
           ports:
           - name: http
             containerPort: 8080
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: sample-app
     namespace: default
     labels:
       app: sample-app
   spec:
     ports:
       - port: 80
         name: http
         protocol: TCP
         targetPort: 8080
     selector:
       app: sample-app
     type: ClusterIP

   Appliquez le manifeste :

   kubectl apply -f nginx2.yaml

Étape 2 : Créer un Ingress

1. Créez ingress.yaml avec le contenu suivant :

   Champ	Description
   host	Nom de domaine pour l’accès au service. Défini sur test.example.com dans cet exemple.
   path	Chemin URL. Les requêtes correspondant à ce chemin sont acheminées vers le service correspondant.
   backend	Nom et port du service cible pour chaque chemin. / est acheminé vers sample-app ; /home est acheminé vers test-app.

   Exemple YAML

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: test-ingress
     namespace: default
   spec:
     ingressClassName: nginx
     rules:
       - host: test.example.com
         http:
           paths:
             - backend:
                 service:
                   name: sample-app
                   port:
                     number: 80
               path: /
               pathType: ImplementationSpecific
             - backend:
                 service:
                   name: test-app
                   port:
                     number: 8080
               path: /home
               pathType: ImplementationSpecific

   Appliquez le manifeste :

   kubectl apply -f ingress.yaml

2. Vérifiez que l’Ingress est en cours d’exécution :

   kubectl get ingress -o wide

   Sortie attendue :

   NAME           CLASS   HOSTS              ADDRESS       PORTS   AGE
   test-ingress   nginx   test.example.com   10.XX.XX.10   80      55s

   Le contrôleur d’entrée NGINX achemine test.example.com/ vers sample-app et test.example.com/home vers test-app. Les deux flux de requêtes sont enregistrés dans la métrique Prometheus nginx_ingress_controller_requests, étiquetés par nom de service.

Étape 3 : Convertir les métriques Prometheus en métriques compatibles avec le HPA

Le HPA lit les métriques à partir de l’API de métriques externes de Kubernetes, et non directement depuis Prometheus. L’adaptateur ack-alibaba-cloud-metrics-adapter traduit les métriques Prometheus dans ce format via des règles définies dans la ConfigMap adapter-config.

kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/*/nginx_ingress_controller_per_second" | jq .

{
  "kind": "ExternalMetricValueList",
  "apiVersion": "external.metrics.k8s.io/v1beta1",
  "metadata": {},
  "items": [
    {
      "metricName": "nginx_ingress_controller_per_second",
      "metricLabels": {},
      "timestamp": "2025-07-25T07:56:04Z",
      "value": "0"
    }
  ]
}

Étape 4 : Créer les HPA

Les deux HPA utilisent la même métrique externe nginx_ingress_controller_per_second mais la filtrent pour leur service respectif en utilisant selector.matchLabels.service. L’adaptateur transmet ces étiquettes en tant que <<.LabelMatchers>> dans la requête PromQL, garantissant ainsi l’indépendance des décisions de mise à l’échelle pour chaque application.

1. Créez hpa.yaml avec le contenu suivant :

   Exemple YAML

   apiVersion: autoscaling/v2
   kind: HorizontalPodAutoscaler
   metadata:
     name: sample-hpa
     namespace: default
   spec:
     scaleTargetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: sample-app
     minReplicas: 1
     maxReplicas: 10
     metrics:
       - type: External
         external:
           metric:
             name: nginx_ingress_controller_per_second
             selector:
               matchLabels:
   # Filters the metric to requests for this service only.
   # The labels set here are passed to <<.LabelMatchers>> in the adapter rule.
                 service: sample-app
   # External metrics support only Value and AverageValue target types.
           target:
             type: AverageValue
             averageValue: 30
   ---
   apiVersion: autoscaling/v2
   kind: HorizontalPodAutoscaler
   metadata:
     name: test-hpa
     namespace: default
   spec:
     scaleTargetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: test-app
     minReplicas: 1
     maxReplicas: 10
     metrics:
       - type: External
         external:
           metric:
             name: nginx_ingress_controller_per_second
             selector:
               matchLabels:
   # Filters the metric to requests for this service only.
   # The labels set here are passed to <<.LabelMatchers>> in the adapter rule.
                 service: test-app
   # External metrics support only Value and AverageValue target types.
           target:
             type: AverageValue
             averageValue: 30

   Appliquez le manifeste :

   kubectl apply -f hpa.yaml

2. Vérifiez que les deux HPA sont prêts :

   kubectl get hpa

   Sortie attendue :

   NAME         REFERENCE               TARGETS       MINPODS   MAXPODS   REPLICAS   AGE
   sample-hpa   Deployment/sample-app   0/30 (avg)   1         10        1          74s
   test-hpa     Deployment/test-app     0/30 (avg)   1         10        1          59m

   Les deux HPA affichent 0/30 (avg), ce qui signifie que le taux de requêtes actuel est inférieur au seuil de mise à l’échelle horizontale de 30 requêtes par seconde par pod.

Étape 5 : Vérifier l’autoscaling

Utilisez Apache Benchmark pour générer du trafic et observer la réponse indépendante de chaque HPA.

1. Envoyez 5 000 requêtes vers le chemin /home (acheminé vers test-app) :

   ab -c 50 -n 5000 test.example.com/home

2. Surveillez l’état du HPA en temps réel :

   kubectl get hpa --watch

   Après la charge, test-hpa effectue une mise à l’échelle horizontale tandis que sample-hpa reste à un seul réplica :

   NAME         REFERENCE               TARGETS           MINPODS   MAXPODS   REPLICAS   AGE
   sample-hpa   Deployment/sample-app   0/30 (avg)        1         10        1          22m
   test-hpa     Deployment/test-app     22096m/30 (avg)   1         10        3          80m

   Appuyez sur Ctrl+C pour arrêter la surveillance.

3. Envoyez 5 000 requêtes vers le chemin racine (acheminé vers sample-app) :

   ab -c 50 -n 5000 test.example.com/

4. Vérifiez à nouveau l’état du HPA :

   kubectl get hpa

   Sortie attendue :

   NAME         REFERENCE               TARGETS           MINPODS   MAXPODS   REPLICAS   AGE
   sample-hpa   Deployment/sample-app   27778m/30 (avg)   1         10        2          38m
   test-hpa     Deployment/test-app     0/30 (avg)        1         10        1          96m

   sample-hpa a effectué une mise à l’échelle horizontale sous la charge, tandis que test-hpa a réduit ses ressources après l’arrêt du trafic vers /home. Chaque application a été mise à l’échelle indépendamment en fonction de son propre trafic.

Étapes suivantes

• Mise à l’échelle multi-zones : Mettre à l’échelle simultanément sur plusieurs zones pour les services à forte intensité de données et haute disponibilité.

• Images OS personnalisées pour la mise à l’échelle élastique : Simplifiez l’autoscaling dans les environnements ayant des exigences spécifiques en matière de nœuds en utilisant des images personnalisées.