应将业务连接检查放入readinessProbe而非livenessProbe，通过/readyz端点同步验证DB、Redis等依赖，并配合startupProbe保护慢启动服务，避免误剔除流量。
容器网络探针本身不直接用于“排查连接状态”，它只负责向容器发起健康检查（HTTP/TCP/Exec），而业务连接可用性需靠应用层逻辑暴露。真正能自动化识别业务连接是否正常的方式，是把业务依赖检查（如数据库连通性、下游服务调用）封装进就绪探针（readinessProbe）或自定义健康端点，再配合合理配置实现自动隔离与恢复。
把业务连接检查放进 readinessProbe
就绪探针失败时，K8s 会自动将 Pod 从 Service 的 Endpoints 中剔除，不再转发新请求——这是防止流量打到“已启动但连不上 DB”的关键机制。
- 推荐用 HTTP GET 方式调用应用内置的 /readyz 端点，该端点内部应同步检查：数据库连接、Redis 连通性、关键配置加载完成、本地缓存预热完毕等
- 避免在 livenessProbe 中做这类检查——存活探针只管“进程是否活着”，加业务依赖会导致误重启
- 如果应用无法提供 HTTP 接口，可用 exec 方式执行轻量脚本，例如：
curl -sf http://localhost:8080/health-db || exit 1
用 startupProbe 保护慢启动服务
某些服务启动后需等待 30 秒以上才能连上中间件，若此时 readinessProbe 已开始检测，可能连续失败导致 Pod 被反复剔除流量。启用 startupProbe 可延迟其他探针生效时机：
- 设置 startupProbe.httpGet.path: /startupz，该接口只需返回 200 表示进程已拉起（不检查业务依赖）
- 配置 failureThreshold: 30 和 periodSeconds: 2，允许最长 60 秒启动窗口
- 一旦 startupProbe 成功，readinessProbe 才开始运行，自然衔接业务连接验证
结合日志与指标做闭环诊断
探针只是“开关”，不是“诊断器”。要真正定位连接问题，需让 /readyz 等端点返回结构化信息：
- 返回 JSON，包含各依赖项的状态、耗时、错误原因（如
"mysql": {"ok": false, "error": "timeout"}） - 将该响应记录到标准输出，便于通过
kubectl logs快速查看 - 用 Prometheus 抓取 /metrics 中的 probe_result_total 等指标，设置告警：连续 5 次 readiness 失败 → 触发“DB 连接异常”告警
避开常见配置陷阱
很多连接类故障其实源于探针参数不合理：
- initialDelaySeconds 设太小：应用还没初始化完，探针已开始检查 → 建议设为预估启动时间 + 5 秒
- timeoutSeconds 过短：网络抖动或 DB 响应稍慢就失败 → 对依赖外部服务的检查，建议 ≥3 秒
- failureThreshold 过低：一次临时超时即剔除流量 → 生产环境建议 ≥3，避免偶发抖动引发雪崩
- 不要复用 /healthz 同时用于 liveness 和 readiness —— 语义混淆易导致误判
