近日，GitHub 上的 Go 语言趋势榜呈现了一个新的我的项目 —— KubeVela。
据我的项目官网文档，KubeVela 是“一个简略易用且高度可扩大的利用治理平台与外围引擎，KubeVela 是基于 Kubernetes（K8s）与 Open Application Model（OAM）技术构建的”。
在云原生浪潮席卷寰球的明天，置信大家对 K8s 必定不会生疏，那么 KubeVela 和 OAM 又是什么技术呢？事实上，K8s 的小名尽管曾经路人皆知，但在很多社区网友的反馈中，咱们仿佛看到围绕 K8s 的云原生生态目前只是几家头部大厂的专属。很多一线业务同学都反馈 K8s 太简单了，太难学了，如果没有大厂的投入和技术储备来基于 K8s 构建出场景化的下层平台进去，要落地云原生技术，感觉基本搞不定。
而去年十月，阿里云与微软单干独特开源了 OAM 我的项目，旨在为云原生生态提供一个 以利用为核心 的、对立的下层形象技术，从而大大降低业务研发同学上手云原生技术的门槛，真正享受到云原生带来的极致麻利与研发效力晋升。而刚刚公布的 KubeVela 我的项目，正是 OAM 模型在 Kubernetes 上的残缺实现。
现在间隔 OAM 我的项目开源正好过来一年，那么 OAM 我的项目现在有何停顿？本次公布的 KubeVela 我的项目又将为国内的 K8s 生态带来哪些影响？带着这些问题，咱们与 KubeVela 我的项目背地的设计者之一、CNCF 利用交付畛域小组 co-chair、官网大使，来自阿里云的工程师张磊，具体的聊了聊。
采访嘉宾介绍
以下为采访原文：
- 请给还不理解 OAM 的敌人介绍一下 OAM 和 KubeVela 我的项目吧。
< 张磊 >：Kubernetes 和云原生技术的各种外围概念，间隔咱们业务用户其实是很边远的。理论的落地过程也通知咱们，仅仅有基础设施层形象，离云原生“丝般顺滑”的云端利用治理与交付体验，还是存在着微小的鸿沟。在 Kubernetes 与用户之间，还存在着一层名叫“应用层”形象亟待填补。所以，很多业务用户对“云原生”、Kubernetes 的价值其实广泛不足体感，这个状况不仅在阿里外面存在，在整个社区里也是个让人头疼的问题。只有咱们的业务研发接触到的是“代码”、“利用”而不是“Pod”、“StatefulSet”，那么“让研发专一于写代码”这个美妙、奢侈的云原生欲望，才可能真正实现。
而 Open Application Model（OAM）凋谢利用模型，以及它的 Kubernetes 实现 KubeVela 我的项目，正是阿里云联结微软等云原生社区中坚力量，独特推出的“以解决用户侧诉求”为外围的云原生应用层我的项目。其中，OAM 的设计思维是为包含 Kubernetes 在内的任何云端基础设施提供一个对立、面向最终用户的利用定义模型；而 KubeVela，则是这个对立模型在 Kubernetes 上的残缺实现。对于业务研发人员来讲，KubeVela 能够被认为是云原生社区的 Heroku。而对于平台团队来讲，KubeVela 因为具备极高的可扩展性，则能够被认为是一个“以利用为核心”的、高度可扩大的 Kubernetes 发行版。而 OAM 我的项目，这是 KubeVela 背地的外围 API 范式和插件化能力治理模型。
- 间隔 OAM 公布整整一年，有哪些新增玩家参加了我的项目的建设工作，提交了哪些奉献？是否曾经生产可用，或者还存在哪些须要欠缺的中央？
< 张磊 >：在现今的 OAM 社区中，有大量的奉献来自 Oracle、MasterCard、Upbound.io、腾讯、字节跳动、第四范式、和满帮团体等十余家技术公司与团队，他们不仅是 OAM 社区重要的技术力量，很多还是 KubeVela 我的项目的晚期发起者。事实上，当初的 OAM 模型和它的 Kubernetes 实现 KubeVela 我的项目，自身就是阿里云原生利用基础设施的外围组件，撑持着包含阿里云 EDAS 服务、阿里团体外围 PaaS、阿里云边缘计算平台、达摩院 AI PaaS 在内的多个互联网级平台的内核的运行与扩大。而在接下来的设计中，OAM 社区会以 KubeVela 为外围，在曾经生产可用的平台层模型的根底上，持续建设面向开发者的用户侧模型，并且以此为根底通过 Dapr sidecar 和 Istio 来欠缺应用层中间件与流量治理能力，实现“让云原生利用交付轻松愉悦（Make shipping applications more enjoyable）”的指标。
- KubeVela 定义为“简略易用又高度可扩大利用治理平台”，该我的项目背地的思考是什么？其“简略易用又高度可扩大”这两大个性又是如何实现的？
< 张磊 >：明天，Kubernetes 为咱们构建出了一个对立的基础设施形象层，为平台团队屏蔽掉了“计算”、“网络”、“存储”等过来咱们不得不关注的基础设施概念。但当咱们把视角从平台团队晋升到垂直业务零碎的最终用户（如：利用开发人员）的时候，咱们会发现 Kubernetes 这样的定位也为利用开发者们带来了挑战和困扰。比方，太多的用户都在埋怨 Kubernetes“太简单了”。究其原因，其实在于 Kubernetes 中的外围概念与体系，次要是面向平台团队而非最终用户设计的。不足面向用户的设计不仅带来了平缓的学习曲线，影响了用户的应用体验，拖慢了研发效力，甚至在很多状况下还会引发错误操作乃至生产故障（毕竟不可能每个业务开发人员都是 Kubernetes 专家）。
这也是为什么在云原生生态中，简直每一个平台团队都会基于 Kubernetes 构建一个下层平台给用户应用。最简略的也会给 Kubernetes 做一个图形界面，略微正式一些的则往往会基于 Kubernetes 开发一个类 PaaS 平台来满足本人的需要。实践上讲，在 Kubernetes 生态中各种能力曾经十分丰盛的明天，开发一个类 PaaS 平台应该是比拟容易的。
然而事实却往往不尽如人意。在大量的社区访谈当中，咱们发现在云原生技术极大遍及的明天，基于 Kubernetes 构建一个功能完善、用户敌对的下层利用平台，仍然是中大型公司们的“专利”。这里的起因在于：Kubernetes 生态自身的能力池诚然丰盛，然而社区里却并没有一个可扩大的、方便快捷的形式，可能帮忙平台团队把这些能力疾速“组装”成面向最终用户的性能（Feature）。
这种窘境带来的后果，就是只管大家明天都在基于 Kubernetes 构建下层利用平台，但这些平台实质上却并不可能与 Kubernetes 生态齐全买通，而都变成一个又一个的垂直“烟囱”。这些平台都无一例外的引入了本人的专属下层形象、用户界面和插件机制。这里最典型的例子包含经典 PaaS 我的项目比方 Cloud Foundry，也包含各种 Serverless 平台。所以，作为一个公司的平台团队，咱们实际上只有两个抉择：要么把本人局限在某种垂直的场景中来适配和驳回某个开源下层平台我的项目；要么就只能自研一个合乎本人诉求的下层平台并且造无数个社区中曾经存在的“轮子”。
那么，有没有”第三种抉择”可能让平台团队在不造轮子、齐全买通 Kubernetes 生态的前提下，轻松的构建面向用户的下层平台呢？
KubeVela 就是这样一个面向用户的下层平台我的项目。对于业务开发者来说，KubeVela 简略、易用，它能够让开发者以极低的心智累赘和上手老本在 Kubernetes 上定义与部署利用 。而关开发者只须要编写一个 docker-compose 格调利用形容文件 Appfile 即可，不须要接触和学习任何 Kubernetes 层的相干细节。但更重要的是，对于平台团队来说，KubeVela 可不是一个简略的 PaaS 或者 Serverless， 它是一个可能以 Kubernetes 原生的形式进行任意扩大的 PaaS 内核，平台工程师能够基于它构建出任意的垂直业务零碎。
在具体实现上，KubeVela 通过 OAM 模型，对云原生生态中的能力进行了面向用户侧的形象，同时也做到了 KubeVela 中的任何一个性能都是插件。基于这种设计，KubeVela 以可插拔式的形式内置了 Flagger，KEDA 等社区先进的公布、扩容技术作为默认能力，又以 Kubernetes 原生的形式提供了能够一键接入任何生态能力的高可扩展性。同时，对用户提供了一个 docker-compose 格调的 Appfile 来让用户以极简的形式形容如何 build，deploy 和 release 本人的利用。这些办法，都是达成“简略易用、又高度可扩大”这两个指标的重要技术手段。
- 具体到某一位用户要应用 KubeVela 平台，比方我是一个商城业务开发者，我如何在理论生产过程中部署和应用 KubeVela? 作为一个平台工程师，我又如何应用 KubeVela 呢？
< 张磊 >：KubeVela 只有一个二进制文件，所以它的部署非常简单。在任何一个 Kubernetes 集群曾经就绪的状况下，下载这个二进制文件后执行 vela install 命令即可。
而应用 KubeVela 就更加简略了。比方咱们商城业务开发，他从始至终都不须要关怀 KubeVela 和 Kubernetes 的存在，只须要在代码库中实现开发和本地测试，而后加上一个如下所示的 Appfile 放在代码库中即可。
这个 20 来行的配置文件，指定了咱们这个商城利用的镜像打包文件（Dockerfile），运行类型（type），启动命令（cmd），拜访所需的路由和域名（route），以及程度扩容的策略（autoscale）。所有这些配置项，全部都是 KubeVela 提供的面向用户的下层形象，不须要理解底层 Kubernetes 的任何细节和执行机制。而作为用户，只须要执行一句：vela up，一个残缺的、能够立刻域名拜访、会主动扩容的利用就会被公布到 Kubernetes 上运行起来。这个 vela up 操作，也能够接入到 CI/CD 流水线当中，让 Git 去触发。
值得一提的是，下面所有的这些配置项具体有哪些、每个项有哪些字段能够让用户填？这些都是平台管理员能够随时配置、调节、并且批改立刻失效的。这种平台层高度灵便和疾速响应的敏捷性，是互联网时代软件开发与迭代的重要保障。
而对于平台开发者来说，他应用 KubeVela 的次要形式，就是通过 Kubernetes 来治理这些形象和能力。他能够随时往 KubeVela 里装置新的能力。这些能力能够是 Kubernetes 社区里已有的插件，也能够是平台团队本人开发的 CRD controller。而所有这些操作只须要一行命令：kubectl apply -f trait.yaml。
这个 trait.yaml 实际上就是一个“能力”的形容文件，它的内容是对该能力应的 CRD 的援用和用户模板。比方，咱们能够把 Kubernetes 社区的监控 CRD 作为一个利用监控能力（起名叫做 metrics）装置到 KubeVela 中，那么成果就是，平台的用户立即就可能在 Appfile 里新定义一个配置项，叫做 metrics：
上述 Appfile 的最初一部分，就是咱们新增的 metrics 能力。怎么样，非常简单吧？大家可能会好奇，那么这样一个能力的“形容文件“，外面的内容到底长什么样子呢？
别急，KubeVela 的官网文档里提供了具体的例子和指南：https://kubevela.io/#/en/platform-engineers/trait
- 那么 KubeVela 我的项目是一个 PaaS 吗？
< 张磊 >：大多数经典 PaaS 都能提供残缺的利用生命周期治理性能，同时也十分关注提供简略敌对的用户体验，晋升研发效力。在这些点上，KubeVela 跟经典 PaaS 的指标，是十分统一的。
但另一方面，经典 PaaS 往往是不可扩大的（比方 Rancher 的 Rio 我的项目），或者会引入属于本人的插件生态（哪怕这个 PaaS 是齐全基于 Kubernetes 构建的），以此来确保平台自身的用户体验和能力的可控制性（比方 Cloud Foundry 或者 Heroku 的插件核心）。
相比之下，KubeVela 的设计是齐全不同的。KubeVela 的指标，从一开始就是利用整个 Kubernetes 社区作为本人的“插件核心”，并且“成心”把它的每一个内置能力都设计成是独立的、可插拔的插件。这种高度可扩大的模型，背地其实有着精细的设计与实现。比方，KubeVela 如何确保某个齐全独立的 Trait 肯定可能绑定于某种 Workload Type？如何查看这些互相独立的 Trait 是否抵触？这些挑战，正是 Open Application Model（OAM）作为 KubeVela 模型层的起到的关键作用，一言以蔽之：OAM 是一个高度可扩大的利用定义与能力治理模型。
KubeVela 和 OAM 社区欢送大家设计和制作任何 Workload Type 和 Trait 的定义文件。只有把它们寄存在 GitHub 上，全世界任何一个 KubeVela 用户就都能够在本人的 Appfile 里应用你所设计的能力。具体的形式，请参考 vela cap（即：插件能力治理命令）的应用文档。
- 是否就云原生相干生态在国内的发展趋势发表一些您的观点和认识？
< 张磊 >：正如后面讲到的，不止国内，其实整个云原生生态在接下来的倒退方向，能够说是“回归初心”。
云原生技术与理念倒退至今，在基础设施形象层曾经获得了空前的成就。当然，这里的所有一切都是围绕着 Kubernetes 我的项目来进行的。但咱们也提到，光有基础设施形象是远远不够的。咱们云原生的最终目标是给业务用户带来价值，用云原生与生俱来的弹性和麻利，帮忙业务用户更快、更好、更有信念的去开发与交付利用。而至于 Kubernetes 也好，容器也罢，都是实现这个指标的伎俩而不是目标。所以，云原生倒退的方向肯定会持续朝这个指标后退，比方为了进一步解决业务用户以语言无关的形式对流量与服务进行治理的诉求，就呈现了 Service Mesh。而明天 OAM 与 KubeVela 我的项目的呈现，则是在所有这些能力之上，答复“最初一公里”的问题：咱们如何把这些能力高效、麻利、通过”以利用为核心“的形式交付给业务用户？让他们真的可能像应用 Heroku 那样应用 Kubernetes 和 Istio？
这种“让业务研发专一于写代码”体验，说起来简略，宣传起来也很赞，但从云原生技术诞生到当初，在整个云原生生态的继续致力下，这件事件仍然只解决了一小部分。而现在，KubeVela 我的项目的提出与公布，正是云原生生态持续推动这件事件向终态后退的一个缩影。心愿 KubeVela 这样的我的项目，可能让构建简略易用又高可扩大的云原生利用平台从大厂专属的“下里巴人”，变成“小菜一碟”，让越来越多的团队可能疾速、高效、高质量的基于 Kubernetes 生态能力池构建出合乎本人诉求的、各种各样的下层平台，让云原生技术可能真正落地到各行各业中开花结果。
原文链接
本文为阿里云原创内容，未经容许不得转载。