Shulou(Shulou.com)06/01 Report--

How to understand the Rainbond plug-in system design, I believe that many inexperienced people do not know what to do, so this paper summarizes the causes of the problem and solutions, through this article I hope you can solve this problem.

In the past few years, using containers to package and deploy code has become increasingly popular, and more and more enterprises have begun to test or have run micro-service architecture applications in the production environment. Begin to directly face and solve various problems in the evolution of distributed service architecture.

In this trend and environment, serverless PaaS * * Rainbond** has made a series of thoughts and attempts around the expansion, monitoring and governance of services, and the plug-in system is an important part of it.

The abstraction of Rainbond's plug-in system focuses on the business level of the platform, and the theoretical basis comes from Kubernetes's pod mechanism and part of the container concept. According to the business level of the platform, the kubernetes container choreography is abstracted and transformed into a user-friendly Rainbond plug-in product, which is convenient for users without understanding the principle of Kubernetes.

Design principle

The Rainbond plug-in architecture is designed to be easy to understand and easy to use:

Easy to understand

In the Rainbond plug-in system, the process of plug-in use is the process of combining the main container with containers such as init or sidecar. The principle is that the plug-in container is arranged into the pod of the main application in the form of a sidecar container (most), sharing the network and environment variables of the main application container, so it is possible to plug-in to achieve some additional functions, such as traffic analysis of the main application.

Pod

Pod is an instance of modular container service in Kubernetes, which is composed of one or more containers that share resources, including file system, kernel namespace, IP address and so on. It is the atomic unit scheduled in the Kubernetes cluster and implements flexible deployment and management patterns by providing a higher level of abstraction.

In the following snippet of Rainbond (www.rainbond.com) deployment pod description file, we can see that the pod contains two containers:394d2f238a603bf01eb5215e23237691 (primary container) and 22dc8b12aeaf417fa7bd6466c136b9f4 (secondary container), which are bundled together through the pod mechanism to complete the services provided by the server.

Kubectl describe pod-n b314b3e7e44e45a082a0d00e125e88bf b314b3e7e44e45a082a0d00e125e88bfContainers: 394d2f238a603bf01eb5215e23237691: Container ID: docker://44018fa19a268c1f9ea5b20e9793290cbd89b167bd1fc9017a04ecbd9606d379 Image: goodrain.me/tomcat:latest_gr237691 Image ID: docker-pullable://goodrain.me/tomcat@sha256:701d36cde0b55d07f59a65e525e258523aae46b033297f80b44b0b6c07fc0277 Port: 8080/TCP State: Running Started: Sun 21 Jan 2018 14:56:35 + 0800 Ready: True Restart Count: 0 Limits: cpu: 640m memory: 512Mi Requests: cpu: 120m memory: 512Mi 22dc8b12aeaf417fa7bd6466c136b9f4: Container ID: docker://4c8bd31c2ec2200ee323fb1abdd7b652544ce3d110b1621c36acab4bae434c77 Image: goodrain.me/tcm_20180117175939 Image ID: docker-pullable://goodrain.me/tcm_20180117175939 @ sha256:d2b20d7eec4da05d953fb7862b9c9ead76797ea5542bff4b93cf2bc98331d279 Port: State: Running Started: Sun 21 Jan 2018 14:56:36 + 0800 Ready: True Restart Count: 0 Limits: memory: 64Mi Requests: memory: 64Miinit container

A pod can encapsulate multiple containers in which the application runs; at the same time, pod can have one or more init containers, and the init container starts before the application container starts. If the init container of a pod fails to start and run, Kubernetes will restart the pod until the init container starts and runs successfully. Of course, we can set the pod restart Policy value to Never to prevent it from starting repeatedly.

Sidecar container

Taking advantage of the ability of containers in pod to share storage and networks, sidecar containers can be extended and enhanced to coexist with and work better with "primary" containers. In the above pod description file snippet, 22dc8b12aeaf417fa7bd6466c136b9f4 is a sidecar type container that is used to assist in analyzing some of the performance metrics of the main container.

Easy to use

The principle that Rainbond plug-in system is easy to use is reflected in the application of classes, binding use, unique variable scope and so on.

Class application

The Rainbond plug-in system designs a life cycle similar to the application for the plug-in, including creating, enabling, closing and other modes, which is consistent with the habits of Rainbond platform users to operate applications. At the same time, the Rainbond plug-in system simplifies plug-in creation types and supports creation based on docker image and dockerfile. It is easier to create plug-ins than to create applications.

The plug-in creation process is designed as follows:

It should be noted that when a plug-in version is fixed, its memory, version information, and plug-in variables can no longer be modified, and these elements only work on the current plug-in version. When you need to modify elements such as plug-in variables, rebuild the plug-in and repeat the creation process.

Bind to use

The process of creating and using plug-ins is relatively independent. Users can use plug-ins created under current tenants and other teams (or tenants) to share plug-ins with Cloud City (Rainbond will provide several plug-ins for users in the initial stage).

If users do not create their own plug-ins, they need to install the plug-ins that others share in Cloud City locally before using the plug-ins. This process stores the shared plug-in metadata under the user tenant, which is equivalent to the user "creating" the plug-in (there is no time-consuming build process).

After the creation is completed, users can set the plug-in specifically. At present, you can set variables and whether the plug-in takes effect (memory settings will be increased later to meet the memory requirements of additional features in the complex case of the main application). Memory limits will be limited when the pod is created, and plug-in variables take effect and real-time modifications will be described below.

Unique variable scope

The variables injected into the container are designed to have two types: common variables and plug-in variables.

The common variable is the variable of the main container. In order to enable the plug-in to participate in or even expand the function of the main application, the environment variable of the main application is injected into the plug-in container during the creation of the pod; the plug-in variable only acts inside the plug-in container to prevent the repetition and mixing of variables between plug-ins.

The working process of Rainbond plug-in system

Rainbond currently provides two plug-ins for performance analysis and service governance by default. For details, visit http://www.rainbond.com/docs/stable/user-app-docs/myapps/myapp-platform-plugin.html for more information.

Below we take the network agent plug-in as an example to introduce the working process of the Rainbond plug-in system.

Build generation of plug-ins

After the user fills in the relevant information about the plug-in, Rainbond will generate the plug-in creation task based on this information and send it to the Rainbond message component, and the task discoverer will process the task message. After the builder component of Rainbond accepts the task, the plug-in will be built to generate a plug-in container image. A plug-in container image corresponds to a build, associated with its corresponding features. In Rainbond, plug-ins will circulate as a built image. Similar to applications, plug-ins can also be shared in Rainbond and Cloud Market.

Plug-in is associated with the application and takes effect

Referring to the plug-in usage documentation, after clicking install in the application's plug-in tab, the latest version of the plug-in will be marked as associated with the application. Restart the application at this time, and the plug-in will be judged when the pod is created. If there is a plug-in, the main container and plug-in container will be included in the container list for PluginContainerCreate,pod.

Agent network

The network proxy plug-in, also known as servicemesh in Rainbond, is a feature enhancement container that shares the network with the master container in pod.

In order to complete its function, the network agent plug-in needs to fully proxy the network of the main container and take over the entrance and exit of the main container. The structure is shown in the figure:

Network agents are divided into two modes: egress network mode and ingress network mode.

Egress network mode

Egress network mode (in the diagram, accessing the tomcat application is the egress network mode). In the figure, service mesh2 plugin obtains the network information of tomcat application through discover_service, including listen ports,routers,endpoints and so on. This information is obtained by discover_service through the services and endpoints resources of the tomcat application in the watching kubernetes cluster. For discover_service API related, please see the related code https://github.com/goodrain/rainbond/blob/master/pkg/node/api/router/discoverRouter.go.

After the service mesh2 plugin obtains the required downstream application information, it begins to listen to the port of the local corresponding tomcat to proxy the request of the current application to access the tomcat, such as curl http://tomcat.

Why can the above request be proxied by a container in pod? This is because dns_service resolves regular domain names such as tomcat locally, while routing and load balancing are handed over to service mesh2 plugin, that is, the client load balancing mode.

Ingress network mode

The ingress network mode is similar to the egress mode (main container is the ingress network mode from the public network access in the diagram). The complexity lies in the forwarding of the port set by the current application user, which cannot listen to the same port as the main container due to local listening.

When dealing with this scenario, the listening port of service mesh2 plugin is transformed. When the plug-in is opened, a non-repetitive port port_outer1 is randomly generated for outer listening. Service mesh2 plugin continues to forward the original port of the master application. When generating service and pod resources for K8s, the new port replaces the original port and marks the corresponding relationship.

Port_outer1 is used to register the access to the public network port of this application when the public network load balancer registers. The domain name assigned to the user remains unchanged based on the mapping rules between the original port and the new port, and the user is not aware of it.

Dynamic configuration and resource discovery

Related component discover_service

After the user associates (installs) the application with the plug-in for the first time in the console, the plug-in will generate a configuration for the previous application. It is stored in the etcd of the data center via the region side. Modify the corresponding settings of the configuration, and update the corresponding service plug-in resources.

Distributed service-oriented architecture faces many problems. If you want to achieve service-oriented, service governance is a key point. On the basis of providing governance services, configuration needs to achieve real-time effectiveness and linkage. Therefore, in the rainbond design, the configuration resources of the plug-in are placed in the discover_service, and the discovery service supports dynamic configuration.

When Kubernetes creates the pod, a related environment variable DISCOVER_URL is injected into the env of the plug-in container. The value of this variable is that the plug-in can obtain the url of the resource through the GET request. This variable is also necessary for your plug-in to obtain resources when subsequent users use the platform to create their own functional plug-ins.

After reading the above, have you mastered how to understand the design of the Rainbond plug-in system? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.