netem仅能模拟网络层（L3/L4）故障，如Pod访问外部服务的延迟或丢包；无法影响存储IO（PV读写、块设备操作），因其属于文件系统/块设备层，须用Chaos Mesh io chaos、device-mapper delay target等方案实现。
在 kubernetes 生产环境中，对容器做存储 io 丢包和写延迟类弱网演练，**不能直接用 netem 模拟**——因为 netem 只作用于网络协议栈（l3/l4），而存储 io（如挂载的 pv、本地盘、块设备读写）走的是块设备层或文件系统层，不属于网络流量范畴。
明确边界：哪些“丢包/延迟”能用 tc+netem？
netem 只能干扰 Pod 出向网络流量，比如：
- Pod 访问外部数据库（MySQL、Redis）时的 TCP 包延迟或丢包
- Service 间 HTTP 调用的网络抖动
- DNS 查询超时或丢包
它无法影响以下行为：
- PV（如 NFS、Ceph RBD、本地 hostPath）的 read/write syscall 延迟
- 块设备层（如 /dev/sdb）的 I/O 超时、IO 错误注入
- 文件系统 sync、fsync 的阻塞或失败
真正有效的存储 IO 弱网/故障演练方式
要模拟存储层的“丢包”（即 IO 错误）和“写延迟”，需下沉到块设备或文件系统层，常用方法有：
- fio + ioengine=libaio + latency_target / rate_iops：在 Pod 内运行 fio，人为压测并触发 IO 队列积压，间接暴露高延迟场景
- blktrace + bcc 工具（如 biolatency、biosnoop）：可观测真实 IO 延迟分布，辅助验证是否已达瓶颈
- 使用 device-mapper 的 error target 或 delay target：需在宿主机上对底层块设备做映射（例如把 /dev/sdb 映射为 /dev/mapper/delay-sdb），可精确注入 IO 延迟、随机返回 -EIO
-
chaos-mesh 的 io chaos（支持 block device 和 file path 级别）：生产推荐。它通过 eBPF 或内核模块拦截 vfs_write/vfs_read 等系统调用，支持：
- write 延迟（毫秒级可控）
- write 失败（返回 ENOSPC、EIO、ETIMEDOUT）
- read 返回脏数据或校验错误（需配合特定文件系统）
生产落地建议（安全 & 可控）
避免在核心业务 Pod 所在节点直接操作底层设备。推荐组合方案：
- 用 Chaos Mesh v3.1+ 部署 io chaos，限定作用域为特定 PVC 名称或 mountPath（如 /data）
- 演练前确认 PV 类型：NFS 类需在 client 端注入（mount.nfs 参数加 soft,nolock,timeo=5），而非 server 端；块存储（RBD、iSCSI）才适合 device-mapper 或 eBPF 注入
- 设置自动恢复时间（例如 60s 后自动关闭 chaos），防止因异常未清理导致持续故障
- 搭配监控看板（如 Prometheus + node_exporter + ceph-mgr metrics），实时比对 iostat 中 await、r_await、w_await 和 %util 的突变
为什么不推荐在 Pod 里装 tc 对 /dev 目录限速？
tc 是网络流量控制工具，对块设备无效。即使你在容器里执行：tc qdisc add dev sdb root handle 1: tbf rate 1mbit burst 32kbit latency 400ms，会报错 Cannot find device "sdb" —— 因为容器默认看不到宿主机的 /dev/sdb，且 tc 不支持块设备命名空间穿透。
