阿里云ACK One GitOps：轻松实现多团队多集群应用交付

作者：蔡靖

GitOps 概述、

应用分发 GitOps 的核心是以 Git 仓库作为应用部署的唯一来源，持续同步 Git 仓库中应用状态到 Kubernetes 集群上。CNCF 于 2023 年底发布的一项评估 GitOps 使用趋势的微观调查结果 [ 1] ，其数据显示 GitOps 已经成为大多数开发者实现快速、一致、安全交付的首要选择。2022 年 12 月 CNCF Argo 项目正式毕业 [ 2] ，标志着 Argo 项目的稳定和成熟，也让更多基于 Kubernetes 的用户使用 Argo CD 来实现 GitOps CD。

GitOps 的优势：

快速交付、持续部署应用

通过自动化的构建和部署提升部署速度；并自动同步 Kubernetes 集群和 Git 仓库中的应用状态，保持状态一致。
可靠性强

Git 仓库作为应用部署的唯一来源，提供版本控制，快速回滚和审计能力；实现更高的部署一致性。
安全性高

开发者使用 GitOps 无需任何 Kubernetes 集群权限，只需要 Git 仓库权限；自动化流程更安全，减少手动操作的出错风险。
简单易学

Git 易于被接受开发者接受，易于集成，无额外学习成本。

ACK One GitOps

ACK One GitOps 提供了面向多云、多集群、混合云的多集群应用 GitOps 持续交付能力。通过全托管开源的 Argo CD 项目，集成 ACK One 的多集群、阿里云的 RAM SSO 等能力，为您提供开箱即用的 ArgoCD 能力，和完整、安全的多集群应用 GitOps CD 体验，快速、一致、安全地实现混合云、多集群下的应用持续部署。

下图为 ACK One GitOps 能力图：

开发者通过 ArgoCD UI/CLI/Go SDK 创建 Application 或者 ApplicationSet，部署应用；
开发者更新新镜像到镜像仓库，ArgoCD Image Updater 检测到镜像更新后，将新 tag 更新到 Git 仓库的 yaml 中；
ArgoCD 定时同步 Git 仓库的应用状态到云上、云下集群（GitOps 中 Secret 管理基于 KMS 实现）；
应用同步过程中状态变化实时钉钉通知。

ACK One GitOps 优势如下：

托管开源 ArgoCD，提供 ArgoCD 原生 CLI 和 UI 体验。
开箱即用，免运维。
专属 ArgoCD 控制台域名，集成阿里云 RAM 用户/角色 SSO 登录，支持 ArgoCD 多租权限管理。
混合云、多集群分发，ACK One 关联子集群自动加入 ArgoCD，成为应用分发 GitOps 的目标集群。
支持 ArgoCD Applicationset，提升多集群应用分发体验。
更安全地发布多集群应用，支持 GitOps 中的 Secret 管理，和 ServiceAccount 级别权限访问子集群。

混合云、多集群应用的快速部署

实现混合云场景多集群应用快速部署分 3 步：

先通过 ACK One 注册集群 [ 3] 将 IDC 集群注册到云端；
再由 ACK One 舰队 [ 4] 统一管理云上多地域的 ACK 集群和云下 IDC 集群；
再通过 ACK One GitOps 实现云上、云下集群应用的自动化快速部署。

ACK One 的关联子集群会自动加入 ArgoCD，成为应用分发的目标集群，简化了多集群应用分发流程。

目前 ACK One 有些客户，正使用 ACK One 管理混合云云上、云下数十个集群，并使用 GitOps 实现数千应用（ArgoCD Application）的快速部署。并通过 ArgoCD ApplicationSet，提升了多集群应用的管理效率。以下是一个来自 ArgoCD 社区 [ 5] 的 ApplicationSet 的样例 yaml，可以方便地将多个应用部署到多个集群：

yaml 复制代码

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: cluster-git
spec:
  goTemplate: true
  goTemplateOptions: ["missingkey=error"]
  generators:
    # matrix 'parent' generator
    - matrix:
        generators:
          # git generator, 'child' #1
          - git:
              repoURL: https://github.com/argoproj/argo-cd.git
              revision: HEAD
              directories:
                - path: applicationset/examples/matrix/cluster-addons/*
          # cluster generator, 'child' #2
          - clusters:
              selector:
                matchLabels:
                  argocd.argoproj.io/secret-type: cluster
  template:
    metadata:
      name: '{{.path.basename}}-{{.name}}'
    spec:
      project: '{{index .metadata.labels "environment"}}'
      source:
        repoURL: https://github.com/argoproj/argo-cd.git
        targetRevision: HEAD
        path: '{{.path.path}}'
      destination:
        server: '{{.server}}'
        namespace: '{{.path.basename}}'

另外，多集群应用的一致性部署在很多场景也是极有必要的，一个案例是基于 ACK One 构建混合云容灾系统 [ 6] ，需要确保应用在云上 ACK 和云下IDC 集群的 Service 保持一致。使用 GitOps 可以轻松实现多集群应用的一致性部署，且自动化部署可以规避手动部署的出错风险。

多租权限管理

多团队用户共同使用 GitOps 系统时，往往需要多租权限控制。ACK One GitOps 集成了阿里云 RAM 用户和 RAM 角色 SSO 登录，多租权限管理主要包含以下几方面：

ACK One 舰队的权限管理，支持阿里云 RAM 主账号或权限管理员，为 RAM 用户和 RAM 角色授予舰队和子集群的 RBAC 权限（包括 Applicaiton 资源）。
支持阿里云 RAM 主账号或权限管理，在 argocd-rbac-cm 中为 RAM 用户和 RAM 角色授予 ArgoCD RBAC 的权限 [ 7] 。
支持阿里云 RAM 主账号或权限管理，通过 ArgoCD Projects 管理 RAM 用户和 RAM 角色对目标集群、仓库、应用（Application）的 RBAC 权限。

下图是一个多租配置例子：

管理员为 team-one 和 team-two 分别创建 1 个 project
- team-one 的与 Application 1 和 team-one Git Repo 绑定
- team-two 的与 Application 2 和 team-two Git Repo 绑定
team-one 想访问 team-two 的 Application 2 时，会被 ArgoCD 拒绝，因为并没有为 team-one 赋予 Application 2 的权限

下面给出一个管理员为某 RAM 用户/角色分配只读某个应用权限的 ArgoCD Project 的样例，可由 ArgoCD UI 创建得到：

27***02 为 RAM 用户或 RAM 角色 ID
27***02 只能对 demo project 下的 application1 执行 get（无法创建、删除等）

yaml 复制代码

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: demo
  namespace: argocd
spec:
  destinations:
  - name: '*'
    namespace: '*'
    server: '*'
  roles:
  - groups:
    - "27***02"
    name: test
    policies:
    - p, proj:demo:application1, applications, get, demo/*, allow
  sourceRepos:
  - https://github.com/AliyunContainerService/gitops-demo.git

此处是在 argocd-rbac-cmConfigMap 中配置，RAM User/Role 具有 projects 的所有操作权限的例子：

yaml 复制代码

data:
  policy.csv: |
    p, role:project-admin, projects, *, *, allow
    
    g, "27***02", role:project-admin     # 为RAM User/Role "27***02"绑定ArgoCD role:project-admin权限。
  scopes: '[uid]'

GitOps 中 Secret 管理

在多集群 GitOps 中安全、有效地管理如授权 Token、用户名密码、私钥等敏感信息，是非常必要的。ACK One GitOps 提供结合 KMS 的方案来实现 GitOps 中 Secret 管理 [ 8] 。

以下简要介绍基于 ACK Secret Manager 的方案：

在要使用 Secret 的子集群中，先安装 ACK Secret Manager 组件；
在 KMS 凭据管家中添加凭证；
在 Git 仓库中应用下添加 ExternalSecretyaml，并在 Deployment 中引用Secret；如下图左边 yaml 样例所示。
通过 ACK One GitOps 将包含 ExternalSecret 的应用同步到子集群中，已安装的 ACK Secret Manager 组件会根据 ExternalSecret 创建出 Secret，供 Deployment 使用。