Shulou(Shulou.com)05/31 Report--

This article mainly introduces "how to use the OpenResty plug-in". In the daily operation, I believe many people have doubts about how to use the OpenResty plug-in. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the doubts about "how to use the OpenResty plug-in". Next, please follow the editor to study!

Why do you need load balancing?

Rainbond internal network partition supports multi-tenancy, each tenant has a private IP segment, and the networks of different tenants are not visible to each other. When we deploy a containerized application to Rainbond,Rainbond, we will assign an internal IP to the container for communication between different applications in the same tenant within the cluster, but there is no direct access outside the cluster, so we need a cluster entry controller so that users can easily access these applications.

In addition, each application deployed in Rainbond can have multiple instances, that is, suppose we deploy three instances for a WEB application, and each instance shares part of the traffic, we need to add a load balancer controller in front of these three instances to complete the work of distributing traffic.

In addition to the above basic functions, the load balancing controller must support more functions, such as:

The ingress controller can forward requests to the specified application based on packet information (such as protocol, port number, hostname, etc.)

Discover the changes of applications in the cluster in real time (such as adding custom domain names, certificates, ports, etc.) and dynamically update their own forwarding rules

At the same time, HTTP, TLS, TCP and UDP protocols are supported, because sometimes not only WEB applications need to provide service slips, but RPC, MySQL and so on also need to be open to the public.

Support for high availability

To sum up, we need a load balancing controller cluster that supports L4 or various application protocols (L7) at the same time, and must be able to automatically find application changes in the cluster to update its forwarding rules.

The overall Architecture of load balancing in Rainbond

Web: represents an application in Rainbond and has three instances

Kube-apiserver component of api-server:kubeneters

Entrance:Rainbond 's universal interface for load balancing controller, which supports multiple load balancing plug-ins.

Entrance implementation

Load balancing in Rainbond is application-oriented, and different applications can use different load balancing. Rainbond's Entrance component is designed so that it can be integrated into a variety of load balancing plug-ins, that is, Rainbond supports not only common OpenResty, but also other load balancing plug-ins, such as commercially supported F5.

The main work of Entrance is to listen for changes in application running node information from kube-apiserver, such as Service, Endpoint, Pod, etc., and then abstract these resources into general load balancer abstractions and cache them in etcd. These common abstractions include:

Pool: load balancing pool, which includes multiple nodes, corresponding to the three WEB instances in the figure above

A node in Node:Pool that corresponds to one of the WEB instances in the figure above

Domain: domain name. The load balancer controller can identify the domain name information in a packet and forward the data to the corresponding Pool.

VirtualService: listens to the virtual host of a port and indicates the protocol name of the port, which is mainly used to handle L4 entry control and load balancing

Rule: forwarding rules, used to describe the corresponding relationship between domain name and Pool, also specify the protocol name and certificate information of the port, handle L7 access control and load balancing

When there is a change in resources, Entrance will convert the general resources into the corresponding plug-in resources, and operate the load balancing controller according to the different plug-in drivers selected by the application.

As you can see from the architecture, there are two Entrance and two OpenResty instances, and their relationship is that each Entrance holds the addresses of all OpenResty, and when there is information to update, Entrance updates the information to all OpenResty. How to coordinate between the two Entrance? Here we use the features of etcd to make distributed locks to ensure that only one Entrance has permission to update information to OpenResty, thus achieving high availability.

OpenResty plug-in

OpenResty is a WEB application that can handle requests and business bar logic with Lua scripts, and many Lua-related assignments and functions are built-in for developers to use. It is very suitable to develop Restful API servers. The reasons why we use OpenResty as a plug-in for Entrance are as follows:

Based on Nginx development, excellent in terms of stability and performance

Close to the design goal of Rainbond, it has helped us compile the Lua module, and can easily enrich the functions of the load balancing controller with Lua scripts.

Support both L7 and L4 load balancers

We embed a Rest API server on the OpenResty side, and these API are written in Lua. As mentioned earlier, OpenResty integrates Lua scripting, and we can use Lua to process requests directly. Here is part of the Nginx configuration file:

# custom api of upstream and serverserver {listen 10002; location ~ / v1/upstreams/ ([- _ 0-9a src_name Z.@] +) {set $src_name $1; content_by_lua_file lua/upstream.lua;} location ~ / v1/servers/ ([- _ 0-9a src_name Z.@] +) {set $src_name $1; content_by_lua_file lua/server.lua;}}

When we call the following API:

Curl-s localhost:10002/v1/servers/app1-X POST-d "$json_data"

OpenResty will execute the corresponding Lua foot, that is, lua/server.lua. As mentioned earlier, OpenResty has built-in many Lua-related instructions and functions to enable Lua to interact with Nginx better, so we handle the received JSON data in a container in the script and convert it into a configuration Nginx file. As more Lua code is not posted, you can find the project address in the reference section of this article.

One thing to note here is that when you receive a large number of requests to modify server and upstream, OpenResty needs to load configuration files frequently, which increases the load and affects performance. In fact, there are many third-party plug-ins available for OpenResty, and there is a plug-in called dyups that can dynamically modify upstream. It is used as follows: Lua code:

-- add or update the specified upstreamdyups.update ("upstream_name", [[server 127.0.0.1 server 8088;]])-- Delete the specified upstreamdyups.delete ("upstream_name")

It has already taken effect after the successful execution, and there is no need for us to execute the nginx-s reload command, which will improve some efficiency.

For the time being, the modification of server has not been dynamically modified with plug-ins, so in fact, our load balancer controller is divided into two cases. If you update the upstream configuration, it will take effect immediately, while you need to add the nginx-s reload command to update the server configuration.

At this point, the study on "how to use the OpenResty plug-in" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.