必须先用kubectl rollout history查看Deployment的REVISION号以定位更新，REVISION是单调递增整数，每次Pod模板变更即生成新版本；可用--revision参数查看指定版本完整配置，或导出YAML比对差异；需检查revisionHistoryLimit和--record参数确保历史可追溯。
在Kubernetes中快速定位某次更新是否生效、排查镜像版本错乱或确认回滚目标，必须先准确查看Deployment的历史更新记录版本号，否则后续操作将失去依据。
基础命令：列出所有历史版本编号
执行 kubectl rollout history deployment/<deployment-name></deployment-name>，例如 kubectl rollout history deployment/nginx-deployment。
输出中第一列即为 【REVISION】，它是Kubernetes内部生成的单调递增整数，从1开始，每次Pod模板（.spec.template）变更都会触发新revision生成。
注意：revision不是时间戳，也不是Git commit ID，它只反映该Deployment下ReplicaSet的代际顺序。
查看指定版本的完整配置快照
方法一：用 --revision 参数精确读取某次更新的原始定义
kubectl rollout history deployment/nginx-deployment --revision=3
这会打印出 revision 3 对应的完整 Pod 模板，包括容器镜像、环境变量、端口、资源限制等——这才是真正决定该版本行为的全部内容。
方法二：直接导出当前生效的 Deployment YAML 并比对
kubectl get deploy nginx-deployment -o yaml → 查看 .spec.template 部分，再与历史版本对比，确认差异点。
确保版本记录可查的关键前提
第一步：检查 revisionHistoryLimit 是否足够
运行 kubectl get deploy nginx-deployment -o jsonpath='{.spec.revisionHistoryLimit}'，若返回空或小于你预期保留的数量（如5或20），说明旧版本可能已被自动清理。
第二步：确认关键更新是否带 --record
如果历史列表中 CHANGE-CAUSE 列显示 <none></none>，说明那次更新未加 【--record】 参数，你将无法通过文字线索判断那次更新改了什么镜像或配置。
第三步：立即补救（仅对后续更新有效）
编辑 Deployment：kubectl edit deploy nginx-deployment，在 spec 下添加或修改 revisionHistoryLimit: 20，保存退出即可生效。
