💥 第26课：故障演练
核心概念
故障演练(Chaos Engineering)：主动发现弱点
主动在受控条件下注入故障，验证系统容错能力和告警有效性。
故障演练方法论
1. 定义稳态假设（System is healthy when...）
2. 引入真实故障变量（Network delay, Pod kill, CPU stress）
3. 观察系统行为（是否维持稳态？告警是否触发？）
4. 分析差距并改进
故障类型：
├── 基础设施：CPU/内存/磁盘压力
├── 网络：延迟、丢包、分区
├── 应用：Pod Kill、错误注入
├── 依赖：外部服务宕机
└── 数据：数据库故障、缓存失效
命令实操
1. Chaos Mesh实验 ✅
kubectl apply -f https://mirrors.chaos-mesh.org/v2.6.0/chaos-mesh.yaml
# Pod Kill实验
cat > pod-kill.yaml << 'EOF'
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata: {name: pod-kill-test, namespace: chaos-mesh}
spec:
action: pod-kill
mode: one
selector: {namespaces: ["default"], labelSelectors: {app: myapp}}
scheduler: {cron: "@every 10m"}
EOF
kubectl apply -f pod-kill.yaml
# 网络延迟实验
cat > network-delay.yaml << 'EOF'
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata: {name: network-delay-test, namespace: chaos-mesh}
spec:
action: delay
mode: all
selector: {namespaces: ["default"], labelSelectors: {app: myapp}}
delay: {latency: "500ms", correlation: "50", jitter: "100ms"}
duration: "5m"
EOF
kubectl apply -f network-delay.yaml
# CPU压力实验
cat > cpu-stress.yaml << 'EOF'
apiVersion: chaos-mesh.org/v1alpha1
kind: StressChaos
metadata: {name: cpu-stress-test, namespace: chaos-mesh}
spec:
mode: one
selector: {namespaces: ["default"], labelSelectors: {app: myapp}}
stressors: {cpu: {workers: 4, load: 80}}
duration: "3m"
EOF
kubectl apply -f cpu-stress.yaml
2. 手动故障注入脚本 ✅
#!/bin/bash
# chaos-test.sh
ACTION="${1:?pod-kill|network-delay|cpu-stress|cleanup}"
TARGET="${2:-myapp}"
case "$ACTION" in
pod-kill)
echo "💥 Killing random $TARGET pod..."
POD=$(kubectl get pods -l app=$TARGET -o json | jq -r '.items[].metadata.name' | shuf -n 1)
kubectl delete pod "$POD" --grace-period=0
;;
network-delay)
echo "⏱ Adding 500ms delay to $TARGET..."
kubectl apply -f - <
架构图
故障演练(Chaos Engineering)：主动发现弱点架构
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 定义稳态 │→│ 注入故障 │→│ 观察系统 │
│(健康基线) │ │(受控变量) │ │(偏离检测) │
└──────────┘ └──────────┘ └─────┬────┘
┌─────────────┼─────────────┐
▼ ▼
维持稳态 ✅ 偏离稳态 ❌
系统容错OK 发现弱点
→ 增加难度 → 修复问题 → 改进SLO故障排查
❌ Chaos实验未生效
kubectl get pods -n chaos-mesh
kubectl describe networkchaos network-delay-test -n chaos-mesh
# 常见：selector标签不匹配/Chaos Mesh权限不足/PDB保护/网络插件不支持tc
💡 故障演练原则：从小爆炸半径开始、生产环境也要演练、确保回滚手段就绪、每次演练后复盘改进。
🏆 成就解锁：故障演练专家！
掌握Chaos Mesh、手动注入、稳态假设——主动找弱点比被动救火更高效
📝 故障演练计划模板
| 项目 | 内容 |
|---|
| 演练名称 | 数据库主库宕机 |
| 爆炸半径 | 仅staging环境 |
| 稳态假设 | API成功率>99.9% |
| 故障注入 | Chaos Mesh PodChaos on DB |
| 预期结果 | 自动故障转移，成功率>99% |
| 观察指标 | 错误率、延迟、恢复时间 |
| 回滚方案 | 删除Chaos实验 |
💡 演练原则：从小开始(staging→production)、有回滚手段、演练后必须复盘、生产演练选择低峰期。
🔧 Litmus Chaos实验
# 安装Litmus
kubectl apply -f https://litmuschaos.github.io/litmus/2.14.0/litmus-2.14.0.yaml
# 创建ChaosEngine
cat > pod-delete-engine.yaml << 'EOF'
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata: {name: myapp-chaos}
spec:
appinfo: {appns: default, applabel: "app=myapp"}
chaosServiceAccount: litmus-admin
experiments:
- name: pod-delete
spec:
components:
env:
- {name: TOTAL_CHAOS_DURATION, value: "30"}
- {name: CHAOS_INTERVAL, value: "10"}
probe:
- name: check-app-health
type: httpProbe
httpProbe/inputs: {url: "http://myapp-svc/health", method: {get: {}}}
mode: Continuous
runProperties: {probeTimeout: 5, interval: 5}
EOF
kubectl apply -f pod-delete-engine.yaml
📝 混沌实验清单
| 实验 | 目标 | 验证能力 | 工具 |
|---|
| Pod随机删除 | 应用层 | 自愈能力 | Chaos Mesh/Litmus |
| 网络延迟 | 网络层 | 超时重试 | Chaos Mesh |
| CPU压力 | 资源层 | 弹性伸缩 | Chaos Mesh |
| 磁盘故障 | 存储层 | 数据冗余 | Chaos Mesh |
| DNS故障 | 网络层 | 服务发现 | Chaos Mesh |
| 时间偏移 | 系统层 | 证书/日志 | Chaos Mesh |
⚠️ 混沌实验安全要求：必须有回滚方案、爆炸半径可控、生产演练选低峰期、必须有监控和On-Call待命。
⚠️ 学习建议：每课内容都需要在实验环境中实际操作验证，只有动手才能真正掌握。建议搭建自己的实验环境反复练习。
📝 本课知识图谱
| 知识域 | 核心技能 | 验证方式 |
|---|
| 核心概念 | 理解原理和架构 | 能用自己的话解释 |
| 命令实操 | 熟练使用相关工具 | 能独立完成操作 |
| 故障排查 | 定位和解决问题 | 能在模拟故障中恢复 |
| 最佳实践 | 遵循生产级标准 | 能设计可靠方案 |
💡 持续学习：技术领域更新快，关注官方博客、GitHub Release、社区动态，保持知识新鲜度。
🔗 相关课程链接
| 前置课程 | 后续课程 | 关联课程 |
|---|
| 前几课基础内容 | 下一课深入内容 | 跨领域综合应用 |
⚠️ 实验环境安全：本课所有命令请在隔离的实验环境中执行，避免在生产环境直接操作。备份重要数据后再进行任何修改操作。
📌 记住：理论+实践=真正的掌握。每个概念都要动手验证，每个命令都要理解原理。