专访 CNCF 大使张磊：让云原生不再是大厂专属

来源| 阿里巴巴云原生公众号

近日，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、官方大使，来自阿里云的工程师张磊，详细的聊了聊。

采访嘉宾介绍

以下为采访原文：

1. 请给还不了解 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 范式和插件化能力管理模型。

2. 距离 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）”的目标。

3. 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 自己的应用。这些方法，都是达成“简单易用、又高度可扩展”这两个目标的重要技术手段。

4. 具体到某一位用户要使用 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

5. 那么 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 （即：插件能力管理命令）的 使用文档 。

6. 能否就云原生相关生态在国内的发展趋势发表一些您的观点和看法？

<张磊>：正如前面讲到的，不止国内，其实整个云原生生态在接下来的发展方向，可以说是“回归初心”。

云原生技术与理念发展至今，在基础设施抽象层已经取得了空前的成就。当然，这里的所有一切都是围绕着 Kubernetes 项目来进行的。但咱们也提到，光有基础设施抽象是远远不够的。咱们云原生的最终目标是给业务用户带来价值，用云原生与生俱来的弹性和敏捷，帮助业务用户更快、更好、更有信心的去开发与交付应用。而至于 Kubernetes 也好，容器也罢，都是实现这个目标的手段而不是目的。所以，云原生发展的方向一定会继续朝这个目标前进，比如为了进一步解决业务用户以语言无关的方式对流量与服务进行治理的诉求，就出现了 Service Mesh。而今天 OAM 与 KubeVela 项目的出现，则是在所有这些能力之上，回答“最后一公里”的问题：我们如何把这些能力高效、敏捷、通过”以应用为中心“的方式交付给业务用户？让他们真的能够像使用 Heroku 那样使用 Kubernetes 和 Istio？

这种“让业务研发专注于写代码”体验，说起来简单，宣传起来也很赞，但从云原生技术诞生到现在，在整个云原生生态的持续努力下，这件事情依然只解决了一小部分。而如今，KubeVela 项目的提出与发布，正是云原生生态继续推动这件事情向终态前进的一个缩影。希望 KubeVela 这样的项目，能够让构建简单易用又高可扩展的云原生应用平台从大厂专属的“阳春白雪”，变成“小菜一碟”，让越来越多的团队能够快速、高效、高质量的基于 Kubernetes 生态能力池构建出符合自己诉求的、各种各样的上层平台，让云原生技术能够真正落地到各行各业中开花结果。