LivenessProbe超时但程序在跑，根本原因是探针过早发起请求：Go服务监听端口后即被探测，但DB连接、配置加载等初始化未完成，导致/healthz返回503或超时；正确做法是延迟启动Serve，待初始化完毕再接受连接。
为什么 LivenessProbe 会超时，但程序明明在跑？
常见现象是 Pod 反复重启，kubectl describe pod 显示 Liveness probe failed: HTTP probe failed with statuscode: 503 或直接 timeout，而你进容器 curl localhost:8080/healthz 却立刻返回 200。根本原因通常是：Go HTTP server 启动了，但还没来得及注册 handler、加载配置或连上数据库，probe 就已开始发送请求。
典型错误写法是把 http.ListenAndServe 放在 main 函数最外层，没做任何就绪前置检查：
func main() {
http.HandleFunc("/healthz", healthHandler)
http.ListenAndServe(":8080", nil) // 启动即监听，但 handler 可能还没准备好
}
解决思路不是“加长 timeout”，而是让 probe 真正反映服务就绪状态：
- 用
http.Server显式管理生命周期，启动前先完成初始化（如 DB 连接池 warmup、配置校验） - 健康 endpoint 必须检查关键依赖（如
db.Ping()），不能只返回硬编码 200 - 首次响应前，避免提前打开监听端口 —— 否则 kubelet 会立即开始 probe
如何让 Go server 真正“延迟就绪”？
核心是分离「监听」和「接受连接」两个动作。用 net.Listen 创建 listener，等所有初始化完成后，再用 server.Serve(lis) 启动服务。
立即学习“go语言免费学习笔记（深入）”；
func main() {
mux := http.NewServeMux()
mux.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
if err := checkDB(); err != nil {
http.Error(w, "db unreachable", http.StatusServiceUnavailable)
return
}
w.WriteHeader(http.StatusOK)
})
lis, err := net.Listen("tcp", ":8080")
if err != nil {
log.Fatal(err)
}
defer lis.Close()
server := &http.Server{Handler: mux}
// 关键：这里做所有阻塞初始化
if err := initDatabase(); err != nil {
log.Fatal(err)
}
if err := loadConfig(); err != nil {
log.Fatal(err)
}
// 初始化完成，才开始接受连接
log.Println("Server ready, starting HTTP listener")
log.Fatal(server.Serve(lis))
}
这样 Kubernetes 的 LivenessProbe 和 ReadinessProbe 都会在服务真正可用后才开始工作。注意：ReadinessProbe 应该调用同一个 /healthz，但 LivenessProbe 可考虑更轻量（如只检查进程存活），避免因 DB 临时抖动误杀 Pod。
ReadinessProbe 和 LivenessProbe 参数怎么设才不互相打架？
很多人把两者 timeoutSeconds / failureThreshold 设成一样，结果 DB 慢一点，readiness 失败导致流量被切走，liveness 紧跟着失败触发重启 —— 形成雪崩。
推荐配置逻辑：
-
readinessProbe：侧重“是否愿意收流量”，可稍敏感。例如initialDelaySeconds: 10（等 Go 完成初始化）、periodSeconds: 5、failureThreshold: 3（连续 15 秒不可用才摘流） -
livenessProbe：侧重“进程是否卡死”，应更宽松。例如initialDelaySeconds: 30（给慢依赖留足时间）、periodSeconds: 30、timeoutSeconds: 5、failureThreshold: 2 - 两者 endpoint 可不同：
readinessProbe调/healthz（检查 DB），livenessProbe调/livez（只检查http.Server是否还在 accept）
如果用的是 httpGet 探针，务必确认 handler 不带锁、不阻塞、不依赖外部网络 —— 否则 probe 自身可能成为瓶颈。
为什么本地测试没问题，一上 K8s 就超时？
本地 curl 成功不代表 K8s 环境下 probe 也能过。真实环境有三个隐藏差异：
- Kubelet 默认通过 Pod IP + hostNetwork=false 访问，若你的 handler 绑定的是
127.0.0.1，它根本收不到请求 —— 必须用0.0.0.0:8080或空 host - 容器内 DNS 解析可能慢，若 health handler 里调用了
http.Get("http://xxx.svc.cluster.local")，会拖慢响应 - Go 的
http.Server.ReadTimeout和WriteTimeout如果设得太小（如 2s），Kubelet probe 在网络波动时容易被中断，建议设为10s以上，并确保小于 probe 的timeoutSeconds
最容易被忽略的一点：Golang 的 http.DefaultServeMux 是全局的，多个包 init 时注册 handler 可能冲突；生产环境强烈建议用显式 http.ServeMux 实例，避免隐式依赖。
