Go应用无需适配Sidecar健康检查，但需确保K8s和Sidecar能准确判断其状态：启用mTLS时HTTP探针会因无证书被拒绝，应通过Istio健康代理端口（如15021）或配置重定向解决。
Go 应用本身不用“适配”Sidecar 的健康检查逻辑，但必须让 Kubernetes 和 Sidecar 能正确判断它的状态——否则 readinessProbe 会永远成功（TCP 检查被 Sidecar 拦截），或 livenessProbe 会持续失败（HTTP 检查被 mTLS 拒绝）。
Sidecar 注入后 HTTP 健康检查总失败？先看是否开了双向 TLS
开启双向 TLS（mTLS）后，Kubelet 发起的 httpGet 健康检查请求会被 Envoy 拒绝，因为 Kubelet 没有服务网格颁发的证书。这不是 Go 代码的问题，而是流量路径被拦截后语义错位。
- 确认是否启用全局 mTLS：
istioctl authn tls-check <pod-name><namespace></namespace></pod-name>，若显示CONNECTION STATUS: OK但健康检查仍失败，大概率是探针没重定向 - 不改代码的最快解法：在 Pod annotation 中加
sidecar.istio.io/healthCheckPath: "/healthz"和sidecar.istio.io/healthCheckPort: "15021"，让探针直接打到 Istio 的健康检查代理端口 - 更推荐的做法是启用健康检查重定向：给 Deployment 加 annotation
traffic.sidecar.istio.io/includeInboundPorts: "*"+readiness.status.sidecar.istio.io/timeoutSeconds: "1"，再配合 Istio 的自动重定向策略
为什么不能把 readinessProbe 指向 Go 自己的 /readyz 端口？
不是不能，而是容易误判。Sidecar 注入后，所有端口都会被 Envoy 监听，TCP 探针只要 Envoy 活着就返回成功，完全无法反映 Go 应用真实状态；而 HTTP 探针若未配置重定向，又会在 mTLS 下 403 或超时。
- Go 的
/readyz端点仍要保留，用于业务级就绪判断（如 DB 连通、配置加载完成、消费者 goroutine 启动） - 但 Kubernetes 的
readinessProbe应指向 Sidecar 提供的聚合健康端点，例如http://localhost:15021/healthz/ready（Istio 默认）或http://localhost:9999/health（Linkerd） - 若你坚持用 Go 自身端点，请确保它不依赖任何被 Sidecar 拦截的出站调用（比如不要在 /readyz 里调用另一个 mesh 内服务），否则形成循环依赖
Go 代码里怎么配合 readiness 状态变化？
Kubernetes 不会动态修改探针目标，但你可以让 Go 程序主动控制 /readyz 的返回值，从而影响 Endpoint 是否摘除。这和 Sidecar 无关，但能避免流量打入半死状态。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 用原子变量控制就绪态：
var isReady int32 = 0，启动完成后atomic.StoreInt32(&isReady, 1) - 在
/readyzhandler 中只做轻量检查：if atomic.LoadInt32(&isReady) == 0 { http.Error(w, "not ready", http.StatusServiceUnavailable); return } - 收到
SIGTERM时，先置isReady = 0，再等待活跃请求 drain（比如用http.Server.Shutdown()），最后退出 - 注意：这个机制只影响 readinessProbe 的结果，不影响 Sidecar 是否转发流量——Sidecar 仍会尝试转发，只是 K8s 不再把该 Pod 加入 Endpoint 列表
StartupProbe 怎么设才不被 Sidecar 干扰？
Sidecar 容器启动通常比 Go 主容器慢 2–5 秒，如果 StartupProbe 直接访问 Go 的端口，很可能在 Sidecar 还没完成 iptables 规则注入前就失败，导致整个 Pod 被重启。
- StartupProbe 必须等 Sidecar 就绪后再检查 Go 应用，推荐方式是：先用 exec 探针检查
curl -f http://localhost:15021/healthz/ready（Istio）或nc -zv localhost 4191（Linkerd） - 再用 HTTP 探针访问 Go 的
/healthz，initialDelaySeconds设为 10，failureThreshold设为 15，避免因 Sidecar 启动抖动误判 - 不要在 StartupProbe 里执行耗时操作（如拉取远程配置），那属于 Go 应用自身初始化逻辑，应由主进程处理
真正容易被忽略的是：Sidecar 健康检查重定向不是开个开关就完事，它依赖 Istio 控制平面版本、Sidecar 容器镜像一致性、以及 Pod annotation 的优先级顺序。哪怕只漏掉一个 traffic.sidecar.istio.io/includeInboundPorts，/healthz 请求就仍会走 mTLS 链路并失败。
