4. 故障注入工具选型：Chaos Mesh、LitmusChaos、kube-monkey 对比与安装

在 HPA 伸缩任务编排的故障复测中，选择合适的故障注入工具是实验成功的关键。当前社区主流的开源工具包括 Chaos Mesh、LitmusChaos 和 kube-monkey。三者设计理念、故障类型、安装复杂度差异显著，需根据测试场景精准选型。

4.1 工具核心特性对比

对比维度 Chaos Mesh LitmusChaos kube-monkey
设计定位 Kubernetes 原生混沌工程平台 云原生混沌工程框架（CNCF 沙箱） Pod 随机杀灭工具（Netflix Chaos Monkey 移植）
故障类型 Pod 故障、网络延迟/丢包、DNS、HTTP、IO 延迟、压力注入等 20+ 种 Pod 故障、网络、节点压力、HTTP、云服务 API 故障等 50+ 种（通过实验包扩展） 仅支持 Pod 随机删除（基于标签选择）
编排方式 YAML CRD + Dashboard 可视化 YAML CRD + Litmus Portal Web UI 配置文件 + 命令行参数
HPA 复测适配度 高（支持定时、串行、并行实验，可精确控制故障持续时间） 高（支持工作流编排，可组合多个故障步骤） 低（仅随机杀 Pod，无法控制故障时序与类型）
安装复杂度 中（Helm 一键安装，需配置 admission webhook） 中高（需安装 Operator、CRD、Portal 三组件） 低（单二进制部署，无需 CRD）
社区活跃度 高（PingCAP 主导，CNCF 沙箱） 高（MayaData 主导，CNCF 沙箱） 低（维护缓慢，功能单一）
选型建议： 对于 HPA 伸缩任务编排的故障复测，推荐优先使用 Chaos Mesh 或 LitmusChaos。kube-monkey 仅适合做最简单的 Pod 随机杀灭验证，无法满足精细化故障编排需求。

4.2 工具架构与故障注入流程

下图展示了 Chaos Mesh 与 LitmusChaos 在 Kubernetes 集群中的核心架构差异。Chaos Mesh 采用 Sidecar + Webhook 模式注入故障，而 LitmusChaos 基于 Operator + Job 模式执行实验。

Chaos Mesh 与 LitmusChaos 架构对比 Chaos Mesh vs LitmusChaos 架构对比 Chaos Mesh 架构 chaos-controller-manager chaos-daemon (DaemonSet) Admission Webhook Dashboard LitmusChaos 架构 chaos-operator chaos-exporter Litmus Portal ChaosJob (临时 Job) 故障注入模式差异 注入方式：Sidecar + iptables / tc 无需修改 Pod Spec，通过 Webhook 动态注入 注入方式：Operator + Job + RBAC 创建临时 Job 执行故障脚本，依赖 ServiceAccount
架构要点： Chaos Mesh 的 Sidecar 注入对目标 Pod 无侵入，适合生产环境灰度验证；LitmusChaos 的 Job 模式更灵活，但需要目标命名空间有足够的 RBAC 权限。

4.3 安装步骤详解

4.3.1 安装 Chaos Mesh（推荐用于 HPA 复测）

Chaos Mesh 提供 Helm 和 Operator 两种安装方式。以下使用 Helm 3 安装最新稳定版（v2.7.x）：

# 1. 添加 Helm 仓库
helm repo add chaos-mesh https://charts.chaos-mesh.org
helm repo update

# 2. 创建命名空间
kubectl create namespace chaos-mesh

# 3. 安装 Chaos Mesh（开启 Dashboard）
helm install chaos-mesh chaos-mesh/chaos-mesh \
  --namespace=chaos-mesh \
  --set dashboard.securityMode=false \
  --set chaosDaemon.runtime=containerd \
  --set chaosDaemon.socketPath=/run/containerd/containerd.sock

# 4. 验证安装
kubectl get pods -n chaos-mesh
# 预期输出：chaos-controller-manager-xxx, chaos-daemon-xxx, chaos-dashboard-xxx 均为 Running

# 5. 暴露 Dashboard（开发环境）
kubectl port-forward -n chaos-mesh svc/chaos-dashboard 2333:2333
# 浏览器访问 http://localhost:2333
安装注意： 如果集群使用 containerd 运行时，必须设置 chaosDaemon.runtime=containerd 并指定正确的 socket 路径。默认路径为 /run/containerd/containerd.sock，若使用 CRI-O 或 Docker 需相应调整。

4.3.2 安装 LitmusChaos

LitmusChaos 2.x 版本采用 Operator + Portal 架构，安装步骤稍多：

# 1. 安装 Litmus Chaos Operator
kubectl apply -f https://litmuschaos.github.io/litmus/litmus-operator-v2.14.0.yaml

# 2. 验证 Operator 安装
kubectl get pods -n litmus
# 预期输出：chaos-operator-xxx Running

# 3. 安装 Litmus Portal（Web UI）
kubectl apply -f https://litmuschaos.github.io/litmus/litmus-portal-v2.14.0.yaml

# 4. 获取 Portal 访问地址
kubectl get svc -n litmus
# 默认 NodePort 或 LoadBalancer，根据集群配置访问

# 5. 安装 Chaos Experiments（故障实验包）
kubectl apply -f https://hub.litmuschaos.io/api/chaos/2.14.0?file=charts/generic/experiments.yaml
# 该命令会安装 generic 实验包，包含 pod-delete、network-delay 等常用故障

4.3.3 安装 kube-monkey（轻量级随机杀 Pod）

kube-monkey 安装最简单，适合快速验证：

# 1. 使用 Helm 安装
helm repo add kube-monkey https://asobti.github.io/kube-monkey
helm install kube-monkey kube-monkey/kube-monkey \
  --namespace kube-system \
  --set config.dryRun=false \
  --set config.schedule.interval=30 \
  --set config.schedule.startHour=8 \
  --set config.schedule.endHour=20

# 2. 验证安装
kubectl get pods -n kube-system | grep kube-monkey

# 3. 配置目标 Deployment（添加 annotation）
# kubectl annotate deployment my-app kube-monkey/enabled=true
# kubectl annotate deployment my-app kube-monkey/mtbf=2
# kubectl annotate deployment my-app kube-monkey/kill-mode="fixed"
# kubectl annotate deployment my-app kube-monkey/kill-value=1

4.4 工具选型决策流程

根据 HPA 伸缩任务编排的故障复测需求，建议按以下流程选择工具：

  1. 是否需要精确控制故障时序与类型？
    • 是 → 进入步骤 2
    • 否（仅需随机杀 Pod）→ 选择 kube-monkey
  2. 是否需要可视化编排与 Dashboard？
    • 是 → 进入步骤 3
    • 否（偏好 YAML 直接定义）→ 两者均可，推荐 Chaos Mesh（CRD 更简洁）
  3. 是否已有 Prometheus + Grafana 监控体系？
    • 是 → LitmusChaos（内置 chaos-exporter 集成更顺滑）
    • 否 → Chaos Mesh（Dashboard 自带实验状态与事件查看）
本课程推荐： 后续章节的故障注入实验将统一使用 Chaos Mesh 作为主要工具，原因包括：安装简洁、CRD 定义直观、支持 Pod 网络延迟/CPU 压力等与 HPA 伸缩强相关的故障类型，且 Dashboard 便于观察实验状态。

4.5 安装后验证清单

验证项 Chaos Mesh LitmusChaos kube-monkey
核心 Pod 运行状态 controller-manager, daemon, dashboard 均为 Running chaos-operator, chaos-exporter, portal 均为 Running kube-monkey Pod Running
CRD 注册 kubectl get crd | grep chaos-mesh 返回 10+ CRD kubectl get crd | grep litmus 返回 5+ CRD 无 CRD
Webhook 就绪 kubectl get mutatingwebhookconfiguration 包含 chaos-mesh 不依赖 Webhook 不依赖 Webhook
简单故障注入测试 创建 PodChaos 资源，观察 Pod 重启 创建 ChaosEngine 资源，观察 Job 执行 添加 annotation 后等待调度
← 上一章 📖 返回目录 下一章 →