广西城乡和住房建设厅网站,做网站广告语,wordpress用户id号,注册商标怎么注册商标作者#xff1a;孙健波、曾庆国
点击查看#xff1a;「开源人说」第五期《KubeVela#xff1a;一场向应用交付标准的冲锋》
2023 年 2 月#xff0c;**KubeVela [ 1] ** 经过全体 ToC 投票成功进入 CNCF Incubation#xff0c;是云原生领域首个晋级孵化的面向应用的交付…作者孙健波、曾庆国
点击查看「开源人说」第五期《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 则是这一层抽象的具体实现。 图 1KubeVela 是什么
明确的目标和定位不仅支撑了 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 模型与早期发布的版本形成了较为明显的差异这里形成了一个不小的挑战即“开源项目的兼容性如何保证”。 图 2KubeVela 可编程可扩展的模块化设计
持续迭代保持开源项目的兼容性
KubeVela 基本上就是在 OAM 社区的众多用户呼声下诞生的那些早期参与贡献的工程师们他们其实也同时是公司里面积极推进 OAM 落地的平台构建者他们不仅提供了大量的建议和代码贡献还通过自身的实际场景帮助社区做验证。我们知道一个新技术的推广很重要的一点是在解决原有问题的同时尽可能降低采纳的成本也就是不引入新的问题。 所以当 KubeVela 发布的第一个版本的时候我们的早期采纳者他们更多的是在做一个自身 OAM 实践的升级而不是使用一个全新的系统。同样地在后续的项目迭代过程中对兼容性的考量一直都放在首要的位置。
当 KubeVela 项目的第一阶段功能实现完成并被开源社区逐步采用的过程中。根据大量的用户反馈和调研我们发现除了基础的工作负载和运维需求之外用户还会有诸如多集群高可用、资源共享、资源回收等应用管理策略的需求而看似非常碎片化和复杂的各类应用交付场景其背后确实存在一个非常本质的模型那就是“工作流”。我们很快就开始同时演进 OAM 模型本身并且在 KubeVela 实现了一个非常轻量级的工作流引擎。而“工作流”这个特性本身就又与 Kubernetes 和 GitOps 生态天然互补KubeVela 的工作流步骤可以任意扩展而声明式 API 面向终态的语义也可以很好的描述工作流的状态机这使得 KubeVela 的工作流几乎可以满足任何交付场景的需要所以这个创新后来也成为了 KubeVela 被大量采用的“杀手锏”。 图 3KubeVela 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 早期的第一个用例要么过于简单看不出功能特点要么过于复杂没有多个集群都跑不起来。经过持续打磨现在的第一个用例围绕着核心概念体现了工作负载抽象、交付策略、多集群、工作流等核心能力但对用户环境又无额外要求。 图 4VelaD 全离线一键安装包括 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 等企业合作伙伴也在陆续加入社区共同承担项目维护的职责。 图 5OAM/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体系方便社区里的开发者可以将生态项目的集成方便地制作成一个具备版本、统一仓库、可发现、可分发、一键安装的插件包。 图 6KubeVela 的插件生态
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
