测验：存活不等于准备就绪

readiness 失败的直接作用是什么？

• 立即重启所有失败进程
• 把 Pod 模板回滚到上一个修订版本
• 从 Service 的就绪目标中排除，不再接收一般服务流量
• 把容器镜像替换为其他版本

探针访问 /missing 返回 404，但直接请求 / 成功。最合理的假设是什么？

• 应用与 readiness 路径的契约不一致
• 容器因 CPU 不足而退出
• Service selector 自动改变
• 集群全部 DNS 停止

修改探针设置后，看到新的 Pod UID 和 restartCount 0。正确的区分是什么？

• 探针失败使容器重启了一次
• 同一 Pod 只是改名后继续运行
• restartCount 为 0 表示模板没有变化
• Pod 替换与容器重启是两种不同记录

用旧 Pod 的 Unhealthy 事件解释当前故障前，需要做什么？

• reason 相同即可视为当前故障
• 比较事件目标 UID 与当前 Pod UID
• 属于同一 Deployment 的事件即可视为当前事件
• 只取时间最新的一条事件作为原因

本实验为什么使用单副本和 Recreate？

• 这是无停机运维唯一推荐设置
• 为了避免使用 readiness 探针
• 防止旧的正常 Pod 掩盖实验故障
• 因为 Kubernetes 不支持 RollingUpdate

真实依赖已经故障，却把 readiness 改为无条件返回 200，会怎样？

• 检查可能显示绿色，但业务失败仍然存在
• 依赖服务会自动恢复
• 旧容器日志会全部恢复
• 服务的全部数据一致性得到保证