Rainbond 插件机制设计

[yangkaa]

目的

1. 实现微内核，平台完整功能通过插件扩展，便于开源生态扩展
2. 通过插件体系，开发者方便共享代码
3. 精简安装，按需扩展功能
4. 支持 K8s 中一些能力的扩展或编辑

设计思路

当前可以规划的插件大概有大屏系统、监控系统、工作流、安全类系统或源码构建系统。

插件设计当前会有以下两种思路：

1. UI 扩展、后端接口扩展。即 UI 和后端接口都提供可扩展的方式。开发插件时可以自定义 UI 和后端接口，优势是灵活性极高，能满足用户对 UI 的一些定制化，但是开发难度高，无法复用已有的体系。
2. 将插件作为一种特殊类型的应用进行部署，平台识别到后统一查看管理。优势是能尽可能的复用我们应用市场。对于用户制作，也可以复用已有的应用市场能力。

扩展能力主要是指如何能复用已有的 Kubernetes 上的一些能力，实现功能的扩充，可以理解为能力是 K8s 中标准实现，通过平台能直接编辑，与集群资源同步。

最终效果

1. 插件统一存放到应用市场，可以从应用市场安装和升级

2. 有插件配置页面

   • 用户自行实现插件发布后，可以在平台被识别出来
   • 被识别出来的插件，可以通过界面进行查看
   • 官方实现的插件安装后可以触发平台对应页面，或支持进行配置二级菜单

3. 支持多种 ServiceMesh 框架的注入和使用。支持用户使用自己的 GatewayAPI 实现，支持用户自定义想要直接在平台上编辑的能力。

业务流程

插件

用户安装插件，分为官方插件/非官方插件：官方插件会在UI上展示隐藏入口；非官方插件则不会。

1. 用户在应用级别管理插件的各类参数配置
2. 用户在平台管理页面，全局管理各个集群下的插件信息，可以跳转到应用下或者直接访问

扩展能力

平台管理员在集群中部署 CRD 资源（定义Rainbond 需要 Watch 的资源类型），控制台可以看到对应资源组的全部资源。

如果 Watch 到的资源类型与平台集成，则可以在页面上配置对应的参数。如应用治理模式、GatewayClass等资源。

如果不能与平台集成，那么在该页面只能直接编辑 yaml 文件修改。

技术实现

插件

1. 用户安装插件以后，会创建出两类资源：
   • Rainbond应用模版：插件本身就是一个应用，该应用提供完整能力
   • RainbondPluginCR：Rainbond 的插件定义 CR 资源，主要包括插件的元数据（用于页面展示）、插件类型（可根据平台功能进行拆分，如构建类型插件【平台构建组件】、展示类型插件【大屏】等）、插件作者信息等
2. Console 会调用 rbd-api 的接口，获取当前可用的插件资源以及安装状态。插件资源只有安装了才会在页面显示。插件需要分集群展示，通过切换集群，可以看到某个集群内拥有的插件。部署多套时，插件会展示多个。

apiVersion: rainbond.io/v1alpha1
kind: RainbondPlugin
spec:
  name: large-screen
  description: This is Linkerd Plugin
  pluginType: Monitor # Custom
  author: "goodrain"

扩展能力

1. 用户可以自己在集群中创建 RainbondAbilityCR 资源，该资源可以定义需要 Watch 的资源类型。
2. 控制台会去查询所有 RainbondAbilityCR 中需要 Watch 的资源，在扩展能力处展示出来相关资源，此处资源和 K8s 集群同步，可以进行修改操作。不允许删除。

ServiceMesh能力的使用

apiVersion: rainbond.io/v1alpha1
kind: RainbondAbility
spec:
  name: ServiceMesh
  description: "xxxxx"
  watchGroups:
    - apiVersion: rainbond.io/v1alpha1
      kind: RBDServiceMesh

apiVersion: rainbond.io/v1alpha1
kind: RBDServiceMesh
spec:
  name: linkerd
  description: "xxxxx"
  inject:
    - method: label # label/annotation
      key: istio/enable-sidecar
      value: "true"

需要两类CRD资源，RainbondAbility 和 RainbondServiceMesh。

1. 可以在 RainbondServiceMesh CR 资源中定义 ServiceMesh 框架的注入方式以及描述。
2. RainbondAbility 定义需要 watch RainbondServiceMesh 资源，这样第一步创建出来的资源即可在页面中编辑，同时能触发控制台治理模式切换功能。

GatewayAPI能力的使用

1. 部署 RainbondAbility 资源，定义需要 watch 的资源类型，平台管理-能力就会列出 GatewayClass 所有资源，eg: envoy

   apiVersion: rainbond.io/v1alpha1
   kind: RainbondAbility
   spec:
   name: gateway
   description: "xxxxx"
   watchGroups:
   - apiVersion: gateway.networking.k8s.io/v1beta1
     kind: GatewayClass

2. 用户在集群中安装 envoy Gateway，此时会生成 gatewayClass 资源
3. 用户在网关页面，添加策略时，可以选择对应的 网关实现，选择 envoy。参数只支持标准的 Gateway HttpRoute 、TCPRoute 。
4. 当应用运行起来后，生成的资源类型不再是 ingress，而是 Gateway 和 HttpRoute 资源。

插件规划

• [ ] 插件基础框架
• [ ] 功能扩展
  • [ ] 流水线
  • [ ] CI能力扩展
  • [ ] 自动测试
  • [ ] 代码静态检查
  • [ ] CD能力扩展
  • [ ] 金丝雀发布/AB测试
  • [ ] 流程审核
• [ ] 可观测能力扩展插件
  • [ ] 收集插件
  • [ ] 展示插件
• [ ] Service Mesh框架插件
  • [ ] Linkerd
  • [ ] dapr
  • [ ] 其他支持Sidecar注入的治理框架
• [ ] 网关插件
  • [ ] Higress
  • [ ] Envoy Gateway
  • [ ] 其他支持Gateway API的实现
• [ ] 设备插件（以DeamonSet的方式运行）
  • [ ] GPU
  • [ ] 其他需要跟硬件结合的驱动
• [ ] Cloud provider（通过API自动对接云平台）
  • [ ] 阿里云 ACK
  • [ ] 华为云 CCE
• [ ] Workload类型扩展插件(在现有应用模型上支持扩展)
  • [ ] Knative
  • [ ] Volcano
• [ ] 边缘计算支持（安装/对接/应用分发特殊支持）
  • [ ] kubedge
  • [ ] SuperEdge
• [ ] 安全和策略插件（扩展安全能力）
• [ ] 存储插件（对接存储的能力）

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

Title: Rainbond plug-in mechanism design

Purpose

1. Realize the microkernel, and the complete functions of the platform can be extended through plug-ins, which is convenient for open source ecological expansion
2. Through the plug-in system, developers can easily share code
3. Simplified installation, expand functions on demand
4. Support the expansion or editing of some capabilities in K8s

Design ideas

Currently, the plug-ins that can be planned include large-screen system, monitoring system, workflow, security system or source code construction system.

There are currently two ideas for plug-in design:

1. UI extension, backend interface extension. That is, both the UI and the backend interface provide an extensible way. When developing a plug-in, you can customize the UI and back-end interface. The advantage is that it is extremely flexible and can meet some customizations of the UI by users. However, the development is difficult and the existing system cannot be reused.
2. Deploy the plug-in as a special type of application, and view and manage it uniformly after the platform recognizes it. The advantage is that we can reuse our application market as much as possible. For user production, existing application market capabilities can also be reused.

Expansion capability mainly refers to how to reuse some existing Kubernetes capabilities to achieve functional expansion. It can be understood that capabilities are standard implementations in K8s, can be directly edited through the platform, and synchronized with cluster resources.

final effect

1. Plug-ins are uniformly stored in the application market, and can be installed and upgraded from the application market

2. There is a plug-in configuration page

   • After the user implements the plug-in release, it can be recognized on the platform
   • The identified plug-ins can be viewed through the interface
   • After the official plug-in is installed, it can trigger the corresponding page of the platform, or support the configuration of the secondary menu

3. Support the injection and use of various ServiceMesh frameworks. Support users to use their own GatewayAPI implementation, and support users to customize the ability to edit directly on the platform.

Business Process

Plugins

Plug-ins installed by users are divided into official plug-ins/unofficial plug-ins: official plug-ins will display hidden entrances on the UI; unofficial plug-ins will not.

1. Users manage various parameter configurations of plug-ins at the application level
2. On the platform management page, the user can globally manage the plug-in information under each cluster, and can jump to the application or directly access

Extendability

The platform administrator deploys CRD resources in the cluster (defining the resource types that Rainbond needs to watch), and the console can see all the resources of the corresponding resource group.

If the watched resource type is integrated with the platform, you can configure the corresponding parameters on the page. Such as application governance mode, GatewayClass and other resources.

If it cannot be integrated with the platform, you can only edit the yaml file directly on this page.

Technical realization

Plugins

1. After the user installs the plug-in, two types of resources will be created:
   • Rainbond application template: the plugin itself is an application that provides complete capabilities
   • RainbondPluginCR: Rainbond's plug-in defines CR resources, mainly including plug-in metadata (for page display), plug-in type (which can be split according to platform functions, such as construction type plug-ins [platform construction components], display type plug-ins [big screen ], etc.), plug-in author information, etc.
2. The Console will call the rbd-api interface to obtain the currently available plug-in resources and installation status. Plug-in resources will only be displayed on the page if they are installed. Plugins need to be displayed in clusters. By switching clusters, you can see the plugins in a certain cluster. When deploying multiple sets, the plugin will display multiple.

apiVersion: rainbow.io/v1alpha1
kind: RainbowPlugin
spec:
  name: large-screen
  description: This is Linkerd Plugin
  pluginType: Monitor # Custom
  author: "goodrain"

Extendability

1. Users can create a RainbondAbilityCR resource in the cluster by themselves, which can define resource types that require Watch.
2. The console will query all the resources in RainbowdAbilityCR that need to be Watched, and display the relevant resources in the extension capability. Here, the resources are synchronized with the K8s cluster and can be modified. Deletion is not allowed.

Use of ServiceMesh capabilities

apiVersion: rainbow.io/v1alpha1
kind: Rainbow Ability
spec:
  name: ServiceMesh
  description: "xxxxx"
  watchGroups:
    - apiVersion: rainbow.io/v1alpha1
      kind: RBDServiceMesh

apiVersion: rainbow.io/v1alpha1
kind: RBDServiceMesh
spec:
  name: linkerd
  description: "xxxxx"
  inject:
    - method: label # label/annotation
      key: istio/enable-sidecar
      value: "true"

Two types of CRD resources are required, RainbondAbility and RainbondServiceMesh.

1. The injection method and description of the ServiceMesh framework can be defined in the RainbondServiceMesh CR resource.
2. The RainbowAbility definition needs to watch the RainbowServiceMesh resource, so that the resource created in the first step can be edited on the page, and at the same time, it can trigger the console management mode switching function.

Use of GatewayAPI capabilities

1. Deploy the RainbondAbility resource, define the resource type that needs to be watched, and platform management-ability will list all the resources of GatewayClass, eg: envoy

   apiVersion: rainbow.io/v1alpha1
   kind: Rainbow Ability
   spec:
   name: gateway
   description: "xxxxx"
   watchGroups:
   - apiVersion: gateway.networking.k8s.io/v1beta1
     kind: GatewayClass

2. The user installs envoy Gateway in the cluster, and a gatewayClass resource will be generated at this time
3. On the gateway page, when adding a policy, the user can select the corresponding gateway implementation and select envoy. The parameters only support standard Gateway HttpRoute and TCPRoute.
4. When the application is running, the generated resource type is no longer ingress, but Gateway and HttpRoute resources.

Plug-in planning

• [ ] Plugin base framework
• [ ] function extension
  • [ ] pipeline
  • [ ] CI capability expansion
  • [ ] automatic testing
  • [ ] Code static checking
  • [ ] CD ability expansion
  • [ ] Canary release/AB test
  • [ ] Process review
• [ ] Observability extension
  • [ ] Collect plugins
  • [ ] display plugin
• [ ] Service Mesh framework plugin
  • [ ] Linkerd
  • [ ] dapr
  • [ ] Other governance frameworks that support sidecar injection
• [ ] Gateway plugin
  • [ ] Higress
  • [ ] Envoy Gateway
  • [ ] Other implementations that support the Gateway API
• [ ] Device plugin (run as DeamonSet)
  • [ ] GPU
  • [ ] Other drivers that need to be combined with hardware
• [ ] Cloud provider (automatically connect to cloud platform through API)
  • [ ] Alibaba Cloud ACK
  • [ ] HUAWEI CLOUD CCE
• [ ] Workload type extension plug-in (support extension on existing application model)
  • [ ] Knative
  • [ ] Volcano
• [ ] Edge computing support (special support for installation/docking/application distribution)
  • [ ] kubedge
  • [ ] SuperEdge
• [ ] Security and policy plugins (extended security capabilities)
• [ ] Storage plug-in (ability to connect to storage)