PodChaos 失效主因是 labelSelector 未匹配目标 Pod，需用 kubectl 查真实 label、选稳定 label、加 podPhase: Running，并检查 controller 日志是否报“no matching pods”。
Chaos Mesh 的 PodChaos 类型为什么总不生效？
不是 YAML 写错了，大概率是目标 Pod 没被正确选中。Chaos Mesh 依赖 labelSelector 匹配 Pod，但 Go 微服务常带动态 label（比如 pod-template-hash 或 app.kubernetes.io/version），手动写死容易漏掉。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先用
kubectl get pod -n <ns> --show-labels看真实 label，别信 deployment yaml 里写的 - 优先用稳定 label，比如
app: user-service，避免用version或release这类滚动更新时会变的 - 加个
podPhase: Running字段，防止 chaos 在 Pod 启动中就被调度，实际没注入成功 - 检查 Chaos Mesh controller 日志：
kubectl logs -n chaos-testing deploy/chaos-controller-manager | grep -i "podchaos"，看有没有no matching pods报错
Go 应用里怎么让 NetworkChaos 真正丢包或延迟？
Go 默认用 net/http，底层走系统 socket，而 NetworkChaos 是通过 eBPF 或 tc 注入网络异常——它只作用于 Pod 的 eth0 流量，不碰 Go runtime 自己的 DNS 解析或连接池复用逻辑。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 确保目标 Pod 启用了
hostNetwork: false（默认就是），否则 tc 规则不会生效 - 丢包率设太高（比如 >30%）可能导致 Go 的 HTTP client 直接报
context deadline exceeded，而不是你预期的慢请求；建议从5%开始试 - 如果服务间用 gRPC，记得加
grpc.WithBlock()和合理超时，否则 NetworkChaos 延迟一上来，gRPC 会快速失败，看不出“渐进式降级”效果 - 验证是否生效：进 Pod 执行
ping -c 3 <target-ip>或curl -v --connect-timeout 2 http://other-svc，别只看业务日志
StressChaos 注入 CPU 压力后 Go 程序没卡住？
Go runtime 有 GPM 调度模型，即使 CPU 被占满，只要还有 P（processor），goroutine 仍可能被调度。StressChaos 的 stress-ng 进程只是“抢资源”，并不直接阻塞 Go 的 runtime.Gosched() 或 channel 操作。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 别只压 CPU，搭配
MemoryChaos一起用——Go 的 GC 在内存紧张时更容易暴露出调度延迟和 OOM 风险 - StressChaos 的
workers数建议设为 Pod request 的 1.5 倍，比如 request=2，就设workers: 3；设太高会被 kubelet kill，太低压不出效果 - 观察指标重点看
go_goroutines和go_gc_duration_seconds，而不是 CPU usage——后者可能虚高，但 goroutine 积压、GC 频次飙升才是真问题 - 注意 Go 版本：1.21+ 对 cgo 调用做了优化，如果 stress-ng 启用了
--vm（内存压力），可能触发更多 cgo 调用，反而掩盖了纯 Go 场景的问题
本地开发环境跑不了 Chaos Mesh？用 Kind + chaos-mesh-kind 行不行？
可以跑，但 Kind 默认禁用 cgroups v2 和部分内核模块（比如 nf_conntrack），而 Chaos Mesh 的 NetworkChaos 和 IOChaos 严重依赖这些。直接用官方 chaos-mesh-kind 脚本，大概率 network 故障不生效。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- Kind 集群创建时必须加配置：
containerdConfigPatches开启systemd_cgroup = true，并挂载/sys/fs/cgroup:/sys/fs/cgroup - 用
kind create cluster --config kind-chaos.yaml，别用默认集群；yaml 里要显式指定disable-cni: false，否则 NetworkChaos 的 tc 规则无法注入 - Mac 用户尤其注意：Docker Desktop 的 Linuxkit 内核不支持
tc netem的某些 mode（如corrupt），建议改用delay或loss，别试duplicate - 验证是否就绪：进 chaos-controller-manager 容器，执行
lsmod | grep nf_conntrack和tc qdisc show dev eth0，两个都得有输出
最常被忽略的一点：Chaos Mesh 的 CRD 不会自动传播到所有 namespace，PodChaos 必须和目标 Pod 在同一个 namespace，或者明确设置 scope: cluster 并授予 clusterRole——很多人卡在这一步，却去调 stress-ng 参数。
