Supposons que vous construisez une application cloud. De toute évidence, vous testerez l’application pendant le développement pour vous assurer qu’elle se comporte comme vous l’attendez. Et quelle que soit la manière dont vous développez votre application, votre outil de test unitaire préféré facilitera la création, l’exécution et l’obtention des résultats de vos tests.
Et si vous testiez votre application lorsque vous la déployez dans un cluster Kubernetes (test/dev/staging/prod) ? L’application gère-t-elle des conditions de charge réalistes avec des performances acceptables ? La nouvelle version de l’application améliore-t-elle les statistiques commerciales par rapport à la version précédente ? Est-il résilient ?
Dans cet article, je vais vous présenter Iter8 et l’une de ses nouvelles fonctionnalités, AutoX. Iter8 est un optimiseur de version open source Kubernetes qui peut vous aider à démarrer le test des applications Kubernetes (expériences) en quelques secondes. Avec Iter8, vous pouvez effectuer différents types d’expériences, telles que des tests de performances, des tests A/B/n, des tests d’injection de chaos, etc.
Iter8 a récemment introduit une nouvelle fonctionnalité : AutoX. AutoX, abréviation d’expériences automatiques, vous permet d’effectuer automatiquement les expériences ci-dessus en tirant parti d’Argo CD, un outil de livraison continue populaire. Nous explorerons le lancement automatique d’expériences de test de performances pour un service HTTP déployé dans Kubernetes. Vous pouvez vous familiariser avec Iter8 sur le site officiel d’Iter8.
AutoX
La publication d’une nouvelle version d’une application implique généralement la création de nouveaux objets de ressource Kubernetes et/ou la mise à jour d’objets existants. AutoX peut être configuré pour surveiller ces changements et lancer automatiquement de nouvelles expériences. Vous pouvez configurer AutoX avec plusieurs groupes d’expériences et, pour chaque groupe, spécifier l’objet de ressource Kubernetes qu’AutoX surveillera et une ou plusieurs expériences à effectuer en réponse aux nouvelles versions de cet objet.
Voyons maintenant cela en action en utilisant un service HTTP Kubernetes et en configurant AutoX, donc chaque fois qu’une nouvelle version du service est publiée, AutoX lancera un nouveau test de performance HTTP qui validera si le service répond aux exigences de latence et d’erreur.
Télécharger l’interface de ligne de commande Iter8
brew tap iter8-tools/iter8
brew install iter8@0.13La CLI Iter8 fournit les commandes nécessaires pour voir les rapports d’expérience.
Configurer le cluster Kubernetes avec ArgoCD
Comme mentionné précédemment, AutoX est construit sur ArgoCD, nous devrons donc également l’installer.
Une installation de base d’Argo CD peut être effectuée comme suit :
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yamlDéployer l’application
Maintenant, nous allons créer un httpbin déploiement et service :
kubectl create deployment httpbin --image=kennethreitz/httpbin --port=80
kubectl expose deployment httpbin --port=80Appliquer l’étiquette de version
Ensuite, nous attribuerons httpbin déploiement le app.kubernetes.io/version étiquette (étiquette de version). AutoX lancera des expériences uniquement lorsque cette étiquette est présente sur votre objet déclencheur. Il relancera les expériences chaque fois que ce libellé de version sera modifié.
kubectl label deployment httpbin app.kubernetes.io/version=1.0.0Configurer le cluster Kubernetes avec Iter8 AutoX
Ensuite, nous allons configurer et installer le contrôleur AutoX :
helm install autox autox --repo https://iter8-tools.github.io/hub/ --version 0.1.6 \
--set 'groups.httpbin.trigger.name=httpbin' \
--set 'groups.httpbin.trigger.namespace=default' \
--set 'groups.httpbin.trigger.group=apps' \
--set 'groups.httpbin.trigger.version=v1' \
--set 'groups.httpbin.trigger.resource=deployments' \
--set 'groups.httpbin.specs.iter8.name=iter8' \
--set 'groups.httpbin.specs.iter8.values.tasks={ready,http,assess}' \
--set 'groups.httpbin.specs.iter8.values.ready.deploy=httpbin' \
--set 'groups.httpbin.specs.iter8.values.ready.service=httpbin' \
--set 'groups.httpbin.specs.iter8.values.ready.timeout=60s' \
--set 'groups.httpbin.specs.iter8.values.http.url=http://httpbin.default/get' \
--set 'groups.httpbin.specs.iter8.values.assess.SLOs.upper.http/error-count=0' \
--set 'groups.httpbin.specs.iter8.values.assess.SLOs.upper.http/latency-mean=50' \
--set 'groups.httpbin.specs.iter8.version=0.13.0' \
--set 'groups.httpbin.specs.iter8.values.runner=job'La configuration du contrôleur AutoX est composée d’un définition d’objet déclencheur et un ensemble de spécifications de l’expérience. Dans ce cas, l’objet déclencheur est le httpbin déploiement et il n’y a qu’une seule expérience, un test de performance HTTP avec validation SLO associée à ce déclencheur.
Pour aller plus en détail, la configuration est un ensemble de groupeset chaque groupe est composé d’une définition d’objet déclencheur et d’un ensemble de spécifications de l’expérience. Cela permet à AutoX de gérer un ou plusieurs objets déclencheurs, chacun associé à une ou plusieurs expériences. Dans ce tutoriel, il n’y a qu’un seul groupe nommé httpbin (groups.httpbin...), et dans ce groupe, il y a la définition de l’objet déclencheur (groups.httpbin.trigger...) et une seule spécification de test nommée iter8 (groups.httpbin.specs.iter8...).
La définition de l’objet déclencheur est une combinaison du nom, de l’espace de noms et des métadonnées de ressource de version de groupe (GVR) de l’objet déclencheur. Dans ce cas, httpbin, defaultet GVR apps, deploymentset v1respectivement.
L’expérience est un test de validation HTTP SLO sur le httpbin un service. Cette expérience Iter8 est composée de trois tâches, ready, httpet assess. Les ready tâche garantira que le httpbin le déploiement et le service sont en cours d’exécution. Les http La tâche effectuera des requêtes à l’URL spécifiée et collectera les métriques liées à la latence et aux erreurs. Enfin, le assess tâche s’assurera que la latence moyenne est inférieure à 50 millisecondes et que le nombre d’erreurs est égal à « 0 ». De plus, le coureur est défini sur « travail » car il s’agira d’une expérience à boucle unique.
Observer l’expérience
Après le démarrage d’AutoX, le test de validation HTTP SLO devrait suivre rapidement. Vous pouvez maintenant utiliser la CLI Iter8 pour vérifier l’état et voir les résultats du test.
La commande suivante vous permet de vérifier l’état du test.
Note: Vous devez spécifier un groupe de tests via le -g option. Les groupe d’expérimentation pour les expériences démarrées par AutoX est sous la forme autox-<group name>-<experiment spec name>donc, dans ce cas, ce serait autox-httpbin-iter8:
iter8 k assert -c completed -c nofailure -c slos -g autox-httpbin-iter8Nous pouvons voir dans l’exemple de sortie que le test est terminé, qu’il n’y a eu aucun échec et que tous les SLO et conditions ont été satisfaits.
INFO[2023-01-11 14:43:45] inited Helm config
INFO[2023-01-11 14:43:45] experiment completed
INFO[2023-01-11 14:43:45] experiment has no failure
INFO[2023-01-11 14:43:45] SLOs are satisfied
INFO[2023-01-11 14:43:45] all conditions were satisfied La commande suivante vous permet de voir les résultats sous forme de rapport texte :
iter8 k report -g autox-httpbin-iter8Vous pouvez également produire un rapport HTML que vous pouvez visualiser dans le navigateur :
iter8 k report -g autox-httpbin-iter8 -o html > report.htmlLe rapport HTML ressemblera à ce qui suit :
Expérimentation continue et automatisée
Maintenant qu’AutoX regarde le httpbin déploiement, la nouvelle version relancera le test de validation HTTP SLO. La mise à jour de version doit s’accompagner d’une modification du déploiement app.kubernetes.io/version étiquette (étiquette de version); sinon, AutoX ne fera rien.
Pour plus de simplicité, nous allons changer le libellé de la version du déploiement pour relancer le test de validation HTTP SLO. Dans le monde réel, une nouvelle version impliquerait généralement une modification de la spécification de déploiement (par exemple, l’image du conteneur) et cette modification devrait être accompagnée d’une modification de l’étiquette de version :
kubectl label deployment httpbin app.kubernetes.io/version=2.0.0 --overwriteObservez la nouvelle expérience
Vérifiez si une nouvelle expérience a été lancée. Reportez-vous au précédent « Observer l’expérience” section pour les commandes nécessaires.
Si nous devions continuer à mettre à jour le déploiement (et changer son étiquette de version), alors AutoX relancerait l’expérience pour chaque changement.
Plats à emporter
AutoX est une nouvelle fonctionnalité puissante d’Iter8 qui vous permet de lancer automatiquement des expériences de performances sur vos applications Kubernetes dès que vous publiez une nouvelle version. La configuration d’AutoX est simple et nécessite de spécifier un objet de ressource Kubernetes déclencheur et les expériences que vous souhaitez associer à cet objet déclencheur. Après avoir essayé le didacticiel, envisagez de l’essayer sur vos propres applications Kubernetes.