【GitOps·ArgoCD篇】核心概念:Application、Project与Repo Server详解

发布时间:2026/8/15 17:10:57
【GitOps·ArgoCD篇】核心概念:Application、Project与Repo Server详解 前言上一篇跑通了第一个应用部署但 ArgoCD 背后发生了什么Application、Project、Repo Server 这些概念分别是什么本篇深入 ArgoCD 的核心概念和架构原理帮你从会用升级到理解。一、ArgoCD 架构总览┌──────────────────────────────────────────────────────────────┐ │ ArgoCD 架构 │ │ │ │ ┌─────────────┐ ┌──────────────┐ ┌───────────────────┐ │ │ │ API Server │ │ Repo Server │ │ Application │ │ │ │ (认证/UI) │ │ (Git操作) │ │ Controller │ │ │ │ 端口: 8080 │ │ 端口: 8081 │ │ (协调循环) │ │ │ └──────┬──────┘ └──────┬───────┘ └────────┬──────────┘ │ │ │ │ │ │ │ ┌──────┴──────┐ ┌──────┴───────┐ ┌────────┴──────────┐ │ │ │ Dex Server │ │ Redis Cache │ │ ApplicationSet │ │ │ │ (SSO/OIDC) │ │ (状态缓存) │ │ Controller │ │ │ └─────────────┘ └──────────────┘ └────────────────────┘ │ │ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ Notifications │ │ │ │ (Slack/钉钉/企微/Email/Webhook) │ │ │ └──────────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────────┘ ↓ 管理 ┌──────────────────────────────────────────────────────────────┐ │ K8s 集群 │ │ Application 1 Application 2 Application 3 │ │ (dev namespace) (test namespace) (prod namespace) │ └──────────────────────────────────────────────────────────────┘各组件职责组件职责端口API Server对外接口gRPC/RESTUI 后端认证授权8080Repo Server克隆 Git 仓库生成 manifestsHelm/Kustomize 渲染8081Application Controller协调循环比较 Git 和集群状态执行同步-ApplicationSet Controller批量生成 Application多集群/多环境-Redis缓存 Git 仓库内容和应用状态6379Dex ServerSSO/OIDC 认证对接 LDAP/Google/GitHub5556二、Application最核心的资源Application CRD 结构apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: myapp-prod # Application 名称 namespace: argocd # 必须在 argocd 命名空间 finalizers: - resources-finalizer.argocd.argoproj.io # 删除时清理关联资源 spec: # 源配置从哪里读配置 source: repoURL: https://github.com/myorg/myapp-deploy.git targetRevision: main # 跟踪哪个分支/Tag path: overlays/prod # 仓库中的路径 # 如果用 Helm # chart: myapp # Chart 名称 # helm: # values: | # replicas: 3 # image: # tag: v2.0.0 # 如果用 Kustomize自动检测不需要额外配置 # 只要路径下有 kustomization.yaml 即可 # 目标配置部署到哪里 destination: server: https://kubernetes.default.svc # 本集群 # server: https://prod-cluster:6443 # 外部集群 namespace: myapp-prod # 目标命名空间 # 同步策略 syncPolicy: automated: prune: true # 自动删除 Git 中不存在的资源 selfHeal: true # 自动修复漂移 syncOptions: - CreateNamespacetrue # 自动创建命名空间 - PrunePropagationPolicyforeground # 删除策略 # 资源钩子 # syncHooks 在同步前后执行 retry: limit: 3 # 失败重试3次 backoff: duration: 5s # 初始等待 factor: 2 # 退避因子 maxDuration: 30s # 最大等待 # 健康检查 # ArgoCD 内置了常见资源的健康检查逻辑 # 可以自定义 # 忽略资源差异 ignoreDifferences: - group: apps kind: Deployment jsonPointers: - /spec/replicas # 忽略副本数差异HPA 自动调整时有用 # 同步约束 # 同步前等待某些资源就绪 # syncConstraints:Application 状态说明argocd app get myapp-prod # 输出示例: # Name: myapp-prod # Project: default # Server: https://kubernetes.default.svc # Namespace: myapp-prod # URL: https://argocd.mycompany.com/applications/myapp-prod # Repo: https://github.com/myorg/myapp-deploy.git # Target: main # Path: overlays/prod # SyncWindow: Sync Allowed # Sync Policy: Automated (Prune, Self-Heal) # Sync Status: Synced (OK) # Health Status: Healthy状态含义Sync Status: Synced集群状态与 Git 仓库一致Sync Status: OutOfSync有差异等待同步Sync Status: Syncing正在同步中Health Status: Healthy所有资源健康Health Status: Progressing正在滚动更新Health Status: Degraded有资源不健康Health Status: Suspended资源被暂停三、Project多租户隔离Project 的作用Project 用于: 1. 限制 Application 可以部署到哪里集群命名空间 2. 限制可以使用的 Git 仓库 3. 限制可以部署的资源类型 4. RBAC 权限控制 5. 环境隔离开发组只能部署到 dev 命名空间创建 ProjectapiVersion: argoproj.io/v1alpha1 kind: AppProject metadata: name: team-alpha namespace: argocd spec: # 允许的源仓库 sourceRepos: - https://github.com/myorg/* - https://github.com/partner/* # 允许的目标集群和命名空间 destinations: - server: https://kubernetes.default.svc namespace: team-alpha-* # 通配符匹配 # 允许部署的资源类型 clusterResourceWhitelist: - group: kind: Namespace - group: kind: PersistentVolume namespaceResourceWhitelist: - group: * kind: * # 禁止的资源类型 namespaceResourceBlacklist: - group: kind: ResourceQuota # 禁止创建 ResourceQuota - group: kind: LimitRange # 角色定义用于 RBAC roles: - name: developer description: Team Alpha developers policies: - p, proj:team-alpha:developer, applications, *, team-alpha/*, allow groups: - myorg:team-alpha-developers # 对接 SSO Group # 同步窗口限制部署时间 syncWindows: - kind: allow schedule: * * * * 0-4,6 # 周日-周四周六允许 duration: 24h applications: - * manualSync: true # 允许手动同步Project RBAC# argocd-rbac-cm ConfigMap apiVersion: v1 kind: ConfigMap metadata: name: argocd-rbac-cm namespace: argocd data: policy.default: # 默认拒绝 policy.csv: | # 全局管理员 p, role:admin, applications, *, */*, allow # team-alpha 的开发者可以管理自己的应用 p, proj:team-alpha:developer, applications, *, team-alpha/*, allow # 只读用户 p, role:viewer, applications, get, */*, allow p, role:viewer, clusters, get, *, allow p, role:viewer, repositories, get, *, allow培训要点Project 是 ArgoCD 多租户的核心。没有 Project所有人都能部署到任何地方——这在生产环境中是不可接受的。每个团队至少有一个 Project限制其可操作范围。四、Repo ServerGit 操作引擎工作原理Application Controller 说: 我需要 myapp-deploy 仓库 main 分支的 overlays/prod 路径下的 manifests ↓ Repo Server: 1. 检查 Redis 缓存 → 有缓存直接返回 2. 没缓存 → 克隆/拉取 Git 仓库 3. 如果是 Helm → 运行 helm template 4. 如果是 Kustomize → 运行 kustomize build 5. 渲染出完整的 K8s manifests 6. 缓存到 Redis 7. 返回给 Application Controller ↓ Application Controller: 1. 拿到 Git 中的期望状态manifests 2. 从集群中读取实际状态 3. 比较差异 4. 如有差异执行同步Repo Server 配置# 修改 ArgoCD ConfigMap 增加 Repo Server 配置 apiVersion: v1 kind: ConfigMap metadata: name: argocd-cmd-params-cm namespace: argocd data: # Git 仓库轮询间隔默认3分钟 repo.server.timeout: 60s # 并发克隆数 reposerver.parallelism.limit: 10私有仓库的已知主机配置# 对于 SSH 方式连接的仓库需要配置 known_hosts apiVersion: v1 kind: ConfigMap metadata: name: argocd-ssh-known-hosts-cm namespace: argocd data: ssh_known_hosts: | github.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... gitlab.com ssh-rsa AAAAB3NzaC1yc2EAAA...五、ApplicationSet批量应用管理为什么需要 ApplicationSet传统方式每个应用一个 Application: Application: myapp-dev Application: myapp-test Application: myapp-staging Application: myapp-prod → 4个 Application大量重复配置 ApplicationSet 方式一个模板生成多个 Application: ApplicationSet 模板: 生成 4 个 Application: myapp-{dev,test,staging,prod} 每个用不同的路径和命名空间ApplicationSet 示例apiVersion: argoproj.io/v1alpha1 kind: ApplicationSet metadata: name: myapp-multi-env namespace: argocd spec: generators: # 列表生成器为每个环境生成一个 Application - list: elements: - env: dev namespace: myapp-dev path: overlays/dev - env: test namespace: myapp-test path: overlays/test - env: staging namespace: myapp-staging path: overlays/staging - env: prod namespace: myapp-prod path: overlays/prod template: metadata: name: myapp-{{env}} spec: project: default source: repoURL: https://github.com/myorg/myapp-deploy.git targetRevision: main path: {{path}} destination: server: https://kubernetes.default.svc namespace: {{namespace}} syncPolicy: automated: prune: true selfHeal: true syncOptions: - CreateNamespacetrueGit 目录生成器spec: generators: # 自动扫描 Git 仓库中的目录每个目录生成一个 Application - git: repoURL: https://github.com/myorg/monorepo-deploy.git revision: main directories: - path: apps/* # 会匹配 apps/service-a, apps/service-b 等六、本篇要点回顾ArgoCD 架构API Server认证UI Repo ServerGit操作 Application Controller协调 Redis缓存Application 是核心 CRDsourceGit→ destination集群→ syncPolicy策略Sync Status同步状态和 Health Status健康状态是两个独立维度AppProject 实现多租户限制仓库、命名空间、资源类型、RBACApplicationSet 批量生成 Application列表生成器和 Git 目录生成器下一篇预告《应用管理App-of-Apps 模式与多集群部署》——从单个应用扩展到多应用、多集群管理。