2. Argo CD 基础回顾：核心概念、架构组件与工作流程

在深入模板驱动自助目录之前，必须牢固掌握 Argo CD 的底层基础。本章将系统回顾 Argo CD 的三大核心概念（Application、Project、Repository）、关键架构组件以及端到端的工作流程，为后续的工程化设计奠定坚实的知识基础。

2.1 核心概念：Application、Project、Repository

Argo CD 围绕三个核心资源构建其声明式 GitOps 模型。理解它们之间的关系是使用 Argo CD 的第一步。

概念 定义 关键属性 类比
Application 代表一个部署单元，定义了“从哪个仓库、哪个路径、同步到哪个目标集群/命名空间”。 源（Source）、目标（Destination）、同步策略（Sync Policy） 一份“部署订单”，告诉厨师（Argo CD）从哪本书（Repo）的哪一页（Path）抄菜谱，送到哪张桌子（Cluster/Namespace）。
Project Application 的逻辑分组和权限边界。用于隔离团队、环境或业务线。 允许的源仓库、允许的目标集群、允许的资源类型、角色（RBAC） 一个“项目空间”或“部门”，规定了该部门的人（角色）可以看哪些书（Repo）、送到哪些区域（Cluster）。
Repository 存储 Kubernetes 清单（YAML/JSON/Helm/Kustomize）的 Git 仓库。Argo CD 通过连接该仓库来获取期望状态。 仓库 URL、认证方式（SSH/HTTPS/）、连接状态 一个“菜谱库”，里面存放着所有服务的部署配置。
关键关系： 一个 Repository 可以被多个 Application 引用；一个 Application 必须属于且仅属于一个 Project；一个 Project 可以包含多个 Application，并限制它们可以访问哪些 Repository 和 Cluster。

2.2 架构组件与核心模块

Argo CD 采用微服务架构，由多个协同工作的组件构成。下图展示了其核心组件及交互关系。

Argo CD 核心架构组件图 Argo CD 核心架构组件 Git Repository 期望状态（清单） API Server REST/gRPC 接口 Repo Server 清单生成与缓存 Application Controller 状态监控与同步 Redis 缓存 目标集群 K8s API 组件职责说明： • API Server：对外暴露 Web UI/CLI/API，处理认证、授权和应用 CRUD 操作。 • Repo Server：克隆 Git 仓库，生成最终 Kubernetes 清单（Helm/Kustomize 渲染），并缓存结果。 • Application Controller：持续监控 Application 状态，对比期望状态（来自 Repo Server）与实际状态（来自目标集群），执行同步。

2.3 核心工作流程：从 Git 提交到集群同步

Argo CD 的工作流程遵循“观察-对比-行动”的循环模式。以下是标准的一次同步周期：

  1. 用户提交变更：开发者在 Git 仓库中修改 Kubernetes 清单（YAML/Helm/Kustomize）并推送。
  2. Repo Server 拉取与渲染：Argo CD 的 Repo Server 定期轮询或通过 Webhook 感知变更，克隆仓库，并根据 Application 配置（如 Helm Values）渲染出最终的 Kubernetes 清单。
  3. 状态缓存：渲染后的清单被存储在 Redis 中，作为“期望状态”的快照。
  4. Application Controller 对比：Application Controller 定期（默认 3 分钟）从 Redis 读取期望状态，并通过 Kubernetes API 查询目标集群中对应资源的“实际状态”。
  5. 检测偏差：Controller 对比期望状态与实际状态。如果发现差异（OutOfSync），则根据同步策略（手动或自动）触发同步操作。
  6. 执行同步：Controller 调用 Kubernetes API 对目标集群应用期望状态（kubectl apply 或 kubectl create/delete），使实际状态向期望状态收敛。
  7. 状态更新：同步完成后，Application 的状态更新为 Synced 和 Healthy，并在 Argo CD UI/CLI 中展示。
关键流程总结： Git 仓库是唯一的“真相源”（Source of Truth）。Argo CD 确保集群中的实际状态始终与 Git 中定义的期望状态保持一致。任何手动修改集群资源的行为都会被 Argo CD 检测为“偏差”，并在下一次同步周期中被自动或手动纠正。

2.4 同步策略与状态概览

Argo CD 提供了灵活的同步策略来适应不同的运维场景。

策略类型 模式 描述 适用场景
手动同步 Manual 需要用户通过 UI 或 CLI 手动点击“Sync”按钮。Argo CD 仅检测和报告偏差。 生产环境、需要人工审批的变更、高风险操作。
自动同步 Automatic Argo CD 检测到偏差后，自动执行同步操作，无需人工干预。 开发/测试环境、CI/CD 流水线末端、低风险、追求快速迭代的场景。
自动修剪 Auto-Prune 与自动同步配合使用。当 Git 仓库中删除了某个资源定义时，Argo CD 会自动删除集群中对应的资源。 需要严格保持 Git 与集群资源一致性的场景。需谨慎使用，防止误删。
自我修复 Self-Heal 当集群中的资源被手动修改（与 Git 状态不一致）时，Argo CD 会自动将其恢复为 Git 中定义的状态。 防止配置漂移，确保集群状态始终受 Git 管控。
生产环境建议： 在生产环境中，推荐使用 手动同步 或 自动同步 + 禁止自动修剪 的组合。自动修剪和自动修复功能虽然强大，但若配置不当（如误删 Git 仓库中的关键资源），可能导致大规模服务中断。务必在非生产环境充分测试后再启用。
← 上一章 📖 返回目录 下一章 →