「开源人说」第五期 | KubeVela:一场向应用交付标准的“冲锋”

简介: 「开源人说」第五期聚焦云原生领域开源至今仅两年多的项目——KubeVela,将镜头对准 KubeVela 项目背后的代码贡献者和落地实践者,讲述这个从第一天就诞生在社区的技术,如何走到对不同场景应用“海纳百川”,直至成为 CNCF 孵化项目,并逐渐向应用交付领域的事实标准演进的故事。 阅读下文,让我们跟随 KubeVela 创始团队,一起了解它的开源背后的故事。

01

云原生下的开源标准化演进


回顾信息产业几十年的发展历史,整个行业存量的数千万台服务器,在集群管理、资源切分供给、资源调度、任务编排、应用交付、应用运维等领域,一直没有形成标准和规范。几年前一份行业调研显示,全球服务器平均资源利用率不超过10%,这里面存在巨大的社会资源浪费,也存在巨大的优化空间。


云计算的发展使这些问题变得可以解决了。基础设施逐渐向云上迁移的过程中,催生了容器和 Kubernetes 的迅速流行,也为上述领域构建统一的标准,不同云厂商间 IaaS 的差异性被屏蔽,使用户在所有云环境中可以灵活使用资源,并且可以无缝的迁移和维护应用。


云原生的理念也因此得到快速普及。企业将越来越多的工作负载都迁移到 Kubernetes 之上,包括有状态或无状态的,比如微服务、大数据、AI、数据库、中间件等等。为了管理和运维这些应用,开发者不得不面对大量的底层API,这形成了两个挑战。一方面,应用交付和管理标准的缺失,使各种工作负载都会形成自己的运维和管理平台,带来企业平台层的分化。另一方面,Kubernetes 对于业务开发者而言过于复杂,带来了很高的使用门槛和稳定性风险。


在 Kubernetes 和云原生技术对基础设施和工作负载层面的抽象逐渐统一的态势下,如何进一步简化和标准化应用交付与管理层面的操作和功能,成为接下来一个非常自然但重要的演化方向,也会成为市场真正需要角逐的战场。


1.png2019年阿里云与微软联合发布OAM


2018年前后,阿里云云原生团队和微软同时看到了这个方向,在一次于阿里硅谷中心的深度交流和头脑风暴后,双方当即决定联合起来,共同孵化这个应用交付与管理体系,并于 2019 年联合发布了应用标准化模型OAM(Open Application  Model),为云原生生态的应用平台建设提供理论依据。


02

KubeVela:一场向应用交付标准的冲锋


OAM 的开源引发了业界不小的震动,不少企业都在进行积极的推广验证,这其中当然包括阿里的多个产品线。然而一段时间之后,阿里云云原生团队意识到要真正解决用户的问题,只靠模型还远远不够。


由于没有具体的实现方案,仅遵循 OAM 模型的思想,仍会使系统之间形成巨大差异,特别是在规模较大的场景下。比如阿里内部就形成了多套实现,能力无法复用,应用间也不能互通。而在社区的推进过程中,得到的更多反馈是 OAM 模型没有实现,很难落地使用。因此云原生团队下决心要把 OAM 的实现做出来,并且是以开源的方式去做,这也是来自社区的呼声。 


2.png

KubeVela 开源团队在沟通技术实现细节


KubeVela 就此诞生。


一、新技术要解决原有问题,而不是带来新的问题


KubeVela 诞生于 OAM 社区,也是第一个将“以应用为中心”的设计理念落地的项目。发展到 2021 年 5 月,阿里云联合信通院发布业内首个以 OAM 为核心的“云计算开放架构”标准,将 OAM“模型”化虚为实,也对 KubeVela 后来的发展起到关键作用,推动其成为一个真正意义上的跨云应用交付与管理平台。


凭借过去做云产品的经验积累,KubeVela 团队深知一个新技术想要顺利推广,很重要的一点是在解决原有问题的同时,尽可能降低用户采纳的成本。社区对之前的实践和功能做了充分兼容。当 KubeVela 发布第一个正式版本的时候,用户做的操作更像是升级而不是使用一个全新的系统。


为了保证社区后续的演进不偏离这个路线,在设计之初 KubeVela 创始团队就定下了一些核心原则,指导整个 KubeVela 开源社区的长期发展。


1、兼顾用户友好和可扩展性

KubeVela 基于 OAM 模型提供用户友好的上层抽象,但这些抽象可以随时扩展以满足用户的各种需求。这就避免了 KubeVela 项目成为了一个只能解决“最小公分母”问题的“鸡肋”项目。这是一个非常重要的创新。


2、可编程

而在众多的可扩展性设计中,KubeVela 最终选择了 Infra as Code 的可编程扩展方式。因为这种扩展方式不仅简单易用,还可以方便的模块化和插件化。这个选择不仅提供了扩展 KubeVela 的最佳方案,还为后来的插件市场等生态能力打下了基础。


3、以工作流为核心的交付模型

在 KubeVela 被开源社区逐步采用的过程中,根据大量的用户反馈和调研显示,看似非常碎片化和复杂的各类应用交付与管理场景,其背后确实有一个非常本质的基础模型存在的。这个基础模型就是“工作流”,所以在 KubeVela 创立后,团队很快就开始同时演进 OAM 模型本身,引入了“工作流”这个基础模型并且在 KubeVela 实现了一个非常轻量级的工作流引擎。而“工作流”这个特性本身就又与 Kubernetes 和 GitOps 生态天然互补,所以这个关键创新很快就成为了 KubeVela 被大量采用的“杀手锏”。


4、以业界最广泛和最真实的场景作为项目演进指南针

KubeVela 的发展过程中,大量关键的设计比如对交付 Helm 组件的完善支持、基于 GitOps 的核心交付流程、以多集群/多云/混合云环境作为首要交付目标等,都是结合阿里内部大规模实践,同大量的开源社区用户一起打磨、设计、然后最终实现出来的。这也是为什么很多人评价 KubeVela 是一个非常接地气的项目。这种基于阿里最佳实践但又紧贴业界最广泛场景的演进方式,对于 KubeVela 项目的广泛采用,做出了至关重要的贡献。

4.png


云原生时代的工具和技术百花齐放,对于企业来说,如何将这些丰富的技术快速落地为我所用,是一个很大的挑战。KubeVela的价值就在这里。如果做一个类比的话,它有点像云原生生态的 “Spring 框架”。在 Java 生态中,开发者可以通过Spring 快速构建业务应用,使用一致的编程模型、不需要了解各类技术框架的细节,从而能够大幅降低技术门槛。 相对应的,KubeVela 是将云原生技术组件和企业应用连接起来,建立管理和运维交付的标准,让开发者对云原生的关注点从 Kubernetes 向应用平台升级。


二、更多的功能和更低的门槛,怎么选?


OAM 先进的理念、社区的用户基础加之阿里内部大规模的实践检验,使 KubeVela 初期的发展非常顺利,正式发布的第一周就冲上了 GitHub 的 Go 语言项目的趋势榜榜首。

6.png


同时,它也不可避免地遇到了刚起步的开源项目都可能遇到的问题。


首先,开源项目要成功的一大关键就是用户初始体验,而早期团队一般会更注重产品能力研发。KubeVela 本身的灵活性和可扩展性强大,这就导致第一个用例要么过于简单无法突出特色,要么过于复杂跑不起来。为了解决这些问题,团队开始重视安装复杂度、第一个用例的设计,文档结构的设计等等。直到现在,社区也一直在不断完善相关工具和文档,让初始用户可以低门槛体验项目。


第二, 可扩展性是 KubeVela与生俱来的核心设计。刚开始的时候,KubeVela 的扩展点众多,但是没有一个统一的概念,没有对应的工具链,几乎没有社区开发者能够知道如何进行扩展。因此,社区提出 Addon 的产品概念,将扩展能力以相对规范的形式进行开发、整合。投入开发者重点维护全链路工具,打通 Addon 的开发、存储、分发、升级机制。目前 Addon 的产品概念已成为 KubeVela 的特色之一。


第三,随着项目面临的场景越来越多、功能越来越丰富,KubeVela不可避免地会遇到复杂性挑战。2021年下半年,KubeVela 迎来v1.1版本,加入多集群管理的能力,同时也具备了通过工作流驱动整个交付过程的能力,这些都大大提升了KubeVela 整个项目的可扩展性,但是也加剧了用户使用的门槛。也是在这时,KubeVela 团队意识到,项目的用户群体需要分层:下层是PaaS的构建者和运维,基于 KubeVela 的引擎能力去构建 PaaS ,他们需要充分的灵活性和扩展性去适配企业内的不同场景;而上层是业务的开发者,相对来说他们更需要一个简单易用的平台,快速足业务开发需求。于是,社区开启了一个新的项目 VelaUX , 以插件化的方式集成到 KubeVela 内核上,使用户可以通过点击一个插件实现安装一个直接开箱即用的平台。  VelaUX 的出现也将 KubeVela 从以 Kubernetes 为主的技术性高扩展性项目实现向平台化高扩展性项目的跃迁。


三、热爱,就是一种竞争力


相比于那些已经在公司内孵化好再开源的项目,KubeVela 是特殊的。它从第一天起就在社区发起、在社区演进,甚至 KubeVela 这个名字也是由早期成员投票产生的。KubeVela 的初创团队邀请了许多 OAM 早期采纳公司的工程师一起来合作开发,保证项目核心部分的代码质量和稳定性。剩下的许多模块设计也都是在社区群策群力下完成的,比如官网的 UI 设计、命令行功能的使用方法、对于云资源支持的优先级等等,确保 KubeVela 许多用户体验方面的设计都建立在满足社区最广泛需求的基础之上,也保证了 KubeVela 项目贴近开发者的初心。


KubeVela 发展初期,团队成员每天打开 Github 页面都能看到大家给出的使用反馈、建议、以及代码贡献,这给了初创团队很深的感触和鼓舞。工程师在贡献开源的时候,其实都是在做自己喜欢的事情。如果一个人一直在做自己喜欢的事情,这本身就是一种强大的竞争力。KubeVela 社区也通过构建包容、开放、专业的协作环境,鼓励大家参与到开源建设中来,肯定每个人的工作,尊重每个人的价值。


从诞生之初, KubeVela 就是按照面向全球的开源项目去运作的。为使社区保持持续的生命力,2021 年 7 月,阿里云将 KubeVela 捐赠给 CNCF ,渐渐将影响力渗透到北美、日本、西班牙、英国等多个国家。如今,KubeVela 贡献者已经遍布全球,所在的企业和组织超过70个。不久前,KubeVela 正式晋升为 CNCF Incubation 项目,证明项目的影响力和成熟度得到业界认可。


7.png

KubeVela 社区的贡献者们


今天,企业对 KubeVela 的采纳程度正在快速提升。在阿里云内部,KubeVela 已经陆续成为SAE、ACK One、EDAS、云效、CDN 等多款产品的 PaaS 内核;在社区中,招商银行、第四范式、中国电子、Napptive 等大量国内外公司也正在企业的平台工程中展开 KubeVela 的落地实践。


03

让平台化、标准化的理念生根发芽


在最近 Gartner 发布的“2023年十大重要技术趋势”中,“平台工程”(Platform Engineering)这一项和 KubeVela 的定位不谋而合。KubeVela 正在成为平台工程的最佳范式。记得一次社区例会上,社区的一位企业用户代表在分享他们的实践方案时说了这样一段话:“通过使用 KubeVela,目前在我们的团队,产品、后端、前端甚至是交付同事之前的沟通语言由原来的 Kubernetes 技术概念完全变更成了 OAM 的标准化概念,我们不再需要向具有不同技术背景的同事去解释技术,特别是Kubernetes 复杂生态的技术。平台化、标准化理念正在公司生根发芽。”


云原生技术的普及催生了全新的应用开发方式,其带来的技术水位的持续上移,将会把应用的交付和管理带向成熟和统一。也许这条路还很长,但我们相信,在这场面向应用交付标准的冲锋中,KubeVela 的贡献势必会留下浓墨重彩的一笔。  

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
运维 JavaScript Java
快速部署阿里云WebIDE(DevStudio)并参与开源项目开发
3个步骤,在轻量应用服务器上完成部署DevStudio,帮你快速学习使用DevStudio进行代码的开发。
快速部署阿里云WebIDE(DevStudio)并参与开源项目开发
|
10月前
|
机器学习/深度学习 人工智能 资源调度
隐语1.0正式发布|MVP部署体验包、资源调度框架Kuscia全新亮相!
隐语1.0正式发布|MVP部署体验包、资源调度框架Kuscia全新亮相!
231 0
|
JSON 运维 Prometheus
让应用交付和管理统一:KubeVela 亮点功能及核心技术回顾
让应用交付和管理统一:KubeVela 亮点功能及核心技术回顾
11645 0
让应用交付和管理统一:KubeVela 亮点功能及核心技术回顾
|
运维 Kubernetes Cloud Native
「开源人说」| 开源项目的演进会遇到哪些“坑”?KubeVela 从发起到晋级 CNCF 孵化的全程回顾
KubeVela 诞生于 OAM 社区,开源第一天起就遵循“社区发起、开放治理、国际化运作”的原则。 今 年 2 月,KubeVela 经过全体 ToC 投票成功进入 CNCF Incubation,是云原生领域首个晋级孵化的面向应用的交付和管理平台。本文将做一个完整的回顾,梳理项目演进过程中的那些“坑”,希望对整个开源生态的发展有所帮助。
48501 1
「开源人说」| 开源项目的演进会遇到哪些“坑”?KubeVela 从发起到晋级 CNCF 孵化的全程回顾
|
存储 运维 Kubernetes
从开源技术 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(一)
快速学习从开源技术 KubeVela 谈起:云原生应用交付会怎样发展。
1776 0
|
存储 运维 Kubernetes
从开源技术 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(三)
快速学习从开源技术 KubeVela 谈起:云原生应用交付会怎样发展。
1934 0
|
人工智能 运维 Kubernetes
从 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(二)
快速学习从 KubeVela 谈起:云原生应用交付会怎样发展
1630 0
从 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(二)
|
运维 Kubernetes Cloud Native
从 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(三)
快速学习从 KubeVela 谈起:云原生应用交付会怎样发展
1627 0
从 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(三)
|
存储 Kubernetes Cloud Native
从 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(四)
快速学习从 KubeVela 谈起:云原生应用交付会怎样发展
1701 0
从 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(四)
|
存储 运维 Cloud Native
从 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(一)
快速学习从 KubeVela 谈起:云原生应用交付会怎样发展
1689 0
从 KubeVela 谈起:云原生应用交付会怎样发展|学习笔记(一)