存活不等于准备就绪

一句话总结

readiness 失败表示失去接收流量的资格，并不代表容器进程已经退出。

为什么需要它

假设服务启动时需要时间加载数据或缓存。进程虽然存活，却尚未准备好处理正常请求。此时持续转发请求会向客户返回错误；无条件重启，又可能让准备工作从头开始。因此，需要区分进程存活、初始启动完成，以及能否接收流量。

Kubernetes 的 liveness、startup、readiness probe 就是表达这种区分的工具。liveness 用于决定是否重启，startup 用于保护缓慢启动阶段，readiness 用于判断能否接收服务流量。与其背诵 probe 名称，不如追问“失败时会改变什么”。本实验只有 readiness，因此把失败解释为 liveness 触发的重启，与观测相矛盾。

如何工作

实验应用在 8080 端口的 / 路径返回约定正文，正常 readiness 也检查同一条 /。若只把 readiness path 改为 /missing，应用本身仍能处理 / 请求，但 probe 会从不存在的路径收到 HTTP 404。Pod 可能保持 Running，容器 ready 却变为 false。即使 Service 的 EndpointSlice 中仍有该地址，ready 条件为 false 的目标也不是普通服务流量的就绪目标。

GET PodIP:8080/         → 200, 앱은 살아 있다
readiness /missing     → 404, 수신 준비 조건은 실패한다
Pod phase              → Running일 수 있다
container ready        → false
Service의 Ready 대상   → 0

这五行证据共同表明，“probe 约定与真实路径不同，导致实例被移出流量目标”，比“应用死亡导致服务停止”更符合事实。但不能把旧 Pod 的 404 event 当成当前 Pod 的原因。模板改变会替换 Pod，应同时核对名称与 UID，确认事件属于当前 Pod。旧事件只说明过去发生过故障，不能自动证明当前原因。

只有 readiness 失败，不会让同一容器重启。本实验同时观察当前 Pod 的 restartCount 为 0，以及直接 HTTP 请求成功。不要混淆两件事：修改模板中的 readiness 路径会创建新 Pod，而 probe 失败是否会让容器反复重启。出现新 Pod UID 是 Deployment 变更的结果，新 Pod 内部的 restartCount 才是容器重启记录。

普通 Deployment 使用 RollingUpdate。新 Pod 无法就绪时，旧的正常 Pod 可以继续保留并处理请求。这不代表没有故障，而是 rollout 被阻塞、旧版本仍在守护服务。本课程使用单 replica 与 Recreate，让旧 Pod 不会掩盖实验症状。这是为了观测因果关系的控制条件，不是无中断生产环境的推荐配置。

这也是保持其他设置不变、一次只改一个变量的原因。如果 readiness 路径和 Service selector 同时错误，Ready 目标为 0 就有两个原因。只修复其中一个，请求仍不会恢复，学员可能反过来怀疑修复命令本身。请先完整恢复 selector 实验，再进入 readiness 实验。复合故障应在能够区分各单一故障后再处理。

在实际项目中

新版本可能把健康检查路径从 /health 改为 /ready，而部署设置仍保留旧路径。应用主要业务请求正常，只有新 Pod 无法 Ready。此时删除 probe 让状态变绿，未必是在解决原因，反而可能移除了判断流量接收能力的保护装置。应让应用与部署设置采用一致路径，再确认状态是否变化。

相反，probe 也可能真实反映依赖故障。数据库不可用时，若只把 readiness 改成无条件返回 200，检查虽能通过，客户请求仍然失败。probe 是服务契约的缩写。包含哪些依赖、对短暂错误多敏感、检查成本多高，都要按服务特性设计。把本实验的 / 原样复制到所有服务并不是答案。

若 readiness 与 liveness 都调用同一个繁重业务 API，会增大负载；依赖服务只短暂变慢，也可能导致多个 Pod 同时重启，形成恶性循环。本课程不会向生产集群注入这种连锁故障，但必须先理解两个 probe 承担不同判断，之后才能讨论阈值与失败策略。仅仅缩短检查周期，也不代表故障响应总会更快或更安全。

请练习根据观测写句子。不要写“Kubernetes 坏了”，而应写“当前 Pod 为 Running，直接请求 / 成功，但该 Pod 的 readiness /missing 返回 404，Ready Endpoint 为 0”。后一种描述让下一个人可以重复请求并反驳或确认，在不急于断定原因的同时缩小后续检查范围。

下一次检查要做什么

在测验中区分 Pod 替换与容器重启，以及 probe 的目的与结果。实验第 4～5 步会分别保存错误 readiness 路径与恢复后的观测。观测工具成功表示实验条件已复现，并不表示工具自动修复了 probe。最后还要在报告中关联原因与预防措施。