Network transmission method and device based on container environment, storage medium and product

Abstract

The embodiment of the invention provides a network transmission method and device based on a container environment, a storage medium and a product, and the method comprises the steps: receiving a deployment request for deploying a first container in a server, enabling the server to configure a plurality of physical network cards, and enabling each physical network card to be configured in a different network namespace, the network namespace comprises a system network namespace and at least one private network namespace; determining a target physical network card required to be used by the first container, and adding the first container into a target network namespace corresponding to the target physical network card; and controlling the first container to perform data transmission with a target device accessing the first container through the target physical network card in the target network namespace. The isolation among the multiple physical network cards is realized through the network namespace, and the container does not need to modify codes or configurations, so that the adaptation cost is reduced; in this way, a plurality of physical network cards of the server can be used, network flow distribution is achieved, the network bandwidth of the server is improved, and the network performance is improved.

Description

TECHNICAL FIELD

[0001] Embodiments of the present disclosure relate to the technical field of computer, and particularly, to a network transmission method and device based on a container environment, a storage medium and a product. BACKGROUND

[0002] In some server environments, multi-physical NIC deployment is a common solution to improve network bandwidth and redundancy. Container technology is a lightweight and portable software packaging technology that packages an application and all its dependencies together so that it can run quickly and reliably in any computing environment.

[0003] Currently, in a server with multiple physical NICs, container technology is usually applied by configuring the container to directly bind the container to a physical NIC, or generating multiple virtual functions (VF) for the physical NIC, assigning the virtual functions to the container and configuring network parameters.

[0004] In the prior art, the container needs to be configured or the program code needs to be modified, and the network isolation between containers is poor, and the utilization rate of multiple physical NICs is not high. SUMMARY

[0005] Embodiments of the present disclosure provide a network transmission method and device based on a container environment, a storage medium and a product to solve the above technical problems.

[0006] In a first aspect, embodiments of the present disclosure provide a network transmission method based on a container environment, comprising:

[0007] receiving a container deployment request, the container deployment request indicating to deploy a first container in a server, the server being configured with multiple physical NICs, each physical NIC being configured in a different network namespace, only one physical NIC being deployed in one network namespace, the network namespace including a system network namespace and at least one dedicated network namespace;

[0008] determining a target physical NIC required by the first container, and adding the first container to a target network namespace corresponding to the target physical NIC;

[0009] controlling the first container to perform data transmission with a target device accessing the first container in the target network namespace through the target physical NIC.

[0010] In a second aspect, embodiments of the present disclosure provide a network transmission device based on a container environment, comprising:

[0011] The request unit is configured to receive a container deployment request, the container deployment request indicating to deploy a first container in a server, the server being configured with a plurality of physical network cards, each of the physical network cards being configured in a different network namespace respectively, only one physical network card being deployed in one network namespace, the network namespaces including a system network namespace and at least one special network namespace;

[0012] The deployment unit is configured to determine a target physical network card required by the first container, and add the first container into a target network namespace corresponding to the target physical network card;

[0013] The communication unit is configured to control the first container to perform data transmission with a target device accessing the first container in the target network namespace through the target physical network card.

[0014] In a third aspect, an electronic device is provided, including a processor and a memory.

[0015] The memory stores computer-executable instructions.

[0016] The processor executes the computer-executable instructions stored in the memory, so that the at least one processor executes the container-environment-based network transmission method as described in the first aspect and various possible designs of the first aspect.

[0017] In a fourth aspect, a computer-readable storage medium is provided, and the computer-readable storage medium stores computer-executable instructions. When a processor executes the computer-executable instructions, the container-environment-based network transmission method as described in the first aspect and various possible designs of the first aspect is implemented.

[0018] In a fifth aspect, a computer program product is provided, and the computer program product includes a computer program. When a processor executes the computer program, the container-environment-based network transmission method as described in the first aspect and various possible designs of the first aspect is implemented.

[0019] The method, device, storage medium and product provided by the embodiments of the present disclosure provide a network transmission method based on a container environment. The method comprises the following steps: receiving a container deployment request, wherein the container deployment request indicates to deploy a first container in a server, the server is configured with multiple physical network cards, each physical network card is configured in a different network namespace, only one physical network card is deployed in one network namespace, and the network namespace comprises a system network namespace and at least one special network namespace; determining a target physical network card required by the first container, and adding the first container to a target network namespace corresponding to the target physical network card; and controlling the first container to perform data transmission with a target device accessing the first container in the target network namespace through the target physical network card. The network namespaces are used to realize the isolation between the multiple physical network cards, avoid network configuration conflicts between containers, and enable the containers to only perceive one physical network card in the network namespace. Therefore, the containers do not need to modify codes or configurations, and the adaptation cost is reduced. The multiple physical network cards of the server can be used, different containers can use different physical network cards, network traffic is distributed, the network bandwidth of the server is improved, and the network performance is improved. BRIEF DESCRIPTION OF DRAWINGS

[0020] In order to more clearly illustrate the technical solutions in the embodiments of the present disclosure or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or the prior art description. Obviously, the drawings in the following description are some embodiments of the present disclosure, and other drawings can be obtained by those skilled in the art without creative labor under the premise of the drawings.

[0021] Figure 1 A server architecture example diagram of a network transmission method based on a container environment in the prior art is shown in FIG. 1.

[0022] Figure 2 A network transmission method flow diagram based on a container environment provided by an embodiment of the present disclosure is shown in FIG. 2.

[0023] Figure 3 A network transmission method flow diagram based on a container environment provided by another embodiment of the present disclosure is shown in FIG. 3.

[0024] Figure 4 A structure block diagram of a network transmission device based on a container environment provided by an embodiment of the present disclosure is shown in FIG. 4.

[0025] Figure 5 A hardware structure diagram of an electronic device provided by an embodiment of the present disclosure is shown in FIG. 5. DETAILED DESCRIPTION

[0026] To make the purposes, technical solutions, and advantages of the embodiments of the present disclosure clearer, the technical solutions in the embodiments of the present disclosure will be described clearly and completely below with reference to the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are some but not all of the embodiments of the present disclosure. Based on the embodiments in the present disclosure, all other embodiments obtained by a person of ordinary skill in the art without creative work fall within the protection scope of the present disclosure.

[0027] First, some technical terms in the embodiments of the present disclosure are introduced:

[0028] Network Namespace: Linux system realizes network resource isolation through a network namespace, different network namespaces can have independent network cards, IP addresses, and routing tables, and can provide basic network isolation capability for isolated environments such as containers.

[0029] Container technologies such as Docker (container engine) and Containerd (container daemon) usually realize network access through Bridge, MACVLAN (MAC Virtual Local Area Network), IPVLAN (IP Virtual Local Area Network), and the like:

[0030] Bridge mode: containers share the host network stack and communicate with the outside world through a virtual bridge, which cannot directly bind physical network cards.

[0031] MACVLAN / IPVLAN mode: containers can directly associate with virtual interfaces of physical network cards, but need to manually configure card mapping, and cannot perceive server hardware topology (such as NUMA node and physical affinity of network cards).

[0032] Currently, in a server with multiple physical network cards, container technology is usually applied by configuring containers to directly bind containers with physical network cards, the specific process including: 1) configuring multiple virtual network cards (such as veth pairs) for containers in the host network namespace, respectively associated with different physical network cards; 2) manually configuring multi-card routing strategies (such as network card selection based on target IP) in the container; 3) the application needs to modify the code to support multi-card adaptation (such as binding a specific IP to send data). In this scheme, the application must perceive the existence of multiple network cards and be modified accordingly, otherwise it cannot take advantage of the bandwidth of multiple network cards; without considering the server hardware topology, the network card and the NUMA node where the container is located may not match, and the performance loss is significant.

[0033] Or generate multiple virtual functions (Virtual Function, VF) for the physical network card, assign the virtual functions to the containers and configure the network parameters. The specific process includes: 1) enabling SR-IOV (Single Root I / O Virtualization) function for the physical network card to generate multiple virtual functions (VF); 2) directly assigning the VF to the container through a tool to realize direct data communication between the container and the physical network card; 3) identifying the VF as an independent network card in the container, and manually configuring the network parameters.

[0034] In the prior art, the container usually needs to be configured or the program code needs to be modified, the network isolation between containers is poor, and the utilization rate of multiple physical network cards is not high.

[0035] To solve the above technical problems, the present embodiment provides a network transmission method based on a container environment. The method includes receiving a container deployment request, the container deployment request indicating to deploy a first container in a server, the server being configured with multiple physical network cards, each physical network card being configured in a different network namespace, only one physical network card being deployed in one network namespace, the network namespace including a system network namespace and at least one special network namespace; determining a target physical network card required by the first container, and adding the first container to a target network namespace corresponding to the target physical network card; and controlling the first container to perform data transmission with a target device accessing the first container through the target physical network card in the target network namespace. In this embodiment, the isolation between multiple physical network cards is realized through the network namespace, avoiding network configuration conflicts between containers. The container can only perceive one physical network card in the network namespace, and the container does not need to modify the code or configuration, reducing the adaptation cost. The multiple physical network cards of the server can be used, different containers can use different physical network cards, network traffic can be distributed, the network bandwidth of the server can be improved, and the network performance can be improved.

[0036] The application scenario of the network transmission method based on the container environment of the present embodiment is as follows: Figure 1As shown, the server is configured to include multiple physical network cards Eth0, Eth2, etc. At the initialization of the server (at startup or restart), only one system network namespace (default net namespace) exists, and all physical network cards are in the system network namespace. At least one dedicated network namespace (for example, ns2 net namespace) can be created, and at least one physical network card of the multiple physical network cards in the system network namespace can be migrated, so that only one physical network card is migrated into each dedicated network namespace, and the migrated physical network card is configured. Further, a container can be deployed in any of the system network namespace and the dedicated network namespace, in which the container can only see one physical network card, and the container can directly use the physical network card without modifying the code or configuration.

[0037] In addition, after each dedicated network namespace is created, a proxy node, denoted as a first proxy node (prox Agent), can be deployed in each dedicated network namespace, and corresponding proxy nodes, denoted as second proxy nodes (for example, XAgent and Y Agent), can be deployed in the system network namespace for some commonly used ports such as 80, 443, and custom service ports, which are denoted as target ports. A preset bidirectional forwarding channel (for example, UPI / xGMI) can be constructed between each dedicated network namespace and the system network namespace, that is, a bidirectional forwarding channel between the first proxy node in each dedicated network namespace and the second proxy nodes corresponding to the target ports in the system network namespace, so as to realize communication across network namespaces.

[0038] The container environment-based network transmission method of the present disclosure will be described in detail below with reference to specific embodiments.

[0039] Reference Figure 2 , Figure 2 A container environment-based network transmission method flowchart is provided for an embodiment of the present disclosure. The method of the present embodiment can be applied in a server, and the container environment-based network transmission method includes the following steps.

[0040] S201, a container deployment request is received, the container deployment request indicating to deploy a first container in a server, the server being configured to include multiple physical network cards, each physical network card being configured in a different network namespace, only one physical network card being deployed in one network namespace, and the network namespaces including a system network namespace and at least one dedicated network namespace.

[0041] In the embodiment, the server is configured with multiple physical network cards, and the server can be a multi-path server (a server configured with multiple CPUs) or other available servers. In order to make full use of the multiple physical network cards and ensure the network isolation of the containers using the physical network cards, without modifying the code or configuration of the containers, different network namespaces are configured for the server in the embodiment, and only one physical network card is configured in each network namespace.

[0042] Specifically, when the server is initialized (when starting up or restarting), only one system network namespace exists, all the physical network cards are in the system network namespace, at least one dedicated network namespace can be created, and at least one physical network card of the multiple physical network cards in the system network namespace is migrated, so that only one physical network card is migrated into each dedicated network namespace, and the migrated physical network card is configured with a network. Optionally, the process can be realized by an automatic script.

[0043] Optionally, each physical network card is respectively configured in one of the system network namespace and the dedicated network namespace, that is, one physical network card is configured in each of the system network namespace and the dedicated network namespace, and therefore the number of the created dedicated network namespaces can be equal to the number of the physical network cards minus 1. Specifically, in the creation process, for each network card other than the currently used physical network card of the system namespace, it can be checked whether the corresponding dedicated network namespace exists, and if not, the corresponding dedicated network namespace is created. Alternatively, the number of the created dedicated network namespaces can be less than the number of the physical network cards minus 1, so that at least two physical network cards exist in the system network namespace, but only one physical network card can be used in the system network namespace after the containers are added to the dedicated network namespace, that is, only one physical network card is visible to the containers.

[0044] Optionally, after the creation of the dedicated network namespace, the loopback interface in the dedicated network namespace can be started to ensure that the network stack of the dedicated network namespace is available, and to ensure that the containers running in the dedicated network namespace have a complete and functional network environment. The loopback interface is automatically generated when the dedicated network namespace is created, is independent and exclusive, and is a component of the network stack in the dedicated namespace.

[0045] Optionally, the ip command can be used for migration during migration; and the network configuration can include, but is not limited to, configuring the IP address of the migrated physical network card, the subnet mask (inherited from the system network namespace, such as ip netns exec ns2 ip a add 192.168.1.10 / 24 dev eth2), the route configuration, etc. The route configuration can calculate the gateway (such as the first available IP of the network segment for IPv4 gateway) through a specific calculation rule, and add the default route (i.e., route to the gateway); if the server has a policy routing table, such as an ort (Object Relational Transform) prefix table, the routing rules are inherited from the policy routing table.

[0046] In addition, if the server supports the SR-IOV technology, after migrating any physical network card into any dedicated network namespace, the virtual function (VF) of the physical network card and the representative device (Representer) of the virtual function are migrated into the dedicated network namespace for use by containers in the dedicated network namespace, such as Kata Containers and other container runtimes (runtime) that need to use VFs. The SR-IOV technology implements network card hardware-level virtualization through PCIe (bus) virtual functions, which, in combination with the network namespace mechanism of the present embodiment, can further improve performance isolation.

[0047] It should be noted that the creation of the above-mentioned dedicated network namespace, the migration of the physical network card, and the network configuration are only performed when the server is initialized, and do not need to be performed again after the server is initialized.

[0048] After the server is initialized, the deployment of containers can be performed, and a container deployment request can be received, which indicates to deploy a first container in the server.

[0049] S202, determining a target physical network card required by the first container, and adding the first container to a target network namespace corresponding to the target physical network card.

[0050] In the present embodiment, for the first container to be deployed, the target physical network card required by the first container can be determined first, and then the first container is connected to the target network namespace corresponding to the target physical network card.

[0051] The target physical network card required by the first container can be determined in any feasible manner, for example, the target physical network card required by the first container is directly specified in a deployment request; or a physical network card with relatively small load is selected as the target physical network card required by the first container according to the load of each physical network card, so as to balance the load among the physical network cards; or the target physical network card required by the first container can also be determined according to affinity, and the like. The target network namespace can be a system network namespace or a dedicated network namespace.

[0052] The first container is connected to the target network namespace corresponding to the target physical network card, which can be implemented by a container orchestration system (for example, Kubernetes, etc.). Since there is only one physical network card in the target network namespace, the first container can only see the target physical network card after joining the target network namespace. Therefore, the first container directly uses the target physical network card in the target network namespace, without the need to configure the physical network card for the first container. In addition, the first container can also achieve network isolation with containers in other network namespaces.

[0053] S203, control the first container to perform data transmission with a target device accessing the first container through the target physical network card in the target network namespace.

[0054] In this embodiment, after the first container is deployed, if any target device needs to access the first container (that is, the target device sends data to the first container), or the first container needs to send data to the target device, data transmission between the target physical network card and the target device can be achieved through the target physical network card in the target network namespace.

[0055] The network transmission method based on a container environment provided in this embodiment comprises the following steps: receiving a container deployment request, wherein the container deployment request indicates to deploy a first container in a server, the server is configured with multiple physical network cards, each of which is configured in a different network namespace, only one physical network card is deployed in one network namespace, and the network namespace comprises a system network namespace and at least one special network namespace; determining a target physical network card required by the first container, and adding the first container to a target network namespace corresponding to the target physical network card; and controlling the first container to perform data transmission with a target device accessing the first container in the target network namespace through the target physical network card. In this embodiment, the isolation between multiple physical network cards is realized through network namespaces, network configuration conflicts between containers are avoided, and a container can only perceive one physical network card in the network namespace. Therefore, the container does not need to modify the code or configuration, the adaptation cost is reduced, and the multiple physical network cards of the server can be used. Different containers can use different physical network cards, network traffic is shunted, the network bandwidth of the server is improved, and the network performance is improved.

[0056] On the basis of any of the above embodiments, when the target physical network card required by the first container is determined at S202, the target physical network card required by the first container can be determined according to affinity configuration information of the first container, wherein the affinity configuration information of the first container can comprise the affinity between the first container and a CPU (central processing unit) in the server, and the CPU and the physical network card have a mapping relationship. Therefore, the CPU to which the first container is affinity can be determined according to the affinity configuration information of the first container, and then the target physical network card required by the first container can be determined according to the mapping relationship between the CPU and the physical network card. Optionally, the affinity configuration information of the first container can be obtained by a container orchestration system, for example, nodeAffinity or cpuset configuration information of Kubernetes.

[0057] Optionally, the server can be a multi-path server (configured with multiple CPUs), and the multi-path server comprises multiple NUMA (Non Uniform Memory Access) nodes, wherein NUMA is a memory design architecture of a multi-processor computer, and memory access optimization is realized by grouping multiple processors into nodes. The NUMA nodes and the physical network cards of the multi-path server have a mapping relationship (or an affinity relationship), and the mapping relationship is usually many-to-one, that is, multiple NUMA nodes correspond to one physical network card.

[0058] In an optional embodiment, as Figure 3 The method can further comprise the following steps:

[0059] S301, determining a target NUMA node that is affinity with the first container according to affinity configuration information of the first container;

[0060] S302, determining a target physical network card corresponding to the target NUMA node as the target physical network card according to a mapping relationship between each physical network card of the multi-path server and each NUMA node.

[0061] In the embodiment, the affinity configuration information of the first container can be the affinity between the first container and the CPU in the multi-path server, wherein one CPU corresponds to multiple NUMA nodes, or the affinity configuration information of the first container can also be the affinity between the first container and the NUMA node. Optionally, the affinity configuration information of the first container can be obtained through a container orchestration system, for example, nodeAffinity or cpuset configuration information of Kubernetes.

[0062] Further, the target NUMA node that is affinity with the first container can be determined according to the affinity configuration information of the first container (the target NUMA node can be one or more), and the target NUMA node is also the NUMA node that finally runs the first container. For example, if the affinity configuration information of the first container is the affinity between the first container and the CPU in the multi-path server, that is, the affinity configuration information of the first container includes the CPU that has the highest affinity with the first container, then one or more NUMA nodes corresponding to the CPU are taken as the target NUMA node; if the affinity configuration information of the first container is the affinity between the first container and the NUMA node, that is, the affinity configuration information of the first container includes the NUMA node that has the highest affinity with the first container, then the NUMA node is taken as the target NUMA node.

[0063] In addition, the mapping relationship between each physical network card of the multi-path server and each NUMA node, that is, the affinity relationship between each NUMA node and each physical network card, can also be obtained, and then the target physical network card corresponding to the target NUMA node (that is, the physical network card that has the highest affinity with the target NUMA node) can be queried from the mapping relationship. The target physical network card is determined as the target physical network card required by the first container, so that the target physical network card required by the first container can be determined in combination with the hardware topology of the multi-path server, thereby the first container is connected to the network namespace corresponding to the optimal target physical network card, the data transmission across the NUMA node is reduced, and the network delay is reduced.

[0064] Optionally, the mapping relationship between each physical network card of the multi-path server and each NUMA node can be as follows:

[0065] Obtaining NUMA node distribution information of the multi-path server and bus link information of each physical network card of the multi-path server, and determining a mapping relationship between each physical network card of the multi-path server and each NUMA node according to the NUMA node distribution information and the bus link information of each physical network card.

[0066] In the embodiment, the NUMA node distribution information of the multi-path server, i.e., which CPU is associated with each NUMA node, can be obtained by a numactl command or the like; and the bus link information of each physical network card of the multi-path server, i.e., which CPU is connected to each physical network card, can be obtained by an lspci command or the like. Since one CPU is usually connected to one physical network card and one CPU corresponds to multiple NUMA nodes, the mapping relationship between each physical network card and each NUMA node can be constructed.

[0067] In another optional embodiment, S202 determines a target physical network card required by the first container, including:

[0068] detecting whether target physical network card information is configured in a container label of the first container;

[0069] if yes, determining the target physical network card required by the first container according to the target physical network card information.

[0070] In the embodiment, the container label of the first container can be automatically or manually configured, and the physical network card affinity to the first container can be configured in the container label, for example, network.affinity=eth2, i.e., the physical network card affinity to the first container configured in the container label is the physical network card eth2, which can be determined as the target physical network card required by the first container.

[0071] Optionally, when the physical network card affinity to the first container is configured in the container label of the first container, the configuration can be performed according to any rule or user demand, for example, the physical network card with a load lower than a preset threshold can be determined as the physical network card affinity to the first container according to the load of each physical network card of the server, and the physical network card affinity to the first container is configured in the container label of the first container, so that load balancing between the physical network cards can be realized.

[0072] It should be noted that if it is detected that the container tag of the first container is not configured with the physical network card affinity to the first container, the manner in the previous optional embodiment can be performed, that is, the target physical network card required by the first container can be determined according to the affinity configuration information of the first container; in the scenario in which the multi-path server includes multiple NUMA nodes, the target NUMA node affinity to the first container can be determined according to the affinity configuration information of the first container, and then the physical network card corresponding to the target NUMA node is determined as the target physical network card according to the mapping relationship between each physical network card of the multi-path server and each NUMA node.

[0073] On the basis of any of the above embodiments, after creating each dedicated network namespace, a proxy node can be deployed in each dedicated network namespace, denoted as a first proxy node, and a corresponding proxy node can be deployed in the system network namespace for some commonly used ports such as 80, 443, and custom service ports, denoted as a second proxy node. The ports are denoted as second ports, and the mirror ports of the second ports are deployed in each dedicated network namespace, denoted as first ports. However, only the second ports can actually provide services, and the first ports as mirrors cannot actually provide services, but are used to enable the containers deployed in the dedicated network namespace to perceive the existence of the first ports in the dedicated network namespace, and the containers can send request data packets to the first ports when the containers need to call the first ports.

[0074] In addition, a preset bidirectional forwarding channel is constructed between each dedicated network namespace and the system network namespace, that is, a bidirectional forwarding channel between the first proxy node in each dedicated network namespace and the second proxy node corresponding to each target port in the system network namespace.

[0075] The second proxy node corresponding to each first port in the system network namespace can monitor the target port, and can also call the dedicated network namespace through a setns system or the like to monitor the first port of the target port in the dedicated network namespace. In this way, when the first port in the dedicated network namespace receives the request data packet sent by the container, the second proxy node can obtain the data packet received by the first port through the first proxy node.

[0076] Further, in the case that the target network namespace accessed by the first container is a dedicated network namespace, if the first container needs to call any common port such as 80, 443, custom service port, etc., the mirror of the common port in the target network namespace is a first port, the first container can send a request data packet to the first port in the target network namespace, and the request data packet of the first container can be received by the first proxy node in the target network namespace; then the first proxy node transmits the request data packet to the second proxy node of the second port in the system network namespace through the preset bidirectional forwarding channel between the target network namespace and the system network namespace, so that the second proxy node transmits the request data packet to the second port, wherein the first port is the mirror port of the second port in the target network namespace, so that the container in the dedicated network namespace can directly and non-perceptively call the common port in the system network namespace, which guarantees the container network isolation and does not need to modify the program code of the container.

[0077] Further, when the first proxy node transmits the request data packet to the second proxy node, there are at least two different scenarios:

[0078] In one scenario, the request data packet does not need to pay attention to the request source, and the second proxy node does not need to know which container sends it, for example, the scenario of unchanged TCP / UDP Payload, that is, the scenario in which the actual application data content carried in the data packet remains completely consistent in multiple network communications (such as heartbeat detection, fixed command, etc.), in which the first proxy node can directly transmit the request data packet to the second proxy node through the preset bidirectional forwarding channel, and the transmission mode can adopt memcpy function (memory copy) and the like, which is not limited in the embodiment.

[0079] In another scenario, the request data packet needs to pay attention to the request source, and the second proxy node needs to know which container sends it, and the network identifier of the request data packet needs to be modified, which can be modified by the first proxy node according to the mapping relationship between the network identifier of the first container and the network identifier of the server (the mapping relationship between the IP of the first container and the IP of the server), such as modifying the IP header and MAC header of the request data packet (replacing the source IP of the first container with the server egress IP), and transmitting the modified request data packet to the second proxy node, wherein the modification mode can adopt the tc (traffic control) or netfilter (network filter) mechanism in the Linux kernel, which is not limited in the embodiment.

[0080] Further, if the second port returns a response packet based on the request packet, the second agent node corresponding to the second port can directly transmit the response packet to the first agent node in the target network namespace through the preset bidirectional forwarding channel, and the first agent node can transmit the response packet to the first container.

[0081] Further, the first agent node can transmit the data packet to the second agent node based on a preset forwarding rule. The preset forwarding rule can be dynamically configured and can include a forwarding rule based on a target IP segment, a forwarding rule based on a port, and the like.

[0082] Based on any of the above embodiments, after all containers in any special network namespace are completely destroyed, the physical network card configured in the special network namespace can be migrated to the system network namespace, and the special network namespace can be released, so as to realize recycling of the physical network card.

[0083] Optionally, when any physical network card changes, for example, the physical network card stops being used or is replaced, only the physical network card is migrated out of the special network namespace in which the physical network card is located, and a new physical network card is migrated into the special network namespace, so as to realize change of the physical network card in the special network namespace.

[0084] The network transmission method based on a container environment corresponding to the above embodiments, Figure 4 A structure block diagram of a network transmission device based on a container environment provided by the embodiments of the present disclosure is provided. For ease of illustration, only parts related to the embodiments of the present disclosure are shown. Refer to Figure 4 The network transmission device based on a container environment 400 includes a request unit 401, a deployment unit 402, and a communication unit 403.

[0085] The request unit 401 is configured to receive a container deployment request, the container deployment request indicating to deploy a first container in a server, the server being configured with a plurality of physical network cards, each physical network card being configured in a different network namespace, only one physical network card being deployed in one network namespace, the network namespace including a system network namespace and at least one special network namespace.

[0086] The deployment unit 402 is configured to determine a target physical network card required by the first container and add the first container to a target network namespace corresponding to the target physical network card.

[0087] The communication unit 403 is configured to control the first container to perform data transmission with a target device accessing the first container in the target network namespace through the target physical network card.

[0088] The network transmission device based on a container environment provided by the embodiments of the present disclosure receives a container deployment request, the container deployment request indicating to deploy a first container in a server, the server being configured with multiple physical network cards, each physical network card being configured in a different network namespace, only one physical network card being deployed in one network namespace, the network namespace including a system network namespace and at least one special network namespace; determining a target physical network card required by the first container, and adding the first container to a target network namespace corresponding to the target physical network card; and controlling the first container to perform data transmission with a target device accessing the first container in the target network namespace through the target physical network card. In this embodiment, the isolation between multiple physical network cards is realized through network namespaces, network configuration conflicts between containers are avoided, and a container can only perceive one physical network card in the network namespace, without the need for the container to modify codes or configurations, thereby reducing the adaptation cost; and multiple physical network cards of the server can be used, different containers can use different physical network cards, network traffic is shunted, the network bandwidth of the server is improved, and the network performance is improved.

[0089] In one or more embodiments of the present disclosure, when determining the target physical network card required by the first container, the deployment unit 402 is configured to:

[0090] determine the target physical network card required by the first container according to affinity configuration information of the first container.

[0091] In one or more embodiments of the present disclosure, the server includes a multi-path server including multiple non-uniform memory access (NUMA) nodes; accordingly, when determining the target physical network card required by the first container according to the affinity configuration information of the first container, the deployment unit 402 is configured to:

[0092] determine a target NUMA node to which the first container is affinity according to the affinity configuration information of the first container.

[0093] determine a physical network card corresponding to the target NUMA node as the target physical network card according to a mapping relationship between each physical network card of the multi-path server and each NUMA node.

[0094] In one or more embodiments of the present disclosure, before determining a physical network card corresponding to the target NUMA node as the target physical network card according to a mapping relationship between each physical network card of the multi-path server and each NUMA node, the deployment unit 402 is further configured to:

[0095] Obtaining NUMA node distribution information of the multi-path server and bus link information of each physical network card of the multi-path server, and determining a mapping relationship between each physical network card of the multi-path server and each NUMA node according to the NUMA node distribution information and the bus link information of each physical network card.

[0096] In one or more embodiments of the present disclosure, the deployment unit 402, when determining the target physical network card required by the first container, is configured to:

[0097] detect whether target physical network card information is configured in a container label of the first container;

[0098] If yes, determine the target physical network card required by the first container according to the target physical network card information.

[0099] In one or more embodiments of the present disclosure, the deployment unit 402 is further configured to:

[0100] determine, according to the load conditions of each physical network card of the server, a physical network card with a load lower than a preset threshold as a physical network card affinity to the first container, and configure the physical network card affinity to the first container in a container label of the first container.

[0101] In one or more embodiments of the present disclosure, the communication unit 403 is further configured to:

[0102] If the target network namespace is any of the special network namespaces, receive, by a first proxy node in the target special network namespace, a request data packet of the first container for a first port, transmit the request data packet to a second proxy node in the system network namespace via a preset bidirectional forwarding channel between the target special network namespace and the system network namespace, and transmit the request data packet to a second port by the second proxy node, wherein the second proxy node is a proxy node corresponding to the second port, and the first port is a mirror port of the second port in the target special network namespace.

[0103] In one or more embodiments of the present disclosure, when the communication unit 403 transmits the request data packet to the second proxy node in the system network namespace via the preset bidirectional forwarding channel between the target special network namespace and the system network namespace, the communication unit 403 is configured to:

[0104] If the request data packet is a data packet without a request source to be concerned, the first proxy node directly transmits the request data packet to the second proxy node via the preset bidirectional forwarding channel; or

[0105] If the request data packet is a data packet requiring attention to the request source, the first proxy node modifies the network identifier of the request data packet according to the mapping relationship between the network identifier of the first container and the network identifier of the server, and transmits the modified request data packet to the second proxy node.

[0106] In one or more embodiments of the present disclosure, the deployment unit 402 is further configured to:

[0107] The first proxy node is deployed in each of the special network namespaces, the second proxy node corresponding to the second port is deployed in the system network namespace, and a preset bidirectional forwarding channel is constructed between each of the special network namespaces and the system network namespace.

[0108] In one or more embodiments of the present disclosure, the deployment unit 402 is further configured to:

[0109] When the server is initialized, at least one special network namespace is created;

[0110] At least one physical network card of a plurality of physical network cards in the system network namespace of the server is migrated, so that only one physical network card is migrated into each special network namespace, and the migrated physical network card is configured with a network.

[0111] In one or more embodiments of the present disclosure, the deployment unit 402 is further configured to:

[0112] If the server supports a single root input / output virtualization technology, after any physical network card is migrated into any special network namespace, a virtual function of the physical network card and a representative device of the virtual function are migrated into the special network namespace for use by a container in the special network namespace.

[0113] In one or more embodiments of the present disclosure, the deployment unit 402 is further configured to:

[0114] If all containers in any of the special network namespaces are completely destroyed, the physical network card configured in the special network namespace is migrated to the system network namespace, and the special network namespace is released.

[0115] The device provided by the embodiment can be used to execute the technical solutions of the above-mentioned method embodiments, and has similar implementation principles and technical effects, which will not be described here again.

[0116] In order to implement the above-mentioned embodiments, the electronic device is further provided in the embodiments of the present disclosure.

[0117] Reference Figure 5The diagram illustrates a structural schematic of an electronic device 500 suitable for implementing embodiments of the present disclosure. The electronic device 500 can be a terminal device or a server. The terminal device can include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, personal digital assistants (PDAs), tablet computers, portable media players (PMPs), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 5 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0118] like Figure 5 As shown, the electronic device 500 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage device 508 into a random access memory (RAM) 503. The RAM 503 also stores various programs and data required for the operation of the electronic device 500. The processing unit 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0119] Typically, the following devices can be connected to I / O interface 505: input devices 506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 508 including, for example, magnetic tapes, hard disks, etc.; and communication devices 509. Communication device 509 allows electronic device 500 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 5 An electronic device 500 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0120] In particular, according to embodiments of the present disclosure, the processes described above with reference to the flowcharts can be implemented as a computer software program. For example, embodiments of the present disclosure include a computer program product comprising a computer program carried on a computer-readable storage medium, the computer program containing program code for executing the methods illustrated by the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network by the communication device 509, or installed from the storage device 508, or installed from the ROM 502. When the computer program is executed by the processing device 501, the above-mentioned functions defined in the methods of the embodiments of the present disclosure are executed.

[0121] Note that the computer-readable storage medium described above in the present disclosure can be a computer-readable signal medium or a computer-readable storage medium or any combination thereof. The computer-readable storage medium may, for example, be but is not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or apparatus, or any suitable combination thereof. More specific examples of the computer-readable storage medium can include, but are not limited to, an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present disclosure, the computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device. In the present disclosure, the computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, in which the computer-readable program code is carried. Such a propagated data signal can take on many forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable storage medium that is not a computer-readable storage medium, and that can transmit, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable storage medium can be transmitted by any suitable medium, including but not limited to wire, cable, fiber optic, RF (radio frequency), or any suitable combination thereof.

[0122] The computer-readable storage medium described above can be included in the electronic device described above; or can exist separately from the electronic device and not be assembled into the electronic device.

[0123] The computer-readable storage medium described above carries one or more programs, which, when executed by the electronic device, cause the electronic device to execute the methods illustrated by the embodiments described above.

[0124] Computer program code for carrying out operations of the present disclosure can be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0125] The flow diagrams and the block diagrams in the drawings are meant as illustrative representations of the architectures, functions, and operations of possible implementations of systems, methods and computer program products in accordance with the present disclosure. It should be noted that each block in the flow diagrams and the block diagrams, and combinations of blocks in the flow diagrams and the block diagrams, can be implemented by a computer program instruction or code means. Also, it should be noted that each block in the flow diagrams and the block diagrams, and combinations of blocks in the flow diagrams and the block diagrams, can be implemented by special purpose hardware-based computer systems which perform the specified functions or operations, or combinations of special purpose hardware and computer code means.

[0126] The units described in the embodiments of the present disclosure can be implemented by software, or by hardware. In some cases, the name of the unit does not constitute a limitation on the unit itself. For example, the first obtaining unit can also be described as a unit for obtaining at least two Internet protocol addresses.

[0127] The functions described above in the specification of the present disclosure can be performed by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include: Field-programmable Gate Arrays (FPGAs), Program-specific Integrated Circuits (ASICs), Application-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc.

[0128] The electronic device, the computer readable storage medium, and the computer program product provided in the embodiments of the present disclosure receive a container deployment request, the container deployment request indicating to deploy a first container in a server, the server being configured with multiple physical network cards, each of which is configured in a different network namespace, only one physical network card being deployed in one network namespace, the network namespace including a system network namespace and at least one special network namespace; determining a target physical network card required by the first container, and adding the first container to a target network namespace corresponding to the target physical network card; and controlling the first container to perform data transmission with a target device accessing the first container in the target network namespace through the target physical network card. In the embodiments, isolation between multiple physical network cards is implemented through network namespaces, network configuration conflicts between containers are avoided, a container can only perceive one physical network card in the network namespace, the container does not need to modify code or configuration, and adaptation cost is reduced; and multiple physical network cards of the server can be used, different containers can use different physical network cards, network traffic is split, network bandwidth of the server is improved, and network performance is improved.

[0129] The above description is merely the preferred embodiments and the explanation of the applied technical principles of the present disclosure. It should be understood by those skilled in the art that the disclosed range of the present disclosure is not limited to the technical solutions formed by the specific combinations of the technical features described above, and should also cover other technical solutions formed by any combinations of the technical features described above or their equivalent features without departing from the disclosed concept. For example, the technical solutions formed by the mutual replacement of the above-described features and the technical features disclosed in the present disclosure (but not limited to) having similar functions.

[0130] In addition, although each operation is depicted in a particular order, this should not be understood as requiring the operations to be performed in the particular order shown or in a sequential order. In certain circumstances, multitasking and parallel processing can be advantageous. Similarly, although several implementation details are included in the above discussion, these should not be interpreted as limiting the scope of the present disclosure. Certain features described in the context of separate embodiments can also be combined in a single embodiment. Conversely, various features described in the context of a single embodiment can also be separated and implemented in multiple embodiments.

[0131] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A network transmission method based on a container environment, characterized in that, include: Receive a container deployment request, the container deployment request instructing the deployment of a first container in a server, the server being configured with multiple physical network interface cards (NICs), each NIC being configured in a different network namespace, and only one NIC being deployed in a network namespace, the network namespace including the system network namespace and at least one dedicated network namespace; Determine the target physical network interface card (NIC) required by the first container, and add the first container to the target network namespace corresponding to the target physical NIC; The first container is controlled to transmit data with the target device accessing the first container in the target network namespace through the target physical network card.

2. The method according to claim 1, characterized in that, Determining the target physical network interface card (NIC) required for the first container includes: Based on the affinity configuration information of the first container, the target physical network interface card required by the first container is determined.

3. The method according to claim 2, characterized in that, The server includes a multi-socket server, which includes multiple non-uniform memory access (NUMA) nodes; then, determining the target physical network interface card (NIC) required by the first container based on the affinity configuration information of the first container includes: Based on the affinity configuration information of the first container, determine the target NUMA node that is compatible with the first container; Based on the mapping relationship between each physical network card of the multi-path server and each NUMA node, the physical network card corresponding to the target NUMA node is determined as the target physical network card.

4. The method according to claim 3, characterized in that, Before determining the physical network interface card corresponding to the target NUMA node as the target physical network interface card based on the mapping relationship between each physical network interface card of the multi-path server and each NUMA node, the method further includes: Obtain the NUMA node distribution information of the multi-path server and the bus link information of each physical network card of the multi-path server, and determine the mapping relationship between each physical network card and each NUMA node of the multi-path server based on the NUMA node distribution information and the bus link information of each physical network card.

5. The method according to claim 1, characterized in that, Determining the target physical network interface card (NIC) required for the first container includes: Detect whether the target physical network interface card information is configured in the container label of the first container; If so, the target physical network interface card (NIC) required by the first container is determined based on the target physical NIC information.

6. The method according to claim 1, characterized in that, The method further includes: If the target network namespace is any of the dedicated network namespaces, the first proxy node in the target dedicated network namespace receives the request data packet from the first container to the first port, and transmits the request data packet to the second proxy node in the system network namespace via a preset bidirectional forwarding channel between the target dedicated network namespace and the system network namespace. The second proxy node then transmits the request data packet to the second port, wherein the second proxy node is a proxy node corresponding to the second port, and the first port is a mirror port of the second port in the target dedicated network namespace.

7. The method according to claim 6, characterized in that, The step of transmitting the request data packet to the second proxy node in the system network namespace via a preset bidirectional forwarding channel between the target dedicated network namespace and the system network namespace includes: If the request data packet is a data packet that does not require attention to the request source, then the first proxy node directly transmits the request data packet to the second proxy node through the preset bidirectional forwarding channel; or If the request data packet is a data packet whose request source needs to be monitored, the first proxy node modifies the network identifier of the request data packet according to the mapping relationship between the network identifier of the first container and the network identifier of the server, and transmits the modified request data packet to the second proxy node.

8. The method according to claim 1, characterized in that, The method further includes: During server initialization, at least one dedicated network namespace is created; At least one physical network card from multiple physical network cards in the system network namespace of the server is migrated so that only one physical network card is migrated into each dedicated network namespace, and the migrated physical network card is configured for network.

9. The method according to claim 8, characterized in that, The method further includes: If the server supports single root input / output virtualization technology, then after any physical network card is migrated into any dedicated network namespace, the virtual functions of the physical network card and the representative device of the virtual functions are migrated into the dedicated network namespace for use by containers in the dedicated network namespace.

10. The method according to claim 1, characterized in that, The method further includes: If all containers in any of the dedicated network namespaces are destroyed, the physical network cards configured in the dedicated network namespaces are migrated to the system network namespace, and the dedicated network namespaces are released.

11. A network transmission device based on a container environment, characterized in that, include: A request unit is used to receive a container deployment request, which indicates that a first container is deployed in a server. The server is configured with multiple physical network interface cards (NICs), each of which is configured in a different network namespace. Only one physical NIC is deployed in a network namespace. The network namespace includes a system network namespace and at least one dedicated network namespace. The deployment unit is used to determine the target physical network interface card (NIC) required by the first container and add the first container to the target network namespace corresponding to the target physical NIC. A communication unit is used to control the first container to transmit data with the target device accessing the first container in the target network namespace through the target physical network card.

12. An electronic device, characterized in that, include: Processor and memory; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, implement the method as described in any one of claims 1-10.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-10.

Images