2. Argo CD 基础回顾:架构与核心概念

在将变更风险评估任务编排移植到 Argo CD 之前,必须深入理解其核心架构与概念。Argo CD 并非简单的 GitOps 触发器,而是一个由多个独立组件协同工作的声明式持续交付系统。本章将拆解其三大核心组件与三大核心概念,为后续的移植适配奠定基础。

2.1 Argo CD 架构:三组件协作模型

Argo CD 采用微服务架构,由 API Server、Repo Server 和 Application Controller 三个主要组件构成。它们各自独立部署,通过 gRPC 和 REST API 通信,共同实现“Git 仓库状态 = 集群运行状态”的闭环。

架构设计要点: 三组件分离设计使得 Repo Server 可以独立缓存 Git 数据,Application Controller 可以专注于集群状态对比,API Server 则统一对外暴露接口。这种解耦为后续插入自定义风险评估任务提供了清晰的扩展点。
Argo CD 三组件架构与交互流程 Argo CD 三组件架构与交互流程 API Server REST/gRPC 接口 Repo Server Git 仓库缓存 Application Controller 状态对比与同步 Git 仓库 Kubernetes 集群 用户 / CI 系统 获取清单 分发清单 同步指令 拉取/监听 同步/对比 CLI/UI/API 组件职责说明: • API Server:对外暴露 REST/gRPC 接口,处理认证、授权、Application CRUD 和同步请求。 • Repo Server:维护 Git 仓库的本地缓存,生成 Helm/Kustomize/Jsonnet 等清单,并返回给其他组件。 • Application Controller:持续对比 Git 中声明的期望状态与集群中实际运行状态,触发同步或告警。 • 三者通过 gRPC 通信,API Server 是唯一对外入口,Repo Server 和 Controller 不直接暴露端口。

2.2 核心概念详解

Argo CD 围绕三个核心概念构建其对象模型:Application(应用)、Project(项目)和 Sync Policy(同步策略)。理解这三者的关系是配置和管理 Argo CD 的基础。

2.2.1 Application:最小部署单元

Application 是 Argo CD 中的核心自定义资源(CRD),它定义了一个应用从 Git 仓库到 Kubernetes 集群的完整映射关系。每个 Application 包含三个关键部分:Source(源)、Destination(目标)和 Sync Policy(同步策略)。

字段 子字段 说明 示例值
spec.source repoURL / path / targetRevision 指定 Git 仓库地址、清单路径和分支/标签 https://github.com/example/app.git / ./manifests / main
spec.destination server / namespace 指定目标集群 API Server 地址和命名空间 https://kubernetes.default.svc / production
spec.syncPolicy automated / syncOptions / retry 定义自动同步行为、资源修剪策略和重试机制 automated: { prune: true, selfHeal: true }
移植适配提示: 在后续章节中,我们将通过扩展 Application 的 spec.source 和 spec.syncPolicy 字段,注入自定义的风险评估任务。例如,在 syncPolicy 中增加一个 preSync 钩子来执行变更影响分析。

2.2.2 Project:多租户隔离边界

Project 是 Argo CD 中的逻辑分组和权限隔离单元。一个 Project 可以包含多个 Application,并定义这些 Application 可以访问的 Git 仓库、目标集群和命名空间范围。Project 还支持配置全局的同步策略和资源配额。

  • 源白名单: 限制 Project 内的 Application 只能从指定的 Git 仓库拉取清单。
  • 目标白名单: 限制 Application 只能部署到指定的集群和命名空间。
  • 角色绑定: 通过 RBAC 为不同团队分配 Project 级别的操作权限。
  • 全局同步窗口: 定义允许自动同步的时间段,避免非工作时间意外变更。
常见误区: 不要将 Project 视为环境(如 dev/staging/prod)的替代品。Project 是团队/业务线的隔离边界,而环境应该通过不同的 Destination 或 Cluster 来区分。一个 Project 可以包含跨多个环境的 Application。

2.2.3 Sync Policy:同步行为控制器

Sync Policy 定义了 Application 在同步时的具体行为。它分为 自动同步 和 手动同步 两种模式,并支持丰富的选项来控制同步的精细度。

策略选项 类型 作用 风险等级
automated.prune 布尔 自动删除集群中不再存在于 Git 中的资源 高
automated.selfHeal 布尔 自动纠正集群中被手动修改的资源,恢复为 Git 状态 高
syncOptions.Validate 布尔 同步前对清单进行 Kubernetes 校验 中
syncOptions.CreateNamespace 布尔 如果目标命名空间不存在,自动创建 低
retry.limit 整数 同步失败时的最大重试次数 低
Argo CD 核心概念关系图 Argo CD 核心概念关系图 Project(项目隔离边界) Application A Source: repo-A/manifests Destination: cluster-1/prod SyncPolicy: auto + prune Application B Source: repo-B/helm-chart Destination: cluster-1/staging SyncPolicy: manual Application C Source: repo-C/kustomize Destination: cluster-2/dev SyncPolicy: auto + selfHeal Sync Policy 是 Application 的一部分,但 Project 可以设置默认策略: • 每个 Application 独立配置 syncPolicy;Project 可定义 allowedSyncOptions 来限制可用的同步选项。 • 风险评估任务将作为 PreSync / Sync / PostSync 钩子注入到 syncPolicy 中执行。

2.3 组件与概念的映射关系

理解组件与概念之间的映射关系,有助于在后续移植过程中准确定位需要修改或扩展的模块。

核心概念 主要交互组件 存储位置 扩展点
Application API Server(CRUD)、Application Controller(同步) Kubernetes CRD(etcd) 自定义 syncPolicy 钩子、自定义 Source 插件
Project API Server(CRUD)、Repo Server(源白名单校验) Kubernetes CRD(etcd) 自定义 RBAC 角色、全局同步窗口配置
Sync Policy Application Controller(执行)、Repo Server(清单生成) Application CRD 的子字段 PreSync/Sync/PostSync 钩子、自定义同步脚本
移植适配关键洞察: 变更风险评估任务最适合以 PreSync 钩子 的形式注入到 Application 的 syncPolicy 中。这样,在 Argo CD 执行任何同步操作之前,都会自动触发风险评估流程。如果评估失败,可以阻止同步继续执行,从而实现“风险前置”的安全策略。