kubectl rollout - Kubernetes 部署版本管理命令

kubectl rollout 是 Kubernetes 中用于管理部署过程的核心命令，专门处理 Deployment、DaemonSet 和 StatefulSet 等资源的滚动更新、版本回退、状态监控等操作。该命令通过控制 Pod 的渐进式替换，实现应用更新的零停机或最小化停机时间。

语法格式

kubectl rollout <SUBCOMMAND> <RESOURCE_TYPE>/<RESOURCE_NAME> [flags]

子命令详解

子命令	功能描述	适用资源类型	示例
history	查看资源的修订历史记录，包括版本号和变更原因	Deployment、DaemonSet、StatefulSet	kubectl rollout history deployment/my-app
pause	暂停正在进行的滚动更新，允许中间检查和配置调整	主要适用于 Deployment	kubectl rollout pause deployment/my-app
resume	恢复被暂停的滚动更新过程	主要适用于 Deployment	kubectl rollout resume deployment/my-app
status	监控滚动更新的实时状态和进度	Deployment、DaemonSet、StatefulSet	kubectl rollout status deployment/my-app -w
undo	回滚到之前的版本（上一个或指定修订版本）	Deployment、DaemonSet、StatefulSet	kubectl rollout undo deployment/my-app --to-revision=2
restart	重启资源，触发新的滚动更新	Deployment、DaemonSet、StatefulSet	kubectl rollout restart deployment/my-app

核心功能与应用场景

1. 版本历史查看与追踪

kubectl rollout history 命令可以显示资源的完整版本历史，每个修订版本都包含版本号、镜像版本和变更原因等信息。

# 查看 Deployment 的修订历史
kubectl rollout history deployment/nginx-deployment

# 查看特定修订版本的详细信息
kubectl rollout history deployment/nginx-deployment --revision=3

使用 --record 参数记录变更原因是一种最佳实践，便于后续追踪：

# 更新镜像并记录变更原因
kubectl set image deployment/nginx-deployment nginx=nginx:1.20.0 --record

2. 滚动更新控制（暂停与恢复）

pause 和 resume 子命令提供了对滚动更新过程的精细控制，特别适用于金丝雀部署场景。

# 金丝雀部署示例：更新部分Pod后暂停，验证通过后再继续
kubectl set image deployment/my-app app=my-app:v2
kubectl rollout pause deployment/my-app

# 验证新版本运行状态后恢复更新
kubectl rollout resume deployment/my-app

这种分段式更新策略可以先将少量流量（如5-10%）导入新版本进行验证，确认无误后再全量发布，大幅降低发布风险。

3. 部署状态监控

kubectl rollout status 提供实时更新进度监控，确保部署过程可视可控。

# 实时监控部署状态（持续跟踪直到完成）
kubectl rollout status deployment/my-app --watch

该命令会显示详细的更新进度，如"2 out of 10 new replicas have been updated"，帮助运维人员准确把握更新节奏。

4. 版本回滚操作

当新版本出现问题时，kubectl rollout undo 可以快速回退到稳定版本。

# 回滚到上一个版本
kubectl rollout undo deployment/my-app

# 回滚到特定修订版本
kubectl rollout undo deployment/my-app --to-revision=3

# 试运行回滚（不实际执行）
kubectl rollout undo deployment/my-app --dry-run=client

回滚操作本质上是将当前部署配置替换为历史修订版本的配置，Kubernetes会自动执行反向滚动更新。

经典工作流程示例

场景：安全更新与快速回滚流程

# 1. 查看当前部署状态
kubectl get deployment nginx-deployment
kubectl rollout status deployment/nginx-deployment

# 2. 更新镜像版本（并记录变更原因）
kubectl set image deployment/nginx-deployment nginx=nginx:1.25.0 --record

# 3. 监控更新进度
kubectl rollout status deployment/nginx-deployment -w

# 4. 发现问题，立即回滚
kubectl rollout undo deployment/nginx-deployment

# 5. 确认回滚成功
kubectl rollout history deployment/nginx-deployment
kubectl describe deployment nginx-deployment | grep Image

场景：金丝雀部署进阶流程

# 1. 初始部署
kubectl apply -f deployment-v1.yaml

# 2. 更新部分实例并暂停
kubectl set image deployment/my-app app=my-app:v2
kubectl rollout pause deployment/my-app

# 3. 验证新版本（监控指标、日志等）
kubectl get pods -l app=my-app
kubectl logs deployment/my-app --container=app

# 4. 根据验证结果决策：继续更新或回滚
# 情况A：验证通过，继续更新
kubectl rollout resume deployment/my-app

# 情况B：验证失败，回滚
kubectl rollout undo deployment/my-app

关键配置参数与策略调优

滚动更新策略调整

通过调整 maxSurge 和 maxUnavailable 参数，可以控制滚动更新的速度和影响范围：

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1           # 允许超出预期Pod数量的最大值（更新速度）
      maxUnavailable: 0     # 更新过程中不可用Pod的最大数量（可用性影响）

• maxSurge：值越大，更新速度越快，但需要更多临时资源
• maxUnavailable：值越大，更新期间可用性影响越大，但更新完成更快

修订历史记录管理

通过 revisionHistoryLimit 字段限制保留的历史版本数量，平衡存储空间和历史追溯需求：

spec:
  revisionHistoryLimit: 5   # 保留最近5个修订版本

注意事项与最佳实践

1. 版本记录完整性：始终使用 --record 参数记录变更原因，确保历史版本信息完整可追溯。

2. 回滚限制认知：回滚操作仅恢复Kubernetes资源配置，不会自动回滚数据库架构或外部系统变更，需要额外处理数据兼容性问题。

3. 资源预留充足：暂停滚动更新时，新旧版本Pod会同时运行，需确保集群有足够资源支持。

4. 健康检查配置：合理配置就绪和存活探针，确保Kubernetes能够准确判断Pod健康状态，这是滚动更新可靠进行的基础。

5. 修订历史清理：定期清理过期的修订历史（通过调整revisionHistoryLimit），避免占用过多存储空间。

6. 预生产环境测试：在生产环境使用前，在测试环境充分验证滚动更新和回滚流程，熟悉操作影响。

kubectl rollout 命令集为Kubernetes应用部署提供了强大的生命周期管理能力，结合合理的策略配置和操作流程，可以显著提升应用发布的可靠性和效率。

kubectl rollout history - 查看Kubernetes资源部署历史记录

命令简介

kubectl rollout history 是 Kubernetes 中用于查看 Deployment、DaemonSet 或 StatefulSet 等控制器资源历史修订版本的关键命令。通过该命令，用户可以获取每次部署的详细变更记录，包括版本号、变更原因和配置差异，这对于故障排查、版本回滚和审计跟踪至关重要。

语法格式

kubectl rollout history (TYPE NAME | TYPE/NAME) [flags]

核心功能

1. 基础查询 显示资源的全部修订历史，包括REVISION编号和CHANGE-CAUSE（变更原因）：

   kubectl rollout history deployment/my-app

   典型输出：

   REVISION  CHANGE-CAUSE
   1         Initial deployment
   2         Update image to v1.1.0
   3         Fix configmap issue

2. 版本详情查看
   通过--revision参数查看特定版本的完整配置：

   kubectl rollout history deployment/my-app --revision=2

   输出内容包括该版本的Pod模板、环境变量等完整YAML。

关键选项

选项	描述	示例
--revision	查看指定版本的详细配置	kubectl rollout history deploy/nginx --revision=3
-o yaml/json	以指定格式输出历史记录	kubectl rollout history deploy/nginx -o json
--record	记录当前命令到变更原因（需在修改命令中使用）	kubectl set image deploy/nginx nginx=nginx:1.19 --record

使用场景

1. 故障排查 当新版本出现问题时，通过对比历史版本的配置差异快速定位问题点。

2. 回滚准备 结合kubectl rollout undo命令，先通过history确定目标版本号：

   kubectl rollout undo deployment/my-app --to-revision=2

3. 审计追踪 在CI/CD流程中，通过--record记录变更来源（如Jenkins任务ID）：

   kubectl set image deploy/my-app app=my-image:v2.0 --record="Jenkins build #123"

注意事项

1. 变更记录依赖--record 若修改资源时未添加--record参数，CHANGE-CAUSE会显示为<none>，且可能继承前一条记录的说明（K8s已知设计行为）。

2. 历史版本保留策略 通过spec.revisionHistoryLimit控制保留的修订数量（默认保留全部），设为0将禁用回滚功能：

   apiVersion: apps/v1
   kind: Deployment
   spec:
     revisionHistoryLimit: 5  # 只保留最近5个版本

3. 生产环境建议

   • 所有修改命令都应添加--record
   • 重要变更建议通过更新YAML文件而非命令行修改（避免记录丢失）
   • 定期清理过期的历史版本（减少etcd存储压力）

扩展技巧

1. 与其他命令联动

   # 查看当前部署状态后再检查历史
   kubectl rollout status deployment/my-app && kubectl rollout history deployment/my-app

2. JSON Patch查询
   对于使用kubectl patch的修改，可通过--revision查看补丁效果：

   kubectl rollout history deploy/my-app --revision=3 | grep -A 5 "patch"