📚 课程目录第4章 K8s回滚基础

4. K8s 回滚基础：kubectl rollout undo 命令、回滚历史版本查看与指定版本回滚

在 Kubernetes 集群中，Deployment 的滚动更新（Rolling Update）机制保证了应用可以平滑升级。然而，当新版本发布后出现异常（如 CrashLoopBackOff、响应超时、业务逻辑错误），快速回滚到上一个稳定版本是运维人员的核心技能。本章将深入解析 kubectl rollout 命令族，重点掌握 undo 操作、历史版本查看与指定版本回滚。

4.1 回滚核心命令：kubectl rollout undo

kubectl rollout undo 是 Kubernetes 内置的回滚指令，它通过修改 Deployment 的 PodTemplate 哈希值，触发控制器将 Pod 副本集（ReplicaSet）回退到指定的历史版本。其基本语法如下：

# 回滚到上一个版本（默认行为）
kubectl rollout undo deployment/<deployment-name> -n <namespace>

# 回滚到指定版本（通过 --to-revision 参数）
kubectl rollout undo deployment/<deployment-name> --to-revision=<revision-number> -n <namespace>

关键行为：执行 undo 后，K8s 不会立即删除当前异常的 ReplicaSet，而是将目标 ReplicaSet 的副本数（replicas）调整到期望值，同时将当前 ReplicaSet 的副本数缩为 0。历史 ReplicaSet 会保留在集群中，用于后续再次回滚。

4.2 查看回滚历史版本

在回滚之前，必须确认可用的历史版本列表。使用 kubectl rollout history 命令可以查看 Deployment 的所有修订版本（Revision）。

# 查看所有历史版本摘要
kubectl rollout history deployment/nginx-deployment -n production

# 查看指定版本的详细信息（包括 PodTemplate 的完整 YAML）
kubectl rollout history deployment/nginx-deployment --revision=3 -n production

输出示例：

deployment.apps/nginx-deployment
REVISION  CHANGE-CAUSE
1         <none>
2         kubectl set image deployment/nginx-deployment nginx=nginx:1.21.6 --record=true
3         kubectl set image deployment/nginx-deployment nginx=nginx:1.23.1 --record=true

注意：如果创建 Deployment 时没有使用 --record=true 或在更新时未记录变更原因，CHANGE-CAUSE 列会显示 <none>。建议在 CI/CD 流水线中统一使用 kubectl annotate 或 --record 标记变更原因，便于追溯。

4.3 指定版本回滚实战

假设当前 Deployment 处于 Revision 3（异常版本），需要回滚到 Revision 1（稳定版本）。操作流程如下：

确认当前状态：使用 kubectl rollout status deployment/nginx-deployment 查看是否处于可用状态。
查看历史版本：执行 kubectl rollout history deployment/nginx-deployment 获取所有 Revision 编号。
执行指定回滚：kubectl rollout undo deployment/nginx-deployment --to-revision=1
验证回滚结果：使用 kubectl rollout status deployment/nginx-deployment 等待回滚完成，并检查 Pod 状态。

# 完整回滚命令示例
kubectl rollout undo deployment/nginx-deployment --to-revision=1 -n production

# 验证回滚后的版本
kubectl rollout history deployment/nginx-deployment -n production

# 查看 Pod 是否正常运行
kubectl get pods -n production -l app=nginx

4.4 回滚流程与版本管理机制

下图展示了 K8s 回滚的核心流程，从用户发起 undo 命令到最终 Pod 副本集切换的完整链路：

4.5 回滚参数与行为对比

下表总结了 kubectl rollout undo 在不同参数下的行为差异，帮助你在流水线中精确控制回滚动作：

参数组合	行为描述	适用场景
`undo deployment/<name>`	回滚到上一个版本（Revision N-1）	快速恢复最近一次异常发布
`undo deployment/<name> --to-revision=1`	回滚到指定的 Revision 编号	需要跳过中间版本，直接回到已知稳定版本
`undo deployment/<name> --dry-run=client`	模拟回滚，不实际执行	在流水线中预检回滚目标是否正确
`undo deployment/<name> --timeout=5m`	设置回滚等待超时时间	避免回滚过程卡住导致流水线无限等待

4.6 回滚后的版本号变化

理解回滚后 Revision 的变化规律，对于流水线中的版本追踪至关重要。下图展示了回滚操作对 Revision 序列的影响：

undo --to-revision=1 后： Rev 1 Rev 2 Rev 3 ← 当前版本（回滚后） Rev 2、Rev 3 保留但缩容至 0 Revision 变化规则 • 回滚不会创建新的 Revision 编号 • 当前 Revision 指向目标版本 • 后续再次更新会创建 Rev 4 • 历史版本保留数量受 revisionHistoryLimit 控制

4.7 流水线集成中的回滚策略要点

流水线回滚设计原则：

版本追溯：在 CI/CD 流水线中，每次部署前记录当前 Revision 和镜像版本到制品库或配置中心，便于回滚时快速定位目标 Revision。
渐进式回滚：优先使用 --to-revision 指定已知稳定版本，避免使用默认的“上一个版本”回滚（可能上一个版本也是异常的）。
超时控制：在流水线脚本中为 rollout undo 设置合理的 --timeout 参数，防止回滚过程卡死导致流水线阻塞。
回滚验证：回滚完成后，自动执行健康检查（如 kubectl rollout status + 业务探活接口），确认服务恢复后再继续后续步骤。

4.8 常见避坑指南

问题场景	原因分析	解决方案
回滚后 Pod 仍异常	回滚的目标版本本身存在缺陷（如配置错误、依赖不兼容）	回滚前确认目标 Revision 的镜像版本和配置，建议使用 `--dry-run` 预检
回滚命令报错 "revision not found"	目标 Revision 已被 `revisionHistoryLimit` 清理，或从未存在	增大 `revisionHistoryLimit`（默认 10），或在流水线中持久化历史版本信息
回滚后 Revision 编号未变化	这是 K8s 的正常行为，回滚不产生新 Revision	通过 `kubectl rollout history` 确认当前指向的 Revision 编号
回滚过程中服务中断	Deployment 的 `strategy.type` 不是 RollingUpdate，或 `maxSurge`/`maxUnavailable` 配置不当	确保使用滚动更新策略，并合理设置 `maxSurge: 25%` 和 `maxUnavailable: 25%`