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 必须快、稳、不依赖外部系统。一个典型实现：

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 却实际不可用）或太紧（依赖抖动就切走流量）。