Chaos Engineering - Un monde de destruction ?!
Tags: kubernetes, sre, french, devops
Published: 2022-10-18 12:21:08

**Quand on parle de Chaos Engineering et qu'on n'est pas très connaisseur du domaine, ça peut être quelque chose qui peut faire peur.**

> *On a entendu que chez Netflix ils tuaient des noeuds aléatoirement dans leurs clusters de prod!*

La phrase précédente est généralement ce que les gens retiennent d'une petite discussion autour du Chaos Engineering. Et c'est sûr *(plus particulièrement chez des personnes moins techniques)* que c'est quelque chose qui va faire peur.

---

Aujourd'hui, nous allons commencer une discussion autour du Chaos Engineering, ce que c'est, comment l'implémenter sans tuer des clusters en prod et quels outils peuvent vous aider à cela.

*C'est une introduction brève au Chaos Engineering, si vous voulez avoir plus d'informations sur un sujet traité ici, n'hésitez pas à me le faire savoir dans les commentaires. D'autres articles traitant de ces sujets pourront être alors publiés par la suite.*

---

## Origines

Comme on l'a évoqué au début, Netflix en est à l'origine pour **tester leur infrastructure et sa résilience en tuant des instances.**

*Voici le lien vers leur projet et leur documentation.*
[Repo Github](https://github.com/Netflix/chaosmonkey)
[Documentation en ligne](https://netflix.github.io/chaosmonkey/)

De là est né le **Chaos Engineering**.

---

## Chaos Engineering

Tel que définit dans les [**Principes du Chaos Engineering**](https://principlesofchaos.org/):

> **L’Ingénierie du Chaos est une discipline de l’expérimentation sur un système distribué afin de renforcer la confiance dans la capacité du système à résister à des conditions turbulentes en production.**

Avec cette idée, on garde l'état d'esprit de Netflix de vouloir "perturber les instances pour voir ce qu'il se passe et si c'est résilient", mais sans tuer des instances en prod.

L'objectif est alors d'ajouter des perturbations à des moments aléatoires afin de s'assurer que tout continue de fonctionner. On peut alors :
#### - Ajouter de la latence
Ajouter un peu de latence va permettre de s'assurer que tout continuer de fonctionner normalement. Sinon on peut ajouter suffisemment de latence pour dépasser la valeur du timeout défini et voir si le mécanisme de retry fonctionne bien *(si il y en a un)*

#### - Retourner des erreurs http 500
C'est une autre option pour tester le système de retry et s'assurer d'éviter des faux positifs.

#### - Tuer des pods
L'idée ici est de s'assurer que quand un service à au moins 2 pods, si un disparaît, est-ce que la charge est répartie correctement. On peut alors se poser les questions suivantes :
- Est-ce que le trafic est bien balancé parmis les instances restantes?
- Est-ce que la nouvelle instance *(remplaçant celle tuée)* démarre suffisemment vite?
- Est-ce qu'il ne devrait pas y avoir plus d'instances de ce service?

Comme vous pouvez le voir, ce sont des options simples *(beaucoup d'autres existent)*, mais c'est un bon premier pas pour ajouter des perturbations dans le système et s'assurer que c'est résilient.

### En prod ou en non prod?

C'est sûr que si vous voulez **voir ce qu'il se passe avec des cas réels**, et que vous voulez être sûr d'avoir quelque chose qui correspond aux besoins de vos consommateurs, **le faire en prod est la meilleure solution**.

**Mais, tous les systèmes, équipes et compagnies ne sont pas prêtes à faire ça en production!** Alors, ne vous inquiétez pas, vous **pouvez le faire en non production, mais vous DEVEZ avoir ce qu'il faut pour simuler un réel trafic.**

Vous devez avoir vos scénarios de cas **réels** de prêts avec vos outils de tests de charges. Faire juste des GET pour récupérer en boucle tout le temps la même information peut ne pas être suffisant. Des cas réels peuvent mettre votre système dans des situations auxquelles vous n'avez jamais pensé. De facto, ça vous amènera aussi plus de confiance dans les systèmes qui ont été testés avec ces scénarios. 

---

## Comment le tester

Dans cette dernière partie, on va voir quels outils vont vous permettre de l'implémenter et de l'automatiser.

Le premier est peut être un outil que vous utilisez déjà : **Istio**.

*De manière générale, allez vérifier la documentation du service mesh que vous utilisez. Ils peuvent avoir déjà des outils qui vous permettront d'implémenter le Chaos Engineering.*

### Istio
Dans ses fonctionnalités, Istio en possède une s'appelant[**l'Injection de fautes**](https://istio.io/latest/docs/tasks/traffic-management/fault-injection/). Avec cela, vous serez capable d'ajouter du délai sur une partie ou tous les appels à une api
```yaml
  - fault:
      delay:
        fixedDelay: 7s
        percentage:
          value: 100
```
ou de leur retourner directement un code http particulier.
```yaml
  - fault:
      abort:
        httpStatus: 500
        percentage:
          value: 100
```

Donc si vous utilisez déjà cet outil, il ne s'agit que de petites modifications dans les définitions de vos `VirtualService`.

### Chaos Mesh

[**Chaos Mesh**](https://chaos-mesh.org/) est un outil dédié au Chaos Engineering qui fait parti de l'ensemble d'outils du CNCF.

Orienté pour **Kubernetes** et des **noeuds physiques**, il va vous aider à tester un ensemble de scénarios comme : 
- **Soucis de pods**
- **Soucis de réseau**
- **Scénarios de stress**
- **Soucis de DNS**
- **Soucis avec la JVM dans des pods**
- **Soucis de communication avec des fournisseurs d'outils dans le Cloud**
- ...

Avec cela, vous avez de quoi vous assurer que votre cluster Kubernetes est suffisemment résilient.

Mais vous pouvez avoir d'autres outils gravitant autour de votre cluster. Des bases de données, des services de messages...

### Litmus Chaos
Et c'est là où [**Litmus Chaos**](https://litmuschaos.io/) arrives. C'est aussi un projet du CNCF, mais ce projet me semble plus approprié dans des scénarios où votre infrastructure ne comporte pas qu'un cluster Kubernetes.

Tout comme Litmus, il a de nombreuses fonctionnalités permettant de tester un cluster Kubernetes. Mais il a surtout de quoi tester d'autres outils! En effet, il possède des scénarios pour tester **Kafka**, **Cassandra** ou **Core DNS**. Mais aussi des **Cloud providers!** *(AWS, Azure & GCP)*

Présentées comme dans un site d'achat, le [**Hub LitmusChaos**](https://hub.litmuschaos.io/) va vous montrer tout ce qui est possible d'être fait avec.

---

Une chose importante, sachez que ces 3 outils sont open source. Donc si vous voyez des choses qui n'y sont pas, vous voulez ajouter de nouveaux scénarios... ou même poser des questions à la communauté, n'hésitez pas!

---

Comme dit plus tôt, je ne suis pas allé dans le détail des outils, comment ils fonctionnent... Mais si il y a des éléments pour lesquels vous souhaitez plus d'informations, n'hésitez pas à laisser un commentaire pour me le faire savoir.

J'espère que ça vous aidera! 🍺