Kubernetes 健康检查配置避坑与调优实战

在 Kubernetes 上跑服务，探针（Probe）配置看似简单，实际踩坑最多。Liveness、Readiness、Startup 三者职责不同，配错轻则滚动更新时流量中断，重则容器被反复杀掉进入 CrashLoopBackOff。本文按实战场景梳理常见误区与调优方法。

一、三种探针的职责边界

Liveness 探针决定「要不要重启容器」。失败到阈值后 kubelet 会杀掉容器重建。它解决的是进程假死、死锁这类无法自愈的问题，**不要用它检测依赖是否可用**——下游数据库抖动就重启，只会雪崩。

Readiness 探针决定「要不要接流量」。失败时 Pod 会从 Endpoints 摘除，但容器不重启。依赖预热、下游连接池未就绪、缓存未加载完，都该用 Readiness 把住流量入口。

Startup 探针是慢启动保护。启动超过 `initialDelaySeconds + periodSeconds × failureThreshold` 的应用，必须配 Startup 探针，否则 Liveness 会在应用初始化阶段就把它杀掉。一旦 Startup 成功，后续只由 Liveness 接管。

二、常见坑与解法

**坑 1：HTTP 探针打在 302 重定向上。** 很多框架的 `/` 会 302 到登录页，kubelet 默认只认 200–399，看似能过，但一旦登录服务异常就开始误杀。显式指定 `httpHeaders` 带上健康路径，或直接用 `/healthz` 这类无重定向端点。

**坑 2：TCP 探针只测端口通不通。** 进程还在但线程池耗尽时，端口是通的。核心服务用 HTTP 探针并让 `/healthz` 真正检查线程池、队列深度，而不是只 `return 200`。

**坑 3：`periodSeconds` 太短导致探测风暴。** 集群几百个 Pod、1 秒一次探测，API Server 和业务日志都会被打爆。一般 `periodSeconds: 10`、`timeoutSeconds: 3` 足够；确需快速失败可降到 5 秒。

**坑 4：`failureThreshold` 默认 3 但配合长超时，实际容忍窗口过长。** 例如 `timeoutSeconds: 10` + 3 次失败 = 最坏 30 秒才重启。对延迟敏感的服务，把 `timeoutSeconds` 压到 1–3 秒更合适。

**坑 5：滚动更新时 Readiness 未就绪就切流量。** Deployment 配 `minReadySeconds: 10` 给缓冲，同时 Readiness 探针要覆盖「能真正服务请求」的完整路径（含必要依赖的连通性），而不是只看端口。

三、推荐配置模板

startupProbe:
  httpGet: { path: /healthz, port: 8080 }
  periodSeconds: 5
  failureThreshold: 30   # 最多保护 150 秒启动期
livenessProbe:
  httpGet: { path: /healthz, port: 8080 }
  periodSeconds: 10
  timeoutSeconds: 3
  failureThreshold: 3
readinessProbe:
  httpGet: { path: /ready, port: 8080 }
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 2

`/healthz` 只做进程自检（线程、事件循环、基本内存），`/ready` 额外检查下游依赖与缓存预热。两个端点分开，职责清晰，排障时看事件日志就能区分是假死还是未就绪。

四、调优与验证方法

部署后用 `kubectl describe pod` 看 Events 里的 `Liveness probe failed` / `Readiness probe failed` 次数与时间分布。压测时观察 `kubectl top pod` 的 CPU/内存，确认探测本身不是瓶颈。滚动更新时用 `kubectl rollout status deployment/xxx` 确认新 Pod 在 Readiness 通过前没有接管流量。

经验阈值：初始化超过 30 秒的应用必须配 Startup 探针；微服务 Readiness 要查下游；`/healthz` 保持极简。把探针配置纳入上线 checklist，能挡掉大部分「更新即故障」的低级问题。