Golang配置K8s健康检查教程

在 Kubernetes 中保障 Go 服务稳定运行，远不止于配置 livenessProbe 和 readinessProbe——关键在于 Go 程序需主动暴露轻量、语义清晰的健康端点（如 /healthz），用原子变量精细控制就绪状态，严格区分存活与就绪探针的检查逻辑（前者保进程存活，后者保依赖可用），并规避镜像行为（如 panic 未捕获）、资源配置（如内存过紧）、探针参数（如 failureThreshold 过低）及 HTTP 头校验等常见陷阱；只有代码逻辑与 K8s 配置深度协同，才能真正实现优雅启停、精准摘流和故障自愈，避免“越配越不稳”的恶性循环。

Go 程序跑在 Kubernetes 里，光写好 livenessProbe 和 readinessProbe 不够——K8s 不会“自动修复”，它只按配置做重启或摘流量；真正要靠 Go 代码自己暴露健康端点、处理状态异常、配合探针逻辑，才能让服务稳住。

如何用 net/http 暴露标准健康检查端点

Kubernetes 的 livenessProbe 默认走 HTTP GET，要求返回 200。别写成重定向或返回 503 后还硬扛着不退出——K8s 会直接杀 Pod。

常见错误：把 /healthz 写成只检查内存或 goroutine 数量，却忽略下游依赖（比如数据库连不上时仍返回 200）。

• 用 http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) { ... }) 注册端点，不要用中间件拦截后统一处理，避免探针被延迟或吞掉
• 检查项必须轻量：DB 连接用 db.PingContext(ctx, 1s)，缓存用 redis.Ping()，超时设为 probe 的 timeoutSeconds - 1
• 返回体建议加简单 JSON：{"status":"ok","timestamp":1712345678}，方便人工 curl 验证，也利于日志追踪

livenessProbe 和 readinessProbe 的参数怎么配才不互相打架

两个探针语义不同：liveness 判定“该不该重启”，readiness 判定“该不该转发流量”。配错会导致滚动更新卡住、或反复重启却始终 503。

• initialDelaySeconds：Go 程序启动慢（比如加载大配置、初始化 gRPC client），liveness 至少设 15–30s，readiness 可稍短（10s），但不能比程序就绪时间还短
• periodSeconds 和 failureThreshold 要匹配：比如 DB 临时抖动 2s，若 periodSeconds=5 + failureThreshold=1，一次失败就触发重启——应调成 failureThreshold=3
• 避免 liveness 和 readiness 指向同一个 handler：前者可只查进程存活（如 atomic.LoadInt32(&healthy)），后者才查完整依赖链

Go 里怎么主动通知 K8s “我暂时不可用”

K8s 不支持运行时动态修改探针行为，但你可以让 readinessProbe 返回非 200，从而让 Endpoint Controller 自动从 Service Endpoints 中摘掉这个实例。

典型场景：收到 SIGTERM 后，先关掉 readiness，等请求 drain 完再停服务。

• 用原子变量控制 handler 行为：var isReady int32 = 1，readiness handler 中 if atomic.LoadInt32(&isReady) == 0 { http.Error(w, "not ready", http.StatusServiceUnavailable); return }
• 收到 os.Interrupt 或 SIGTERM 时，先 atomic.StoreInt32(&isReady, 0)，再 sleep 几秒（比如 5s），再调 srv.Shutdown()
• 别依赖 context.WithTimeout 在 handler 里做“优雅关闭中”的判断——探针超时很短（通常 1–3s），容易误判

为什么加了健康检查，Pod 还是频繁 Restart？

最常被忽略的不是 Go 代码，而是容器镜像和 K8s 配置的隐性冲突：

• Go 程序用了 log.Fatal 或 panic 未捕获，导致进程直接退出——K8s 认为 liveness 失败，立即重启，根本没机会走 shutdown 流程
• 容器 runtime 是 containerd 时，terminationGracePeriodSeconds 默认 30s；但你的 Go Shutdown 设了 60s，K8s 强杀前你根本来不及清理
• Probe 的 httpHeaders 加了认证头（比如 Authorization: Bearer xxx），但 handler 没校验，结果所有探针都 401——看起来像“一直不健康”
• Pod 资源限制太紧（比如 memory: 64Mi），GC 频繁或 OOMKilled 后重启，日志里却只看到 “Liveness probe failed”

真要排查，先 kubectl describe pod 看 Events，再 kubectl logs --previous 看上次崩溃前输出——别只盯着 probe 配置改。

以上就是《Golang配置K8s健康检查教程》的详细内容，更多关于的资料请关注golang学习网公众号！