配置贴合实际的容器健康探针

概述

启动探针回答进程是否完成启动，存活探针回答进程是否还能推进，就绪探针回答是否应该接收流量。最常见的错误是把三者混为一谈：把数据库检查放进存活探针，会让数据库故障演变成重启风暴；把存活逻辑放进就绪探针，会让卡死的 Pod 继续留在负载均衡后面。

步骤

1. 拆分端点：/livez 只反映进程健康，/readyz 检查迁移状态与数据库连接：

app.get('/livez', (req, res) => res.status(200).send('ok'));
app.get('/readyz', async (req, res) => {
  if (!migrationsApplied) return res.status(503).send('migrating');
  const ok = await db.query('SELECT 1');
  return ok ? res.status(200).send('ready') : res.status(503).send('db down');
});

2. 配置三类探针，启动探针给 60 秒，存活探针连续 3 次失败重启，就绪探针仅摘除流量：

startupProbe:
  httpGet: { path: /livez, port: 8080 }
  failureThreshold: 30
  periodSeconds: 2
livenessProbe:
  httpGet: { path: /livez, port: 8080 }
  periodSeconds: 10
  failureThreshold: 3
readinessProbe:
  httpGet: { path: /readyz, port: 8080 }
  periodSeconds: 5
  failureThreshold: 2

3. 模拟依赖故障，观察 kubectl get pods -w 中 READY 变为 0/1 而 RESTARTS 保持 0。
4. 用 kubectl exec deploy/payments-api -- kill -STOP 1 验证存活探针会重启卡死进程。

验证

预期依赖故障时 Pod 被摘除但不重启，恢复后自动重新就绪；进程卡死时连续三次存活失败后重启并恢复服务。若启动阶段出现 CrashLoopBackOff，说明存活探针过早介入或启动探针时间不足。

注意事项

• 存活探针不得检查数据库或外部 API，只测试进程本身。
• timeoutSeconds 应小于 periodSeconds，避免一次挂起占满整个周期。
• 就绪检查要包含迁移完成标志，不能只判断端口可连接。
• 探针无法发现单条查询路径的局部故障，仍需业务指标配合。