文｜李大元 （花名：达远）
Kusion 项目担任人
来自蚂蚁集团 PaaS 中心团队，PaaS IaC 根底渠道担任人。
本文 4331 字 阅览11 分钟
PART. 1 后云原生年代
间隔 Kubernetes 第一个 commit 现已过去八年多了，以其为代表的云原生技能早已不再是什么新技能，而是现代化运用的“标配”。现代化运用依靠的根底服务远不止 Kubernetes 一种，略微杂乱点的运用往往会同时运用到 Kubernetes 生态云原生技能、IaaS 云服务、企业界部自建系统等各种异构根底设施，或许还会有多云、混合云的布置需求，咱们现已进入到了 ”后云原生年代”，只针对 Kubernetes 的运维东西早已不能满足咱们的诉求。
更杂乱的是，在企业界部，这些服务一般是由不同团队保护的，一次规模化运维需求多个团队的成员互相配合才能完结，可是 App Dev、Platform Dev、SRE 各个团队之间缺少高效的协作方法。技能自身的杂乱性加上低效的团队协作，使得 “后云原生年代” 的规模化运维难度有了指数级的提高。
PART. 2 规模化运维的问题一向都在
杂乱异构根底设施的规模化运维，这并不是后云原生年代特有的问题，自分布式系统诞生以来，一向都是一个难题，仅仅在后云原生年代，这个问题变得愈加困难。十多年前业界提出了 DevOps 理念，无数企业基于此理念构建了自己的 DevOps 渠道，希望处理此问题，但在实践落地的进程中往往不尽人意，Dev 团队和 Ops 团队之间如何合作？责任如何区分？几十人的渠道团队，如何支撑几万工程师的运维诉求？底层根底设施杂乱多样，才能日新月异，如何快速让一线 Dev 享受到技能盈利？这些问题一向没有得到很好的处理，最近又有人提出了 DevOps 已死，Platform Engineering 才是未来的说法。抛开概念界说，无论是 DevOps 仍是 Platform Engineering，本质上都是企业规模化运维这同一命题下的不同理念，咱们更需求的是一个契合技能发展趋势，能处理当前问题的处理方案。
PART. 3 传统架构不再适用
在传统的运维思路中，处理上述问题的方法一般是构建一个 PaaS 渠道，例如咱们前期的蚂蚁 PaaS 渠道，他是一个 Web 控制台，有 UI 界面，用户（通常是 App Dev 或 SRE）经过 UI 交互能够完结诸如发布、重启、扩缩容等操作。在技能实现上大体能够分为三部分，一个前端系统，供给用户交互的才能，作为系统入口；中间是一个后端系统，对接各个根底设施；底层是各个根底设的 API。这种架构运转了近十年，一向运转的很好，既有用户友爱的交互界面，又能够屏蔽根底设施杂乱性，而且各个团队之间还责任分明，可是到了如今后云原生年代，这种架构不再适用，露出出有两个致命缺点， “费人” 、 “费时” 。
举一个常见的比如，网络团队为其担任的 Loadbalancer（负载均衡器）开发了一种新的负载算法，需求供给给用户运用。
在上述架构下，整个工作流程是这个样子：
1.网络团队开发好才能，供给出 API；
2.PaaS 后端经过编码对接底层 API，进行互联互通，屏蔽杂乱性，供给面向用户的更高等级 API；
3.PaaS 前端依据新功用修正 UI，运用后端 API 把才能透出给最终用户。
这儿存在一个问题，即便一个再小的功用，也需求 PaaS 后端和前端修正代码，整个流程下来最快也要一周才能上线，而且触及的根底设施团队越多，效率越低。这个问题在十年前并不算是一个问题，可是在今日就是一个很大的问题，一个后云原生年代的现代化运用，运用三个云原生技能（Kubernetes + Istio + Prometheus），两个云服务（Loadbalancer + Database），一个内部自建服务，现已是一个很常见的形状了，杂乱运用只会依靠的更多。假如每个根底设施都由 PaaS 团队硬编码对接一遍，PaaS 团队的人再扩展十倍也不够用。
“费人”讲完了，咱们再看看“费时”的问题。上面比如里的一个小功用，需求进行两次跨团队的协作，一次根底设施和 PaaS 后端，另一次是 PaaS 后端与 PaaS 前端。团队协作是一个很难的问题，有时候比技能自身还要难。运用的架构现已很杂乱了，假如要做一次规模化运维，一次运维 100 个运用，这要和多少个团队沟通协作？要花费多少时刻？没有好的协作机制，这就变成了一个不或许完结的使命。
PART. 4 探究与实践
咱们在蚂蚁集团内部进行了近两年的探究，kustomize、helm、argoCD、Terraform 这些常见的东西咱们都实践过，乃至还为一些东西自研了一些辅佐系统，但成果并不尽人意。这些东西要么太局限于 Kubernetes 生态，运维不了其他类型的根底设施，要么就是支撑了异构根底设施，但关于 Kubernetes 生态支撑的不友爱，无法发挥出云原生技能的优势，而且仅仅运维东西的升级关于团队协作效率几乎没有提升，咱们需求一套愈加系统化的方案。
回到问题自身，针对“费人”、“费时”的问题，咱们提出两个思路：
1.能否不让 PaaS 做中转，而是由 App Dev 经过一种高效自助的方法，运用到互联互通的各种根底设施才能？
2.能否构建一个中心化的协作渠道，用技能的手法规范咱们的行为，标准化的进行沟通？
从技能的角度来看，PaaS 渠道需求供给灵敏的东西链和工作流，根底设施一切才能都经过模块化的方法露出出来，App Dev 运用这些渠道的根本才能，自己组合、编列来处理自己的问题，进程中不需求渠道层的参加。而且整个进程中触及的一切团队，都运用一致的语言和接口进行沟通，全程无需人工参加。
PART. 5 咱们的实践
经过在蚂蚁内部 PaaS 渠道近两年的探究与实践，沉淀出一套端到端的完整方案， 取名为 KusionStack，目前现已开源。试图从一致异构根底设施运维与团队协作两个角度处理传统 PaaS “费人”、“费时”的问题。
整个系统主要分为三个部分：
1.Konfig：Git 大库，是多团队协作的中心化渠道，存放着各个团队的运维目的；
2.KCL：蚂蚁自研的装备战略 DSL，一切团队间沟通的东西；
3.Kusion：KusionStack 引擎，担任一切的运维操作。
Platform Dev 经过 KCL 界说好根底才能模型，App Dev 经过 import、mixin 等语言特性在运用装备模型（AppConfig）里复用这些预界说好的才能，快速在 Konfig 里描绘运维目的。AppConfig 是一个精心设计过的模型，只露出 App Dev 需求关怀的属性，屏蔽根底设施的杂乱性。
永远不要低估根底设施的专业性与杂乱性，即便现已成为云原生技能标准的 Kubernetes，对一般用户来说依然有很高的门槛，一个 Deployment 就有几十个字段，再加上自界说的 labels、annotations 就更多了，一般用户根本无法全部了解。或者说一般 AppDev 不该该去了解 Kubernetes，他们需求的仅仅发布，乃至不需求关怀底层是不是 Kubernetes。
AppConfig 经过编译后会生成多个异构根底设施的资源，经过 CI、CLI、GUI 等方法把数据传输给 KusionStack 引擎。引擎是整个系统的中心，担任一切运维操作，是运维目的真实收效到根底设施的当地。他经过一致的方法对接异构根底设施，并对这些资源进行校验、编列、预览、收效、观测、健康检查等一系列操作。
值得一提的是，整个进程对运维 Kubernetes 资源非常友爱。运用过 Kubernetes 的同学都知道，由于其面向终态、自谐和的特色，apply 成功并不代表资源现已能够用，需求等资源谐和成功后才能供给服务，假如谐和失败了，还需求登陆到集群中，经过 get、describe、log 等命令检查详细报错，整个进程非常繁琐。
咱们经过技能的手法对这些操作进行了简化，把谐和进程中的重要信息以用户友爱的方法透露出来。下面的动图是一个简单的示例，当命令下发后，能够明晰的看到一切资源及其相关资源谐和进程，直到资源真实的可用。
整个系统有如下几个特色：
1.以运用为中心
-
运用全方位装备办理，包括计算、网络、存储等一切与运用有关装备；
-
运用全生命周期办理，从第一行装备代码到生产可用。
2.一致运维“后云原生年代”运用的异构根底设施
-
Kubernetes 友爱的工作流，为 Kubernetes 资源供给可观测性、健康检查等高阶才能，释放云原生技能盈利；
-
复用 Terraform 生态，一致的工作流运维 Kubernetes、Terraform 多运转时资源。
3.规模化协同渠道
-
灵敏的工作流，用户可运用渠道的根本才能，自己组合、编列来处理自己的问题；
-
App Dev 和 Platform Dev 关注点别离，底层才能迭代无需渠道介入，直接供 App Dev 运用；
-
纯客户端方案，危险“左移”，尽早发现问题。
PART. 6 一切才刚刚开始
这套系统经过近两年的探究，已广泛运用在蚂蚁多云运用交给运维，计算及数据根底设施交给，建站运维，数据库运维等多个业务领域，目前 400+ 研发者直接参加了 Konfig 大库代码奉献，累计近 800K Commits，其间大部分为机器自动化代码修正，日均 1K pipeline 使命履行和近 10K KCL 编译履行，全量编译后可发生 3M+ 行的 YAML 文本。
不过，这一切才刚刚开始，后云原生年代也才刚刚到来，咱们把这套系统开源的目的也是希望约请业界各方的力气，一起构建一个契合技能发展趋势，能真实处理当下企业规模化运维这个难题的处理方案。蚂蚁 PaaS 团队还有很多经过内部规模化验证的技能沉淀，后续也会开源出来，只要咱们远远不够，真诚地约请咱们一起来玩。
| 相关链接 |
Kusion：
github.com/KusionStack…
KCL：
github.com/KusionStack…
Konfig：
github.com/KusionStack…
官网：kusionstack.io
PPT：KusionStack：“后云原生年代” 运用模化运维处理方案
kusionstack.io/blog/2022-k…
了解更多…
KusionStack Star 一下✨：
github.com/KusionStack…
本周推荐阅览
从规模化渠道工程实践，咱们学到了什么？
KusionStack 开源有感｜历时两年，打破“隔行如隔山”窘境
Go 代码城市上云——KusionStack 实践
KusionStack 开源｜Kusion 模型库和东西链的探究实践
