




健康检查端点必须显式注册如/healthz,不可依赖根路径或中间件;就绪检查应仅验证本地服务状态与快速依赖探活(≤200ms),避免阻塞操作和日志输出。
http.HandleFunc 注册到根路径或明确路径Go 标准库的 http.ServeMux 不支持通配路由,/healthz、/health 这类路径必须显式注册。如果只注册了 /,而请求发到 /healthz,会返回 404 —— 这是部署到 Kubernetes 时最常见的失败原因。
实操建议:
http.HandleFunc("/healthz", healthHandler)
livenessProbe 和 readinessProbe 默认不带任何 header 或 cookie,中间件可能意外拦截或重定向db.Ping(),应改用非阻塞探测(如检查连接池是否已初始化、或使用 db.Stats().OpenConnections)net/http 实现轻量级就绪检查(readiness)就绪检查要反映服务是否能真正处理业务请求,但又不能太重。常见错误是把数据库 Ping() 放进 readiness handler,导致 DB 短暂抖动时整个服务被 K8s 下线。
推荐做法:
http.Client 带 Timeout: 200 * time.Millisecond 请求下游 /healthzlog.Println("readiness ok") 会刷爆日志系统func readinessHandler(w http.ResponseWriter, r *http.Request) {
select {
case <-serverReady:
w.WriteHeader(http.StatusOK)
w.Write([]byte("ok"))
default:

w.WriteHeader(http.StatusServiceUnavailable)
w.Write([]byte("not ready"))
}
}livenessProbe 和 readinessProbe 的参数差异直接影响 Go 服务行为Go 程序没有 JVM 那样的 GC 暂停感知能力,probe 配置不当会导致误杀或雪崩。关键区别在于:livenessProbe 失败会重启容器,readinessProbe 失败只是摘流量 —— 两者不能共用同一 handler。
典型配置陷阱:
initialDelaySeconds: 5 对 Go 服务往往不够:若主逻辑含 initDB()、loadConfig() 等同步耗时操作,5 秒内 handler 可能还没注册成功,probe 就已开始,直接触发重启循环periodSeconds: 10 + timeoutSeconds: 10 是危险组合:HTTP handler 若因锁竞争卡住 10 秒,probe 超时后立即发起下一次请求,形成并发雪球failureThreshold: 3(默认是 3),避免单次网络抖动导致误重启http.Server.Shutdown() 配合健康检查实现优雅终止健康检查本身不解决进程退出问题,但它是优雅终止的前提。当 K8s 发送 SIGTERM 后,需先停止接受新请求(即让 readiness 变为 false),再等活跃连接关闭。
关键步骤:
sync.WaitGroup 跟踪活跃 HTTP 连接数,在 handler 入口 wg.Add(1),defer wg.Done()
srv.Shutdown(),最后 wg.Wait()
ctx.Done():若 shutdown 已触发,/healthz 应立即返回 503,而不是等待 wg.Wait 完成最容易被忽略的一点:Go 的 http.Server 默认不启用 SetKeepAlivesEnabled(false),长连接可能拖慢 shutdown —— 生产环境建议显式关闭 keep-alive 或缩短 IdleTimeout。