普通进程00 的 /health=200、/ready=503已经证明“活着”和“就绪”不同。在 Kubernetes 节点上还要区分 Pod phase、容器 status、探针结果、Service 端点和用户请求。CrashLoopBackOff 常表示重启等待状态，而不是一种 Pod phase；Running 不等于所有容器已 Ready，更不保证业务已成功执行。

把检查点放回节点路径

init 容器先于应用启动完成；sidecar 语义要按当前 Kubernetes API/版本核查，不把任何普通辅助容器都当作同样的启动顺序。startup probe 给慢启动争取窗口，readiness probe 控制何时把后端纳入就绪集合，liveness probe 可触发重启；这些探针并不能证明数据正确性。优雅终止时观察终止通知、endpoint 移除、收到的信号与应用结束请求的时间顺序；即使 readiness 很快转 false，已在途请求也需要单独验证。

正例在专用 kind 集群用 probe_app.py --ready-delay 10 记录容器 Running、probe 503、后续 probe 200 与 Service endpoint 集合；边界例把 ready-delay 延长、在滚动更新中替换为不可就绪的新版本，统计真实成功/失败请求与终止期间存留的流量。只删除自己的 Deployment/Service，保留 Pod UID、容器 ID、事件和 HTTP 输出。入口与探针源码提供同一应用代码；当前无 kind，真实 Pod 生命周期、探针与滚动更新 NOT_RUN，00 的普通进程 503 不能充当 k8s 成功案例。

现象 检查 限定条件
Running 但 503 容器、readiness 与请求 不等于运行时 create 失败
有 Ready 端点却业务失败 实际请求和应用数据 probe 非完整业务测试
更新被卡住 新旧 ReplicaSet/Pod UID 不把副本名当事件顺序

练习

  1. 先预测 ready-delay 大于 readiness 初次探测窗口时，Pod phase 与 Service 后端集合分别如何变化，专用集群保存时间线。
  2. 预测坏版本替换时滚动更新是否必然停止旧版本请求，记录每秒成功/失败计数和在途请求，而不是只报 kubectl rollout status。

上一篇：27：资源；下一篇：29：Pod IP 与 Service。

系列总目录：从进程隔离到运行时与编排。

参考资料