📚 课程目录第3章多集群架构设计

3. 多集群架构设计：Hub-Spoke模式、ApplicationSet模式、多集群注册与RBAC基础

在多集群管理场景中，架构设计直接决定了变更门禁的落地成本与安全边界。本章聚焦三种核心设计模式：Hub-Spoke（中心辐射）、ApplicationSet（应用集生成）以及多集群注册与RBAC（基于角色的访问控制）基础。理解这些模式是构建可审计、可隔离的多集群变更门禁的前提。

3.1 Hub-Spoke 模式：控制面与工作负载面分离

Hub-Spoke 是 Argo CD 多集群管理中最经典的拓扑结构。一个中心集群（Hub）运行 Argo CD 控制面，多个工作集群（Spoke）仅运行工作负载，不安装 Argo CD 组件。

  核心优势： 控制面集中管理，工作集群无需暴露 API Server 给开发者；变更审批、审计日志、策略检查全部在 Hub 侧完成，符合安全合规要求。

3.2 ApplicationSet 模式：声明式多集群部署生成器

ApplicationSet 是 Argo CD 原生提供的多集群部署生成器，通过模板和生成器（Generators）自动为每个目标集群创建 Application 资源。它消除了手动重复创建 Application 的繁琐操作，同时保证了每个集群的 Application 配置一致性。

生成器类型	适用场景	变更门禁影响
List Generator	固定集群列表，手动维护集群标识	适合审批粒度按集群枚举的场景
Cluster Generator	自动发现 Argo CD 中已注册的集群	新增集群自动生成 Application，需配合 RBAC 限制
Git Generator	从 Git 仓库目录或文件动态生成参数	目录结构变化即触发 Application 变更，需严格审批
Matrix Generator	组合多个生成器结果，实现多维参数化	复杂度高，建议配合模板预审机制

最佳实践： 在变更门禁场景下，优先使用 Cluster Generator 结合 Argo CD 项目标签（Label）进行集群分组。这样可以在 ApplicationSet 模板中通过 selector 字段精确控制哪些集群接收变更，避免误部署到敏感环境。

3.3 多集群注册与 RBAC 基础

多集群注册是 Hub-Spoke 架构的起点。Argo CD 通过 argocd cluster add 命令或直接在 UI/API 中导入集群 kubeconfig 完成注册。注册后的集群信息存储在 Hub 集群的 Secret 资源中，命名空间为 argocd。

# 注册一个远程集群（示例）
argocd cluster add context-name \
  --name prod-cluster-01 \
  --label env=production \
  --label team=platform

# 查看已注册集群
argocd cluster list

# 注册后生成的 Secret 示例（简化）
apiVersion: v1
kind: Secret
metadata:
  name: cluster-prod-cluster-01
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: cluster
    env: production
    team: platform
type: Opaque
stringData:
  name: prod-cluster-01
  server: https://api.prod.example.com:6443
  config: |
    {
      "bearerToken": "<>",
      "tlsClientConfig": {
        "insecure": false,
        "caData": "<base64-ca>"
      }
    }

3.4 RBAC 基础：项目隔离与权限模型

Argo CD 的 RBAC 模型以 Project（项目） 为核心隔离单元。每个项目可以绑定特定的集群、Git 仓库、命名空间和资源类型。多集群场景下，RBAC 配置必须同时考虑 控制面（Hub） 和 工作负载面（Spoke） 两个维度。

3.5 项目配置示例：集群与仓库绑定

以下是一个 Argo CD 项目配置片段，展示了如何通过 sourceRepos 和 destinations 字段实现多集群隔离：

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: platform-prod
  namespace: argocd
spec:
  # 允许的 Git 仓库（只允许经过审批的仓库）
  sourceRepos:
  - 'https://git.internal.company.com/platform/prod-manifests.git'
  
  # 允许的目标集群和命名空间
  destinations:
  - namespace: 'prod-*'
    server: 'https://api.prod-cluster-01.example.com:6443'
  - namespace: 'prod-*'
    server: 'https://api.prod-cluster-02.example.com:6443'
  
  # 允许部署的资源类型（限制 ClusterRole 等敏感资源）
  clusterResourceWhitelist:
  - group: '*'
    kind: 'Namespace'
  - group: 'apps'
    kind: 'Deployment'
  - group: 'networking.k8s.io'
    kind: 'Ingress'
  
  # 拒绝所有未显式允许的集群资源
  clusterResourceBlacklist:
  - group: 'rbac.authorization.k8s.io'
    kind: 'ClusterRole'
  - group: 'rbac.authorization.k8s.io'
    kind: 'ClusterRoleBinding'
  
  # 同步策略：禁止自动同步，必须手动审批
  syncWindows:
  - kind: deny
    schedule: '* * * * *'
    duration: 1h
    applications:
    - '*-prod'
    clusters:
    - 'https://api.prod-cluster-01.example.com:6443'
    namespaces:
    - 'prod-*'

安全警告： 在多集群注册时，务必使用 专用 Service Account 而非管理员。每个集群的 kubeconfig 应限制在最小权限范围内（例如只授予 argocd-manager 角色）。定期轮换集群 Secret 中的，避免凭证泄露导致所有集群被接管。

3.6 多集群注册与 RBAC 的合规检查清单

检查项	合规要求	验证方式
集群注册凭证	每个集群使用独立 Service Account，权限最小化	检查 Secret 中对应的 RBAC 绑定
项目集群绑定	每个项目只允许访问指定的集群组	审计 `AppProject.spec.destinations`
仓库来源限制	只允许经过安全扫描的 Git 仓库	审计 `AppProject.spec.sourceRepos`
资源类型白名单	禁止部署 ClusterRole、ClusterRoleBinding 等敏感资源	审计 `clusterResourceBlacklist`
同步窗口策略	生产集群必须配置 deny 窗口，禁止自动同步	审计 `syncWindows` 配置
审计日志	所有集群注册和项目修改操作记录到审计日志	启用 Argo CD 审计日志并接入 SIEM

通过 Hub-Spoke 架构、ApplicationSet 声明式生成以及精细化的 RBAC 项目隔离，多集群变更门禁具备了可审计、可追溯、可控制的基础设施底座。下一层我们将深入 ApplicationSet 的生成器高级用法与审批钩子集成。