In this version, we mainly support platform-level plug-ins and capability extensions. It is hoped that the platform capabilities can be expanded through external plug-ins to achieve the effect of the microkernel; at the same time, the installation will continue to be streamlined in the future, allowing users to expand platform functions as needed. In terms of Kubernetes compatibility, we also expose corresponding resources through platform-level capabilities and hand them over to users for processing.
overview
In the previous version, users would initially rely on the functions of the platform to simplify management, but when it comes to advanced usage scenarios, it is possible that the existing functions of the platform cannot meet the needs of users. At this time, the mechanism for extending platform capabilities to users is Very important. If the entire underlying platform is upgraded in order to expand platform functions, it will face challenges of complexity and stability.
At the same time, because Rainbond mainly abstracts at the application layer, some capabilities provided by clusters in Kubernetes cannot be displayed on the platform, and capabilities such as StorageClass and GatewayAPI cannot be directly managed on the platform. In order to provide users with more advanced functions, we have done a lot of work on Kubernetes ecological compatibility in previous versions, such as application-level K8s resource creation, component-level K8s attribute configuration, etc.
And after version 5.12, we will expand the platform's functions through Rainbond's plug-in system. There are two concepts here, platform-level plug-ins and capabilities.
Plugins:
The plug-in in Rainbond actually corresponds to the application in the application market, but the application contains the metadata definition of the plug-in (defined by the CRD resource), so that when the user installs the plug-in, the information of the plug-in can be obtained in and can 平台管理-扩展-插件be Quickly jump to the app for management. In this way, the existing application store system can be used to realize the distribution and management of the platform plug-in system.
Typically, a plugin consists of the following:
- A functioning application: The application is a complete implementation of the plugin and works even when deployed alone.
- Plug-in description file (CRD): This file mainly defines the basic information of the plug-in, such as name, description, version, author, etc.
- Capability description file (CRD): This file mainly defines which capabilities the plug-in can provide, and all implementations of the capabilities will be displayed in this K8s cluster. If the ServiceMesh type plug-in provides the application management capability, then when installing this type of plug-in, it will list the capability resources it can provide.
After installing the plug-in in this way, we can know the capabilities provided by the current k8s cluster at a glance, such as various ServiceMesh frameworks that support application governance, different GatewayAPI implementations, different storage capabilities, and so on.
ability:
Capability expansion is mainly to display some capabilities provided by the bottom layer of Kubernetes to users. Through the CRD resource definition, some resources in the Kubernetes cluster are synchronized to the platform, and these resources can be quickly previewed and edited. If you define the storageClass in the cluster as the display of storage capabilities, you can preview and operate all storageClass resources here.
The plug-in can include the definition of resources such as capabilities, so that when the plug-in is installed, the capabilities that the plug-in can provide can be exposed at the same time and processed by the user. As shown below:
Why use plugins
For users, the experience of installing a plug-in is exactly the same as installing an application. So why use plugins at all? It can mainly be seen from the following points:
- Plug-ins can achieve global management. For enterprise administrators, they are more concerned about the capabilities provided by the platform, which can be seen at a glance. When only using applications, administrators cannot manage these applications that provide capabilities in a unified manner.
- Plug-ins can be installed on demand, decoupled from the platform, and will not be installed together with the platform, so that resources will not be occupied when the plug-in is not needed.
- Using the distribution system of the app store, plug-ins can be upgraded individually, and bug fixes will be more timely.
- Different plug-ins can provide platform users with different capabilities, such as GatewayAPI plug-ins, which can provide additional gateway capabilities for the platform; various ServiceMesh plug-ins, which can provide the platform with the ability to inject application governance models; various cloud services of cloud vendors , can provide storage capabilities for the platform and so on.
In the future, we will continue to release some platform-level plug-ins and capabilities, and distribute them through the application market for users to use. At present, there is a Rainbond Pipeline plug-in that can enrich the CI process of the platform. For specific usage reference documents: Pipeline usage documents
Detailed change points
new features
- Support platform-level plugins and capability extensions #1480
- Added a pipeline plug-in to expand the CI capability of the platform #1180
optimization function
- Support creating components through OpenAPI #1266
- Optimize Helm warehouse installation application logic #1570