Kubernetes集群中REST API应用存活探针设计咨询

核心原则先明确 #

存活探针（liveness probe）的核心作用是判断应用进程本身是否还具备运行能力——简单说，就是进程没挂、还能响应基础请求，就认为它“活着”。而数据库属于外部依赖，要不要加进去得分场景：

不建议在存活探针里加数据库检查的常见场景 #

• 数据库故障不是重启Pod能解决的：如果数据库挂了，重启应用Pod根本无法修复数据库问题，反而会导致服务中断范围扩大，甚至引发连锁反应（比如大量Pod重启后同时请求数据库，加重恢复负担）。
• 避免误判重启：数据库偶尔出现网络抖动、临时扩容导致的短时间不可用是常见情况，很多应用本身自带重连逻辑，过几秒就能恢复连接。这时候如果存活探针检测到数据库不可用就重启Pod，属于没必要的“误杀”。
• 轻量性要求：存活探针会定期执行，过于复杂的检查（比如数据库连接测试）会增加应用和数据库的负载，尤其是大规模集群下，频繁的数据库探测请求可能成为性能瓶颈。

可以考虑加入数据库检查的特殊场景 #

只有当你的应用满足以下两个条件时，才适合把数据库连通性加入存活探针：

1. 应用完全依赖数据库才能提供任何服务，且一旦数据库连接断开，应用进程会陷入死锁、无法自动重连，彻底失去服务能力；
2. 重启Pod确实能解决连接问题（比如数据库恢复后，新启动的Pod能重新建立连接）。

如果要加，一定要配置合理的探针参数：

• 设置initialDelaySeconds足够长，给应用留足初始化数据库连接的时间；
• 调高failureThreshold，允许几次探测失败，避免临时波动触发重启；
• 不要把periodSeconds设得太频繁，减少对数据库的压力。

更优的实践方案 #

结合健康检查的最佳实践，更推荐把数据库连通性检查放在**就绪探针（readiness probe）**里：

• 就绪探针负责判断Pod是否具备处理请求的能力，当数据库不可用时，就绪探针失败，Kubernetes会把这个Pod从服务的端点列表中移除，不再给它发流量；
• 等数据库恢复后，就绪探针自动恢复成功，Pod重新接入流量，全程不需要重启，避免服务中断。

而存活探针只做最基础的无依赖检查，比如让/healthz端点直接返回200 OK，只要进程能响应这个请求，就认为它存活。

内容的提问来源于stack exchange，提问作者Kannan K