Argo CD 基础回顾:核心概念与工作流程

在深入多集群变更门禁与项目隔离之前,必须牢固掌握 Argo CD 的核心概念与架构。本章将系统回顾 Application、Project、Repository、Cluster 四大资源对象,以及控制平面与工作节点的组件协作流程,为后续的项目级安全策略与审批证据链设计奠定基础。

核心概念与资源模型

Argo CD 围绕四个核心资源构建声明式 GitOps 模型,下表总结了每个资源的职责与关键属性:

资源 职责 关键属性
Application 定义目标集群、命名空间、源仓库路径及同步策略 source.repoURL, destination.server, syncPolicy
Project 逻辑隔离边界,控制应用可访问的源仓库、目标集群与资源范围 sourceRepos, destinations, clusterResourceWhitelist
Repository 存储 Kubernetes 清单的 Git 仓库连接凭证与元数据 url, type, sshPrivateKey / password
Cluster 注册外部 Kubernetes 集群的 API Server 地址与凭据 server, config.bearerToken / awsAuthConfig
关键理解:Project 是 Argo CD 中实现多租户隔离与变更门禁的核心单元。没有 Project 约束,任何 Application 都可以引用任意仓库并部署到任意集群,这在多集群环境中是严重的安全风险。

架构组件与通信流程

Argo CD 采用控制平面 + 工作节点(Repo Server、Application Controller、Redis)的架构。下图展示了组件间的核心交互路径:

Argo CD 核心架构组件与交互流程 Argo CD 核心架构组件与交互流程 用户 / CI 系统 API Server Git 仓库 Repo Server App Controller Redis 缓存 目标集群 CLI / UI / API 生成清单 拉取 清单差异 缓存状态 同步/比较 组件职责说明: • API Server:认证授权、应用 CRUD、Project 策略校验 • Repo Server:克隆仓库、渲染 Helm/Kustomize/Jsonnet 模板,生成最终 Kubernetes 清单 • Application Controller:持续比较清单与集群实际状态,执行同步操作

工作流程:从 Git 提交到集群同步

一个完整的 Argo CD 工作流程包含以下步骤,每一步都涉及核心组件的协作:

  1. 用户提交变更:开发者向 Git 仓库推送 Kubernetes 清单变更(YAML、Helm Chart 或 Kustomize 覆盖)。
  2. Repo Server 拉取与渲染:Argo CD Repo Server 定期或通过 Webhook 触发拉取最新代码,执行模板渲染生成纯 Kubernetes 清单。
  3. Application Controller 比较差异:Controller 将渲染后的清单与目标集群中当前运行的资源进行 3-way 比较(当前状态 vs 目标状态 vs 上次同步状态)。
  4. 同步策略执行:根据 Application 的 syncPolicy(自动或手动),Controller 调用 Kubernetes API 执行 create/update/delete 操作。
  5. 状态反馈与缓存:同步结果写入 Redis 缓存,API Server 通过 gRPC 流式推送状态给 UI/CLI 客户端。
多集群场景关键点:Application Controller 可以同时管理多个目标集群。每个集群注册为独立的 Cluster 资源,Application 通过 destination.server 字段指定目标集群。Project 的 destinations 白名单则控制哪些集群可以被该 Project 下的 Application 使用。

Project 隔离:变更门禁的第一道防线

Project 在 Argo CD 中扮演着“安全容器”的角色。下图展示了 Project 如何约束 Application 的行为边界:

Project 隔离模型:源仓库、目标集群与资源约束 Project 隔离模型:源仓库、目标集群与资源约束 Project: production sourceRepos https://git.company.com/ prod-* 仓库 destinations cluster-prod-* namespace: prod-* clusterResourceWhitelist Deployment, Service ConfigMap, Secret Application: payment-service source: prod-payment-repo → destination: cluster-prod-eu / prod-payment Application 只能引用 sourceRepos 中列出的仓库,部署到 destinations 中允许的集群/命名空间,且只能创建 clusterResourceWhitelist 中允许的资源类型。
常见误区:仅靠 Application 级别的 syncPolicy 无法实现多租户安全隔离。如果未配置 Project 级别的 sourceRepos 和 destinations 白名单,任何拥有 Argo CD 写入权限的用户都可以将任意仓库的内容部署到任意集群。Project 隔离是变更门禁的强制性前置条件。

核心概念关系总结

下表从多集群管理视角,对比四个核心资源在变更门禁中的角色:

资源 变更门禁角色 多集群场景约束
Project 策略执行点:白名单、审批、RBAC 每个集群组(生产/预发/测试)应映射到独立 Project
Application 变更单元:声明期望状态 每个 Application 只能部署到一个集群的一个命名空间
Repository 可信来源:代码与配置的单一事实源 生产环境应使用只读凭证,禁止直接推送
Cluster 执行目标:运行时的 Kubernetes 环境 生产集群凭证应单独管理,定期轮换