OSPP2023-23aaf0425

[yikuaibro]

Describe what this PR does / why we need it

There are many scenarios in the control plane that require expansion, such as the parsing, conversion or application of some custom CRDs. The Go language itself does not have good support for the extension mechanism. After evaluating the plug-in solution's research results and project ideas, a multi-process solution based on communication was finally adopted, implemented using the go-plugin framework, and the outer layer was packaged to form a The set of infrastructure is highly reusable and can adapt to different plug-ins. Learn from other open source products that have used go-plugin, and create a plug-in mechanism that supports the extensibility of the control plane according to the needs of the control plane. This PR implements the control plane extensibility mechanism and builds a plug-in system.

Does this pull request fix one issue?

Fixes #46

Describe how you did it

Adopting the gRPC idea, a new plug-in process is started locally to provide corresponding method calling services for the main program. The plug-in process can provide scalable functions at different points in the main link configured by the control plane.

The request plug-in flow chart is as follows:

Describe how to verify it

To build the plug-in executable program, execute the make command in the plug-in directory and the corresponding file will be generated under plugin/assets. Currently, you can directly start the control plane to start the plug-in service, or you can ``go build main.goundermain/to test an already written Demo plug-in: Stream. This is a plugin that can be called in both directions. So how to write a simple plug-in? For exampleratelimit``` plugin

1. Write proto, generate grpc and pb code, mainly define the functional interface of the specific implementation of the plug-in. This example is the actual execution logic. For other examples, please see the examples in the pl/builtin directory and embed them into the go-plugin framework. That’s it.
2. The server construction method corresponding to the plug-in needs to be completed in the server directory, because the script executed by make scans this directory.
3. New plug-in types need to be added to func ServerPlugin in plugin/pl/plugin/plugin.go, for example:

   if ratelimitSvc, ok := svc.(ratelimit_plugin.RateLimit); ok {
   ratelimitServiceServer, err := ratelimit_plugin.NewRateLimitPluginServiceServer(ratelimitSvc)
   if err != nil {
       return err
   }
   plugins[builtin.RateLimitServicePluginSetName] = ratelimitServiceServer
   }

   By the way, there is currently no particularly good way to assert the plugin type here. Now that the basic plug-in building work is completed, you can expose the plug-in to the control plane according to the plug-in name and call it at the appropriate location.

   Special notes for reviews

[CLAassistant]

All committers have signed the CLA.

[codecov-commenter]

We're currently processing your upload. This comment will be updated when the results are available.

[LearningGp]

Thanks for contributing!