Kubernetes 健康检查探针实战：liveness、readiness、startup 正确用法

一、探针不是可选项，而是稳定性的底线

在 Kubernetes 里，一个 Pod 显示“Running”并不代表它真的能对外服务：进程可能还在初始化、依赖的下游还没连上、或者已经死锁但端口还开着。健康检查探针（Probes）就是告诉 kubelet“这个容器现在到底健不健康”的机制。

用错探针，轻则服务抖动、重则级联雪崩；用对探针，滚动发布零中断、故障自愈都靠它。本文把 liveness、readiness、startup 三种探针讲清楚，并给出可直接套用的配置。

二、三种探针的分工

• livenessProbe（存活探针）：判断容器是否“活着”。失败会重启容器。用于处理死锁、进程假死等无法自愈的情况。不要把依赖检查放进 liveness，否则下游一抖动就会引发大面积重启。
• readinessProbe（就绪探针）：判断容器是否“可以接收流量”。失败会把 Pod 从 Service 的 Endpoints 里摘掉，不重启。用于启动预热、依赖未就绪时先不接流量。
• startupProbe（启动探针）：判断容器是否“启动完成”。在它成功之前，liveness/readiness 都不会执行。专门拯救启动慢的应用，避免还没启动完就被 liveness 反复杀死。

一句话记忆：liveness 管重启，readiness 管流量，startup 管启动宽限。

三、三种探针的常用检查方式

• httpGet：发 HTTP 请求，状态码 200–399 视为成功（最常用）。
• tcpSocket：能建立 TCP 连接即成功。
• exec：在容器内执行命令，退出码 0 视为成功。
• grpc：K8s 1.24+ 支持 gRPC 健康检查协议。

四、一份可直接套用的配置

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
spec:
  replicas: 3
  selector:
    matchLabels: { app: demo-app }
  template:
    metadata:
      labels: { app: demo-app }
    spec:
      containers:
        - name: app
          image: registry.example.com/demo-app:1.4.0
          ports:
            - containerPort: 8080
          startupProbe:            # 启动慢的应用必备
            httpGet:
              path: /healthz
              port: 8080
            failureThreshold: 30  # 最多容忍 30 次
            periodSeconds: 2      # 每 2s 一次 → 最多 60s 启动窗口
          livenessProbe:           # 只查进程自身是否健康
            httpGet:
              path: /livez
              port: 8080
            periodSeconds: 10
            failureThreshold: 3   # 连续 3 次失败才重启
          readinessProbe:          # 检查是否可接流量（含依赖）
            httpGet:
              path: /readyz
              port: 8080
            periodSeconds: 5
            failureThreshold: 2
          resources:
            requests: { cpu: "200m", memory: "256Mi" }
            limits:   { cpu: "1",    memory: "512Mi" }

要点：

• 三个端点分开：/livez 只看进程自身，/readyz 可检查 DB/缓存等依赖，/healthz 供 startup 使用。
• failureThreshold 别设太小，网络抖动容易误杀。
• readiness 的 periodSeconds 可比 liveness 更短，让摘流量更灵敏。

五、五个高频坑

1. liveness 里查数据库：DB 一抖动，所有 Pod 被重启，雪崩。liveness 只查自身。
2. 没有 startupProbe：启动 40s 的应用被 10s 一次的 liveness 反复杀死，永远起不来。
3. readiness 太宽松：依赖没连上就接流量，用户看到大量 500。
4. 超时与阈值不合理：timeoutSeconds 大于 periodSeconds 意义不大；总容忍时间 = periodSeconds × failureThreshold，要结合业务算。
5. 探针端点太重：健康检查里跑重查询，反而拖垮服务；保持轻量。

六、和优雅停机配合

探针要和 terminationGracePeriodSeconds、preStop 钩子一起用：Pod 被删除时先从 Endpoints 摘除（readiness 失效），再等 preStop 完成、连接排空，最后才真正退出。这样滚动发布时不会出现“请求打到正在退出的 Pod”导致的 502。

spec:
  terminationGracePeriodSeconds: 30
  containers:
    - name: app
      lifecycle:
        preStop:
          exec:
            command: ["sh", "-c", "sleep 5"]

七、总结

健康检查的正确姿势：liveness 只查进程自身（失败才重启）、readiness 查能否接流量（含依赖）、startup 给慢启动应用留足宽限；三个端点分开、阈值结合业务调；再配合 preStop 优雅停机。探针配好了，Kubernetes 的自愈和滚动发布才能真正发挥作用，而不是把偶发抖动放大成故障。