2026 年 6 月 18 日至 19 日，KubeCon + CloudNativeCon India 在孟买举行。对 LitmusChaos 而言，这不只是一次常规参会，而是其迄今最重要的活动之一。来源摘要没有展开具体议程和现场成果，但 Flipkart、LitmusChaos 与 KubeCon 同时出现，本身就指向一个值得工程团队关注的趋势：混沌工程正从少数可靠性专家的专项实验，逐步进入 Kubernetes 团队的日常交付流程。
为什么这类行业交流值得关注
云原生系统的故障通常不发生在单个进程内部，而是跨越 Pod、节点、网络、存储和外部依赖。传统测试可以证明代码在预期输入下工作，却很难回答这些问题：
- 一个 Pod 被删除时，服务是否真的无感恢复？
- 副本重建期间，流量是否会打到尚未就绪的实例？
- 告警能否在用户投诉前触发？
- 值班手册中的恢复步骤是否仍然有效？
LitmusChaos 采用 Kubernetes 原生资源描述实验，这让故障注入可以像 Deployment 一样接受版本控制、代码审查和流水线执行。其价值不只是“制造故障”，而是把可靠性假设变成能够重复验证的工程资产。
从一次 Pod 删除实验开始
如果集群已经安装 LitmusChaos，并且存在名为 pod-delete 的 ChaosExperiment 与具备权限的 litmus-admin ServiceAccount，可以这样实践。下面的清单先部署 3 个 Nginx 副本，再创建一个 ChaosEngine，持续删除匹配 app=demo-nginx 的 Pod。
运行前需要确认：实验应放在隔离的测试集群或测试命名空间中；不同 LitmusChaos 版本的 CRD 字段和安装方式可能有差异，应以当前版本文档为准。
apiVersion: v1
kind: Namespace
metadata:
name: chaos-test
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: demo-nginx
namespace: chaos-test
spec:
replicas: 3
selector:
matchLabels:
app: demo-nginx
template:
metadata:
labels:
app: demo-nginx
spec:
containers:
- name: nginx
image: nginx:1.27-alpine
ports:
- containerPort: 80
readinessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 2
periodSeconds: 3
---
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
name: demo-pod-delete
namespace: chaos-test
spec:
appinfo:
appns: chaos-test
applabel: 'app=demo-nginx'
appkind: deployment
engineState: active
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'
将内容保存为 pod-delete-demo.yaml 后执行：
kubectl apply -f pod-delete-demo.yaml
kubectl get pods -n chaos-test -w
另开一个终端观察实验和应用状态：
kubectl get chaosengine,chaosresult -n chaos-test
kubectl get deployment demo-nginx -n chaos-test
实验结束后清理资源：
kubectl delete namespace chaos-test
这个示例验证的是 Kubernetes 能否重建副本，但“Pod 最终恢复”不等于“用户没有受到影响”。实际项目还应同时采集请求成功率、P95/P99 延迟、就绪副本数和告警触发时间，并为实验设置明确的中止阈值。
把现场热度转化为交付机制
会议可以让团队看到工具和案例，但可靠性提升最终取决于仓库中的配置与流水线。一个更稳妥的落地顺序是：
- 从测试环境中的低风险故障开始，例如删除单个无状态 Pod。
- 为实验写出可验证的假设，例如“任意一个副本消失后，5xx 比例仍低于 1%”。
- 设置停止条件，指标越过错误预算时立即终止实验。
- 将 ChaosEngine、监控查询和结果记录纳入版本控制。
- 在人工审核通过后，再把稳定实验接入定时任务或发布流水线。
不要一开始就注入节点宕机、磁盘故障或跨可用区网络中断。这些实验影响面更大，还可能暴露云平台、存储系统和恢复流程之间的耦合。团队需要先确认权限边界、业务低峰窗口、回滚路径和责任人。
采用时真正要检查的事项
Flipkart 与 LitmusChaos 在 KubeCon + CloudNativeCon India 2026 的亮相，说明混沌工程仍是云原生可靠性讨论中的重要组成部分。不过，工具本身不会自动带来韧性。准备采用 LitmusChaos 的团队应检查四件事：实验是否有业务假设、指标是否可观测、故障范围是否受控、结果是否能推动修复。
当每次实验都能留下配置、指标和整改记录时，混沌工程才不再是一场演示，而会成为持续验证 Kubernetes 系统恢复能力的日常机制。