4. ArgoCD 架构与组件：Application、Project、Repo Server、Controller

ArgoCD 遵循 声明式 GitOps 模式，其核心架构由四个主要组件构成：Application（应用）、Project（项目）、Repo Server（仓库服务）和 Application Controller（应用控制器）。理解这些组件的职责与协作关系，是构建多团队 GitOps 流水线的基础。

4.1 核心组件总览

下表列出了 ArgoCD 四大核心组件及其在 GitOps 工作流中的角色：

组件 类型 核心职责 关键特性
Application CRD 资源 定义目标集群、源仓库、同步策略 声明式配置，支持自动/手动同步
Project CRD 资源 多租户隔离、权限控制、资源配额 限制目标集群、源仓库、命名空间
Repo Server 无状态服务 拉取 Git 仓库、生成 Kubernetes 清单 支持 Helm/Kustomize/Jsonnet 等工具
Application Controller 有状态控制器 持续对比期望状态与实际状态 自动修复漂移、回滚、健康检查

4.2 组件协作流程

下图展示了 ArgoCD 内部组件之间的数据流与协作关系：

ArgoCD 核心组件协作架构 Git 仓库 声明式清单 Repo Server 生成 Kubernetes 清单 Application Controller 对比 & 同步 Kubernetes 集群 实际运行状态 Application / Project CRD 配置 拉取 传递清单 同步/回滚 状态反馈 读取配置 💡 说明：Application 和 Project 作为 CRD 存储在 Kubernetes 中，Application Controller 持续读取它们来驱动同步循环。

4.3 组件详解

4.3.1 Application（应用 CRD）

Application 是 ArgoCD 的核心资源，它定义了 GitOps 工作流的三个关键要素：

  • 源（Source）：Git 仓库 URL、路径、分支以及 Helm/Kustomize 参数。
  • 目标（Destination）：目标 Kubernetes 集群的 API Server 地址和命名空间。
  • 同步策略（Sync Policy）：自动/手动同步、自动创建命名空间、Prune 资源行为。

多团队场景提示： 每个团队的应用应使用独立的 Application 资源，并通过 spec.destination.namespace 隔离到不同命名空间，避免资源冲突。

4.3.2 Project（项目 CRD）

Project 是 ArgoCD 的多租户隔离单元，用于限制 Application 的行为范围：

限制维度 配置字段 典型值示例
允许的源仓库 spec.sourceRepos https://git.company.com/team-a/*
允许的目标集群 spec.destinations https://k8s-prod.example.com
允许的目标命名空间 spec.destinations.namespace team-a-*
资源配额 spec.clusterResourceWhitelist Deployment, Service, ConfigMap

4.3.3 Repo Server（仓库服务）

Repo Server 是一个无状态服务，负责将 Git 仓库中的原始配置转换为 Kubernetes 可识别的清单文件。它支持多种配置管理工具：

  • 原生 YAML：直接读取目录下的 YAML 文件。
  • Helm Chart：渲染 Helm Chart，支持 values 覆盖。
  • Kustomize：执行 kustomize build 生成最终清单。
  • Jsonnet / Tanka：编译 Jsonnet 模板。

性能优化： Repo Server 会缓存已拉取的仓库内容，减少对 Git 服务器的重复请求。多团队场景下建议配置 reposerver.repository.cache.expiry 参数。

4.3.4 Application Controller（应用控制器）

Application Controller 是 ArgoCD 的“大脑”，它运行一个持续循环：

  1. 对比（Diff）：将 Repo Server 生成的期望清单与 Kubernetes 集群中的实际状态进行对比。
  2. 同步（Sync）：当检测到漂移时，执行同步操作将集群状态修正为期望状态。
  3. 健康检查（Health Check）：监控已部署资源的健康状态（如 Deployment 的 Ready 副本数）。
  4. 回滚（Rollback）：支持通过 Application 历史版本快速回滚到之前的同步状态。

    5. 4.4 组件间通信与安全

    下表总结了组件间的通信方式及安全考量：

    通信路径 协议 安全机制
    Repo Server → Git 仓库 HTTPS / SSH SSH 密钥 / 令牌认证
    Application Controller → Repo Server gRPC (TLS) mTLS 双向认证
    Application Controller → K8s API HTTPS ServiceAccount / Kubeconfig
    用户/CI → ArgoCD API HTTPS OIDC / RBAC / JWT

    4.5 多团队协作中的组件设计原则

    关键实践： 在多团队 GitOps 流水线中，应遵循以下组件设计原则：

    • 一个团队一个 Project：每个团队拥有独立的 Project，限制其只能访问自己的仓库和命名空间。
    • Application 与微服务一一对应：每个微服务或组件对应一个 Application，便于独立回滚和审计。
    • Repo Server 共享但隔离：所有团队共享 Repo Server 实例，但通过 Project 的 sourceRepos 限制仓库访问。
    • Controller 全局统一：一个 Application Controller 管理所有团队的 Application，通过 RBAC 实现操作权限隔离。

    理解 ArgoCD 的这四个核心组件及其协作关系，是后续章节中配置多团队流水线、实现精细化权限控制以及执行回滚操作的基础。下一节将深入讲解如何通过 Application 和 Project 实现多租户隔离。

    ← 上一章 📖 返回目录 下一章 →