健康检查：liveness/readiness/startup

程序跑着跑着可能卡死，但进程还活着。这种”假活”Kubernetes 看不出来。健康检查（探针）就是让 kubelet 定期敲门，确认容器真能干活。

14-1 为什么需要探针

没有探针时，只要容器进程没退出，Kubernetes 就认为它好好的。可现实中很多”假死”：死锁、线程池打满、连不上数据库却还在监听端口。

探针（Probe）是 kubelet 周期性对容器做的诊断。诊断失败会触发对应动作，比如重启容器或把它摘出流量池。它把”活着”和”能用”两件事分开了。

14-2 三类探针各管什么

这是本章最核心的区别，记牢。

liveness（存活探针）：管”该不该重启”。失败就杀容器、按重启策略重启。用来对付死锁这类假死。

readiness（就绪探针）：管”该不该接流量”。失败就把 Pod 从 Service 的端点里摘掉，不再转发请求；恢复就加回来。它不重启容器。

startup（启动探针）：管”启动保护期”。在它成功之前，liveness 和 readiness 都不生效。给慢启动应用争取时间，避免没起完就被 liveness 误杀。

打个比方：liveness 是”人还喘气不”，readiness 是”现在能接客不”，startup 是”刚出生还在穿衣服，别催”。

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

14-3 四种探测方式

不管哪类探针，敲门的方式就这四种。

exec：在容器里执行一条命令，返回 0 算成功。适合用脚本判断内部状态。

httpGet：对容器某个路径发 HTTP 请求，返回码 200–399 算成功。Web 服务最常用。

tcpSocket：尝试和容器建立 TCP 连接，连上就算成功。不关心返回内容，只关心端口通不通。

grpc：调 gRPC 的健康检查协议。应用实现了就能用，v1.27 起稳定。

livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5

这段意思是：每 5 秒执行 cat /tmp/healthy，文件在就成功，不在就失败。

14-4 关键参数怎么配

探针有组通用参数，配错比不配还糟。

initialDelaySeconds：容器启动后等多久才做第一次探测。设太短，程序没起完就误判失败。

periodSeconds：探测间隔，默认 10 秒。

timeoutSeconds：单次探测超时，默认 1 秒。超时就当失败。

failureThreshold：连续失败几次才认定失败，默认 3 次。

successThreshold：连续成功几次才认定成功，默认 1 次。liveness 只能是 1。

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

上面 startup 组合：30 次 × 10 秒 = 最多 5 分钟启动窗口。应用有 5 分钟慢慢起，起完一次，liveness 才接管。慢启动服务就靠它续命。

14-5 一个完整例子

下面是同时配了三类探针的容器片段，可直接套用：

containers:
- name: web
  image: myapp:1.0
  ports:
  - containerPort: 8080
  startupProbe:
    httpGet:
      path: /healthz
      port: 8080
    failureThreshold: 30
    periodSeconds: 10
  livenessProbe:
    httpGet:
      path: /healthz
      port: 8080
    periodSeconds: 10
  readinessProbe:
    httpGet:
      path: /ready
      port: 8080
    periodSeconds: 5

14-6 常见坑

一是只配 liveness、不配 readiness。有人只配 liveness，结果应用还没加载完配置就被放进流量，用户疯狂报错。该接流量前不就绪，用 readiness 拦。

二是 initialDelaySeconds 拍脑袋写 0。程序要 20 秒才起，探针 1 秒就探，直接重启循环。慢应用请上 startup 探针。

三是探测路径太重。探针接口别查数据库、别算大报表，否则探一次拖垮业务。返回个轻量 ok 即可。

容器健康了，资源却可能被挤爆。下一章讲 CPU、内存的限制，以及 QoS 三档优先级。