1. 混沌工程与 LitmusChaos 概述
1.1 混沌工程的起源
混沌工程（Chaos Engineering）的核心理念最早由 Netflix 在 2011 年提出。当时 Netflix 从传统数据中心迁移到 AWS 云平台，发现分布式系统的复杂性远超预期——网络延迟、磁盘故障、实例崩溃等异常事件随时可能发生。为了验证系统在真实故障下的韧性，Netflix 开发了 Chaos Monkey，随机终止生产环境中的实例，迫使工程师构建能够自动恢复的弹性架构。
2015 年，Netflix 正式发布 Principles of Chaos Engineering，将混沌工程从内部工具提升为一门系统化的工程学科。2017 年，混沌工程社区（Chaos Engineering Community）成立，推动了行业标准与开源工具的快速发展。
- 2011 — Netflix 推出 Chaos Monkey
- 2015 — 发布混沌工程原则白皮书
- 2017 — 混沌工程社区成立
- 2019 — CNCF 接纳 LitmusChaos 为沙箱项目
- 2021 — LitmusChaos 晋升为 CNCF 孵化项目
1.2 混沌工程的核心原则
混沌工程并非随机的破坏行为，而是一套严谨的实验方法。根据 Netflix 白皮书，混沌工程遵循以下五项核心原则：
| 原则 | 说明 | 实践要点 |
|---|---|---|
| 1. 定义稳态 | 明确系统正常运行时的可观测行为指标 | 延迟、错误率、吞吐量、饱和度 |
| 2. 提出假设 | 假设系统在故障注入后仍能维持稳态 | “即使 Pod 被删除，服务仍应在 5 秒内恢复” |
| 3. 引入故障 | 在生产或类生产环境中注入真实故障 | Pod 故障、网络延迟、CPU 压力、磁盘 I/O |
| 4. 验证假设 | 对比实验组与对照组的稳态指标差异 | 若假设成立 → 系统韧性达标；否则 → 发现弱点 |
| 5. 自动化运行 | 将实验编排为持续运行的流水线 | CI/CD 集成、定期演练、告警联动 |
1.3 LitmusChaos 项目简介
LitmusChaos 是一个云原生的混沌工程平台，由 MayaData 公司开源，2019 年加入 CNCF Sandbox，2021 年晋升为 Incubating 项目。它专为 Kubernetes 环境设计，提供声明式的故障注入、实验编排、结果分析和自动化治理能力。
LitmusChaos 的核心优势包括：
- Kubernetes 原生 — 使用 CRD（Custom Resource Definition）定义实验，与 K8s API 深度集成
- 声明式编排 — 通过 YAML 描述实验流程，支持 GitOps 工作流
- 丰富的故障库 — 内置 50+ 故障类型，覆盖 Pod、网络、存储、节点、DNS 等层面
- 可观测性集成 — 支持 Prometheus、Grafana、Datadog 等监控系统
- 多租户安全 — 基于 RBAC 的权限控制，支持团队隔离
本课程聚焦于 Pod 故障注入，这是 LitmusChaos 最常用、最基础的实验类型，包括 Pod 删除、Pod 崩溃、容器暂停、Pod 资源抢占等场景。
1.4 LitmusChaos 架构
LitmusChaos 采用 控制平面 + 数据平面 的分层架构。控制平面负责实验编排、用户管理和结果存储；数据平面负责在目标集群中执行具体的故障注入操作。
1.5 核心 CRD 与实验流程
LitmusChaos 通过三个核心 CRD 定义实验生命周期：
| CRD 名称 | 作用 | 关键字段 |
|---|---|---|
| ChaosEngine | 实验的入口资源，定义目标应用、故障类型、执行策略 | spec.engineState, spec.appinfo, spec.experiments[] |
| ChaosExperiment | 故障注入的具体实现，包含环境变量、探针、持续时间 | spec.definition.env, spec.definition.probes |
| ChaosResult | 实验执行后的结果记录，包含状态、探针输出、错误信息 | status.experimentStatus, status.probeStatuses[] |
一个典型的 Pod 故障注入实验流程如下：
- 定义 ChaosEngine — 指定目标 Namespace、应用标签、故障实验名称
- Operator 监听 — Chaos Operator 检测到新的 ChaosEngine 资源
- 启动 Chaos Runner — Operator 创建临时 Job 执行实验逻辑
- 注入故障 — Runner 根据实验定义执行 Pod 删除、暂停、崩溃等操作
- 执行探针 — 在故障注入前后运行 HTTP/Cmd/PromQL 探针验证稳态
- 记录结果 — 实验完成后写入 ChaosResult CRD，Portal 可查询展示
- 始终在非生产环境验证实验模板，确认探针逻辑正确
- 使用
spec.engineState: stop控制实验启停，避免意外执行 - 为 ChaosEngine 设置
spec.terminationGracePeriodSeconds防止残留 Job - 结合 RBAC 限制 ChaosEngine 的创建权限，仅授权给可信团队