2. K8s回滚基础：K8s原生回滚机制

Kubernetes 原生回滚机制是 GitOps 流水线中故障恢复的底层保障。理解 Deployment rollout undo 的工作原理、历史查看方式以及策略配置，是构建可靠回滚能力的前提。本章从这三个维度展开，帮助你在 GitOps 场景中精准调用 K8s 原生能力。

2.1 Deployment Rollout Undo 核心机制

kubectl rollout undo 是 Kubernetes 提供的原生回滚命令，其本质是将 Deployment 的 PodTemplate 恢复到历史版本中的某个修订版（Revision）。K8s 通过 ReplicaSet 记录每次变更的快照，回滚时只需调整控制器指向的目标 ReplicaSet。

# 回滚到上一个版本（默认）
kubectl rollout undo deployment/nginx-deployment

# 回滚到指定 Revision
kubectl rollout undo deployment/nginx-deployment --to-revision=3

# 查看回滚状态
kubectl rollout status deployment/nginx-deployment

2.2 回滚历史查看与 Revision 管理

K8s 默认保留 10 个历史 Revision，可通过 revisionHistoryLimit 调整。查看历史记录是回滚决策的关键步骤。

# 查看历史版本列表
kubectl rollout history deployment/nginx-deployment

# 输出示例：
# REVISION  CHANGE-CAUSE
# 1         kubectl apply --record=true
# 2         kubectl set image deployment/nginx nginx=nginx:1.21
# 3         kubectl set image deployment/nginx nginx=nginx:1.22

# 查看 Revision 3 的完整配置
kubectl rollout history deployment/nginx-deployment --revision=3

2.3 回滚策略配置与参数详解

Deployment 的回滚行为受 .spec.strategy 和 .spec.revisionHistoryLimit 控制。合理配置这些参数，可以平衡回滚速度、稳定性和历史保留深度。

2.3.1 revisionHistoryLimit

控制保留的 ReplicaSet 数量，默认值为 10。设置为 0 将关闭历史记录，导致无法回滚。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  revisionHistoryLimit: 5  # 只保留最近 5 个版本
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
  template:
    # ... Pod 模板

2.3.2 回滚过程中的滚动更新参数

回滚本质是一次滚动更新，因此 maxSurge 和 maxUnavailable 同样生效。

2.4 回滚策略配置对比

根据业务场景选择合适的回滚策略配置，以下为三种典型配置模板：

2.5 回滚操作的实际影响

• Revision 递增： 每次 rollout undo 都会产生一个新的 Revision，历史版本链持续增长。
• Pod 重建： 回滚会导致旧版本 Pod 重新创建，而非原地恢复，因此会触发新一轮 Readiness 探针检查。
• 事件记录： 回滚操作会在 Deployment 的 Events 中记录，可通过 kubectl describe deployment 查看。
• 与 HPA 的交互： 回滚期间如果 HPA 正在扩缩容，可能出现短暂的副本数冲突，建议回滚前暂停 HPA。