📚 课程目录第2章 GitOps基础

2、GitOps基础：声明式配置、Git作为单一事实来源、GitOps工作流与传统CI/CD的区别

GitOps 是一种以 Git 仓库作为单一事实来源（Single Source of Truth）的运维与部署模式。它通过声明式配置描述系统的期望状态，并利用自动化工具（如 Argo CD）持续将集群实际状态向 Git 中定义的期望状态对齐。理解 GitOps 的三大核心支柱——声明式配置、Git 作为单一事实来源、以及自动化状态收敛——是掌握本课程后续实践的前提。

2.1 声明式配置：描述“要什么”，而非“怎么做”

声明式配置的核心思想是：用户只定义系统的期望状态（Desired State），而不编写具体的执行步骤。系统会自动决定如何从当前状态迁移到期望状态。

对比示例： 传统命令式（Imperative） vs 声明式（Declarative）

维度	命令式（Imperative）	声明式（Declarative）
操作方式	执行具体命令：`kubectl run nginx --image=nginx:1.25`	定义 YAML 文件：`apiVersion: v1; kind: Deployment; ...`
状态管理	手动跟踪变更，容易产生漂移	Git 仓库自动记录所有期望状态版本
可重复性	依赖操作顺序和环境上下文	任意时刻应用同一 YAML 得到相同结果
故障恢复	需要人工重新执行命令	自动检测漂移并回滚至 Git 定义状态

以下是一个典型的 Kubernetes 声明式 Deployment 配置示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: registry.example.com/my-app:v2.1.0
        ports:
        - containerPort: 8080

这份 YAML 文件完整描述了应用的期望状态：运行 3 个副本、使用 v2.1.0 镜像、监听 8080 端口。Argo CD 读取该文件后，会自动对比集群实际状态，并执行必要的创建、更新或删除操作。

2.2 Git 作为单一事实来源

在 GitOps 模型中，Git 仓库不再仅仅是代码托管平台，而是整个系统的权威状态数据库。所有环境（开发、预发布、生产）的配置、版本、策略都必须通过 Pull Request 合并到 Git 仓库的主分支，才能被应用到集群。

关键原则： 任何手动修改集群的行为（如 kubectl edit、kubectl scale）都会导致 Git 中的期望状态与集群实际状态不一致，这种不一致被称为“配置漂移”。GitOps 工具会自动检测并纠正这种漂移。

Git 作为单一事实来源带来的核心优势：

可审计性： 每一次配置变更都有完整的 Git 提交记录，包括作者、时间、变更内容。
回滚能力： 只需 git revert 到上一个提交，Argo CD 会自动将集群回滚到对应状态。
权限控制： 通过 Git 仓库的 Branch Protection 规则和 Code Review 流程，确保只有经过审批的变更才能生效。
灾难恢复： 当集群完全损坏时，只需重新部署 Argo CD 并指向 Git 仓库，即可重建整个集群状态。

2.3 GitOps 工作流与传统 CI/CD 的区别

传统 CI/CD 与 GitOps 在部署模型上存在根本性差异。下图直观展示了两者的核心区别：

下表从多个维度详细对比两种模式：

对比维度	传统 CI/CD	GitOps
部署触发方式	CI 流水线完成后，CD 工具主动推送（Push）到集群	Argo CD 等 Operator 持续从 Git 拉取（Pull）期望状态
配置存储位置	分散在 CI 脚本、配置文件、数据库、环境变量中	全部集中在 Git 仓库，单一入口
漂移处理	依赖人工巡检或额外监控告警，修复需手动执行命令	自动周期性对比，发现漂移立即自动回滚至 Git 定义状态
权限模型	CI 系统通常拥有集群管理员权限，安全风险较高	Git 仓库控制变更权限，Operator 仅需只读权限
回滚操作	重新触发 CI/CD 流水线，或手动执行 kubectl rollout undo	git revert 后自动同步，集群自动回滚
环境一致性	不同环境可能因配置差异导致行为不一致	所有环境使用同一 Git 仓库的不同分支，配置差异显式可见

2.4 GitOps 工作流核心步骤

一个标准的 GitOps 工作流包含以下五个关键环节：

开发人员提交变更： 修改 Kubernetes 清单文件（YAML）或 Helm Chart，提交 Pull Request 到 Git 仓库。
代码审查与合并： 通过 Code Review 后，变更合并到主分支（main/release）。
Argo CD 检测变更： Argo CD 持续监听 Git 仓库，检测到主分支有新的提交。
自动同步（Sync）： Argo CD 将 Git 中的期望状态与集群实际状态进行对比，执行 diff 并应用变更。
持续状态收敛： Argo CD 持续运行，一旦检测到集群状态偏离 Git 定义（如手动删除 Pod），立即自动纠正。

常见误区： GitOps 并不意味着完全不需要 CI。CI 仍然负责代码编译、单元测试、镜像构建和推送。GitOps 接管的是部署阶段——CI 将镜像推送到镜像仓库后，更新 Git 仓库中的镜像版本标签，Argo CD 再自动完成部署。CI 与 GitOps 是互补关系，而非替代关系。

2.5 声明式配置与 GitOps 的协同效应

声明式配置与 Git 作为单一事实来源的结合，产生了强大的协同效应：

可预测性： 任何时刻，只要 Git 仓库中的 YAML 文件不变，集群状态就不会发生意外变化。
可复现性： 将 Git 仓库克隆到新集群，Argo CD 可以重建完全相同的环境。
可观测性： Argo CD 提供清晰的 Diff 视图，直观展示“期望状态 vs 实际状态”的差异。
安全性： 无需将集群凭证暴露给 CI 系统，Argo CD 在集群内部运行，仅需拉取 Git 仓库的权限。

以下 SVG 图展示了 GitOps 工作流中声明式配置与 Git 仓库的协同关系：