Liveness探针用/healthz端点检查进程存活，Readiness探针用/readyz端点检查服务就绪；前者轻量无依赖，后者验证外部依赖与初始化状态；均需200表示通过，避免阻塞。
在 Go 应用中实现 Kubernetes 的 Readiness 和 Liveness 探针，核心是暴露两个独立的 HTTP 端点，分别返回不同语义的健康状态，且逻辑要严格区分：Liveness 判断进程是否“还活着”，Readiness 判断服务是否“可接收流量”。
1. 设计两个独立的健康检查端点
不要复用同一个接口。推荐路径如下：
- /healthz —— Liveness 探针目标：只检查进程基本可用性（如能否响应 HTTP、goroutine 是否卡死）
- /readyz —— Readiness 探针目标：检查依赖服务（数据库、缓存、下游 API）、内部初始化状态、连接池是否就绪等
两者都应返回 200 OK 表示通过，非 200（如 503）表示失败。K8s 默认超时 1 秒、失败阈值 3 次，建议在 handler 中避免阻塞或长耗时操作。
2. 实现轻量、无副作用的 Liveness handler
Liveness 必须快、稳、不依赖外部系统。一个典型实现：
立即学习“go语言免费学习笔记（深入）”；
http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
// 只做最基础检查：时间是否正常、内存是否严重告警（可选）
if time.Since(startTime) < 0 {
http.Error(w, "clock skew detected", http.StatusInternalServerError)
return
}
w.WriteHeader(http.StatusOK)
w.Write([]byte("ok"))
})⚠️ 注意：不要在这里查 DB 或 Redis —— 它挂了应该触发重启（Liveness 失败），而不是让整个探针变慢或误判。
3. 实现依赖感知的 Readiness handler
Readiness 要反映真实服务能力。常见检查项：
- 数据库连接是否活跃（执行
SELECT 1或检查连接池状态） - Redis 连接是否可 ping，或关键 key 是否可 set/get
- 配置是否已加载完成（比如从 etcd/viper 加载完毕的标志位）
- gRPC 依赖服务是否连通（可缓存上次探测结果，避免每次 dial）
示例片段：
var dbReady = atomic.Bool{}
// 启动时异步检查 DB 并设置标志
go func() {
for i := 0; i < 3; i++ {
if err := db.Ping(); err == nil {
dbReady.Store(true)
return
}
time.Sleep(2 * time.Second)
}
}()
http.HandleFunc("/readyz", func(w http.ResponseWriter, r *http.Request) {
if !dbReady.Load() {
http.Error(w, "database not ready", http.StatusServiceUnavailable)
return
}
w.WriteHeader(http.StatusOK)
w.Write([]byte("ready"))
})
4. 在 Kubernetes YAML 中正确配置探针
关键参数要匹配 Go 服务实际行为：
-
livenessProbe：用
httpGet指向/healthz，initialDelaySeconds: 10（给应用冷启动留时间） -
readinessProbe：指向
/readyz，initialDelaySeconds: 5（可比 liveness 更早开始） - 两者都建议设
timeoutSeconds: 2、periodSeconds: 5，避免默认 1 秒超时导致频繁失败
示例片段：
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 10
timeoutSeconds: 2
periodSeconds: 5
readinessProbe:
httpGet:
path: /readyz
port: 8080
initialDelaySeconds: 5
timeoutSeconds: 2
periodSeconds: 5基本上就这些。重点不是写得多，而是两个探针职责分明：Liveness 守住进程底线，Readiness 把控流量入口。不复杂但容易忽略 —— 很多线上问题其实源于 readiness 检查太松（一直 200 却实际不可用）或太紧（依赖抖动就切走流量）。
