Kubernetes混沌工程不是搞破坏而是验证修复能力

混沌工程的核心目标是在受控条件下主动注入故障，验证系统的自动恢复能力是否真正生效。很多团队花了大量精力搭建告警和自动扩缩容，却从来没验证过这些机制在真实故障场景下能否正常工作。等到生产事故发生才发现自动扩容配置有bug、就绪探针检查逻辑有漏洞——这种”上线即翻车”的情况在混沌工程实践中非常常见。

Kubernetes环境下的混沌工程有独特的优势：声明式资源管理天然支持故障恢复，只要删除或修改资源对象，控制器会自动把状态拉回期望值。这意味着Kubernetes中的混沌实验天然可逆，风险可控。

混沌实验框架选型：Chaos Mesh vs Litmus

两个主流Kubernetes混沌工程框架各有侧重：

Chaos Mesh（CNCF孵化项目，PingCAP出品）
– 支持的故障类型全面：Pod Kill、Network Delay/Packet Loss、IO Error、Stress CPU/Memory、Time Skew
– Dashboard可视化操作，学习成本低
– 与TiDB生态集成好
– 安装：helm install chaos-mesh chaos-mesh/chaos-mesh -n chaos-testing

Litmus（CNCF孵化项目，MayaData出品）
– 实验库更丰富，社区贡献的混沌实验模板超过400个
– 与Argo Workflows集成好，支持复杂编排
– 更侧重CI/CD流水线中的混沌测试
– 安装：kubectl apply -f https://litmuschaos.github.io/litmus/litmus-operator.yaml

两者选型的判断依据：如果主要目标是快速验证基础设施韧性，Chaos Mesh更简单直接；如果需要把混沌实验嵌入到发布流水线中做持续验证，Litmus的编排能力更强。

Pod级故障注入实战

最常见的混沌实验场景——随机杀掉Pod，验证HPA和PDB是否正常工作：

# Chaos Mesh: Pod Kill实验配置
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: web-app-pod-kill
  namespace: chaos-testing
spec:
  action: pod-kill
  mode: one
  selector:
    namespaces:
      - production
    labelSelectors:
      app: web-app
  scheduler:
    cron: "@every 5m"
  duration: "30s"

验证要点清单：
1. 被杀Pod是否在30秒内自动重建（检查kubectl get pods -w）
2. 新Pod的Ready状态是否在就绪探针通过后立即标记（检查Endpoint更新延迟）
3. Service流量是否自动切走被杀Pod（检查Endpoint Controller的更新速度）
4. HPA是否在负载增加时触发扩容（检查kubectl get hpa）

网络故障注入与流量切换验证

网络故障是生产环境最常见的故障类型之一。Kubernetes中网络混沌实验的重点是验证服务间调用的超时配置、重试策略和熔断机制。

# 网络延迟注入：给payment-service调用增加2秒延迟
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: payment-network-delay
  namespace: chaos-testing
spec:
  action: delay
  mode: all
  selector:
    namespaces:
      - production
    labelSelectors:
      app: web-app
  direction: to
  target:
    selector:
      namespaces:
        - production
      labelSelectors:
        app: payment-service
  delay:
    latency: "2s"
    jitter: "500ms"
  duration: "10m"

这个实验验证的核心问题：当支付服务延迟飙升到2秒，上游服务的超时时间是否合理？如果上游配置的timeout是1秒，那会大量超时失败；如果是3秒，延迟会增加但不会失败。熔断器是否在错误率超过阈值后打开？Istio的DestinationRule中配置的重试策略是否会放大下游压力？

IO故障注入：验证数据持久化韧性

IO故障通常被忽视，但对数据库和消息队列类服务是致命的：

# IO延迟注入：给PVC挂载的磁盘增加读写延迟
apiVersion: chaos-mesh.org/v1alpha1
kind: IOChaos
metadata:
  name: mysql-io-delay
  namespace: chaos-testing
spec:
  action: delay
  mode: one
  selector:
    namespaces:
      - production
    labelSelectors:
      app: mysql
  delay:
    latency: "100ms"
  methods:
    - read
    - write
  path: "/var/lib/mysql"
  percent: 80
  duration: "5m"

验证数据库连接池是否会在IO延迟下耗尽。应用层是否配置了合理的查询超时。MySQL的innodb_lock_wait_timeout是否过长导致慢查询阻塞连接。

实验编排：多故障组合场景

单故障注入验证的是单点韧性，真实生产故障往往是多个异常叠加。用Workflow编排多步实验：

# Chaos Mesh Workflow：模拟滚动更新期间的节点故障
apiVersion: chaos-mesh.org/v1alpha1
kind: Workflow
metadata:
  name: rollout-node-failure
  namespace: chaos-testing
spec:
  entry: entry
  templates:
    - name: entry
      templateType: Serial
      children:
        - start-rollout
        - inject-node-failure
        - verify-recovery
    - name: start-rollout
      templateType: Task
      task:
        container:
          image: bitnami/kubectl
          command: ["kubectl", "rollout", "restart", "deployment/web-app"]
    - name: inject-node-failure
      templateType: PodChaos
      podChaos:
        selector:
          namespaces: ["production"]
          labelSelectors:
            app: web-app
        action: pod-kill
        mode: random
        value: "30%"
    - name: verify-recovery
      templateType: Task
      task:
        container:
          image: curlimages/curl
          command: ["curl", "-sf", "http://web-app/health"]

安全护栏与实验终止机制

混沌实验必须有紧急终止能力。Chaos Mesh提供了Abort机制，Litmus有Rollback步骤。关键配置：

1. 监控告警联动：混沌实验开始前配置Prometheus告警规则，当SLO指标（如错误率、P99延迟）突破红线时自动终止实验
2. 爆炸半径控制：实验只作用于带有特定标签的Pod，绝不影响核心支付链路
3. 人工审批门：高风险实验（如节点级故障注入）必须经过审批流程，Chaos Mesh的Schedule支持pause状态
4. 时间窗口限制：实验duration不超过15分钟，避免长期影响业务

# 自动终止脚本：监控错误率超阈值立即清理
while true; do
    ERROR_RATE=$(curl -s 'http://prometheus:9090/api/v1/query?query=rate(http_requests_total{status=~"5.."}[1m])/rate(http_requests_total[1m])' | jq -r '.data.result[0].value[1]')
    if (( $(echo "$ERROR_RATE > 0.05" | bc -l) )); then
        kubectl delete networkchaos,podchaos,iochaos -n chaos-testing --all
        echo "ERROR_RATE=$ERROR_RATE exceeds 5%, all chaos experiments terminated"
        break
    fi
    sleep 10
done

混沌工程不是一次性测试项目，而是持续验证机制。推荐在staging环境开启定时混沌实验（每天凌晨低峰期），在预发布环境做发布前的自动混沌验证。把混沌实验纳入日常运维流程，系统的韧性才能持续提升。