KusionStack 在蚂蚁集团的探索实践 (上)

文｜史贵明（花名：莫城)

蚂蚁集团技术专家

蚂蚁集团多云配置管理系统技术负责人

云原生基础设施领域，容器服务、配置管理、IaC、PaC、GitOps 等方向

本文 2369 字阅读 7 分钟

背景
KusionStack

要讲 Kusion 在蚂蚁集团的实践，我们首先来了解下蚂蚁集团在此之前的配置管理状况。

如上图所示，图中展示的是在结合 Kusion 之前的应用基线配置管理系统。这里提到的 “应用基线配置” 非应用动态开关，而是注入应用依赖的软件版本、中间件配置、网络数据库等基础设施配置。

从上图可以看到，应用基线管理系统是标准 BS 架构，对用户提供 Console 和 API，历经 6、7 年发展历史，承担起蚂蚁集团历史上绝大多数应用基线配置需求，功能丰富且拥有极其复杂的配置计算能力。目前已经支撑了 15000+ 应用、近 400 项应用配置、50+ 全局配置。

在这个架构下，最上层用户通过表单或者集成系统 API 来与系统交互，以 RDBMS 为存储介质，将应用的配置以类 Key-Value 形式存储。能力层主要包含通用的角色管理、认证鉴权、版本与配置审计等通用能力，还提供模板化的方式来计算应用配置，如将 Deployment 模板化，最终将用户的基线配置渲染为 Deployment，同时模板与基线配置都存在非常复杂而又灵活的继承能力，举个例子，可以给应用配置 Zone_（逻辑机房）_级别的基线，也可以配置环境级别的基线，或者应用级别的基线，前者可以继承后者，就像子类和父类的集成关系。

除了应用本身的基线配置，同时也管理了全局配置，如全局的 DNS 配置、Load Balance、网路配置等等。这个架构非常经典，并且有效支持了历史上各种配置需求及各种 618、双 11 等场景，这些都是毋庸置疑的。但是随着蚂蚁集团云原生化进程的推进，上面的经典架构也逐渐出现一些瓶颈。不知道大家对于这种架构的配置管理，或者架构有没有遇到这样的问题？我来举几个例子：

● 灵活性： 业务越来越多，应用的基础设施配置也更加的灵活，各种定制化需求越来越多，原有架构主要解决标准应用的场景和通用场景；

● 开放性： 基线系统的核心能力主要代码在 PaaS 同学这边负责，对于多种多样的需求需要内部排期支持，开放性不足，无法复用和沉淀强大的 SRE 团队的经验；

● 透明性： 配置计算黑盒，很多配置的计算逻辑都 hardcoding 在代码中，一个配置的变更最终会影响什么、影响有多大无法确定。比如修改了全局 sidecar 版本，导致线上应用批量异常。

业界对标

带着上面这些问题，我们在业界做了一些对标和学习:

1. 在 Google的《The Site Reliability Workbook》这本书中，Google 同学从自身的实践中总结出一些常见问题，其中非常重要的一点是：在做配置管理过程中，没有意识到，大规模配置管理问题的本质是编程语言问题。配置需求的声明、校验都可以通过语言来解决。

2. 从 Google 自身的实践来讲，K8s 是基于 Google 多年大规模集群管理经验贡献的开源产品，但是其内部主要使用的是 Borg，Borg 团队是在 Borg master 之上研发的，Borg 接入的三件套分别是：

● BCL： 用户通过编写 BCL 代码实现对基础设施需要的配置；

● Borgcfg： 通过 Borgcfg 将配置执行到 Borg 集群；

● Webconsole： 通过 Webconsole 查看发布情况。

经过调研，我们了解到 Google 大量的运维能力、产品、质量生态都是基于上述三件套演进多年。

基于上述的一些总结，我们推演出类 Borg 的思路来解决蚂蚁集团的基础设施配置管理，我们尝试用语言和工具及服务实现蚂蚁集团下一代配置管理架构。

下一代配置管理架构

在这个新的架构下，我们可以看到整体架构不仅仅是一个简单的 BS 架构，配置的用户界面也从浏览器 Form 表单演进为中央开放配置大库。而配置大库所使用的就是 Kusion，Kusion 的用户使用前面的同学已经讲过了，对于配置大库本身的技术细节我不做过多的展开，这里强调的是大库在设计上支持多站点交付的架构。

新配置管理架构主要分为以下几个特点：

● 基于配置代码化理念抽象建设统一的应用配置模型，沉淀可重用模型组件，实现配置代码一次编写多站点可迁移。抽象领域模型：Stack 是配置的最小集合，Project 是一组 Stack 的抽象，不仅囊括 App 的应用基线配置, 也支持其他如 DataBase 配置、负载均衡配置，甚至 Network Policy 等非应用配置。

● 通过策略控制器机制，创建与组织独特的安全性，合规性和治理要求相对应的防护规则。

● 声明式自动化，持续监控运行状态并确保符合 Git 中定义的期望状态。

应用发布案例

接下来结合一个具体产品案例做阐述，在这个案例中以应用迭代发布为例：

1. 用户在业务迭代中，修改业务代码、提交代码、CI 测试、构建镜像，并将构建的镜像推送到远程镜像中心。然后通过配置管理服务层——这里是 auto-image-updater 组件——自动将配置更新到配置大库对应的配置文件中。

2. 触发大库的变更扫描、测试、审核等一些列的质保手段，同时触发一次应用发布流程，应用发布流程是具有风险体系的、可视化的发布流程，包括推进流程要从预发、仿真、灰度逐步推进，最后进入生产环境。

在每个推进阶段，需要从配置大库获取到配置代码并同时使用配置管理服务层获取 KCL 的编译结果，也就是 Spec 模型，然后通过产品化方式将 Spec 与生产环境中真实的 Runtime 进行“Live Diff”以供参与人更好地识别变更内容和变更范围，然后以分组发布等具有风险防控的手段变更到对应环境，如 apply 到 K8s 集群。

3. 我们看下过程中的具体可视化产品，可以看到发布进度、应用配置的 Diff，以及可以看到历史版本的配置。