共计 5942 个字符，预计需要花费 15 分钟才能阅读完成。
文|杨英明（花名：向野)
KusionStack 外围贡献者、蚂蚁团体高级研发工程师
在基础设施技术畛域深耕，专一 IaC/XaC、GitOps 等方向
本文 4912 字 浏览 12 分钟
前言
KusionStack 最早是为了解决蚂蚁外部简单的运维场景而诞生的解决方案。思路是通过自研的 DSL （KCL） 积淀运维模型 （Kusion Model），将基础设施局部能力的应用形式从白屏转为代码化，同时联合 DevOps 工具链 （Kusion CLI） 实现配置疾速验证和失效，以此晋升基础设施的开放性和运维效率。
其中，Kusion Model 就是题中所说的 Kusion 模型库，而 Kusion CLI 就是 Kusion 工具链了。具体概念如下：
Kusion 模型库
Kusion 模型库是基于 KCL 形象的配置模型。它的特点包含了开箱即用、用户敌对、以及业务形象。其实模型库最后奢侈的出发点就是改善 YAML 用户的编写效率和体验，因为目前其实有不少配置是基于 YAML 形容的，比方 Kubernetes 在成为容器编排的事实标准之后，基于 K8s 的申明式配置就越来越多了起来。
然而因为 K8s 自身的复杂性导致 YAML 配置越来越简短、简单。咱们心愿通过将简单的配置形容通过 KCL 这门配置语言形象封装到对立的模型中，从而简化用户侧配置代码的编写。
Kusion 工具链
Kusion 工具链是基于 KCL 的 DevOps 工具汇合，它是用来辅助用户在 Kusion 生态里更好的生成、驱动他们的 KCL 配置。
简略来说，Kusion 模型库是用 KCL 语言积淀下来的可复用组件，工具链是 Kusion 模型的驱动器。
本文次要介绍 KusionStack 中 Kusion 模型库和工具链在蚂蚁外部的实际摸索和总结，重点论述了如何利用 KusionStack 晋升简单基础设施的开放性和运维效率，心愿对同样面临此类窘境的搭档有所启发。
PART. 1– 为什么要做 Kusion 模型库和工具链？
咱们能够先来看一张“景象 – 问题”图：
在这张图中，咱们列出了一些在外部大规模场景下的实际过程中会遇到的问题。
举个利用部署的例子，利用 A 有 10+ 组件，外部对于这种非标利用没有提供很好的反对，每次部署须要经验繁多的步骤，比方元数据筹备、申请证书、VIP、域名、手动部署 CRD、RBAC、Webhook、监控配置等。这个过程没有自动化，交付部署简单，定制水平高，其中任何一个步骤呈现问题，都须要找对应的研发同学沟通，利用部署的人工成本很高。
总体来说，过后蚂蚁外部在大规模场景下利用现有基础设施进行运维的窘境，次要就是来源于以上列出的这些景象，所以去解决这些景象背地的问题，成了亟待咱们去做的事件。
PART. 2– 窘境中的应答思路
通过重复的探讨和统一认同，咱们最终摸索出一套解决方案，即通过 Kusion 模型库和工具链，从以下几个方面解决上述简单基础设施运维窘境的问题。
可读性
面向业务 & 屏蔽底层实现
咱们基于 KCL 形象了 Kusion 模型库，其中蕴含一些开箱即用的模型，这些模型针对业务进行了形象和提炼，面向用户的这层模型界面裸露的都是用户关怀的属性，一些实现的细节被屏蔽掉了，所以它是面向业务的，也更容易被用户所承受和上手应用。
合乎工程直觉
Kusion 模型库作为用 KCL 编写的模型汇合，更加合乎工程直觉。因为 KCL 既然作为一门语言，它反对定义变量，编写条件判断，比方你能够通过 if-else 编写一些差异化的配置。
解决的问题
本节介绍的可读性的晋升次要分为两个方面。一方面是 KCL 这门 KusionStack 自研的配置语言自身足够强的表达力，使得通过 KCL 形容配置和形象模型更加丝滑；另一方面，应用 KCL 定义的 Kusion Model 封装了简单的配置转换逻辑，屏蔽业务细节，形象出清晰易懂的用户界面。这两方面的带来的可读性的劣势能够比拟好的解决应用传统配置语言保护艰难的问题。
工程性
前后端模型解耦
咱们对 Kusion 模型库依据性能，辨别了前端模型和后端模型。为什么要辨别前端模型和后端模型？间接目标是将「用户界面」和「模型实现」进行拆散：
前端模型
前端模型即「用户界面」。蕴含平台侧裸露给用户的所有可配置属性，其中省略了一些反复的、可推导的配置，形象出必要属性裸露给用户。
用户只须要像实例化一个类 （Class） 一样，传入必要参数形成一份利用的「配置清单」，再通过工具链编译即可失去残缺的面向基础设施的配置形容，比如说 K8s 的 YAML；
后端模型
后端模型是「模型实现」。后端模型和前端模型不同，是对用户不感知，方才提到前端模型能够形成用户的配置清单，那么怎么让用户的配置清单失效呢？
咱们将属性的渲染逻辑全副下沉到后端模型中，后端模型中可借助 KCL 编写校验、逻辑判断、代码片段复用等逻辑，进步配置代码复用性和健壮性。
Mixin 复用
Mixin 是 KCL 提供的一种复用代码片段的形式。举个具体的例子，比如说有个模型的属性叫做超卖，开启超卖开关能够将 Pod 调度到能够超卖的机器当中，利用个别在公布线下环境的时候会开启超卖，以充分利用集群的资源。这段超卖配置失效的逻辑可能会被不同的利用运维模型应用，那么就能够借助 Mixin 机制实现一个 OverQuotaMixin，OverQuotaMixin 能够被不同后端模型援用，解决复用性的问题，无需反复造轮子。
AppConfiguration 积淀
咱们针对不同利用运维场景或者部署场景形象为不同的利用运维模型，这些利用运维模型咱们叫做 AppConfiguration。
它们裸露的属性是不一样的，比方适应于规范基础设施的规范利用模型，适应于网络应用的网络应用模型。这些不同的利用运维模型裸露给用户可配置的属性是不同的，这些模型积淀下来能够形容越来越多场景的利用运维配置，积淀为在推动配置代码化过程中重要的资产。
解决的问题
本节介绍的是团队在建设蚂蚁的 Kusion 模型库过程中造成的一套最佳实际，它是推动建设 Kusion 模型库和工具链的一站式和开放性的根底。
一站式
全生命周期配置形容 & Single Source of Truth
咱们在欠缺可读性和工程性的过程中实现了 全生命周期配置形容。咱们将利用的部署配置、网络配置、监控配置等等和利用生命周期相干的配置尽可能的放到了一个模型中。
这样做的益处是，将散落在各个系统的配置片段收集到了一起，用户能够在一个对立界面中保护他的利用配置，同时对于第三方零碎，也不须要对接不同零碎，他只须要运维一份对立的配置即可。
「全生命周期配置形容」其实在做一件事件，就是业界常常提到的 Single Source of Truth，也就是所谓的“惟一实在起源”。这是实现 IaC 的重要前提之一。
从下图能够看到，Kusion 模型库中的前后端模型将不同维度的运维能力通过 KCL 模块化，并灵便组织在各种 AppConfiguration 模型中。同时基于 AppConfiguration 实例化出的配置清单作为业务配置落到配置大库中进行对立运维，最终通过 Kusion 工具链和 PaaS 平台进行配置的疾速验证 / 失效。
CICD
在外部一些实际中，咱们搭建了针对 IaC 配置的流水线。能够参考上面这张图，流水线会对每一次 KCL 配置变更进行依赖剖析、单元测试、集成测试、配置代码上传等等步骤，以保障每次用户配置变更的品质和稳定性。
解决的问题
借助一站式个性，像咱们之前提到的，像配置难以被残缺定义、散落在各处，以及利用 A 部署艰难的问题就能够失去比拟好的解决。
开放性
MonoRepo
针对之前提到的配置散落在各处的问题，KusionStack 举荐应用配置大库 （MonoRepo） 进行集中式的配置管理。
在外部的落地实际中，配置大库不仅寄存形象模型自身的 KCL 定义，还寄存各种类型的配置清单。也就是说，次要蕴含根底配置和业务配置两局部，业务配置比方利用的运维配置、策略配置等。配置大库举荐托管在各类版本控制系统当中，以不便做配置的回滚和漂移查看。
配置大库其实是一种组织配置的形式，能够参考上面这张图，在外部的实际中，是通过架构域、我的项目、环境等维度组织配置文件。
其中，利用的业务配置局部能够援用任意根底配置，根底配置之间也能够互相援用。
比如说用户的利用配置是依照环境维度去散发的，每个环境的配置不一样。这其实是一个比拟广泛的划分，那基于配置大库和 KCL 自身的个性，就能够做到环境通用配置和环境特有配置的隔离。同时在编译某个具体的环境配置时，借助 KCL 的语法糖，可能做到主动合并配置，并也能反对细粒度的笼罩规定。
工程标准
下面提到的工程目录构造的划分其实能够作为一种工程标准的约定，通过工具标准起来。
同时，因为配置大库自身是通过版本控制系统托管起来的，所以能够人造的做到配置代码的变更可评审。同时联合 CICD 零碎，将上述工程目录构造查看以及 KCL Linter、Test 工具集成到流水线当中，就能够搭建起一套标准的工作流程。
协同共建
基于这些工作，咱们能够 involve 更多的人进来共建配置大库，包含利用运维的批改、模型库自身的形容。这些都是对所有人可见，并且能够参加共建的。
上面列了两张图，是不同的开发者在配置大库中评审、交换的截图：
解决的问题
通过实现了刚刚提到的这几个点，就能够肯定水平上将基础设施的能力通过模型层积淀到配置大库中。
带来的益处能够举个例子，之前想在网络工单上增加一个参数，都要走一个残缺的研发迭代，然而当初网络相干的配置和渲染逻辑下沉到模型库后，需求方只须要在配置大库中提交一个后端模型的变更评审，而且这个变更评审仅需通过相干 Owner Review 和所有的流水线查看，就能够实现上线了。
以上提到的几个点能够解决之前提到的基础设施关闭、需求方无奈做到自服务的问题，随之而来的，新个性上线工夫也会大大缩短。
须要留神的是，配置代码化能在肯定水平上开释基础设施的开放性，但它不是银弹，不能解决所有问题。
PART. 3–Kusion 工具链和引擎架构介绍
Kusion 工具链
统一的工作流
在 Kusion 工具链中，咱们定义了统一的工作流：init -> write -> preview -> apply，来帮忙用户治理一份 KCL 代码的生命周期。
比方最开始 KCL 配置是这样来的：
– 用户必定能够本人去编写，不过为了更好的解决这个问题，甚至帮忙一些第三方的零碎更快的初始化出 KCL 代码，咱们提供了脚手架模板仓库和 Kusion Converter。
– 脚手架仓库中存储了各种场景中的 KCL 模板，它和 Kusion 工程自身的代码是隔离开的，任何人都能够在这个仓库奉献代码。
Kusion Converter 是为了解决存量配置疾速接入 KCL 而诞生的。用户之前可能曾经用其它配置语言编写了一些配置代码，那么借助 Kusion Converter 工具集能够一键转换成 KCL 的代码。
对立视图
Kusion 工具链也能够比拟不便的集成到第三方零碎中，做到零碎的输入和本地的 Console UI 视图统一。比方开源配置大库中的流水线就集成了 Kusion 工具链，能够在 apply 那一步的流水线日志输入中看到和本地 Console 一样的输入界面。
生态集成
目前咱们在外部集成了 Kusion 服务化产品、代码服务以及外部的一些加解密服务。对外的生态集成咱们也正在建设，目前咱们集成了 Github Action、ArgoCD，将来也期待能与更多的平台和开源产品进行联合，帮忙大家更好的解决问题。
Kusion 引擎
Kusion 引擎介于 KCL 与底层基础设施之间，用于解释 KCL 的编译后果，并对底层各种异构根底设置进行操作。
在 Kusion 引擎中，咱们充沛拥抱了 Terraform 的生态。通过无缝集成 Terraform 生态中的 Provider，能够将配置下发到不同的 Runtime 中，屏蔽基础设施复杂性。
同时 Kusion 引擎也提供了一些精细化的 Resource Lifecycle 治理，比方资源依赖解析等等。
PART. 4– 阶段性成绩
首先是咱们在外部推广 KusionStack 之后的一些阶段性成绩 （截至 2022.7.15）：
– 配置大库中针对不同的利用运维场景总共积淀了 10 多个 AppConfiguration 模型定义，给不同的保护团队去形容他们的利用模型；
– 配置大库每天有 100+ 配置变更评审；
– 有 300+ 贡献者，波及 20 多个 BU，这外面蕴含 SRE、利用 Owner、大库模型研发者等等；
– 有 1000 多个 Project，每个利用都是一个 Project，然而 Project 不仅蕴含利用，还蕴含其它类型的配置，比方网络策略，建站配置等；
– 配置大库有 10000 多个 MR，50000 多个 Commit，450000 行 KCL 代码 （外面有相当一部分是机器提交和保护的）。
而后是一些业务效力晋升的数据展现：
– 单利用 SLO 监控配置失效工夫从 1 天缩短至 0.5 小时；
– 利用运维需要上线工夫从 25 天 缩短至 5 天；
– 利用 A 部署工夫从 1 个月缩短至 0.5 小时；
– 网络相干工单数量由原先的 7 种缩短至 1 种，实现：1 种工单，1 次审批。
PART. 5– 总结与瞻望
通过 KusionStack 在蚂蚁外部的推广，咱们曾经有了一些实践经验，尽管不肯定实用所有公司，但对同样面临此类窘境的搭档应该能有所帮忙。
KusionStack 一方面要一直解决蚂蚁外部的一些运维问题；另一方面，咱们也心愿能开阔视野，借助开源这片瘠田，拓展出更多场景并继续打磨整个技术栈。
KusionStack 目前处于非常晚期的开源阶段，还有许多工作是亟待要做的。鉴于咱们本身人力无限，只靠咱们是很难建设出让所有人都称心的技术计划的。上图是 Kusion 工具链和模型库相干的路线布局以及一些挑战，供大家参考和探讨，欢送提 issue 和拍砖，谢谢大家！
相干链接
Kusion 工具链和引擎： http://github.com/KusionStack/kusion
Kusion 模型库： http://github.com/KusionStack/konfig
Roadmap： http://KusionStack.io/docs/governance/intro/roadmap
理解更多…
KusionStack Star 一下✨： https://github.com/KusionStack/Kusion
KusionStack 的开源，心愿能对大家有所帮忙，也心愿能跟更多敌人独特欠缺 KusionStack。欢送对云原生、运维自动化、编程语言、编译器感兴趣的同学一起参加社区共建，在新的技术畛域降级方面进行摸索和冲破，实现更多新的想法。
本周举荐浏览
KusionStack 开源有感|历时两年，突破“隔行如隔山”窘境
KCL：申明式的云原生配置策略语言
精彩回顾|KusionStack 开源啦～
Go 原生插件应用问题全解析
欢送扫码关注：
