Chaos Engineering Grundlagen
Chaos Engineering Grundlagen
Chaos Engineering testet die Widerstandsfähigkeit von Systemen durch kontrollierte Experimente. Lernen Sie Prinzipien, Tools und wie Sie Chaos-Experimente sicher durchführen.
Was ist Chaos Engineering?
┌─────────────────────────────────────────────────────────────┐ │ CHAOS ENGINEERING │ ├─────────────────────────────────────────────────────────────┤ │ │ │ "The discipline of experimenting on a system in order │ │ to build confidence in the system's capability to │ │ withstand turbulent conditions in production." │ │ - Netflix │ │ │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ │ │ │ │ TRADITIONELL: │ │ │ │ Warten auf Ausfälle → Reagieren → Fixen │ │ │ │ │ │ │ │ CHAOS ENGINEERING: │ │ │ │ Ausfälle simulieren → Schwächen finden → │ │ │ │ Verbessern → Wiederholen │ │ │ │ │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ │ ZIEL: Schwächen finden BEVOR sie in Production │ │ zu Ausfällen führen │ │ │ └─────────────────────────────────────────────────────────────┘
Prinzipien
1. STEADY STATE HYPOTHESE ┌─────────────────────────────────────────────────────┐ │ Definiere "normale" System-Metriken: │ │ • Response Time < 200ms │ │ • Error Rate < 0.1% │ │ • Throughput > 1000 req/s │ │ │ │ Hypothese: "Das System behält diesen Zustand │ │ auch wenn X passiert" │ └─────────────────────────────────────────────────────┘ 2. REALE EREIGNISSE SIMULIEREN ┌─────────────────────────────────────────────────────┐ │ • Server/Container Ausfall │ │ • Netzwerk-Partitionen │ │ • Hohe Latenz │ │ • Disk Full │ │ • CPU/Memory Exhaustion │ │ • Dependency Ausfall │ └─────────────────────────────────────────────────────┘ 3. IN PRODUCTION EXPERIMENTIEREN ┌─────────────────────────────────────────────────────┐ │ Production ist die einzige echte Umgebung. │ │ Staging kann Production nie perfekt nachbilden. │ │ │ │ → Mit Sicherheitsnetzen und Rollback-Plänen! │ └─────────────────────────────────────────────────────┘ 4. AUTOMATISIEREN ┌─────────────────────────────────────────────────────┐ │ Chaos-Experimente sollten kontinuierlich laufen, │ │ nicht nur einmalig. │ │ │ │ → In CI/CD Pipeline integrieren │ └─────────────────────────────────────────────────────┘ 5. BLAST RADIUS MINIMIEREN ┌─────────────────────────────────────────────────────┐ │ Klein anfangen, schrittweise erweitern: │ │ • Erst einen Pod │ │ • Dann eine Availability Zone │ │ • Dann eine Region │ └─────────────────────────────────────────────────────┘
Chaos Monkey (Netflix)
# Das Original von Netflix # Simtian Army Tools: # - Chaos Monkey: Zufällige Instance-Terminierung # - Latency Monkey: Künstliche Verzögerungen # - Conformity Monkey: Nicht-konforme Instances finden # - Chaos Gorilla: Ganze AZ ausschalten # - Chaos Kong: Ganze Region ausschalten # Installation (Spinnaker integriert) # Oder als standalone: # Simian Army Config simianarmy.chaos.enabled = true simianarmy.chaos.probability = 1.0 simianarmy.chaos.leashed = false # Bestimmte ASGs ausschließen simianarmy.chaos.asgs.exclude = critical-*,database-* # Schedule simianarmy.chaos.schedule.startHour = 9 simianarmy.chaos.schedule.endHour = 17 simianarmy.chaos.schedule.workdays = Mon,Tue,Wed,Thu,Fri
Chaos Toolkit
# Open Source Chaos Engineering Framework
# Installation
pip install chaostoolkit
pip install chaostoolkit-kubernetes
pip install chaostoolkit-aws
# Experiment Definition (experiment.json)
{
"version": "1.0.0",
"title": "Pod Failure Resilience",
"description": "Verify system handles pod failures gracefully",
"steady-state-hypothesis": {
"title": "Application is healthy",
"probes": [
{
"type": "probe",
"name": "api-responds",
"tolerance": 200,
"provider": {
"type": "http",
"url": "https://api.example.com/health",
"timeout": 5
}
},
{
"type": "probe",
"name": "error-rate-acceptable",
"tolerance": {
"type": "range",
"range": [0, 1]
},
"provider": {
"type": "python",
"module": "my_probes",
"func": "get_error_rate"
}
}
]
},
"method": [
{
"type": "action",
"name": "terminate-random-pod",
"provider": {
"type": "python",
"module": "chaosk8s.pod.actions",
"func": "terminate_pods",
"arguments": {
"ns": "production",
"label_selector": "app=myapp",
"qty": 1
}
},
"pauses": {
"after": 30
}
}
],
"rollbacks": [
{
"type": "action",
"name": "scale-up-pods",
"provider": {
"type": "python",
"module": "chaosk8s.deployment.actions",
"func": "scale_deployment",
"arguments": {
"name": "myapp",
"replicas": 3,
"ns": "production"
}
}
}
]
}
# Experiment ausführen chaos run experiment.json # Mit Report chaos run experiment.json --journal-path=journal.json chaos report --export-format=html journal.json report.html # Nur Steady-State validieren (Dry Run) chaos validate experiment.json
LitmusChaos (Kubernetes)
# Kubernetes-native Chaos Engineering
# Installation
kubectl apply -f https://litmuschaos.github.io/litmus/litmus-operator-v2.0.0.yaml
# ChaosEngine erstellen
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
name: myapp-chaos
namespace: production
spec:
appinfo:
appns: production
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: PODS_AFFECTED_PERC
value: '50'
- name: pod-network-latency
spec:
components:
env:
- name: NETWORK_LATENCY
value: '500' # 500ms Latency
- name: TOTAL_CHAOS_DURATION
value: '120'
# Verfügbare Experimente POD-LEVEL: - pod-delete: Pods terminieren - pod-network-latency: Netzwerk-Verzögerung - pod-network-loss: Packet Loss - pod-cpu-hog: CPU-Last erzeugen - pod-memory-hog: Memory-Last erzeugen - pod-io-stress: Disk I/O Stress NODE-LEVEL: - node-drain: Node drainieren - node-taint: Node tainten - kubelet-service-kill: Kubelet stoppen NETWORK: - pod-network-partition: Netzwerk-Partition - pod-dns-error: DNS-Fehler simulieren
Gremlin (Enterprise)
# Kommerzielle Chaos Engineering Plattform # Gremlin Agent installieren helm repo add gremlin https://helm.gremlin.com helm install gremlin gremlin/gremlin \ --set gremlin.secret.managed=true \ --set gremlin.secret.teamID=$GREMLIN_TEAM_ID \ --set gremlin.secret.clusterID=$GREMLIN_CLUSTER_ID \ --set gremlin.secret.teamSecret=$GREMLIN_TEAM_SECRET # Angriffe via CLI gremlin attack kubernetes pod \ --target-container myapp \ --length 60 \ --percent 50 \ cpu gremlin attack kubernetes pod \ --target-container myapp \ --length 120 \ latency \ --delay 500 # Oder via Web UI für: # - Scheduled Attacks # - Game Days # - Automated Scenarios # - Status Pages Integration
Experiment-Ablauf
┌─────────────────────────────────────────────────────────────┐ │ CHAOS EXPERIMENT WORKFLOW │ ├─────────────────────────────────────────────────────────────┤ │ │ │ 1. STEADY STATE DEFINIEREN │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ • Welche Metriken definieren "gesund"? │ │ │ │ • Response Time, Error Rate, Throughput │ │ │ │ • Dashboards und Alerts vorbereiten │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ 2. HYPOTHESE FORMULIEREN │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ "Wenn ein Pod ausfällt, bleibt das System im │ │ │ │ Steady State weil Kubernetes automatisch │ │ │ │ einen neuen Pod startet" │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ 3. EXPERIMENT DURCHFÜHREN │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ • Steady State validieren (Pre-Check) │ │ │ │ • Chaos einführen (Pod terminieren) │ │ │ │ • Metriken beobachten │ │ │ │ • Steady State erneut validieren (Post-Check) │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ 4. ERGEBNISSE ANALYSIEREN │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ ✅ Hypothese bestätigt → System ist resilient │ │ │ │ ❌ Hypothese widerlegt → Schwäche gefunden! │ │ │ │ → Dokumentieren, Ticket erstellen, fixen │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ 5. VERBESSERN UND WIEDERHOLEN │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ • Fixes implementieren │ │ │ │ • Experiment erneut durchführen │ │ │ │ • Nächstes Experiment planen │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────┘
Game Days
GAME DAY PLANNING ┌──────────────────────────────────────────────────────────┐ │ Ein "Game Day" ist ein koordiniertes Chaos-Event │ │ mit dem gesamten Team. │ └──────────────────────────────────────────────────────────┘ VORBEREITUNG: 1. Datum und Zeitfenster festlegen 2. Alle Stakeholder informieren 3. Runbooks und Rollback-Pläne bereithalten 4. Monitoring und Alerting validieren 5. "Big Red Button" für Notfall-Stop DURCHFÜHRUNG: 1. Pre-Game Briefing (15 min) 2. Steady State Baseline aufnehmen 3. Chaos-Szenarien nacheinander durchführen 4. Beobachten und dokumentieren 5. Post-Game Review (30-60 min) BEISPIEL-AGENDA: 09:00 - Briefing, Steady State Check 09:15 - Szenario 1: Database Failover 09:45 - Analyse und Recovery 10:00 - Szenario 2: 50% Pod Failure 10:30 - Analyse und Recovery 11:00 - Szenario 3: Network Partition 11:30 - Analyse und Recovery 12:00 - Debrief und Action Items
Sicherheitsmaßnahmen
1. KILL SWITCH - Sofortiger Stopp aller Experimente - Automatischer Rollback 2. BLAST RADIUS LIMITS - Max. 10% der Pods - Max. 1 AZ gleichzeitig - Bestimmte Services ausschließen 3. ZEITLICHE GRENZEN - Nur während Business Hours - Automatischer Stop nach X Minuten - Nicht vor/während wichtiger Events 4. MONITORING - Real-time Dashboards - Sofortige Alerts bei Anomalien - SLI/SLO Überwachung 5. KOMMUNIKATION - Team über Experiment informieren - #chaos Slack Channel - Incident Commander bereitstellen
⚠️ Wichtig:
Chaos Engineering in Production erfordert Reife. Beginnen Sie in Staging, bauen Sie Vertrauen auf, und führen Sie erst dann vorsichtig Production-Experimente durch. Immer mit Rollback-Plan und Kill Switch!
💡 Best Practices:
1. Klein anfangen, schrittweise erweitern
2. Hypothesen vor Experimenten formulieren
3. Immer Monitoring aktiv haben
4. Ergebnisse dokumentieren und teilen
5. Gefundene Schwächen tatsächlich fixen
2. Hypothesen vor Experimenten formulieren
3. Immer Monitoring aktiv haben
4. Ergebnisse dokumentieren und teilen
5. Gefundene Schwächen tatsächlich fixen