revisionHistoryLimit 是什么
Deployment 每改一次 Pod 模板就产生一个新的 ReplicaSet，旧 ReplicaSet 会被缩容到 0 但仍保留下来作为回滚目标，revisionHistoryLimit 决定这类旧对象最多留几个，默认值是 10。它管的是历史对象的保留数量，既不限制正在运行的副本数，也不影响当前版本的发布策略。值越大可回退的版本越多，代价是 etcd 里多出一批副本数为 0 的对象。
基本信息
| 所属字段 | Deployment.spec.revisionHistoryLimit |
|---|---|
| 默认值 | 10 个旧 ReplicaSet |
| 取值范围 | 不小于 0 的整数，0 表示不留历史对象 |
| 作用范围 | 只作用于旧 ReplicaSet，不影响当前版本与副本数 |
| 生效方式 | 修改 spec 后由控制器在后续对账中清理多余历史 |
典型使用场景
- 核心服务保留更多回滚点：把值调大，近几次发布随时可以一键回退
- 测试环境压缩对象数量：发布频繁、历史价值低，调小以减少集群里的无用对象
- 发布前确认可回退范围：用 rollout history 看清当前还留着哪些 revision
- 排查回滚失败：提示找不到可回滚版本时，先怀疑历史被清理或值被设成 0
- 大规模集群治理：成批缩容到 0 的旧 ReplicaSet 会拖慢列表查询与巡检脚本
调整与查看
调整与查看
kubectl get deploy web -o jsonpath='{.spec.revisionHistoryLimit}' # 当前保留数量
kubectl patch deploy/web -p '{"spec":{"revisionHistoryLimit":20}}' # 调大保留量
kubectl rollout history deploy/web # 列出仍在的 revision
kubectl rollout history deploy/web --revision=3 # 看某版本的状态摘要
kubectl get rs -l app=web --sort-by=.metadata.creationTimestamp # 旧 ReplicaSet 与副本数
kubectl rollout undo deploy/web --to-revision=3 # 回滚到指定版本取值参考
| 场景 | 常见取值 | 取舍 |
|---|---|---|
| 生产核心服务 | 10 到 30 | 回滚不必重新构建镜像，代价是对象数量上升 |
| 一般业务 | 保持默认 10 | 覆盖近期几次发布，占用可控 |
| 测试环境 | 2 到 3 | 发布频繁，历史价值低，优先减少集群对象 |
| 演练或临时集群 | 0 | 不打算回滚时避免堆积无用对象 |
rollout history 的 CHANGE-CAUSE 列取自 kubernetes.io/change-cause 注解。发布前用 kubectl annotate deploy/web kubernetes.io/change-cause="升级到 1.26.3" 写清内容，事后回看历史才知道每个编号对应什么改动。
历史对象的清理不可逆：被回收的旧 ReplicaSet 无法再作为回滚目标，对应 revision 也会从 rollout history 中消失。做高风险变更前，先记下当前镜像 tag 与 revision 号。