存活探针与就绪探针的后果不同

Kubernetes 靠两种探针判断一个实例该怎么处理，触发的动作完全不同：存活探针失败意味着应用陷入了自己恢复不了的故障状态，平台的应对是直接重启这个实例；就绪探针失败意味着应用暂时处理不了新请求（可能还在启动阶段初始化组件，也可能是临时过载），平台的应对不是重启，而是先停止把流量转发给这个实例，等它恢复了再重新纳入负载均衡。默认情况下应用的存活状态只看自己内部的 Spring 上下文是否启动成功，不依赖任何外部组件——如果把外部依赖也算进存活判断，一旦某个下游服务抖动，会连带触发一堆本不该重启的实例被反复重启，故障因此被放大而不是被隔离。发散：这两种探针分别对应”这个实例还救不救得活”和”这个实例现在能不能干活”两个不同维度的问题，混着用（比如把外部依赖健康状况错误地接进存活探针）是很常见的一个陷阱——本该是”暂时不可用”的临时状态，被误判成了”必须重启”的永久性故障。