kubernetes 中仅配置 livenessprobe 和 readinessprobe 不足，go 程序需自行暴露轻量健康端点、区分探针语义、用原子变量控制就绪状态，并避免镜像与配置冲突导致频繁重启。
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。
立即学习“go语言免费学习笔记（深入）”；
-
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，readinesshandler 中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；但你的 GoShutdown设了 60s，K8s 强杀前你根本来不及清理 - Probe 的
httpHeaders加了认证头（比如Authorization: Bearer xxx），但 handler 没校验，结果所有探针都 401——看起来像“一直不健康” - Pod 资源限制太紧（比如
memory: 64Mi），GC 频繁或 OOMKilled 后重启，日志里却只看到 “Liveness probe failed”
真要排查，先 kubectl describe pod <name></name> 看 Events，再 kubectl logs --previous 看上次崩溃前输出——别只盯着 probe 配置改。
