Chaos Mesh Kubernetes : Guide avancé 2026

Introduction

Chaos Mesh est la plateforme open-source de référence pour le chaos engineering sur Kubernetes, soutenue par la CNCF. Contrairement à des outils comme Litmus qui se limitent à des scripts, Chaos Mesh offre une API Kubernetes-native avec des CRDs (Custom Resource Definitions) pour modéliser PodChaos, NetworkChaos, StressChaos et plus. En 2026, avec Kubernetes 1.32+, il intègre nativement les eBPF pour des injections précises sans downtime.

Pourquoi l'utiliser ? Dans un monde où 70% des incidents cloud proviennent de dépendances externes (rapport SRE 2025), Chaos Mesh simule pannes, latences et saturations pour valider la résilience. Imaginez votre API e-commerce : un NetworkChaos à 500ms de latence révèle un timeout mal géré. Ce tutoriel avancé couvre le déploiement, des expériences complexes et les workflows, avec des manifests YAML 100% fonctionnels. À la fin, vous bookmarkederez ce guide pour vos CI/CD chaos. (128 mots)

Prérequis

Cluster Kubernetes 1.30+ (Minikube, Kind ou EKS avec 4+ nœuds pour tests avancés)
kubectl 1.30+ configuré
Helm 3.14+
Namespace dédié chaos-testing
Application test : Deployment Nginx simple (exposé via Service)
Accès au Dashboard Chaos Mesh via port-forward

Installation de Chaos Mesh via Helm

install-chaos-mesh.sh

helm repo add chaos-mesh https://charts.chaos-mesh.org
helm repo update
kubectl create namespace chaos-testing
helm install chaos-mesh chaos-mesh/chaos-mesh \
  --namespace=chaos-testing \
  --set chaosDaemon.runtime=containerd \
  --set chaosDaemon.containerRuntime.socketPath=/run/containerd/containerd.sock \
  --set dashboard.create=true \
  --set enableCRD=true

Ce script ajoute le repo Helm officiel, crée le namespace et déploie Chaos Mesh v2.6+ avec ChaosDaemon pour containerd (standard en 2026). Le dashboard est activé pour l'UI web. Piège : vérifiez containerRuntime.socketPath selon votre runtime (CRI-O : /var/run/crio/crio.sock) pour éviter les PodChaos échoués.

Vérification et accès au Dashboard

Appliquez le script ci-dessus, puis kubectl get pods -n chaos-testing pour confirmer les composants : chaos-controller-manager, chaos-daemon et chaos-dashboard. Port-forwardez le dashboard : kubectl port-forward -n chaos-testing svc/chaos-dashboard 2333:2333. Accédez à http://localhost:2333, utilisateur/password : chaos-mesh/123456. L'UI liste les CRDs et permet de visualiser les expériences en temps réel, avec logs et métriques Prometheus intégrées.

Déploiement d'une app test (Nginx)

nginx-app.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-app
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.27-alpine
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
  namespace: default
spec:
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80
  type: ClusterIP

Ce manifest déploie 3 pods Nginx pour simuler une app scalable. Appliquez avec kubectl apply -f nginx-app.yaml. Vérifiez kubectl get pods -l app=nginx. C'est la cible pour tous les Chaos : sélection via labelSelector app=nginx.

PodChaos : Simulation de crash de pods

pod-chaos.yaml

apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: pod-kill-example
  namespace: default
spec:
  action: pod-kill
  mode: one
  selector:
    labelSelectors:
      app: nginx
  scheduler:
    cron: "@every 30s"
  duration: "10s"
  gracePeriod: 0
  replaceWith: "nginx:1.27-alpine"
  direction: forward

Ce PodChaos tue un pod Nginx toutes les 30s pendant 10s, avec replaceWith pour auto-remplacement sans downtime. Mode 'one' cible un seul pod. Surveillez via dashboard : observez le flap et la recovery HPA si configurée. Piège : gracePeriod=0 pour kill hard, sinon SIGTERM lent.

Monitoring du PodChaos

Testez : kubectl apply -f pod-chaos.yaml, puis kubectl get events -l app=nginx. Dans le dashboard, cliquez sur l'expérience : graphiques montrent kill/recovery. Scalez à 3 pods min pour absorber. Analogy : comme un orage qui abat un arbre dans une forêt, testant la redondance.

NetworkChaos : Latence et perte de paquets

network-chaos.yaml

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: network-latency-loss
  namespace: default
spec:
  action: delay
  mode: one
  selector:
    namespaces:
    - default
    labelSelectors:
      app: nginx
  delay:
    latency: "500ms"
    jitter: "100ms"
    correlation: "80%"
  direction: to
  target:
    mode: all
  scheduler:
    cron: "@every 1m"
  duration: "30s"
---
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: network-loss-example
  namespace: default
spec:
  action: partition
  mode: one
  selector:
    labelSelectors:
      app: nginx
  partition:
    exceptions:
      - 172.17.0.0/16
  direction: both
  scheduler:
    cron: "@every 2m"
  duration: "20s"

Deux NetworkChaos : delay simule 500ms latence + jitter (80% corrélé) vers Nginx, partition isole un pod (exceptions IP pour bypass). eBPF sous-jacent pour zero-copy. Dashboard affiche topologie réseau chaotique. Piège : direction 'to' cible outbound depuis pods.

StressChaos : Surcharge CPU/Mémoire

stress-chaos.yaml

apiVersion: chaos-mesh.org/v1alpha1
kind: StressChaos
metadata:
  name: stress-cpu-mem
  namespace: default
spec:
  mode: all
  selector:
    labelSelectors:
      app: nginx
  stressors:
  - containerName: nginx
    cpu:
      workers: 2
      load: 80
    memory:
      workers: 1
      size: "512Mi"
  scheduler:
    cron: "@every 45s"
  duration: "60s"
  force: true

StressChaos injecte 2 workers CPU à 80% load + 512Mi alloc mémoire sur tous pods Nginx. Utilise stress-ng natif. Force=true pour OOMKill si limites pod dépassées. Monitorez kubectl top pods. Piège : alignez workers avec cœurs vCPU pour réalisme.

IOChaos : Chaos disque avec falldisk

io-chaos.yaml

apiVersion: chaos-mesh.org/v1alpha1
kind: IOChaos
metadata:
  name: io-latency-fill
  namespace: default
spec:
  action: latency
  mode: one
  selector:
    namespaces:
    - default
    labelSelectors:
      app: nginx
  volumePaths:
  - /var/cache/nginx
  latency: "2s"
  scheduler:
    cron: "@every 90s"
  duration: "45s"
  force: true
---
apiVersion: chaos-mesh.org/v1alpha1
kind: IOChaos
metadata:
  name: disk-fill
  namespace: default
spec:
  action: fill
  mode: all
  selector:
    labelSelectors:
      app: nginx
  fillPercent: 90
  path: /var/cache/nginx
  scheduler:
    cron: "@every 3m"
  duration: "30s"

IOChaos latency ajoute 2s sur /var/cache/nginx (un pod), fill occupe 90% disque sur tous. falldisk backend pour persistance. Idéal pour DBs StatefulSets. Dashboard trace IOPS drop. Piège : volumePaths doit matcher mounts pod, sinon skip.

Workflows Chaos avancés

Pour enchaîner : créez un ChaosWorkflow combinant PodChaos puis NetworkChaos. kubectl apply un YAML workflow pour séquences conditionnelles (onSuccess/onFailure). Exemple avancé : blast radius limité via namespaceSelector. Intégrez à ArgoCD pour CI chaos.

Exemple ChaosWorkflow séquentiel

chaos-workflow.yaml

apiVersion: chaos-mesh.org/v1alpha1
kind: Workflow
metadata:
  name: sequential-chaos
  namespace: default
spec:
  deadline: 600
  backoffPolicy:
    maxRetries: 3
  tasks:
  - name: pod-kill-task
    type: Task
    spec:
      embeddedChaos:
        spec:
          action: pod-kill
          mode: one
          selector:
            labelSelectors:
              app: nginx
          duration: "10s"
  - name: network-task
    type: Task
    dependencies:
    - pod-kill-task
    spec:
      embeddedChaos:
        spec:
          action: delay
          mode: one
          selector:
            labelSelectors:
              app: nginx
          delay:
            latency: "1s"
          duration: "20s"

Ce Workflow tue un pod, attend recovery, puis injecte latence. Dependencies séquencielle, backoff sur retry. Deadline 10min. Lancez et trackez dans dashboard 'Workflows'. Piège : embeddedChaos doit matcher CRD specs exactes.

Bonnes pratiques

Blast radius contrôlé : Utilisez toujours namespaceSelector et labelSelectors précis ; testez en staging avec AdmissionWebhooks pour auto-approve.
Scheduling avancé : Préférez cron + scheduler.range pour bursts réalistes (ex: pic heure de pointe).
Observabilité : Intégrez Prometheus/Grafana via Chaos Metrics ; exportez vers Steadybit pour SLO.
Rollback safe : Définissez tolerations ChaosDaemon et priorityClass high pour controller.
CI/CD : GitOps avec Flux/ArgoCD appliquant YAMLs conditionnels sur Git tags.

Erreurs courantes à éviter

DaemonSet non-ready : Oublie socketPath runtime → ChaosDaemon pending ; debug kubectl logs -n chaos-testing daemonset/chaos-daemon.
Selector mismatch : Pas de pods matchés → expérience 'Running' mais no-op ; validez kubectl get pods -l app=nginx.
Force=false sans grace : Pods en crashloop après kill ; set force=true pour SIGKILL.
Workflow deadline trop court : Tasks timeout → backoff infini ; scalez à 30min+ pour chains complexes.

Pour aller plus loin

Docs officielles : Chaos Mesh GitHub
Avancé eBPF : Chaos Mesh 2.6+ Features
Intégration Litmus : Migration Guide
Formations expertes : Découvrez nos formations Kubernetes et Chaos Engineering chez Learni pour certifs CNCF CKA+Chaos.

Comment implémenter Chaos Mesh en Kubernetes 2026