Rainbond 插件机制设计

[yangkaa]

Rainbond 插件机制设计

[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

4. 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)