TL;DR

LitmusChaos ist ein Open-Source-Framework für Chaos Engineering auf Kubernetes. Du definierst Experimente als Custom Resources — Pod-Delete, Netzwerk-Latenz oder Node-Drain — und validierst mit Steady-State-Hypothesen, ob deine Anwendung resilient ist. Litmus liefert vorgefertigte Experimente und ein Dashboard zur Auswertung.

Chaos Engineering mit LitmusChaos

Du weißt erst, ob deine Anwendung ausfallsicher ist, wenn du den Ausfall tatsächlich provozierst. Chaos Engineering macht genau das — kontrolliert und reproduzierbar. LitmusChaos ist das CNCF-Projekt, das Chaos-Experimente als native Kubernetes-Ressourcen bereitstellt.

Warum Chaos Engineering?

Kubernetes verspricht Self-Healing: Pods werden neu gestartet, Deployments rollen aus, Nodes werden ersetzt. Aber funktioniert das auch, wenn drei Pods gleichzeitig sterben? Oder wenn die Netzwerk-Latenz zwischen Services auf 500ms steigt?

Ohne Tests sind das Annahmen. Chaos Engineering macht daraus verifizierte Fakten.

Litmus installieren

Litmus 3.x besteht aus einer Control Plane (ChaosCenter) und Agents, die Experimente im Cluster ausführen.

# Namespace erstellen
kubectl create namespace litmus

# Litmus via Helm installieren
helm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/
helm repo update

helm install chaos litmuschaos/litmus \
  --namespace litmus \
  --set portal.frontend.service.type=ClusterIP \
  --set portal.server.service.type=ClusterIP

Warte bis alle Pods laufen:

kubectl get pods -n litmus -w

Das ChaosCenter erreichst du per Port-Forward:

kubectl port-forward svc/chaos-litmus-frontend-service -n litmus 9091:9091
# Browser: http://localhost:9091
# Login: admin / litmus

Kernkonzepte

Litmus arbeitet mit drei zentralen Custom Resources:

Der Ablauf: Du erstellst ein ChaosExperiment, bindest es per ChaosEngine an deine Anwendung und Litmus erzeugt automatisch ein ChaosResult.

Experiment 1: Pod Delete

Das einfachste und wichtigste Experiment — überlebt deine Anwendung den Verlust eines Pods?

Zuerst brauchen wir eine Zielanwendung:

kubectl create deployment nginx-app --image=nginx --replicas=3
kubectl expose deployment nginx-app --port=80

Dann das ChaosExperiment und die ChaosEngine:

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: nginx-pod-delete
  namespace: default
spec:
  appinfo:
    appns: default
    applabel: "app=nginx-app"
    appkind: deployment
  engineState: active
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: "30"
            - name: CHAOS_INTERVAL
              value: "10"
            - name: FORCE
              value: "false"
            - name: PODS_AFFECTED_PERC
              value: "50"

kubectl apply -f pod-delete-engine.yaml

Litmus löscht jetzt 50% der Pods alle 10 Sekunden, 30 Sekunden lang. Beobachte das Verhalten:

# Experiment-Status verfolgen
kubectl get chaosengine nginx-pod-delete -w

# Pods beobachten
kubectl get pods -l app=nginx-app -w

Ergebnis auswerten

kubectl get chaosresult nginx-pod-delete-pod-delete -o jsonpath='{.status.experimentStatus.verdict}'

Ein Pass bedeutet: Die Anwendung hat den Pod-Verlust überlebt. Bei Fail gab es Probleme — etwa weil das Deployment zu wenig Replicas hatte oder die Readiness-Probes falsch konfiguriert waren.

Experiment 2: Netzwerk-Latenz

Realitätsnäher als Pod-Löschung: Was passiert, wenn die Latenz zwischen Services steigt?

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: nginx-network-latency
  namespace: default
spec:
  appinfo:
    appns: default
    applabel: "app=nginx-app"
    appkind: deployment
  engineState: active
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-network-latency
      spec:
        components:
          env:
            - name: NETWORK_INTERFACE
              value: "eth0"
            - name: NETWORK_LATENCY
              value: "500"
            - name: TOTAL_CHAOS_DURATION
              value: "60"
            - name: CONTAINER_RUNTIME
              value: "containerd"
            - name: SOCKET_PATH
              value: "/run/containerd/containerd.sock"

Dieses Experiment fügt 500ms Latenz auf eth0 hinzu — für 60 Sekunden. Timeouts, Retries und Circuit Breaker deiner Anwendung werden damit auf die Probe gestellt.

Experiment 3: Node Drain

Simuliert den Ausfall eines Worker-Nodes:

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: node-drain-chaos
  namespace: default
spec:
  appinfo:
    appns: default
    applabel: "app=nginx-app"
    appkind: deployment
  engineState: active
  chaosServiceAccount: litmus-admin
  experiments:
    - name: node-drain
      spec:
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: "60"
            - name: TARGET_NODE
              value: "worker-node-01"

Hier wird der Ziel-Node gecordoned und gedrained. Kubernetes sollte die Pods auf andere Nodes verschieben. Achte auf Pod Disruption Budgets — ohne PDB kann es zu Downtime kommen.

Steady-State-Hypothese

Chaos Engineering ohne Hypothese ist nur Zerstörung. Definiere vorher, was "normal" bedeutet:

• HTTP-Erfolgsrate bleibt über 99%
• P95-Latenz bleibt unter 200ms
• Keine 5xx-Fehler während des Experiments

Litmus unterstützt Probes, die das automatisch prüfen:

experiments:
  - name: pod-delete
    spec:
      probe:
        - name: check-frontend-access
          type: httpProbe
          httpProbe/inputs:
            url: "http://nginx-app.default.svc:80"
            method:
              get:
                criteria: ==
                responseCode: "200"
          mode: Continuous
          runProperties:
            probeTimeout: 5s
            retry: 3
            interval: 5s

Diese HTTP-Probe prüft während des gesamten Experiments, ob der Service erreichbar bleibt. Fällt die Probe, wird das Experiment als Fail gewertet.

Chaos in die CI/CD-Pipeline integrieren

Chaos-Experimente gehören in die Pipeline — nicht nur als manuelle Ad-hoc-Tests. Ein einfacher Ansatz mit GitHub Actions:

# .github/workflows/chaos-test.yaml
name: Chaos Test
on:
  schedule:
    - cron: "0 4 * * 1"  # Montags um 04:00 UTC
jobs:
  chaos:
    runs-on: self-hosted
    steps:
      - name: Run Pod Delete Experiment
        run: |
          kubectl apply -f chaos/pod-delete-engine.yaml
          sleep 60
          RESULT=$(kubectl get chaosresult -o jsonpath='{.items[0].status.experimentStatus.verdict}')
          if [ "$RESULT" != "Pass" ]; then
            echo "Chaos experiment failed!"
            exit 1
          fi

Troubleshooting

ChaosEngine bleibt auf initialized:

# RBAC prüfen — der ChaosServiceAccount braucht ausreichende Rechte
kubectl get clusterrolebinding | grep litmus
kubectl logs -n litmus -l app.kubernetes.io/component=experiment

Node-Drain-Experiment schlägt fehl:

Der ServiceAccount braucht Cluster-Rechte für Node-Operationen. Prüfe die ClusterRole litmus-admin.

FAQ

Kann Chaos Engineering meinen Production-Cluster beschädigen?

Die Experimente sind zeitlich begrenzt und reversibel. Trotzdem solltest du in Production mit kleinem Blast-Radius starten — einzelne Pods statt ganzer Nodes. Litmus bietet PODS_AFFECTED_PERC und TARGET_NODE zur Einschränkung.

Wie unterscheidet sich Litmus von Chaos Mesh?

Beide sind CNCF-Projekte für Kubernetes Chaos Engineering. Litmus bietet ein ChaosCenter mit UI und Workflow-Orchestrierung. Chaos Mesh hat stärkere Kernel-Level-Experimente (IO-Chaos, Zeitmanipulation). Für die meisten Teams reicht eines von beiden.

Brauche ich einen separaten Cluster für Chaos Tests?

Für den Einstieg reicht ein Staging-Cluster. In Production solltest du Chaos Engineering erst einsetzen, wenn du Observability (Monitoring, Alerting, Tracing) etabliert hast — sonst siehst du nicht, was passiert.

Wie oft sollte ich Chaos-Experimente durchführen?

Regelmäßig und automatisiert. Wöchentliche Experiments in Staging, monatlich in Production. Nach jeder größeren Architekturänderung solltest du die Experimente erneut ausführen.

Welche Experimente sollte ich zuerst durchführen?

Starte mit pod-delete — es deckt die häufigsten Resilienz-Probleme auf. Danach Netzwerk-Latenz, weil sie reale Fehlerszenarien abbildet. Node-Drain ist der dritte logische Schritt.