HelloWorld LitmusChaos 教程

在Kubernetes集群中用LitmusChaos完成一个HelloWorld级别的故障注入实验，关键是准备好集群与kubectl、安装Litmus Operator（或使用litmusctl）、创建一个简单的ChaosExperiment与ChaosEngine（例如Pod-delete），运行后通过ChaosResult与事件判断实验通过与否，最后清理资源即可。下面按步骤、原理与实操示例带你从零走通整个流程，顺带讲清常见故障与扩展思路。

先把概念讲清楚：LitmusChaos 是什么，HelloWorld 实验到底做什么

想象你在厨房测试一台烤箱：你关掉电源，看看菜还能不能做熟。LitmusChaos 的工作类似——在 Kubernetes 集群里“故意”制造故障（比如删除 Pod、消耗 CPU、断网络），观察应用是否仍然健壮。HelloWorld 实验通常是最简单的一类故障注入，用来验证工具链和观测流程是否正确，比如删除一个非关键 Pod 并确认系统检测与恢复机制生效。

关键概念速览

• ChaosExperiment：定义要做什么样的故障（类型、参数、目标对象）。
• ChaosEngine：在特定命名空间/目标上触发 ChaosExperiment，包含容器目标选择与运行策略。
• ChaosResult：记录每次实验的执行结果与关键指标，便于审计与告警。
• Chaos Operator / Runner：负责监听 ChaosEngine 并实际执行实验的控制面（通常运行在 litmus 命名空间）。
• Probes：在实验过程中用于判断应用正确性的检查点（比如 HTTP 探针、命令探针）。

环境与准备：开始前要准备什么

如果你只是想快速验证，至少需要一台能运行 Kubernetes 的环境（Minikube、Kind、AKS/GKE/EKS 任一云集群），以及本地的 kubectl。对生产级验证建议准备 Prometheus、Grafana 或其他监控以便收集指标。

前置条件清单

• Kubernetes 集群（v1.16+ 推荐，视 Litmus 版本而定）
• kubectl 已配置并能访问集群
• Helm 或直接 kubectl 用于安装 Litmus Operator（可选 litmusctl）
• 一个测试应用（最简单的 nginx deployment 即可）
• 对集群有足够权限以创建 CRD、Pod 与 RBAC

动手实操：一步步做一个 HelloWorld（Pod-delete）实验

下面我们以最常见的“删除 Pod”实验为例，从部署测试应用到安装 Litmus、编写 ChaosEngine、查看结果、清理资源，覆盖每一步常见命令与说明。

1. 部署一个简单测试应用（nginx）

先创建一个命名空间并部署 nginx，示例命令：

kubectl create ns hello-litmus
kubectl -n hello-litmus create deployment nginx --image=nginx
kubectl -n hello-litmus scale deployment nginx --replicas=3

确认 Pod 在运行：

kubectl -n hello-litmus get pods

2. 安装 Litmus Operator（最简方式：kubectl 应用 operator 与 CRD）

Litmus 通常通过部署 operator（控制 plane）来管理 ChaosExperiment/Engine。安装过程可能随版本不同而变化，但本质上是创建 litmus 命名空间并应用 operator 的 YAML。示例（占位，按你下载的版本替换）：

kubectl create ns litmus
kubectl apply -f  -n litmus

确认 operator 与 runner pod 运行：

kubectl -n litmus get pods

3. 准备 ChaosExperiment（使用现成的 pod-delete 或自定义）

很多版本的 Litmus 自带 pod-delete 类型的实验 CRD。如果没有，你可以定义一个 ChaosExperiment 或直接使用社区实验。实验定义主要包含执行镜像、参数（像目标 pod 选择）、以及回滚或清理策略。

例如（概念性片段）：

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosExperiment
metadata:
  name: pod-delete-example
spec:
  definition:
    scope: Namespaced
    ...
    image: "litmuschaos/chaos-exec:latest"
    args: ["--operation=delete-pod"]

4. 创建 ChaosEngine 来触发实验

ChaosEngine 将实验应用到目标应用上。下面示例将 pod-delete 应用到 hello-litmus 命名空间的 nginx 部署：

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: nginx-pod-delete
  namespace: hello-litmus
spec:
  appinfo:
    appns: hello-litmus
    applabel: "app=nginx"
    appkind: "deployment"
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-delete-example

应用：

kubectl apply -f chaosengine.yaml -n hello-litmus

5. 观察实验执行与结果

关键的检查点：

• 查看 ChaosEngine 状态：kubectl -n hello-litmus describe chaosengine nginx-pod-delete
• 查看 ChaosResult：kubectl -n hello-litmus get chaosresults
• 查看 runner/experiment pod 日志（通常在 litmus 命名空间）：kubectl -n litmus logs <runner-pod>
• 检查应用 Pod 是否被删除与恢复：kubectl -n hello-litmus get pods -w

实验结果如何判定：哪些数据有意义

判断实验是否“通过”不仅看 Pod 被删没被删，而是看应用的关键可用性指标在实验窗口内是否满足预期。

• ChaosResult：是否记录 experimentVerdict 为 Pass/Fail。
• Probe 输出：在实验期间，探针应持续验证应用接口或业务流程（HTTP status、DB 读写等）。
• 监控指标：如果接入 Prometheus，关注请求成功率、响应时延、错误率等。
• 日志与事件：查看应用与 operator 的日志以定位异常或超时。

常见故障与排查思路（Troubleshooting）

实验中遇到问题很常见，下面按症状给出排查思路，便于快速定位并修复。

症状：ChaosExperiment/ChaosEngine 未被 Operator 识别

• 检查 CRD 是否已注册：kubectl get crd | grep litmus
• 检查 operator 是否正常运行：kubectl -n litmus get pods
• 查看 operator 日志，排查权限或 API 错误：kubectl -n litmus logs <operator-pod>

症状：实验没有实际影响目标 Pod

• 确认 ChaosEngine 中的 appinfo.applabel 与目标 Deployment 的标签一致。
• 检查实验参数（例如选择器、顺序、间隔）是否合理。
• 查看 runner 日志，确认实验镜像是否拉取成功并正确运行。

症状：Probe 连续失败导致实验判定为 Fail，但应用似乎没问题

• 确认 probe 的检查命令/URL 是否在非故障场景下也能通过（调试 probe 命令）。
• 可能是网络隔离或 Service DNS 问题，排查 Service/Endpoint。

安全与实践建议：不要轻易在关键流量上直测

做混沌工程应遵循最小破坏、可控制与可回滚原则。以下是一些实践建议：

• 先在开发或预生产环境做验证，再迁移到生产。
• 使用逐步扩展策略（先对单 Pod、再对单可用区、最后对多实例）。
• 设置清晰的观察窗口和自动回滚/修复脚本。
• 使用 RBAC 限制谁能触发 ChaosEngine 与谁能查看结果。
• 在 CI/CD 中加入 litmus 测试作为一个阶段，但要保证失败不会直接中断紧急排查。

如何把 HelloWorld 扩展成真实的可靠性验证流程

把单次实验升级为有价值的可靠性工程，需要把实验工具化、指标化与自动化：

• 编写标准化的 ChaosExperiment 模板，参数化目标与强度。
• 在每次发布前触发一次“可控的”混沌检查（例如短时的 pod-delete）并在报告中记录结果。
• 把 ChaosResult 与监控系统（Prometheus、Alertmanager）集成，实现异常报警与自动 ticket；
• 建立知识库，记录每次实验的观察与改进点。

小技巧与实践心得（边做边想的那种）

• 先做最小实验：只有一个简单的 pod-delete，确认流程再增加复杂度。
• 用 probe 判断业务而非仅看资源：直接看 Pod 状态太表面，Probe 能给出业务可用性的真实反馈。
• 日志比指标更细腻：当指标模糊时，operator 与 runner 的日志通常能告诉你为何失败。
• 版本匹配很重要：不同 Litmus 版本对 Kubernetes 版本的兼容性不同，升级前查阅变更日志。

示例命令总结（常用命令一览）

• 部署测试应用：kubectl -n hello-litmus create deployment nginx –image=nginx
• 查看 pods：kubectl -n hello-litmus get pods
• 安装 operator（示例）：kubectl apply -f litmus-operator.yaml -n litmus
• 应用 ChaosEngine：kubectl apply -f chaosengine.yaml -n hello-litmus
• 查看 ChaosResults：kubectl -n hello-litmus get chaosresults
• 查看 runner 日志：kubectl -n litmus logs <runner-pod>
• 清理资源（示例）：kubectl -n hello-litmus delete chaosengine nginx-pod-delete

你可能会问的几个细节问题

• Q：实验会断开集群控制面或影响节点吗？
  A：默认实验范围在命名空间或 Pod 级别，影响节点级操作需谨慎并明确授权。
• Q：如何保证实验安全可回滚？
  A：设置短观测窗口、自动恢复脚本与限速策略；并在实验前备份关键配置。
• Q：能否与 CI 集成？
  A：可以，把可控实验作为验证阶段，并确保失败不会自动阻塞紧急发布。

参考与进阶阅读（便于你继续深入）

• LitmusChaos 官方文档（阅读你当前版本的 CRD 与示例）
• 混沌工程实践：Chaos Engineering 原则与案例
• Prometheus + Grafana 指标接入与告警最佳实践

好了，就像做一道实验菜，先从最简单的口味开始，把步骤熟练了再慢慢加料。你可以先按上面的步骤在本地做一遍 HelloWorld 的 pod-delete，然后根据结果慢慢把探针、监控和 CI 流程接上去，别忘了把遇到的问题记录下来——这些记录往往比一次成功更有价值。