在这个版别中，咱们首要支撑了渠道级的插件和才能扩展。希望能经过外部插件扩展渠道才能，完成微内核的效果；同时今后将会继续精简装置，能让用户按需扩展渠道功用。在 Kubernetes 兼容性这方面，咱们也经过渠道级的才能将对应资源露出出来，交给用户处理。
概述
在之前的版别中，用户一开始会依赖于渠道的功用简化办理，但到了高级运用场景，就有或许遇到渠道当时已有的功用无法满意用户需求，此时给用户扩展渠道才能的机制就非常重要。如果为了扩展渠道功用，升级整个底层渠道，将会面对复杂性和稳定性的挑战。
同时因为 Rainbond 首要在运用这一层进行笼统，所以关于 Kubernetes 中集群所供给的一些才能，并不能悉数在渠道上进行展示，如 StorageClass、GatewayAPI 等才能也无法在渠道上直接进行办理。为了给用户供给更高级的功用，在之前的版别中，咱们在 Kubernetes 生态的兼容性上做了许多工作，如运用等级的 K8s 资源创立、组件级的 K8s 属性配置等。
而在 5.12 版别今后，咱们将经过 Rainbond 的插件系统扩展渠道的功用。在这里有以下两个概念，渠道级的插件和才能。
插件：
插件在 Rainbond 中其实对应的是运用商场中的运用，但是该运用包括插件的元数据界说（经过 CRD 资源界说），这样当用户装置该插件时，能够在渠道办理-扩展-插件中获取到该插件的信息，并能够快速跳转到该运用进行办理。这样能够运用已有的运用商铺系统，完成渠道插件系统的分发和办理。
一般来说，一个插件包括以下内容：
- 一个能正常运转的运用：这个运用是插件的完好完成，即便独自布置也能够正常进行工作。
- 插件的描绘文件（CRD）：这个文件首要界说了插件的基本信息、如名称、描绘、版别、作者等。
- 才能的描绘文件（CRD）：这个文件首要界说了该插件能够供给哪些才能，在这个 K8s 集群中一切该才能的完成都会被展示出来。如 ServiceMesh 类型的插件供给了运用管理的才能，那么在装置这类插件时，将会列出其能够供给的才能资源。
这样装置插件后，咱们就能够一望而知的知道当时 k8s 集群供给的才能，比方支撑运用管理的各类 ServiceMesh 结构、不同的 GatewayAPI 完成，不同的存储才能等等。
才能：
才能扩展首要是将 Kubernetes 底层所供给的一些才能展示给用户。经过 CRD 资源界说，将 Kubernetes 集群中一些资源同步到渠道内，能够快速预览和编辑这些资源。如界说集群中的 storageClass 作为存储才能的展示，那么就能够在这里预览到一切的 storageClass 资源并进行操作。
而插件中则能够包括才能这种资源的界说，这样在装置插件时，即可同时露出出该插件可供给的才能，由用户处理。如下图所示：
为什么运用插件
关于用户而言，装置插件与装置运用的体会完全一致。那为什么还要运用插件呢？首要能够从以下几点来看：
- 插件能够完成大局的办理，关于企业办理员而言，更重视于渠道供给了哪些才能，这些都能够一望而知。而仅仅运用运用时，办理员无法对这些供给才能的运用做统一办理。
- 插件能够按需装置，与渠道解耦，不会与渠道一同装置，这样不需要该插件时则不会占用资源。
- 运用运用商铺的分发系统，能够独自升级插件，Bug 修正也会更及时。
- 不同的插件都能够为渠道的用户供给不同的才能，如 GatewayAPI 插件，能够为渠道供给额定网关的才能；各类 ServiceMesh 插件，能够为渠道供给运用管理形式注入的才能；云厂商的各类云服务，能够为渠道供给存储的才能等等。
后续咱们也会继续发布一些渠道级的插件和才能，经过运用商场进行分发，供用户运用。现在已有Rainbond Pipeline 插件能够丰富渠道的 CI 流程，详细运用参阅文档：Pipeline 运用文档
详细变更点
新增功用
- 支撑渠道级插件和才能扩展 #1480
- 新增流水线插件，扩充渠道 CI 才能 #1180
优化功用
- 支撑经过 OpenAPI 创立组件 #1266
- 优化 Helm 库房装置运用逻辑 #1570
BUG 修正
- 修正Gitlab OAuth 库房最多只显示20个库房的问题 #1560
- 修正团队页面排序问题 #1571 #1274
- 修正 DockerCompose 抛弃创立后，运用名重复的问题 #1573
