Flipkart 用 LitmusChaos 给 Kubernetes 做混沌工程：大规模电商的可靠性实战

预计阅读时间：7 分钟

印度最大电商平台 Flipkart 刚拿下 CNCF 终端用户案例研究大赛的奖项，核心看点只有一个：把 LitmusChaos 深度嵌入 Kubernetes 原生架构，在生产环境系统性注入故障，用可控的混乱换取真实的可靠性。这对任何跑在 K8s 上的业务都有直接参考价值。

为什么混沌工程不是"找麻烦"

大规模电商的流量峰值极端——大促期间秒级请求量可以翻几十倍。传统做法是压测 + 容量预留，但压测只验证"正常负载下系统能扛"，不验证"某个核心组件突然挂了，业务还能不能活"。混沌工程补的就是这块盲区：主动在可控条件下制造故障，观察系统真实反应，再补短板。

Flipkart 的选择是 LitmusChaos——一个 CNCF 孵化项目，专为 Kubernetes 设计的混沌编排框架。它的优势在于完全 K8s 原生：实验定义是 CRD，调度靠 Operator，结果采集用 Kubernetes 事件机制，不需要额外部署一套独立管控平面。

LitmusChaos 的架构逻辑

LitmusChaos 的核心组件只有三个：

Chaos Operator：监听 ChaosExperiment CRD，负责创建和销毁实验 Pod。
ChaosExperiment CRD：每个实验是一个自定义资源，声明目标、故障类型、持续时间等参数。
ChaosEngine CRD：把实验和具体服务绑定，指定选哪些 Pod、注入什么故障、并行还是串行。

这套设计意味着你用 kubectl get chaosengine 就能看到所有正在跑的混沌实验，和查 Deployment 一样自然。实验结果也写成 CRD 状态，可以对接 GitOps 和监控体系。

Flipkart 的落地思路

根据公开信息，Flipkart 的做法有几个关键决策：

渐进式注入：先在 staging 跑全量实验，确认服务能承受后，再逐步把部分实验搬到生产，初始只做短时、低破坏性实验（比如 Pod 删除 5 秒后自动恢复）。
与 CI/CD 集成：混沌实验作为发布流水线的一环——每次重大版本上线前，自动触发一组基线实验，如果关键指标跌破阈值，发布自动阻断。
游戏日（GameDay）机制：定期组织跨团队演练，模拟多组件同时故障的场景，验证应急响应流程和告警链路。

这些思路不依赖 Flipkart 的内部工具，任何团队都可以复用。

动手跑一个 LitmusChaos 实验

下面是一个最小可运行的示例，在你的 K8s 集群上给一个 Deployment 做 Pod 删除实验。前提：你有一个可用的 K8s 集群（v1.24+），kubectl 已配置好。

安装 LitmusChaos

# 添加 Litmus Helm repo 并安装核心组件
helm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/
helm repo update

# 安装到 litmus namespace
kubectl create namespace litmus
helm install chaos-operator litmuschaos/litmus --namespace litmus

# 等待 Operator 就绪
kubectl wait --for=condition=available deployment/chaos-operator --namespace litmus --timeout=120s

准备实验目标

先部署一个简单的测试应用：

kubectl create deployment demo-app --image=nginx --replicas=3 --namespace default
kubectl wait --for=condition=available deployment/demo-app --namespace default --timeout=60s

创建 Pod 删除实验

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: demo-app-pod-delete
  namespace: default
spec:
  appinfo:
    appns: default
    applabel: "app=demo-app"
    appkind: deployment
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: "30"
            - name: CHAOS_INTERVAL
              value: "10"
            - name: FORCE
              value: "false"

TOTAL_CHAOS_DURATION 是实验总时长（秒），CHAOS_INTERVAL 是每次删除间隔，FORCE=false 表示优雅删除而非强制杀 Pod。生产环境务必先用 false。

# 创建 RBAC（简化版，生产环境应收紧权限）
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: litmus-admin
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: litmus-admin-binding
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: litmus-admin
    namespace: default
EOF

# 提交实验
kubectl apply -f chaosengine.yaml

# 观察实验状态
kubectl get chaosengine -n default -w

# 实验结束后查看结果
kubectl describe chaosengine demo-app-pod-delete -n default

实验跑完后，检查 Deployment 是否自动恢复了预期副本数。如果 30 秒内副本数回到 3 且服务正常响应，说明你的应用对 Pod 突然消失有足够韧性。

上生产前的检查清单

混沌工程的价值在于"在可控条件下发现不可控风险"，但如果控制本身不到位，实验本身就成了风险。上线前逐条确认：

实验范围明确：ChaosEngine 的 applabel 必须精确匹配目标，避免误伤无关服务。
自动回滚保障：每个实验设置 TOTAL_CHAOS_DURATION 上限，超时自动停止注入；同时确认目标 Deployment 有 readinessProbe 和足够副本。
告警链路验证：实验触发前，确认 Prometheus/Grafana 告警规则能覆盖该故障类型，否则实验结果无法闭环。
权限最小化：生产环境不要用 cluster-admin，为 ChaosServiceAccount 只授予目标 namespace 的必要权限。
先 staging 再生产：任何新实验类型，至少在 staging 跑三轮以上再考虑生产。

Flipkart 的获奖案例证明了一件事：混沌工程不是锦上添花的实验性工具，而是大规模 K8s 环境下可靠性的基础工程实践。LitmusChaos 的 K8s 原生设计让这件事的门槛比想象中低——从一个 Pod 删除实验开始，你就已经上路了。