GeoXMind

存活、就绪与启动探针回答不同问题

区分进程是否应重启、实例能否接收流量和应用是否完成启动，避免错误探针制造级联故障。

存活、就绪与启动探针回答不同问题

编排平台需要判断容器是否应重启、是否可以接收流量，以及是否仍在正常启动。这三个问题分别对应存活、就绪和启动探针。把它们指向同一个“所有依赖都正常”检查，可能在外部故障时同时重启大量健康进程，反而扩大事故。

存活探针判断重启是否有帮助

存活探针用于识别进程仍在运行却无法继续工作的状态，例如内部死锁。失败达到阈值后，平台会重启容器，因此检查条件必须代表重启能够恢复的问题。

数据库短暂不可用通常不意味着应用进程已经不可恢复。若存活依赖数据库，数据库故障会触发所有实例重启，增加启动和连接压力。外部依赖更适合影响就绪或业务降级。

存活检查应轻量、局部并有严格超时。探针本身执行昂贵查询、创建进程或竞争主线程资源，会在过载时成为额外负担。

就绪探针控制流量入口

就绪探针回答实例当前能否接受新请求。失败时实例继续运行，但从服务流量端点移除，适合初始化未完成、缓存预热、临时维护或局部过载。

就绪条件可以包含真正必需的依赖，但要考虑共同依赖失效。如果所有实例因同一数据库不可用而同时不就绪，入口可能完全无端点；有时返回受控错误或只保留只读能力更合适。

实例恢复就绪前应确认已有能力稳定，避免快速进出流量池。成功与失败阈值、探测周期和流量传播延迟共同决定抖动。

启动探针给慢启动独立时间

某些应用需要加载大模型、迁移本地状态或预热数据，正常启动时间超过存活阈值。启动探针成功前，Kubernetes 不执行存活和就绪探针，使应用有单独启动窗口。

启动窗口不是无限等待。失败阈值与周期规定最大允许时间，超出后按重启策略处理。配置应依据启动时间分布，而不是只观察一次最快启动。

启动完成的条件应与真正可继续运行相关。仅端口打开可能早于数据和路由就绪；执行全部深度检查又可能拖慢和放大依赖压力。

探针失败动作决定风险

相同检查逻辑用于不同探针会产生不同动作：存活失败重启，就绪失败停止流量，启动失败结束启动尝试。设计探针时应先问“失败后希望平台做什么”，再写检查。

重启不是修复所有故障的方法。配置错误、缺失密钥和不兼容数据库会让实例进入重启循环。此时清晰失败原因和退避比频繁重启更重要。

停止流量也需要配合连接排空和优雅终止。就绪状态变化到负载均衡器生效存在延迟，进程不能立即关闭所有现有请求。

深度检查与浅检查各有边界

浅检查确认事件循环、关键线程或本地状态能工作，成本低且不受外部波动影响。深度检查调用依赖，能发现实例无法提供完整服务，却可能把依赖故障扩散到探针系统。

可将存活保持浅层，就绪检查有限的必要依赖，并用独立监控执行更深的端到端探测。用户旅程健康不应完全依赖容器探针表达。

检查返回成功必须与实际能力一致。固定返回 200 的端点不能发现故障；执行过多业务又会让检查本身不稳定。每个条件都应有可测试的失败场景。

超时与频率影响故障检测

周期短、失败阈值低可以更快反应，也更容易因瞬时延迟误判。周期长则减少开销，但故障实例继续接收流量更久。参数应结合请求期限、实例数量和恢复时间设计。

探针超时必须小于周期并远低于业务长任务时间。健康端点不应排队在普通请求之后，否则过载时探针超时会造成流量迁移和重启，形成正反馈。

大量实例在同一时刻探测共享依赖也会产生脉冲负载。必要时应错开周期或让本地状态汇总依赖健康，而不是每次直连执行重查询。

监控探针与真实服务结果

探针通过不代表用户请求成功。它通常只覆盖一个轻量路径，权限、下游和数据问题仍可能存在。SLO、合成监控和业务指标要与探针状态并行观察。

应记录失败原因、耗时、连续次数和平台动作。只记录容器重启次数无法判断是应用死锁、探针超时还是错误配置。

发布前要演练启动慢、依赖中断、进程卡死和过载。正确结果应分别表现为等待启动、停止流量、重启或受控降级，而不是所有情况都触发同一动作。

探针是编排控制信号，不是健康报告页面。把存活、就绪和启动的目的分开，并让检查成本和失败动作匹配，才能帮助系统恢复而不是制造级联故障。

滚动发布时尤其要检查状态转换：新实例在真正可接流量前不能就绪，旧实例退出前应先撤销就绪并完成连接排空。否则探针本身配置正确，发布窗口仍可能出现短暂错误或请求丢失。

这些时序应纳入每次发布验证。

资料依据