“我们用 GitLab CI 部署到 K8s，算不算 GitOps？”
“每次上线还要手动点 Helm upgrade，能不能自动同步？”
“如何确保集群状态和 Git 仓库始终保持一致？”

如果你还在用 CI 工具直接调用 kubectl apply 或 helm upgrade，那你只是在做自动化部署，而非真正的 GitOps。

GitOps 的核心不是工具，而是一种以 Git 为唯一事实源（Single Source of Truth）的交付哲学。而 Argo CD 正是这一理念在 Kubernetes 领域的最佳实践。本文将带你深入理解 GitOps 原理，并通过 Argo CD 实现安全、可靠、可审计的声明式持续交付。

---

一、GitOps 核心：Git 是唯一事实源

传统 CI/CD 模型（如 GitLab CI + kubectl）属于 Push 模式：

• CI 流水线构建镜像后，主动“推送”配置到集群；
• 集群状态由外部脚本驱动，Git 与集群可能不一致。

而 GitOps 是 Pull 模式：

• 所有期望状态（YAML/Helm Chart）存储在 Git 仓库；
• 集群内的 Operator（如 Argo CD）持续“拉取” Git 状态；
• 自动比对并同步，确保集群始终与 Git 一致。

✅ 关键优势：

• 可审计：所有变更通过 Git MR（Merge Request）留痕；
• 可回滚：git revert 即可恢复上一状态；
• 自愈性：人为修改集群会被自动纠正。

---

二、Argo CD 架构：三大核心组件

Argo CD 由三个主要组件构成：

1. Application Controller

• 核心引擎，运行在 K8s 集群内；
• 持续监控 Git 仓库中的目标状态；
• 对比当前集群状态，执行同步操作。

2. Repo Server

• 负责从 Git 仓库拉取配置；
• 渲染 Helm/Kustomize 模板为最终 YAML；
• 缓存结果供 UI 和 Controller 使用。

3. Web UI / CLI

• 提供可视化界面，展示应用同步状态、健康状况、历史记录；
• 支持手动同步、回滚、参数覆盖等操作。

---

三、自动同步 vs 手动批准

Argo CD 支持两种同步策略：

1. 自动同步（Auto-sync）

• 当 Git 仓库更新时，自动同步到集群；
• 可配置是否允许自动创建资源（prune）和自我修复（self-heal）；
• 适用场景：dev/staging 环境，追求快速反馈。

syncPolicy:
  automated:
    prune: true
    selfHeal: true

2. 手动批准（Manual Sync）

• Git 更新后，需人工在 UI 或 CLI 中点击“Sync”；
• 适用场景：生产环境，需人工审核变更。

⚠️ 安全建议：生产环境务必关闭 auto-sync，结合 Git MR 审批流程，实现双重保障。

---

四、多环境管理：分支 or 目录？

如何用一个 Git 仓库存储多环境配置？主流有两种模式：

方案 1：多分支（Branch-based）

• dev 分支 → 开发环境
• prod 分支 → 生产环境

缺点：分支合并冲突频繁，难以追溯跨环境差异。

方案 2：目录隔离（Recommended）

apps/
├── user-service/
│   ├── base/               # 公共配置
│   ├── overlays/
│   │   ├── dev/
│   │   └── prod/           # 环境特有配置

配合 Kustomize 使用，Argo CD 可分别指向不同 overlay 目录：

source:
  repoURL: 'https://git.example.com/apps.git'
  path: 'user-service/overlays/prod'

✅ 优势：单一历史线，差异清晰，易于复用 base 配置。

---

五、安全：RBAC + SSO 集成

Argo CD 支持企业级安全控制：

1. RBAC（基于角色的访问控制）

• 定义用户/组对应用的操作权限（get/sync/override）；
• 示例：只允许 SRE 团队同步 prod 应用。

# argocd-rbac-cm
policy.csv:
  p, role:prod-admin, applications, sync, */*, allow
  g, sre-team@example.com, role:prod-admin

2. SSO 集成

• 支持 OIDC（如 Google、Azure AD、Keycloak）；
• 用户登录 Argo CD 时跳转至企业身份提供商；
• 权限基于 ID Token 中的 groups 或 email 字段。

🔒 效果：无需维护本地账号，权限与企业 IAM 系统统一。

---

六、GitOps 与 GitLab CI 的关系

很多人误以为 GitOps 要取代 CI，其实二者互补：

• GitLab CI：负责构建阶段（测试、镜像构建、推送）；
• Argo CD：负责部署阶段（从 Git 拉取配置，同步到集群）。

典型工作流：

1. 开发者提交代码 → 触发 GitLab CI；
2. CI 运行测试 → 构建镜像 → 推送到 Harbor；
3. CI 更新 Git 仓库中的 Helm values.yaml（如 image.tag: v1.2.3）；
4. Argo CD 检测到 Git 变更 → 自动同步新版本到集群。

🔗  GitOps 可作为【云原生】《GitLab CI + K8s：构建云原生 CI/CD 流水线》的增强方案，实现更安全的生产发布。
相比直接在 CI 中 helm upgrade，GitOps 将部署行为从“脚本执行”变为“状态声明”，大幅降低误操作风险。

---

七、实战：部署一个 Argo CD Application

apiVersion: argoproj.io/v1alpha1
kind: Application
meta
  name: user-service-prod
  namespace: argocd
spec:
  project: default
  source:
    repoURL: 'https://git.example.com/apps.git'
    targetRevision: HEAD
    path: 'user-service/overlays/prod'
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: prod
  syncPolicy:
    automated: {}  # 生产环境建议删除此行，改用手动同步

应用创建后，Argo CD 会：

• 拉取 prod overlay 配置；
• 渲染 Helm Chart；
• 同步到 prod 命名空间；
• 持续监控漂移（Drift Detection）。

---

结语：GitOps 不是工具，而是交付范式升级

Argo CD 的价值，不在于它能自动部署，而在于它强制团队将基础设施视为代码，并通过 Git 管理其全生命周期。

当你做到：

• 所有配置在 Git 中；
• 所有变更通过 MR；
• 所有部署由 Argo CD 驱动；

你就真正迈入了 声明式、可审计、自愈型 的云原生交付时代。

📌 关注专栏《云原生从入门到精通》，系统掌握从构建到交付的完整能力。