在这个版本中,我们主要支持了平台级的插件和能力扩展。希望能通过外部插件扩展平台能力,实现微内核的效果;同时以后将会继续精简安装,能让用户按需扩展平台功能。在 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
感谢
流水线插件由 拓维信息 提供,感谢 丁鹏、刘进文、朱智阳 在社区中的贡献,才能使产品变得更好,我们欢迎大家任何形式的参与和贡献。
还没有评论,来说两句吧...