作者：孙健波、曾庆国
点击查看：「开源人说」第五期《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 团队随后公布的 Terraform Controller 我的项目 [ 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
https://kubevela.net/
[2] Helm/Kustomzie 利用治理、多集群利用交付
https://www.infoq.cn/article/sbwSX8ypxgID2-SB723K
[3] Terraform Controller 我的项目
https://github.com/kubevela/terraform-controller
[4] CUE 配置语言
https://cuelang.org/
[5] VelaD
https://github.com/kubevela/velad