近日，GitHub Go 语言热门趋势榜上出现了一个新项目——KubeVela。

根据项目官方文档，KubeVela 是“一个简单易用且高度可扩展的应用管理平台与核心引擎”，它基于 Kubernetes（K8s）与 Open Application Model（OAM）技术构建而成。

在云原生持续升温的当下，很多开发者对 Kubernetes（K8s）已经不再陌生。那么，KubeVela 和 OAM 到底是什么？事实上，虽然 K8s 早已广为人知，但从大量社区反馈来看，围绕 Kubernetes 的云原生生态在实际落地时，仍然更像是少数头部大厂的主场。许多一线业务研发人员普遍认为 K8s 概念复杂、学习成本高，如果没有足够的技术积累和平台建设能力，想要基于 Kubernetes 搭建面向具体业务场景的上层平台并真正落地云原生，难度依然很大。

时间回到去年十月，阿里云联合微软共同开源了 OAM 项目。这个项目的目标，是为云原生生态打造一种“以应用为核心”的统一上层抽象技术。它的出现，有望显著降低业务研发人员学习和使用云原生技术的门槛，让更多团队真正感受到云原生所带来的敏捷交付能力与研发效率提升。而近期发布的 KubeVela，则正是 OAM 模型在 Kubernetes 上的完整落地实现。

如今距离 OAM 项目开源刚好过去一年，那么 OAM 项目目前有哪些进展？此次发布的 KubeVela，又会给国内 Kubernetes 生态带来哪些变化？带着这些问题，我们与 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 通过可插拔方式内置了 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 生态能力池，构建出真正符合自身需求的各类上层平台，推动云原生技术在更多行业和业务场景中真正落地、生根、开花结果。