Chaos Mesh vs. Litmus: Chaos Engineering für Kubernetes im Vergleich 2026

Chaos Mesh und Litmus sind führende Open-Source-Tools für Chaos Engineering auf Kubernetes. Welches Tool passt besser für Resilienz-Tests in Produktionsumgebungen?

Chaos Engineering ist die Praxis, absichtlich Fehler in ein System einzuschleusen, um dessen Resilienz zu testen. Für Kubernetes-Umgebungen haben sich zwei Open-Source-Tools als de-facto-Standards etabliert: Chaos Mesh von PingCAP und Litmus Chaos (heute LitmusChaos), ein CNCF-Incubating-Projekt. Beide ermöglichen kontrollierte Chaos-Experimente – von Pod-Kills bis zu Netzwerkpartitionen –, unterscheiden sich jedoch in Architektur, Funktionsumfang und Bedienbarkeit erheblich.

Chaos Engineering wird in der Praxis oft vernachlässigt, obwohl komplexe verteilte Systeme ohne regelmäßige Resilienz-Tests unberechenbar reagieren können. Ein Produktionsausfall lässt sich am besten durch kontrollierte Experimente in Staging- oder sogar Produktionsumgebungen vorbeugen.

Was ist Chaos Mesh?

Chaos Mesh ist ein Open-Source-Chaos-Engineering-Framework für Kubernetes, das 2019 von PingCAP entwickelt und 2020 an die CNCF übergeben wurde (heute CNCF Graduated Project). Es bietet eine breite Palette an Chaos-Experimenten und eine webbasierte Benutzeroberfläche, über die auch Nicht-Entwickler Chaos-Workflows definieren und visualisieren können.

Kernfeatures von Chaos Mesh:

Pod-Chaos: Pod-Kills, Crashes, Container-Failures
Network-Chaos: Latenzen einschleusen, Paketverlust simulieren, Netzwerkpartitionen erzeugen
I/O-Chaos: Disk-Fehler, I/O-Latenzen und Fehlerinjektionen in Dateisystemoperationen
Stress-Chaos: CPU- und Memory-Stress auf Pods und Nodes
HTTP-Chaos: HTTP-Request/Response-Manipulation
TimeChaos: Systemuhrmanipulation
Chaos-Workflows: Parallele und sequenzielle Experiment-Ketten
Web-Dashboard (Chaos Dashboard) mit Experiment-Visualisierung und Event-Timeline

# Chaos Mesh: Netzwerklatenz auf einen Service einschleusen
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: network-delay-example
  namespace: default
spec:
  action: delay
  mode: one
  selector:
    namespaces:
      - default
    labelSelectors:
      "app": "myapp"
  delay:
    latency: "100ms"
    correlation: "25"
    jitter: "0ms"
  duration: "5m"

Was ist LitmusChaos?

LitmusChaos (ehemals Litmus) ist ein CNCF-Incubating-Projekt, das von MayaData (heute DataCore) entwickelt wurde. Im Gegensatz zu Chaos Mesh verfolgt Litmus einen stärker deklarativen, GitOps-freundlichen Ansatz: Chaos-Experimente werden als ChaosExperiment-CRDs definiert und über ChaosEngines ausgeführt.

Litmus 3.x (LitmusChaos) hat eine vollständige Überarbeitung erhalten, mit einem zentralen Control Plane (Litmus Portal) und einer umfangreichen Bibliothek vorgefertigter Chaos-Experimente im ChaosHub.

Kernfeatures von LitmusChaos:

ChaosHub: Bibliothek von ~200 vordefinierten Chaos-Experimenten
Resilience Score: Automatische Bewertung der System-Resilienz nach Experimenten
ChaosWorkflows: Komplexe Experiment-Pipelines mit Bedingungen und Rollbacks
Integrierter Observability-Support (Prometheus-Metriken, Grafana-Dashboards)
Multi-Tenant-Support mit feingranularer Zugriffskontrolle
GitOps-Integration: Experimente als YAML in Git versionieren
API-first Design für CI/CD-Integration

# LitmusChaos: Pod-Delete-Experiment
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: pod-delete-engine
  namespace: default
spec:
  appinfo:
    appns: "default"
    applabel: "app=myapp"
    appkind: "deployment"
  engineState: "active"
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: "60"
            - name: CHAOS_INTERVAL
              value: "10"
            - name: FORCE
              value: "false"

Architektur-Vergleich

Chaos Mesh: Daemon-basierte Fehlerinjektion

Chaos Mesh nutzt DaemonSets, die auf jedem Kubernetes-Node laufen und direkte Fehlerinjektionen auf Kernel-Ebene ermöglichen (via cgroups, iptables, tc). Experimente werden als Custom Resources definiert, ein dedizierter Controller verarbeitet sie.

Chaos Mesh Controller Manager
        │
        ├── chaos-daemon (DaemonSet, ein Pod pro Node)
        │       └── Kernel-level Chaos (network, io, stress)
        └── chaos-daemon-manager
                └── CRD-Controller (verarbeitet ChaosXxx-Objekte)

Der DaemonSet-Ansatz ermöglicht präzise Fehlerinjektionen direkt auf Node-Ebene, erfordert aber erhöhte Privilegien (privileged mode für den Daemon).

LitmusChaos: Operator + Experiment-Pods

Litmus startet für jedes Chaos-Experiment einen temporären ChaosRunner-Pod, der das eigentliche Experiment als Kubernetes-Job ausführt. Der Chaos-Operator überwacht ChaosEngine-Objekte und startet die entsprechenden Experimente.

Chaos Operator (Deployment)
        │
        ├── ChaosEngine (CRD) → erstellt ChaosRunner-Pod
        │       └── Experiment-Job (kuberenetes-argo-workflow)
        └── Litmus Portal (Control Plane, optional)
                └── Multi-Cluster-Management, UI, API

Der Job-basierte Ansatz ist weniger invasiv als Chaos Meshs DaemonSets, aber auch weniger flexibel bei Low-Level-Fehlerinjektionen.

Feature-Vergleich

Feature	Chaos Mesh	LitmusChaos
Netzwerk-Chaos	✅ Umfangreich (Latenz, Loss, Partition)	✅ Gut
I/O-Chaos	✅ Stark (kernel-level)	✅ Verfügbar
HTTP-Chaos	✅ Request/Response-Manipulation	⚠️ Eingeschränkt
Zeitmanipulation	✅ TimeChaos	⚠️ Begrenzt
Vorgefertigte Experimente	⚠️ Wenige	✅ ~200 im ChaosHub
Resilience Score	❌ Nein	✅ Automatisch
GitOps-Integration	⚠️ Manuell	✅ Nativ
Multi-Cluster	⚠️ Manuell	✅ Nativ (Portal)
Web-UI	✅ Chaos Dashboard	✅ Litmus Portal
CNCF-Status	Graduated	Incubating

Observability-Integration

Beide Tools lassen sich in gängige Monitoring-Stacks integrieren, unterscheiden sich aber in der Tiefe.

Chaos Mesh: Exportiert Metriken über Prometheus und bietet Event-Timeline im Dashboard. Für Grafana stehen Community-Dashboards zur Verfügung, die Chaos-Events mit Metriken korrelieren.

LitmusChaos: Bietet einen nativen Prometheus-Exporter und vorgefertigte Grafana-Dashboards. Der Resilience Score ermöglicht es, die Gesundheit des Systems nach jedem Experiment zu quantifizieren – ein einzigartiges Feature, das in Chaos Mesh fehlt.

# LitmusChaos Resilience Score nach Experiment abfragen
curl -X GET   "http://litmus-portal.example.com/api/chaos/workflow/runs?id=<workflow-id>"   -H "Authorization: Bearer <token>"
# → {"resiliencyScore": 87.5, "passed": 7, "failed": 1}

CI/CD-Integration

Chaos Engineering entfaltet seinen vollen Nutzen erst im CI/CD-Kontext – automatisierte Chaos-Tests als Teil der Pipeline, bevor Code in Production geht.

Chaos Mesh in GitHub Actions:

- name: Run Chaos Test
  run: |
    kubectl apply -f chaos-experiment.yaml
    sleep 300
    kubectl get networkchaos network-delay-example -o json |       python3 -c "import json,sys; d=json.load(sys.stdin); print('OK' if d['status']['experiment']['desiredPhase'] == 'Stop' else 'FAILED')"

LitmusChaos bietet eine dedizierte CLI (litmusctl) und GitHub Actions-Workflows, die sich direkt mit dem Litmus Portal verbinden und Resilienz-Scores als Pipeline-Gate nutzen.

Wann solltest du Chaos Mesh wählen?

Chaos Mesh eignet sich besonders wenn:

Du präzise, low-level Fehlerinjektionen auf Kernel-Ebene benötigst
HTTP-Chaos (Request-/Response-Manipulation) wichtig ist
Du keine zentrale Control Plane benötigst und einfaches CRD-Deployment bevorzugst
Zeitmanipulation (TimeChaos) ein Anforderung ist
Du ein CNCF Graduated Project bevorzugst

Wann solltest du LitmusChaos wählen?

LitmusChaos ist die bessere Wahl wenn:

Du vorgefertigte Chaos-Experimente aus dem ChaosHub nutzen möchtest
Resilience Scoring für automatische Bewertungen wichtig ist
GitOps-Integration mit YAML-versionierten Experimenten benötigt wird
Du Multi-Cluster-Management über das Litmus Portal bevorzugst
CI/CD-Integration über litmusctl oder die API geplant ist

Fazit

Chaos Mesh und LitmusChaos sind beide hervorragende Tools für Chaos Engineering auf Kubernetes, ergänzen sich aber in ihren Stärken. Chaos Mesh überzeugt durch seine Tiefe bei Netzwerk- und I/O-Chaos sowie HTTP-Manipulation auf Kernel-Ebene. LitmusChaos punktet mit dem ChaosHub, nativem Resilience Scoring und starker GitOps-Integration.

Für Teams, die mit einer Bibliothek vorgefertigter Experimente starten wollen und Resilience-Scores als objektive Metrik benötigen, ist LitmusChaos die bessere Wahl. Für Teams, die maximale Kontrolle über die Fehlerinjektion auf niedriger Ebene brauchen, ist Chaos Mesh vorzuziehen. In der Praxis sind beide Tools kombinierbar.