测验：恢复三起故障并记录证据
仅看到 CrashLoopBackOff，无法直接知道什么？
- 它表示正在等待再次重启
- 应用退出的具体原因
- 还需要进一步调查容器状态
- 需要检查日志和退出码
如果已经确认某个修订版本正常，应如何确定回滚目标？
- 始终选择最小编号
- 按 Service 创建顺序计算编号
- 用 kubectl 调用次数作为修订号
- 查看历史和内容，并指定已确认正常的修订版本
回滚后 Pod 已 Ready，但 Service 的 targetPort 错误，会怎样？
- 即使 Pod 已恢复，Service 请求仍可能失败
- Deployment 回滚会自动恢复 Service
- 旧 EndpointSlice 会覆盖端口号
- Service 失败会删除修订历史
恢复前保存观测 JSON，主要原因是什么？
- 只要有文件就无须真正恢复
- 保证学习者绝对无法编辑
- 用于对比恢复后将消失的故障时状态
- 保证永久保存全部日志
哪项预防检查能直接应对选择器不匹配事故？
- 让探针无条件成功
- 部署前比较 Service 选择器与 Pod 标签
- 缩短正常 Pod 的重启周期
- 定期删除旧容器日志
验证评分器时只运行正确答案，会漏掉什么？
- 无法确认存在成功响应
- 无法测量正常环境中的检查时间上限
- 无法确认正常文件的 JSON 语法
- 会漏掉“错误恢复也能通过”的无效检查