使用 ChaosBlade 模拟容器网络 200 ms 延迟 - 问题详情 - 创脉思

解读

面试官想验证三件事：

你是否真的在生产级容器环境里做过网络故障演练，而不是只跑过“hello-world”实验；
能否把 ChaosBlade 的“宿主机视角”与 Docker 的“容器视角”精准对齐，避免误杀宿主机网络；
演练结束后，能否干净无损地恢复，并给出可观测性数据证明延迟确实生效且仅影响目标容器。

一句话：不仅要“能搞”，还要“搞得不背锅”。

知识点

ChaosBlade 底层依赖 Linux tc/netem 模块，必须在容器共享的宿主机网络命名空间里注入，因此需要 --target-network 与 --container-id 联合使用；
Docker 的 Cgroup 与 Network Namespace 隔离机制决定了：
- 若容器使用 bridge 模式，宿主机 veth 接口是最佳注入点；
- 若使用 host 模式，需额外加 --exclude-port 防止把 ssh 端口也延迟；
国内主流镜像源（阿里云、清华）已同步 ChaosBlade 包，但生产内网建议提前拉取并做 sha256 校验，避免演练当天因网络策略失败；
恢复时必须执行 blade destroy UID，否则 tc 规则残留会导致后续 POD/容器重启仍带延迟，成为“背锅侠”；
观测手段：
- 容器内 ping -c 100 <目标> 看 rtt 均值；
- 宿主机 tc -s qdisc show dev vethxxx 确认排队规则；
- 若接入 Prometheus+Grafana，对比演练前后业务 P99 延迟曲线，形成闭环证据链。

答案

实操步骤（以 Docker 单机 20.10.x、CentOS 7.9、bridge 网络为例，全部在运维堡垒机上执行，已提前申请变更单）：

前置检查

docker ps | grep target-app
CONTAINER_ID=7f8b9c12d3e4
docker inspect $CONTAINER_ID -f '{{.State.Pid}}'
# 确认容器运行并拿到 Pid

安装 ChaosBlade（内网 Harbor 已镜像）

tar -xzf chaosblade-1.7.3-linux-amd64.tar.gz -C /opt/
ln -s /opt/chaosblade-1.7.3/blade /usr/local/bin/blade
blade version

定位容器的宿主机 veth

# 通过 Pid 找到 network namespace
nsenter -t <Pid> -n ip link show eth0@host
# 得到宿主机侧 veth 名，例如 veth1234

注入 200 ms 单向延迟（±20 ms 抖动，丢包 0%）

blade create network delay \
  --interface veth1234 \
  --time 200 \
  --offset 20 \
  --timeout 300 \
  --container-id $CONTAINER_ID \
  --target-network
# 返回实验 UID，例如 4f1a2b3c5678

验证
容器内执行

ping -c 10 172.16.0.5
# 平均 rtt ≈ 200 ms 即达标

宿主机确认

tc -s qdisc show dev veth1234
# 看到 netem delay 200ms 20ms

业务观测
登录 Grafana，找到 “checkout-service P99 延迟” 面板，确认曲线从 30 ms 升至 230 ms，误差范围内即验收通过。

清理

blade destroy 4f1a2b3c5678
tc -s qdisc show dev veth1234
# 无 netem 残留即恢复成功

复盘报告
在 Confluence 输出《容器网络延迟演练报告》，包含目标、范围、观测、结论、风险、改进项，抄送 SRE 与业务负责人，闭环完成。

拓展思考

如果目标容器运行在 Kubernetes 集群，ChaosBlade 仍依赖宿主机网络命名空间，需通过 kubectl debug 或 nsenter 进入对应节点，切勿直接对 POD IP 注入；
对 Service Mesh（Istio） 场景，可把 ChaosBlade 与 VirtualDestinationRule 对比：
- Istio 在 L7 注入延迟，无需宿主机 root，但只能影响 HTTP/gRPC；
- ChaosBlade 在 L3/L4，覆盖所有协议，却需要节点级权限；
  面试时可主动提出“按协议栈分层选型”，体现深度。
国内金融合规要求演练前必须做 “影响面评估”，可提前用 blade prepare 打快照，结合 蓝鲸、夜莺 做配置基线对比，防止“演练”变“事故”；
未来可接入 ChaosMesh CRD，把 200 ms 延迟声明为 YAML，纳入 GitOps 流水线，实现“故障即代码”，让面试官看到你从“单次实验”到“持续混沌工程”的演进思路。