Sidecar 注入由 Istio 在 Kubernetes 层面通过 mutating webhook 实现，与 Go 代码无关；需确保命名空间启用注入标签、webhook 正常运行，并验证 Pod spec 中是否存在 istio-proxy 容器。
Sidecar 注入不是 Go 代码控制的
Go 应用本身不负责注入 Sidecar，Istio 的注入发生在 Kubernetes 层面，靠 istio-injection=enabled 标签和 istiod 的 mutating webhook 触发。你在 Go 里写任何逻辑，都不会让 istio-proxy 容器自动出现。
常见错误现象：
— 启动 Go 服务后发现没有 istio-proxy 容器
— 在代码里调用 os.Setenv("ISTIO_META_…") 以为能触发注入
— 把 istioctl kube-inject 当成运行时命令硬塞进 Go 的 exec.Command
- 注入只在 Pod 创建时发生，由
admissionregistration.k8s.io/v1 MutatingWebhookConfiguration拦截并修改 Pod spec - Go 程序只需按标准方式监听
0.0.0.0:8080（别绑定127.0.0.1），让istio-proxy能拦截流量 - 确保命名空间打了标签：
kubectl label namespace default istio-injection=enabled - 验证是否注入成功：查看 Pod YAML，确认有
containers列表里包含istio-proxy
Go 服务要适配 Istio 的流量劫持机制
Istio 默认用 iptables 重定向所有入站/出站流量到 istio-proxy 的 15006/15001 端口。Go 程序必须配合这个模型，否则会连不上自己或下游服务。
典型问题：
— Go 用 http.DefaultClient 直连 http://other-svc:80 失败（未走 proxy）
— 本地调试时用 localhost:8080 调不通（proxy 不处理 localhost）
— HTTP/2 流量被 reset（未启用 ALPN 或 TLS 配置不匹配）
立即学习“go语言免费学习笔记（深入）”；
- 出站请求务必使用服务名（如
http://product-service.default.svc.cluster.local:80），而非localhost或127.0.0.1 - 若需绕过 proxy（比如健康检查探针），用
http://127.0.0.1:8080/healthz—— 这是唯一被istio-proxy显式放行的地址 - 启用 mTLS 时，Go 的 HTTP client 要配置
http.Transport.TLSClientConfig，否则可能被拒绝；但多数场景下 Istio 会自动处理，无需手动设证书 - 避免在 Go 中硬编码端口，优先从环境变量读取：
os.Getenv("PORT")，默认值设为"8080"
如何让 Go 日志和指标对齐 Istio 的可观测性链路
Istio 依赖应用透传 x-request-id、x-b3-traceid 等 header 来串联 trace。Go 不做适配，Jaeger 里就只有 istio-proxy 的 span，没有你的 handler。
容易忽略的点：
— 日志里没打印 trace ID，导致排查时无法关联 proxy 和业务日志
— Prometheus metrics 标签缺失 destination_service 等字段，Dashboard 里服务名显示为空
— 使用 log.Printf 而非结构化日志，无法被 Istio 的 access log parser 提取
- 用中间件提取并透传 tracing headers，例如：
r.Header.Get("x-request-id")记入 context 或日志字段 - 响应头中显式设置：
w.Header().Set("x-request-id", reqID)，保证下游也能继续传递 - 避免在 handler 中覆盖
Content-Length或Connection等 proxy 依赖的 header - 如果用 OpenTelemetry SDK，初始化时指定 propagator：
otel.SetTextMapPropagator(b3.New())，兼容 Istio 默认的 B3 格式
调试注入失败时该查哪几个地方
注入失败几乎从来不是 Go 代码的问题，但排查路径容易跑偏。重点盯住三处：命名空间标签、webhook 状态、Pod spec 是否被改写。
典型错误信息：
— error: failed to create resource: Internal error occurred: failed calling webhook "sidecar-injector.istio.io"
— kubectl get mutatingwebhookconfiguration istio-sidecar-injector 返回空
— kubectl describe pod xxx 里 Events 没有 injection 相关记录
- 先确认
istiodPod 是 Running 状态：kubectl -n istio-system get pods -l app=istiod - 检查 webhook 是否启用：
kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o jsonpath='{.webhooks[0].clientConfig.service.path}'应返回/inject - 看 Pod YAML 里有没有
annotations: sidecar.istio.io/inject: "true"—— 如果手动加了"false"，会覆盖 namespace 标签 - 临时禁用自动注入，用
istioctl kube-inject -f service.yaml | kubectl apply -f -验证原始 manifest 是否合法
最常被忽略的是：集群启用了 istio-cni 插件但网络策略没放开，导致 webhook 请求被拦截；或者 istiod 的 service account 缺少 mutatingwebhookconfigurations 的 update 权限。
