📚 课程目录第3章回滚基础概念

3. 自动化流水线基础：CI/CD 流水线概念、工具对比与流水线即代码

在 Kubernetes 集群升级与回滚场景中，自动化流水线是串联“代码提交 → 构建 → 测试 → 部署 → 验证”的核心骨架。本章从 CI/CD 基础概念出发，对比主流工具选型，并深入流水线即代码（Pipeline as Code）理念，为后续集成 Cluster 升级与回滚验证奠定工程化基础。

3.1 CI/CD 流水线核心概念

CI/CD 是持续集成（Continuous Integration）、持续交付（Continuous Delivery）和持续部署（Continuous Deployment）的统称。在集群升级场景中，流水线需要覆盖以下关键阶段：

阶段	目标	集群升级场景示例
持续集成（CI）	代码合并后自动构建、单元测试、静态扫描	升级脚本语法检查、Helm Chart Lint、容器镜像构建
持续交付（CD）	将构建产物自动部署到类生产环境，准备发布	自动部署升级 Job 到预发集群，执行预升级检查
持续部署（CD）	通过审批后自动部署到生产环境	灰度升级控制平面、节点池滚动、自动回滚触发
验证与回滚	部署后自动执行冒烟测试、健康检查，失败时自动回滚	Pod 就绪检查、API Server 可达性测试、etcd 一致性校验

实践要点： 集群升级流水线应至少包含“预检 → 升级 → 验证 → 回滚决策”四个原子阶段，每个阶段都应有明确的退出码和日志输出，便于自动化判断。

3.2 主流 CI/CD 工具对比

Jenkins、GitLab CI 和 GitHub Actions 是当前最主流的三种流水线引擎。下表从集群升级场景的关键维度进行对比：

维度	Jenkins	GitLab CI	GitHub Actions
部署方式	自托管，需维护 Master/Agent	SaaS 或自托管 Runner	SaaS 或自托管 Runner
流水线定义	Jenkinsfile（Groovy DSL）	.gitlab-ci.yml（YAML）	.github/workflows/*.yml（YAML）
Kubernetes 集成	原生 Kubernetes Plugin，动态 Agent	Kubernetes Executor，自动扩缩容	自托管 Runner 部署在 K8s 上
集群升级场景优势	插件生态丰富，可定制复杂审批流	内置容器注册表，CI/CD 一体化	与 GitHub 仓库深度集成，Action 市场丰富
回滚触发能力	通过 Webhook 或 Pipeline 步骤调用	通过 API 或 CI/CD 变量控制	通过 workflow_dispatch 或 check_run 事件
学习曲线	较高（Groovy 语法、插件配置）	中等（YAML 声明式）	较低（YAML 声明式，社区模板丰富）

  选型建议： 对于已有自建 Jenkins 的团队，建议保留 Jenkins 作为调度中心，通过 Kubernetes Plugin 动态生成 Agent 执行升级任务。新项目优先考虑 GitLab CI 或 GitHub Actions，利用其原生容器支持和声明式语法降低维护成本。

3.3 流水线即代码（Pipeline as Code）理念

流水线即代码（Pipeline as Code）将流水线的定义、配置、参数和步骤全部以代码形式存储在版本控制系统中。这一理念在集群升级场景中具有以下核心价值：

版本化与审计： 每次升级流程的变更都有 Git 历史记录，支持 diff 审查和回退。
可重复性： 同一份流水线代码可在开发、预发、生产环境执行，保证行为一致。
自动化触发： 通过 Git 事件（push、tag、PR）自动触发升级流水线，减少人工操作。
参数化： 通过环境变量或配置文件传递集群名称、目标版本、回滚阈值等参数。
测试驱动： 流水线代码本身可进行单元测试（如 Jenkins Pipeline Unit），提升可靠性。

3.4 声明式流水线示例

以下是一个基于 GitLab CI 的集群升级流水线片段，展示了 Pipeline as Code 的具体实现：

# .gitlab-ci.yml - 集群升级流水线示例
stages:
  - precheck
  - upgrade
  - verify
  - rollback

variables:
  CLUSTER_NAME: "production-cluster"
  TARGET_VERSION: "1.28.0"
  ROLLBACK_THRESHOLD: "2"  # 连续失败次数触发自动回滚

precheck-job:
  stage: precheck
  script:
    - kubectl version --short
    - kubectl get nodes -o wide
    - ./scripts/check-cluster-health.sh
  only:
    - tags

upgrade-control-plane:
  stage: upgrade
  script:
    - ./scripts/upgrade-control-plane.sh ${CLUSTER_NAME} ${TARGET_VERSION}
  when: on_success

verify-cluster:
  stage: verify
  script:
    - ./scripts/run-smoke-tests.sh
    - ./scripts/check-api-server.sh
  retry: 2

rollback-on-failure:
  stage: rollback
  script:
    - ./scripts/rollback-cluster.sh ${CLUSTER_NAME}
  when: on_failure

关键注意点： 流水线中的回滚阶段应使用 when: on_failure 或手动触发，避免在验证阶段因临时网络抖动导致误回滚。建议设置“验证重试次数”和“连续失败阈值”双重保护。

3.5 流水线即代码的最佳实践

单一职责原则： 每个流水线阶段只做一件事，如预检阶段只检查集群状态，不执行升级操作。
参数化设计： 将集群名称、目标版本、回滚策略等作为流水线变量，避免硬编码。
幂等性： 每个阶段脚本应支持重复执行，不会因重试导致集群状态异常。
日志与通知： 每个阶段输出结构化日志（JSON 格式），并通过 Webhook 或 Bot 通知运维人员。
版本锁定： 流水线依赖的工具（如 kubectl、helm）应锁定版本，避免因工具升级导致行为不一致。