3. LitmusChaos 核心组件解析：CRD 驱动的混沌工程

LitmusChaos 基于 Kubernetes CRD（Custom Resource Definition）扩展机制，将混沌实验定义为声明式资源。理解其四大核心组件——ChaosOperator、ChaosRunner、ChaosEngine 和 ChaosExperiment——是掌握 Pod 故障注入的关键。它们共同构成了“定义-调度-执行-监控”的闭环。

3.1 组件总览与职责划分

下表从作用层级、生命周期和用户交互三个维度对比四个核心组件：

3.2 组件交互流程与架构

下图展示了从用户提交 ChaosEngine 到 Pod 故障注入完成的完整调用链：

3.3 ChaosExperiment CRD：实验蓝图

ChaosExperiment 是不可变的实验定义模板，通常由 LitmusChaos 社区预置或用户自定义。它描述了“做什么”和“怎么做”。

3.3.1 关键字段

3.3.2 预置实验示例（pod-delete）

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosExperiment
metadata:
  name: pod-delete
  namespace: litmus
spec:
  definition:
    scope: Namespaced
    image: "litmuschaos/go-runner:latest"
    permissions:
      - apiGroups: [""]
        resources: ["pods"]
        verbs: ["list", "get", "delete"]
      - apiGroups: [""]
        resources: ["events"]
        verbs: ["create", "patch"]
    experiments:
      - name: pod-delete
        steps:
          - name: inject-pod-delete
            action: delete
            target: pod
            filters:
              - key: app
                value: nginx

3.4 ChaosEngine CRD：实验配置单

ChaosEngine 是用户直接操作的 CRD，它引用一个 ChaosExperiment，并填充具体参数：目标应用、注入持续时间、探针、回滚策略等。

3.4.1 核心字段解析

3.4.2 典型 ChaosEngine YAML

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: nginx-pod-delete-engine
  namespace: default
spec:
  engineState: "active"
  appinfo:
    appns: "default"
    applabel: "app=nginx"
    appkind: "deployment"
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: "60"
            - name: CHAOS_INTERVAL
              value: "10"
            - name: TARGET_PODS
              value: "1"

3.5 ChaosOperator：调度与协调中枢

ChaosOperator 是一个标准的 Kubernetes Controller，运行在 litmus 命名空间中。它通过 Informer 机制监听 ChaosEngine 资源的变化。

3.5.1 核心职责

• 校验：验证 ChaosEngine 引用的 ChaosExperiment 是否存在、参数是否合法。
• 实例化：为每个活跃的 ChaosEngine 创建对应的 ChaosRunner（Job）。
• 生命周期管理：当 ChaosEngine 被删除或状态变为 stop 时，终止 Runner Job。
• 状态同步：将实验执行结果写回 ChaosEngine 的 status 字段。

3.5.2 工作流程

1. Operator 监听到 ChaosEngine 创建/更新事件。
2. 读取 spec.experiments[].name，查找对应的 ChaosExperiment。
3. 合并 ChaosEngine 传入的环境变量与 ChaosExperiment 默认值。
4. 创建 ChaosRunner Job（名称格式：<engine-name>-runner）。
5. 持续监控 Runner Job 状态，直到完成或超时。
6. 更新 ChaosEngine status 为 completed 或 failed。

3.6 ChaosRunner：故障注入执行者

ChaosRunner 是一个一次性 Job，由 ChaosOperator 自动创建。它运行在目标应用所在的命名空间中，直接与 Kubernetes API 交互以执行故障注入。

3.6.1 执行流程

• 初始化：读取 ChaosEngine 和 ChaosExperiment 的合并配置。
• 前置探针：检查目标 Pod 是否就绪、服务是否正常。
• 注入故障：根据实验类型执行操作（如 kubectl delete pod、网络延迟注入）。
• 等待恢复：等待 TOTAL_CHAOS_DURATION 秒后自动恢复。
• 后置探针：验证应用是否恢复正常。
• 清理：删除临时资源，上报结果。

3.6.2 Runner 日志查看

# 查看 Runner Job
kubectl get jobs -n default -l "app.kubernetes.io/component=chaos-runner"

# 查看 Runner Pod 日志
kubectl logs -n default -l "job-name=nginx-pod-delete-engine-runner" --tail=50

3.7 组件关系总结

下图以分层视角展示四个组件在 Kubernetes 集群中的位置与依赖关系：