À la fin de ce tutoriel, vous saurez poser une hypothèse de résilience, borner le blast radius, choisir Litmus ou Chaos Mesh, lancer un pod-delete contrôlé sur un lab Kubernetes, et relier l’expérience à vos SLO — sans casser la prod « pour voir ».

Niveau : Intermédiaire · Temps estimé : 55–75 min · Versions cibles : Kubernetes 1.29+ · LitmusChaos 3.x · Chaos Mesh 2.x · kubectl · AWS CLI v2 · Dernière vérification : 2026-09-11 · Region : ca-central-1

Slug : wow-chaos-engineering-litmus · Série : WOW (29/50) · Mot-clé SEO : chaos engineering litmus · Publish : HOLD

← Précédent : SRE : error budgets et SLOs · → Suivant : Load testing k6 · Aussi : OpenTelemetry · Falco runtime · Incident runbooks

Prérequis

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
kubectl config current-context && kubectl get nodes

Règle d’or : jamais de chaos en production sans hypothèse écrite, abort, fenêtre et rollback. Ce lab cible uniquement chaos-lab.

Ce que nous allons construire

Chaos Engineering (WOW 29/50) — ca-central-1
  ├── Pourquoi casser volontairement
  ├── Hypothèse + SLO + blast radius
  ├── Litmus vs Chaos Mesh
  ├── Lab : demo-api + Litmus pod-delete
  ├── Observer, abort, teardown
  └── Quiz + FAQ + maillage WOW

(Schéma — alt : « Hypothèse SLO, ChaosEngine Litmus sur namespace isolé, métriques, abort si error budget ».)

Étape 1 — Pourquoi le Chaos Engineering en 2026 ?

Un staging « vert » n’est pas résilient. Pannes réelles : nœud spot, AZ ca-central-1a, sidecar, DNS timeout. Attendre l’incident, c’est trop tard.

Le Chaos Engineering est une discipline expérimentale : hypothèse (« si un pod meurt, le Service reste dans le SLO 99,9 % »), faille bornée, mesure, correctif — pas le dashboard.

Ce que c’est Ce que ce n’est pas
Expérience + métriques kubectl delete pod au hasard en prod
Blast radius explicite Tester « tout le mesh » le vendredi 17h
Lié aux SLO Un opérateur de plus « pour le CV »
Game day planifié Chaos 24/7 sans abort

Enjeu SRE 2026 : prouver que HPA, PDB, probes et retry tiennent les runbooks.

Étape 2 — Hypothèse, blast radius, abort

Avant Helm : une fiche. Sinon, du bruit.

  1. Service : demo-api (ns chaos-lab)
  2. Hypothèse : « Si 1 replica sur 3 est tué, p99 < 300 ms pendant 5 min, 0 erreur 5xx client. »
  3. Steady state : 3 replicas Ready, / OK, ~20 RPS lab
  4. Injection : pod-delete, une fois, ~33 %
  5. Blast radius : chaos-lab uniquement — pas kube-system, pas ingress
  6. Abort : error rate > 1 % ou p99 > 800 ms pendant 60 s → stop
  7. Rollback : rollout / scale ; engineState: stop
  8. Obs : Prometheus + logs ; traces si OTel

Sans sélecteur de labels, le ChaosEngine n’est pas ciblé.

apiVersion: v1
kind: ConfigMap
metadata:
  name: chaos-experiment-card
  namespace: chaos-lab
  labels: { deh.lab/region: ca-central-1 }
data:
  hypothesis: "1/3 pods deleted => p99 < 300ms, 0 5xx"
  abort: "error_rate>1% OR p99>800ms for 60s"
  window: "15m"
  owner: "sre-lab"

Étape 3 — Litmus ou Chaos Mesh ?

Deux stacks CNCF — un seul suffit.

Critère LitmusChaos Chaos Mesh
Modèle Experiments + ChaosEngine CRDs (PodChaos, NetworkChaos)
UX Portail + GitOps YAML CRDs très lisibles
Force Catalogue (pod, net, disk, AWS…) Réseau / time / kernel K8s
Courbe Engine + runner Un YAML = une faille
Quand DEH Game days, CI chaos Équipes GitOps-CRD pures

Lab = Litmus. Un seul outil le premier mois, sinon vous ne savez plus qui a tué le pod.

Étape 4 — Lab : demo-api + pod-delete

kubectl create namespace chaos-lab
kubectl label namespace chaos-lab deh.lab/region=ca-central-1 purpose=chaos

# demo-api.yaml
apiVersion: apps/v1
kind: Deployment
metadata: { name: demo-api, namespace: chaos-lab }
spec:
  replicas: 3
  selector: { matchLabels: { app: demo-api } }
  template:
    metadata: { labels: { app: demo-api } }
    spec:
      containers:
        - name: api
          image: hashicorp/http-echo:1.0
          args: ["-text=ok-ca-central-1", "-listen=:8080"]
          ports: [{ containerPort: 8080 }]
          readinessProbe: { httpGet: { path: /, port: 8080 }, periodSeconds: 5 }
          livenessProbe: { httpGet: { path: /, port: 8080 }, periodSeconds: 10 }
          resources:
            requests: { cpu: "20m", memory: "32Mi" }
            limits: { cpu: "100m", memory:  "64Mi" }
---
apiVersion: v1
kind: Service
metadata: { name: demo-api, namespace: chaos-lab }
spec:
  selector: { app: demo-api }
  ports: [{ port: 80, targetPort: 8080 }]

kubectl apply -f demo-api.yaml
kubectl -n chaos-lab rollout status deploy/demo-api

Installez Litmus via le chart officiel litmuschaos (version du jour).

helm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/
helm repo update
helm install chaos litmuschaos/litmus 
  --namespace litmus --create-namespace 
  --set portal.frontend.service.type=ClusterIP
kubectl -n litmus get pods

Portail en port-forward lab. Changez le MDP admin du chart tout de suite.

# pod-delete-engine.yaml — alignez apiVersion/SA sur votre chart
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata: { name: demo-api-pod-delete, namespace: chaos-lab }
spec:
  appinfo:
    appns: chaos-lab
    applabel: "app=demo-api"
    appkind: deployment
  engineState: active
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            - { name: TOTAL_CHAOS_DURATION, value: "30" }
            - { name: PODS_AFFECTED_PERC, value: "33" }
            - { name: FORCE, value: "false" }

kubectl apply -f pod-delete-engine.yaml
kubectl -n chaos-lab get chaosengine,pods -w

Un pod disparaît, le ReplicaSet le recrée. Si l’app casse : probes, PDB, ou singleton — pas Litmus.

kubectl -n chaos-lab run load --rm -it --image=curlimages/curl --restart=Never -- 
  sh -c 'for i in $(seq 1 80); do curl -s -o /dev/null -w "%{http_code}n" http://demo-api/; sleep 0.2; done'

200 + replicas Ready = hypothèse tenue. Timeouts = réfutée (victoire scientifique).

Étape 5 — Observer, abort, post-mortem

  1. Latence / error rate — Prometheus
  2. Retry qui masque un 5xx — OpenTelemetry
  3. Kill hors fenêtre — Falco
  4. Steady state réaliste — k6
kubectl -n chaos-lab patch chaosengine demo-api-pod-delete 
  --type merge -p '{"spec":{"engineState":"stop"}}'
kubectl -n chaos-lab rollout status deploy/demo-api

Post-mortem 10 lignes : résultat, surprise, correctif (PDB, grace, retry), date du re-run.

Palier EKS ca-central-1 : drain / spot sur node group lab, error budget SRE vert — pas le control plane.

Étape 6 — GitOps et anti-patterns

GitOps — Argo CD : engineState: stop par défaut ; active en pipeline lab / game day. Jamais sync prod.

Anti-pattern Pourquoi ça brûle Correction DEH
Chaos prod « pour sensibiliser » Incident + confiance Lab → staging → game day
100 % des pods Plus de quorum 33 % / 1 pod d’abord
Sans SLO Pas de verdict Lier error budget
Chart cluster-wide J1 RBAC flou Namespace + SA dédiés
Portail MDP défaut / LB public Cluster-admin de facto ClusterIP + secret
Oublier le teardown Surprise lundi Job cleanup

Nettoyage (obligatoire)

kubectl -n chaos-lab delete chaosengine demo-api-pod-delete --ignore-not-found
kubectl delete ns chaos-lab
# helm uninstall chaos -n litmus && kubectl delete ns litmus

EKS lab : pas de NAT/ALB « pour le chaos ». Tags Owner / Purpose=lab.

Erreurs fréquentes

Erreur Impact Correction
ChaosEngine sans applabel Tous les pods du ns app=demo-api
1 replica « plus vite » 100 % down 3 replicas min
Probes absentes Traffic vers pod mort readiness + liveness
FORCE=true trop tôt Kill sans graceful false d’abord
Region us-east-1 Dérive lab ca-central-1
Portail LoadBalancer public Compte chaos = cluster ClusterIP + VPN
Confondre chaos et load test Mauvais verdict Charge = k6
Pas d’abort Expérience qui dérive engineState: stop

Quiz (5 questions)

1. Le Chaos Engineering vise surtout à :
– A. Casser la prod pour motiver l’équipe
– B. Valider une hypothèse de résilience (blast radius + métriques)
– C. Remplacer les tests unitaires

2. Litmus vs Chaos Mesh, réflexe DEH :
– A. Installer les deux partout
– B. Un outil, GitOps, namespace isolé
– C. Chaos Mesh en prod, Litmus en local

3. Un pod-delete à 33 % sur 3 replicas devrait :
– A. Couper tout le Service
– B. Laisser le Service répondre si probes + replicas OK
– C. Redémarrer kube-apiserver

4. Region lab DEH :
– A. us-east-1
– B. ca-central-1
– C. eu-west-3

5. Abort typique :
– A. « On verra lundi »
– B. Error rate ou p99 hors SLO pendant N secondes → stop
– C. CPU idle < 50 %

Réponses : 1‑B · 2‑B · 3‑B · 4‑B · 5‑B

FAQ

Chaos Engineering = tests de charge ?

Non. k6 pousse le trafic. Le chaos injecte une faille sous un trafic déjà représentatif.

En production ?

Plus tard : périmètre minuscule, fenêtre, error budget vert, abort. Ce tuto s’arrête au lab.

Litmus suffit-il sans Chaos Mesh ?

Oui pour 90 % des game days (pod, network, io). Chaos Mesh si CRDs ultra-ciblés (time skew, kernel).

Faut-il un EKS dédié ?

Non. kind / k3s suffisent pour pod-delete. EKS ca-central-1 pour node-drain / spot.

Chaos et sécurité ?

Portail + SA = privilèges. NetworkPolicy, RBAC least-privilege, pas d’exposition publique. Falco alerte les kills hors fenêtre.

Lien avec les SLO ?

Hypothèse qui casse le SLO = error budget en laboratoire, moins cher qu’un incident client. Correctif + re-run.

Pour aller plus loin

Maillage série WOW
← Précédent SRE : error budgets et SLOs
→ Suivant Load testing k6
Aussi OpenTelemetry · Falco · k6 · Homelab k3s

Meta publication (SEO)

  • Title SEO : Chaos Engineering avec Litmus et Chaos Mesh (guide FR)
  • Meta description : Chaos Engineering 2026 : hypothèses, blast radius, Litmus vs Chaos Mesh. Lab pod-delete en ca-central-1, abort, FAQ et quiz DEH.
  • Focus keyword : chaos engineering litmus
  • Secondary : litmuschaos, chaos mesh, chaos engineering kubernetes, game day SRE
  • Image : assets/web/devopelastichayway/cover-wow-chaos-engineering-litmus-1200x630.webp (à générer)
  • Catégorie : WOW / SRE · Niveau : Intermédiaire
  • URL cible : https://devopelastichayway.com/tutoriels/wow-chaos-engineering-litmus/
  • Post live : N/A (nouveau) · slug wow-chaos-engineering-litmus · Publish : HOLD (draft only — feu vert Maître requis)

← Catalogue Tutoriels

Pour aller plus loin — hubs live

Retour parcours Catalogue Tutoriels — hub de la série et leçons sœurs.

© 2023 devopelastichayway.com All rights reserved.