CN107070691B - Cross-host communication method and system for Docker containers - Google Patents

Abstract

The present application provides a method and system for cross-host communication of a Docker container. The method includes: controlling Docker to create an OVS network bridge after starting; the controlling Docker acquiring network configuration information of the application Docker after detecting that the application Docker on the host is started; the controlling Docker configuring the network The information is sent to the distributed coordination service for storage, and the distributed coordination service is used to maintain the network configuration information of applying Docker on each host in the network; the control Docker is monitoring the distributed coordination service. The network of applying Docker When the configuration information is updated, a forwarding flow table is generated according to the updated network configuration information; the control Docker issues the forwarding flow table to the OVS bridge; the OVS bridge instructs the application Docker according to the forwarding flow table cross-host communication between them.

Description

Cross-host communication method and system for Docker containers

technical field

The present application relates to the field of communication technologies, and in particular, to a method and system for cross-host communication of a Docker container.

Background technique

Docker Container is an open source application container engine that allows developers to package their applications and dependencies into a portable container, which can then be distributed to any popular Linux machine, and can also be virtualized.

In related technologies, the Docker container natively provides three network models, namely bridge, host, and none. Among them, the bridge model and the none model cannot realize cross-host communication of Docker containers. Although the host model can realize cross-host communication, it cannot achieve network isolation between Docker containers on the same host at the same time.

SUMMARY OF THE INVENTION

In view of this, the present application provides a method and system for cross-host communication of Docker containers.

Specifically, the application is achieved through the following technical solutions:

A cross-host communication method for a Docker container, the method comprising:

Control Docker to create an OVS bridge after startup;

The control Docker obtains the network configuration information of the application Docker after detecting that the application Docker on the host is started;

The control Docker sends the network configuration information to a distributed coordination service for storage, and the distributed coordination service is used to maintain the network configuration information of Docker applied on each host in the networking;

The control Docker generates a forwarding flow table according to the updated network configuration information when monitoring the update of the network configuration information of the application Docker in the distributed coordination service;

The control Docker sends the forwarding flow table to the OVS bridge;

The OVS bridge guides the cross-host communication between the application Dockers according to the forwarding flow table.

A cross-host communication system of a Docker container, the system comprising: controlling Docker, an OVS bridge and applying Docker, wherein,

After the control Docker is started, the OVS bridge is created;

The control Docker obtains the network configuration information of the application Docker after detecting that the application Docker on the host is started;

The control Docker sends the network configuration information to a distributed coordination service for storage, and the distributed coordination service is used to maintain the network configuration information of Docker applied on each host in the networking;

The control Docker generates a forwarding flow table according to the updated network configuration information when monitoring the update of the network configuration information of the application Docker in the distributed coordination service;

The control Docker sends the forwarding flow table to the OVS bridge;

The OVS bridge guides the cross-host communication between the application Dockers according to the forwarding flow table.

It can be seen from the above description that the application can maintain the network configuration information of Docker in the networking through the distributed coordination service, and the control Docker can generate a forwarding flow table for the started application Docker in time by monitoring the distributed coordination service. It is sent to the OVS bridge to guide forwarding, which realizes cross-host communication between applications and Docker. At the same time, the distributed coordination service is used to maintain the network configuration information of the application Docker, which is simpler and more reliable than the Gossip protocol.

Description of drawings

FIG. 1 is a schematic diagram of a Docker Overlay network architecture in the related art.

FIG. 2 is a schematic flowchart of a cross-host communication method for a Docker container according to an exemplary embodiment of the present application.

FIG. 3 is a networking architecture diagram of cross-host communication of a Docker container according to an exemplary embodiment of the present application.

Detailed ways

Exemplary embodiments will be described in detail herein, examples of which are illustrated in the accompanying drawings. Where the following description refers to the drawings, the same numerals in different drawings refer to the same or similar elements unless otherwise indicated. The implementations described in the illustrative examples below are not intended to represent all implementations consistent with this application. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present application as recited in the appended claims.

The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to limit the application. As used in this application and the appended claims, the singular forms "a," "the," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It will also be understood that the term "and/or" as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in this application to describe various information, such information should not be limited by these terms. These terms are only used to distinguish the same type of information from each other. For example, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information without departing from the scope of the present application. Depending on the context, the word "if" as used herein can be interpreted as "at the time of" or "when" or "in response to determining."

In the related art, the cross-host communication of Docker can be realized through the DockerOverlay network. Please refer to the networking architecture shown in Figure 1. When creating an Overlay network, you can create a networknamespace on the host at the same time, then create a br0 bridge in this network namespace, and create a Vxlan (VirtualExtensible LAN, virtual extensible LAN) The virtual network device of the local area network) is connected to the br0 bridge, and the virtual network card eth0 inside the Docker container can also be connected to the br0 bridge.

The host host can manage the cluster relationship through the Gossip protocol. When a host host starts, other host hosts can receive a new node joining event. Through the relevant information of this event, the FDB (Forwarding DataBase) entry of the local br0 bridge can be updated. Please continue to refer to Figure 1. If Docker container 1 on host A accesses Docker container 3 on host B for the first time, since Docker container 1 does not have the MAC address of Docker container 3, the Linux kernel will send an L3 miss, and the kernel will send an L3 miss. It will be converted into an event notification to the user mode, and subsequently converted into a query request, and broadcast to other hosts in the Overlay network. Docker container 3 on host B will reply with its MAC address. Based on this process, Docker container 1 can obtain the MAC address of Docker container 3. Then, combined with the br0FDB table entry, Docker container 1 and Docker container 3 can communicate through Vxlan1.

However, the implementation of the above-mentioned Overlay network has the following problems:

1) The Overlay network of the Docker container requires that the Linux kernel version be at least 3.8 or above, and the currently popular low version (2.6.32) kernel cannot be supported, which leads to a small scope of application of the Overlay network.

2) The nodes of the Docker container Overlay network are discovered through the Gossip protocol. The Gossip protocol is a dynamic discovery protocol. When a new node joins, it needs to complete the information synchronization with the existing node, and also needs to update the FDB entry of the Vxlan device, which is less reliable.

3) The Docker container overlay network uses the broadcast ARP (Address Resolution Protocol, Address Resolution Protocol) request message to address the MAC address, and the ARP broadcast message will be transmitted in the cluster, consuming a certain network bandwidth. In addition, the Docker container needs to have a unique MAC address within the network, which increases the complexity of management.

4) There are two virtual network cards in the Docker container in the Docker container Overlay network, one is used for cross-host communication between Docker containers, and the other is used for mutual access with external networks, which increases the complexity of application processing.

5) The Docker container Overlay network does not support the multi-subnet architecture, and the subnet planning cannot be performed, and the flexibility is poor.

6) The Docker container Overlay network adopts the native Vxlan virtual device of Linux. The encapsulation of the Vxlan protocol requires the participation of the CPU of the host host, which increases the performance loss of the host host.

In view of the above problems, the present application provides a cross-host communication solution for Docker containers.

FIG. 2 is a schematic flowchart of a cross-host communication method for a Docker container according to an exemplary embodiment of the present application.

Please refer to FIG. 2, the cross-host communication method of the Docker container may include the following steps:

Step 201, after controlling Docker to start, create an OVS bridge.

In this embodiment, a control Docker may be configured in the host host for issuing the business Docker forwarding flow table, and the control Docker may be implemented by the CPU of the host host. Specifically, after the control Docker is started, an OVS (Open VSwitch) bridge can be created on the host host. In one example, controlling Docker can create the OVS bridge based on the CPU. In another example, when an OVS-supporting smart network card is configured in the host host, an OVS bridge can also be created in the smart network card to save CPU overhead.

In this embodiment, the low-version Linux kernel can also support the OVS technology, and the implementation of virtual interaction by using the OVS technology can effectively solve the problem of the limited scope of application of the overlay network.

Step 202: After detecting that the application Docker on the host is started, the control Docker acquires the network configuration information of the application Docker.

In this embodiment, after the Docker is controlled to start, the startup of the application Docker on the host can be detected through the plug-in mechanism between Dockers. After it is detected that the application Docker is started, the network configuration information of the application Docker can be obtained. Wherein, the network configuration information may include: application Docker ID, IP address, MAC address, OVS port, IP address of the host host, and the like.

Step 203: Control Docker to send the network configuration information to a distributed coordination service for storage, and the distributed coordination service is used to maintain the network configuration information of Docker applied on each host in the networking.

In this embodiment, after the control Docker obtains the network configuration information of the application Docker, the network configuration information can be sent to the distributed coordination service for storage. The distributed coordination service is usually an external service, which can be used to maintain the network configuration information of Docker applied on each host in the networking. The distributed coordination service may use zookeeper or the like, which is not particularly limited in this application.

In this embodiment, if the cross-host communication between Dockers is implemented based on the Vxlan protocol, the network configuration information usually also includes the Vxlan ID to which the application Docker belongs. Correspondingly, the distributed coordination service can realize the isolated storage of the application Docker network configuration information based on the Vxlan ID. The network configuration information is stored in the directory of its Vxlan ID to facilitate the management of the application Docker network configuration information.

Step 204: When monitoring the update of the network configuration information of the application Docker in the distributed coordination service, the Docker is controlled to generate a forwarding flow table according to the updated network configuration information.

In this embodiment, the controlling Docker may start a monitoring thread to monitor the update of the network configuration information of the application Docker in the distributed coordination service, wherein the update includes addition, modification, and the like. For example, if the network configuration information of the newly added application Docker in the distributed coordination service is monitored, the control Docker can generate a forwarding flow table according to the newly added network configuration information. If it is monitored that the network configuration information of the application Docker stored in the distributed coordination service is modified, the control Docker can also generate a forwarding flow table according to the modified network configuration information.

In this embodiment, the forwarding flow table includes network configuration information corresponding to the application Docker, such as: IP address, MAC address, and IP address of the host host where it is located.

Step 205, controlling Docker to deliver the forwarding flow table to the OVS bridge.

Step 206, the OVS bridge guides the cross-host communication between the application Dockers according to the forwarding flow table.

Based on the foregoing step 204, after controlling Docker to generate the forwarding flow table, it can send the forwarding flow table to the OVS bridge, and the subsequent OVS bridge can guide the cross-host communication between the application Dockers according to the forwarding flow table that has been issued, such as: Packet encapsulation, decapsulation, etc.

It can be seen from the above description that the application can maintain the network configuration information of Docker in the networking through the distributed coordination service, and the control Docker can generate a forwarding flow table for the started application Docker in time by monitoring the distributed coordination service. It is sent to the OVS bridge to guide forwarding, which realizes cross-host communication between applications and Docker. At the same time, the distributed coordination service is used to maintain the network configuration information of the application Docker, which is simpler and more reliable than the Gossip protocol.

The technical solution of the present application is described in detail below through three aspects: MAC address acquisition, service message forwarding, and external communication using Docker.

First, the application of Docker's MAC address acquisition

In this embodiment, before the application Docker communicates with the other application Docker, the MAC address of the other application Docker can be obtained through an ARP request message. After receiving the ARP request message, the OVS bridge may construct an ARP reply message based on the preset MAC address, and send the ARP reply message to the application Docker.

Please refer to the networking architecture shown in Figure 3. Suppose application Docker1 on host A sends ARP request packet 1 to request the MAC address of application Docker3 on host B. After OVS bridge 1 receives ARP request packet 1, It can be determined according to the destination IP address of the ARP request message 1 (that is, the IP address of the application Docker3) whether the ARP request message 1 is a cross-network segment ARP request message or an ARP request message on the same network segment. Specifically, if the destination IP address of the ARP request message 1 and the source IP address (that is, the IP address of the application Docker1) belong to the same network segment, it can be determined that the ARP request message 1 is an ARP request message on the same network segment, and the OVS bridge 1 can then construct an ARP response message 1 according to the preset pseudo MAC address, and send the ARP response message 1 to Docker1. Wherein, the pseudo MAC address may be set by an administrator, which is not particularly limited in this application.

Please continue to refer to Figure 3, assuming that the application Docker1 on the host host A sends an ARP request message 2 to request the MAC address of the application Docker4 on the host host B. After receiving the ARP request message 2, the OVS bridge 1 can request the ARP request according to the ARP request. The destination IP address of the packet 2 (that is, the IP address of the application Docker4) determines whether the ARP request packet 2 is an ARP request packet across the network segment or an ARP request packet on the same network segment. Specifically, if the destination IP address of the ARP request packet 2 and the source IP address (that is, the IP address of the application Docker1) belong to different network segments, it can be determined that the ARP request packet 2 is a cross-network segment ARP request packet, and the OVS bridge 1 can then construct an ARP response packet 2 according to the MAC address of the container gateway, and send the ARP response packet 2 to Docker1.

Based on the above description, in this example, for the application Docker, the MAC addresses of other Docker applications in the same network segment are fixed pseudo-MAC addresses, and the MAC addresses of Docker applications in different network segments are the MAC addresses of the container gateway. The ARP proxy mechanism is used to obtain the MAC address of the application Docker, which can avoid the transmission of ARP request packets across hosts in the cluster and save a lot of network bandwidth.

2. Service message forwarding

In this embodiment, after receiving the service message sent by the application Docker, the OVS bridge can query the host address information of the target application Docker in the forwarding flow table according to the destination IP address of the service message. Next, the OVS bridge can encapsulate the service message according to the queried host address information, and then send the encapsulated service message to the host where the target application Docker is located through the tunnel. Wherein, the target application Docker is the application Docker to which the business message is sent.

Please continue to refer to FIG. 3 , assuming that the OVS bridge 1 receives the service message sent by the application Docker1, the OVS bridge 1 can determine the target application Docker according to the destination IP address of the service message. Assuming that the destination IP address of the service packet is the IP address of the application Docker3, it can be determined that the target application Docker is Docker3. The OVS bridge 1 can query the network configuration information of the application Docker3 in the forwarding flow table, such as the IP address and Vxlan port of the host B where the application Docker3 is located. Based on the queried network configuration information of the host B, the OVS bridge 1 may perform Vxlan tunnel encapsulation on the service packet, and send the encapsulated service packet to the OVS bridge 2 of the host host B through the Vxlan tunnel.

It should be noted that this application takes the Vxlan protocol as an example for description, and in practical applications, it is not limited to the Vxlan protocol.

In this embodiment, after receiving the tunnel encapsulation service packet from other hosts, the OVS bridge may decapsulate the tunnel encapsulation service packet to obtain the decapsulated service packet. Based on the destination IP address of the service packet, the OVS bridge can query the real MAC address of the target application Docker in the forwarding flow table. The OVS bridge can modify the destination MAC address of the service packet to the real MAC address, and when determining that the service packet is a service packet on the same network segment, modify the source MAC address of the service packet to a pseudo-MAC address, when it is determined that the service packet is a cross-network segment service packet, the source MAC address of the service packet is modified to the MAC address of the container gateway. After the MAC address modification is completed, the OVS bridge can send the modified service message to the target application Docker.

Please continue to refer to FIG. 3 , still taking the above example as an example, after receiving the encapsulated service packet through the Vxlan tunnel, the OVS bridge 2 may perform decapsulation to restore the service packet. The OVS bridge 2 can query the forwarding flow table according to the destination IP address of the service packet (the IP address of the application Docker3) to query the real MAC address of the application Docker3, and modify the destination MAC address of the service packet to the application of Docker3. real MAC address. For the source MAC address of the service packet, before modifying it, OVS bridge 2 also needs to determine the subnet. If the service packet is a service packet on the same network segment (the IP addresses of application Docker1 and application Docker3 belong to the same network segment), the source MAC address of the service packet can be changed to a pseudo MAC address. If the service packet is a cross-network segment service packet (the IP addresses of application Docker1 and application Docker3 belong to different network segments), the source MAC address of the service packet can be changed to the MAC address of the container gateway. The OVS bridge 2 can send the service message with the modified MAC address to the application Docker3 to implement cross-host communication between the application Docker1 and the application Docker3.

It can be seen from the above description that the cross-host communication solution of the Docker container provided by the present application can support the planning of the subnet and improve the flexibility of the business.

It should be noted that the encapsulation and forwarding of the above-mentioned service packets may be implemented through a virtual device established on the OVS bridge. Specifically, after controlling Docker to create an OVS bridge, it can also create a Vxlan device and a Veth device on the OVS bridge, where the Vxlan device can be used for encapsulation and decapsulation of service packets, and the Veth device can be used for Implement container gateway functions, etc. For the processing and implementation of this part, reference may be made to the related art, which will not be repeated here in this application.

3. Apply Docker external communication

In this embodiment, a forwarding flow entry with the lowest priority may be preconfigured, and the forwarding flow entry may be: the destination MAC address is the address of the container gateway MAC and forwarded to the virtual host gateway. Specifically, after receiving the service packet sent by the application Docker, if the OVS bridge determines that the destination MAC address of the service packet is the MAC address of the container gateway and matches the forwarding flow entry with the lowest priority, it can It is determined that the service packet is a service packet that needs to be sent to the external network. The OVS bridge can send the service packet to the virtual host gateway, and the virtual host gateway combines the iptable snat or dnat to send the service packet. Send to external network.

Specifically, after controlling Docker to create an OVS bridge, the address of the container gateway can be configured into the virtual host gateway. Subsequently, if the OVS bridge receives a service packet that matches the forwarding flow entry with the lowest priority, it can determine that the service packet is a service packet sent to an external network, and can then use the container gateway to send the service packet to the external network. Sent to the virtual host gateway, and sent by the virtual host gateway to the external network. On the contrary, if the OVS bridge receives a service packet from the virtual host gateway, it can modify the source MAC address of the service packet to the MAC address of the container gateway and send it to the corresponding application Docker.

It can be seen from the above description that the present application can simultaneously realize the cross-host communication between the application Docker and the communication between the application Docker and the external network through the container gateway, without the need to configure two virtual network cards, and the processing is simpler for the application.

Corresponding to the foregoing embodiments of the cross-host communication method of the Docker container, the present application also provides an embodiment of the cross-host communication system of the Docker container. The cross-host communication system of the Docker container may include: controlling Docker, an OVS bridge, and applying Docker.

Wherein, after the control Docker is started, the OVS bridge is created;

The control Docker obtains the network configuration information of the application Docker after detecting that the application Docker on the host is started;

The control Docker sends the network configuration information to a distributed coordination service for storage, and the distributed coordination service is used to maintain the network configuration information of Docker applied on each host in the networking;

The control Docker generates a forwarding flow table according to the updated network configuration information when monitoring the update of the network configuration information of the application Docker in the distributed coordination service;

The control Docker sends the forwarding flow table to the OVS bridge;

The OVS bridge guides the cross-host communication between the application Dockers according to the forwarding flow table.

Optionally, the OVS bridge receives the ARP request message sent by the application Docker;

If the OVS bridge determines that the ARP request message is a cross-network segment ARP request message, it constructs an ARP response message based on the MAC address of the container gateway, and returns it to the application Docker;

If the OVS bridge determines that the ARP request message is an ARP request message on the same network segment, it constructs an ARP reply message based on the preset pseudo-MAC address, and returns it to the application Docker.

Optionally, after receiving the service message sent by the application Docker on the host, the OVS bridge queries the host address information of the target application Docker in the forwarding flow table according to the destination IP address of the service message in the forwarding flow table. ;

The OVS bridge encapsulates the service message according to the host address information, and sends the encapsulated service message to the host where the target application Docker is located through a tunnel.

Optionally, after receiving the tunnel encapsulation service packet from other hosts, the OVS bridge decapsulates the tunnel encapsulation service packet;

The OVS bridge queries the real MAC address of the target application Docker in the forwarding flow table according to the destination IP address of the decapsulated service message;

The OVS bridge modifies the destination MAC address of the decapsulated service message to the real MAC address, and when it is determined that the decapsulated service message is a service message on the same network segment, the service message The source MAC address of the service packet is modified to the pseudo MAC address, and when it is determined that the decapsulated service packet is a cross-network segment service packet, the source MAC address of the service packet is modified to the MAC address of the container gateway;

The OVS bridge sends the modified service message to the target application Docker.

Optionally, after receiving the service message sent by the application Docker on the host, if the OVS bridge determines that the service message matches the forwarding flow entry with the lowest priority, the OVS bridge sends the service message to a virtual host gateway, where the virtual host gateway sends the service message to an external network;

The forwarding flow entry with the lowest priority is to send the service packet whose destination MAC address is the MAC address of the container gateway to the virtual host gateway.

Optionally, the controlling Docker creates an OVS bridge in the smart network card.

Optionally, a Vxlan device and a Veth device are also created on the OVS bridge;

The Vxlan device is used for encapsulation and decapsulation of service packets, and the Veth device is used to implement the container gateway function.

The systems, devices, modules or units described in the above embodiments may be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementing device is a computer, which may be in the form of a personal computer, laptop computer, cellular phone, camera phone, smart phone, personal digital assistant, media player, navigation device, email sending and receiving device, game control desktop, tablet, wearable device, or a combination of any of these devices.

The above descriptions are only preferred embodiments of the present application, and are not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application shall be included in the present application. within the scope of protection.

Claims (14)

1. A cross-host communication method of a Docker container, the method comprising:

controlling the Docker to create an OVS bridge after starting;

the control Docker acquires network configuration information of the application Docker after detecting that the application Docker on the host computer is started;

the control Docker sends the network configuration information to a distributed coordination service for storage, and the distributed coordination service is used for maintaining the network configuration information of the application Docker on each host computer in the networking;

when monitoring that the network configuration information of the application Docker in the distributed coordination service is updated, the control Docker generates a forwarding flow table according to the updated network configuration information;

the control Docker issues the forwarding flow table to the OVS network bridge;

and the OVS bridge guides the cross-host communication between application Dockers according to the forwarding flow table.

2. The method of claim 1, further comprising:

the OVS bridge receives an ARP request message sent by an application Docker;

if the OVS network bridge determines that the ARP request message is a cross-network-segment ARP request message, constructing an ARP response message based on the MAC address of the container gateway, and returning the ARP response message to the application Docker;

and if the OVS network bridge determines that the ARP request message is the same-network-segment ARP request message, constructing an ARP response message based on a preset pseudo MAC address, and returning the ARP response message to the application Docker.

3. The method of claim 2, further comprising:

after receiving a service message sent by an application Docker on a host, the OVS network bridge inquires host address information of a target application Docker to which the service message is to be sent in the forwarding flow table according to a destination IP address of the service message;

and the OVS network bridge encapsulates the service message according to the host address information, and sends the encapsulated service message to a host where a target application Docker to which the service message is to be sent is located through a tunnel.

4. The method of claim 3, further comprising:

after receiving tunnel encapsulation service messages from other hosts, the OVS network bridge decapsulates the tunnel encapsulation service messages;

the OVS network bridge inquires a real MAC address of a target application Docker to which the decapsulated service message is to be sent in the forwarding flow table according to the destination IP address of the decapsulated service message;

the OVS bridge modifies a target MAC address of the decapsulated service message into the real MAC address, modifies a source MAC address of the service message into the pseudo MAC address when determining that the decapsulated service message is a same-network-segment service message, and modifies the source MAC address of the service message into an MAC address of the container gateway when determining that the decapsulated service message is a cross-network-segment service message;

and the OVS network bridge sends the modified service message to a target application Docker to which the decapsulated service message is to be sent.

5. The method of claim 1, further comprising:

after receiving a service message sent by an application Docker on a host, the OVS network bridge sends the service message to a virtual host gateway if the service message is determined to be matched with a forwarding flow table entry with the lowest priority, and the virtual host gateway sends the service message to an external network;

and the forwarding flow table entry with the lowest priority sends the service message with the destination MAC address as the MAC address of the container gateway to the virtual host gateway.

6. The method of claim 1, wherein the creating an OVS bridge comprises:

an OVS bridge is created in an intelligent network card.

7. The method of claim 1,

vxlan equipment and Veth equipment are also established on the OVS bridge;

the Vxlan equipment is used for encapsulating and de-encapsulating the service message, and the Veth equipment is used for realizing the function of the container gateway.

8. A cross-host communication system for a Docker container, the system comprising: control Docker, OVS bridge, and application Docker, wherein,

after the control Docker is started, the OVS bridge is established;

the control Docker acquires network configuration information of the application Docker after detecting that the application Docker on the host computer is started;

the control Docker sends the network configuration information to a distributed coordination service for storage, and the distributed coordination service is used for maintaining the network configuration information of the application Docker on each host computer in the networking;

when monitoring that the network configuration information of the application Docker in the distributed coordination service is updated, the control Docker generates a forwarding flow table according to the updated network configuration information;

the control Docker issues the forwarding flow table to the OVS network bridge;

and the OVS bridge guides the cross-host communication between application Dockers according to the forwarding flow table.

9. The system of claim 8,

the OVS bridge receives an ARP request message sent by an application Docker;

if the OVS network bridge determines that the ARP request message is a cross-network-segment ARP request message, constructing an ARP response message based on the MAC address of the container gateway, and returning the ARP response message to the application Docker;

and if the OVS network bridge determines that the ARP request message is the same-network-segment ARP request message, constructing an ARP response message based on a preset pseudo MAC address, and returning the ARP response message to the application Docker.

10. The system of claim 9,

after receiving a service message sent by an application Docker on a host, the OVS network bridge inquires host address information of a target application Docker to which the service message is to be sent in the forwarding flow table according to a destination IP address of the service message;

and the OVS network bridge encapsulates the service message according to the host address information, and sends the encapsulated service message to a host where a target application Docker to which the service message is to be sent is located through a tunnel.

11. The system of claim 10,

after receiving tunnel encapsulation service messages from other hosts, the OVS network bridge decapsulates the tunnel encapsulation service messages;

the OVS network bridge inquires a real MAC address of a target application Docker to which the decapsulated service message is to be sent in the forwarding flow table according to the destination IP address of the decapsulated service message;

the OVS bridge modifies a target MAC address of the decapsulated service message into the real MAC address, modifies a source MAC address of the service message into the pseudo MAC address when determining that the decapsulated service message is a same-network-segment service message, and modifies the source MAC address of the service message into an MAC address of the container gateway when determining that the decapsulated service message is a cross-network-segment service message;

and the OVS network bridge sends the modified service message to a target application Docker to which the decapsulated service message is to be sent.

12. The system of claim 8,

after receiving a service message sent by an application Docker on a host, the OVS network bridge sends the service message to a virtual host gateway if the service message is determined to be matched with a forwarding flow table entry with the lowest priority, and the virtual host gateway sends the service message to an external network;

and the forwarding flow table entry with the lowest priority sends the service message with the destination MAC address as the MAC address of the container gateway to the virtual host gateway.

13. The system of claim 8,

and the control Docker creates an OVS bridge in the intelligent network card.

14. The system of claim 8,

vxlan equipment and Veth equipment are also established on the OVS bridge;

the Vxlan equipment is used for encapsulating and de-encapsulating the service message, and the Veth equipment is used for realizing the function of the container gateway.

Images