作者：孙健波、曾庆国
点击检查：「开源人说」第五期《KubeVela：一场向运用交给标准的冲锋》
2023年2月，**KubeVela [ 1] **通过全体 ToC 投票成功进入 CNCF Incubation，是云原生范畴首个晋级孵化的面向运用的交给和办理渠道。KubeVela 背后的中心理念是 2019 年阿里云和微软联合发布的敞开运用模型（OAM），演化至今，KubeVela 通过其可编程可扩展的架构、杰出的用户体会，以及许多的生态中心才能，协助了钉钉、招商银行、抱负轿车、移动云、百度等数百家企业构建其云原生运用渠道，大大下降了云原生技能的运用门槛。
KubeVela 自身也有别于“大厂开源”的惯性方式，它从第一天起就遵从“社区建议、敞开管理、国际化运作”的准则，中心理念之一便是“一向以业界的最广泛和最真实场景作为项目演进的指南针”，所以开展途径中一向在倾听社区的声音，以最遍及、最共性的需求为最高优先级。因而，咱们也有幸经历了一个项目从社区建议到用户集体强大的全进程。从技能迭代、完善功用，到社区运营、开源管理，再到打磨产品、树立生态，咱们克服了诸多困难，这或许是开源项目都会遇到的应战。
今日，咱们将做一个完好的回忆，梳理项目演进进程中的那些“坑”，期望对整个开源生态的开展有所协助。
项目建议：明晰方针和定位
一个开源项目的建议，其最中心的是明晰项目的方针和定位。 OAM/KubeVela 诞生之初的 2018-2019 年，当时咱们判别：跟着云原生技能逐渐一致基础设施和作业负载层面的笼统，怎么进一步简化和标准化运用交给与办理层面的操作和功用，会成为接下来一个十分自然的演化方向，也会成为商场的下一个焦点。这里边咱们首要考虑了四个方面：
- 受众
大多数开发者，也便是终究事务运用的开发者，他们日常关心的是运用开发和布置，而不是核算存储网络，这意味着运用层的大幅简化和标准化必定会成为强需求。
- 定位和空间
Kubernetes 十分明晰的要把它的笼统层次停留在基础设施层，这为运用层的进一步创新和作业供给了满意的空间和支撑。
- 职业格局
在 Kubernetes 逐渐成为事实标准的布景下，大多数技能（比方 OpenShift）仍然在做局限的封装，而原生的工具（如 helm、kustomize）又过于简略。这样既不满意云上用户碎片化、多样化的运用诉求，也无法打造用户友爱的运用体会。
- 技能储备
CRD Operator， Terraform 等 IaC 技能的逐渐遍及供给了一个快速交给可编程、模块化的运用办理笼统，而依据 Kubernetes，一个独立的运用办理和交给系统能够十分专注于该层自身，而无需关注基础设施层的问题。
依据以上趋势的判别，阿里开端在2019年逐渐布局运用交给与办理范畴，提出了一系列先导性探究和实践，包含**Helm/Kustomzie运用办理、多集群运用交给 [ 2] **等。终究确定将“让软件交给在当今流行的混合、多云环境中变得愈加简略、高效、可靠”作为咱们的中心方针和愿景，将“一个与基础设施无关的、用户友爱但又灵敏可扩展的运用交给笼统”作为咱们的中心交给物，这个运用交给笼统便是今日的 OAM spec，而随后出现的 KubeVela 则是这一层笼统的详细完结。
图 1：KubeVela 是什么？
明晰的方针和定位不只支撑了 KubeVela 开源团队以及许多社区奉献者能够在相对松懈的方式下长时刻协作，还协助团队从许多杂乱的需求中解放出来，专注在最中心的问题域中。 比方 KubeVela 不会触及作业负载自身，用户能够挑选集成 Kubernetes 原生的 Deployment，或许自己扩展 CRD Operator，又或许挑选 OpenKruise 这样的作业负载办理工具。一起团队专注于项目的集成才能和扩展性，比方咱们投入了满意的精力去做 Kubernetes API 的编排，恣意的 Kubernetes 资源都能够在 KubeVela 系统中组合、拆分、检查状况、传递参数，这一特性使得 KubeVela 前期快速的打出了自己的商场定位，而且获得了像第四范式这样的前期用户。
前期演进：明晰要坚守的中心技能准则
开源项目的前期通常是沿着开端设定的方针去补齐中心功用，在此之前咱们或许需求回答一个问题：“为了让咱们的开源项目异乎寻常，咱们该遵从怎样的规划准则？ ”
KubeVela 项目的第一个年初是中心技能功用初步构成的阶段，规划之初咱们给项目定下的要害准则是：
- Kubernetes 原生
OAM 运用模型不局限于 Kubernetes 生态，但是咱们挑选将 KubeVela 操控平面通过 Kubernetes 的插件（CRD）方式完结。一方面它充分利用了 Kubernetes 声明式 API 面向终态的规划理念，为用户带去易用性和确定性，便利用户装置和运用。
另一方面它也协助咱们利用 Kubernetes 的 API 生态，快速完结了诸如 Helm 交给、弹性扩缩容、服务网关、灰度发布等运用所需的中心才能，而 KubeVela 团队随后发布的**TerraformController项目 [ 3] **也证明了依据 Kubernetes 操控平面衔接云才能的可行性。
- 可扩展
KubeVela 依据 OAM 模型供给用户友爱的上层笼统，但这些笼统能够随时扩展以满意用户的各种需求。这给技能完结带来了很大的应战，但这也是一个十分重要的创新，它避免了 KubeVela 项目成为一个只能处理“最小公分母”问题的“鸡肋”项目。
- 可编程
在许多的可扩展性规划中，KubeVela 终究挑选了 Infra as Code(IaC)的可编程扩展方法。由于这种扩展方法不只简略易用，还能够便利的模块化和插件化。这个挑选不只供给了扩展 KubeVela 的最佳方案，还为后来的插件商场等生态才能打下了基础。
围绕着这些准则，项目挑选依据**CUE装备言语 [ 4] **来作为动态编程才能的基石，KubeVela 1.0及前期版别给出了一个十分灵敏的 OAM 完结。但项目的演进也使得 KubeVela 及 OAM 模型与前期发布的版别构成了较为明显的差异，这里构成了一个不小的应战，即“开源项目的兼容性怎么确保”。
图 2：KubeVela 可编程可扩展的模块化规划？
继续迭代：坚持开源项目的兼容性
KubeVela 基本上便是在 OAM 社区的许多用户呼声下诞生的，那些前期参加奉献的工程师们，他们其实也一起是公司里边积极推动 OAM 落地的渠道构建者，他们不只供给了许多的建议和代码奉献，还通过自身的实际场景协助社区做验证。咱们知道一个新技能的推广，很重要的一点是在处理原有问题的一起，尽或许下降选用的本钱，也便是不引入新的问题。 所以当 KubeVela 发布的第一个版别的时分，咱们的前期选用者他们更多的是在做一个自身 OAM 实践的晋级，而不是运用一个全新的系统。同样地，在后续的项目迭代进程中，对兼容性的考量一向都放在首要的位置。
当 KubeVela 项目的第一阶段功用完结完结，并被开源社区逐渐选用的进程中。依据许多的用户反应和调研，咱们发现，除了基础的作业负载和运维需求之外，用户还会有诸如多集群高可用、资源共享、资源回收等运用办理战略的需求，而看似十分碎片化和杂乱的各类运用交给场景，其背后确实存在一个十分实质的模型，那便是“作业流”。咱们很快就开端一起演进 OAM 模型自身，而且在 KubeVela 完结了一个十分轻量级的作业流引擎。而“作业流”这个特性自身就又与 Kubernetes 和 GitOps 生态天然互补，KubeVela 的作业流进程能够恣意扩展，而声明式 API 面向终态的语义也能够很好的描述作业流的状况机，这使得 KubeVela 的作业流简直能够满意任何交给场景的需求，所以这个创新后来也成为了 KubeVela 被许多选用的“杀手锏”。
图 3：KubeVela 1.0发布后一向坚持功用以及模型层面的兼容性
当然这也会为技能方案的长时刻演进带来许多包袱和困难，所以咱们在随后也参加了项目功用的废弃机制，仅对少数不合理、且简直没有用户的功用做废弃，而且在正式废弃前提早两个版别做告诉。中心才能构成的进程中，咱们观察到用户增长并不满意预期。通过运营剖析，咱们发现无论是 Github 仍是官网，初度拜访流量是比较大的，但实际转化数据不太抱负。此时咱们意识到项目的运用体会或许不尽如人意，而社区用户的运用和反应是驱动咱们项目继续增长的重要输入。
用户转化：重视易用性和初次体会
KubeVela 的理念是业界领先的，所以咱们一向在做许多布道，许多用户被咱们招引过来。但是许多用户反应说，看了 KubeVela 项目官网，看不懂这个项目是做什么的。此时咱们意识到，项目的易用性出了问题。咱们把自己从项目保护者的身份中走出来，开端作为用户审视这个项目，关于初次接触项目的新用户，咱们问自己三个问题：
- 第一个问题：我能一会儿看了解项目处理的是什么问题吗？
KubeVela 项目自身是有必定的了解门槛的，它树立在 OAM 运用模型之上，OAM 模型关注点分离的中心思路又把渠道的用户分成了渠道的构建者和终究用户，这给直接接触 KubeVela 的用户带来了不小的认知本钱。在 1.0到 1.5 这挨近一年的时刻中，咱们每次发版都会依据用户的反应继续重构咱们官网的文档，以广阔用户最能产生共鸣的要害词、场景进行类比，一起也一向在做减法，将项目的高档功用藏到相对较深的位置。
另一方面，咱们在产品完结上也继续明晰方针用户集体，将 KubeVela 操控器中心定位给渠道工程师，而开发的 VelaUX 子项目初始定位是事务开发者开箱即用，一起也为渠道工程师结构企业渠道供给参阅和基础结构。通过明晰定位的产品培育用户心智，进而将越来越多要害信息传达给社区用户，再通过用户社群继续影响更广泛的生态。
- 第二个问题：我能一会儿联想到我的场景是否能够用它吗，或许它能满意我的需求吗？
用户的注意力是有限的，通过对官网的用户拜访数据进行剖析，咱们发现新用户在网站的均匀驻留时刻不超越 3 分钟，怎么在有限的时刻里迅速捉住方针用户的兴趣，文档结构的规划十分重要。通过对社区用户的许多访谈，咱们意识到大多数用户会带着需求要害词来寻找项目，所以们不断调整官网侧边栏目录，把项目能够完结的中心功用以用户熟悉的要害词表现到导航目录中便利用户快速匹配。
除了项目文档，另一个要害点是提炼用户事例，职业头部用户事例具有很强的带动作用。有一段时刻抱负轿车率先选用了 KubeVela，没多久就看到了小鹏轿车的选用，甚至在不久前，自动驾驶范畴的巨子 Aurora 也在 Slack 上联络咱们，方案全公司选用 KubeVela，而招商银行的事例也带动了一大批金融职业的用户选用 KubeVela。当然这些事例的堆集是一个小火慢炖的进程，很难一蹴即至。 这不只需求项目的保护者关于社区用户有满意的耐性，也需求站在开源项目背后支撑项目开展的公司有满意的远见， 咱们十分感谢阿里云、招商银行、Napptive等公司的保护者们继续而坚决的投入。
- 第三个问题：我想试一下项目的实际运行作用，我能在几分钟只能快速体会完好的 Demo 吗？
这个问题其实涉及到了开源项目的一个要害特色，那便是开源项目必须能够用户自助，即用户要有才能自发的装置、运用、运维，以及在社群进行传达。假如一个开源项目是大多数用户自己玩不起来的，那注定难以成功。所以咱们在每次发版时都会检查以下两项：
-
大多数用户能否顺畅进行装置？关于国际化运作的 KubeVela 项目来说，咱们需求协助用户客服网络妨碍，不管是拜访文档仍是下载装置都需求在国内外流畅进行；为了下降装置杂乱度，咱们甚至专门建议了一个叫**VelaD [ 5] **的项目，协助用户从单机一键离线拉起包含 Kubernetes 在内的完好体会环境，大大下降了用户的上手门槛。除此之外，还有包含 ARM 架构镜像支撑、版别晋级一键完结等体会优化。
-
第一个用例是否满意简略又充分说明项目特性？KubeVela 前期的第一个用例要么过于简略看不出功用特色，要么过于杂乱没有多个集群都跑不起来。通过继续打磨，现在的第一个用例围绕着中心概念，表现了作业负载笼统、交给战略、多集群、作业流等中心才能，但对用户环境又无额外要求。
图 4：VelaD 全离线一键装置包含 Kubernetes 集群在内的完好环境
逐渐成熟：产品化运作和社区用户
跟着项目的逐渐成熟，社区会迎来一批又一批的用户，而开源项目成功的中心便是许多的用户选用。KubeVela 很幸运，一向有阿里巴巴内部许多的场景能够协助打磨孵化，而咱们也十分重视社区用户的需求。除了每周定时举行国内外社区会议，还会组织跟不同企业的点对点沟通会，甚至协助他们制定完好的渠道架构。而这个进程的堆集也是相互的，KubeVela 保护团队从各行各业的头部企业中了解了职业的现状和差异化痛点，得以从更广阔的视界做功用的规划。
在社区用户的进程中，咱们也总结了一些要害经验：
-
怎么给到开源用户安全感？ 关于基础设施类的开源项目，一旦选用就会成为企业界部中心架构的一部分，比较于企业界部自建，选用开源往往会缺乏一些安全感，开源项目自身怎么给到企业安全感至关重要。首要是项目保护团队的多样化、长时刻安稳性以及高活泼，KubeVela 是 CNCF 保管的孵化项目，背后有阿里云、招商银行、Napptive 等多个公司在继续保护。一起要继续对代码质量坚持较高的要求、重视安全问题和安稳性，KubeVela 有 40多项继续集成测验条目，总体测验覆盖率超越 60%，中心场景的覆盖率在 90%以上，基本上每个合并的代码都能确保兼容性，一起对代码奉献者自身的才能也有较高的要求。而团队对安全问题的上报和安稳性问题也一向坚持高度敏感，一旦发现会第一时刻发布修正版别。最后是供给确定性，有明晰的里程碑、发版方案 ，而且坚决的履行。 KubeVela 发布至今每隔 2-3 个月发布一次大版别，每隔 1-2 周发布一个小版别，社区一向坚持极高的活泼度，至今已经发布了超越 150个版别，每个版别都有明晰的变更文档。
-
怎么平衡社区用户的小众需求？ 社区用户在落地进程中由于场景的差异，必然会产生相对小众的需求。关于这一点，咱们的战略是 Blocker Issue 优先，即假如由于一些功用设定和完结直接阻止了场景落地，那么这类问题要第一时刻处理。关于功用新增类的需求，则交由社区一同评价等待更多的反应，确认是一个相对遍及的需求再参加到版别方案中。例如 KubeVela 前期有一些用户期望对接他们企业界部的一致认证渠道，这或许并不是标准的协议方式，通过社区 Issue 的来会评论，有奉献者指出选用了 Dex 作为企业单点登录的一致方法，不同企业自行对接 Dex 即可。这使得项目能够齐心协力，着眼于长远开展。
3. 怎么获得海外用户？ 基础设施范畴的开源项目，要想获得真正意义上的成功，怎么翻开国际化商场是一个绕不开的话题。一方面，项目自身要一向着眼于范畴的最前沿，坚持技能的先进性，聆听国外用户的运用场景和习气，对技能开展趋势做出敏锐的判别。另一方面，KubeVela 的中心团队均在国内，也克服了包含时差、言语、文化在内的诸多客观困难，一向坚持在北美相对合适的时刻举行社区会议，继续在 KubeCon 等各类海外大会布道，文档、文章一向用中英文双语发布，一起积极活泼在 Slack、Issue 中答疑，满意国外用户期望点对点沟通沟通的诉求。这不只需求项目保护者有较强的归纳实力，也需求对项目真正的热爱。 团队也在积极培育海外奉献者，跟着 KubeVela 生态的不断繁荣，Napptive、Guidewire 等企业合作伙伴也在陆续参加社区，一起承担项目保护的职责。
图 5：OAM/KubeVela 风雨无阻的国外社区会议
生态建设与社区运营
最后咱们要谈一谈社区生态，由于做好一个开源项目绝不只仅是做一项前沿的技能，它更像是在方针范畴打造一款好的产品。除了打磨产品功用，咱们还需求通过对项目继续运营、对社区管理，得到更多开发者的认可，让他们参加进来奉献。要完结这样的方针，就需求让开发者对 KubeVela 构成共识、主动参加并参加协作。
KubeVela 诞生于 OAM 社区，也是第一个将“以运用为中心”的规划理念落地的项目。因而前期，咱们首要要让咱们了解 OAM 模型的思想，咱们才会有意愿开端了解 KubeVela 是什么。咱们做了许多的布道，并联合 CNCF 发布业界首个“云原生技能公开课”，介绍 OAM“以运用为中心”的理念怎么处理云原生时代运用开发问题，得到了越来越多开发者的共鸣。开展到 2021 年 5 月，阿里云联合信通院发布业界首个以 OAM 为中心的“云核算敞开架构”标准，将 OAM “模型”化虚为实，也对 KubeVela 开展起到要害作用。
为使社区坚持继续的生命力，2021 年 7 月，KubeVela 正式参加 CNCF ，项目受众也扩展至全球。咱们投入了许多精力做海外运营，比方联动 CNCF TAG App Delivery，以及 Argo、FluxCD、Prometheus、K3s 等生态伙伴举行社区会议、在干流的海外开发者社区树立团队账号，渐渐将影响力渗透到北美、日本、西班牙、英国等多个国家。为了让周边生态繁荣起来，以便能够让项目在更大的范畴得到广泛的传达，为此咱们专门树立了一个插件（Addon）系统，便利社区里的开发者能够将生态项目的集成，便利地制作成一个具有版别、一致库房、可发现、可分发、一键装置的插件包。
图 6：KubeVela 的插件生态
KubeVela 的技能很先进，社区的奉献者许多，但水平也有差异，为了确保项目的质量，又不打击奉献者的积极性。关于每一个代码提交，咱们都会及时呼应、充分沟通，给予奉献者满意的尊重和耐性。一起咱们会积极的弥补开发者文档，将开发者遇到的常见问题系统化整理。另一方面，咱们也树立了完善的开发者晋级机制，从组织的 member，到 reviewer、approver 最后到 maintainer，都有明晰的达到条件，让开发者像打怪晋级一样有成就感。
如今 KubeVela 奉献者已经遍布全球，地点的企业和组织超越70个。咱们倡导的理念是，开源奉献的方式不只是代码，一次分享、一次回答，都是对项目的奉献。咱们也在树立并逐渐完善社区晋升模型和协作机制，让咱们更标准、高效地参加社区。KubeVela 社区仍然十分年轻，还有许多事情在逐渐完善，很高兴有这么多朋友同行，让这个部队越来越强大。也等待更多朋友来到 KubeVela 社区感触开源的魅力。
相关链接
[1]KubeVela
kubevela.net/
[2]Helm/Kustomzie运用办理、多集群运用交给
www.infoq.cn/article/sbw…
[3] TerraformController项目
github.com/kubevela/te…
[4] CUE装备言语
cuelang.org/
[5] VelaD
github.com/kubevela/ve…
