LitmusChaos : github.com/litmuschaos/litmus • Page CNCF (Incubating)
Chaos Mesh : github.com/chaos-mesh/chaos-mesh • Page CNCF (Incubating)

Une architecture distribuée sur Kubernetes n’est jamais aussi résiliente que le prétendent ses diagrammes tant qu’elle n’a pas affronté des pannes réelles : perte brutale d’un nœud, latence disque I/O sur le quorum etcd ou PostgreSQL, corruption de paquets TCP entre microservices, dérive d’horloge NTP (Clock Skew) ou éviction OOM en pleine montée de charge.

Dans l’écosystème open-source de la Cloud Native Computing Foundation (CNCF), deux plateformes ont atteint le statut CNCF Incubating et dominent aujourd’hui l’ingénierie du chaos Cloud-Native : LitmusChaos (initialement créé par MayaData / Harness) et Chaos Mesh (forgé par PingCAP pour éprouver la base distribuée TiDB). Bien qu’ils partagent la même finalité : vérifier empiriquement la tenue des SLO sous contrainte : leurs philosophies architecturales diffèrent profondément.

1. Philosophie et Origines : Plateforme SRE Globale vs Chirurgie Kernel/Réseau

LitmusChaos : L’orchestrateur SRE, GitOps et multi-environnement

Conçu autour d’un plan de contrôle centralisé (ChaosCenter), LitmusChaos aborde le Chaos Engineering sous l’angle de la gouvernance SRE de bout en bout :

• Il orchestre des scénarios complexes (basés sur Argo Workflows) combinant des pannes Kubernetes ET des pannes hors-cluster (instances AWS EC2/RDS, GCP, Azure, VMware, Bare-Metal Linux).
• Il place la validation du Steady-State (Probes déclaratives) au cœur même de chaque expérience pour calculer automatiquement un Resilience Score (0 à 100 %) exploitable comme barrière de qualité (Quality Gate) dans un pipeline CI/CD GitLab ou GitHub Actions.

Chaos Mesh : L’injecteur de fautes bas niveau ultra-rapide

Né chez PingCAP pour tester les pires scénarios de corruption sur la base de données distribuée TiDB/TiKV, Chaos Mesh brille par sa profondeur d’injection au niveau du noyau Linux, du système de fichiers et de la pile réseau :

• Son chaos-daemon privilégié manipule directement les cgroups, les namespaces réseau (tc / netem / ipset), FUSE (Filesystem in Userspace) pour injecter des erreurs errno (EIO, ENOSPC) sur des appels système précis, ou encore vdso pour décaler l’horloge système (TimeChaos) d’un conteneur sans affecter le reste du nœud hôte.

2. Comparaison Architecturale des CRDs et du Plan d’Exécution

┌────────────────────────────────────────────────────────────────────────────┐
│                   LITMUSCHAOS (Gouvernance & SLO Probes)                   │
│  ChaosCenter (UI/GitOps) ──▶ ChaosEngine + ChaosExperiment + Probes        │
│                              ├── httpProbe / promProbe (SLO PromQL)        │
│                              ├── k8sProbe  / cmdProbe                      │
│                              └── Calcul automatique du Resilience Score    │
├────────────────────────────────────────────────────────────────────────────┤
│                   CHAOS MESH (Injection Kernel, I/O & Réseau)              │
│  Chaos Dashboard / CRDs  ──▶ Chaos Controller Manager                      │
│                              └──▶ Chaos Daemon (DaemonSet par Nœud)        │
│                                   ├── NetworkChaos (tc / netem / ipset)    │
│                                   ├── IOChaos (FUSE syscall delay / errno) │
│                                   ├── TimeChaos (ptrace / vdso clock skew) │
│                                   └── JVMChaos / KernelChaos (eBPF/slab)   │
└────────────────────────────────────────────────────────────────────────────┘

Tableau comparatif détaillé pour Architectes K8s

3. Exemple concret n°1 : LitmusChaos avec validation SLO PromQL (promProbe)

La force majeure de LitmusChaos réside dans sa capacité à interrompre immédiatement un test (et à faire échouer le pipeline CI/CD) si un indicateur de santé métier viole son budget d’erreur pendant l’injection de panne :

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: payment-api-network-resilience
  namespace: production
spec:
  appinfo:
    appns: "production"
    applabel: "app=payment-api"
    appkind: "deployment"
   engineState: "active"
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-network-latency
      spec:
        probe:
          - name: "verify-p99-latency-slo"
            type: "promProbe"
            mode: "Continuous"
            runProperties:
              probeTimeout: 5s
              interval: 10s
              retry: 1
              stopOnFailure: true # Coupe immédiatement le chaos si le SLO tombe !
            promProbe/inputs:
              endpoint: "http://prometheus-server.monitoring.svc:80"
              query: "histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket{app='payment-api'}[1m])) by (le))"
              comparator:
                type: "float"
                criteria: "<="
                value: "0.250" # SLO : P99 <= 250ms malgré 100ms de latence injectée sur un réplica
        components:
          env:
            - name: NETWORK_INTERFACE
              value: "eth0"
            - name: NETWORK_LATENCY
              value: "100" # ms
            - name: TOTAL_CHAOS_DURATION
              value: "120" # secondes
            - name: PODS_AFFECTED_PERC
              value: "50"

4. Exemple concret n°2 : Chaos Mesh pour simuler une panne disque EIO et un décalage d’horloge (TimeChaos)

Lorsqu’il s’agit de vérifier qu’un cluster de base de données (PostgreSQL Patroni, TiDB, Etcd, Raft) ou un système d’authentification JWT/OIDC survit à une corruption disque partielle ou à une dérive NTP de 5 minutes sur un seul Pod, Chaos Mesh est imbattable en quelques lignes de YAML :

apiVersion: chaos-mesh.org/v1alpha1
kind: IOChaos
metadata:
  name: postgres-wal-io-errno
  namespace: database
spec:
  action: fault
  mode: one
  selector:
    namespaces:
      - database
    labelSelectors:
      app.kubernetes.io/name: postgresql
  volumePath: /var/lib/postgresql/data
  path: "/var/lib/postgresql/data/pg_wal/**/*"
  errno: 5 # EIO (Input/Output error) injecté au niveau syscall !
  percent: 25
  methods:
    - write
    - fsync
  duration: "90s"
---
apiVersion: chaos-mesh.org/v1alpha1
kind: TimeChaos
metadata:
  name: auth-service-clock-skew
  namespace: security
spec:
  mode: one
  selector:
    namespaces:
      - security
    labelSelectors:
      app: oidc-provider
  timeOffset: "-5m" # Décalage temporel isolé au conteneur (sans toucher à l'horloge du Node Linux)
  clockIds:
    - CLOCK_REALTIME
  duration: "3m"

5. Verdict : Lequel choisir pour votre infrastructure ?

1. Choisissez LitmusChaos si vous construisez une pratique SRE transversale à l’échelle d’une organisation : vous avez besoin d’un portail unifié (ChaosCenter), de l’intégration native des SLO Probes PromQL/HTTP qui calculent un score de résilience auditable dans vos pipelines GitLab/GitHub, et vos scénarios débordent au-delà de Kubernetes (VM Linux, services managés AWS/Azure/GCP).
2. Choisissez Chaos Mesh si votre priorité est le test de résilience chirurgical 100 % Kubernetes pour des systèmes distribués critiques (bases de données, files de messages, opérateurs, stockage distribué) nécessitant des injections de fautes au niveau noyau, système de fichiers (IOChaos), horloge (TimeChaos), HTTP L7 ou bytecode JVM avec une empreinte opérationnelle minimale.

Liens officiels à conserver dans vos favoris SRE

• LitmusChaos : GitHub (litmuschaos/litmus) • Page CNCF Officielle • Documentation
• Chaos Mesh : GitHub (chaos-mesh/chaos-mesh) • Page CNCF Officielle • Documentation