专访 KubeVela 核心团队：如何简化云原生复杂环境下的应用交付和管理

采访嘉宾 | 曾庆国

编辑 | Tina

12 月 9 日，在 2021 年 KubeCon 云原生技术峰会上，CNCF 开源项目 KubeVela 宣布推出了 1.2 版本。

KubeVela 是一个简单易用且高度可扩展的应用交付和管理平台，基于 Kubernetes 与 OAM 技术构建。其核心功能是让开发人员方便快捷地在 Kubernetes 上定义与交付现代微服务应用，而无需了解任何 Kubernetes 本身相关的细节。

KubeVela 于 2020 年 11 月开源，2021 年 4 月发布 1.0 版本。2021 年 7 月，KubeVela 和 OAM 项目整体捐赠给 CNCF 基金会托管。

在 1.2 版本中，KubeVela 新增了以应用为中心的控制面板 UI 功能，使应用组装、分发、交付流程变得更简单，并可以通过 UI 控制台及时了解整个交付链路状态，简化多云/混合环境交付方式。另外还新增了基于订阅模型的开源应用交付系统 ，使企业和云原生应用开发者只需要在 GitHub/Gitlab 上修改代码，就可以自动完成云原生应用交付的整个链路。

从开源到现在已经有一年多，KubeVela 社区取得了什么样的进展？有了哪些落地实践？1.2 版本中为什么会新增加这两个功能，适合于什么场景？为解答这些问题，InfoQ 采访了 OAM/KubeVela 产品和开源社区负责人曾庆国。

嘉宾简介：曾庆国（花名：悦达），阿里云技术专家，目前负责 OAM/KubeVela 产品和开源社区，从事云原生、应用交付、开源领域研究和实践多年，致力于推动云原生应用标准化和云原生技术“亲民化”。

InfoQ：目前基于 Kubernetes 的云原生应用交付还存在哪些挑战和难点？业界对应的有哪些解决方案？

曾庆国：如今 Kubernetes 逐渐成为了基础设施的标准集成界面，云原生生态的繁荣也为我们提供了近乎无限的基础设施能力。然而众多的选择是礼物，也是研发工程师的噩梦，大量复杂的知识需要学习，就好比一个业务研发工程师需要了解操作系统底层的系统调用一样。然而应用的高效、安全交付，才是工程师真正的诉求。 如何用好云原生繁荣的技术生态，又能降低用户的使用门槛，同时安全可靠的交付应用，成为了业界新的挑战。

业界的典型做法主要分为三类，一类是容器平台模式，原汁原味的透出底层组件，灵活性很强，但平台使用者需要学习组件大量的技术细节；第二类是在针对不同的业务场景构建内部的平台，但是由于顶层设计不足，拉通难度大，不同垂直场景成为互相独立的烟囱而无法做到能力复用、统一管理；第三类则是基于 CI/CD 系统，以脚本、配置等构建简单的抽象体系简化使用，这个方式的问题在于无法满足大规模场景的需要，脚本和配置文件散落各处，其上手和维护的门槛非常高，也有安全隐患。

InfoQ：KubeVela 在 Kubernetes 生态系统中处于什么位置？初心是解决什么样的问题？现在的目标与最初相比有所变化？

曾庆国：今天，无论是 Kubernetes 本身还是现有的各类应用交付系统，都缺乏一个统一的面向应用交付过程的上层抽象。这种缺乏往往同底层基础设施紧密耦合，导致用户心智负担很重并且严重依赖于用户个人的经验和能力。这不仅会大幅影响用户体验、降低生产效率，甚至还会导致错误和故障的发生。KubeVela 是针对这个问题的开源、标准又不失灵活度的解法。

KubeVela 在 Kubernetes 生态系统上层建立了“以应用为中心”的视角，业务层的开发者可以直接使用 KubeVela 作为开箱即用的 CI/CD 工具对接包括 Kubernetes 和云资源，完成应用交付和管理。对于中大型的公司，KubeVela 是一个具备充分可扩展性的应用交付和管理引擎，这些公司可以基于 KubeVela 标准化的扩展机制，针对自身业务场景扩展应用交付能力，快速构建自己的应用管理平台。

这个初心一直没有变化，我们从应用标准 OAM 到如今 KubeVela v1.2 即将推出的 UI 控制台，这一系列的工作都是在推动云原生社区从基础设施向应用层不断发展和演进，最终实现开发者自助的应用交付和管理模式，最终期望为业界带来标准和统一的云原生应用管理层，普惠云计算的开发者。

InfoQ：从中立客观的角度来讲，您们认为 PaaS 解决方案和 KubeVela 各有什么样的优缺点？

曾庆国：说到经典的 PaaS 解决方案，业界最出名的就是 Heroku 和 Cloud Foundry，它们提供完整的应用程序部署和管理功能，为业务开发人员提供了非常好的体验和开发效率。但是云原生的崛起带来了技术的全面升级，也带来了云计算的巨大繁荣。传统的 PaaS 平台通过提供一层应用封装和抽象为用户带来好的体验，但这层封装往往缺少良好的定制化扩展能力，平台演进不得不完全依靠平台团队开发，无法应对业务新的个性化需求，无法应对新技术发展的敏捷集成。 

KubeVela 和它们最大的区别在于其可扩展性，KubeVela 从设计的第一天就以高可扩展为原则，以此为核心提供端到端的抽象和用户体验。它的交付工作流乃至整个应用交付与管理能力集都是由独立的可插拔模块构成的，这些模块可以随时通过编写 IaC 配置模板的方式进行增减、重定义，且变更会即时生效。借助这种从核心模型到 UI 呈现都能够快速变更的技术，使得 KubeVela 能够兼顾“使用简单”和“技术先进性”。

此外，KubeVela 是一个独立于运行时集群的应用交付控制平面，天然支持多集群、多云混合环境（这是我们认为的下一代 PaaS 系统的合理形态），而现有的 PaaS 则往往选择以插件形式部署在运行时集群当中。

InfoQ：基于 Helm 的应用交付方案，和 KubeVela 解决方案相比，两者有哪些不同？

曾庆国：Helm 是 Kubernetes 的包管理器，它能够以 Chart 为一个单元，提供打包、安装和升级的一组 YAML 文件的能力。

KubeVela 是一个完整的应用交付系统，它借助扩展能力可以部署各种制品类型，当然也包括 Helm Chart，除此之外还包括 Kustomize、Terraform Modules 等。KubeVela 支持 Kubernetes 和云服务等多种运行平台。 同时它也涵盖了多集群交付的能力，包括跨环境部署的各类编排能力。例如，你可以使用 KubeVela 定义一个由 WordPress Chart 和阿里云 RDS 实例组成的应用，编排这两个组件之间的顺序关系，然后将它们按照一定的策略分发到多个 Kubernetes 集群当中。

我们也在社区里见到了一些基于传统 CI/CD 工具 和 Helm 做应用部署的解决方案，这类方案通常会通过类似 Jenkins/Gitlab 这样的 Pipeline ，将应用制品打包成 Helm Chart，然后直接部署到 Kubernetes 集群中。这种模式看似简单，实际上存在三个方面的问题：

• 一是手工维护工作量大，比如由于突发的网络原因、或者由于 pipeline 系统的某个故障，就会中断所有的发布并且需要人工介入，缺乏自愈能力，一旦场景有变化，就要修改脚本，比较难维护。

• 二是没有一个统一的模型描述完整的应用交付过程，不同的人可以从多处入口对系统进行变更，例如有的通过 CI/CD 系统，有的直接改 Kubernetes，时间久了系统的配置会出现很大的不一致，容易引发故障。

• 三是存在安全风险，CI/CD 安全域不隔离，基础设施多个集群的秘钥全都在 CI/CD 系统中存储，一旦被黑客突破容易引发非常大的系统安全风险。

KubeVela 是面向终态的应用交付和管理控制平面，KubeVela 的交付引擎具备自愈、幂等、收敛以及确定这四大特性，同时 KubeVela 背后有一个完整的应用模型（OAM），这个可以作为统一的应用入口，避免配置漂移等问题。KubeVela 自身也具备完整的 GitOps 以及多集群自治的功能，可以保证环境独立管理，安全域隔离。

InfoQ：社区针对小规模集群或个人开发者的场景有所疑问，认为无论是增加 API 层还是还需编码，KubeVela 的方向在复杂化应用交付和集群管理，对此您们有何看法？

曾庆国：KubeVela 从一开始就诞生于开源社区，演进至今已有上百位贡献者参与代码贡献，吸纳了来自阿里、腾讯、字节、第四范式、Gitlab 等一系列不同领域公司的工程实践。KubeVela 从一开始的设计目标是保证充分的可扩展性，这样才能满足用户的多样化场景需求，充分利用云原生领域百花齐放的技术生态红利。

对于个人开发者或中小型科技企业，他们的实际需求必然是希望使用云原生技术就像使用 iOS 操作系统一样，低门槛，易用且好用。把端到端的体验做成闭环才能更好满足他们，无论增加 API 层还是需要编码，都不是这类用户想要关心的话题。

客观的说，在 KubeVela 最初的几个版本，由于要把面向可扩展性的核心设计做实，用户看到的形态更多是偏框架一层的实现。在发展到 v1.1 版本以后，我们就陆续加入了很多端到端的集成案例，包括 GitOps、Jenkins CI/CD、Helm 包的完整部署等，即将发布的 v1.2 就更是一个面向小规模集群和个人开发者直接开箱即用的平台了，用户可以直接操作 KubeVela 的 UI 控制台就可以完成应用交付的完整体验。

InfoQ：1.2 版本中，基于订阅模型的应用交付主要是解决什么场景下的问题？

曾庆国：

基于订阅模型的应用交付主要解决以下几个维度问题：

（1）区域隔离，安全自治

完整的应用交付链条分为 CI 过程、配置过程和部署过程。在订阅模型中，控制平台支持自动从制品库发现制品的变更，从配置仓库发现配置的变更，从而执行后续的部署动作，Runtime 集群区域主动从管控平台获取到部署任务执行。每一个环节都独立工作，自成体系，每一个环节都根据需要进行授权和审核，安全可靠。

（2）网络隔离，云边协同

订阅模型采用 PULL 的模式，仅需要单向通信网络即可工作，在边缘应用交付中这是一个必需的选项。KubeVela 可以统一编排和管理云端和边缘端应用，实现云边协同。

（3）集中管理，充分自动化

刚才我们提到，每一个阶段都是独立自动化工作的，且具备自愈、幂等、收敛以及确定这四大特性。让我们的管理侧实现统一。

另一方面，在 KubeVela 1.2 版本中，主要打造了在多集群、多环境下微服务应用的统一管理解决方案。用户通过操作 UI 控制台，实现集群接入、租户分配、环境规划和应用交付等完整用户故事。

InfoQ：目前 KubeVela 社区发展情况如何？未来的路径规划是什么？

曾庆国：KubeVela 是一个从第一天就诞生在云原生社区的开源项目，KubeVela 背后的应用模型就是 OAM。自 2019 年阿里和微软发布 OAM 模型以来，OAM 模型以及 KubeVela 项目已被阿里、Oracle、Salesforce、腾讯、字节跳动、网易游戏等 40+ 家不同行业的领先企业应用在实际生产环境，帮助他们在不同场景下实现更高效的云原生应用的交付和管理。

KubeVela 项目发展也非常迅速，至今已经累计有上百位开发者参与贡献，社区有上百万的镜像下载。2021 年 7 月，KubeVela 和 OAM 项目也已经整体捐赠给 CNCF 基金会托管，所以这也是一个完全中立的社区。KubeVela 在社区用户中的大规模实践，也正在促进 OAM 成为混合云/多云/分布式云领域应用交付的事实标准，并在阿里、微软、Oracle Cloud、腾讯等多家国内外厂商中被采用。2021 年 5 月，以 OAM 模型为核心的《云计算开放应用架构》标准文件也已经由阿里云和信通院等 10 余家单位联合发起并在“云原生产业大会”现场发布。

随着 v1.2 版本的发布， 未来 KubeVela 将更多的提供端到端的完整用户体验，丰富更多垂直场景下的能力，朝着开发者能够自助完成应用交付的方向演进，让混合环境下的应用交付就像我们今天使用 App Store 一样简单。