Semer le Chaos en moins de 24h avec Litmus

Dans notre précédent article, nous vous parlions de notre plongée dans le monde du chaos engineering lors du Weckathon annuel de WeScale. À cette occasion, nous avons exploré Chaos Mesh pour tester la résilience d’infrastructures et d’applications Kubernetes dans des conditions défaillantes.

Alors qu’il ne reste que quelques heures avant la fin de ce Weckathon, nous décidons de déployer une nouvelle solution de chaos engineering : Litmus Chaos. Plusieurs collègues nous l’avaient recommandée et nous sommes curieux de voir comment elle se compare à Chaos Mesh.

Litmus, le challenger plus complexe

Installation

Nous disposons déjà de l’environnement de test installé pour l’évaluation de Chaos Mesh :

• K3s déployé sur trois VM sur notre laptop,
• WordPress et sa base MariaDB déployés sur ce mini-cluster K3s,
• K6 pour simuler du trafic utilisateur sur notre site WordPress,
• Prometheus et Grafana pour l’observabilité sur les ressources de notre cluster.

Il ne nous reste donc plus qu’à installer Litmus.

La documentation de Litmus 3.16.0 propose deux modes d’installation : via helm ou un kubectl (apply d’un manifest). Comme pour Chaos Mesh, nous choisissons l’option Helm.

• Ajouter le repo Helm Litmus :

helm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/

helm repo list

• Installer Litmus (namespace litmus) : 

kubectl create ns litmus

helm install chaos litmuschaos/litmus \
  --namespace=litmus \
  --set portal.frontend.service.type=NodePort

• Vérification de l’installation

kubectl get pods --namespace litmus
NAME                                        READY   STATUS    RESTARTS   AGE
chaos-litmus-auth-server-6798b5688f-lhb5t   1/1     Running   0          2m45s
chaos-litmus-frontend-76f7fb449d-rk8qc      1/1     Running   0          2m45s
chaos-litmus-server-56658b7f6d-n2rlt        1/1     Running   0          2m45s
chaos-mongodb-0                             1/1     Running   0          2m45s
chaos-mongodb-1                             1/1     Running   0          2m25s
chaos-mongodb-2                             1/1     Running   0          2m5s
chaos-mongodb-arbiter-0                     1/1     Running   0          2m45s

Ce que l’on vient d’installer ce sont les composants du Chaos Center :

• chaos-litmus-frontend : l’interface web Chaos Center
• chaos-litmus-server : l’API GraphQL backend
• chaos-litmus-auth-server : le service d'authentification
• chaos-mongodb : la base de données MongoDB pour la persistance

C’est l’interface Web qui centralise les expériences et le reporting : le QG du chaos !  Les composants de l’architecture de chaos ne sont pas encore installés à ce stade. 

Pour poursuivre, il ne reste plus qu'à lancer un port-forwarding et nous accédons à cette interface.

Prise en main

Connexion

La première connexion se fait avec les login et mot de passe par défaut admin/litmus que l’application nous demande de mettre à jour (avec des contraintes sur le nombre de caractères, etc.).

Configuration du chaos !

Une popup apparaît après le login : il nous faut créer un environnement de chaos engineering. 

L’environnement selon Litmus est une abstraction d’une infrastructure cible. Il est possible de configurer puis d’exécuter des scénarios sur différentes infrastructures que ce soit sur le même cluster ou sur un cluster distant. 

L’interface propose un choix de tag, une description et de choisir entre la production et pré production. Pourquoi pas !

Une fois la configuration faite, il faut “activer” le chaos sur l’infrastructure ciblée 💥 (là nous rajoutons, le namespace, les tags, …).

Au premier abord, cela nous fait l’effet boîte noire : un manifest assez lourd de plus de 4000 lignes est généré et doit être appliqué sur le cluster choisi pour le test. 

L’apply prend quelques minutes avant que notre environnement soit disponible : 

Sous le capot

Que s'est-il passé ? Nous avions installé précédemment le Control Plane, ce manifeste-ci complète l’installation avec l'Execution Plane, les RBAC et les CRD nécessaires à l'exécution d’une expérience : 

• chaos-operator : Orchestrateur des expériences 
• chaos-exporter : Collecte et exposition de métriques vers Prometheus
• workflow-controller : Contrôleur Argo Workflows
• event-tracker : Suivi des événements chaos
• subscriber : Communication entre control/execution planes
• Les autorisations RBACs de tout cela !
• Les CRDs

• • chaosEngine :  est chargé d’exécuter une expérimentation
  • chaosExperiment : définit un template de chaos réutilisable
  • chaosResult : stocke le résultat d'une expérience de chaos

 Au final, voilà à quoi ressemble l'architecture : 

Et côté sécurité cela donne quoi ?

• Avec cette architecture distribuée, la gestion des permissions est plus fine, on a l’interface de gestion et le moteur d'exécution avec des responsabilités distinctes. 
• Chaque équipe d’utilisateurs peut avoir ses propres espaces isolés, avec des rôles différents.
• Notre avis : Litmus amène une gouvernance plus sophistiquée mais potentiellement plus complexe à maintenir suivant les besoins.

Création du premier test ! 

Création de l’expérience

Bon, nous sommes prêts pour démarrer après cette longue configuration et installation !

Lors de notre précédente prise en main de Chaos Mesh, l'expérience qui avait permis d’observer l’impact le plus net sur les performances de notre application était celle consistant à stresser la mémoire des pods de base de données MariaDB de l’application WordPress. Nous décidons donc d’essayer de la reproduire avec Litmus.

Litmus nous offre trois possibilités : 

• Créer une expérience à partir d’un canevas vierge, en ayant accès à la “Fault Libraries” : bibliothèque de défaillances unitaires pour créer une expérience.
• Choisir dans un répertoire de gabarits d'expériences prédéfinies, le “Chaos Hub”.
• Uploader le manifest d’une expérimentation au format YAML.

Le contenu du ChaosHub nous semblant assez pauvre avec une dizaine de templates d'expériences très orientés démo (Podtato-head, Sock shop…), nous partons sur un canevas vierge pour bien appréhender l’ensemble des options mises à notre disposition pour configurer une expérience.

Nous arrivons alors sur le “Chaos Studio” : une interface de type “workflow editor” dans laquelle nous avons la possibilité d’ajouter un premier noeud : 

En cliquant sur “Add”, nous arrivons sur une librairie de défaillances (“faults”). Il y a cette fois un choix très varié :

• Des défaillances spécifiques aux trois grands cloud providers AWS, Azure et GCP.
• Des défaillances VMWare, Spring Boot…
• Une trentaine de défaillances dédiées à Kubernetes.

Chaque composant est associé à une description, ce qui nous permet d’identifier facilement celui qui correspond le mieux à l'expérience que nous souhaitons construire : le pod-memory-hog.

Paramétrage de la défaillance

Une fois notre défaillance pod-memory-hog ajoutée, il nous faut la paramétrer en commençant par cibler l’application dans laquelle l’injecter : 

Un second onglet nous permet de paramétrer les détails. Comme pour notre prise en main de Chaos Mesh, nous décidons de charger la mémoire à la limite, au sens défini dans le déploiement de WordPress (384Mi) pendant une minute.

À noter que là ou Chaos Mesh nous facilitait la vie en proposant des menus déroulants, par exemple pour le choix d’un pod cible, Litmus ne propose que des champs textuels, sans contrôle sur la validité des données saisies.

Ajout d’une sonde

Dernière étape obligatoire avant de pouvoir lancer notre expérience : la configuration d’une sonde (probe). Les sondes permettent d’effectuer des mesures pour évaluer la résilience de notre application ou de notre infrastructure face aux conditions que nous allons lui imposer.

Litmus propose plusieurs types de sondes : 

• HTTP Probe : Vérifie la disponibilité et la réponse des services web
• Command Probe : Permet d'exécuter des commandes shell et de regarder le résultat
• K8s Probe : Vérifie l'état des ressources Kubernetes
• Prometheus Probe : Contrôle les métriques
• Probe chaining : Permet de réutiliser le résultat d’une sonde dans les sondes suivantes (présent dans la documentation mais non dans l’interface - YAML only 🙂)

Dans notre cas et afin d’évaluer la résilience de notre application WordPress, nous décidons de créer une sonde de type HTTP.

Configurer cette sonde est assez simple : 

• Timeout : délai maximum accordé pour qu’une requête HTTP réponde.
• Interval : temps d’attente entre deux exécutions de la probe.
• Attempt : nombre de tentatives pour une exécution donnée avant de déclarer l’échec.
• Polling Interval : fréquence à laquelle la sonde vérifie la condition de succès pendant la durée d’exécution.
• Evaluation Timeout : délai maximum autorisé pour une exécution de la probe.

Il faut ensuite préciser quelle URL doit être utilisée pour le test. Nous donnons l’URL d’accueil de notre WordPress en utilisant la Cluster IP du service associé (La communication se faisant au sein de notre cluster, entre pods litmus et wordpress). Si la page renvoie un code de réponse 200, nous considérons notre sonde en succès.

Enfin, il faut préciser à quelle étape de l'expérience exécuter la sonde :

Nous souhaitons exécuter notre sonde pendant toute la durée de l’expérience. Les options “Continuous” et “On Chaos” nous semblent les plus adaptées, mais la nuance entre les deux nous échappe et la documentation n’offre pas plus de détails. Il est cependant possible de créer plusieurs sondes pour notre défaillance : nous ajoutons donc les deux pour voir ce que cela donne. 

Et c’est parti !

Une fois l'expérience lancée, nous pouvons suivre sa progression de manière visuelle dans le Chaos Center. Les étapes de préparations (install-chaos-fault) et de clean-up (clean-chaos-resources) de l'expérience sont automatiquement incluses dans le workflow.

Pour chaque étape du workflow, il est possible de suivre sa progression, son temps d'exécution et d’afficher les logs associés.

Et là, c’est le drame…

Nous attendons fébrilement le résultat de notre expérience mais celle-ci échoue et c’est le début des problèmes. Il nous a fallu mettre un peu les mains dans le cambouis pour aboutir à un résultat.

Par exemple, le chemin configuré par défaut pour le socket containerd n’était pas le bon pour notre cluster K3s. Un paramètre permettait de le corriger dans l’interface, mais cela n’a pas suffi. En cherchant un peu dans le manifest de l'expérience, il s’est avéré qu’une autre référence au chemin erroné existait et n’était pas corrigée via l’interface…

Avec nos premiers paramétrages, nous avons également été confrontés à des erreurs lors de l'exécution de notre expérience. Par exemple :

Les messages d’erreur nous laissent d’abord circonspects mais la référence à un SIGTERM sur l’un des process nous évoque un problème de ressources. Quelques tâtonnements plus tard, nous trouvons une solution pour nous débarrasser de l’erreur : diminuer la quantité de mémoire visée pour charger le pod MariaDB. C’est ennuyeux car cela va à l’encontre de l’objectif que nous avions fixé pour l'expérience.

Celle-ci va finalement à son terme et nous constatons sur notre dashboard Grafana que l’augmentation de mémoire a bien été injectée dans le pod MariaDB.

L’interface affiche fièrement un score de 100% de résilience pour nos sondes. Ce n’est pas exactement ce à quoi nous nous attendions par rapport aux résultats obtenus lors de notre expérience équivalente avec Chaos Mesh.

À notre sens, l’utilisation des sondes était l’équivalent de notre simulation de trafic effectuée avec K6 lors de nos tests de Chaos Mesh. Nous aurions donc dû constater un nombre important de requêtes en erreur. 

Comment expliquer ces différents problèmes ? Sont-ils liés aux ressources limitées de notre infrastructure ? Notre installation et notre configuration de Litmus était-elle bancale (probable) ? Autant de questions que nous laisserons malheureusement derrière nous faute de temps… Mais c’est aussi ça, la réalité d’un Weckathon ! 😅

Et ces résultats en demi-teinte nous permettent tout de même de tirer quelques enseignements de cette prise en main de Litmus 

Conclusion

Notre essai de Litmus a été intéressant en découverte, autant sur son architecture que sur son fonctionnement, mais nous n’avons pas eu le sentiment d’aboutir à un résultat concret, ni de nous faire une impression concluante sur cet outil. 

L’un de ses atouts indéniables reste la grande variété de scénarios prêts à l’emploi, qui font gagner un temps précieux, ainsi que la fonctionnalité des Probes, très utile pour valider l’exécution des tests. Nous avons toutefois rencontré quelques limites : certains scénarios n’ont pas fonctionné comme prévu, parfois sans retour d’erreur explicite. 

Au final, Litmus nous est apparu comme un outil très complet – peut-être même trop complexe pour les cas simples que nous visions. 

Comparatif

En bonus, voici notre humble comparatif pour cette journée de POC : 

Ce Weckathon nous aura surtout permis de lever un peu le voile sur ces outils de chaos engineering, d’apprendre ensemble et de challenger nos pratiques. Mission accomplie !

Article de Samia Kherrati et Sébastien Henne