关于阿里云:KubeVela-v12-发布你要的图形化操作控制台-VelaUX-终于来了

作者：KubeVela 社区

随着云原生的一直倒退和成熟，越来越多的基础设施能力逐步标准化成为 PaaS 平台或者 SaaS 化产品。一个产品的诞生不再像过来那样须要建设一个团队，从开发、测试始终到运维、基础设施全局部多种角色零碎实现。现在，麻利组织文化和云原生技术驱动，使得这些职责更多的是“左移”到了开发者身上，测试左移、监控左移、平安左移，以及 DevOps 等一系列理念都是在强调，通过开源我的项目或者云的产品和服务将测试、监控、平安、运维等一系列事务提前到开发阶段实现。这看似美妙的愿景却给开发者带来了微小的挑战，开发者对底层形形色色的产品和简单 API 不足掌控力，他们不仅仅是在做抉择，更多的须要去了解和协调底层简单异构的基础设施能力，以便满足下层业务的疾速倒退和迭代需要。

这种复杂性和不确定性无疑大大降低了开发者的体验，升高了业务零碎的交付效率，减少了运维危险。开发者体验的外围是“简略”和“高效率”，不论是开发者还是企业都须要更好用的开发者工具或者平台来达成。在古代云原生技术之上打造一款帮忙开发者从开发、交付以及后续继续运维的一体化平台，始终是 KubeVela 演进的外围指标。如图 1 所示，在 v1.2 版本中，咱们围绕开发者体验新增了 UI 控制台组件（VelaUX），简化了编排 YAML 的复杂性，欠缺了插件体系建设，丰盛了云资源的扩大能力，减少了大量 CI/CD 等生态对接的能力，进一步欠缺了开发者端到端的应用体验。

图 1：KubeVela 架构设计

让咱们再来简略回顾一下 OAM 和 KubeVela 的倒退阶段和历程：

OAM（Open Application Model）诞生和成长

在简单的世界中要发明简略，首先咱们须要解决的问题就是形象和标准化。阿里云和微软联合推出 OAM 模型，创新性地提出“关注点拆散”的理念，开发者关注业务自身、运维关注模块化能力。OAM 模型围绕“所有皆服务，全面模块化”的思维，为各大厂商和云原生的平台构建者们实现本人的利用治理平台提供了简略易用与高度可扩大相结合的规范实际形式。该模型提出后的短短一年内便失去了包含 AWS、Oracle、腾讯、华为在内的国内外各大厂商响应，被国家信通院立项作为行业标准。因为大家有独特的指标，升高云原生的应用门槛，让利用交付和治理更简略。

KubeVela 开源我的项目 v1.0 公布，为社区带来了 OAM 的规范实现

有了 OAM 模型作为实际领导，社区高级玩家也开始发明本人的工具来实际，包含阿里、微软、Oracle、Upbond、腾讯在内的一系列公司都基于 OAM 的领导构建了本人的业务平台。但对于更宽广的开发者和中小型企业群体来说，他们却无奈间接享受模型带来的红利，于是，KubeVela 作为 OAM 社区的官网实现引擎诞生了。它从一开始就由 7 家来自不同组织的 OAM 社区成员从零到一构建。KubeVela 的实现排汇了多家公司针对 OAM 的实践经验，同时联合 Kubernetes 社区生态劣势，实现了自动化、可收敛、幂等且稳固的利用公布控制器，围绕 IaC（基础设施即配置）结构了用户敌对的形象层，帮忙开发者实现了开箱基于的 OAM 实现引擎。

KubeVela v1.1 公布，实现利用交付工作流，原生反对混合环境多集群利用交付

随着企业上云过程的推动，混合云、分布式云等多元化基础设施逐步成为常态。KubeVela 作为古代利用管理系统也顺应潮流，整体架构降级为面向混合环境做利用交付和治理的管制立体，将所有的性能人造构筑在多集群技术之上。咱们置信，出于高可用、老本性能、数据安全等多方面因素，将来大多数企业应用的状态都将是异构多元的。KubeVela v1.1 版本的公布，同时也实现了高度可扩大的利用公布工作流，它人造以混合环境架构出现，创新性的实现了交付工作流与利用形象相结合的工作模式，实现了面向终态的利用交付工作流，大大简化了流程编排的复杂性。

工夫来到 2022 年，KubeVela 也正式进入了第四个阶段，在原先外围控制器 API 根本稳固的根底上，咱们以插件的模式减少了一系列开箱即用的性能。让开发者能够通过 UI 控制台的形式，连贯 CI/CD 残缺流程，端到端公布多集群利用，进一步晋升开发者体验。

提供好用的图形化操作界面是升高开发者应用门槛的首选路径，从 KubeVela 诞生以来，社区对 UI 控制台的呼声始终很高。从 v1.2 版本开始，它正式到来了。打造 UI 控制台的目标是帮忙开发者以更标准化的形式组装和治理异构业务利用，帮忙他们剖析和更快的发现业务故障和妨碍。

VelaUX [1] 是 KubeVela 的前端我的项目，设计实现时它充分考虑了 KubeVela 的可扩展性这一外围要点。引入了低代码平台的理念来打造前端，咱们的指标是打造一个能够通过利落拽形式就能做到自定义利用交付输出参数，并且实现运行数据可观测的平台。为此咱们设计了前端形容标准（UISchema [2]），配合 KubeVela 的模块化定义（X-Definition [3]），通过配置就能够渲染出丰盛的前端交互元素。同时为了让前端的数据查问也配置化，咱们设计了多维数据自定义查询语言（VelaQL [4]），这样的设计造成了 KubeVela 交付和治理异构利用的根底。

目前通过 VelaUX，用户能够治理扩大，连贯 Kubernetes 集群，调配交付指标，布局环境和交付各类型利用，并观测利用运行状态，实现利用交付的残缺闭环。

图 2：VelaUX 预览

如图 2 所示，VelaUX 中呈现了一些新名词，请参考外围概念 [5] 文档进行学习和理解。

KubeVela 将 N 个 Kubernetes 集群，N 个云厂商服务或其余公有云服务对立为大的基础设施资源池。在此基础上，咱们的开发者能够依照业务需要、流程需要、团队需要等多种业务维度划分环境。在大资源池的根底上造成环境空间。同一个利用可公布到不同的环境，环境之间从治理到运行态齐全隔离。

图 3：多环境 / 多集群利用治理页面

如图 3 所示，利用可被公布到生产、测试、默认三个环境中，每一个环境能够包含多个交付指标，每一个交付指标背地能够是独立的 Kubernetes 集群。

在云原生体系中，咱们交付利用的模式抉择十分多。基于 Kubernetes 基础设施，咱们既能够通过成熟的 Helm Chart 包交付中间件和第三方开源利用，也能够通过镜像交付企业业务利用，还能够通过 OpenYurt 交付治理边缘利用。基于云服务商的凋谢能力，咱们能够交付数据库、音讯、缓存等中间件，也有日志、利用监控等运维能力。

对于这么多的可选项，KubeVela 采纳规范的 OAM 标准实现对异构利用的对立交付和治理。KubeVela 实现了高度可扩大的交付零碎，通过内置、社区共享等状态帮忙用户扩大平台，以统一化的交付和治理体验解决异构的利用。在 KubeVela 之上，开发者看到的都是模块化、所有皆服务的治理状态。

图 4：云服务利用治理页面

如图 4 所示，咱们能够看到，雷同的利用治理页面，用户能够十分便捷得获取到云服务利用。开发者能够通过浏览上面几篇文档查看异构利用的交付过程：

交付 Docker 镜像 [6]
交付 Helm Chart 包 [7]
交付 Kubernetes 资源 [8]
交付云服务 [9]

KubeVela 从一开始就是设计为一款微内核高可扩大的零碎，上文咱们说到异构利用，KubeVela 能够通过扩大体系，以标准化的状态，裁减有限的利用交付能力。既匹配企业差异性诉求，也不带来过多的认知累赘。KubeVela 中可扩大的点包含了组件类型、运维能力、工作流类型、利用交付策略等。在以后版本中，咱们公布了 Addon 扩大体系。Addon 是组织各种扩大能力的承载体，它便于散发和治理。

图 5：KubeVela 插件治理页面

目前在官网仓库中曾经存在如图 5 所示的可用 Addon。同时在实验性仓库中咱们正在联结社区用户踊跃发明更多的扩大能力。当然，这里须要每一个社区开发者的积极参与。

截止到当初，KubeVela 曾经成长为一款可间接服务于宽广开发者的利用交付平台，那么企业哪些场景能够间接利用 KubeVela 呢？咱们整顿了以下几个常见场景：

在过往社区的交换中，咱们发现企业支流的研发体系都相似如图 6 所示的构造，他们应用云服务厂商提供的计算资源作为生产、演示环境。应用本人购买或历史遗留的服务器搭建开发、测试环境。如果业务有多区域或灾备需要，生产环境可能须要部署到多个区域或多云。

图 6：多集群利用实际架构

对于根底的 DevOps 流程，包含了代码托管和 CI/CD 的环节。KubeVela 目前为你提供 CD 环节的反对。对于企业实际的步骤如下：

依据理论状况筹备本地或云服务资源。至多单项买通本地和云资源的网络，便于资源集中管理。
将 KubeVela 零碎搭建在生产环境中，保障继续的可用性。
通过 KubeVela 部署 Gitlab、Jenkins、Sonar 等 DevOps 工具，并买通工具链。通常状况下，代码托管和开发工具的可用性至关重要，咱们须要将其部署在生产环境中（如果你本地机房具备生产可用性，且心愿代码数据在本地环境流转，可部署在本地机房）。
通过 KubeVela 布局本地开发环境，部署本地测试用中间件，布局生产环境和部署云服务中间件。
通过 Jenkins 搭建业务代码 CI 流水线，产出 Docker 镜像交由 KubeVela 进行多环境部署，造成残缺利用交付工作流。

联合 KubeVela 的多集群利用 DevOps 计划有如下劣势：

（1）开发者无需把握过多的 Kubernetes 生态常识，可实现异构利用云原生部署。

（2）多集群，多环境对立治理，原生可部署跨集群利用。

（3）对立的利用管理模式，无论是业务利用还是开发工具链。

（4）灵便的工作流，帮忙企业买通各种开发标准流程。

不同的企业往往都存在不一样的基础设施和业务诉求。在基础设施侧：企业可能搭建了公有云，可能购买了私有云，可能还有边缘计算资源。在业务侧：不同的业务规模不同，资源需要不同，可能有多云多活利用，也有企业遗留零碎。在研发侧：业务研发往往须要开发、测试、预发和生产环境。在治理侧：不同的业务团队须要互相隔离，又可能须要业务互通。

随着工夫的累积，企业因为职责边界和不同分工的影响，会逐步造成不同业务团队互相独立甚至割裂的状态，这种割裂包含了：开发工具割裂，技术架构割裂，业务管理状态割裂。KubeVela 秉持着“尊重事实，踊跃翻新”的准则，带来的计划是谋求对立的过程中用高扩大的能力去兼容差异性。

面对基础设施差别，咱们反对以 Kubernetes API、云服务 API 或其余自定义 API 的状态，去对基础设施进行充沛的模型化。最终通过对立的 OAM 模型向上裸露统一的概念。
面对业务架构差别，利用模型是凋谢的，对架构无要求的。KubeVela 做的是连贯和赋能，连贯已有零碎，通过扩大机制加持新的生态技术。
面对开发工具链的差别，企业中可能曾经存在不同的开发工具链，产出不同的业务制品。KubeVela 通过扩大和规范模型去反对各类制品，实现其标准化交付。当然，它的规范逐渐衍生到前置环节，帮忙企业逐渐实现工具链统一化。因而，你不必放心你是用的 Gitlab 还是 Jenkins，它都能对接。
面对运维能力差异，企业中不同团队的运维能力、工具计划能够在 KubeVela 的标准下逐渐积攒，能力互通。更多运维能力也同样在社区的维度进行共享和复用。

因而，应用 KubeVela 来作为企业买通业务，进行对立能力建设的根底平台，它是可落地、有将来的计划。

从 Heroku、Cloud Foundry 时代开始，市场上始终在产生不同的 PaaS 平台，咱们都晓得固定模式的公布平台往往不适宜所有的企业。举个例子，某些规范化程度较高的企业，他们基于业务的个性，公布利用时仅需更新镜像名称，然而应用通用 PaaS 就不得不去了解大量的概念和参数。再比方某个企业生产的是 AI 利用，对于 AI 利用的公布与一般利用有比拟大的区别，这时就须要定制 AI 场景的 PaaS，企业不得不付更多的费用和学习更多的概念。

通用产品不合乎企业需要时，自研是实在存在的诉求。然而对于从零开始自研平台，必然又须要投入大量的人力物力，甚至超过了企业外围业务的投入，这显得得失相当。KubeVela 也思考到了具备自研能力企业的独特诉求，他们能够基于 KubeVela 微内核、高可扩大的设计，针对本人的业务场景和畛域常识，打造属于本人的、更为简略易用的业务平台。

对于须要自研发布平台的企业来说，KubeVela 的微内核是一个 PaaS 平台研发框架。一方面，企业能够依据本人的需要自研或者装置社区的各种性能插件；另一方面，企业也能够基于 OAM 模型批改模块化配置，新增或裁剪用户应用的参数。这种模块化的设计能够大大降低企业的投入老本，同时能够跟上社区的倒退潮流，随时将社区更多的先进技术转化为本身的生产力。

做了这么多的介绍，你是否对 KubeVela 的倒退有了一些新的意识，没有哪个产品是相对的银弹，也没有一个计划能够解决所有的问题。然而咱们的现实是能够发明一个标准化模式，让更多的企业和开发者用户参加到这场为了“简略”和“高效”的开发者体验战斗中来。KubeVela 还很年老，咱们心愿你能够参加进来独特打造。这里非常感谢在过来参加 KubeVela 奉献的 100 多位开发者 [10]，正是因为你们的携手致力，才让咱们的社区生态变得更加凋敝。

对于 OAM 利用标准，模型的更新和降级基于 KubeVela 实际驱动，然而它并不绑定 KubeVela 实现。它是 KubeVela 在云原生利用交付和治理层面实践经验的总结和形象，是发明规范化利用管理体系的最佳实际和核心理念。咱们十分欢送云厂商、平台厂商、最终用户能够参加进来，同时咱们也欣慰的看到国内包含腾讯在内的多家厂商对 OAM 利用标准的关注和反对。任何人、组织都能够发表你的想法、倡议和思考。

参加 OAM 模型探讨：

https://github.com/oam-dev/spec

如上文介绍的一样，咱们曾经开启了 Addon 的扩大体系，十分欢送社区的创造者、开发者能够来奉献更多的扩大能力。

如何扩大和奉献 Addon 参考文档：

https://kubevela.net/zh/docs/platform-engineers/addon/intro

KubeVela 通过集成 Terraform Module 来扩大云服务集成能力，咱们曾经反对了罕用的云资源 [ 11]，欢送社区敌人参考并奉献更多的云服务厂商和产品。

如何扩大和奉献云资源参考文档：

https://kubevela.net/zh/docs/platform-engineers/components/component-terraform

或者你是一般开发者，也或者你是云原生畛域的从业者，如果你认可咱们的方向，认可咱们正在做的事件，咱们十分欢送你能够参加到 KubeVela 社区探讨中来。

社区探讨：

https://github.com/oam-dev/kubevela

KubeVela 的官网文档托管在 GitHub（[https://github.com/oam-dev/ku…]()）上，如果你发现有任何错漏或者想要参加翻译，欢送间接到我的项目中奉献。同时为了国内用户能够减速拜访，咱们减少了 kubevela.net 这个域名，能够不便国内用户更快的拜访，内容与 kubevela.io 的域名完全一致、实时同步。

KubeVela 是 CNCF 沙箱我的项目，理解更多信息，请点击

此处查阅官网文档。

[1] VelaUX：

[](https://github.com/oam-dev/ve…)

https://github.com/oam-dev/ve…

[2] UISchema：

[](https://kubevela.io/zh/docs/r…)

https://kubevela.io/zh/docs/r…

[3] X-Definition：