CN114301913B

CN114301913B - Request processing method and system

Info

Publication number: CN114301913B
Application number: CN202111598255.9A
Authority: CN
Inventors: 夏磊
Original assignee: Hangzhou Ezviz Software Co Ltd
Current assignee: Hangzhou Ezviz Software Co Ltd
Priority date: 2021-12-24
Filing date: 2021-12-24
Publication date: 2024-03-08
Anticipated expiration: 2041-12-24
Also published as: CN114301913A

Abstract

The embodiment of the application provides a request processing method and a request processing system. The scheme is as follows: the first container sends a first connection request to the second container through a first OVS based on a preconfigured first route, the destination address of the first connection request is a first IP address of the second container, and the next hop of the first route is the IP address of a container network card of the second container; the second container generates a first request response of the first connection request, and sends the first request response to the first container through the first OVS based on a second route which is configured in advance, wherein the next hop of the second route is the IP address of the container network card of the first container; the first container determines to establish a connection with the second container based on the received first request response. By the technical scheme provided by the embodiment of the application, the problem that the IP address of the container network card of the container in the cluster is inconsistent with the address information when the container is connected with the IP address of the container network card of the container is solved, so that the establishment of the connection and the normal operation of access among the containers are ensured.

Description

Request processing method and system

Technical Field

The present disclosure relates to the field of container network technologies, and in particular, to a method and a system for processing a request.

Background

Contiv is an open source container network architecture for heterogeneous container deployment across virtual machines, bare machines, public clouds, or private clouds, and is integrated with the mainstream container orchestration system. OVS (Open vSwitch) is a multi-layer virtual switch with industrial quality.

In the related art, a cluster constructed by using Contiv and OVS includes a plurality of containers, and each container can directly communicate after establishing a connection. At present, the connection between the containers can be established through the IP address of the container network card of the container, and also can be established through the IP address of the corresponding Service (namely Service) of the container. However, it is not possible to establish a connection by simultaneously using the IP address of the container network card of each container and the IP address of the service corresponding to each container.

Specifically, after the IP address of the container network card and the IP address of the service configured in the cluster are monitored, the context updates the mapping table entry between the service and the container, and configures the mapping table entry into the manager (Controller) of the OVS. And the Controller generates a corresponding control rule according to the mapping table item and issues the control rule to the OVS. The OVS adds the received control rule to the openflow table. Among them, openFlow is a network communication protocol.

When a container in the cluster (e.g., container a) establishes a connection with container B via the IP address of the service of another container (e.g., container B), the OVS stores a control rule including a rule for converting the source address of the request response to the IP address of the service of the container B. At this time, when the container a directly accesses the container B, the source address of the request response generated by the container B is the IP address of the container network card of the container B, and after the request response is forwarded to the OVS, the OVS converts the source address of the request response into the IP address of the service of the container B according to the stored control rule thereof, so that the source address of the request response received by the container a is inconsistent with the destination address of the connection request sent by the container a, and connection cannot be established, thereby affecting normal access between containers.

Disclosure of Invention

An object of the embodiments of the present application is to provide a method and a system for processing a request, so as to solve a problem that when an IP address of a container network card of a container in a cluster is inconsistent with address information during connection establishment of the container, thereby ensuring establishment of connection and normal access between containers. The specific technical scheme is as follows:

the embodiment of the application provides a request processing method, which is applied to a target cluster, wherein the target cluster comprises a first host, and the first host comprises a first container, a second container and a first OVS, and the method comprises the following steps:

When connection is required to be established between the IP address of the container network card of the second container and the second container, the first container sends the first connection request to the second container through the first OVS based on a preconfigured first route, wherein the destination address of the first connection request is the IP address of the container network card of the second container, and the next hop of the first route is the IP address of the container network card of the second container;

after receiving the first connection request, the second container generates a first request response of the first connection request, and sends the first request response to the first container through the first OVS based on a second preset route, wherein the next hop of the second route is the IP address of the container network card of the first container;

the first container determines to establish a connection with the second container based on the received first request response.

Optionally, the first host further includes a host gateway;

the method further comprises the steps of:

when a connection is required to be established between the IP address of the service of the second container and the second container, the first container sends a second connection request to the host gateway through the first OVS based on a pre-configured third route, wherein the destination address of the second connection request is the IP address of the service of the second container, and a network mask in the third route represents a service network and the next hop is the gateway address of the host gateway;

The host gateway forwards the second connection request to the second container according to the corresponding relation between the pre-stored service IP address and the container network card IP address and the destination address of the second connection request;

after receiving the second connection request, the second container generates a second request response of the second connection request, and sends the second request response to the host gateway through the first OVS based on a preconfigured fourth route corresponding to the third route, wherein the destination address of the second request response is the IP address of the container network card of the first container, and the next hop of the fourth route is the gateway address of the host gateway;

the host gateway sends the second request response to the first container according to the destination address of the second request response;

the first container determines to establish a connection with the second container based on the received second request response.

Optionally, the first host further includes a first host network card, the target cluster further includes a second host, the second host includes a third container, a second OVS, and a second host network card, and the first host and the second host are connected through a preset switch in communication;

The method further comprises the steps of:

when connection is required to be established between the IP address of the container network card of the third container and the third container, the first container sends a third connection request to the first host network card through the first OVS based on a pre-configured fifth route, the destination address of the third connection request is the IP address of the container network card of the third container, and the destination address of the fifth route is the IP address of the container network card of the third container and the output interface is the interface of the container network card of the first container;

the first host network card forwards the received third connection request to the second host network card through the preset switch;

the second host network card sends a third connection request to the third container through the second OVS based on the received destination address of the third connection request;

after receiving the third connection request, the third container generates a third request response of the third connection request, and sends the third request response to the second host network card through the second OVS based on a sixth pre-configured route, wherein a destination address of the third request response is an IP address of a container network card of the first container, a destination address of the sixth route is an IP address of a container network card of the first container, and an outgoing interface is an interface of a container network card of the third container;

The second host network card forwards the received third request response to the first host network card through the preset switch;

the first host network card sends a third request response to the first container through the first OVS based on the received destination address of the third connection request;

the first container determines to establish a connection with the third container based on the received third request response.

Optionally, the first host further includes a third host network card;

the method further comprises the steps of:

when a connection is required to be established between the IP address of the service of the third container and the third container, the first container sends a fourth connection request to the host gateway through the first OVS based on a preconfigured third route, wherein the destination address of the fourth connection request is the IP address of the service of the third container, and a network mask in the third route represents a service network and the next hop is the gateway address of the host gateway;

the host gateway converts the source address of the fourth connection request into the IP address of the third host network card according to a preset address conversion rule based on the received destination address of the fourth connection request to obtain a fifth connection request, and forwards the fifth connection request to the third host network card;

The third host network card forwards the received fifth connection request to the third container through the preset switch and the second OVS based on a preset seventh route, wherein an output interface of the seventh route is an interface of the third host network card, and a destination address is an IP address of a container network card of the third container;

after receiving the fifth connection request, the third container generates a fourth request response of the fifth connection request, and sends the fourth request response to the third host network card through the second OVS and the preset switch based on the eighth route, wherein an output interface of the eighth route is an interface of a container network card of the third container, and a destination address is an IP address of the third host network card;

the third host network card sends the fourth request response to the host gateway according to a ninth route, and the next hop of the ninth route is the gateway address of the host gateway;

after receiving the fourth request response, the host gateway converts a destination address of the fourth request response into an IP address of a container network card of the first container according to the preset address conversion rule to obtain a fifth request response, and sends the fifth request response to the first container through the first OVS;

The first container determines to establish a connection with the third container based on the received fifth request response.

The embodiment of the application provides a request processing system, which comprises a first host, wherein the first host comprises a first container, a second container and a first OVS;

the first container is configured to send, when a connection needs to be established with the second container through an IP address of a container network card of the second container, the first connection request to the second container through the first OVS based on a first route configured in advance, where a destination address of the first connection request is the IP address of the container network card of the second container, and a next hop of the first route is the IP address of the container network card of the second container;

the second container is configured to generate a first request response of the first connection request after receiving the first connection request, and send the first request response to the first container through the first OVS based on a second route configured in advance, where a next hop of the second route is an IP address of a container network card of the first container;

the first container is further configured to determine, based on the received first request response, to establish a connection with the second container.

Optionally, the first host further includes a host gateway;

the first container is further configured to send, when a connection needs to be established with the second container through an IP address of a service of the second container, a second connection request to the host gateway through the first OVS based on a third route configured in advance, where a destination address of the second connection request is an IP address of the service of the second container, and a network mask in the third route indicates a service network and a next hop is a gateway address of the host gateway;

the host gateway is configured to forward the second connection request to the second container according to a corresponding relationship between a pre-stored service IP address and a container network card IP address, and a destination address of the second connection request;

the second container is further configured to generate a second request response of the second connection request after receiving the second connection request, and send the second request response to the host gateway through the first OVS based on a fourth route configured in advance and corresponding to the third route, where a destination address of the second request response is an IP address of a container network card of the first container, and a next hop of the fourth route is a gateway address of the host gateway;

The host gateway is further configured to send the second request response to the first container according to the destination address of the second request response;

the first container is further configured to determine, based on the received second request response, to establish a connection with the second container.

Optionally, the first host further includes a first host network card, the system further includes a second host, the second host includes a third container, a second OVS and a second host network card, and the first host and the second host are connected through a preset switch in communication;

the first container is further configured to send, when connection is required to be established between the IP address of the container network card of the third container and the third container, a third connection request to the first host network card through the first OVS based on a fifth route configured in advance, where a destination address of the third connection request is an IP address of the container network card of the third container, and a destination address of the fifth route is an IP address of the container network card of the third container, and an outgoing interface is an interface of the container network card of the first container;

the first host network card is used for forwarding the received third connection request to the second host network card through the preset switch;

The second host network card is configured to send, based on a destination address of the received third connection request, the third connection request to the third container through the second OVS;

the third container is configured to generate a third request response of the third connection request after receiving the third connection request, and send the third request response to the second host network card through the second OVS based on a sixth pre-configured route, where a destination address of the third request response is an IP address of a container network card of the first container, a destination address of the sixth route is an IP address of a container network card of the first container, and an outgoing interface is an interface of a container network card of the third container;

the second host network card is further configured to forward, through the preset switch, the received third request response to the first host network card;

the first host network card is further configured to send, through the first OVS, the third request response to the first container based on the destination address of the received third connection request;

the first container is further configured to determine, based on the received third request response, to establish a connection with the third container.

Optionally, the first host further includes a third host network card;

the first container is further configured to send, when a connection needs to be established with the third container through an IP address of a service of the third container, a fourth connection request to the host gateway through the first OVS based on a third route configured in advance, where a destination address of the fourth connection request is an IP address of the service of the third container, and a network mask in the third route indicates a service network and a next hop is a gateway address of the host gateway;

the host gateway is further configured to convert, according to a preset address conversion rule, a source address of the fourth connection request to an IP address of the third host network card based on a destination address of the received fourth connection request, to obtain a fifth connection request, and forward the fifth connection request to the third host network card;

the third host network card is configured to forward the received fifth connection request to the third container through the preset switch and the second OVS based on a preset seventh route, where an output interface of the seventh route is an interface of the third host network card, and a destination address is an IP address of a container network card of the third container;

The third container is further configured to generate a fourth request response of the fifth connection request after receiving the fifth connection request, and send the fourth request response to the third host network card through the second OVS and the preset switch based on the eighth route, where an output interface of the eighth route is an interface of a container network card of the third container, and a destination address is an IP address of the third host network card;

the third host network card is further configured to send the fourth request response to the host gateway according to a ninth route, where a next hop of the ninth route is a gateway address of the host gateway;

the host gateway is further configured to, after receiving the fourth request response, convert, according to the preset address conversion rule, a destination address of the fourth request response to an IP address of a container network card of the first container, obtain a fifth request response, and send the fifth request response to the first container through the first OVS;

the first container is further configured to determine, based on the received fifth request response, to establish a connection with the third container.

Embodiments of the present application also provide a computer readable storage medium having a computer program stored therein, which when executed by a processor, implements any of the above-described request processing method steps.

Embodiments of the present application also provide a computer program product comprising instructions which, when run on a computer, cause the computer to perform any of the above-described request processing methods.

The beneficial effects of the embodiment of the application are that:

according to the technical scheme provided by the embodiment of the application, when the first container establishes connection with the second container through the IP address of the container network card of the second container, the first connection request is sent to the second container based on the preconfigured first route, namely, the IP address link route of the container network card of which the next hop is the second container. The second container sends a first request response to the first container based on a pre-configured second route, i.e., a link route of the IP address of the container network card of which the next hop is the first container, in response to the first connection request, thereby completing connection establishment.

Compared with the related art, the request process and the response process are both based on the pre-configured link route for message forwarding, so that the response process is not influenced by the rule when the first container establishes connection with the second container through the IP address of the service of the second container, the problem that the IP address of the container network card of the container in the cluster is inconsistent with the address information when the container establishes connection with the container is solved, and the establishment of connection and the normal operation of access among the containers are ensured.

Of course, not all of the above-described advantages need be achieved simultaneously in practicing any one of the products or methods of the present application.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following description will briefly introduce the drawings that are required to be used in the embodiments or the description of the prior art, and it is obvious that the drawings in the following description are only some embodiments of the present application, and other embodiments may also be obtained according to these drawings to those skilled in the art.

FIG. 1-a is a first schematic diagram of TCP connection establishment between PODs in a kubernetes cluster;

FIG. 1-b is a second schematic diagram of TCP connection establishment between PODs in a kubernetes cluster;

fig. 2 is a schematic structural diagram of a kubernetes cluster according to an embodiment of the present application;

FIG. 3 is a first flowchart of a request processing method according to an embodiment of the present application;

fig. 4 is a first signaling diagram of a connection establishment procedure provided in an embodiment of the present application;

FIG. 5 is a second flowchart of a request processing method according to an embodiment of the present application;

fig. 6 is a second signaling diagram of a connection establishment procedure provided in an embodiment of the present application;

FIG. 7 is a third flowchart of a request processing method according to an embodiment of the present application;

Fig. 8 is a third signaling diagram of a connection establishment procedure provided in an embodiment of the present application;

FIG. 9 is a fourth flowchart of a request processing method according to an embodiment of the present application;

fig. 10 is a signaling diagram of a connection establishment procedure provided in an embodiment of the present application;

fig. 11 is a schematic structural diagram of a request processing system according to an embodiment of the present application.

Detailed Description

The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are only some, but not all, of the embodiments of the present application. Based on the embodiments herein, a person of ordinary skill in the art would be able to obtain all other embodiments based on the disclosure herein, which are within the scope of the disclosure herein.

In the related art, in a cluster constructed by utilizing Contiv and OVS, a transmission control protocol (Transmission Control Protocol, TCP) connection can be established between different containers through the IP address of the container network card of the container, or through the IP address TCP connection of the corresponding service of the container.

For ease of understanding, figures 1-a and 1-b are illustrated, respectively. Fig. 1-a is a first schematic diagram of TCP connection establishment between PODs in kubernetes cluster, and fig. 1-b is a second schematic diagram of TCP connection establishment between PODs in kubernetes cluster. Wherein, kubernetes (also called k8 s) cluster is constructed by using Contiv and OVS, PODs are the minimum management units of kubernetes, and each POD can contain one or more containers. Each container in the same POD will share the same name space and local network and each container in the same POD can be accessed to each other through a local host (localhost), so each POD can be considered as one container.

Now assume that the IP addresses of the container network cards of POD1 in fig. 1-a and 1-b are: 10.86.36.10; the IP address of the container network card of POD2 is: 10.86.36.20, the IP address of the service is: 10.68.236.110.

in the procedure shown in fig. 1-a, POD1 may establish a TCP connection with POD2 through the IP address of the service of POD 2. Specifically, the TCP request sent by POD1 will be transmitted to OVS (i.e. stage 101 shown in fig. 1-a), at this time, the destination address of the TCP request is the IP address of the service of POD 2. After the OVS performs address conversion on the received TCP request, that is, converts the destination address of the TCP request from the IP address of the service of POD2 to the IP address of the container network card of POD 2. The OVS forwards the address translated TCP request to POD2 (i.e., stage 102 shown in fig. 1-a).

After receiving the TCP request, POD2 generates a corresponding TCP response, where the source address of the TCP response is the IP address of the container network card of POD2, and the destination address is the IP address of the container network card of POD 1. POD2 sends the TCP response to the OVS (i.e., stage 103 shown in fig. 1-a). The OVS performs address conversion on the received TCP response, that is, converts the source address of the TCP response from the IP address of the container network card of POD2 to the IP address of the service of POD2, and the converted TCP response is sent to POD1 (i.e., stage 104 shown in fig. 1-a).

In the process shown in fig. 1-a, the source address and destination address of the message corresponding to each stage are shown in table 1.

TABLE 1

Stage(s)	Stage 101	Stage 102	Stage 103	Stage 104
					Source address	10.86.36.10	10.86.36.10	10.86.36.20	10.68.236.110
Destination address	10.68.236.110	10.86.36.20	10.86.36.10	10.86.36.10

Since the destination address of the TCP request sent by POD1 and the source address of the TCP response received by POD1 are both IP addresses of the service of POD2, i.e. 10.68.236.110 shown in table 1, POD1 can determine to establish a TCP connection with POD2 according to the received TCP response.

When the rule of address translation in the procedure shown in fig. 1-a is stored in the above OVS, POD1 cannot establish a TCP connection with POD2 through the IP address of the container network card of POD 2. Specifically, as shown in fig. 1-b, the TCP request sent by POD1 will be transmitted to the OVS (i.e. stage 105 shown in fig. 1-b), where the destination address of the TCP request is the IP address of the container network card of POD 2. The OVS will forward the TCP request to POD2 (i.e. stage 106 shown in fig. 1-b) based on the destination address.

After receiving the TCP request, POD2 generates a corresponding TCP response, where the source address of the TCP response is the IP address of the container network card of POD2, and the destination address is the IP address of the container network card of POD 1. POD2 sends the TCP response to the OVS (i.e., stage 107 shown in fig. 1-b). Because the OVS stores address conversion rules for converting the source address in the TCP response packet with the source address of the IP address of the container network card of POD2 into the IP address of the service of POD2, at this time, the OVS converts the source address in the received TCP response from the IP address of the container network card of POD2 into the IP address of the service of POD2, and the converted TCP response is sent to POD1 (i.e. stage 108 shown in fig. 1-b).

In the process shown in fig. 1-b, the source address and destination address of the message corresponding to each stage are shown in table 2.

TABLE 2

Stage(s)	Stage 105	Stage 106	Stage 107	Stage 108
					Source address	10.86.36.10	10.86.36.10	10.86.36.20	10.68.236.110
Destination address	10.68.236.20	10.86.36.20	10.86.36.10	10.86.36.10

Since the destination address of the TCP request sent by POD1 is 10.68.236.20 and the source address of the TCP response received by POD1 is 10.68.236.110, which are different, POD1 can determine that the received TCP response is illegal, and at this time, POD1 refuses to establish a connection with POD2 according to the received TCP response.

In order to solve the problems in the related art, the embodiment of the application provides a request processing method. The method is applied to a target cluster. The target cluster can comprise a plurality of hosts, each host can comprise a plurality of containers, and different hosts are in communication connection through a preset switch.

For ease of understanding, the description is provided in connection with fig. 2. Fig. 2 is a schematic structural diagram of kubernetes cluster according to an embodiment of the present application.

In the target cluster shown in fig. 2 (i.e., kubernetes cluster), the host 1 includes two containers (i.e., POD1 and POD 2) and one OVS (i.e., OVS 1). The host 2 includes one container (i.e., POD 3) and one OVS (i.e., OVS 2). The host 1 and the host 2 are communicatively connected through a preset switch. Here, the number of PODs included in each host of the kubernetes cluster is not particularly limited.

In this embodiment of the present application, each host of the kubernetes cluster may further include a host gateway and a host network card, which are described below, in addition to the POD and the OVS, and are not described herein.

In this embodiment of the present application, the target cluster may be a Docker cluster in addition to the kubernetes cluster. Wherein, docker is an open-source container engine. The target clusters are not particularly limited herein. For ease of understanding, the following description is given by taking the target cluster as a kubernetes cluster as an example, and is not meant to be limiting in any way.

The embodiments of the present application will be described below by way of specific examples.

As shown in fig. 3, fig. 3 is a first flowchart of a request processing method according to an embodiment of the present application. The method is applied to the target cluster, the target cluster comprises a first host, the first host comprises a first container, a second container and a first OVS, and the method comprises the following steps: the method comprises the following steps.

In step S301, when a connection needs to be established between the IP address of the container network card of the second container and the second container, the first container sends a first connection request to the second container through the first OVS based on a first route configured in advance, where a destination address of the first connection request is the IP address of the container network card of the second container, and a next hop of the first route is the IP address of the container network card of the second container.

In the embodiment of the present application, when the target cluster is constructed, for each container included in the same host in the target cluster, a link route of a message route of the container to other containers may be preconfigured. The next hop of the link route is the IP address of the container network card that the message needs to be transmitted to the container.

When the first container needs to establish a connection with the second container through the IP address of the container network card of the second container, the first container may send a connection request (denoted as a first connection request) to the first OVS according to a preconfigured first route in which the next hop is the IP address of the container network card of the second container, and the first OVS forwards the received first connection request to the second container.

The source address of the first connection request is the IP address of the container network card of the first container, and the destination address is the IP address of the container network card of the second container.

In this embodiment of the present application, the connection request may be the TCP connection request or a TCP access request. Here, the first connection request is not particularly limited.

In step S302, after receiving the first connection request, the second container generates a first request response of the first connection request, and sends the first request response to the first container through the first OVS based on a second route configured in advance, where a next hop of the second route is an IP address of a container network card of the first container.

After forwarding the first connection request to the second container, the second container will receive the first connection request. At this time, the second container will generate a request response (denoted as a first request response) to the first connection request.

The source address of the first request response is the IP address of the container network card of the second container, and the destination address is the IP address of the container network card of the first container.

After the second container generates the first request response, the second container may forward the first request response to the first OVS according to a second route that is preconfigured that the next hop is the IP address of the container network card of the first container. The first OVS forwards the received first request response to the first container.

In step S303, the first container determines to establish a connection with the second container based on the received first request response.

In this step, after the first container receives the first request response, since the source address of the first request response is the IP address of the container network card of the second container, and the destination address of the first connection request sent by the first container to the second container is the IP address of the container network card of the second container, at this time, the first container may determine that the first request response received by the first container is legal. The first container may determine to establish a connection with the second container.

Processing logic of the OVS to the IP address of the service is removed from the OVS of the host when the target cluster is constructed. The first OVS is a bridge connecting the first container and the second container.

The first host may be any host in the target cluster, and the first container and the second peer may be any two containers in containers included in the first host. Here, the first host, the first container, and the second container are not particularly limited.

For ease of understanding, the connection establishment procedure described above is described with reference to fig. 2 and 4. Fig. 4 is a first signaling diagram of a connection establishment procedure provided in an embodiment of the present application.

In the request processing method shown in fig. 3, only the connection establishment process between different containers in the same host is referred to, and therefore, only the connection establishment process between POD1 and POD2 included in the host 1 in fig. 2 will be described as an example.

As in fig. 4, POD1 sends request 1 to OVS1 based on the first route described above. OVS1 acts as a bridge between POD1 and POD2, forwarding received request 1 to POD2.

After receiving the request 1, the POD2 generates a response 1 corresponding to the request 1.POD2 sends response 1 to OVS1 based on the second route described above. OVS1 acts as a bridge between POD1 and POD2, forwarding the received response 1 to POD1.

POD1, upon receiving response 1, determines that the destination address of request 1 is the same as the source address of response 1. At this time, POD1 determines to establish a connection with POD 2.

By the method shown in fig. 3, when the first container establishes a connection with the second container through the IP address of the container network card of the second container, the first connection request is sent to the second container based on the preconfigured first route, that is, the IP address link route of the container network card of which the next hop is the second container. The second container sends a first request response to the first container based on a pre-configured second route, i.e., a link route of the IP address of the container network card of which the next hop is the first container, in response to the first connection request, thereby completing connection establishment.

In an alternative embodiment, the first host may further include a host gateway. Based on the host gateway, the embodiment of the application also provides a request processing method. As shown in fig. 5, fig. 5 is a second flowchart of a request processing method according to an embodiment of the present application. The method comprises the following steps.

In step S501, when a connection is required to be established between the IP address of the service of the second container and the second container, the first container sends a second connection request to the host gateway through the first OVS based on a third route configured in advance, where the destination address of the second connection request is the IP address of the service of the second container, and a network mask in the third route indicates that the service network and the next hop are gateway addresses of the host gateway.

In the embodiment of the application, in constructing the target cluster, for each container in the target cluster, a network route from the container network to the service network may be preconfigured in the container.

For example, a network route (denoted as a third route) in which the network mask indicates a serving network and the next hop is a gateway address of the host gateway may be preconfigured in the first container.

When the first container needs to establish a connection with the second container through the IP address of the service of the second container, the first container may send a connection request (denoted as a second connection request) to the first OVS based on the third route, and the first OVS forwards the received second connection request to the host gateway of the first host.

The source address of the second connection request is the IP address of the container network card of the first container, and the destination address is the IP address of the service of the second container.

In this embodiment of the present application, for each container in the target cluster, the IP address of the container network card of the container is different from the network segment where the IP address of the service of the container is located. The IP address of the container network card is in the IP address field of the container network and the IP address of the service is in the IP address field of the service network. The network masks corresponding to the different IP address segments are different.

For ease of understanding, the second container is described above as an example, and it is assumed that the IP address of the service of the second container is: 10.68.0.1/16. That is, the first IP address of a certain address segment of the service network is: 10.68.0.0/16. When the destination address of the second connection request is 10.68.0.1/16, the IP address is in the address field corresponding to the service network, and therefore, the network mask corresponding to the IP address indicates the service network, and at this time, when the second connection request is sent based on the third route, the second connection request is forwarded to the host gateway.

Step S502, the host gateway forwards the second connection request to the second container according to the corresponding relation between the pre-stored service IP address and the container network card IP address and the destination address of the second connection request.

In this embodiment of the present application, after the target cluster is constructed, for each host in the target cluster, a corresponding relationship between a container network card IP address of each container and a service IP address of a service of each container is recorded in the host. The host gateway may determine, according to the correspondence and the destination address in the second connection request, the container network card IP address corresponding to the destination address, that is, determine the container network card IP address corresponding to the IP address of the service of the second container in the correspondence (that is, the container network card IP address of the second container). At this time, the host network card may forward the received second connection request to the second container based on the container network card IP address.

In step S503, after receiving the second connection request, the second container generates a second request response of the second connection request, and sends the second request response to the host gateway through the first OVS based on a fourth route configured in advance and corresponding to the third route, where a destination address of the second request response is an IP address of the container network card of the first container, and a next hop of the fourth route is a gateway address of the host gateway.

The second container may generate a second request response to the second connection request after receiving the second connection request.

The source address of the second request response is the IP address of the service of the second container, and the destination address is the IP address of the container network card of the first container.

In the embodiment of the present application, when the target cluster is constructed, in addition to the pre-configured network route, a link route corresponding to the network route, that is, a link route (denoted as a fourth route) where the next hop is a gateway address of the host gateway, is also configured.

After generating the second request response, the second container may forward the second request response to the first OVS based on the fourth route, where the first OVS forwards the received second request response to the host gateway of the first host.

In step S504, the host gateway sends the second request response to the first container according to the destination address of the second request response.

In this step, after receiving the second request response, the host gateway may forward the received second request response to the first container according to the destination address of the second request response, that is, the IP address of the container network card of the first container.

In step S505, the first container determines to establish a connection with the second container based on the received second request response.

In this step, after the first container receives the second request response, since the source address of the second request response is the IP address of the service of the second container, and the destination address of the second connection request sent by the first container is the IP address of the service of the second container, the first container may determine that the second request response received by the first container is legal. The first container may determine to establish a connection with the second container.

The first OVS is a bridge connecting the first container and the host gateway, and a bridge connecting the second container and the host gateway.

For ease of understanding, the connection establishment procedure described above is described with reference to fig. 2 and 6. Fig. 6 is a second signaling diagram of a connection establishment procedure provided in an embodiment of the present application.

In the request processing method shown in fig. 5, only a process of establishing a connection with a different container in the host through an IP address of a service of the container is involved. Therefore, the connection establishment procedure between the POD1 and the POD2 included in the host 1 in fig. 2 is described as an example.

In fig. 6, POD1 sends request 2 to OVS1 based on the third route described above. OVS1 acts as a bridge between POD1 and the host gateway, forwarding the received request 2 to the host gateway.

And the host gateway forwards the request 2 to the POD2 according to the corresponding relation between the destination address in the request 2 and the service IP address and the container network card IP address.

POD2 generates response 2 after receiving request 2 and forwards response 2 to OVS1 based on the fourth route described above. The OVS1 acts as a bridge between POD2 and the host gateway, forwarding the received response 2 to the host gateway.

The host gateway forwards the received response 2 to POD1 according to the destination address of the response 2.

POD1, upon receiving response 2, determines that the destination address of request 2 is the same as the source address of response 2. At this time, POD1 determines to establish a connection with POD2.

By the method shown in fig. 5, when the first container establishes a connection with the second container through the IP address of the service of the second container, the manner of forwarding the message by using openflow generated according to the control rule in the related art is abandoned, the processing logic of the IP address of the service of the container in the OVS is abandoned, the process of connecting the first container with the second container and the process of responding to the request are realized through the pre-configured route, and the address conversion is not performed in the process, so that the source address of the second request response received by the first container is consistent with the destination address of the first connection request sent by the first container, the problem that the address information is inconsistent when the IP address of the container network card of the container is established with the container in the cluster is solved, and the establishment of the connection and the normal operation of the access between the containers are ensured.

In an optional embodiment, the first host further includes a first host network card, the target cluster further includes a second host, the second host includes a third container, a second OVS, and a second host network card, and the first host and the second host are communicatively connected through a preset switch.

In an optional embodiment, based on the first host network card and the second host, the embodiment of the application further provides a request processing method. As shown in fig. 7, fig. 7 is a third flowchart of a request processing method according to an embodiment of the present application. The method comprises the following steps.

In step S701, when connection is required to be established between the IP address of the container network card of the third container and the third container, the first container sends a third connection request to the first host network card through the first OVS based on a fifth route configured in advance, the destination address of the third connection request is the IP address of the container network card of the third container, the destination address of the fifth route is the IP address of the container network card of the third container, and the output interface is the interface of the container network card of the first container.

In the embodiment of the application, in the construction of the target cluster, a host route from a container route to a host network card is preconfigured for a scenario that a connection is established across hosts for different containers. For example, the first container may be configured with an IP address of the container network card having the destination address of the third container and a host route (denoted as a fifth route) having an interface of the container network card having the first container.

When the first host needs to establish a connection with the third container across the host through the IP address of the container network card of the third container, the first container may send a connection request (denoted as a third connection request) to the first OVS based on the fifth route described above. The first OVS forwards the received third connection request to the first host network card of the address host.

The source address of the third connection request is the IP address of the container network card of the first container, and the destination address is the IP address of the container network card of the third container.

In this embodiment of the present application, each host in the target cluster has a corresponding host network card, and the number of host network cards may be one or more. Each container has a corresponding container network card. The host network card is a physical network card, and the container network card is a virtual network card.

The first network card may be a host network card in the first host. The first host can switch the master network card and the slave network card through a network card binding (bonding) switching mode. Here, the network card binding mode of the host network card in the first host is not specifically described.

In step S702, the first host network card forwards the received third connection request to the second host network card through the preset switch.

In this step, after the first host network card receives the third connection request, the third connection request may be forwarded to a preset switch according to the destination address of the third connection request. The preset exchanger forwards the received third connection request to a second host network card of the second host.

The second host network card may refer to the description of the first host network card, which is not described herein.

In step S703, the second host network card sends the third connection request to the third container through the second OVS based on the destination address of the received third connection request.

In this step, after receiving the third connection request, the second host network card may forward the third connection request to the second OVS according to the destination address of the third connection request, and the second OVS may forward the received third connection request to the third container.

Step S704, after receiving the third connection request, the third container generates a third request response of the third connection request, and sends the third request response to the second host network card through the second OVS based on a sixth pre-configured route, where a destination address of the third request response is an IP address of the container network card of the first container, a destination address of the sixth route is an IP address of the container network card of the first container, and the output interface is an interface of the container network card of the third container.

The third container may generate a request response (referred to as a third request response) to the third connection request after receiving the third connection request.

The source address of the third request response is the IP address of the container network card of the third container, and the destination address is the IP address of the container network card of the first container.

In the embodiment of the application, in the construction of the target cluster, a host route from a container route to a host network card is preconfigured for a scenario that different containers cross hosts to establish connection. For example, the IP address of the container network card whose destination address is the first container may be configured in the third container, and the host route (referred to as a sixth route) whose interface is the interface of the container network card of the third container may be outputted.

After the third container generates the third request response, the third container may forward the generated third request response to the second OVS based on the sixth route, and the second OVS may forward the received third request response to the second host network card.

Step S705, the second host network card forwards the received third request response to the first host network card through the preset switch.

In this step, after receiving the third request response, the second host network card may forward the third request response to the preset switch according to the destination address of the third request response. And the preset exchanger forwards the third request response to the first host network card according to the destination address of the third request response.

In step S706, the first host network card sends a third request response to the first container through the first OVS based on the destination address of the received third connection request.

In this step, after receiving the third request response, the first host network card may forward the third request response to the first OVS according to the destination address of the third request response, where the first OVS forwards the received third request response to the first container.

In step S707, the first container determines to establish a connection with the third container based on the received third request response.

In this step, after receiving the third request response, the first container may determine that the source address of the third request response is the IP address of the container network card of the third container, and the destination address of the third connection request sent by the first container is the IP address of the container network card of the third container, where the first container may determine that the third request response received by the first container is legal. The first container may determine to establish a connection with the third container.

The first OVS is a bridge connecting the first container and the first host network card, and the second OVS is a bridge connecting the third container and the second host network card.

For ease of understanding, the connection establishment procedure described above will be described with reference to fig. 2 and 8 described above. Fig. 8 is a third signaling diagram of a connection establishment procedure according to an embodiment of the present application.

In the request processing method shown in fig. 7, only the process of establishing connection of a container in a different host through the IP address of the container network card of the container is involved. Therefore, the connection establishment procedure between the POD1 included in the host 1 and the POD3 included in the host 2 in fig. 2 is described only as an example.

In fig. 8, POD1 sends request 3 to OVS1 based on the fifth route described above, and OVS1 forwards the received request 3 to host network card 1. The host network card 1 forwards the received request 3 to a preset switch connecting the host 1 and the host 2.

The preset switch sends a request 3 to the host network card 2 of the host 2 according to the destination address of the request 3.

The host network card 2 forwards the received request 3 to the OVS2.OVS2 forwards the received request 3 to POD3. The POD3 generates a response 3 in response to the received request 3, and forwards the generated response 3 to the OVS2 based on the sixth route, and the OVS2 forwards the received response 3 to the host network card 2. And the host network card 2 sends the response 3 to the preset exchanger according to the destination address of the response 3.

And the preset exchanger sends a response 3 to the host network card 1 of the host 1 according to the destination address of the response 3.

The host network card 1 forwards the received response 3 to the OVS1.OVS1 forwards the received response 3 to POD1.POD1, after receiving response 3, determines that the source address of received response 3 is the same as the destination address of request 3 it sent. At this time, POD1 may determine to establish a connection with POD3.

By the method shown in fig. 7, when the IP address of the container network card passing through the third container is connected with the third container across the host, the connection request process and the request response process are both based on the pre-configured routing information for forwarding the message, so that the response process is not affected by the rule when the first container establishes the connection with the third container through the IP address of the service of the third container, the problem that the address information is inconsistent when the IP address of the container network card passing through the container in the cluster establishes the connection with the container is solved, and the establishment of the connection and the normal running of the access between the containers are ensured.

In an optional embodiment, the first host further includes a third host network card. Based on the third host network card, the embodiment of the application also provides a request processing method. As shown in fig. 9, fig. 9 is a fourth flowchart of a request processing method according to an embodiment of the present application. The method comprises the following steps.

In step S901, when a connection is required to be established between the IP address of the service of the third container and the third container, the first container sends a fourth connection request to the host gateway through the first OVS based on a third route configured in advance, where the destination address of the fourth connection request is the IP address of the service of the third container, and a network mask in the third route indicates that the service network and the next hop are gateway addresses of the host gateway.

In this step, when the first container needs to establish a connection with the third container across the hosts through the IP address of the service of the third container, the first container may send a connection request (denoted as a fourth connection request) to the first OVS based on the above-described third route. The first OVS forwards the received fourth connection request to the host gateway of the first host.

The source address of the fourth connection request is the IP address of the container network card of the first container, and the destination address is the IP address of the service of the third container.

Step S902, the host gateway converts the source address of the fourth connection request into the IP address of the third host network card according to the preset address conversion rule based on the received destination address of the fourth connection request, to obtain a fifth connection request, and forwards the fifth connection request to the third host network card.

In the embodiment of the application, in constructing the target cluster, two networks, namely, a base (infra) network and a data (data) network, are created in the management plane. The Infra network is the basis for bearing a container to access a host and an external network, and can support the types of a virtual local area network (Virtual Local Area Network, VLAN) and a virtual extension local area network (Virtual Extensible Local Area Network, VXLAN), the data network is a network connected with a container (such as the POD), and corresponding address pools are allocated for the Infra network and the data network.

In the data network construction process, preset address conversion rules, such as internet protocol virtual server (IP Virtual Server, ipvs) rules and firewall (iptables) rules for controlling linux access, can be configured in the host of the target cluster. Wherein linux is an operating system kernel. The ipvs rule and the iptables rule are used for address conversion of the first message in different modes, so that the message can be transmitted from the host gateway to the host network card.

In addition, iptables filter INPUT rules are also configured in the hosts of the target cluster. The iptables filter INPUT rule is a rule for filtering messages in the above-mentioned filtering table of iptables rules, and the iptables filter INPUT rule is used to pass messages received from a host gateway, so that the messages can flow into services in the host, such as into each container in the host, through the host gateway on the host. For example, the iptables filter INPUT rule may be used by the host gateway in fig. 5 for forwarding the second connection request and the second request response, and by the host gateway in fig. 9 for forwarding the fifth connection request and the fifth request response.

After receiving the fourth connection request, the host gateway may perform address conversion on the source address of the fourth connection request according to the ipvs rule or the iptables rule. And converting the source address of the fourth connection request into the IP address of the third host network card to obtain a fifth connection request. The host gateway forwards the fifth connection request to the third host network card of the first host.

The source address in the fifth connection request is the IP address of the third host network card, and the destination address is the IP address of the service of the third container.

The third host network card may be the first host network card, or may be another host network card in the first host. Here, the third host network card is not particularly limited.

In step S903, the third host network card forwards the received fifth connection request to the third container through the preset switch and the second OVS based on the preconfigured seventh route, where an output interface of the seventh route is an interface of the third host network card, and the destination address is an IP address of the container network card of the third container.

In the embodiment of the application, in the establishment process of the Infra network, a direct connection route between a certain host node and a container in another host is created in each host of the target cluster. For example, the first host is configured with an interface having an interface as a third host network card, and a direct route (referred to as a seventh route) having a destination address as an IP address of a container network card of the third container.

After receiving the fifth connection request, the third host network card may forward the received fifth connection request to a preset switch based on the seventh route. The preset switch forwards the received fifth connection request to the second OVS. The second OVS forwards the received fifth connection request to the third container.

Step S904, after receiving the fifth connection request, the third container generates a fourth request response of the fifth connection request, and based on the eighth route, sends the fourth request response to the third host network card through the second OVS and the preset switch, where an output interface of the eighth route is an interface of the container network card of the third container, and a destination address is an IP address of the third host network card.

The third container may generate a request response (referred to as a fourth request response) for the fifth connection request after receiving the fifth connection request.

The source address in the fourth request response is the IP address of the service of the third container, and the destination address is the IP address of the third host network card.

In the embodiment of the application, in the establishment process of the Infra network, a direct connection route between a certain host node and a container in another host is created in each host of the target cluster. For example, an interface of a container network card having an interface of a third container is preconfigured in the second host, and the destination address is an IP address (denoted as an eighth route) of the third host network card.

After generating the fourth connection request, the third container may send the generated fourth request response to the second OVS based on the eighth route. The second OVS forwards the received fourth request response to the preset switch. And forwarding the received fourth request response to the third host network card by the preset switch.

In step S905, the third host network card sends a fourth request response to the host gateway according to the ninth route, where the next hop of the ninth route is the gateway address of the host gateway.

In the embodiment of the present application, in each host of the target cluster, a direct connection route is created between the host network card and the host gateway. For example, the next hop between the third host network card and the host gateway of the first host is a direct connection route (denoted as a ninth route) of the gateway address of the host gateway.

After receiving the fourth request response, the third host network card may send the fourth request response to the host gateway of the first host according to the ninth route.

Step S906, after receiving the fourth request response, the host gateway converts the destination address of the fourth request response into the IP address of the container network card of the first container according to the preset address conversion rule to obtain a fifth request response, and sends the fifth request response to the first container through the first OVS.

In this step, after receiving the fourth request response, the host gateway may perform address conversion on the destination address in the fourth request response according to the preset address conversion rule, that is, the ipvs rule or the iptables rule. That is, the destination address in the fourth request response is converted into the IP address of the container network card of the first container, so as to obtain a fifth request response, and the fifth request response is forwarded to the first OVS. The first OVS forwards the received fifth request response to the first container.

The source address of the fifth request response is the IP address of the service of the third container, and the destination address is converted into the IP address of the container network card of the first container.

In step S907, the first container determines to establish a connection with the third container based on the received fifth request response.

In this step, after receiving the fifth request response, the first container may determine that the source address of the fifth request response is the IP address of the service of the third container, and the destination address of the fourth connection request sent by the first container is the IP address of the service of the third container, where the first container may determine that the received fifth request response is legal. The first container may determine to establish a connection with the third container.

For ease of understanding, the connection establishment procedure described above is described with reference to fig. 2 and 10. Fig. 10 is a signaling diagram of a connection establishment procedure according to an embodiment of the present application.

In the request procedure shown in fig. 9, only the procedure of establishing a connection by the IP address of the service of the container in the different host is involved. Therefore, the connection establishment procedure between the POD1 included in the host 1 and the POD3 included in the host 2 in fig. 2 is described only as an example.

In fig. 10, POD1 sends request 4 to OVS1 based on the third route described above, and OVS1 forwards the received request 4 to the host gateway. The host gateway performs address conversion on the source address of the request 2 according to the ipvs rule or the iptables rule to obtain a request 5, and forwards the request 5 to the host network card 3. The host network card 3 forwards the received request 5 to the preset switch based on the seventh route.

The preset switch forwards the received request 5 to OVS2.

OVS2 forwards the received request 5 to POD3. The POD3 responds to the request 5, generates a response 4, and sends the response 4 to the OVS2 based on the eighth route described above. The OVS2 forwards the received response 4 to the preset switch.

The preset exchange forwards the received response 4 to the host network card 3.

After receiving the response 4, the host network card 3 forwards the received response 4 to the host gateway based on the ninth route. The host gateway performs address conversion on the response 4 according to the ipvs rule or the iptables rule to obtain a response 5, and forwards the response 5 to the OVS1, and the OVS1 forwards the received response 5 to the POD1.

By the method shown in fig. 9, when the first container establishes a connection with the third container across the host through the IP address of the service of the third container, the manner of forwarding the message by openflow generated according to the control rule in the related art is abandoned, the processing logic of the IP address of the service of the container in the OVS is abandoned, the process of connection request and the process of request response between the first container and the second container are realized through the pre-configured route, and the address conversion process is only for the source address of the connection request and the destination address of the request response, and does not perform address conversion on the destination address of the connection request and the original address of the request response, so that the source address of the request response received by the first container is consistent with the destination address of the connection request sent by the first container, the problem that the address information is inconsistent when the connection is established between the IP address of the container network card of the container and the container in the cluster is solved, and the normal operation of connection and the access between the containers is ensured.

Based on the same inventive concept, according to the request processing method provided by the embodiment of the application, the embodiment of the application also provides a request processing system. As shown in fig. 11, fig. 11 is a schematic structural diagram of a request processing system according to an embodiment of the present application. The system includes a first host 1101, the first host 1101 including a first container 1102, a second container 1103, and a first OVS 1104;

the first container 1102 may be configured to send, when a connection needs to be established with the second container 1103 through an IP address of a container network card of the second container 1103, a first connection request to the second container 1103 through a first OVS 1104 based on a first route configured in advance, where a destination address of the first connection request is a first IP address of the second container 1103, and a next hop of the first route is an IP address of the container network card of the second container 1103;

the second container 1103 may be configured to generate a first request response of the first connection request after receiving the first connection request, and send the first request response to the first container 1102 through the first OVS 1104 based on a second route configured in advance, where a next hop of the second route is an IP address of a container network card of the first container 1102;

The first container 1102 may be further configured to determine, based on the received first request response, to establish a connection with the second container 1103.

Optionally, the first host 1101 may further include a host gateway 1105;

the first container 1102 may be further configured to send, when a connection needs to be established with the second container 1103 through an IP address of a service of the second container 1103, a second connection request to the host gateway 1105 through the first OVS 1104 based on a third route configured in advance, where a destination address of the second connection request is the IP address of the service of the second container 1103, and a network mask in the third route indicates that the service network and a next hop are gateway addresses of the host gateway 1105;

the host gateway 1105 may be configured to forward the second connection request to the second container 1103 according to a pre-stored correspondence between the service IP address and the container network card IP address, and a destination address of the second connection request;

the second container 1103 may be further configured to generate a second request response of the second connection request after receiving the second connection request, and send the second request response to the host gateway 1105 through the first OVS 1104 based on a fourth route configured in advance and corresponding to the third route, where a destination address of the second request response is an IP address of a container network card of the first container 1102, and a next hop of the fourth route is a gateway address of the host gateway 1105;

The host gateway 1105 may be further configured to send a second request response to the first container 1102 according to the destination address of the second request response;

the first container 1102 may be further configured to determine, based on the received second request response, to establish a connection with the second container 1103.

Optionally, the first host 1101 may further include a first host network card 1106, the request processing system may further include a second host 1107, the second host 1107 includes a third container 1108, a second OVS 1109, and a second host network card 1110, and the first host 1101 and the second host 1107 are communicatively connected through a preset switch 1111;

the first container 1102 may be further configured to send, when a connection needs to be established between the IP address of the container network card of the third container 1108 and the third container 1108, a third connection request to the first host network card 1106 through the first OVS 1104 based on a fifth preset route, where a destination address of the third connection request is an IP address of the container network card of the third container 1108, a destination address of the fifth route is an IP address of the container network card of the third container 1108, and an output interface is an interface of the container network card of the first container 1102;

the first host network card 1106 may be configured to forward, through a preset switch, the received third connection request to the second host network card 1110;

The second host network card 1110 may be configured to send a third connection request to the third container 1108 through the second OVS 1109 based on the destination address of the received third connection request;

the third container 1108 may be configured to generate a third request response of the third connection request after receiving the third connection request, and send the third request response to the second host network card 1110 through the second OVS 1109 based on a sixth pre-configured route, where a destination address of the third request response is an IP address of a container network card of the first container 1102, a destination address of the sixth route is an IP address of a container network card of the first container 1102, and an interface of the container network card of the third container 1108 is output;

the second host network card 1110 may be further configured to forward, through a preset switch, the received third request response to the first host network card 1106;

the first host network card 1106 may be further configured to send a third request response to the first container through the first OVS based on the destination address of the received third connection request;

the first container 1102 may be further configured to determine, based on the received third request response, to establish a connection with the third container 1108.

Optionally, the first host 1101 may further include a third host network card 1112;

the first container 1102 may be further configured to send, when a connection needs to be established with the third container 1108 through an IP address of a service of the third container 1108, a fourth connection request to the host gateway 1105 through the first OVS 1104 based on a third route configured in advance, where a destination address of the fourth connection request is the IP address of the service of the third container 1108, and a network mask in the third route indicates that the service network and a next hop is a gateway address of the host gateway 1105;

the host gateway 1105 may be further configured to convert, according to a preset address conversion rule, a source address of the fourth connection request to an IP address of the third host network card 1112 based on the received destination address of the fourth connection request, to obtain a fifth connection request, and forward the fifth connection request to the third host network card 1112;

the third host network card 1112 may be configured to forward, based on a seventh pre-configured route, the received fifth connection request to the third container 1108 through the preset switch and the second OVS 1109, where an output interface of the seventh route is an interface of the third host network card 1112, and a destination address is an IP address of a container network card of the third container 1108;

The third container 1108 may be further configured to generate a fourth request response of the fifth connection request after receiving the fifth connection request, send the fourth request response to the third host network card 1112 through the second OVS 1109 and the preset switch based on an eighth route, where an outgoing interface of the eighth route is an interface of a container network card of the third container 1108, and a destination address is an IP address of the third host network card 1112;

the third host network card 1112 may be further configured to send a fourth request response to the host gateway 1105 according to a ninth route, where a next hop of the ninth route is a gateway address of the host gateway 1105;

the host gateway 1105 may be further configured to, after receiving the fourth request response, convert, according to a preset address conversion rule, a destination address of the fourth request response into an IP address of a container network card of the first container 1102, obtain a fifth request response, and send the fifth request response to the first container 1102 through the first OVS 1104;

the first container 1102 may be further configured to determine, based on the received fifth request response, to establish a connection with the third container 1108.

According to the system provided by the embodiment of the application, when the first container establishes connection with the second container through the IP address of the container network card of the second container, the first connection request is sent to the second container based on the preconfigured first route, namely, the IP address link route of the container network card of which the next hop is the second container. The second container sends a first request response to the first container based on a pre-configured second route, i.e., a link route of the IP address of the container network card of which the next hop is the first container, in response to the first connection request, thereby completing connection establishment.

Based on the same inventive concept, according to the request processing method provided in the above embodiments of the present application, the embodiments of the present application further provide a computer readable storage medium, where a computer program is stored, and when the computer program is executed by a processor, the steps of any one of the request processing methods are implemented.

Based on the same inventive concept, according to the request processing method provided in the above embodiments of the present application, the embodiments of the present application further provide a computer program product containing instructions, which when executed on a computer, cause the computer to perform any one of the request processing methods in the above embodiments.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions in accordance with embodiments of the present application are produced in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in or transmitted from one computer-readable storage medium to another, for example, by wired (e.g., coaxial cable, fiber optic, digital Subscriber Line (DSL)), or wireless (e.g., infrared, wireless, microwave, etc.) means from one website, computer, server, or data center. Computer readable storage media can be any available media that can be accessed by a computer or data storage devices, such as servers, data centers, etc., that contain an integration of one or more available media. The usable medium may be a magnetic medium (e.g., floppy Disk, hard Disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid State Disk (SSD)), etc.

It is noted that relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises an element.

In this specification, each embodiment is described in a related manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for embodiments of the system, computer readable storage medium, and computer program product, which are substantially similar to method embodiments, the description is relatively simple, and reference should be made to the description of method embodiments for relevant points.

The foregoing is merely a preferred embodiment of the present application, and is not intended to limit the scope of the present application. Any modifications, equivalent substitutions, improvements, etc. that are within the spirit and principles of the present application are intended to be included within the scope of the present application.

Claims

1. A method of request processing, applied to a target cluster, the target cluster comprising a first host, the first host comprising a first container, a second container, and a first multi-layer virtual switch, OVS, the method comprising:

when connection is required to be established between the Internet Protocol (IP) address of the container network card of the second container and the second container, the first container sends a first connection request to the second container through the first OVS based on a preconfigured first route, wherein the destination address of the first connection request is the IP address of the container network card of the second container, and the next hop of the first route is the IP address of the container network card of the second container;

The first container determines to establish a connection with the second container based on the received first request response;

the first host also comprises a host gateway;

the method further comprises the steps of:

2. The method of claim 1, wherein the first host further comprises a first host network card, the target cluster further comprises a second host, the second host comprises a third container, a second OVS, and a second host network card, the first host and the second host are communicatively coupled through a preset switch;

the method further comprises the steps of:

3. The method of claim 2, wherein the first host further comprises a third host network card and a host gateway;

The method further comprises the steps of:

After receiving the fifth connection request, the third container generates a fourth request response of the fifth connection request, and sends the fourth request response to the third host network card through the second OVS and the preset switch based on an eighth route, wherein an output interface of the eighth route is an interface of a container network card of the third container, and a destination address is an IP address of the third host network card;

4. A request processing system, the system comprising a first host, the first host comprising a first container, a second container and a first multi-layer virtual switch OVS;

The first container is configured to send, when connection is required to be established with the second container through an Internet Protocol (IP) address of a container network card of the second container, a first connection request to the second container through the first OVS based on a first route configured in advance, where a destination address of the first connection request is an IP address of the container network card of the second container, and a next hop of the first route is an IP address of the container network card of the second container;

the first container is further configured to determine, based on the received first request response, to establish a connection with the second container;

the first host also comprises a host gateway;

5. The system of claim 4, wherein the first host further comprises a first host network card, the system further comprises a second host comprising a third container, a second OVS, and a second host network card, the first host and the second host communicatively coupled through a preset switch;

6. The system of claim 5, wherein the first host further comprises a third host network card and a host gateway;

the third container is further configured to generate a fourth request response of the fifth connection request after receiving the fifth connection request, and send the fourth request response to the third host network card through the second OVS and the preset switch based on an eighth route, where an outgoing interface of the eighth route is an interface of a container network card of the third container, and a destination address is an IP address of the third host network card;