如何在Golang中实现容器健康检查_Golang 容器健康监控方法

健康检查端点必须显式注册如/healthz，不可依赖根路径或中间件；就绪检查应仅验证本地服务状态与快速依赖探活（≤200ms），避免阻塞操作和日志输出。

健康检查端点必须用 http.HandleFunc 注册到根路径或明确路径

go 标准库的 http.ServeMux 不支持通配路由，/healthz、/health 这类路径必须显式注册。如果只注册了 /，而请求发到 /healthz，会返回 404 —— 这是部署到 kubernetes 时最常见的失败原因。

实操建议：

• 始终为健康检查单独注册一个路径，例如：http.HandleFunc("/healthz", healthHandler)
• 避免依赖中间件自动注入（如某些框架的全局 health route），K8s 的 livenessProbe 和 readinessProbe 默认不带任何 header 或 cookie，中间件可能意外拦截或重定向
• handler 内部不要调用阻塞型 DB 连接池 db.Ping()，应改用非阻塞探测（如检查连接池是否已初始化、或使用 db.Stats().OpenConnections）

使用 net/http 实现轻量级就绪检查（readiness）

就绪检查要反映服务是否能真正处理业务请求，但又不能太重。常见错误是把数据库 Ping() 放进 readiness handler，导致 DB 短暂抖动时整个服务被 K8s 下线。

推荐做法：

立即学习“go语言免费学习笔记（深入）”；

• 只检查本地状态：HTTP server 是否已启动监听、gRPC listener 是否就绪、必要配置是否加载完成
• 对依赖服务做快速探活（超时严格控制在 200ms 内），例如用 http.Client 带 Timeout: 200 * time.Millisecond 请求下游 /healthz
• 避免日志输出：K8s 会高频轮询，每秒一次的 log.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"))     } }

Kubernetes 中 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()
• 在 shutdown 流程中，先关闭 listener，再调用 srv.Shutdown()，最后 wg.Wait()
• 健康检查 handler 必须响应 ctx.Done()：若 shutdown 已触发，/healthz 应立即返回 503，而不是等待 wg.Wait 完成

最容易被忽略的一点：Go 的 http.Server 默认不启用 SetKeepAlivesEnabled(false)，长连接可能拖慢 shutdown —— 生产环境建议显式关闭 keep-alive 或缩短 IdleTimeout。