对于 Kubernetes 环境来说，容器故障注入是验证系统弹性的重要手段。Chaos Mesh 作为云原生计算基金会下的混沌工程平台，通过声明式的方式定义故障实验，可以对 Pod、容器、网络、文件系统等对象注入多种异常。与手动删除 Pod 或修改 iptables 规则相比，Chaos Mesh 的故障注入具备可重复、可度量、可回滚的特点，更适合在 CI/CD 与演练场景中使用。
Chaos Mesh 的安装并不复杂，官方推荐使用 Helm 进行部署。部署完成后，用户可以通过 Kubernetes 自定义资源来创建和管理混沌实验。这种声明式的方式意味着实验定义可以纳入版本控制，团队成员可以审查实验内容，避免因为手工操作而引入不可预期的风险。接下来将围绕核心架构、容器级故障注入、网络与 IO 故障以及安全实践展开说明。
Chaos Mesh 的架构与核心对象
Chaos Mesh 在架构上主要包含三个组件：controller-manager、chaos-daemon 和 chaos-dashboard。controller-manager 负责监听用户提交的混沌实验自定义资源，并根据实验类型协调执行流程。chaos-daemon 以 DaemonSet 形式运行在每个节点上，实际执行进程杀死、网络规则修改、文件系统注入等操作。chaos-dashboard 提供可视化界面，方便查看实验状态和历史记录。
核心自定义资源包括 PodChaos、NetworkChaos、IOChaos、StressChaos、KernelChaos、TimeChaos 等。其中 PodChaos 用于模拟 Pod 删除、Pod 不可用以及容器内进程被杀等场景；NetworkChaos 用于模拟网络延迟、丢包、带宽限制和网络分区；IOChaos 用于在文件系统层面注入读写延迟或错误。每种资源都通过 selector 字段来指定目标对象，避免对所有实例同时施加故障。
helm repo add chaos-mesh https://charts.chaos-mesh.org helm search repo chaos-mesh helm install chaos-mesh chaos-mesh/chaos-mesh -n chaos-mesh --create-namespace
安装完成后，可以通过 kubectl get crd 命令查看 Chaos Mesh 注册的自定义资源。建议先在测试集群中部署，熟悉实验的行为后再考虑在生产环境使用。实验的定义文件通常放在独立的 Git 仓库中，并通过 CI 流程进行语法校验和审核，这样可以有效减少人为配置错误。
使用 PodChaos 实现容器级故障
PodChaos 是容器故障注入中最常用的资源类型之一，它支持三种主要动作：pod-kill、pod-failure 和 container-kill。pod-kill 会随机或按规则删除目标 Pod，由 Kubernetes 控制器自动重建，适合验证服务在实例重启后的恢复能力。pod-failure 会持续让目标 Pod 处于不可用状态，用于模拟节点故障或 Pod 长时间无法启动的情况。container-kill 则只杀死指定容器内的进程，不触发 Pod 重建，适合定位单容器异常对整体服务的影响。
下面是一个 container-kill 实验的 YAML 示例，它会在 default 命名空间下选择带有 app: web-server 标签的 Pod，并杀死其中名为 nginx 的容器，持续时间 60 秒。
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
name: container-kill-example
namespace: chaos-mesh
spec:
action: container-kill
mode: one
selector:
namespaces:
- default
labelSelectors:
app: web-server
containerNames:
- nginx
duration: 60s
scheduler:
cron: "@every 10m"
这里的 mode 字段非常重要，它决定了故障的作用范围。mode 支持 one、all、fixed、fixed-percent、random-max-percent 等取值。one 表示每次只影响一个 Pod，all 表示影响所有匹配的 Pod，fixed 表示影响固定数量的 Pod，fixed-percent 表示按百分比选取。通过组合 labelSelectors 和 mode，可以将故障精确控制在单个副本或部分流量上，避免实验造成全面中断。
在执行 container-kill 实验后，应该观察容器内进程退出是否被应用正确捕获，以及 Kubernetes 是否会按照预期重新拉起容器。如果应用没有优雅处理 SIGTERM 信号，可能会导致请求失败或数据不一致。建议在实验前后记录关键指标，以便对比故障注入前后的行为差异。
网络与 IO 故障注入
微服务架构中，服务之间的通信异常往往比单点崩溃更难排查。NetworkChaos 可以在 Pod 或节点级别注入延迟、丢包、重复包、乱序和带宽限制等故障。例如给 API 服务注入 200 毫秒延迟，可以验证前端是否有超时重试机制，以及重试是否会放大后端压力。
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
name: network-delay-example
namespace: chaos-mesh
spec:
action: delay
mode: all
selector:
namespaces:
- default
labelSelectors:
app: api-server
delay:
latency: 200ms
correlation: "50"
jitter: 20ms
duration: 30s
上述示例中 correlation 表示延迟的持续时间比例，设置为 50 意味着只有一半的请求会经历延迟，jitter 则让延迟值在 200ms 上下浮动 20ms。这种真实感更强的故障注入可以暴露更多边界问题。NetworkChaos 还支持 action: loss、action: duplicate、action: corrupt、action: bandwidth 等动作，需要根据具体场景选择合适的类型。
IOChaos 则主要针对文件读写路径注入异常，例如模拟磁盘慢盘、坏块或权限错误。对于依赖本地存储的数据库或缓存组件，IO 延迟会直接影响响应时间。下面是一个对 MySQL 数据目录注入 100 毫秒读延迟的示例。
apiVersion: chaos-mesh.org/v1alpha1
kind: IOChaos
metadata:
name: io-delay-example
namespace: chaos-mesh
spec:
action: latency
mode: one
selector:
namespaces:
- default
labelSelectors:
app: database
volumePath: /var/lib/mysql
path: /var/lib/mysql/**
delay: 100ms
percent: 50
duration: 30s
IOChaos 需要指定 volumePath 和 path，volumePath 是挂载卷的根路径，path 是具体注入故障的目录或文件模式。percent 字段用于控制有多少比例的 IO 请求会受到延迟影响。这种细粒度控制非常适合模拟真实环境中磁盘性能下降但未完全失效的情况。
故障注入的可观测性及安全实践
混沌实验的价值只有在能够观测系统状态时才能体现。在执行任何故障注入之前，应该先建立完整的监控指标和告警规则。Prometheus、Grafana、Jaeger 等工具可以帮助捕获请求延迟、错误率、资源使用率和分布式追踪信息。将 Chaos Mesh 与这些可观测性平台配合，可以快速定位故障注入后系统哪个环节出现了瓶颈。
生产环境中执行混沌实验需要格外谨慎。首先应在 staging 或预发环境完成多轮验证，确认实验定义不会误伤系统组件。其次通过 namespace 隔离和严格的 RBAC 权限限制，确保只有授权人员可以创建混沌实验。此外给每个实验设置合理的 duration 和 scheduler，避免故障无限期持续。实验结束后要及时验证系统是否完全恢复，例如所有副本是否正常、数据是否一致、告警是否自动恢复。
Chaos Mesh 提供了丰富的安全与恢复机制，例如实验自动过期、实验暂停与恢复、实验状态查询等。在生产环境落地时，建议从低风险实验开始，例如先对单个非关键 Pod 注入进程退出，再逐步扩展到网络延迟和 IO 故障。同时将实验纳入日常演练计划，定期执行并记录结果，这样才能持续验证系统的弹性能力，而不是等到真实故障发生时才手忙脚乱。
Chaos Mesh容器故障注入混沌工程修改时间：2026-08-24 20:59:28