标准答案
- readiness 失败通常把 Pod 从 Service 后端摘除，适合依赖未就绪或实例过载时暂时停止接流量。
- liveness 失败可能触发容器重启，适合发现卡死或无法自行恢复的状态，不应把短暂下游故障直接放进其中。
- startup probe 成功前可以抑制 liveness/readiness 的过早判断，适合启动慢但最终能工作的应用。
- 探针应轻量、有超时和失败阈值，测试重启、摘流、恢复和依赖不可用时的行为。
题目解析
readiness 失败会让 Pod 从 Service 后端摘除，适合实例暂时不能接流量；liveness 失败可能重启容器，只适合进程已经无法自行恢复的状态；startup 在成功前抑制其他探针，给慢启动应用提供窗口。它们表达的是不同控制动作，不是三个相同的健康接口。
探针应轻量、幂等、有明确 timeout 和 failureThreshold。深层数据库或第三方短暂故障通常应通过 readiness、降级和指标处理，放入 liveness 会让所有实例同时重启；启动、摘流、恢复和重启后的数据一致性都需要演练。
常见误区
- 误区：三种探针都调用完整业务链路。改正：分别设计本地存活、接流量能力和启动完成检查，限制依赖范围。
- 误区：慢启动应用没有 startup probe 却设置过短 liveness。改正：用 startup 覆盖初始化时间，再设置稳定的存活阈值。