🏗️ 深入剖析 Argo CD 架构：关键 CR 及其关系图的完整指南

大家好！在Kubernetes中实现GitOps时，Argo CD无疑是我们最熟悉的工具。然而，准确了解仪表板背后实际有哪些资源在运行，则是另一个领域。

今天，我们将深入探讨构成Argo CD核心的自定义资源（CR），并详细了解它们如何在集群内部连接以完成“声明式部署”。🛠️

---

1. 🌟 Argo CD 的四大核心自定义资源 (CR)

安装 Argo CD 时，集群中会创建多个 CRD。其中，运维人员必须了解的核心资源有以下四种：

① Application (最核心！)

这是连接用户定义的“源（Git）”和“目标（集群）”的最小单位。

• 作用: 定义将哪个仓库的哪个路径下的清单部署到哪个集群的哪个命名空间。

② AppProject (逻辑分组)

这是将 Application 捆绑在一起的治理和安全边界。

• 作用: 在多租户环境中，限制每个团队可访问的仓库、目标集群和资源类型。

③ ApplicationSet (自动化之花)

这是一个模板引擎，根据模式动态生成多个 Application。

• 作用: 处理“将此应用程序部署到所有区域”或“将 Git 中的所有文件夹分别创建为应用程序”等需求。

④ ArgoCD (实例管理)

这是通过 Argo CD Operator 安装时出现的资源，负责 Argo CD 自身的配置。

---

2. 🧬 资源之间的关系 (Relationship)

这些资源并非独立存在，而是像齿轮一样相互配合运行。

• AppProject ↔ Application: 每个 Application 都必须属于一个 AppProject。项目扮演着父级的角色，控制着子级应用程序的权限。
• ApplicationSet ↔ Application: ApplicationSet 就像一个“鱼形糕点模具”。它根据配置的 Generator（模式）自动生成多个 Application 资源。
• Application ↔ Kubernetes Resources: 当 Application 同步（Sync）后，实际的 Deployment、Service 等标准 Kubernetes 资源才会被创建。

---

3. 💻 实战代码与详细说明

我们将通过查看每个资源的 YAML 结构，了解如何在实际工作中进行配置。

📜 AppProject: 设置安全与边界

首先，创建一个项目，它是应用程序的“容器”。

YAML

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: platform-team-project
  namespace: argocd
spec:
  description: "플랫폼 팀 전용 프로젝트"
  # 1. 限制允许的 Git 仓库 📦
  sourceRepos:
    - "https://github.com/my-org/platform-infra.git"
  # 2. 指定可部署的目标集群和命名空间 🎯
  destinations:
    - server: "https://kubernetes.default.svc"
      namespace: "production-*"
  # 3. 限制可部署的资源类型 (增强安全性) 🛡️
  clusterResourceWhitelist:
    - group: ""
      kind: Namespace

📜 Application: 源与目标的映射

这是您将最常使用的资源。

YAML

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook-app
  namespace: argocd
spec:
  # 指定所属项目 (上面创建的项目)
  project: platform-team-project
  source:
    repoURL: "https://github.com/my-org/platform-infra.git"
    targetRevision: HEAD
    path: "guestbook" # Git 内部路径
  destination:
    server: "https://kubernetes.default.svc"
    namespace: "production-apps"
  # 设置自动同步策略 🔄
  syncPolicy:
    automated:
      prune: true     # 如果从 Git 删除，也从集群删除
      selfHeal: true  # 如果在集群中手动修改，则回滚

📜 ApplicationSet: 大规模部署自动化

当需要一次性管理多个集群或多个文件夹时使用。

YAML

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: microservices-set
  namespace: argocd
spec:
  # 1. 定义创建模式 (此处使用 List) 📋
  generators:
    - list:
        elements:
          - cluster: engineering-dev
            url: https://1.2.3.4
          - cluster: engineering-prod
            url: https://5.6.7.8
  # 2. 实际将要创建的 Application 模板 🏗️
  template:
    metadata:
      name: '{{cluster}}-guestbook' # 变量替换
    spec:
      project: default
      source:
        repoURL: https://github.com/argoproj/argocd-example-apps.git
        targetRevision: HEAD
        path: guestbook
      destination:
        server: '{{url}}'
        namespace: guestbook

---

4. 🔍 深入：资源生命周期与依赖性

基于我们之前讨论的内容，让我们总结一下在实际工作中需要注意的几点。

1. Cascading Delete (级联删除): 删除 Application 时，可以决定是否同时删除实际部署的资源。这通过 finalizers 设置来控制。
2. Project-level RBAC: AppProject 中定义的 Role 与 argocd-rbac-cm 联动，使特定团队只能查看自己的项目。
3. Status Sync: Application CR 内部的 status 字段实时存储 Git 与集群之间的差异 (Diff) 和健康状态。

---

📝 摘要表格

资源名称	主要作用	比喻
AppProject	权限控制，资源限制	围栏，管理区域
Application	单个应用程序的部署定义	实际部署说明书
ApplicationSet	动态/批量应用程序创建	鱼形糕点模具
ArgoCD	Argo CD 配置控制	控制塔设置

—

💡 总结

理解 Argo CD 的 CR 结构是稳定 GitOps 运维的第一步。特别是通过精心设计 ApplicationSet 和 AppProject 之间的关系，您可以用几行代码安全地管理数百个微服务。🎯

将这种结构设计应用到您的集群中，构建更坚固的基础设施吧！

---