文|李大元 （花名：达远）
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：
https://github.com/KusionStack/kusion
KCL：
https://github.com/KusionStack/KCLVM
Konfig：
https://github.com/KusionStack/konfig
官网：https://kusionstack.io
PPT：KusionStack：“后云原生时代”利用模化运维解决方案
https://kusionstack.io/blog/2022-kusionstack-application-scale-operation-solution-in-the-post-cloudnative-era/
理解更多 …
KusionStack Star 一下✨：
https://github.com/KusionStack/kusion
本周举荐浏览
从规模化平台工程实际，咱们学到了什么？
KusionStack 开源有感|历时两年，突破“隔行如隔山”窘境
Go 代码城市上云——KusionStack 实际
KusionStack 开源|Kusion 模型库和工具链的摸索实际