CN114301913A

CN114301913A - Request processing method and system

Info

Publication number: CN114301913A
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: 2022-04-08
Anticipated expiration: 2041-12-24
Also published as: CN114301913B

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 the first OVS based on a first route configured in advance, wherein 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 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 is solved, so that the connection establishment and the normal operation of the access between the containers are ensured.

Description

Request processing method and system

Technical Field

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

Background

Conteiv 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 mainstream container orchestration systems. Ovs (open vswitch) is a multi-layer virtual switch with industrial-grade quality.

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

Specifically, after monitoring the IP address of the container network card and the IP address of the service configured in the cluster, the contev updates the mapping table entry between the service and the container, and configures the mapping table entry into a 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. And the OVS adds the received control rule to the openflow flow table. The OpenFlow is a network communication protocol.

When a container (e.g., container a) in the cluster establishes a connection with container B through the IP address of the service of another container (e.g., container B), the OVS stores control rules including a rule for converting the source address of the request response into 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, 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, which causes that the connection cannot be established, and normal operation of access between containers is affected.

Disclosure of Invention

An object of the embodiments of the present application is to provide a request processing method and system, so as to solve the problem that address information is inconsistent when a connection is established between an IP address of a container network card of a container and the container in a cluster, thereby ensuring the establishment of the connection and normal operation of access between the 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, the first host comprises a first container, a second container and a first OVS, and the method comprises the following steps:

when connection with the second container needs to be established through the IP address of the container network card of the second container, the first container sends the first connection request to the second container through the first OVS based on a first route configured in advance, 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 route configured in advance, wherein a next hop of the second route is an IP address of a 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 following steps:

when connection needs 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 a next hop is a gateway address of the host gateway;

the host gateway forwards the second connection request to the second container according to a pre-stored corresponding relation between a service IP address and a container network card IP address and a 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 pre-configured fourth route 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 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 in communication connection through a preset switch;

the method further comprises the following steps:

when a connection needs 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, where a destination address of the third connection request is the IP address of the container network card of the third container, and a destination address of the fifth route is the IP address of the container network card of the third container, and an output interface is an 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 the third connection request to the third container through the second OVS based on the destination address of the received 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 pre-configured sixth route, wherein 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 an outgoing interface is an interface of the 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 the 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 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 following steps:

when connection needs 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 a 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 a service network and a next hop is a gateway address of the host gateway;

the host gateway converts a source address of the fourth connection request into an IP address of the third host network card according to a preset address conversion rule based on a destination address of the received 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 preconfigured 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 the 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, where an outgoing 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 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 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;

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, a second host and a first OVS, wherein the first host comprises a first container, a second container and a first OVS;

the first container is configured to send the first connection request to the second container through the first OVS based on a first route configured in advance when a connection needs to be established between the IP address of the container network card of the second container and the second container, 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 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 pre-configured route, 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 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 first container is further configured to send a second connection request to the host gateway through the first OVS based on a preconfigured third route when a connection needs to be established between the IP address of the service of the second container and the second container, where a 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 a service network and a next hop is a gateway address of the host gateway;

the host gateway is used for forwarding the second connection request to the second container according to a pre-stored corresponding relation between a 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 pre-configured fourth route 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 a destination address of the second request response;

the first container is further configured to determine 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 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 in communication connection through a preset switch;

the first container is further configured to send a third connection request to the first host network card through the first OVS based on a preset fifth route when a connection needs to be established between the IP address of the container network card of the third container and the third container, where a destination address of the third connection request is the IP address of the container network card of the third container, and a destination address of the fifth route is the IP address of the container network card of the third container and an output 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 the third connection request to the third container through the second OVS based on a destination address of the received third connection request;

the third container is configured to generate a third request response to 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 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 an outgoing interface is an interface of the container network card of the third container;

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

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

the first container is further configured to determine 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 first container is further configured to send a fourth connection request to the host gateway through the first OVS based on a preconfigured third route when a connection needs to be established between an IP address of a service of a third container and the third container, where a 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 a service network and a next hop is a gateway address of the host gateway;

the host gateway is further configured to convert a source address of the fourth connection request into an IP address of the third host network card according to a preset address conversion rule based on a destination address of the received fourth connection request, 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 a received fifth connection request to the third container through the preset switch and the second OVS based on a preconfigured seventh route, where an outgoing interface of the seventh route is an interface of the third host network card, and a destination address is an IP address of the container network card of the third container;

the third container is further configured to generate a fourth request response to 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 outgoing 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 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 a destination address of the fourth request response into an 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 send the fifth request response to the first container through the first OVS;

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

An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, and when being executed by a processor, the computer program implements any of the steps of the request processing method described above.

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

The embodiment of the application has the following beneficial effects:

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 container sends the first connection request to the second container based on the preconfigured first route, namely the IP address link route of the container network card with the next hop as the second container. And the second container sends the first request response to the first container based on a second route configured in advance when responding to the first connection request, namely the link route of the IP address of the container network card with the next hop being the first container, thereby completing the connection establishment.

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

Of course, not all advantages described above need to be achieved at the same time in the practice of any one product or method 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 drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and it is also obvious for a person skilled in the art to obtain other embodiments according to the drawings.

FIG. 1-a is a first schematic diagram of an inter-POD TCP connection establishment in a kubernets cluster;

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

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

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 according to 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 according to 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 according to 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 according to 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 technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments that can be derived by one of ordinary skill in the art from the description herein are intended to be within the scope of the present disclosure.

In the related art, in the cluster constructed by using the contev and the OVS, a Transmission Control Protocol (TCP) connection may be established between different containers through an IP address of a container network card of the container, or through an IP address TCP connection of a service corresponding to the container.

For ease of understanding, fig. 1-a and 1-b are illustrated as examples, respectively. Fig. 1-a is a first schematic diagram of establishment of a TCP connection between PODs in a kubernets cluster, and fig. 1-b is a second schematic diagram of establishment of a TCP connection between PODs in a kubernets cluster. Wherein, a kubernets (also called k8s) cluster is constructed by using Contiv and OVS, POD is the minimum management unit of kubernets, and each POD can contain one or more containers. Each container in the same POD will share the same namespace and local network and each container in the same POD can be mutually accessed through a local host (localhost), and thus each POD can be considered a container.

Assume now that the IP address of the container network card of POD1 in fig. 1-a and 1-b is: 10.86.36.10, respectively; 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 process shown in fig. 1-a, POD1 may establish a TCP connection with POD2 through the IP address of the service of POD 2. Specifically, a TCP request issued by POD1 will be transmitted to the OVS (i.e. stage 101 shown in fig. 1-a), where the destination address of the TCP request is the IP address of the service of POD 2. After the OVS performs address translation on the received TCP request, that is, the destination address of the TCP request is translated from the IP address of the service of the POD2 to the IP address of the container network card of the 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, the POD2 generates a corresponding TCP response having a source address of the IP address of the container network card of the POD2 and a destination address of the IP address of the container network card of the POD 1. The POD2 sends the TCP response to the OVS (i.e., stage 103 shown in fig. 1-a). The OVS performs address translation on the received TCP response, i.e. 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 sends the translated TCP response to POD1 (i.e. stage 104 shown in fig. 1-a).

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

TABLE 1

Phases	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 from the received TCP response that a TCP connection is established with POD 2.

When the above OVS stores the rule of address conversion by the procedure shown in fig. 1-a, the POD1 cannot establish a TCP connection with the POD2 through the IP address of the container network card of the POD 2. Specifically, as shown in fig. 1-b, a TCP request issued by POD1 is transmitted to the OVS (i.e. stage 105 shown in fig. 1-b), and 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) according to the destination address.

After receiving the TCP request, the POD2 generates a corresponding TCP response having a source address of the IP address of the container network card of the POD2 and a destination address of the IP address of the container network card of the POD 1. POD2 sends the TCP response to the OVS (i.e., stage 107 shown in fig. 1-b). Since the OVS stores the address conversion rule for converting the source address in the TCP response message with the source address being 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 sends the converted TCP response to POD1 (i.e., stage 108 shown in fig. 1-b).

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

TABLE 2

Phases	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 from each other, 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, embodiments of the present application provide 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, reference is made to FIG. 2. Fig. 2 is a schematic structural diagram of a kubernets cluster provided in the embodiment of the present application.

In the target cluster (i.e., kubernets cluster) shown in fig. 2, the host 1 includes two containers (i.e., POD1 and POD2) and one OVS (i.e., OVS 1). Host 2 includes one container (i.e., POD3) 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 kubernets cluster is not particularly limited.

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

In this embodiment of the application, the target cluster may be a Docker cluster, in addition to the kubernets cluster. Wherein Docker is an open source container engine. The target cluster is not particularly limited. For convenience of understanding, the following description will be given only by taking the target cluster as a kubernets cluster, and is not intended to be limiting.

The following examples are given to illustrate the examples of the present application.

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

Step S301, when a connection between the IP address of the container network card of the second container and the second container is required, the first container sends a first connection request to the second container through the first OVS based on a first route configured in advance, 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.

In this embodiment, when the target cluster is constructed, for each container included in the same host in the target cluster, the link routes of the packet 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 first route of the IP address of the container network card of the second container configured in advance as a next hop, 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, the connection request may be the TCP connection request or the TCP access request. Here, the first connection request is not particularly limited.

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 the container network card of the first container.

After the first OVS forwards the first connection request to the second container, the second container receives the first connection request. At this time, the second container generates a request response (denoted as a first request response) of 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 of the IP address of the container network card of which the next hop is configured in advance as 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 received first request response is legal. The first container may determine to establish a connection with the second container.

In building the target cluster, the processing logic of the OVS for the IP address of the service is removed from the OVS of the host. 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 container may be any two containers among the 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 process described above is described in conjunction with fig. 2 and 4. Fig. 4 is a first signaling diagram of a connection establishment procedure according to an embodiment of the present application.

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

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

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

The 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.

Through 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 container sends the first connection request to the second container based on the preconfigured first route, that is, the IP address link route of the container network card whose next hop is the second container. And the second container sends the first request response to the first container based on a second route configured in advance when responding to the first connection request, namely the link route of the IP address of the container network card with the next hop being the first container, thereby completing the connection establishment.

In an optional 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.

Step S501, when a connection between the IP address of the service of the second container and the second container is required, 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 indicates a service network and a next hop is a gateway address of the host gateway.

In this embodiment of the present 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 (referred to as a third route) in which the network mask indicates the service network and the next hop is the gateway address of the host gateway may be configured in advance 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, 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 different IP address segments are different.

For the sake of understanding, the above second container is taken as an example for explanation, 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, since the IP address is in the address field corresponding to the service network, 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 pre-stored corresponding relationship between the service IP address and the IP address of the container network card 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, the host records a correspondence between a network card IP address of a container of each container and a service IP address of a service of each container. The host gateway may determine, according to the corresponding relationship and the destination address in the second connection request, the container network card IP address corresponding to the destination address, that is, the container network card IP address corresponding to the IP address of the service of the second container in the corresponding relationship (that is, the IP address of the container network card of the second container), in the second connection request received by the host gateway. At this time, the host network card may forward the received second connection request to the second container based on the IP address of the container network card.

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 pre-configured fourth route 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) whose next hop is a gateway address of the host gateway, is configured.

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

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 a destination address of the second request response, that is, an 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, at this time, 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 process described above is described in conjunction with fig. 2 and 6. Fig. 6 is a second signaling diagram of a connection establishment procedure according to an embodiment of the present application.

In the request processing method shown in fig. 5, only a procedure of establishing a connection with a different container within 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 still described as an example.

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

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

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

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

The 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 POD 2.

Through the method shown in fig. 5, when the first container establishes connection with the second container through the IP address of the service of the second container, the method of forwarding a message according to openflow generated by a control rule in the related art is abandoned, processing logic for the IP address of the service of the container in the OVS is abandoned, and a process of a connection request between the first container and the second container and a process of a request response are implemented through a preconfigured route, in which no address conversion is performed, so that a source address of the second request response received by the first container is consistent with a destination address of the first connection request sent by the first container, and a problem that address information is inconsistent when the IP address of the network card of the container in the cluster is established with the container is solved, thereby ensuring normal operation of connection establishment and access between containers.

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 in communication connection through a preset switch.

In an optional embodiment, based on the first host network card and the second host, an embodiment of the present 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.

Step S701, when a connection needs 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 pre-configured route, where a destination address of the third connection request is the IP address of the container network card of the third container, a destination address of the fifth route is the IP address of the container network card of the third container, and an output interface is an interface of the container network card of the first container.

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

When the first host needs to establish a connection with the third container across hosts 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. And the first OVS forwards the received third connection request to a 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 the 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 master network card in the first host. The first host may switch the main network card and the standby network card through a network card binding (binding) switching mode. Here, the network card binding mode of the host network card in the first host is not specifically described.

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 receiving the third connection request, the first host network card may forward the third connection request to the preset switch according to the destination address of the third connection request. And the preset switch 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, and is not specifically described herein.

Step S703 is that 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 a destination address of the third connection request, and the second OVS forwards 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 to 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 an outgoing interface is an interface of the container network card of the third container.

After receiving the third connection request, the third container may generate a request response (denoted as a third request response) of 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 present application, in the target cluster for constructing the target, a host route from a container route to a host network card is preconfigured for a scenario where different containers establish connections across hosts. For example, the IP address of the container network card whose destination address is the first container may be previously arranged in the third container, and the host route (referred to as a sixth route) whose egress interface is the interface of the container network card of the third container may be arranged in the third container.

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 forwards 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 a destination address of the third request response. And the preset switch forwards the third request response to the first host network card according to the destination address of the third request response.

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 a destination address of the third request response, and 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, and at this time, 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 network bridge connecting the first container and the first host network card, and the second OVS is a network bridge connecting the third container and the second host network card.

For ease of understanding, the above connection establishment process is described in conjunction with fig. 2 and 8 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 containers in different hosts through the IP addresses of the container network cards of the containers is involved. Therefore, the description will be made only by taking the connection establishment procedure between the POD1 included in the host 1 and the POD3 included in the host 2 in fig. 2 described above as an example.

In fig. 8, POD1 sends request 3 to OVS1 based on the fifth route described above, and OVS1 forwards 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.

And 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.

Host network card 2 forwards received request 3 to OVS 2. OVS2 forwards received request 3 to POD 3. 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 switch according to the destination address of the response 3.

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

Host network card 1 forwards the received response 3 to OVS 1. OVS1 forwards received response 3 to POD 1. The POD1, upon receiving response 3, determines that the source address of the received response 3 is the same as the destination address of its sent request 3. At which point POD1 may determine to establish a connection with POD 3.

Through the method shown in fig. 7, when the connection is established between the host and the third container across the IP address of the container network card of the third container, both the connection request process and the request response process are message-forwarded based on the preconfigured routing information, 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, and the problem of inconsistency of the address information 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, thereby ensuring the establishment of the connection and the normal operation of the access between the containers.

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.

Step S901, when a connection needs to be established between the IP address of the service in 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, where a destination address of the fourth connection request is the IP address of the service in 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.

In this step, when the first container needs to establish a connection with the third container across 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 third route. And 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 destination address of the received fourth connection request, obtains a fifth connection request, and forwards the fifth connection request to the third host network card.

In the embodiment of the present application, in constructing the target cluster, two networks, namely an infrastructure (infra) network and a data (data) network, are created in the management plane. The ifra Network is a base for carrying a container access host and an external Network, the ifra Network can support Virtual Local Area Network (VLAN) and Virtual extended Local Area Network (VXLAN) types, and the data Network is a Network to which containers (such as the above-mentioned POD) are connected, and allocates corresponding address pools to the ifra Network and the data Network.

In the data network building process, preset address translation rules, such as an internet protocol Virtual Server (IP Virtual Server) rule and a firewall (iptables) rule that controls access to linux, may be configured in the host of the target cluster. The linux is an operating system kernel. The ipv rule and the iptables rule are used for performing address translation on the first message in different modes, so that the message can be transmitted from the host gateway to the host network card.

In addition, an iptables filter INPUT rule is also configured in the host of the target cluster. The iptables filter INPUT rule is a rule for filtering a message in a filtering (filter) table of the iptables rule, and the iptables filter INPUT rule is used for putting through a message received from a host gateway, so that the message can flow into a service in the host through the host gateway on the host, for example, into each container in the host. For example, the iptables filter INPUT rule can be used in the forwarding process of the host gateway for the second connection request and the second request response in fig. 5, and the forwarding process of the host gateway for the fifth connection request and the fifth request response in fig. 9.

The host gateway may perform address translation on a source address of the fourth connection request according to the ipv rule or the iptables rule after receiving the fourth connection request. That is, the source address of the fourth connection request is converted into the IP address of the third host network card, and the fifth connection request is obtained. And 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 an IP address of the third host network card, and the destination address is an IP address of the service of the third container.

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

And step S903, forwarding the received fifth connection request to a third container through a preset switch and a second OVS by the third host network card based on a preconfigured 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 the container network card of the third container.

In this embodiment of the present application, in the above-mentioned Infra network construction process, a direct route between a certain host node and a container in another host is created in each host of the target cluster. For example, a direct route (denoted as a seventh route) having an outgoing interface as an interface of a network card of the third host and a destination address as an IP address of a container network card of the third container is configured in advance in the first host.

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. And forwarding the received fifth connection request to the second OVS by the preset switch. 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 to 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, where an outgoing 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.

After receiving the fifth connection request, the third container may generate a request response (denoted as a fourth request response) of 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 network card of the third host.

In this embodiment of the present application, in the above-mentioned Infra network construction process, a direct route between a certain host node and a container in another host is created in each host of the target cluster. For example, the second host is configured with an interface of a container network card whose egress interface is a third container in advance, and the destination address is an IP address of the third host network card (denoted as an eighth route).

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. And the second OVS forwards the received fourth request response to the preset switch. And the preset switch forwards the received fourth request response to the third host network card.

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

In the embodiment of the present application, in each host of the target cluster, a direct 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 route of the gateway address of the host gateway (denoted as a ninth route).

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, obtains 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 translation on the destination address in the fourth request response according to the preset address translation rule, that is, the ipv 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, and at this time, 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 process described above is described in conjunction with 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 process shown in fig. 9, only the process of establishing a connection through the IP address of the container's service in different hosts is involved. Therefore, the description will be made only by taking the connection establishment procedure between the POD1 included in the host 1 and the POD3 included in the host 2 in fig. 2 described above 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 ipv rule or 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 pre-provisioned switch forwards the received request 5 to the OVS 2.

OVS2 forwards received request 5 to POD 3. 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. OVS2 forwards received response 4 to the pre-set switch.

The pre-set switch 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 translation on the response 4 according to the ipv rule or 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 POD 1.

Through the method shown in fig. 9, when the IP address of the service of the third container is connected to the third container across the host, the method of forwarding a message according to openflow generated by a control rule in the related art is abandoned, the processing logic for processing the IP address of the service of the container in the OVS is abandoned, and the process of a connection request between the first container and the second container and the process of a request response are realized through a preconfigured route, and the address translation process is only to perform address translation on the source address of the connection request and the destination address of the request response, and does not perform address translation 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, and the problem that the address information is inconsistent when the IP address of the network card of the container in the cluster is connected to the container is solved, thereby ensuring the establishment of the connection and the normal proceeding of the access between the containers.

Based on the same inventive concept, according to the request processing method provided by the embodiment of the present application, the embodiment of the present application further 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 comprises a first host 1101, the first host 1101 comprising a first container 1102, a second container 1103 and a first OVS 1104;

the first container 1102 may be configured to, when a connection needs to be established with the second container 1103 through the IP address of the container network card of the second container 1103, send a first connection request to the second container 1103 through the first OVS 1104 based on a first route configured in advance, where a destination address of the first connection request is the 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 to 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 to establish a connection with the second container 1103 based on the received first request response.

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

the first container 1102 may be further configured to, when a connection needs to be established between the IP address of the service of the second container 1103 and the second container 1103, send a second connection request to the host gateway 1105 through the first OVS 1104 based on a preconfigured third route, 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 a service network and a next hop is a gateway address 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 to 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 pre-configured fourth route 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 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 a destination address of the second request response;

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

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 in communication connection through a preset switch 1111;

the first container 1102 may also be configured to, 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, send a third connection request to the first host network card 1106 through the first OVS 1104 based on a preset fifth route, where a destination address of the third connection request is the IP address of the container network card of the third container 1108, and a destination address of the fifth route is the 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 the received third connection request to the second host network card 1110 through a preset switch;

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 a destination address of the received third connection request;

the third container 1108 may be configured to generate a third request response to 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 the container network card of the first container 1102, a destination address of the sixth route is an IP address of the container network card of the first container 1102, and an outgoing interface is an interface of the container network card of the third container 1108;

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

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 to establish a connection with the third container 1108 based on the received third request response.

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

the first container 1102 may be further configured to, when a connection needs to be established between the IP address of the service in the third container 1108 and the third container 1108, send a fourth connection request to the host gateway 1105 through the first OVS 1104 based on a preconfigured third route, where a destination address of the fourth connection request is the IP address of the service in the third container 1108, and a network mask in the third route indicates a 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, based on the destination address of the received fourth connection request, the source address of the fourth connection request into the IP address of the third host network card 1112 according to a preset address conversion rule, so as 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 the received fifth connection request to the third container 1108 through the preset switch and the second OVS 1109 based on a preconfigured seventh route, 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 the container network card of the third container 1108;

the third container 1108 may also be configured to generate a fourth request response to the fifth connection request after receiving the fifth connection request, and 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 the 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 the destination address of the fourth request response into the IP address of the container network card of the first container 1102 according to the preset address conversion rule, 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 to establish a connection with the third container 1108 based on the received fifth request response.

With the system provided in the embodiment of the present application, 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 container sends the first connection request to the second container based on the preconfigured first route, that is, the IP address link route of the container network card whose next hop is the second container. And the second container sends the first request response to the first container based on a second route configured in advance when responding to the first connection request, namely the link route of the IP address of the container network card with the next hop being the first container, thereby completing the connection establishment.

Based on the same inventive concept, according to the request processing method provided in the embodiment of the present application, the embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, and the computer program, when executed by a processor, implements the steps of any one of the request processing methods described above.

Based on the same inventive concept, according to the request processing method provided in the embodiments of the present application, the embodiments of the present application also provide a computer program product containing instructions, which when run on a computer, causes the computer to execute any one of the request processing methods in the embodiments.

In the above embodiments, the implementation may be wholly or partially realized 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. The procedures or functions according to the embodiments of the present application are all or partially generated when the computer program instructions are loaded and executed on a computer. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wire (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wirelessly (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the 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)), among others.

It is noted that, herein, relational terms such as first and second, and the like may be 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. Also, 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 an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.

All the embodiments in the present specification are described in a related manner, and the same and similar parts among the embodiments may be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for embodiments such as the system, the computer-readable storage medium, and the computer program product, since they are substantially similar to the method embodiments, the description is simple, and the relevant points can be referred to the partial description of the method embodiments.

The above description is only a preferred embodiment of the present application, and is not intended to limit the scope of the present application. Any modification, equivalent replacement, improvement and the like made within the spirit and principle of the present application are included in the protection scope of the present application.

Claims

1. A request processing method 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 with the second container needs to be established through an Internet Protocol (IP) address of the container network card of the second container, the first container sends the first connection request to the second container through the first OVS based on a first route configured in advance, wherein 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;

2. The method of claim 1, wherein the first host further comprises a host gateway;

the method further comprises the following steps:

3. 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, and the first host and the second host are communicatively connected through a preset switch;

the method further comprises the following steps:

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

the method further comprises the following steps:

5. A request processing system, characterized in that the system comprises a first host comprising a first container, a second container and a first multi-layer virtual switch, OVS;

the first container is configured to send the first connection request to the second container through the first OVS based on a preconfigured first route when a connection needs to be established with the second container through an internet protocol IP address of a container network card of the second container, 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;

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

7. The system of claim 5, wherein the first host further comprises a first host network card, the system further comprises a second host, the second host comprises 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;

8. The system of claim 7, wherein the first host further comprises a third host network card;