Istio故障注入失败主因是VirtualService配置错误或sidecar未注入；需确认Pod含istio-proxy、host匹配DNS、规则匹配请求协议与header，并通过Envoy日志验证而非Go日志。
istioctl 命令注入失败：HTTP 503 或流量无响应
Istio 的故障注入不是在 Go 代码里写的，而是在 VirtualService 资源中声明的。Go 应用本身不需要改一行逻辑——它只是被动接收被 Istio 劫持并篡改后的请求。如果你在 Go 服务里加了重试、超时或熔断逻辑，反而可能掩盖故障注入效果，导致你以为没生效。
常见错误现象：curl 返回 503、连接直接拒绝、延迟没出现、错误率始终为 0。
- 确认目标服务已注入 sidecar：
kubectl get pod -l app=your-go-app中每个 Pod 必须有 2 个容器（app + istio-proxy） -
VirtualService的host必须严格匹配服务 DNS 名（如your-go-service.default.svc.cluster.local），不能写成localhost或短名 - 故障规则只对匹配的
route生效；若你写了http:但请求走的是 HTTPS（或 mTLS），规则会被跳过 - 延迟/中断只作用于匹配的子集请求（比如带特定 header），漏掉
match条件就等于没配
Go 服务日志里看不到故障痕迹？检查 Envoy 访问日志格式
Istio 的故障（如延迟、abort）发生在 Envoy 代理层，Go 应用进程本身收不到“被注入失败”的通知。它只看到一个慢请求或一个 503 响应体——除非你主动解析响应状态码和耗时，否则日志里就是普通错误。
想验证故障是否真实发生，别看 Go 日志，要看 Envoy 的访问日志：
立即学习“go语言免费学习笔记（深入）”；
- 启用访问日志：
istioctl install --set meshConfig.accessLogFile="/dev/stdout"（或 patch 现有控制面） - 查日志：
kubectl logs -l app=your-go-app -c istio-proxy | grep "503\|delayed" - Envoy 日志字段
upstream_service_time和response_code才反映真实故障行为 - Go 代码里如果用了
context.WithTimeout，可能比 Istio 的 5s 延迟更早 cancel 请求，导致你永远收不到那个“被延迟的响应”
想用 Go 写混沌控制器？绕不开 Istio 的 CRD 客户端
如果你需要动态启停故障（比如按测试阶段开关 delay/abort），就得用 Go 操作 Kubernetes API 写 VirtualService。这不是调用某个 SDK 函数就能搞定的事，得处理版本兼容、资源冲突、权限 RBAC。
关键点：
- 用官方 client-go + istio.io/api 生成的 clientset，不要手写 YAML POST；
istio.io/client-go已归档，必须用istio.io/client-go/pkg/apis/networking/v1对应的类型 - 更新
VirtualService时，必须保留resourceVersion，否则会因乐观锁失败；建议用Patch而非Update - 故障字段在
http.route.fault下：delay是networkingv1.HTTPFaultInjection_Delay，abort是networkingv1.HTTPFaultInjection_Abort，拼错字段名会导致整个 VS 不生效且无报错 - 注意 Istio 版本差异：1.16+ 把
percentage改成percentage: {value: 50}，旧写法percentage: 50会静默忽略
本地开发联调时故障不触发？Sidecar 注入和目标规则常被忽略
本地用 kind 或 minikube 跑 Istio，最容易卡在两个地方：sidecar 没自动注入，或者 DestinationRule 缺失导致流量直连不进 Envoy。
- 确认命名空间开启了自动注入：
kubectl label namespace default istio-injection=enabled（部署前打标） - 必须存在对应
DestinationRule，哪怕只定义最简的host和subsets；没有它，Istio 不知道该把流量导向哪个 subset，故障规则不会绑定到任何实例 - 本地调试时，别用
localhost:8080直连 Go 服务 —— 这绕过了 Envoy；必须用集群内 DNS（如curl http://your-go-service.default.svc.cluster.local）或 port-forward 到 ingress gateway - 用
istioctl proxy-status看所有 Envoy 是否 synced；unsynced 的 proxy 不会执行新规则
真正难的不是写几行 Go 控制故障，而是让整个 Istio 数据面稳定同步、让网络路径不绕过代理、让故障粒度刚好卡在你想测的那个 HTTP 路由上。这些地方一出问题，Go 代码再正确也没用。
