4. K8s 回滚机制基础：kubectl rollout undo、回滚历史版本管理、revisionHistoryLimit

Kubernetes 的 Rollout（滚动更新） 机制为 Deployment、DaemonSet 和 StatefulSet 等工作负载提供了原生的版本管理与回滚能力。当一次发布引入配置错误、镜像缺陷或性能退化时，运维人员可以通过 kubectl rollout undo 命令快速将工作负载恢复到上一个稳定版本。理解回滚历史版本的管理策略以及 revisionHistoryLimit 参数的调优，是构建自动化发布流水线的基础。

4.1 kubectl rollout undo：一键回滚到上一版本

kubectl rollout undo 是 Kubernetes 提供的标准回滚命令，其核心原理是：将 Deployment 的 PodTemplate 替换为历史版本中保存的 PodTemplate，并触发一次新的滚动更新。

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

# 回滚到指定历史版本
kubectl rollout undo deployment/<deployment-name> --to-revision=<revision-number>

# 查看回滚状态
kubectl rollout status deployment/<deployment-name>

回滚执行流程：

1. 触发回滚： 执行 kubectl rollout undo 命令。
2. 版本切换： API Server 将 Deployment 的 spec.template 替换为指定历史版本的 PodTemplate。
3. 滚动更新： 控制器按照当前的更新策略（如 maxSurge、maxUnavailable）逐步替换 Pod。
4. 版本递增： 回滚操作本身会生成一个新的 Revision（版本号递增），而不是覆盖旧版本。

4.2 回滚历史版本管理

Kubernetes 通过 Revision（修订版本） 来管理回滚历史。每次 Deployment 的 PodTemplate 发生变化（包括更新、回滚、配置变更），控制器都会创建一个新的 Revision 并存储在 etcd 中。

查看历史版本：

# 查看所有历史版本及对应的 Change-Cause
kubectl rollout history deployment/<deployment-name>

# 查看指定版本的详细信息（包括完整的 PodTemplate YAML）
kubectl rollout history deployment/<deployment-name> --revision=<revision-number>

历史版本存储结构：

4.3 revisionHistoryLimit：控制历史版本保留数量

revisionHistoryLimit 是 Deployment 规范中的一个关键字段，用于限制保留的历史 Revision 数量。默认值为 10，设置为 0 表示不保留任何历史版本（禁用回滚能力）。

配置示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  revisionHistoryLimit: 5   # 只保留最近 5 个历史版本
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:1.0.0

参数调优建议：

4.4 回滚机制与 Revision 生命周期（SVG 图）

下图展示了从初始部署到多次更新、回滚过程中，Revision 的创建与清理机制。假设 revisionHistoryLimit 设置为 3。

4.5 自动化流水线中的回滚策略要点

在自动化发布流水线中，回滚机制需要与 CI/CD 工具（如 Jenkins、GitLab CI、ArgoCD）深度集成。以下是关键配置要点：

• 设置合理的 revisionHistoryLimit： 根据发布频率和存储容量，建议生产环境设置为 5~10，避免 etcd 因历史版本过多而性能下降。
• 记录 Change-Cause： 在每次部署时通过 kubectl annotate deployment/<name> kubernetes.io/change-cause="<描述>" 记录变更原因，便于回滚时快速识别目标版本。
• 自动化回滚触发条件： 在流水线中集成健康检查（如 kubectl rollout status、Prometheus 指标、SLA 监控），当新版本 Pod 启动失败或业务指标异常时自动触发回滚。
• 回滚后的验证： 回滚完成后，流水线应自动执行冒烟测试或金丝雀验证，确保回滚后的版本正常运行。

# 部署新版本
kubectl apply -f deployment-v2.yaml

# 等待 rollout 完成（超时 5 分钟）
if ! kubectl rollout status deployment/my-app --timeout=5m; then
  echo "部署失败，触发自动回滚"
  kubectl rollout undo deployment/my-app
  kubectl rollout status deployment/my-app --timeout=5m
  exit 1
fi

4.6 常见问题与避坑指南