1. GitOps 基础概念

GitOps 是一种以 Git 仓库作为单一事实来源(Single Source of Truth)的云原生运维模式。它将声明式配置、版本控制与自动化交付管道相结合,使基础设施和应用的变更可审计、可回滚、可协作。本节从四个核心维度建立 GitOps 的知识地基。

1.1 GitOps 定义

GitOps 由 Weaveworks 在 2017 年正式提出,其核心思想是:用 Git 仓库管理整个系统的期望状态,并通过自动化机制持续使实际状态趋近于期望状态。GitOps 并非单一工具,而是一套结合了 DevOps 实践、Kubernetes 声明式模型和 Git 工作流的方法论。

维度 传统运维 GitOps 模式
配置来源 手动执行命令、脚本、CMDB Git 仓库(单一事实来源)
变更方式 SSH 登录、kubectl 直接操作 Pull Request + 自动化同步
状态收敛 人工巡检、告警后修复 持续 Reconciliation(调谐循环)
回滚策略 依赖备份快照或手动逆向操作 git revert + 自动同步
审计能力 操作日志分散、难以追溯 Git 提交历史完整可审计
关键认知: GitOps 不是“用 Git 存 YAML”,而是“用 Git 驱动整个系统的状态管理”。任何绕过 Git 的手动变更都破坏了 GitOps 的核心契约。

1.2 声明式配置

声明式配置(Declarative Configuration)是 GitOps 的底层语言。与命令式(Imperative)方式不同,声明式只描述“系统应该是什么状态”,而不描述“如何达到该状态”。Kubernetes 的 YAML 清单是声明式配置的典型代表。

# 命令式:告诉系统做什么
kubectl create deployment nginx --image=nginx:1.25
kubectl scale deployment nginx --replicas=3

# 声明式:告诉系统期望状态
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
声明式优势: 幂等性(多次应用结果一致)、可预测性(状态由 YAML 精确描述)、可组合性(多个声明式对象可叠加管理)。

1.3 Git 作为单一事实来源

在 GitOps 体系中,Git 仓库存储了所有环境(开发、预发、生产)的期望配置。任何对系统的合法变更都必须先提交到 Git,再由自动化组件同步到目标集群。这种设计带来了三个核心收益:

  • 可追溯性: 每一次变更都有作者、时间戳、变更说明和代码差异。
  • 可恢复性: 通过 git revert 或 git checkout 即可将整个环境恢复到任意历史状态。
  • 协作性: 团队通过 Pull Request 评审、分支策略和合并门禁来管控变更质量。
常见误区: 将 Git 仓库仅当作“配置文件备份”。GitOps 要求 Git 仓库是唯一的配置入口,任何手动 kubectl apply 或 Helm upgrade 都会导致状态漂移(Drift),破坏 GitOps 的信任模型。

1.4 GitOps 工作流概述

GitOps 工作流可以抽象为“提交-同步-调谐”三个核心阶段。下图展示了从开发者提交代码到集群实际状态收敛的完整链路。

GitOps 工作流:提交 → 同步 → 调谐 开发者 / CI 系统 提交 YAML / Helm Chart git push Git 仓库 单一事实来源 watch / webhook GitOps Operator ArgoCD / Flux sync K8s 调谐循环(Reconciliation Loop) 1. Operator 从 Git 仓库拉取期望状态(Desired State) 2. 对比集群当前状态(Current State)与期望状态 3. 自动执行差异修复(kubectl apply / Helm upgrade / Kustomize build) ① 提交变更 PR → Merge → git push ② 检测差异 Operator 轮询 / Webhook ③ 自动同步 kubectl apply / Helm upgrade K8s 集群 GitOps 工作流确保 Git 仓库中的每一次提交都能安全、可审计地到达目标集群

1.5 GitOps 核心组件关系

下图展示了 GitOps 体系中各组件之间的依赖与数据流向,帮助理解“仓库-Operator-集群”三层架构。

GitOps 核心组件关系图 Git 仓库 应用配置 + 基础设施配置 GitOps Operator 集群(ArgoCD / Flux) 拉取配置 → 差异对比 → 自动同步 → 健康检查 支持多集群、多租户、同步波次、钩子(Sync Waves / Hooks) 生产集群 Namespace A / B / C 预发集群 Namespace Staging 开发集群 Namespace Dev git pull / webhook kubectl apply / Helm install

1.6 GitOps 适用场景与前提条件

场景 适用性 说明
Kubernetes 集群管理 ✅ 强适用 声明式 API 天然匹配 GitOps 模型
多环境部署(Dev/Staging/Prod) ✅ 强适用 分支策略 + Kustomize overlay 管理差异
多租户隔离 ✅ 强适用 每个租户独立目录 + RBAC + 同步波次
数据库 Schema 变更 ⚠️ 需配合工具 需结合 Liquibase / Flyway 等迁移工具
有状态应用(StatefulSet + PVC) ⚠️ 需谨慎 需处理数据持久化与存储类映射
传统虚拟机 / 裸金属 ❌ 不适用 缺乏声明式 API 层,建议使用 Ansible + Git
课程前置提示: 本章建立的 GitOps 基础概念是后续“多租户同步波次编排”和“成本窗口隔离策略”的基石。理解声明式配置与 Git 单一事实来源,是掌握波次编排和隔离策略的前提。