go应用部署前必须监听0.0.0.0而非127.0.0.1，因envoy sidecar依赖iptables劫持发往0.0.0.0或clusterip的流量；绑定127.0.0.1会导致入向请求无法到达sidecar，且健康检查失败、pod反复重启。
Go应用部署前必须监听 0.0.0.0，不能只绑 127.0.0.1
Envoy sidecar 和 Go 应用容器在同一个 Pod 内共享网络命名空间，但流量劫持依赖 iptables 规则——它只拦截发往 0.0.0.0（或具体 ClusterIP）的请求。如果你的 Go 服务写成 http.ListenAndServe("127.0.0.1:8080", nil)，sidecar 就收不到任何入向流量，kubectl logs -c istio-proxy 里几乎没访问日志，而你的应用日志却显示“已启动”。
正确做法是：显式绑定 0.0.0.0:$PORT，且确保 $PORT 与 Kubernetes Service 的 targetPort 一致。常见错误包括：
- 硬编码端口（如
":8080"），但 Deployment 中容器ports没配containerPort: 8080 - 用了环境变量但没 fallback，比如
os.Getenv("PORT")返回空字符串导致监听失败 - 健康检查路径（如
/healthz）没暴露，导致 readiness probe 失败、Pod 卡在ContainerCreating或反复重启
启用 sidecar 注入必须确认两层配置：命名空间标签 + Pod 注解
自动注入不是“装了 Istio 就生效”，而是靠 Kubernetes 准入控制器（MutatingWebhookConfiguration）识别两个条件：
- 命名空间打了
istio-injection=enabled标签：运行kubectl label namespace default istio-injection=enabled - Pod 模板中没有显式禁用，即不能有
sidecar.istio.io/inject: "false"注解；若有，则覆盖命名空间级设置
验证是否注入成功，不要只看 READY 列是否为 2/2，还要执行：
kubectl get pod my-go-app-7b8d9c4f56-xzabc -o jsonpath='{.spec.containers[*].name}'
输出应包含 my-go-app 和 istio-proxy；若只有前者，说明注入失败，常见原因：
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 命名空间标签拼错（比如写成
istio-inject或istio-injection=disabled） - Istio 控制平面组件异常：
kubectl get pods -n istio-system中istiod状态不是Running - Deployment 创建早于命名空间打标，需删掉 Pod 让 ReplicaSet 重建
出向调用必须用 Kubernetes Service 名，不能用 IP 或 localhost
Envoy sidecar 默认只劫持目标为集群内 DNS 名（如 user-service.default.svc.cluster.local）或短名（如 user-service）的流量。如果你的 Go 代码里写的是 http.Get("http://10.96.123.45:8080") 或 http.Get("http://localhost:8080")，请求会绕过 sidecar，既无 mTLS，也无重试、超时等治理能力。
正确方式是：直接使用 Service 名 + 端口（Kubernetes DNS 自动解析）：
resp, err := http.Get("http://order-service:8080/v1/orders")
注意以下细节：
- Service 必须存在，且
selector能匹配到目标 Pod 的 labels - 如果跨 namespace 调用，必须用完整域名格式：
order-service.production.svc.cluster.local - HTTP 客户端要传播 tracing header，例如用 OpenTelemetry 的
propagators.HTTPTraceContext注入traceparent
调试 Istio 流量失败，优先查这三个地方
当请求返回 503、连接拒绝或超时，别急着改 Go 代码——90% 的问题出在 Istio 层。按顺序排查：
- 运行
istioctl proxy-status：看对应 Pod 的状态是否为SYNCED；若为NOT SENT，说明 istiod 没把配置推下去 - 进 sidecar 容器查监听端口：
kubectl exec -c istio-proxy my-go-app-7b8d9c4f56-xzabc -- netstat -tlnp | grep :15001，确认 Envoy 正在监听入向端口（默认 15001） - 抓包验证流量路径：
kubectl exec -c istio-proxy my-go-app-7b8d9c4f56-xzabc -- tcpdump -i any port 8080 -w /tmp/app.pcap，再用kubectl cp拿出来分析，看请求是否真进了 Envoy
最易被忽略的是：Istio 的 DestinationRule 和 VirtualService 配置错误会导致路由静默失败——没有报错，但流量根本到不了后端。这类配置不生效时，istioctl analyze 能快速定位语法或引用问题。
