3. GitOps 工作流：声明式配置、Git 作为单一事实来源、自动同步与手动审批模式对比

GitOps 的核心是将运维与交付的“期望状态”全部声明在 Git 仓库中，并通过自动化机制使运行环境持续趋近该状态。本章从三个维度拆解 GitOps 工作流：声明式配置的语义、Git 作为单一事实来源的约束力，以及自动同步与手动审批两种模式的适用场景与风险。

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

声明式配置只定义目标状态，由控制器负责调和。Kubernetes 原生资源（Deployment、Service、ConfigMap）本身就是声明式的最佳载体。

# 声明式示例：期望运行 3 个 nginx 副本，镜像版本 1.25
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-stable
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80

3.2 Git 作为单一事实来源（Single Source of Truth）

在 GitOps 模型中，Git 仓库是唯一被信任的期望状态定义。任何对集群的手动修改（kubectl edit、helm upgrade --install 绕过 Git）都会被视为“配置漂移”，并被 GitOps 控制器自动覆盖或告警。

3.3 自动同步模式：持续调和，零人工干预

自动同步模式下，GitOps 控制器持续监控 Git 仓库，一旦检测到新的 commit（或 PR merge），立即将变更应用到目标集群。适用于开发环境、非关键业务、需要快速迭代的场景。

• 优点： 部署速度快（秒级到分钟级）；减少人为操作失误；环境一致性高。
• 风险： 错误配置会直接扩散到生产；缺少变更审批环节；回滚依赖 Git revert 速度。
• 典型工具： Flux v2 默认启用自动同步；ArgoCD 可配置 syncPolicy.automated。

# ArgoCD Application 自动同步配置示例
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp-prod
spec:
  source:
    repoURL: https://github.com/team/gitops-config.git
    path: overlays/prod
    targetRevision: main
  destination:
    server: https://kubernetes.default.svc
    namespace: prod
  syncPolicy:
    automated:
      prune: true       # 自动清理 Git 中已删除的资源
      selfHeal: true    # 自动修复集群中的手动漂移
    syncOptions:
    - CreateNamespace=true

3.4 手动审批模式：变更闸门，安全优先

手动审批模式下，GitOps 控制器只负责检测 Git 仓库与集群的差异，但不会自动应用变更。运维或审批人通过 UI 或 CLI 确认后，才执行同步。适用于生产环境、合规敏感业务、多租户场景。

• 优点： 变更可审查、可暂停、可回滚；支持灰度发布前的最终确认；满足审计与合规要求。
• 代价： 部署速度变慢；需要人工值守；审批流程可能成为瓶颈。
• 典型实践： ArgoCD 关闭 automated，使用 argocd app sync 或 UI 手动同步；Flux 使用 --suspend 暂停调和。

3.5 两种模式对比与选择策略