menu
arrow_back

Tests de charge distribués avec Kubernetes

Tests de charge distribués avec Kubernetes

Hours 5 Credits

GSP182

Google Cloud – Ateliers adaptés au rythme de chacun

Présentation

Dans cet atelier, vous allez apprendre à utiliser Kubernetes Engine pour déployer un framework de tests de charge distribués. Le framework a recours à plusieurs conteneurs pour créer un trafic de tests de charge pour une API simple basée sur REST. Bien que cette solution teste une application Web simple, le même modèle peut être utilisé pour créer des scénarios de test de charge plus complexes, tels que des applications de jeu ou de l'Internet des objets (IoT). Cette solution présente l'architecture générale d'un framework de test de charge basé sur des conteneurs.

Système soumis aux tests

Pour les besoins de cet atelier, le système soumis aux tests est une petite application Web déployée sur Google App Engine. L'application expose les points de terminaison de base de type REST pour enregistrer les requêtes HTTP POST entrantes (les données entrantes ne sont pas conservées).

Exemples de charges de travail

L'application que vous allez déployer a été élaborée sur la base du composant de service de backend présent dans de nombreux déploiements de l'Internet des objets (IoT). Les appareils s'enregistrent d'abord auprès du service, puis commencent à créer des rapports de métriques ou de relevés de capteur, tout en se réenregistrant périodiquement auprès du service.

L'interaction courante des composants de service de backend est semblable à ceci : 542dlt85f86jjd1f.png

Pour modéliser cette interaction, vous allez utiliser Locust, un outil de tests de charge distribués basé sur Python, capable de distribuer des requêtes sur plusieurs chemins d'accès cibles. Par exemple, Locust peut distribuer des requêtes sur les chemins d'accès cibles /login et /metrics.

La charge de travail est basée sur l'interaction décrite ci-dessus et est modélisée en tant qu'ensemble de tâches dans Locust. Pour se rapprocher des clients du monde réel, chaque tâche Locust est pondérée. Par exemple, l'enregistrement se produit tous les milliers de requêtes client.

Solutions de calcul basées sur des conteneurs

  • L'image du conteneur Locust est une image Docker contenant le logiciel Locust.

  • Un cluster de conteneurs se compose d'au moins un cluster maître et de plusieurs nœuds de calcul appelés nœuds. Ces machines maîtres et nœuds exécutent le système d’orchestration de cluster Kubernetes. Pour plus d'informations sur les clusters, consultez la documentation de Kubernetes Engine

  • Un pod est un ensemble d'un ou de plusieurs conteneurs déployés ensemble sur un même hôte, ainsi que l'unité de calcul la plus petite pouvant être définie, déployée et gérée. Certains pods ne contiennent qu'un seul conteneur. Par exemple, dans cet atelier, chacun des conteneurs Locust s'exécute dans son propre pod.

  • Un contrôleur de déploiement fournit des mises à jour déclaratives pour les Pods et les ReplicaSets. Cet atelier comprend deux déploiements : l'un pour locust-master et l'autre pour locust-worker.

  • Services

    Un pod spécifique peut disparaître pour plusieurs raisons : par exemple, en cas de défaillance des nœuds ou d'une interruption volontaire des nœuds pour effectuer des opérations de mises à jour ou de maintenance. Cela signifie que l'adresse IP d'un pod ne fournit pas une interface suffisamment fiable. Une approche plus fiable serait d'utiliser une représentation abstraite de cette interface qui ne change jamais, même si le pod sous-jacent disparaît et est remplacé par un nouveau pod avec une adresse IP différente. Un service Kubernetes Engine fournit ce type d'interface abstraite en définissant un ensemble logique de pods et une stratégie permettant d'y accéder.

    Dans cet atelier, plusieurs services représentent des pods ou des ensembles de pods. Par exemple, il existe un service pour le pod du serveur DNS, un autre service pour le pod maître Locust et un service représentant les 10 pods de nœuds de calcul Locust.

    Le schéma ci-dessous illustre le contenu des nœuds maîtres et des nœuds de calcul :

4er1cd4e32459737.png

Objectifs de l'atelier

  • Créer un système soumis aux tests, c'est-à-dire, une petite application Web déployée sur Google App Engine
  • Utiliser Kubernetes Engine pour déployer un framework de tests de charge distribués
  • Créer un trafic de test de charge pour une API REST simple

Prérequis

  • Bonne connaissance des services GCP App Engine et Kubernetes Engine
  • Bonne connaissance des éditeurs de texte Linux standards tels que Vim, Emacs ou Nano

Join Qwiklabs to read the rest of this lab...and more!

  • Get temporary access to the Google Cloud Console.
  • Over 200 labs from beginner to advanced levels.
  • Bite-sized so you can learn at your own pace.
Join to Start This Lab