Spring Boot部署K8s时用/actuator/health做探针的弊端及相关问题

核心弊端 #

• 探针职责混淆：Kubernetes的存活探针仅需判断容器进程是否正常运行，就绪探针才要检查服务是否具备处理请求的能力（比如依赖的数据库、缓存是否可用）。但/health端点默认会包含所有健康检查项，用它同时充当两个探针的话，会让存活探针过于敏感——比如数据库临时断连，存活探针就会触发容器重启，但其实进程本身没问题，完全没必要重启，反而会放大故障影响。
• 健康检查粒度失控：如果自定义/health时加了非核心检查项（比如某个不重要的第三方API），一旦这些项失败，不管是存活还是就绪探针都会触发动作，要么重启容器，要么把流量切走，完全没必要，反而会平白降低服务可用性。
• 额外资源消耗：如果/health包含大量重逻辑检查（比如查数据库、调用内部服务），K8s频繁的探针请求（默认10秒一次）会额外占用应用和依赖的资源，比如数据库连接池被探针请求占满，进而影响正常业务请求的处理。

与优雅停机的冲突 #

• 停机期间误判存活状态：Spring Boot触发优雅停机时，会先拒绝新请求、处理现有请求，但默认/health在停机初期仍会返回健康状态（除非自定义了停机状态的检查逻辑）。这时候K8s的存活探针会认为容器还正常，不会主动终止它，导致流量继续被转发到正在停机的Pod，引发请求失败。
• 强制中断风险：如果/health在停机过程中一直返回健康，K8s会等到terminationGracePeriodSeconds超时后才强制杀死进程，这会直接中断还在处理的请求，完全违背优雅停机的初衷。

对滚动更新的影响 #

• 更新流程拉长：就绪探针用/health的话，新Pod必须等所有健康检查项都通过才会接收流量，而有些依赖初始化（比如数据库连接建立）需要时间，会导致新Pod就绪延迟，整个滚动更新的时间窗口被拉长。
• 故障扩散风险：如果/health包含全局依赖的检查（比如共享缓存），一旦这个依赖出问题，所有新启动的Pod都无法通过就绪探针，滚动更新会卡住，甚至旧Pod被逐步终止后，整个服务直接不可用。
• 流量切分不精准：滚动更新时，旧Pod开始停机，如果/health没及时反映停机状态，K8s不会把流量从旧Pod切走，用户请求会被发送到正在停机的Pod，出现报错。

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