KusionStack 开源|Kusion 模型库和工具链的探索实践

文|杨英明(诨名:向野)

KusionStack 中心贡献者、蚂蚁集团高档研发工程师

KusionStack 开源|Kusion 模型库和工具链的探索实践

在根底设施技能领域深耕,专心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 装备。

KusionStack 开源|Kusion 模型库和工具链的探索实践

简单来说,Kusion 模型库是用 KCL 言语沉积下来的可复用组件,东西链是 Kusion 模型的驱动器。

本文首要介绍 KusionStack 中 Kusion 模型库和东西链在蚂蚁内部的实践探究和总结,要点论述了如何运用 KusionStack 进步杂乱根底设施的开放性和运维功率,期望对相同面对此类窘境的同伴有所启示。

PART. 1–为什么要做 Kusion 模型库和东西链?

咱们能够先来看一张“现象–问题”图:

KusionStack 开源|Kusion 模型库和工具链的探索实践

在这张图中,咱们列出了一些在内部大规模场景下的实践过程中会遇到的问题。

举个运用布置的比方,运用 A 有 10+ 组件,内部对于这种非标运用没有供给很好的支撑,每次布置需求阅历繁多的步骤,比方元数据预备、请求证书、VIP、域名、手动布置 CRD、RBAC、Webhook、监控装备等。这个过程没有自动化,交付布置杂乱,定制程度高,其间任何一个步骤出现问题,都需求找对应的研发同学沟通,运用布置的人工成本很高。

总体来说,其时蚂蚁内部在大规模场景下运用现有根底设施进行运维的窘境,首要便是来历于以上列出的这些现象,所以去处理这些现象背面的问题,成了亟待咱们去做的作业。

PART. 2–窘境中的应对思路

经过重复的探讨和一起认同,咱们终究摸索出一套处理方案,即经过 Kusion 模型库和东西链,从以下几个方面处理上述杂乱根底设施运维窘境的问题。

KusionStack 开源|Kusion 模型库和工具链的探索实践

可读性

面向事务 & 屏蔽底层完结

咱们根据 KCL 笼统了 Kusion 模型库,其间包括一些开箱即用的模型,这些模型针对事务进行了笼统和提炼,面向用户的这层模型界面暴露的都是用户关怀的特点,一些完结的细节被屏蔽掉了,所以它是面向事务的,也更容易被用户所接受和上手运用。

KusionStack 开源|Kusion 模型库和工具链的探索实践

契合工程直觉

Kusion 模型库作为用 KCL 编写的模型调集,愈加契合工程直觉。由于 KCL 既然作为一门言语,它支撑界说变量,编写条件判别,比方你能够经过 if-else 编写一些差异化的装备。

处理的问题

本节介绍的可读性的进步首要分为两个方面。一方面是 KCL 这门 KusionStack 自研的装备言语本身满足强的表达力,使得经过 KCL 描绘装备和笼统模型愈加丝滑;另一方面,运用 KCL 界说的 Kusion Model 封装了杂乱的装备转化逻辑,屏蔽事务细节,笼统出明晰易懂的用户界面。这两方面的带来的可读性的优势能够比较好的处理运用传统装备言语保护困难的问题。

工程性

前后端模型解耦

咱们对 Kusion 模型库依据功用,区别了前端模型和后端模型。为什么要区别前端模型和后端模型?直接意图是将「用户界面」和「模型完结」进行别离:

前端模型

前端模型即「用户界面」。包括渠道侧暴露给用户的一切可装备特点,其间省略了一些重复的、可推导的装备,笼统出必要特点暴露给用户。

用户只需求像实例化一个类 (Class) 一样,传入必要参数构成一份运用的「装备清单」,再经过东西链编译即可得到完好的面向根底设施的装备描绘,比方说 K8s 的 YAML;

后端模型

后端模型是「模型完结」。后端模型和前端模型不同,是对用户不感知,刚才说到前端模型能够构成用户的装备清单,那么怎么让用户的装备清单收效呢?

咱们将特点的渲染逻辑全部下沉到后端模型中,后端模型中可凭借 KCL 编写校验、逻辑判别、代码片段复用等逻辑,进步装备代码复用性和健壮性。

Mixin 复用

Mixin 是 KCL 供给的一种复用代码片段的方式。举个详细的比方,比方说有个模型的特点叫做超卖,敞开超卖开关能够将 Pod 调度到能够超卖的机器傍边,运用一般在发布线下环境的时分会敞开超卖,以充分运用集群的资源。这段超卖装备收效的逻辑或许会被不同的运用运维模型运用,那么就能够凭借 Mixin 机制完结一个 OverQuotaMixin,OverQuotaMixin 能够被不同后端模型引证,处理复用性的问题,无需重复造轮子。

KusionStack 开源|Kusion 模型库和工具链的探索实践

AppConfiguration 沉积

咱们针对不同运用运维场景或者布置场景笼统为不同的运用运维模型,这些运用运维模型咱们叫做 AppConfiguration。

它们暴露的特点是不一样的,比方适应于标准根底设施的标准运用模型,适应于网络运用的网络运用模型。这些不同的运用运维模型暴露给用户可装备的特点是不同的,这些模型沉积下来能够描绘越来越多场景的运用运维装备,沉积为在推动装备代码化过程中重要的财物。

处理的问题

本节介绍的是团队在建造蚂蚁的 Kusion 模型库过程中构成的一套最佳实践,它是推动建造 Kusion 模型库和东西链的一站式和开放性的根底。

一站式

全生命周期装备描绘 & Single Source of Truth

咱们在完善可读性和工程性的过程中完结了全生命周期装备描绘。咱们将运用的布置装备、网络装备、监控装备等等和运用生命周期相关的装备尽或许的放到了一个模型中。

这样做的优点是,将散落在各个体系的装备片段搜集到了一起,用户能够在一个一起界面中保护他的运用装备,一起对于第三方体系,也不需求对接不同体系,他只需求运维一份一起的装备即可。

「全生命周期装备描绘」其实在做一件作业,便是业界经常说到的Single Source of Truth,也便是所谓的“唯一真实来历”。这是完结 IaC 的重要前提之一。

从下图能够看到,Kusion 模型库中的前后端模型将不同维度的运维才能经过 KCL 模块化,并灵活安排在各种 AppConfiguration 模型中。一起根据 AppConfiguration 实例化出的装备清单作为事务装备落到装备大库中进行一起运维,终究经过 Kusion 东西链和 PaaS 渠道进行装备的快速验证/收效。

KusionStack 开源|Kusion 模型库和工具链的探索实践

CICD

在内部一些实践中,咱们搭建了针对 IaC 装备的流水线。能够参阅下面这张图,流水线会对每一次 KCL 装备改变进行依靠分析、单元测验、集成测验、装备代码上传等等步骤,以确保每次用户装备改变的质量和稳定性。

KusionStack 开源|Kusion 模型库和工具链的探索实践

处理的问题

凭借一站式特性,像咱们之前说到的,像装备难以被完好界说、散落在各处,以及运用 A 布置困难的问题就能够得到比较好的处理。

开放性

MonoRepo

针对之前说到的装备散落在各处的问题,KusionStack 引荐运用装备大库 (MonoRepo) 进行集中式的装备办理。

在内部的落地实践中,装备大库不只存放笼统模型本身的 KCL 界说,还存放各种类型的装备清单。也便是说,首要包括根底装备和事务装备两部分,事务装备比方运用的运维装备、战略装备等。装备大库引荐保管在各类版别控制体系傍边,以便利做装备的回滚和漂移查看。

装备大库其实是一种安排装备的方式,能够参阅下面这张图,在内部的实践中,是经过架构域、项目、环境等维度安排装备文件。

KusionStack 开源|Kusion 模型库和工具链的探索实践

其间,运用的事务装备部分能够引证恣意根底装备,根底装备之间也能够彼此引证。

比方说用户的运用装备是按照环境维度去分发的,每个环境的装备不一样。这其实是一个比较普遍的区分,那根据装备大库和 KCL 本身的特性,就能够做到环境通用装备和环境特有装备的隔离。一起在编译某个详细的环境装备时,凭借 KCL 的语法糖,能够做到自动兼并装备,并也能支撑细粒度的掩盖规矩。

工程标准

上面说到的工程目录结构的区分其实能够作为一种工程标准的约定,经过东西标准起来。

一起,由于装备大库本身是经过版别控制体系保管起来的,所以能够天然的做到装备代码的改变可评定。一起结合 CICD 体系,将上述工程目录结构查看以及 KCL Linter、Test 东西集成到流水线傍边,就能够搭建起一套标准的作业流程。

协同共建

根据这些作业,咱们能够 involve 更多的人进来共建装备大库,包括运用运维的修正、模型库本身的描绘。这些都是对一切人可见,并且能够参加共建的。

下面列了两张图,是不同的开发者在装备大库中评定、沟通的截图:

KusionStack 开源|Kusion 模型库和工具链的探索实践
KusionStack 开源|Kusion 模型库和工具链的探索实践

处理的问题

经过完结了刚刚说到的这几个点,就能够必定程度大将根底设施的才能经过模型层沉积到装备大库中。

带来的优点能够举个比方,之前想在网络工单上增加一个参数,都要走一个完好的研发迭代,可是现在网络相关的装备和渲染逻辑下沉到模型库后,需求方只需求在装备大库中提交一个后端模型的改变评定,而且这个改变评定仅需经过相关 Owner Review 和一切的流水线查看,就能够完结上线了。

以上说到的几个点能够处理之前说到的根底设施关闭、需求方无法做到自服务的问题,随之而来的,新特性上线时刻也会大大缩短。

需求留意的是,装备代码化能在必定程度上释放根底设施的开放性,但它不是银弹,不能处理一切问题。

PART. 3–Kusion 东西链和引擎架构介绍

KusionStack 开源|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 代码 (里面有适当一部分是机器提交和保护的)

KusionStack 开源|Kusion 模型库和工具链的探索实践

然后是一些事务效能进步的数据展现:

单运用 SLO 监控装备收效时刻从 1 天缩短至 0.5 小时;

运用运维需求上线时刻从 25 天 缩短至 5 天;

运用 A 布置时刻从 1 个月缩短至 0.5 小时;

网络相关工单数量由原先的 7 种缩短至 1 种,完结:1 种工单,1 次批阅。

KusionStack 开源|Kusion 模型库和工具链的探索实践

PART. 5–总结与展望

经过 KusionStack 在蚂蚁内部的推广,咱们已经有了一些实践经验,虽然不必定适用一切公司,但对相同面对此类窘境的同伴应该能有所协助。

KusionStack 一方面要不断处理蚂蚁内部的一些运维问题;另一方面,咱们也期望能开阔视野,凭借开源这片沃土,拓展出更多场景并持续打磨整个技能栈。

KusionStack 开源|Kusion 模型库和工具链的探索实践

KusionStack 现在处于十分早期的开源阶段,还有许多作业是亟待要做的。鉴于咱们本身人力有限,只靠咱们是很难建造出让一切人都满足的技能方案的。上图是 Kusion 东西链和模型库相关的道路规划以及一些应战,供咱们参阅和探讨,欢迎提 issue 和拍砖,谢谢咱们!

相关链接

Kusion 东西链和引擎: github.com/KusionStack…

Kusion 模型库: github.com/KusionStack…

Roadmap: KusionStack.io/docs/govern…

了解更多…

KusionStack Star 一下✨: github.com/KusionStack…

KusionStack 的开源,期望能对咱们有所协助,也期望能跟更多朋友一起完善KusionStack。欢迎对云原生、运维自动化、编程言语、编译器感兴趣的同学一起参加社区共建,在新的技能领域升级方面进行探究和突破,完结更多新的想法。

本周引荐阅览

KusionStack 开源有感|历时两年,打破“隔行如隔山”窘境

KusionStack 开源|Kusion 模型库和工具链的探索实践

KCL:声明式的云原生装备战略言语

KusionStack 开源|Kusion 模型库和工具链的探索实践

精彩回顾|KusionStack 开源啦~

KusionStack 开源|Kusion 模型库和工具链的探索实践

Go 原生插件运用问题全解析

KusionStack 开源|Kusion 模型库和工具链的探索实践