Go服务K8s健康检查开销源于中间件干扰、依赖阻塞、日志刷屏及端口竞争；应分离探针端口、区分/livez与/readyz语义、禁用日志、压缩响应、设严格超时，并用原子变量动态控制就绪状态。
Go 服务在 Kubernetes 中的健康检查开销，主要来自探针端点被中间件拖慢、依赖检查阻塞、日志刷屏、或与业务端口共用导致竞争——这些问题不解决，探针反而会成为服务不稳定源头。
避免中间件干扰 /healthz 路由
很多 Go Web 框架（如 Gin、Echo）默认给所有路由套上日志、鉴权、panic recover 等中间件。这些对业务请求合理，但对每秒一次的 /healthz 是纯负担：
- recover 中间件捕获 panic 是好意，但健康端点本就不该 panic；
- 日志中间件每秒记一条，日志量翻倍，还可能撑爆
emptyDir卷； - 鉴权中间件若触发 JWT 解析或远程校验，响应直接超时。
正确做法是绕过框架主路由，单独启动一个轻量 http.ServeMux：
probeMux := http.NewServeMux()
probeMux.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
w.WriteHeader(http.StatusOK)
})
go http.ListenAndServe(":8081", probeMux)
然后在 Deployment 中为容器声明两个端口：containerPort: 8080（业务）、containerPort: 8081（探针），并在 livenessProbe 和 readinessProbe 中明确指定 port: 8081。
立即学习“go语言免费学习笔记（深入）”；
区分 /livez 和 /readyz 的检查粒度
混淆二者语义是高频误配点：/livez 失败 → K8s 杀进程；/readyz 失败 → K8s 摘流量但进程继续运行。它们不该共享 handler，也不该共享检查逻辑：
-
/livez只查进程自身是否卡死：用atomic.LoadInt32(&isRunning)或简单 select + timeout 判断主 goroutine 是否响应； -
/readyz可查 DB 连接、Redis Ping、配置加载状态，但必须设严格超时（如context.WithTimeout(r.Context(), 300 * time.Millisecond)）； - 千万别在
/livez里调db.PingContext——DB 临时抖动就触发无限重启（CrashLoopBackOff）。
禁用日志、压缩响应、控制超时
高频探针若打满日志或返回冗余内容，会放大资源消耗：
- 不要在
/livezhandler 中调log.Printf或fmt.Println；错误只打到stderr且限 error 级别； - 响应体保持极简：
w.Write([]byte("ok"))，别用json.NewEncoder做结构化输出（除非你真需要人工 curl 验证）； - K8s 探针默认超时是 1 秒，你的 handler 必须在
timeoutSeconds - 100ms内完成；例如timeoutSeconds: 2，代码里就要用context.WithTimeout(ctx, 1900 * time.Millisecond)； - 避免任何阻塞操作：文件读写、同步 channel、无缓冲 channel 发送、未设超时的 HTTP 调用。
用原子变量动态控制 readiness 状态
服务启动初期、收到 SIGTERM 或检测到关键错误时，不能靠“等探针失败再摘流量”，而应主动通知 K8s：“我现在不可服务”：
- 定义全局变量：
var isReady int32 = 0； - 主服务初始化完成后，调
atomic.StoreInt32(&isReady, 1)； -
/readyzhandler 中先判断：if atomic.LoadInt32(&isReady) == 0 { http.Error(w, "not ready", http.StatusServiceUnavailable); return }； - 收到
SIGTERM后，立即atomic.StoreInt32(&isReady, 0)，再 sleep 等待现有请求 drain。
这个模式的关键在于：K8s 不会“感知”你的业务状态，它只信 HTTP 返回码。你得自己把状态映射成 200/503，而不是指望探针自动适配。
