kubectl rollout 是干什么的
kubectl rollout 管理控制器下工作负载的滚 动发布：查看发布进度、翻阅历史版本、回滚到指定版本、触发滚动重启，还能暂停与恢复发布节奏。它的价值在于把发布过程变成可观察、可回退的动作，而不是一次不可逆的替换。
基本信息
| 查看进度 | rollout status 会等待发布完成或失败，可加超时时间 |
|---|---|
| 查看历史 | rollout history 列出各版本与变更原因 |
| 回滚 | rollout undo 默认回到上一版，也可指定目标版本 |
| 触发重启 | rollout restart 让控制器滚动重建实例，用于加载新配置 |
| 暂停与恢复 | pause 后批量改配置再 resume，避免多次无谓滚动 |
| 适用范围 | 适用于 Deployment、DaemonSet、StatefulSet 等控制器资源 |
典型使用场景
- 发布后确认结果：跟一次状态检查，确认滚动真的完成而不是卡住
- 快速回退：新版本出现异常时立刻退回上一个可用版本
- 查变更来源：从历史里确认每个版本对应的镜像与变更原因
- 加载配置变更：配置更新后触发滚动重启让新配置生效
- 控制发布节奏：灰度期间暂停发布，观察指标后再继续
- 核对发布历史长度：确认保留的版本数量是否足够支撑回滚
子命令速查
| 子命令 | 作用 | 常用参数 |
|---|---|---|
| status | 等待并显示发布进度 | --timeout 控制等待上限 |
| history | 列出历史版本 | 常与回滚搭配使用 |
| undo | 回滚到上一版或指定版本 | 指定版本前先看历史 |
| restart | 触发滚动重启 | 配置变更后让新配置生效 |
| pause | 暂停发布 | 灰度观察期间使用 |
| resume | 恢复发布 | 与暂停成对使用 |
完整流程
完整流程
kubectl set image deploy/web nginx=nginx:1.27-alpine # 更新镜像触发发布
kubectl rollout status deploy/web --timeout=180s # 跟随发布进度
kubectl rollout history deploy/web # 查看版本历史
kubectl rollout undo deploy/web --to-revision=2 # 回滚到指定版本
kubectl rollout restart deploy/web # 触发滚动重启
# 回滚前先确认目标版本的镜像与配置，避免退回一个同样有问题的版本回滚目标要确认：默认回退到上一版；指定版本前先把历史列表看一遍，确认那一版的镜像与变更内容才是想要的结果。
发布历史数量有限：保留的版本太少时，可用回滚点会非常少，长周期发布节奏下应显式调大保留数量。
触发重启会中断正在处理的请求：有优雅退出与探针配合时影响可控，否则会丢请求，选择重启时机要结合业务流量峰谷。
发布过程中被暂停的控制器不会继续推进：排查卡住时先确认是否处于暂停状态，再去看探针与资源是否满足。
发布过程的观察要点
- 发布期间观察就绪实例数，确认可用容量没有明显缩水
- 关注事件里的拉取失败与探针失败记录，卡住的原因通常写在那里
- 灰度期间先暂停发布，指标稳定后再继续推进
- 回滚前确认目标版本的镜像与配置，避免退回另一个问题版本
- 发布完成后核对副本数与就绪状态，不要只看命令返回成功
- 把发布与回滚步骤写进操作手册，值班人员按流程执行
发布窗口的选择同样重要：低峰期发布不仅影响面小，观察时间也更充裕，发现问题时回滚决策更容易从容做出。
把发布状态检查写成流程里的必选步骤而不是可选项：一忙就容易跳过，而跳过的代价往往在几小时后才显现。