2. GitOps 基础回顾：Git 作为单一事实来源、声明式配置、自动化同步

在深入资源画像与成本分摊联动优化之前，必须重新夯实 GitOps 的核心基础。GitOps 并非简单的“用 Git 管理配置”，而是一套以 Git 仓库为中心的运维与交付范式。本章将拆解其三大支柱：单一事实来源、声明式配置与自动化同步，并对比 ArgoCD 与 Flux 的实现差异。

2.1 单一事实来源：Git 仓库即系统状态的权威记录

传统运维中，配置散落在 CMDB、运维脚本、手动操作记录甚至工程师的本地终端中。GitOps 强制要求：集群中所有运行时状态（Deployment、Service、ConfigMap、Namespace 等）必须完整、精确地反映在 Git 仓库中。任何偏离 Git 的状态都被视为“漂移”，必须被自动或手动纠正。

下表对比了传统运维与 GitOps 在状态管理上的本质差异：

2.2 声明式配置：描述“想要的状态”而非“如何达到”

声明式配置是 GitOps 的语法基础。运维人员只需在 YAML 或 JSON 文件中描述集群的最终期望状态（例如“运行 3 个副本的 Nginx，暴露 80 端口”），而不需要编写如何创建 Pod、如何检查健康、如何滚动更新的步骤。GitOps 控制器负责将当前状态收敛到声明状态。

# 声明式配置示例：期望运行 3 个副本的 nginx 部署
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80

2.3 自动化同步：ArgoCD 与 Flux 的工作原理

自动化同步是 GitOps 的执行引擎。它持续监控 Git 仓库中的声明式配置，并与集群当前状态进行比对，自动执行必要的创建、更新或删除操作。目前主流工具为 ArgoCD 和 Flux，两者在同步机制上存在关键差异。

2.3.1 ArgoCD：基于 Pull 的主动同步

ArgoCD 以 Application 为管理单元，每个 Application 关联一个 Git 仓库路径和一个目标集群/命名空间。其核心工作流如下：

1. 注册仓库： 在 ArgoCD 中配置 Git 仓库地址、认证信息及目标路径。
2. 持续监控： ArgoCD 每隔 --sync-interval（默认 3 分钟）轮询 Git 仓库，或通过 Webhook 接收变更通知。
3. 差异对比： 将 Git 中的期望状态（Desired State）与集群中的实时状态（Live State）进行 Diff。
4. 自动/手动同步： 若检测到差异，ArgoCD 可自动执行 Sync 操作，或等待人工批准后执行。
5. 健康评估： 同步完成后，ArgoCD 根据资源类型（Deployment、Service 等）的健康检查规则评估应用状态。

2.3.2 Flux：基于 Reconciliation 的持续调谐

Flux 采用 Reconciliation Loop（调谐循环）模式，其核心组件包括 Source Controller、Kustomize Controller 和 Helm Controller。Flux 不直接管理“Application”，而是通过 GitRepository 和 Kustomization 自定义资源来定义同步规则。

• Source Controller： 负责从 Git 仓库、Helm 仓库或 S3 存储中拉取配置源，并缓存为 OCI 制品或本地快照。
• Kustomize Controller： 对拉取的 YAML 进行 Kustomize 渲染，然后 apply 到集群。
• Helm Controller： 专门处理 Helm Chart 的渲染与发布。
• Notification Controller： 处理告警与事件通知。

2.4 ArgoCD 与 Flux 核心差异对比

选择 ArgoCD 还是 Flux，直接影响同步窗口的优化策略。下表从同步机制、资源模型和成本分摊适配性三个维度进行对比：