CN116633901A

CN116633901A - Container network management method, device, equipment and computer storage medium

Info

Publication number: CN116633901A
Application number: CN202310556643.3A
Authority: CN
Inventors: 唐家伟; 唐伟志; 杨阳; 吕斌; 刘玄飞; 黄学艺
Original assignee: Guosen Securities Co ltd
Current assignee: Guosen Securities Co ltd
Priority date: 2023-05-17
Filing date: 2023-05-17
Publication date: 2023-08-22

Abstract

The embodiment of the invention relates to the technical field of network communication, and discloses a container network management method, a device, equipment and a computer storage medium, wherein the method comprises the following steps: when a network initialization request corresponding to a target container cluster is received, determining IP resource demand information of a target node in the target container cluster; searching in the available network segments of the clusters corresponding to the target container clusters according to the IP resource demand information to obtain target network segments corresponding to the target nodes; and carrying out route registration in preset three-layer network equipment for the target node according to the target network segment, so that the three-layer network equipment carries out flow forwarding for the target node. By the mode, the embodiment of the invention improves the resource utilization rate of the container computing resource and the IP resource of the container network.

Description

Container network management method, device, equipment and computer storage medium

Technical Field

The embodiment of the invention relates to the technical field of containers, in particular to a container network management method, a device, equipment and a computer storage medium.

Background

In recent years, the cloud native technology is widely promoted due to the advancement of the cloud native technology, and various enterprise information systems are urgently needed to develop cloud native reconstruction. Because of high cost of purchasing private cloud, long transformation migration period and the like, cloud native transformation is developed to be the optimal choice for cost reduction and synergy of a plurality of enterprises based on the enterprise traditional IT infrastructure.

While in the process of cloud native reformation, the inventors found that: conventional container network schemes typically divide cluster network segments equally into nodes, with the available segments for each node being fixed throughout. In the cloud primary migration transformation process, the situation that the container is mixed with non-container application (such as a virtual machine) is considered, namely, the container is deployed on the virtual machine, and the resource specification of each virtual machine serving as a host machine is different, and the number of the containers which can be borne by each virtual machine is also different, so that the computing resources of the node are not matched with the IP resources allocated to the node, and therefore the waste of the IP resources or the computing resources of the container is caused. Therefore, a more reasonable and efficient container network management scheme for resource utilization is needed, and cost reduction and efficiency improvement are further realized for cloud primary reconstruction.

Disclosure of Invention

In view of the above problems, an embodiment of the present invention provides a container network management method, which is used to solve the problem of IP resource or container computing resource waste of a container cluster in the prior art.

According to an aspect of an embodiment of the present invention, there is provided a container network management method, including:

when a network initialization request corresponding to a target container cluster is received, determining IP resource demand information of a target node in the target container cluster;

searching in the available network segments of the clusters corresponding to the target container clusters according to the IP resource demand information to obtain target network segments corresponding to the target nodes;

and carrying out route registration in preset three-layer network equipment for the target node according to the target network segment, so that the three-layer network equipment carries out flow forwarding for the target node.

In an alternative, the method further comprises:

detecting demand change information of IP resource demand information of the target node;

dynamically adjusting the target network segment according to the demand change information to obtain an adjusted network segment;

and carrying out route registration again in preset three-layer network equipment for the target node according to the adjusted network segment.

In an alternative, the method further comprises:

when the IP resource requirement of the target node is determined to be increased, searching an idle network segment in the available network segments of the cluster, and adding the idle network segment into the target network segment;

And when the IP resource requirement of the target node is determined to be reduced, recycling the unoccupied IP in the target network segment.

In an alternative, the method further comprises:

reading a preset extension field in a node configuration file of the target node to obtain the IP resource demand information; the extension field is used for writing the IP resource requirement information;

or calculating the number of the containers which can be accommodated in the target node according to the node specification information of the target node and the container specification information in the node;

and determining IP resource demand information of the target node according to the number of the accommodating containers.

In an alternative, the method further comprises:

obtaining a container creation request for creating a target container on the target node;

distributing target IP from the target network segment to the target container;

and creating a policy routing rule corresponding to the target container so as to guide the traffic forwarded to the target node by the three-layer network equipment into the target container.

In an alternative, the method further comprises:

acquiring a cluster creation request; the cluster creation request comprises a network segment to be allocated;

And detecting network segment conflict between the network segment to be allocated and the occupied network segment, and determining the network segment to be allocated as the cluster available network segment when the network segment to be allocated and the occupied network segment are determined to have no conflict.

In an alternative manner, the IP resource requirement information includes an IP address requirement number; the method further comprises the steps of:

constructing a bitmap file according to the occupation condition of the IP addresses in the available network segments of the cluster;

and carrying out adjacent address combination on the number of unoccupied IP addresses required by the IP addresses according to the bitmap file to obtain a target network segment of the target node.

According to another aspect of an embodiment of the present invention, there is provided a container network management apparatus including:

the determining module is used for determining IP resource demand information of a target node in the target container cluster when a network initialization request corresponding to the target container cluster is received;

the searching module is used for searching in the available network segments of the clusters corresponding to the target container clusters according to the IP resource demand information to obtain target network segments corresponding to the target nodes;

and the registration module is used for carrying out route registration in preset three-layer network equipment for the target node according to the target network segment so as to enable the three-layer network equipment to carry out flow forwarding for the target node.

According to another aspect of an embodiment of the present invention, there is provided a container network management apparatus including: the device comprises a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface complete communication with each other through the communication bus;

the memory is configured to store at least one executable instruction that causes the processor to perform operations of an embodiment of a container network management method as described in any one of the preceding claims.

According to yet another aspect of an embodiment of the present invention, there is provided a computer-readable storage medium having stored therein at least one executable instruction for causing a container network management device to perform the operations of the container network management method embodiment of any one of the preceding claims.

When a network initialization request corresponding to a target container cluster is received, the IP resource demand information of a target node in the target container cluster is determined; searching in the available network segments of the clusters corresponding to the target container clusters according to the IP resource demand information to obtain target network segments corresponding to the target nodes; and carrying out route registration in preset three-layer network equipment for the target node according to the target network segment, so that the three-layer network equipment carries out flow forwarding for the target node. Thus, unlike the existing IP resource allocation for nodes in a container cluster, the IP resource allocation is generally average allocation, and the actual IP requirements of host nodes with different configurations are not considered, so that the problem that the computing resources of the nodes are not matched with the IP resources allocated to the nodes exists. According to the embodiment of the invention, the IP allocation can be carried out for the target node according to the IP resource demand information of the target node and the available network segment information of the cluster where the node is located, so that the IP resources in the container cluster and the resource utilization rate of the container resources are improved, and the resource utilization rate of the container in the cloud primary transfer scene and the non-container application mixed use environment such as the virtual machine is optimized. Further, in order to adapt to the flexible on-demand IP allocation manner, unlike the prior art that a bridge is generally adopted to forward the container traffic, the embodiment of the invention directly forwards through three layers of routes, so that on one hand, the forwarding performance loss of the bridge layer can be eliminated, and more importantly, the configuration and registration of the three layers of routes are more flexible and easy to customize, so that when the IP requirement and allocation scheme are changed, the updating can be synchronously performed in real time, and the management efficiency and the network availability of the container network are ensured.

The foregoing description is only an overview of the technical solutions of the embodiments of the present invention, and may be implemented according to the content of the specification, so that the technical means of the embodiments of the present invention can be more clearly understood, and the following specific embodiments of the present invention are given for clarity and understanding.

Drawings

The drawings are only for purposes of illustrating embodiments and are not to be construed as limiting the invention. Also, like reference numerals are used to designate like parts throughout the figures. In the drawings:

fig. 1 is a schematic flow chart of a container network management method according to an embodiment of the present invention;

fig. 2 is a schematic diagram showing a target network segment allocation result in a container network management method according to still another embodiment of the present invention;

FIG. 3 is a schematic data plane diagram of a container cross-host access scenario in a container network management method according to still another embodiment of the present invention;

FIG. 4 is a schematic diagram of policy routing of a host node-1 in a container network management method according to still another embodiment of the present invention;

FIG. 5 is a schematic diagram of a routing table 100 of a host node-1 in a container network management method according to still another embodiment of the present invention;

FIG. 6 is a schematic diagram of policy routing of a host node-2 in a container network management method according to still another embodiment of the present invention;

fig. 7 is a schematic diagram showing a routing table main of a host node-2 in a container network management method according to still another embodiment of the present invention;

FIG. 8 is a schematic diagram illustrating a structure of a container management component on which a container network management method according to another embodiment of the present invention is based;

fig. 9 is a schematic structural diagram of a container network management device according to an embodiment of the present invention;

fig. 10 is a schematic structural diagram of a container network management device according to an embodiment of the present invention.

Detailed Description

Exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present invention are shown in the drawings, it should be understood that the present invention may be embodied in various forms and should not be limited to the embodiments set forth herein.

A brief description of the related nouns:

cloud primordial: the container is a key technology of the cloud native technology, and micro services, devOps, CI/CD and the like are built on the container. As a lightweight virtualization technique, containers have higher resource usage efficiency than virtual machines because it does not require a separate operating system to be allocated for each application, and thus the instance size is smaller and the creation and migration speeds are faster. The virtual machine is hardware level virtualization and the container is operating system or application level virtualization. The container and the virtual machine essentially belong to the virtualization technology, the difference is that the two are in different levels, the container is arranged on the upper part of the operating system, compared with the virtual machine, the operating system is reduced, and the operating system can be shared between different containers, so that the container is lighter, faster to start and better in efficiency. Also because of this, the isolation of the container is poor compared to the virtual machine, which is not as secure as the virtual machine. On the other hand, the application of the virtual machine is more popular, and related tools are more mature and perfect. Most businesses will use virtual machines and containers at the same time in most cases. In view of this, containers and virtualization should coexist for a considerable amount of time, especially considering the reality that most enterprises have previously widely deployed virtualization technologies.

Node (node): the smallest computational hardware unit in Kubernetes. Which is a representation of a single machine in a cluster. In most production systems, the target node is likely a physical machine in a data center, or a virtual machine hosted on a cloud provider such as google cloud platform.

Cluster (Cluster): the nodes aggregate resources to form a stronger cluster. When a program is deployed into a cluster, the cluster will intelligently handle the allocation of work to target nodes. If any target nodes are added or deleted, the cluster will switch in operation as needed.

Container group (pod): kubernetes does not run a Container directly (Container); instead, it encapsulates one or more containers into a high-level structure called Pod. Any container in the same Pod will share the same namespaces and local networks. The containers can easily communicate with other containers in the same container as if they were on the same machine while maintaining some degree of isolation. The Pod is distributed on the Node according to the schedule, the Node can bear a plurality of pods, and the pods can bear a plurality of containers. The container ports within the Pod do not conflict, all containers in the Pod share the network stack and storage volumes, and resources of different containers in the same Pod can be accessed through localhost.

Policy routing: and forwarding based on the strategy, searching the routing table after failure, and manually configuring hop by hop to ensure that the message is forwarded according to the strategy. The routing table is selected according to different conditions (source address, transport protocol, port) and then the next hop is selected in the routing table according to the destination address. The routing strategy is forwarded according to the routing tables based on the destination address, the linux system is provided with a plurality of routing tables, and the strategy routing can divert the routing request to different routing tables according to some conditions. E.g. source address in some range routing table a, additional packet routing tables, a similar rule is strategic routing control. In the linux system, one piece of information mainly comprises three pieces of information, namely priority, condition and routing table of rule.

Default Gateway (Default Gateway): the device to which the subnetwork is connected to the external network is typically a router. When a computer sends information, whether the target host is in the local subnet or not is judged through the subnet mask according to the target address of the sent information, and if the target host is in the local subnet, the target host is directly sent. If the target is not in the local subnet, the information is sent to the default gateway/router, which forwards it to other networks for further searching for the target host.

Configuration management database (Configuration Management Database, CMDB): a logical database contains information of the full life cycle of the configuration items and the relation (including physical relation, real-time communication relation, non-real-time communication relation and dependency relation) among the configuration items.

Prior art and its problems are further described before proceeding with the description of the embodiments of the present invention:

in recent years, the cloud native technology is widely promoted due to the advancement of the cloud native technology, and various enterprise information systems are urgently needed to develop cloud native reconstruction. However, due to the high cost of purchasing private cloud, long transformation migration period and the like, cloud native transformation is developed to be the optimal cost-reducing and synergy selection of many enterprises based on the enterprise traditional IT infrastructure. Due to the lack of network virtualization capabilities of the underlying profession and the support of rich products on the cloud, at least the following problems need to be solved to accomplish the cloud native transformation on the existing infrastructure of the enterprise:

the IP resource utilization rate of the container network segment is low: in the container cluster, the resource specification of each host machine is different, and the number of the containers which can be carried is also different. The traditional container network scheme ignores the difference, and writes the fixed-length podCIDR serving as the attribute of the host into the Node object field, so that the resource utilization rate is low, and the cost reduction and the efficiency improvement of enterprises are not facilitated.

Network performance is poor: in order to ensure the elasticity of the expansion and contraction capacity of the cluster, the container cluster is often composed of virtual machines, the containers are deployed on the virtual machines, the containers are hung on a virtual network bridge or an OVS network bridge, and the data forwarding link is long, so that the performance is weaker. The conventional overlay scheme also has performance loss for both packetization and depacketization.

The communication between the physical network and the container network segment is difficult: in the process of transforming enterprise cloud native migration, there is a demand for opening up the flow of things of container and non-container applications (such as virtual machines). If the popular Overlay container network scheme is adopted, the network is communicated by adopting an EIP scheme such as kube-ovn, and the EIP (elastic public network IP) is manually applied and allocated, so that the efficiency is low, the automation degree is poor, and the physical network segment IP is wasted; if an underway container network scheme such as Calico is adopted, the underlying network device is required to start BGP (Border Gateway Protocol ) functions, which is highly invasive.

Maintenance of the container segments is difficult: to conserve physical segment IP resources, each container cluster uses a separate segment. Causing cluster network segment management to be decentralized and conflict to be difficult to maintain.

Therefore, a container network management scheme with higher resource utilization, better network performance and smaller management difficulty is needed to adapt to the container network implementation in the cloud native reconstruction scene.

Fig. 1 shows a flowchart of a container network management method provided by an embodiment of the present invention, which is executed by a computer processing device. The computer processing device may include a cell phone, a notebook computer, etc. As shown in fig. 1, the method comprises the steps of:

step 10: when a network initialization request corresponding to a target container cluster is received, determining IP resource demand information of a target node in the target container cluster;

the target container cluster may be created in advance, and it should be noted that the type of the host where the target container cluster is deployed may be a virtual machine or a hybrid type of a virtual machine and a physical machine. The network initialization request is for requesting network initialization of the target container cluster such that the target container cluster has the capability to communicate with an external network. The IP resources in the IP resource requirement information may be IP addresses, and the specific requirement information may include the number of IP addresses, the type of IP addresses, and a network segment interval to which the IP addresses belong.

It is readily understood that the IP resource requirement information may be determined according to actual service requirements, and that the actual service requirements are implemented by means of configuration parameters related to the computing performance of the underlying host and container. Therefore, the determination of the IP resource demand information can be written by the user according to the service demand, or can be determined according to the calculation resource configuration parameters of the target node, so that the efficiency of IP address allocation of the target node is improved.

Thus, in yet another embodiment of the present invention, the determining of the IP resource requirement information may include:

step 101: reading a preset extension field in a node configuration file of the target node to obtain the IP resource demand information; the extension field is used for writing the IP resource requirement information.

The transfer of the IP resource requirement information which is autonomously determined by the user (such as a cluster manager) can be realized through an extension field preset in the node configuration file by a container cluster management platform (such as K8 s). Specifically, the extension field may be an annotation field in K8 s. The extension field is used for transferring custom types of information between the container management platform and the user. The latest IP resource demand information can be acquired by monitoring the extension field in the node configuration file of the target node in real time.

For example, the administrator manually specifies the capacity requirement of the container subnet segment of each host Node according to the specification size of the Node, and writes the capacity requirement into Node object annotation (accounting) of K8s cluster, such as target Node1 of 16G (referring to the memory size) for 4 cores (referring to the CPU kernel number), xx.kubernetes.io/need-ip:16 can be written in the annotation field, wherein the need-IP field (i.e. required IP) is used for representing the meaning of the extension field as the number of IP required by the target Node, so that the target Node can be specified according to the field information under the need-IP by at least 2 ¹⁶ An IP address. For a target Node2 of 8 cores (CPU core number) 32G (memory size), xx.kubernetes.io/reed-ip 32 can be written in the comment field to indicate that the target Node needs at least 2 ³² An IP address.

Or, considering that when the user inputs the IP resource requirement information, the user needs to know the container resource and the IP resource required by the specific service requirement, and the dependence on the manual network management experience is relatively large, and the efficiency and the accuracy are not guaranteed, further, in order to improve the automation degree and the accuracy of the container network management, the dependence of the IP resource allocation on the service experience is eliminated, and the determining process of the IP resource requirement information of the target node in the embodiment of the invention may further be as follows:

step 102: and calculating the number of the containers which can be accommodated by the target node according to the node specification information of the target node and the container specification information in the node.

The node specification information is used for representing configuration specifications of computing resources of a host machine where the target node is located, such as a CPU configuration number, a memory configuration capacity, and the like, and correspondingly, the node container specification information is used for representing configuration rules of computing resources of a single container on the target node, such as the CPU configuration number, the memory configuration capacity, and the like. It is easy to understand that the containers implement a specific function by allocating resources (including computing resources and IP resources) to the nodes, and the more computing resources that a single container occupies, the fewer the number of containers of the type that can be allocated on the target node, so the number of containers that can be accommodated of the target node can be determined according to the ratio value of the node specification information and the container specification information in the node.

Step 103: and determining IP resource demand information of the target node according to the number of the accommodating containers.

Wherein, considering that the containers are in one-to-one correspondence with the IP addresses, the number of containable containers can be determined as the number of IP addresses required by the target node.

It will be readily appreciated that before deploying the target container based on the target node, it is first necessary to create a node cluster in which the target node is located, and when the node cluster is initialized, an administrator may request an independent network segment to be used by the node cluster, so in still another embodiment of the present invention, before step 10, the method further includes:

step 110: acquiring a cluster creation request; the cluster creation request comprises a network segment to be distributed.

Wherein the network segment to be allocated is an independent container network segment (which may be denoted as clusteridr) manually allocated to the container cluster by an administrator at the time of cluster creation. For example, the network segment clusteridr to be allocated may be 192.168.0.0/16.

Step 111: and detecting network segment conflict between the network segment to be allocated and the occupied network segment, and determining the network segment to be allocated as the cluster available network segment when the network segment to be allocated and the occupied network segment are determined to have no conflict.

Before allocating the network segment to be allocated to the target container cluster, it needs to determine whether there is a conflict between the existing network segment already occupied by the container related to other services and the current network segment to be allocated, if so, it needs to suspend the subsequent network initialization process of the target container cluster, if not, it allocates the network segment to be allocated to the target container cluster as the available network segment of the cluster. The occupied network segment can be determined according to a CMDB database corresponding to a preset service system, and the container network of the target container cluster is provided with a locking mechanism by checking the conflict of the container network segments recorded in the CMDB database in real time, so that the concurrency reliability can be ensured.

Step 20: and searching in the available network segments of the clusters corresponding to the target container clusters according to the IP resource demand information to obtain the target network segments corresponding to the target nodes.

And respectively matching each IP address in the available network segments of the cluster with the IP resource demand information, and combining the matched IP addresses to obtain a target network segment corresponding to the target node. Specifically, when the IP resource requirement information is the number of target IP addresses, the number of unoccupied IP addresses of the number of target IP addresses may be screened from the available network segments of the cluster according to the occupation condition of the IP addresses in the available network segments of the cluster, so as to form the target network segment.

Alternatively, when the IP resource requirement information is the target IP type, an IP address whose type satisfies the target IP type and whose state is unoccupied in the available network segments of the cluster may be added to the target network segment. Optionally, when there is a specified requirement for the node network segment, the IP resource requirement information may be a target IP address interval, an unoccupied IP address in the available network segment of the cluster may be intercepted according to the target IP address interval, and when the IP address in the target IP address interval is unoccupied, the target IP address interval may be used as the target network segment.

In order to realize the recording and feedback of the network segment distribution result, the visualization of the subsequent container network management is convenient, and the target network segment can be written into an extension field in a node configuration file of the target node. As described in the foregoing step 101, the extension field is used for transferring information of a custom type between the container creator and the container management platform, so that by correspondingly writing the target network segment into the extension field, it is convenient for the user to obtain feedback of the satisfaction of the IP resource requirement information of the target node after writing the IP resource requirement information of the target node in the node configuration file. Specifically, continuing with the example in step 101, reference is made to fig. 2. As shown in FIG. 2, for node-1 of 4 cores 16G, the corresponding IP resource capacity requirement is determined to be 16, a container sub-network segment with the length of 16 is allocated to node-1, such as 192.168.0.0/28, and xx.kubernetes.io/podCIDR is written in an extension field in a node configuration file corresponding to node-1, wherein podCIDR (i.e. the container sub-network segment) is used for characterizing the sub-network segment allocated by the container in the node. Node-2 is configured identically to node-1 and its IP resource capacity requirements are identical to those of node-1, so that node-2 also has an IP segment allocation result of 192.168.0.0/28. For the node-3 of the 8-core 32G, the corresponding IP resource capacity requirement is determined to be 32, a container sub-network segment with the length of 32 is allocated to the node-3, such as 192.168.32.0/27, and xx.kubernetes.io/podCIDR is written in an extension field in a node configuration file corresponding to the node-3, namely 192.168.0.32/27.

Further, in order to improve the efficiency of searching for the available IP address in the available network segments of the cluster, and divide the target network segments from the available network segments of the cluster, reduce IP fragments as much as possible, improve the utilization rate of IP resources, and use bitmap files to perform state maintenance of the IP address of the available network segments of the cluster, where the IP resource requirement information includes the number of IP address requirements.

Step 20 further comprises: step 201: and constructing a bitmap file according to the occupation condition of the IP addresses in the available network segments of the cluster.

The bitmap file may be a bitmap file, in which an IP address corresponds to an identification bit, and an identification value on the identification bit is used to represent an occupation condition of the IP address. For example, the identification bit may identify 1 when the IP address is occupied and 0 when the IP address is unoccupied.

Step 202: and carrying out adjacent address combination on the number of unoccupied IP addresses required by the IP addresses according to the bitmap file to obtain a target network segment of the target node.

In order to avoid IP fragments to the greatest extent and improve the utilization rate of IP resources, the adjacent IP addresses, which are characterized by the values on the identification bits of the adjacent IP addresses, in the bitmap file can be combined to obtain alternative network segments, and then the number of the IP addresses required by the IP addresses is intercepted from the alternative network segments to serve as target network segments.

Step 30: and carrying out route registration in preset three-layer network equipment for the target node according to the target network segment, so that the three-layer network equipment carries out flow forwarding for the target node.

In consideration of that the IP resource requirement information of the target node may be dynamically changed, particularly in a cloud native modification scenario, since the configuration information of the virtual machine serving as the host machine may be dynamically adjusted, it is necessary to dynamically adjust the specification of the IP resource corresponding to the host node, so that the IP resource is adapted to the computing resource configured on the node, and the situations that the computing performance is high, but the IP address is not enough, or the computing performance is low, but the IP address is excessive are avoided, thereby avoiding the waste of the IP resource or the computing resource. Therefore, the target network segment corresponding to the target node can be updated in real time according to the change of the IP resource demand information, i.e. the update frequency of the target network segment may be higher.

Based on the above, the existing method that the container is hung on the virtual bridge or the OVS bridge is considered, when the container route is updated, the efficiency is lower, the scene that the container is updated more with the IP address is not adapted, the link length for forwarding data based on the bridge layer is long, the network performance is weaker, and the traditional overlay scheme also has the performance loss of package and unpacking. Correspondingly, the individuation degree of the policy routing is considered to be better, the policy routing can be set and modified more freely, in the forwarding process of the three-layer routing equipment, packets and unpacks are not needed, the network performance is better through the routing forwarding directly, and forwarding performance loss brought by a network bridge layer is eliminated through the form of the policy routing after the traffic reaches the virtual machine, so that the network performance of the container can be improved.

Therefore, in order to improve the performance of the container network and the update efficiency of the IP address, in the embodiment of the present invention, the container network is implemented by adopting a three-layer routing forwarding manner. Specifically, the target network segment and the target node can be bound, and then the target network segment bound with the target node is written into the global dynamic routing table of the three-layer network device by calling the bottom layer network device interface, so that when the three-layer network device receives external traffic, the three-layer network device searches in the global dynamic routing table according to the target address of the external traffic, and when the target network segment with the target node is found, the external traffic is guided to the target node, and the external access to the container of the target node is realized.

After the registration of the target node in the three-layer routing device is completed, in order to further realize the container-level flow diversion, a policy route can be established for the target node, so that the next hop of the flow reaching the target node is guided through the policy route until the target address is reached. Specifically, step 30 may include:

step 301: a container creation request is obtained for creating a target container on the target node.

Wherein the container creation request may be sent by the administrator in step 110 described above.

Step 302: and distributing the target IP from the target network segment to the target container.

Specifically, searching for an unoccupied IP address in the target network segment, and distributing the searched unoccupied IP value as a target IP to the target container.

Step 303: and creating a policy routing rule corresponding to the target container so as to guide the traffic forwarded to the target node by the three-layer network equipment into the target container.

And writing the policy routing rule corresponding to the target container into the policy routing entry corresponding to the target node, wherein one policy routing entry comprises the triggering condition of the node priority corresponding to the node priority and the execution action after triggering. By way of example, FIG. 3 shows a data plane schematic of a container accessed across hosts. Fig. 4 shows a schematic policy routing diagram of the host node-1, fig. 5 shows a schematic diagram of the routing table 100 of the host node-1, fig. 6 shows a schematic policy routing diagram of the host node-2, and fig. 7 shows a schematic diagram of the routing table main of the host node-2.

The global dynamic routing table in fig. 3 performs route registration on the IP network segment 192.168.1.0/24 bound by the node-1 and the IP network segment 192.168.2.0/24 bound by the node-2, so that the external traffic is guided into the node-1 through 10.118.8.5 and guided into the node-2 through 10.118.8.6. After the allocation of the IP address of the container to the target node is completed, in the actual application process, the network processing procedure of the container may be as follows: acquiring a flow request sent by a source address aiming at a target container; inquiring according to a policy route configured on a target node where the target container is located by the source address, and obtaining a forwarding path between the source address and the target container; the strategy route comprises a plurality of preset target node priorities, triggering conditions and corresponding route searching actions; and forwarding the flow request to the target container according to the forwarding path. Specifically, as shown in fig. 3-7, container a (192.168.1.1) accesses container B (192.168.2.1), and fills container a with default gateway 169.254.1.1 and static ARP entry, because 169.254.1.1 is not in the same subnet as IP address 192.168.1.1 of container a, it cannot use ARP protocol to obtain gateway Mac address, and thus fills a static ARP entry, making Mac address of gateway 169.254.1.1 be Mac address of veth device on node, so traffic goes smoothly to host node-1. After the packet arrives at node-1, it is determined that the routing table 100 needs to be viewed according to the direction of the host node policy route, from 192.168.1.1look up 100. And then from the eth0 network card according to the direction of the routing table 100 shown in fig. 5. The data packet is forwarded to node-2 via layer 3 routing forwarding. After the data packet reaches the node-2, the routing table main is checked according to the routing direction of the policy of the node-2 as shown in fig. 6, and the routing table main is shown in fig. 7, so that the next step is directed to be sent to the corresponding veth equipment, and finally the target address is reached.

In view of the fact that in the cloud native reconstruction scenario, mixed use of container and non-container technologies often occurs, for example, a virtual machine is used as a host node in a container cluster, and for a host node of a virtual machine type, it is considered that resource allocation of the virtual machine can be dynamically adjusted, and in the existing scheme of allocating an IP address fixedly, a situation that a computing resource after being dynamically adjusted is not adapted to a fixed IP resource exists, so that resource utilization is low. Thus, in a further embodiment of the present invention, after step 30, further comprising:

step 311: and detecting the requirement change information of the IP resource requirement information of the target node.

When the IP resource requirement is obtained by reading an extension field in a node configuration file, the requirement change information can be obtained by monitoring the extension field in the node configuration file of the target node, for example, monitoring a value of a need-IP in an annotation field.

Correspondingly, when the IP resource demand information is automatically calculated according to the node specification information and the container specification information in the node, the demand change information can be correspondingly calculated by detecting the node specification information and the change information of the container specification information in the node.

Step 312: and dynamically adjusting the target network segment according to the demand change information to obtain an adjusted network segment.

When the IP resource demand of the target node increases, the target network segment needs to be expanded, specifically, an idle IP address may be added to the target network segment, and correspondingly, when the IP resource of the target node decreases, in order to avoid the waste of the IP resource, the IP address that is not allocated in the target network segment may be recovered. Thus, in particular, step 312 further comprises:

step 3121: and when the IP resource requirement of the target node is determined to be increased, searching an idle network segment in the available network segments of the cluster, and adding the idle network segment into the target network segment.

Wherein, the free IP can be added to the target network segment by searching the bitmap file for a new free IP. Further, the idle IP may also be written into an extension field corresponding to the target node.

Step 3122: and when the IP resource requirement of the target node is determined to be reduced, recycling the unoccupied IP in the target network segment.

Wherein, the recovery treatment process comprises: and detecting the IP occupation condition on the target node, recovering the unassigned IP, and when the IP is assigned, canceling recovery and performing error reporting processing. Further, the recovery condition of the IP may also be written into an extension field corresponding to the target node.

Step 313: and carrying out route registration again in preset three-layer network equipment for the target node according to the adjusted network segment.

In order to enable the three-layer network device to forward the traffic for the target node after the network segment is adjusted, the adjusted network segment is bound with the target node, and the bottom layer network device interface is called to write the adjusted network segment corresponding to the target node into the global dynamic routing table corresponding to the three-layer network device, so that three-layer routing registration of the target node after the network segment is adjusted is completed.

Compared with the existing scheme adopting the popular Overlay container network, the network opening usually adopts an EIP scheme such as kube-ovn, and the scheme needs to manually apply and distribute EIP (elastic public network IP), so that the efficiency is low, the automation degree is poor, and the physical network segment IP is wasted; if an underway container network scheme such as Calico is adopted, the underlying network device is required to start BGP (Border GatewayProtocol ) functions, which is highly invasive. The embodiment of the invention uses the independent container network segment, avoids the waste of IP resources of the physical network segment, simultaneously efficiently realizes the communication between the container network and the physical network in a three-layer routing mode, furthest improves the automation degree and does not need to manually configure the network connectivity. Meanwhile, the BGP function is not required to be started, and the network security risk is reduced.

In yet another embodiment of the present invention, for low-coupling and high-availability, high-reusability considerations of software design, this may be achieved by a target container network component as shown in fig. 8, wherein the target container network component comprises a total of 3-part components as shown in fig. 8:

(1) Agent (Agent): each node of the container cluster is deployed and is responsible for installing binary files of the main-CNI binary and other universal plugins to a designated directory and configuring designated kernel parameters. Monitoring the change of PodCIDR annotation of the node object, and calling the bottom layer device interface to register the route.

(2) CNI plug-in: is a binary file installed at each node and is only invoked by Kubelet to run when a pod is created and deleted. Corresponding policy route entries can be created or deleted for the Pod.

(3) IPAMD: and (3) monitoring IP capacity requirements filled by an administrator in the annotation of each Node, using a Bitmap algorithm to allocate a container sub-network segment (PodCIDR) as required, and filling the result into the annotation of the Node object after allocation. It should be noted that only one IPAMD needs to be installed in one container cluster, which is responsible for global IP address allocation and record.

The embodiment of the invention monitors Node object annotation in real time through the target container management component shown in fig. 8, dynamically registers the form of a routing table, supports the dynamic modification of the capacity requirement of the Node container network segment, improves the utilization rate of the IP resources of the container network and the virtual computing resources, and is more suitable for large-scale container clusters in enterprises.

According to the container management method provided by the embodiment of the invention, when a network initialization request corresponding to a target container cluster is received, IP resource demand information of a target node in the target container cluster is determined; searching in the available network segments of the clusters corresponding to the target container clusters according to the IP resource demand information to obtain target network segments corresponding to the target nodes; and carrying out route registration in preset three-layer network equipment for the target node according to the target network segment, so that the three-layer network equipment carries out flow forwarding for the target node. Thus, unlike the existing IP resource allocation for nodes in a container cluster, the IP resource allocation is generally average allocation, and the actual IP requirements of host nodes with different configurations are not considered, so that the problem that the computing resources of the nodes are not matched with the IP resources allocated to the nodes exists. According to the embodiment of the invention, the IP allocation can be carried out for the target node according to the IP resource demand information of the target node and the available network segment information of the cluster where the node is located, so that the IP resources in the container cluster and the resource utilization rate of the container resources are improved, and the resource utilization condition of the container in the cloud primary transfer scene and the non-container application such as the virtual machine in the mixed use environment is optimized. Further, in order to adapt to the flexible on-demand IP allocation manner, unlike the prior art that a bridge is generally adopted to forward the container traffic, the embodiment of the invention directly forwards through three layers of routes, so that on one hand, the forwarding performance loss of the bridge layer can be eliminated, and more importantly, the configuration and registration of the three layers of routes are more flexible and easy to customize, so that when the IP requirement and allocation scheme are changed, the updating can be synchronously performed in real time, and the management efficiency and the network availability of the container network are ensured.

Fig. 9 is a schematic structural diagram of a container network management device according to an embodiment of the present invention. As shown in fig. 3, the apparatus 40 includes: a determination module 401, a lookup module 402, and a registration module 403.

A determining module 401, configured to determine IP resource requirement information of a target node in a target container cluster when a network initialization request corresponding to the target container cluster is received;

a searching module 402, configured to search in a cluster available network segment corresponding to the target container cluster according to the IP resource requirement information, to obtain a target network segment corresponding to the target node;

and a registration module 403, configured to perform route registration in a preset three-layer network device for the target node according to the target network segment, so that the three-layer network device performs traffic forwarding for the target node.

The operation process of the container network management device provided in the embodiment of the present invention is substantially the same as that of the foregoing method embodiment, and will not be described again.

The container network management device provided by the embodiment of the invention determines the IP resource demand information of the target node in the target container cluster when receiving the network initialization request corresponding to the target container cluster; searching in the available network segments of the clusters corresponding to the target container clusters according to the IP resource demand information to obtain target network segments corresponding to the target nodes; and carrying out route registration in preset three-layer network equipment for the target node according to the target network segment, so that the three-layer network equipment carries out flow forwarding for the target node. Thus, unlike the existing IP resource allocation for nodes in a container cluster, the IP resource allocation is generally average allocation, and the actual IP requirements of host nodes with different configurations are not considered, so that the problem that the computing resources of the nodes are not matched with the IP resources allocated to the nodes exists. According to the embodiment of the invention, the IP allocation can be carried out for the target node according to the IP resource demand information of the target node and the available network segment information of the cluster where the node is located, so that the IP resources in the container cluster and the resource utilization rate of the container resources are improved, and the resource utilization condition of the container in the cloud primary transfer scene and the non-container application such as the virtual machine in the mixed use environment is optimized. Further, in order to adapt to the flexible on-demand IP allocation manner, unlike the prior art that a bridge is generally adopted to forward the container traffic, the embodiment of the invention directly forwards through three layers of routes, so that on one hand, the forwarding performance loss of the bridge layer can be eliminated, and more importantly, the configuration and registration of the three layers of routes are more flexible and easy to customize, so that when the IP requirement and allocation scheme are changed, the updating can be synchronously performed in real time, and the management efficiency and the network availability of the container network are ensured.

Fig. 10 is a schematic structural diagram of a container network management device according to an embodiment of the present invention, and the embodiment of the present invention is not limited to the specific implementation of the container network management device.

As shown in fig. 10, the container network management apparatus may include: a processor 502, a communication interface (Communications Interface) 504, a memory 506, and a communication bus 508.

Wherein: processor 502, communication interface 504, and memory 506 communicate with each other via communication bus 508. A communication interface 504 for communicating with network elements of other devices, such as clients or other servers. The processor 502 is configured to execute the program 510, and may specifically perform the relevant steps in the embodiment of the container network management method described above.

In particular, program 510 may include program code comprising computer-executable instructions.

The processor 502 may be a central processing unit CPU, or a specific integrated circuit ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement embodiments of the present invention. The one or more processors comprised by the container network management device may be the same type of processor, such as one or more CPUs; but may also be different types of processors such as one or more CPUs and one or more ASICs.

A memory 506 for storing a program 510. Memory 506 may comprise high-speed RAM memory or may also include non-volatile memory (non-volatile memory), such as at least one disk memory.

The program 510 may be specifically invoked by the processor 502 to cause the container network management device to:

The container network management equipment provided by the embodiment of the invention determines IP resource demand information of a target node in a target container cluster when a network initialization request corresponding to the target container cluster is received; searching in the available network segments of the clusters corresponding to the target container clusters according to the IP resource demand information to obtain target network segments corresponding to the target nodes; and carrying out route registration in preset three-layer network equipment for the target node according to the target network segment, so that the three-layer network equipment carries out flow forwarding for the target node. Thus, unlike the existing IP resource allocation for nodes in a container cluster, the IP resource allocation is generally average allocation, and the actual IP requirements of host nodes with different configurations are not considered, so that the problem that the computing resources of the nodes are not matched with the IP resources allocated to the nodes exists. According to the embodiment of the invention, the IP allocation can be carried out for the target node according to the IP resource demand information of the target node and the available network segment information of the cluster where the node is located, so that the IP resources in the container cluster and the resource utilization rate of the container resources are improved, and the resource utilization condition of the container in the cloud primary transfer scene and the non-container application such as the virtual machine in the mixed use environment is optimized. Further, in order to adapt to the flexible on-demand IP allocation manner, unlike the prior art that a bridge is generally adopted to forward the container traffic, the embodiment of the invention directly forwards through three layers of routes, so that on one hand, the forwarding performance loss of the bridge layer can be eliminated, and more importantly, the configuration and registration of the three layers of routes are more flexible and easy to customize, so that when the IP requirement and allocation scheme are changed, the updating can be synchronously performed in real time, and the management efficiency and the network availability of the container network are ensured.

An embodiment of the present invention provides a computer readable storage medium storing at least one executable instruction that, when executed on a container network management device, causes the container network management device to perform the container network management method in any of the method embodiments described above.

The executable instructions may be specifically operable to cause the container network management device to:

The operation process of the executable instructions stored in the computer storage medium provided in the embodiment of the present invention is substantially the same as that of the foregoing method embodiment, and will not be repeated.

The executable instructions stored by the computer storage medium provided by the embodiment of the invention determine the IP resource demand information of the target nodes in the target container cluster when receiving the network initialization request corresponding to the target container cluster; searching in the available network segments of the clusters corresponding to the target container clusters according to the IP resource demand information to obtain target network segments corresponding to the target nodes; and carrying out route registration in preset three-layer network equipment for the target node according to the target network segment, so that the three-layer network equipment carries out flow forwarding for the target node. Thus, unlike the existing IP resource allocation for nodes in a container cluster, the IP resource allocation is generally average allocation, and the actual IP requirements of host nodes with different configurations are not considered, so that the problem that the computing resources of the nodes are not matched with the IP resources allocated to the nodes exists. According to the embodiment of the invention, the IP allocation can be carried out for the target node according to the IP resource demand information of the target node and the available network segment information of the cluster where the node is located, so that the IP resources in the container cluster and the resource utilization rate of the container resources are improved, and the resource utilization condition of the container in the cloud primary transfer scene and the non-container application such as the virtual machine in the mixed use environment is optimized. Further, in order to adapt to the flexible on-demand IP allocation manner, unlike the prior art that a bridge is generally adopted to forward the container traffic, the embodiment of the invention directly forwards through three layers of routes, so that on one hand, the forwarding performance loss of the bridge layer can be eliminated, and more importantly, the configuration and registration of the three layers of routes are more flexible and easy to customize, so that when the IP requirement and allocation scheme are changed, the updating can be synchronously performed in real time, and the management efficiency and the network availability of the container network are ensured.

When a network initialization request corresponding to a target container cluster is received, the IP resource demand information of a target node in the target container cluster is determined; searching in the available network segments of the clusters corresponding to the target container clusters according to the IP resource demand information to obtain target network segments corresponding to the target nodes; and carrying out route registration in preset three-layer network equipment for the target node according to the target network segment, so that the three-layer network equipment carries out flow forwarding for the target node. Thus, unlike the existing IP resource allocation for nodes in a container cluster, the IP resource allocation is generally average allocation, and the actual IP requirements of host nodes with different configurations are not considered, so that the problem that the computing resources of the nodes are not matched with the IP resources allocated to the nodes exists. According to the embodiment of the invention, the IP allocation can be carried out for the target node according to the IP resource demand information of the target node and the available network segment information of the cluster where the node is located, so that the IP resources in the container cluster and the resource utilization rate of the container resources are improved, and the resource utilization condition of the container in the cloud primary transfer scene and the non-container application such as the virtual machine in the mixed use environment is optimized. Further, in order to adapt to the flexible on-demand IP allocation manner, unlike the prior art that a bridge is generally adopted to forward the container traffic, the embodiment of the invention directly forwards through three layers of routes, so that on one hand, the forwarding performance loss of the bridge layer can be eliminated, and more importantly, the configuration and registration of the three layers of routes are more flexible and easy to customize, so that when the IP requirement and allocation scheme are changed, the updating can be synchronously performed in real time, and the management efficiency and the network availability of the container network are ensured.

The embodiment of the invention provides a container network management device for executing the container network management method.

Embodiments of the present invention provide a computer program that can be invoked by a processor to cause a container network management device to perform the container network management method of any of the method embodiments described above.

Embodiments of the present invention provide a computer program product comprising a computer program stored on a computer readable storage medium, the computer program comprising program instructions which, when run on a computer, cause the computer to perform the container network management method of any of the method embodiments described above.

The algorithms or displays presented herein are not inherently related to any particular computer, virtual system, or other apparatus. Various general-purpose systems may also be used with the teachings herein. The required structure for a construction of such a system is apparent from the description above. In addition, embodiments of the present invention are not directed to any particular programming language. It will be appreciated that the teachings of the present invention described herein may be implemented in a variety of programming languages, and the above description of specific languages is provided for disclosure of enablement and best mode of the present invention.

In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.

Similarly, it should be appreciated that in the above description of exemplary embodiments of the invention, various features of the embodiments of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. However, the disclosed method should not be construed as reflecting the intention that: i.e., the claimed invention requires more features than are expressly recited in each claim.

Those skilled in the art will appreciate that the modules in the apparatus of the embodiments may be adaptively changed and disposed in one or more apparatuses different from the embodiments. The modules or units or components of the embodiments may be combined into one module or unit or component, and they may be divided into a plurality of sub-modules or sub-units or sub-components. Any combination of all features disclosed in this specification (including any accompanying claims, abstract and drawings), and all of the processes or units of any method or apparatus so disclosed, may be used in combination, except insofar as at least some of such features and/or processes or units are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings), may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word "comprising" does not exclude the presence of elements or steps not listed in a claim. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by one and the same item of hardware. The use of the words first, second, third, etc. do not denote any order. These words may be interpreted as names. The steps in the above embodiments should not be construed as limiting the order of execution unless specifically stated.

Claims

1. A method of container network management, the method comprising:

2. The method according to claim 1, wherein after the route registration is performed in a preset three-layer network device for the target node according to the target network segment, so that the three-layer network device performs traffic forwarding for the target node, the method includes:

3. The method according to claim 2, wherein dynamically adjusting the target network segment according to the demand change information to obtain an adjusted network segment comprises:

4. The method according to claim 1, wherein determining IP resource requirement information of a target node in a target container cluster when receiving a network initialization request corresponding to the target container cluster comprises:

5. The method according to claim 1, wherein the performing route registration for the target node according to the node network segment in a preset three-layer network device, so that the three-layer network device performs traffic forwarding for the target node, includes:

distributing target IP from the target network segment to the target container;

6. The method according to claim 1, wherein before determining IP resource requirement information of a target node in the target container cluster when the network initialization request corresponding to the target container cluster is received, the method comprises:

7. The method of claim 1, wherein the IP resource requirement information includes an IP address requirement number; the searching is carried out in the available network segments of the clusters corresponding to the target container clusters according to the IP resource demand information to obtain the target network segments corresponding to the target nodes, and the method comprises the following steps:

8. A container network management apparatus, the apparatus comprising:

9. A container network management device, comprising: the device comprises a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface complete communication with each other through the communication bus;

The memory is configured to store at least one executable instruction that causes the processor to perform the operations of the container network management method of any one of claims 1-7.

10. A computer readable storage medium, wherein at least one executable instruction is stored in the storage medium, which when run on a container network management device causes the container network management device to perform the operations of the container network management method according to any one of claims 1-7.