Tutoriel NGINX : réduisez la latence de Kubernetes grâce à l’autoscaling

Daniele Polencic

Ce tutoriel est l’un des quatre qui mettent en pratique les concepts abordés dans « Microservices de mars 2022 : mise en réseau Kubernetes » :

• Réduire la latence de Kubernetes grâce à la mise à l’échelle automatique (cet article)
• Protégez les API Kubernetes grâce à la limitation du débit
• Protéger les applications Kubernetes contre les injections SQL
• Améliorez la disponibilité et la résilience grâce à un déploiement Canary

Vous souhaitez obtenir des conseils détaillés sur l’utilisation de NGINX pour encore plus de cas d’usage réseau avec Kubernetes ? Téléchargez gratuitement notre e-book, « Gestion du trafic Kubernetes avec NGINX : guide pratique ».

Votre organisation a développé une application dans Kubernetes, et celle-ci rencontre désormais un franc succès ! De quelques visiteurs seulement, vous êtes passé à des centaines (et parfois des milliers) par jour. Mais il y a un problème… L’augmentation du trafic se heurte à un goulot d’étranglement, ce qui entraîne des temps de latence et des expirations de délai pour vos clients. Si vous ne parvenez pas à améliorer leur expérience, les utilisateurs cesseront d’utiliser l’application.

Vous – le courageux ingénieur Kubernetes – avez une solution. Vous déployez un contrôleur Ingress pour acheminer le trafic et configurez une politique de mise à l’échelle automatique afin que le nombre de pods du contrôleur Ingress augmente ou diminue instantanément en fonction des fluctuations du trafic. Désormais, les pods de votre contrôleur Ingress absorbent sans difficulté les pics de trafic – « Adieu, latence ! » – et réduisent leur nombre pour économiser les ressources lorsque le trafic diminue – « Bonjour, économies ! » Bravo à vous.

Présentation du lab et du tutoriel

Cet article de blog accompagne le TP de l’unité 1 de Microservices March 2022 – « Concevoir des clusters Kubernetes pour des sites web à fort trafic » et montre comment utiliser NGINX Ingress Controller pour exposer une application, puis adapter automatiquement le nombre de pods du contrôleur Ingress en cas de trafic élevé.

Pour suivre ce tutoriel, vous avez besoin d’une machine disposant des éléments suivants :

• 2 processeurs ou plus
• 2 Go de mémoire disponible
• 20 Go d’espace disque disponible
• Connexion Internet
• Gestionnaire de conteneurs ou de machines virtuelles, tel que Docker, Hyperkit, Hyper‑V, KVM, Parallels, Podman, VirtualBox ou VMware Fusion/Workstation
• minikube installé
• Helm installé
• Une configuration permettant d’ouvrir une fenêtre de navigateur. Si ce n’est pas possible, vous devez déterminer comment accéder aux services concernés depuis un navigateur.

Pour tirer le meilleur parti de l’atelier pratique et du tutoriel, nous vous recommandons, avant de commencer, de :

• Regardez l’enregistrement de la présentation conceptuelle diffusée en direct
• Consultez les articles de blog de référence
• Regardez le résumé vidéo de 20 minutes du laboratoire :  

Ce tutoriel utilise les technologies suivantes :

• Contrôleur Ingress NGINX (basé sur NGINX Open Source)
• Helm
• KEDA
• Locust
• minikube
• Podinfo
• Prometheus

Les instructions de chaque défi comprennent le texte intégral des fichiers YAML utilisés pour configurer les applications. Vous pouvez également copier le texte depuis notre dépôt GitHub. Un lien vers GitHub est fourni avec le texte de chaque fichier YAML.

Ce tutoriel comprend quatre défis :

1. Configurer une application simple sur un cluster Kubernetes
2. Utiliser NGINX Ingress Controller pour acheminer le trafic vers l’application
3. Générer et surveiller le trafic
4. Mettre à l’échelle automatiquement le contrôleur Ingress NGINX

Défi 1 : configurer une application simple sur un cluster Kubernetes

Dans cet exercice, vous allez créer un cluster minikube et installer Podinfo comme application d’exemple.

Créer un cluster Minikube

Créez un cluster minikube. Après quelques secondes, un message confirme que le déploiement a réussi.

$ minikube start 🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default 

Installer l’application Podinfo

Podinfo est une « application web développée en Go qui présente les bonnes pratiques d’exécution de microservices dans Kubernetes ». Nous l’utilisons comme application d’exemple en raison de sa faible empreinte.

1. À l’aide de l’éditeur de texte de votre choix, créez un fichier YAML nommé 1-deployment.yaml avec le contenu suivant (ou copiez-le depuis GitHub). Il définit un déploiement avec un seul réplica et un service.

apiVersion: apps/v1 kind: Deployment 
metadata: 
  name: podinfo 
spec: 
  selector: 
    matchLabels: 
      app: podinfo 
  template: 
    metadata: 
      labels: 
        app: podinfo 
    spec: 
      containers: 
      - name: podinfo 
        image: stefanprodan/podinfo 
        ports: 
        - containerPort: 9898 
--- 
apiVersion: v1 
kind: Service 
metadata: 
  name: podinfo 
spec: 
  ports: 
    - port: 80 
      targetPort: 9898 
      nodePort: 30001 
  selector: 
    app: podinfo 
  type: LoadBalancer 

1. Déployez l’application :

$ kubectl apply -f 1-deployment.yaml deployment.apps/podinfo created 
service/podinfo created

1. Vérifiez que le pod Podinfo a bien été déployé, comme l’indique la valeur « Running » dans la colonne « STATUS ».

$ kubectl get podsNAME                       READY   STATUS   RESTARTS   AGE 
podinfo-5d76864686-rd2s5   1/1     Running  0          3m38s

1. Ouvrez Podinfo dans un navigateur. La page « greetings from podinfo » indique que Podinfo est en cours d’exécution.

$ minikube service podinfo

Défi 2 : utiliser le contrôleur Ingress NGINX pour acheminer le trafic vers l’application

Dans ce défi, vous allez déployer NGINX Ingress Controller et le configurer pour acheminer le trafic vers l’application Podinfo.

Déployer le contrôleur Ingress NGINX

Le moyen le plus rapide d’installer NGINX Ingress Controller est d’utiliser Helm.

1. Ajoutez le dépôt NGINX à Helm :

$ helm repo add nginx-stable https://helm.nginx.com/stable 

1. Téléchargez et installez le NGINX Ingress Controller basé sur NGINX Open Source, qui est maintenu par F5 NGINX. La dernière ligne de sortie confirme que l’installation a réussi.

$ helm install main nginx-stable/nginx-ingress \ --set controller.watchIngressWithoutClass=true \ --set controller.service.type=NodePort \ --set controller.service.httpPort.nodePort=30005 
NAME: main 
LAST DEPLOYED: Tue Mar 15 09:49:17 2022 
NAMESPACE: default 
STATUS: deployed 
REVISION: 1 
TEST SUITE: None 
NOTES: The NGINX Ingress Controller has been installed.

1. Vérifiez que le pod du contrôleur Ingress NGINX a bien été déployé, comme l’indique la valeur « Running » dans la colonne « STATUS » (pour plus de lisibilité, la sortie est répartie sur deux lignes).

$ kubectl get podsNAME                                   READY   STATUS    ...
main-nginx-ingress-779b74bb8b-mtdkr    1/1     Running   ...
podinfo-5d76864686-fjncl               1/1     Running   ...

       ... RESTARTS   AGE
       ... 0          18s 
       ... 0        2m36s

Acheminer le trafic vers votre application

1. À l’aide de l’éditeur de texte de votre choix, créez un fichier YAML nommé « 2-ingress.yaml » avec le contenu suivant (ou copiez-le depuis GitHub). Il définit le manifeste Ingress nécessaire pour acheminer le trafic vers Podinfo.

apiVersion: networking.k8s.io/v1 kind: Ingress 
metadata: 
  name: podinfo 
spec: 
  ingressClassName: nginx 
  rules: 
    - host: "example.com" 
      http: 
        paths: 
          - backend: 
              service: 
                name: podinfo 
                port: 
                  number: 80 
            path: / 
            pathType: Prefix 

1. Déployez la ressource Ingress :

$ kubectl apply -f 2-ingress.yaml ingress.networking.k8s.io/podinfo created 

Défi 3 : générer et surveiller le trafic

Dans cet exercice, vous observez les performances de NGINX Ingress Controller sous différentes charges de trafic. En guise de préparation, vous répertoriez les métriques disponibles dans NGINX Ingress Controller, déployez Prometheus et installez Locust. Vous utilisez ensuite Locust pour simuler un pic de trafic et suivre son impact sur les performances dans Prometheus.

Comme vous l’avez déjà constaté, un contrôleur Ingress est un pod Kubernetes standard qui regroupe un proxy inverse (dans notre cas, NGINX) et du code permettant son intégration à Kubernetes. Si votre application reçoit beaucoup de trafic, vous devrez probablement augmenter le nombre de réplicas du pod NGINX Ingress Controller afin d’éviter la latence qui survient lorsque NGINX Ingress Controller est surchargé.

Répertorier les métriques disponibles

Pour savoir quand effectuer une mise à l’échelle et dans quelle mesure, vous avez besoin d’informations précises sur les performances de NGINX Ingress Controller. Dans ce tutoriel, la métrique NGINX utilisée pour déterminer quand effectuer une mise à l’échelle est le nombre de connexions actives (nginx_connections_active). Vous allez vérifier ici que votre NGINX Ingress Controller assure le suivi de cette métrique.

NGINX Ingress Controller expose plusieurs métriques: 8 métriques avec le modèle basé sur NGINX Open Source que nous utilisons dans ce tutoriel, et plus de 80 métriques avec le modèle basé sur NGINX Plus.

1. Obtenez l’adresse IP du pod NGINX Ingress Controller afin de pouvoir interroger sa liste de métriques. L’adresse apparaît dans le champ « IP » et, ici, il s’agit de « 172.17.0.4 ». (Pour plus de lisibilité, les colonnes « RESTARTS » et « AGE » sont omises et la sortie est répartie sur deux lignes.)

$ kubectl get pods -o wide NAME                                  READY   STATUS    ...
main-nginx-ingress-779b74bb8b-6hdwx   1/1     Running   ...
podinfo-5d76864686-nl8ws              1/1     Running   ...

    ... IP           NODE       NOMINATED NODE  READINESS GATES 
    ... 172.17.0.4   minikube   <none>          <none> 
    ... 172.17.0.3   minikube   <none>          <none>

1. Créez un pod BusyBox temporaire avec un shell sur un hôte au sein du cluster Kubernetes :

$ kubectl run -ti --rm=true busybox --image=busyboxIf you don't see a command prompt, try pressing enter. 
/ # 

1. Répertoriez les métriques générées par votre contrôleur Ingress NGINX et vérifiez qu'elles incluent « nginx_connections_active ». Pour <IP_address>, utilisez la valeur obtenue à l'étape 1.

/# wget -qO- <IP_address>:9113/metrics

1. Quittez le shell pour revenir au serveur Kubernetes.

/# exit 

Déployer Prometheus

Maintenant que vous savez que votre contrôleur Ingress NGINX surveille la métrique nginx_connections_active, vous avez besoin d’un outil pour collecter (« scraper ») les métriques. Ce tutoriel utilise Prometheus.

Comme pour NGINX Ingress Controller, Helm est le moyen le plus rapide d’installer Prometheus.

1. Ajoutez le dépôt Prometheus à Helm :

$ helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

1. Téléchargez et installez Prometheus :

$ helm install prometheus prometheus-community/prometheus \ --set server.service.type=NodePort --set server.service.nodePort=30010

1. Vérifiez l’installation, qui prend généralement jusqu’à 60 secondes. Dans l’exemple de sortie suivant, la commande de vérification a été exécutée quelques secondes seulement après la commande helm install ; l’installation est donc toujours en cours, et l’état ContainerCreating est indiqué dans le champ STATUS pour certains pods Prometheus. L’installation est terminée lorsque tous les pods ont l’état Running. (La sortie est répartie sur deux lignes pour en faciliter la lecture.)

$ kubectl get podsNAME                                           READY  ...
main-nginx-ingress-779b74bb8b-mtdkr            1/1    ...
podinfo-5d76864686-fjncl                       1/1    ...
prometheus-alertmanager-d6d94cf4b-85ww5        0/2    ...
prometheus-kube-state-metrics-7cd8f95cb-86hhs  0/1    ...
prometheus-node-exporter-gqxfz                 1/1    ...
prometheus-pushgateway-56745d8d8b-qnwcb        0/1    ...
prometheus-server-b78c9449f-kwhzp              0/2    ...

      ... STATUS             RESTARTS  AGE 
      ... Running            0         3m23s 
      ... Running            0         5m41s 
      ... ContainerCreating  0         7s
      ... Running            0         7s
      ... Running            0         7s
      ... ContainerCreating  0         7s
      ... ContainerCreating  0         7s

1. Ouvrez Prometheus. Dans un environnement minikube, exécutez la commande suivante, qui ouvre le tableau de bord Prometheus dans votre navigateur par défaut.

$ minikube service prometheus-server

1. Une page comme celle ci-dessous confirme que le serveur fonctionne.
   
2. Saisissez « nginx_ingress_nginx_connections_active » dans la barre de recherche pour afficher la valeur actuelle de la métrique des connexions actives. Une connexion active s’affiche, ce qui est logique puisque vous avez déployé un pod NGINX Ingress Controller.

Installer Locust

Dans la section suivante, vous utiliserez Locust, un outil open source de test de charge, pour simuler un pic de trafic afin d’observer les performances de NGINX Ingress Controller dans Prometheus. Vous allez ici déployer Locust.

1. À l’aide de l’éditeur de texte de votre choix, créez un fichier YAML nommé « 3-locust.yaml » avec le contenu suivant (ou copiez-le depuis GitHub). Les objets Deployment et Service définissent le pod Locust. L’objet ConfigMap définit un script nommé « locustfile.py », qui génère les requêtes à envoyer au pod avec les en-têtes appropriés.

apiVersion: v1 
kind: ConfigMap 
metadata: 
  name: locust-script 
data: 
  locustfile.py: |- 
    from locust import HttpUser, task, between 

    class QuickstartUser(HttpUser): 
        wait_time = between(0.7, 1.3) 

        @task 
        def hello_world(self): 
            self.client.get("/", headers={"Host": "example.com"}) 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: locust 
spec: 
  selector: 
    matchLabels: 
      app: locust 
  template: 
    metadata: 
      labels: 
        app: locust 
    spec: 
      containers: 
        - name: locust 
          image: locustio/locust 
          ports: 
            - containerPort: 8089 
          volumeMounts: 
            - mountPath: /home/locust 
              name: locust-script 
      volumes: 
        - name: locust-script 
          configMap: 
            name: locust-script 
--- 
apiVersion: v1 
kind: Service 
metadata: 
  name: locust 
spec: 
  ports: 
    - port: 8089 
      targetPort: 8089 
      nodePort: 30015 
  selector: 
    app: locust 
  type: LoadBalancer 

1. Déployez Locust :

$ kubectl apply -f 3-locust.yaml configmap/locust-script created 
deployment.apps/locust created 
service/locust created 

Simuler un pic de trafic et observer son impact sur les performances

1. Ouvrez Locust dans un navigateur.

$ minikube service locust

1. 
2. Saisissez les valeurs suivantes dans les champs :
   • Nombre d’utilisateurs – 1 000
   • Taux d’apparition – 10
   • Hôte – http://main-nginx-ingress
3. Cliquez sur le bouton « Démarrer l’essaimage » pour envoyer du trafic vers l’application Podinfo.
4. Revenez au tableau de bord Prometheus pour voir comment NGINX Ingress Controller réagit. Vous devrez peut-être effectuer une nouvelle requête sur nginx_ingress_nginx_connections_active pour observer un changement. Comme le montre la capture d’écran suivante, l’unique pod NGINX Ingress Controller peine à traiter l’augmentation du trafic sans hausse de la latence lorsqu’un grand nombre de connexions sont établies. Le graphique Prometheus révèle qu’environ 100 connexions actives par pod NGINX Ingress Controller constituent le seuil à partir duquel la latence augmente fortement. Vous pouvez utiliser ces informations pour déterminer à quel moment augmenter le nombre de pods NGINX Ingress Controller afin d’éviter une hausse de la latence.
   

Défi 4 : mettre à l’échelle automatiquement NGINX Ingress Controller

Dans le dernier défi, vous créez une configuration qui adapte automatiquement les ressources à mesure que le volume de trafic augmente. Le tutoriel utilise KEDA pour la mise à l’échelle automatique. Vous devez donc commencer par l’installer et créer une stratégie qui définit quand et comment la mise à l’échelle s’effectue. Comme dans le défi 3, vous utilisez ensuite Locust pour simuler un pic de trafic et Prometheus pour observer les performances de NGINX Ingress Controller lorsque la mise à l’échelle automatique est activée.

Installer KEDA

KEDA, un outil de mise à l’échelle automatique de Kubernetes piloté par les événements, intègre un serveur de métriques (le composant qui stocke et transforme les métriques pour Kubernetes) et peut récupérer des métriques directement depuis Prometheus (ainsi que depuis d’autres outils). Il crée un Horizontal Pod Autoscaler (HPA) à partir de ces métriques, fait le lien avec les métriques collectées par Prometheus et les transmet à Kubernetes.

Comme pour NGINX Ingress Controller et Prometheus, ce tutoriel utilise Helm pour installer KEDA.

1. Ajoutez KEDA au dépôt Helm :

$ helm repo add kedacore https://kedacore.github.io/charts 
"kedacore" has been added to your repositories 

1. Installez KEDA :

$ helm install keda kedacore/keda NAME: keda 
NAMESPACE: default 
STATUS: deployed 
REVISION: 1 
TEST SUITE: None

1. Vérifiez que KEDA s’exécute sous la forme de deux pods. (Pour faciliter la lecture, certaines valeurs de la colonne NAME sont abrégées. De plus, la colonne RESTARTS est omise ; sa valeur est 0 pour tous les pods.)

$ kubectl get pods NAME                                    READY  STATUS     AGE 
keda-operator-8644dcdb79-492x5 1/1 Running 59s keda-operator-metrics-apiserver-66d... 1/1 Running 59s 
locust-77c699c94d-dvb5n                 1/1    Running  8m59s 
main-nginx-ingress-779b74bb8b-v7ggw     1/1    Running    48m 
podinfo-5d76864686-c98rb                1/1    Running    50m 
prometheus-alertmanager-d6d94cf4b-8...  2/2    Running    37m 
prometheus-kube-state-metrics-7cd8f...  1/1    Running    37m 
prometheus-node-exporter-j4qf4          1/1    Running    37m 
prometheus-pushgateway-56745d8d8b-9n4nl 1/1    Running    37m 
prometheus-server-b78c9449f-6ktn9       2/2    Running    37m

Créer une stratégie de mise à l’échelle automatique

Utilisez maintenant la définition de ressource personnalisée (CRD) ScaledObject de KEDA pour définir les paramètres qui déterminent la mise à l’échelle de NGINX Ingress Controller. La configuration suivante :

• Déclenche la mise à l’échelle automatique en fonction de la valeur de la métrique nginx_connections_active collectée par Prometheus
• Déploie un nouveau pod lorsque les pods existants atteignent chacun 100 connexions actives
• Met automatiquement à l’échelle les pods NGINX Ingress Controller, d’un seul pod jusqu’à 20 pods

Effectuez les étapes suivantes :

1. À l’aide de l’éditeur de texte de votre choix, créez un fichier YAML nommé 4-scaled-object.yaml avec le contenu suivant (ou copiez-le depuis GitHub). Il définit un objet ScaledObject KEDA.

apiVersion: keda.sh/v1alpha1 kind: ScaledObject 
metadata: 
 name: nginx-scale 
spec: 
 scaleTargetRef: 
   kind: Deployment 
   name: main-nginx-ingress 
minReplicaCount: 1 
maxReplicaCount: 20 
cooldownPeriod: 30 
pollingInterval: 1 
triggers: 
- type: prometheus 
  metadata: 
    serverAddress: http://prometheus-server 
    metricName: nginx_connections_active_keda 
    query: | 
      sum(avg_over_time(nginx_ingress_nginx_connections_active{app="main-nginx-ingress"}[1m])) 
    threshold: "100" 

1. Déployez le ScaledObject :

$ kubectl apply -f 4-scaled-object.yaml scaledobject.keda.sh/nginx-scale created 

Simuler un pic de trafic et observer l’effet de la mise à l’échelle automatique sur les performances

Pour véritablement tester l’efficacité de la mise à l’échelle automatique, vous doublez le nombre de connexions par rapport au défi 3.

1. Revenez au serveur Locust dans votre navigateur. Saisissez les valeurs suivantes dans les champs, puis cliquez sur le bouton « Démarrer l’essaimage » :
   • Nombre d’utilisateurs – 2 000
   • Taux d’apparition – 10
   • Hôte – http://main-nginx-ingress
2. Revenez aux tableaux de bord Prometheus et Locust. La zone rose sous le graphique Prometheus représente l’évolution à la hausse et à la baisse du nombre de pods NGINX Ingress Controller.
   
3. Revenez à votre terminal et inspectez manuellement le HPA de KEDA. Le champ « REPLICAS » dans la sortie indique le nombre actuel de réplicas de pods déployés. (La sortie est répartie sur deux lignes pour en faciliter la lecture.)

$ kubectl get hpa
NAME                  REFERENCE                      ... 
keda-hpa-nginx-scale  Deployment/main-nginx-ingress  ... 

    ... TARGETS           MINPODS   MAXPODS   REPLICAS   AGE 
    ... 101500m/100 (avg) 1         20        10         2m45s

Étapes suivantes

Le fait de baser l’autoscaling uniquement sur le nombre de connexions actives présente une limite potentielle. Si, même avec l’autoscaling, NGINX Ingress Controller est tellement sollicité qu’il doit abandonner des connexions, l’autoscaler détecte moins de connexions actives, en déduit que le nombre de requêtes a diminué et réduit le nombre de réplicas. Cela peut dégrader les performances, mais l’utilisation conjointe de plusieurs métriques permet d’éviter ce problème. Par exemple, nginxplus_connections_dropped (disponible avec NGINX Ingress Controller basé sur NGINX Plus) comptabilise ces connexions clientes abandonnées.

Pour essayer NGINX Ingress Controller avec NGINX Plus et NGINX App Protect, commencez votre essai gratuit de 30 jours dès aujourd’hui ou contactez-nous pour discuter de vos cas d’utilisation.

Pour essayer NGINX Ingress Controller avec NGINX Open Source, vous pouvez obtenir le code source de la version, ou télécharger une image de conteneur précompilée depuis DockerHub.

À propos de l’auteur

Daniele Polencic

Autres articles de Daniele Polencic