Kubernetes生产环境服务韧性验证需真实触发网络延迟、CPU过载和磁盘异常三类故障：用tc+netem在Pod网络命名空间注入可控延迟；用stress-ng通过调试容器或initContainer引发CPU满载；对HostPath/Local PV执行只读挂载或用fio-fault注入I/O错误。
在Kubernetes生产环境中验证服务韧性，必须真实触发网络延迟、CPU过载和磁盘异常这三类典型故障，不能只靠日志猜测或本地模拟。
用tc+netem给Pod注入可控网络延迟
进入目标Pod的网络命名空间是前提，否则tc命令作用于宿主机网卡，对容器无效。
执行 kubectl debug -it <pod-name> --image=busybox --target=<pod-name> -- sh 启动调试容器，并自动共享目标Pod的网络命名空间。
运行 ip link show 确认主网卡名（通常为 eth0）→ 执行 tc qdisc add dev eth0 root netem delay 300ms 50ms 25% → 这条命令添加了均值300ms、抖动±50ms、25%相关性的延迟，比固定延迟更贴近跨地域链路真实表现。
【必须先清空已有qdisc，否则add会报错Device or resource busy】 若之前已配置过，先执行 tc qdisc del dev eth0 root 再重试。
用stress-ng让Pod内CPU持续100%飙升
方法一：直接在调试容器中运行（适合临时压测）
执行 apk add --no-cache stress-ng && stress-ng --cpu 4 --timeout 60s，启动4个CPU密集型进程持续60秒。
方法二：通过initContainer预埋（适合长期演练）
在Pod YAML的 initContainers 中加入：name: cpu-stressimage: quay.io/autamus/stress-ng:latestcommand: ["stress-ng", "--cpu", "2", "--timeout", "120s"]
注意：stress-ng镜像体积小、无依赖，比主流alpine+apk组合更可靠；若用busybox基础镜像，需额外编译或挂载二进制。
模拟磁盘损坏：从只读挂载到I/O错误注入
第一步：确认Pod挂载的持久卷类型
执行 kubectl get pod <pod-name> -o jsonpath='{.spec.volumes[*].persistentVolumeClaim.claimName}' 获取PVC名→再查 kubectl get pvc <pvc-name> -o jsonpath='{.spec.volumeName}' 得到PV名→最后执行 kubectl get pv <pv-name> -o jsonpath='{.spec.csi.driver}' 判断是否为CSI驱动。
第二步：对HostPath或Local PV执行只读挂载破坏
在Pod所在节点上，找到对应目录（如 /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~host-path/<volume-name>）→ 执行 mount -o remount,ro <path> → 容器内对该路径的写操作立即返回Read-only file system错误。
第三步：用fault-injection-tools注入I/O错误（仅限支持blkio cgroup v1的节点）
下载 github.com/chaos-mesh/fault-injection-tools → 编译生成 fio-fault → 在节点上运行：fio-fault --device /dev/sdb --error-rate 0.1 --error-type ioerr → 此时所有对该设备的I/O请求有10%概率返回EIO。
