19/03/2020 - Akram RIAHI

devops

Le guide de Chaos Engineering : Partie 2

Sommaire

1. Introduction

Introduction

Nous avons vu dans la première partie du guide du Chaos Engineering (CE) que le CE ne peut pas avoir lieu sans expérimentations.

Nous allons continuer notre voyage fantastique dans ce monde en passant par le pays du "Chaos Tools Country".

Dans cette partie de l’histoire, je vais vous parler des outils de Chaos Engineering, très nombreux aujourd’hui. On peut les différencier selon un certain nombre de critères :

les actions de chaos,
l'accès à ces outils (Open source, libre, propriétaire),
leurs communautés,
l'environnement d’application.

1- Les outils Open Source de Chaos Engineering

Les tests de chaos diffèrent d'un environnement à un autre : machines virtuelles, conteneurs (Docker, Kubernetes, OpenShift...), cloud (Openstack, Azure, AWS, GCP...).
Avant de commencer les tests avancés sur les systèmes, on peut effectuer quelques expérimentations simples de chaos. Comme on dit, on commence petit:

Epuisement de ressources

On sait que les ressources des machines virtuelles et des conteneurs sont limitées. Ces hosts peuvent atteindre le seuil de leur capacité à un moment donné. Dans ce cas, le système doit gérer l'absence de ressources (CPU, RAM...).
Alors, on peut créer des scripts pour engendrer l'épuisement du processeur. Ce test consiste à consommer des cycles de processeurs, laissant l'application avec le même nombre de tâches en relation avec le client et moins de CPU/RAM pour les faire.

Les réactions courantes de l'épuisement du processeur sont une augmentation des erreurs, de la latence donc une réduction des demandes réussies des clients. Dans ce cas, on obtient "unexpected fallback behaviour".

Saturation des sources de données

La gestion de la relation entre les applications et les bases de données est importante pour assurer le bon fonctionnement du système. Il existe plusieurs méthodes pour stresser cette relation en envoyant par exemple des requêtes médiocres, remplissant le cache et injectant de la latence dans les sources de données.
On pourra utiliser des commandes comme:
dd if=/dev/urandom of=/burn bs=1M count=65536 iflag=fullblock &
cette commande permet de convertir et copier des fichiers.

Réduire la fiabilité du réseau

Comme on sait que tout système distribué est caractérisé par des dépendances réseaux, ces dernières permettent la connexion entre les applications. Elles peuvent être internes ou externes. Là, on peut commencer par injecter de la latence réseau en utilisant tc:
tc qdisc add dev eth0 root netem delay 50ms
et parmi les bonnes pratiques de chaos engineering qu’on doit connaitre comment revenir à l’état stable d’ou:
tc qdisc del dev etho root netem delay 50ms
cette commande permet de contrôler le trafic réseaux.

Les outils existants (les plus utilisés)

La communauté du Chaos Engineering est très active. Chaque jour, on trouve de nouveaux outils créés par cette communauté.
Je vais citer les outils les plus utilisés sur les machines virtuelles, conteneurs et cloud providers dont certains sont bien expliqués à la suite :

2- Les outils à utiliser sur machines virtuelles et Kubernetes

Dans cette partie, je vais parler des différents outils que j'utilise pour créer du chaos sur une architecture distribuée de micro-services implémentée sur machines virtuelles et Openshift, en commençant par VMs :

ChaosToolkit

Il s'agit d'un outil open source avec la licence Apache2 exposant des plugins pouvant s'intégrer avec Spring Driver. Il est installé dans un environnement Python 3.5+.
Il est caractérisé par sa simplicité d'intégration dans le système :
Expose une API pour manipuler les expérimentations de chaos engineering.
Extensible puisqu'il peut être utilisé avec des drivers différents (AWS,Spring Driver, K8S,Azure ...) à travers Open API.
Simple car il suffit de manipuler les fichiers XML des micro-services.
Automatisable via une chaîne de CI/CD.
Permet l'activation et la configuration de plusieurs attaques de chaos sur un service spécifique (créer de la latence, tuer des instances, générer des exceptions..).

Chaos Monkey sur Spring Boot

Il s'agit d'un outil open source implémenté pour attaquer les applications s'exécutant sur Spring Boot.
Il est inspiré de "principals of chaos engineering".
Il s'agit d'une librairie qu'on peut intégrer comme une dépendance au niveau des applications ou micro-services.
Une version de l’outil Chaos Monkey est disponible par version Spring Boot.
Facile à configurer pour l’activer/désactiver et personnaliser les attaques.
Il peut générer plusieurs types d'anomalies telles que :
Latence : il peut par exemple, ajouter de la latence de manière aléatoire sur les requêtes.
Exceptions lors de l'exécution : il injecte des exceptions lors de l'exécution (run). Ces exceptions peuvent être configurés pour qu'elles deviennent aléatoires.
Fin d’une application ou d’un micro-service : Appkiller, qui consiste à détruire la totalité de service.

Chaos HTTP proxy

Il s'agit d'un outil open source pour générer des échecs dans les requêtes HTTP à travers un serveur proxy. Il a été inspiré de Chaos Monkey.
Il change les en-têtes HTTP.
Il génère un timeout côté client et serveur.
Il peut générer des erreurs 500, 503 et 504.
Il peut aussi générer des corruptions au niveau de la réponse et des requêtes du content-md5.
Il est lancé à partir de son jar exécutable.

Vaurien

Il s'agit d'un proxy TCP permettant de simuler le chaos entre les micro-services et les serveurs.
Il peut être utilisé avec des VMs.
Il consiste à lire les données qui lui sont envoyées et les transmet à un backend.
Il utilise plusieurs protocoles tels que : HTTP, TCP ...

Vaurien est caractérisé par une classe appelée Behaviors, qui est invoquée à chaque fois qu'il s'exécute sur une requête. Par l'intermédiaire de cette classe, on pourra modifier le comportement du proxy, par exemple, en ajoutant de la latence au niveau d'une requête.
Les protocoles et Behaviors sont des plugins de Vaurien qui permettent d'en ajouter d'autres. En outre, Vaurien expose des APIs pour changer le Behavior du proxy.

On commence par exemple par ajouter une latence par cette API et on regarde comment l'application web réagit.

Muxy

Il s'agit d'un proxy open source qui simule les événements réels et d'échecs sur des systèmes distribués en s'intégrant au niveau des couches 4, 5 et 7 du modèle OSI. Il exécute des scénarios d'échecs d'API et des applications web en cours d'exécution.
Il s'intègre avec les interfaces réseaux du système et il ne peut pas être exécuté en même temps que d'autres tests. C'est pour cela qu'on doit l'implémenter avec une seule VM pour éviter la perte de connexion.
Il est caractérisé par son architecture modulaire, extensible et une installation simple (installation d’un binaire et sans dépendances).

Pumba

Il s'agit d'un outil open source pour créer du chaos uniquement sur des containers Docker (latence, kill, pause...).

Gremlin

C’est une plateforme de "Resilience As A service", qui peut générer plusieurs attaques de chaos. Elle permet de créer des templates d'attaques et de voir les rapports de ces attaques.

Chaos sur Kubernetes

Kaos (Kinda Chaos Monkey for Kubernetes) : il s'agit d'un outil open source qui est compatible seulement avec Kubernetes. Il est basé sur CRD (Custom Resource Definition).

Kube-monkey : il s'agit d'un outil open source, c’est une implémentation de Chaos Monkey de Netflix pour les clusters Kubernetes. Il est développé avec le client-go v7.0 de Kubernetes. Il supprime aléatoirement des pods dans un cluster. Il est exécuté à une date pré-configurée et il crée un plan horaire de déploiements qui vont perdre des pods. Il peut être configuré avec une liste de namespaces, par exemple : blacklisted namespace, c'est-à-dire qu’aucun déploiement dans ce namespace ne sera affecté. Pour pouvoir exécuter Kube-monkey sur des Kubernetes apps, ll faut positionner des labels sur les applications Kubernetes tels que : kube-monkey/enables, kube-monkey/mtbf, kube-monkey/identifier, kube-monkey/kill-mode.

Monkey-ops : il est utilisé avec Openshift 3.X. Son rôle est de jouer aléatoirement avec les pods et deployment Config (supprime des pods et scale-up and down les dcs).

Quels sont les facteurs à avoir en tête pour implémenter du chaos sur des VMs et Kubernetes :

VMs

Diversité des outils : Les outils de chaos sont nombreux. C'est pour cela qu'on doit bien choisir ceux qui correspondent à nos besoins.
Complexité de configuration : cela dépend des compétences existantes.
La sécurité : l'ajout des dépendances au niveau de POM.xml représente un risque. Cela peut aussi avoir un impact sur des dépendances éventuelles, avec des régressions ou conflits. En effet, l'ajout d'une librairie externe doit être vérifiée avant la mise en production. Il faut vérifier que la librairie ne présente pas des failles de sécurité et de performances. .
Le coût : l'utilisation des VMs est coûteuse en terme de temps pour la configuration, notamment par l'ajout de librairie, l'injection à travers des gestionnaires des APIs : Postman.
Provisionnement des nouvelles VMs pour des outils de chaos qui nécessitent une configuration bien spécifique.
L'intégration des librairies de chaos dans les micro-services nécessite une configuration qui se fait au niveau du code.

Kubernetes

Diversité des outils: le chaos engineering sur les micro-services sur kubernetes est plus flexible en terme d'outils :
chaos sur les containers (Docker par exemple) : Pumba...
chaos sur les pods : monkey-ops, kube-monkey, pod-reaper,kaos...
Complexité de configuration: Cela dépend surtout des compétences existantes.
Sécurité: Certains outils ne peuvent pas être utilisés dans Kubernetes pour des raisons de sécurité.
Exemple : Pumba, puisqu'il demande le mount sur /var/run/docker.sock. En effet, l'accès sur /var/run/docker.sock se fait par le root sur les hosts où le Docker Engine est installé. Cela permet aussi à Pumba de pouvoir interagir avec l’ensemble des containers démarrés sur cet hôte, que ce soit pour les piloter, ou se connecter dessus.
le coût : L'utilisation de chaos sur Kubernetes est plus simple : on utilise des pods (créés par des templates, par exemple) et des images de containers . Cela peut se faire par un simple clic depuis la GUI.
Si un outil nécessite d'être installé à part, on peut le mettre dans un pod au lieu d'une machine virtuelle qui consomme beaucoup plus de ressources mais cela dépend toujours des cas.

Par exemple, on peut injecter de la latence dans un cluster Kubernetes en utilisant PUMBA:

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: pumba
spec:
  template:
    metadata:
      labels:
        app: pumba
      name: pumba
    spec:
      containers:
      - image: docker-registry.default.svc:5000/dvs-devops-groupe-none-hors-prod/pumba:master
        imagePullPolicy: Always
        name: pumba
        command: ["pumba"] 
        args: ["--random", "--debug", "--interval", "30s", "kill", "--signal", "SIGKILL", "re2:.*hello.*"]
        securityContext:
          runAsUser: 0
        volumeMounts:
          - name: dockersocket
            mountPath: /var/run/docker.sock
      volumes:
        - hostPath:
            path: /var/run/docker.sock
          name: dockersocket

Pour rappel et comme expliqué plus haut l’utilisation de pumba crée des failles de sécurité.

Conclusion

Après cette lecture, vous aurez pu remarquer que les outils de CE sont très nombreux. Le choix de ces derniers dépend de plusieurs paramètres, de vos besoins, par exemple vous n’utiliserez pas les mêmes pour Kubernetes ou des VMs.
La troisième partie de ce guide est en cours d’écriture, on vous y présentera une démo de chaos engineering. Stay tuned!

Des liens utiles:
Chaos sur les VMs :
On peut utiliser les scripts : saturation du disque, latence au niveau réseau, charge sur les CPUs.

Dans le cas où les micro-services sont sur des VMs : on peut utiliser Chaos Toolkit, Chaos Monkey for Spring Boot...
Vaurien fait partie des proxy permettant de simuler de chaos entre application et son serveur backend. Il est bien expliqué dans la partie ‘les outils à utiliser sur VMs et Kubernetes’ de cet article.
Muxy similaire à Vaurien mais plus adapté pour des systèmes distribués.
Chaos HTTP Proxy.
Gremlin (outil payant).
Cthulhu-chaos-engineering tool.

Chaos sur les containers :

Chaos sur les clouds :

PowerfulSeal.
ChaosToolkit.
GomJabbar - Chaos Monkey for your private cloud.
Chaos Monkey on AWS (on a plusieurs outils à disposition, on cite par exemple : https://github.com/artilleryio/chaos-lambda.git).
Chaos Gorilla et Chaos Kong.