2、Chaos Mesh 简介：项目背景、社区生态、核心能力
Chaos Mesh 是一个开源的云原生混沌工程平台，由 PingCAP 于 2019 年开源，2020 年成为 CNCF 孵化项目，2022 年正式毕业。它专为 Kubernetes 环境设计，通过声明式 API 和自定义资源定义（CRD）来定义、调度和编排混沌实验，帮助团队在生产或预发环境中主动发现系统脆弱点。
2.1 项目背景与设计哲学
随着微服务和云原生架构的普及，分布式系统的复杂性呈指数级增长。传统的故障注入工具（如 Chaos Monkey）主要针对虚拟机或裸机，无法原生感知 Pod、Sidecar、Service Mesh 等 Kubernetes 抽象。Chaos Mesh 应运而生，其核心设计理念包括：
- 声明式实验：用户通过 YAML 定义实验目标、故障类型和持续时间，由控制器调和至期望状态。
- Kubernetes 原生：基于 CRD + Operator 模式，无缝融入现有 K8s 生态，支持 Helm 部署和 RBAC 集成。
- 安全优先：提供实验准入控制（Admission Webhook）、命名空间隔离、实验白名单/黑名单机制，防止误操作影响生产。
- 可观测性：实验状态、事件和指标通过 Dashboard 和 Prometheus 暴露，便于事后分析和告警。
2.2 社区生态与治理
Chaos Mesh 拥有活跃的全球社区，采用 CNCF 标准的开放治理模式。下表总结了其生态核心组件与角色：
| 组件/角色 | 说明 | 技术栈 |
|---|---|---|
| Chaos Mesh Operator | 核心控制器，监听 CRD 并驱动实验生命周期 | Go, controller-runtime |
| Chaos Dashboard | Web UI，支持实验可视化创建、状态查看和事件检索 | React, Go |
| Chaos Daemon | 运行在每个 K8s 节点上的 Agent，执行具体故障注入 | Go, eBPF, iptables |
| chaos-mesh/chaos-mesh | 主仓库，包含所有核心代码和 Helm Chart | GitHub |
| Admission Webhook | 实验准入控制器，校验和拦截不合规的实验请求 | Go, ValidatingWebhookConfiguration |
社区每季度发布一个稳定版本，遵循语义化版本规范。用户可以通过 Slack、GitHub Discussions 和每周社区会议参与贡献。
2.3 核心能力：三大故障注入类型
Chaos Mesh 支持超过 20 种故障类型，按注入目标可分为三大类：Pod 故障、网络故障 和 压力注入。下面通过一张架构图展示其核心能力分类：
2.4 核心能力详解
2.4.1 Pod 故障
直接操作 Pod 生命周期或容器状态，模拟节点宕机、进程崩溃、DNS 解析异常等场景。典型实验包括：
- Pod Kill：随机或指定删除 Pod，测试 Deployment/StatefulSet 的自动恢复能力。
- Pod Failure：将 Pod 置为不可调度或 NotReady 状态，模拟节点故障。
- Container Kill：杀死 Pod 内指定容器，验证 Sidecar 或主进程的容错逻辑。
- DNS Error：篡改 Pod 内 DNS 解析结果，模拟服务发现故障。
2.4.2 网络故障
通过 iptables、tc 或 eBPF 在 Pod 网络命名空间层面注入延迟、丢包、分区等扰动。典型实验包括：
- Network Delay：为指定目标 Pod 增加固定或随机延迟（如 100ms ± 20ms）。
- Network Loss：按百分比丢弃数据包，模拟网络不稳定。
- Network Partition：阻断 Pod 与特定 IP/端口/标签选择器的通信。
- Network Duplicate / Corrupt：模拟数据包重复或损坏，测试应用层重试和校验机制。
2.4.3 压力注入
向 Pod 内注入 CPU、内存、磁盘 IO 或文件系统压力，验证资源隔离和限流策略。典型实验包括：
- CPU Stress：占用指定数量的 CPU 核心（如 2 核），测试 HPA 和资源 Quota 响应。
- Memory Stress：分配指定大小的内存（如 512MB），触发 OOM Kill 或内存回收。
- IO Stress：对磁盘进行高并发读写，模拟存储性能瓶颈。
- Disk Fill：填充磁盘至指定比例（如 80%），测试日志轮转和磁盘告警。
dry-run: true 模式验证实验定义，再逐步增加持续时间（如从 30 秒开始）和影响范围。结合 Admission Webhook 设置实验白名单，避免误注入关键业务 Pod。
2.5 实验定义示例
以下是一个完整的 Pod Kill 实验 YAML，展示了 Chaos Mesh 的声明式 API 风格：
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
name: pod-kill-example
namespace: chaos-testing
spec:
action: pod-kill
mode: one
selector:
namespaces:
- production
labelSelectors:
app: web-server
duration: 60s
scheduler:
cron: "@every 10m"
# 实验准入控制：仅允许在指定命名空间执行
allowedNamespaces:
- chaos-testing
- staging该实验每 10 分钟在 production 命名空间中随机杀死一个带有 app=web-server 标签的 Pod，持续 60 秒后自动恢复。通过 allowedNamespaces 字段，管理员可以限制实验范围，防止影响生产核心服务。