共计 3183 个字符，预计需要花费 8 分钟才能阅读完成。
文|史贵明（花名：莫城 )
蚂蚁团体技术专家
蚂蚁团体多云配置管理系统技术负责人
云原生基础设施畛域，容器服务、配置管理、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，以及能够看到历史版本的配置。
问题与瞻望
回顾下咱们开始提到的几个问题：
1. 灵活性： 即对各种灵便定制化需要的反对;
2. 开放性： 通过 KCL 语言及凋谢配置大库，用户的基础设施配置通过新的用户界面即可自主实现，不须要期待配置管理平台开发人员进行开发；
3. 透明性： 变更过程能够通过产品化的“Live Diff”来辨认变更危险；
咱们通过上述的一些摸索，肯定水平上解决了蚂蚁团体在推动云原生过程中的问题，过程中也遇到了方方面面的艰难，比方如何从老架构切换到新架构？架构代际演进时新老零碎并存问题是必须要解决的，能够通过如双写等形式解决。 在新架构下更值得探讨的有如下问题，全局配置如何治理以及如何更好的扩大配置的维度。
站点的全局配置，在老的基线配置的全局配置不仅仅是简略的 Key-Value，在应用上是非常复杂的，比方 DNSConfig 配置，依照租户、环境、Zone 等做了不同的优先级编排，对于这些的形容比较复杂，应用 KCL 形容如此简单的配置很艰难。
针对于配置的继承和扩大，以 APP 基线配置为例，目前更多的是反对利用和应用环境级别的配置，针对 Zone 等细粒度的配置须要在 KCL 代码中通过写 if else 来实现，这对于其余粒度的扩大及通过 API 自动化都带来新的难题。
对于这些问题外部有一些计划，冀望在后续的开放性探讨中与大家继续交换。
相干链接
Kusion 工具链和引擎：
http://github.com/KusionStack…
Kusion 模型库：
http://github.com/KusionStack…
Roadmap：
http://KusionStack.io/docs/go…
_
理解更多 …
KusionStack Star 一下✨：
https://github.com/KusionStac…
本周举荐浏览
KCL：申明式的云原生配置策略语言
KusionStack 开源|Kusion 模型库和工具链的摸索实际
精彩回顾|KusionStack 开源啦～
KusionStack 开源有感|历时两年，突破“隔行如隔山”窘境
欢送扫码关注咱们的公众号