Chaos Mesh是CNCF毕业项目，专为Kubernetes设计，支持声明式、精细化网络丢包与延迟注入，通过CRD实现可控、可恢复、可观测、权限隔离的生产级弱网演练。
在 Kubernetes 生产环境中对容器做精细化网络丢包和延迟注入，核心是“可控、可恢复、可观测、不越权”。不能直接进容器敲 tc，也不能随意停 Pod 或改节点配置。必须依托平台化、声明式、带权限隔离的混沌工程能力。
用 Chaos Mesh 实现声明式弱网控制
Chaos Mesh 是 CNCF 毕业项目，专为 K8s 设计，支持毫秒级延迟、百分比丢包、乱序、DNS 故障等，且所有操作通过 CRD 声明，天然适配 GitOps 和生产审批流程。
- 安装后，只需一条
kubectl apply即可注入故障，无需登录节点或容器 - 支持按 label 精准选择目标（如
app: payment-service），避免误伤其他服务 - 自动注入
NET_ADMIN权限并挂载/var/run/docker.sock（仅限 DaemonSet 的 chaos-daemon 容器，业务容器零侵入） - 所有实验自带超时自动恢复（
duration字段），生产环境可设为 2–5 分钟，失败即回滚
示例：对支付服务注入 300ms ±80ms 延迟 + 3% 随机丢包
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
name: payment-weaknet
spec:
action: delay
mode: one
selector:
labelSelectors:
app: payment-service
delay:
latency: "300ms"
jitter: "80ms"
loss:
loss: "3%"
duration: "3m"
用 ChaosBlade 进行容器粒度精准干预
当需要更细粒度（比如只影响 Pod 中某个特定容器，或指定某几个容器 ID），或已有标准化运维脚本体系时，ChaosBlade 更灵活。它支持命令行 + YAML 双模式，且能绕过 K8s API 直接调用 Docker daemon（需提前配置 --docker-endpoint）。
- 适合灰度发布前的单点验证，例如：“只给 frontend 容器加延迟，backend 不动”
- 支持
--container-ids或--container-names显式指定，避免同 Pod 多容器间干扰 - 丢包命令示例：
blade create k8s container-network loss --namespace default --names checkout-pod --container-names app --percent 5 - 延迟命令示例：
blade create k8s container-network delay --namespace default --names checkout-pod --time 200 --offset 40（200ms 基础 + ±40ms 抖动）
规避风险的关键实践
生产环境不是测试沙盒，弱网演练必须守住三条红线：
-
范围锁定：永远使用
labelSelectors或names明确限定目标，禁用mode: all；对核心服务（如订单、支付）务必加--evict-percent 10或--evict-count 1 -
可观测先行：执行前确保 Prometheus 已采集
container_network_receive_bytes_total、envoy_cluster_upstream_cx_rx_bytes_total、业务层超时率等指标；推荐搭配 Grafana 看板实时盯屏 -
权限最小化：Chaos Mesh 的 ServiceAccount 仅需
networkchaosRBAC 权限；ChaosBlade 的 worker 节点只需docker.sock读+有限 exec 权限，禁止授予cluster-admin
不建议在生产中直接用 tc 或手动脚本
虽然 tc qdisc add dev eth0 root netem delay 300ms loss 3% 最底层、最精确，但它要求容器启动时带 --cap-add=NET_ADMIN，且规则无生命周期管理——Pod 重启即失效，人工清理易遗漏，故障残留风险高。生产环境应避免任何需登录容器或节点执行的命令。
同理，自定义 Dockerfile 固化 tc 规则、或用 ATC 做全局代理的方式，都属于“非声明式、难审计、难回滚”，只适合开发/预发环境快速验证。
