使用 ChaosMesh 如何模拟一个节点网络延迟 200 ms？ - 问题详情 - 创脉思

解读

在 CouchDB 这类多主复制、离线优先的分布式数据库里，网络抖动直接决定复制延迟、冲突概率与最终一致性表现。国内面试官问“怎么用 ChaosMesh 打 200 ms 延迟”，表面考工具，实则验证候选人是否理解混沌工程与分布式一致性的闭环：

能否把混沌实验精准打到 CouchDB 节点而不误伤业务 Pod；
是否知道200 ms 在广域网属于“可预期”延迟，可用来验证同步筛选器、心跳超时与重试策略；
是否具备可观测意识，能在实验前后对比 _active_tasks、/_node/_local/_system、_scheduler/docs 等指标。
答不到“标签选择器 + 外部流量区分 + 可观测”三层，会被认为只会“跑工具”，不懂“定级、定量、定界”。

知识点

ChaosMesh 网络延迟模型：基于 Linux tc/netem，注入前自动备份 qdisc，实验结束秒级回滚；
CouchDB 集群发现机制：采用 _membership 与 _nodes 双向注册，延迟注入后节点间心跳>5 s 即触发“flapping”，需提前调大 cluster.quiet_period；
标签级精准打击：ChaosMesh 的 spec.selector.namespaces + labelSelectors 必须与 CouchDB StatefulSet 的 podTemplate 标签完全对齐，否则实验无效；
外部流量豁免：CouchDB 的 HTTP API 默认走 5984，需用 target.mode: one 并排除 port: 5984，防止压测客户端被延迟；
可观测指标：
- 复制进度：/_active_tasks 中 replication_id 的 docs_written 差值；
- 节点健康：/_up 返回的 status: ok 耗时；
- 冲突数：/_all_docs?conflicts=true 统计增长量；
国内云厂商限制：阿里云 Terway、腾讯云 VPC-CNI 均默认开 NetworkPolicy 审计日志，大规模注入可能被安全组拦截，需提前提交混沌工程白名单工单；
合规留痕：金融与运营商场景要求实验编号、回滚方案、值班人三要素写入 CMDB，否则审计无法闭环。

答案

步骤以 ChaosMesh v2.6 为例，假设 CouchDB 以 StatefulSet 形式部署在命名空间 couchdb，节点标签 app=couchdb,release=cluster1，需给任意一个节点持续注入 200 ms 延迟，持续 10 min，仅影响节点间 Erlang 分布式端口 4369 与 9100-9200，不影响客户端 5984 端口。

准备实验

# 确保 ChaosMesh CRD 已安装
kubectl apply -f https://mirrors.chaos-mesh.org/v2.6.0/crd.yaml
# 给 CouchDB ServiceAccount 授权查看 pod
kubectl create rolebinding couchdb-chaos-view \
  --role=pod-view --serviceaccount=couchdb:default -n couchdb

编写延迟实验 YAML couchdb-delay-200ms.yaml

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: couchdb-delay-200ms
  namespace: couchdb
spec:
  action: delay
  mode: one                       # 只打一个节点
  selector:
    namespaces:
      - couchdb
    labelSelectors:
      app: couchdb
      release: cluster1
  delay:
    latency: "200ms"
    correlation: "100"
    jitter: "0ms"
  direction: both                 # 出入双向
  duration: "10m"
  scheduler:
    cron: "@every 0m"             # 立即执行
  target:
    mode: one
  externalTargets: []             # 不对外部域名生效
  ports:                          # 仅对 CouchDB 内部端口生效
    - "4369"
    - "9100-9200"

执行与观察

kubectl apply -f couchdb-delay-200ms.yaml
# 实时查看注入节点
kubectl get networkchaos -n couchdb couchdb-delay-200ms -o jsonpath='{.status.experiment.podRecords[0].podName}'
# 监控复制延迟
while true; do
  curl -s http://couchdb-0.couchdb.couchdb.svc:5984/_active_tasks | jq '.[] | select(.type=="replication") | .docs_written'
  sleep 5
done

实验结束自动回滚，如需手动终止

kubectl delete networkchaos -n couchdb couchdb-delay-200ms

结果判读
若 200 ms 延迟下复制任务 docs_written 增速下降 ≤15%、/_up 接口仍 200 ms 内返回、冲突数增长 <1%，说明 CouchDB 的批量写与重试策略已适配该级别网络抖动；否则需调高 httpc.pool.timeout 或增加 worker_processes。

拓展思考

如何验证“多主写入冲突”而非“复制延迟”？
在注入 200 ms 的同时，用 ab -n 1000 -c 10 对两个节点同一条文档并发 PUT，再对比 _conflicts 长度；若冲突数随延迟线性上升，说明CouchDB 的 MVCC 冲突窗口≈RTT，需业务层加 ?_rev 校验或换用 bulk_docs 的 new_edits:false 模式。
如何做到“灰度”混沌？
利用 ChaosMesh 的 Workflow CRD，将延迟实验与可观测指标组合成 DAG：只有在上一步“复制延迟>400 ms”或“冲突数>5%”时才自动扩容 CouchDB 节点，并继续下一步 500 ms 延迟，实现逐级加压、自动熔断。
国内信通院《分布式数据库稳定性评测》已将“200 ms 网络延迟 30 min 零数据错写”列为必测项，面试官若追问“如何出报告”，需给出：
- 实验前后RPO=0 的 _changes 连续校验截图；
- QPS 衰减率 ≤20% 的 Prometheus 对比；
- 回滚时间 ≤60 s 的审计日志。

掌握以上，可把“跑工具”升级为“出标准”，直接对标金融级 CouchDB 上线准入要求。