恢复三起故障并记录证据

一句话总结

回滚命令成功并不代表恢复结束。必须确认要返回的正常版本，并重新发送真实请求。

为什么需要它

容器命令的一处小改动让应用启动后立即退出。新 pod 不断重启，负责人准备回到上一版本。但“上一版本”真的正常吗？如果前一次实验中创建了 readiness 配置错误的模板，简单后退一步也可能通向另一次故障。恢复目标不能由记忆或序号决定，而应指向经过确认的正常状态。

本实验先确认正常 readiness 已恢复，并记录对应的 Deployment revision。随后把命令改成一段故意返回退出码 17 的短 shell。17 只是本教学场景的标记，不是 Kubernetes 规定的通用错误码。如果退出码不同，或状态是 ImagePullBackOff，就表示原因与本次预设故障不同，不能视为同一答案。

如何工作

当 Pod 模板变化并触发 rollout 时，Deployment revision 会更新。修改 Service selector 不属于 Deployment 模板变更；只调整 replica 数量也不等同于创建新 Pod 模板。因此，不要死记“每执行一次 kubectl 命令，revision 就增加一”的错误规则。应查看 rollout history 以及每个 revision 的内容，确认究竟改了什么。

정상 템플릿 확인 → 정상 revision 기록
명령 변경        → 프로세스 종료 → 재시작과 backoff
증거 보존        → 원인·복구 목표 선택
정상 revision 지정 rollback
현재 Pod·Ready Endpoint·실제 HTTP 다시 확인

CrashLoopBackOff 是等待重启的线索。仅凭这个词，无法知道是 OOM、命令错误还是配置文件缺失。应一起查看 lastState.terminated 的 exitCode 与 reason、restartCount，以及上一次容器日志。本次命令会向 stderr 写入 intentional-exit-17，并以 17 退出。只有上一轮日志中出现该标记且退出码一致，才算准确复现了本实验。

当前容器日志为空，不代表应用没有输出。刚重启后，关注的日志可能留在前一次运行中；kubectl logs --previous 用于确认这种差异。但它不是永久保存日志的审计存储。日志会因 pod 替换与保留策略消失，所以恢复前要把必要内容保存在观测文件中。

如果知道目标 revision，可以用 --to-revision 指定。即使恢复了正常 Pod 模板，Service 仍是独立对象。若 Service targetPort 仍为 9999，pod 恢复 Ready 后，Service 请求依然可能失败。因此最终评分不只检查报告文件或 Deployment 状态，还会分别向真实 Pod IP 与 Service IP 发送两次请求，核对约定响应。

用于确认恢复成功的请求，也要明确自己验证了什么。本课程的 GET / 只是一个不访问数据库或外部支付的小型 HTTP 响应。生产环境的恢复判定可能还需检查代表性业务路径、错误率、延迟、依赖与数据一致性。此处成功响应只证明这个小服务的连接路径已经恢复，并不能保证所有客户业务都已正常。

在实际项目中

事故报告不是命令执行流水账。它应把影响、怀疑的层级、缩小范围的证据、采取的改动，以及确认恢复的请求连成一条链。“重启 pod 后解决”只会让下一次故障重复相同行为；若证据指出是 selector 不匹配，就可以建立发布前比较 selector 与 label 的预防检查。

本报告为 selector、readiness、crash 三个事件分别关联 cause、prevention、evidence，并保存为 JSON。评分器不会评价自由写作的文风，而会明确检查应掌握的原因区分和证据关联。service-selector 使用 compare-selector-labels，readiness-path 使用 probe-real-endpoint，process-command 使用 smoke-test-command 作为预防代码。指令中已经说明各代码含义，不是让学员猜字符串。

不过，报告代码正确并不能强力证明真正做过实验。学员在自己的 VM 中拥有 root 权限，可以编辑观测 JSON。保存的观测只是教学实验笔记，不是不可伪造的证书。最后一步对当前 HTTP 的验证，至少会拒绝只修改文件、未修复服务的情况。诚实说明测试的信任边界，也是高质量运维文档的一部分。

同一服务随时间经历正常→故障→恢复，如果每个步骤只看当前状态，就会出问题。恢复后执行完整评分时，要求“制造故障”的历史步骤会失败。本课程把前 7 步的观测分别保存为文件，最后同时检查它们之间的关联与当前恢复状态。观测命令只是由学员运行的记录工具，评分器不会修改文件或注入故障。

预防措施也必须通过反例验证。如果故意配置错误 Service 端口后，正常判定仍然通过，这项检查就什么也没保护。一个正常示例能通过，对“无条件通过”的检查也成立。编写者不仅要验证正确答案，还要确认这些状态会被拒绝：只修 selector、probe 仍错误；退出码不同；状态 Ready，但 Service HTTP 失败。

下一实验要做什么

在 8 个步骤中观测正常基线、三类故障与恢复，最后把原因、预防和证据关联起来。最终成功后再次执行完整评分，确认历史证据仍然保留。实验约需 50 分钟，使用临时 VM。若需要更多时间，请在会话到期前续期，并在结束前另行保存重要观测。不要把本课程实验原样复制到生产 Kubernetes 集群。