Sidecar健康检查必须由Go程序自身暴露独立HTTP端点（如/healthz、/readyz），禁用外部依赖和主服务路由，通过原子变量控制就绪状态，优先使用httpGet探针而非exec，并配置超时与优雅关闭。
Sidecar容器里怎么写健康检查逻辑
Go程序在Kubernetes中作为Sidecar运行时，健康检查不能依赖外部进程或文件锁，必须自己暴露HTTP端点并主动响应。Kubernetes的livenessProbe和readinessProbe只认HTTP状态码、TCP连通性或命令退出码，而Go侧唯一可控的就是HTTP handler。
常见错误是直接复用主应用的监听端口和路由，导致探针请求被主服务拦截或返回非预期内容（比如重定向、HTML页面、404）。Sidecar的健康端点必须独立、轻量、无副作用。
- 用
http.NewServeMux()单独注册/healthz和/readyz，不挂载到主路由树 - handler里只做内存态检查：例如检查本地channel是否可写、标志位是否置为true、依赖的gRPC连接是否
ConnectivityState() == connectivity.Ready - 避免在
/healthz中调用数据库、Redis或远程API——这会让liveness失败雪崩，违背“健康检查应反映自身状态”的原则 - 监听端口不要硬编码
:8080，从环境变量读取，比如os.Getenv("HEALTH_PORT")，方便Pod内端口隔离
如何让Kubernetes正确识别Sidecar的就绪状态
readinessProbe失败会导致Pod的IP从Service Endpoints中摘除，但Sidecar本身不接受流量，它的就绪与否应取决于它所代理/增强的服务是否就绪。比如一个Envoy Sidecar，只有当它成功加载xDS配置并建立控制平面连接后，才应返回200。
典型陷阱是把readinessProbe和livenessProbe配置成完全一致的路径和超时参数，结果liveness反复重启，readiness却一直上报“就绪”，造成流量打到半死不活的实例上。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 给
readinessProbe设更宽松的initialDelaySeconds（比如30s），让它等主容器真正启动完毕再开始探测 - 在Go代码中用原子变量
ready int32控制/readyz返回值，主逻辑初始化完成后再atomic.StoreInt32(&ready, 1) - Kubernetes YAML里显式设置
failureThreshold: 3和periodSeconds: 10，避免偶发网络抖动误判 - 如果Sidecar需等待另一个容器就绪（如init container写配置文件），可在
/readyz中os.Stat()检查关键文件是否存在，而不是轮询
为什么livenessProbe用HTTP比exec更可靠
在Go Sidecar里用exec探针执行curl -f http://localhost:8080/healthz看似简单，实际会引入额外失败路径：shell启动开销、curl二进制缺失、DNS解析（即使localhost也可能触发）、IPv6 fallback延迟。而HTTP探针由kubelet原生实现，绕过所有用户态依赖。
更隐蔽的问题是Go runtime的GC STW或大量goroutine阻塞时，exec可能因超时失败，但HTTP server依然能响应——因为HTTP handler在独立goroutine里，而exec探针会卡在fork/exec系统调用上。
- 始终优先用
httpGet方式，YAML中写httpGet: path: /healthz, port: 8080 - 若必须用
exec（如调试阶段），确保镜像包含curl且PATH正确，但上线前必须切回HTTP - Go服务启动后，立即用
http.ListenAndServe启动健康服务，不要等到主逻辑初始化完——否则initialDelaySeconds一过，探针就失败了
Golang健康端点的性能和信号处理细节
HTTP健康端点看似简单，但高频探测（比如periodSeconds: 3）下，goroutine泄漏、日志刷屏、锁竞争都可能拖垮Sidecar。另外，容器被SIGTERM终止时，健康服务若没优雅关闭，kubelet可能在旧连接上收到500响应，误判为异常。
最容易被忽略的是http.Server没有设置ReadTimeout和WriteTimeout，导致网络拥塞时goroutine堆积，最终OOMKilled。
- 用
http.Server{Addr: addr, Handler: mux, ReadTimeout: 2 * time.Second, WriteTimeout: 2 * time.Second}显式限流 - 在
main()里监听os.Interrupt和syscall.SIGTERM，调用server.Shutdown(context.WithTimeout(...))关闭健康服务 - 健康handler里禁止
log.Printf——每秒几十次探测会撑爆日志卷；改用io.Discard或条件日志（如仅在status != 200时记录） - 如果Sidecar同时跑多个goroutine（如watch configmap），
/healthz里别用runtime.NumGoroutine()作判断依据，它包含runtime内部goroutine，数值波动大
Sidecar健康检查真正的难点不在写几行HTTP代码，而在于厘清“谁的状态该由谁负责”——你的Go进程只该报告自己的存活与就绪，别替主容器背锅，也别替下游服务做健康兜底。
