Rainbond V5.12 版本发布，支持平台级插件和能力扩展

在这个版本中，我们主要支持了平台级的插件和能力扩展。希望能通过外部插件扩展平台能力，实现微内核的效果；同时以后将会继续精简安装，能让用户按需扩展平台功能。在 Kubernetes 兼容性这方面，我们也通过平台级的能力将对应资源暴露出来，交给用户处理。

概述

在之前的版本中，用户一开始会依赖于平台的功能简化管理，但到了高级使用场景，就有可能遇到平台当前已有的功能无法满足用户需求，此时给用户扩展平台能力的机制就非常重要。如果为了扩展平台功能，升级整个底层平台，将会面临复杂性和稳定性的挑战。

同时由于 Rainbond 主要在应用这一层进行抽象，所以对于 Kubernetes 中集群所提供的一些能力，并不能全部在平台上进行展示，如 StorageClass、GatewayAPI 等能力也无法在平台上直接进行管理。为了给用户提供更高级的功能，在之前的版本中，我们在 Kubernetes 生态的兼容性上做了许多工作，如应用级别的 K8s 资源创建、组件级的 K8s 属性配置等。

而在 5.12 版本以后，我们将通过 Rainbond 的插件体系扩展平台的功能。在这里有以下两个概念，平台级的插件和能力。

插件：

插件在 Rainbond 中其实对应的是应用市场中的应用，但是该应用包含插件的元数据定义（通过 CRD 资源定义），这样当用户安装该插件时，可以在平台管理-扩展-插件中获取到该插件的信息，并可以快速跳转到该应用进行管理。这样可以利用已有的应用商店体系，实现平台插件体系的分发和管理。

通常来说，一个插件包含以下内容：

1. 一个能正常运行的应用：这个应用是插件的完整实现，即使单独部署也可以正常进行工作。
2. 插件的描述文件（CRD）：这个文件主要定义了插件的基本信息、如名称、描述、版本、作者等。
3. 能力的描述文件（CRD）：这个文件主要定义了该插件可以提供哪些能力，在这个 K8s 集群中所有该能力的实现都会被展示出来。如 ServiceMesh 类型的插件提供了应用治理的能力，那么在安装这类插件时，将会列出其能够提供的能力资源。

这样安装插件后，我们就可以一目了然的知道当前 k8s 集群提供的能力，比如支持应用治理的各类 ServiceMesh 框架、不同的 GatewayAPI 实现，不同的存储能力等等。

能力：

能力扩展主要是将 Kubernetes 底层所提供的一些能力展示给用户。通过 CRD 资源定义，将 Kubernetes 集群中一些资源同步到平台内，可以快速预览和编辑这些资源。如定义集群中的 storageClass 作为存储能力的展现，那么就可以在这里预览到所有的 storageClass 资源并进行操作。

而插件中则可以包含能力这种资源的定义，这样在安装插件时，即可同时暴露出该插件可提供的能力，由用户处理。如下图所示：

为什么使用插件

对于用户而言，安装插件与安装应用的体验完全一致。那为什么还要使用插件呢？主要可以从以下几点来看：

1. 插件可以实现全局的管理，对于企业管理员而言，更关注于平台提供了哪些能力，这些都可以一目了然。而仅仅使用应用时，管理员无法对这些提供能力的应用做统一管理。
2. 插件可以按需安装，与平台解耦，不会与平台一起安装，这样不需要该插件时则不会占用资源。
3. 利用应用商店的分发体系，可以单独升级插件，Bug 修复也会更及时。
4. 不同的插件都可以为平台的用户提供不同的能力，如 GatewayAPI 插件，可以为平台提供额外网关的能力；各类 ServiceMesh 插件，可以为平台提供应用治理模式注入的能力；云厂商的各类云服务，可以为平台提供存储的能力等等。

后续我们也会继续发布一些平台级的插件和能力，通过应用市场进行分发，供用户使用。目前已有Rainbond Pipeline 插件可以丰富平台的 CI 流程，具体使用参考文档：Pipeline 使用文档

详细变更点

新增功能

• 支持平台级插件和能力扩展 #1480
• 新增流水线插件，扩充平台 CI 能力 #1180

优化功能

• 支持通过 OpenAPI 创建组件 #1266
• 优化 Helm 仓库安装应用逻辑 #1570

BUG 修复

• 修复Gitlab OAuth 仓库最多只显示20个仓库的问题 #1560
• 修复团队页面排序问题 #1571 #1274
• 修复 DockerCompose 放弃创建后，应用名重复的问题 #1573