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

Abstract

Embodiments of the present application relate to the technical field of network communication, and disclose a container network management method, device and equipment and a computer storage medium, the method comprising: when a network initialization request corresponding to a target container cluster is received, determining IP resource requirement information of a target node in the target container cluster; searching 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 performing routing registration for the target node in a preset three-layer network device according to the target network segment, so that the three-layer network device performs traffic forwarding for the target node. In the foregoing manner, the embodiments of the present application improve the resource utilization of container computing resources and IP resources of a container network.

Description

Technical Field

[0001] This invention relates to the field of container technology, specifically to a container network management method, apparatus, device, and computer storage medium. Background Technology

[0002] Cloud-native technologies have gained widespread popularity in recent years due to their advanced nature, and various enterprise information systems urgently need to undergo cloud-native transformation. However, due to the high cost of purchasing private clouds and the long migration cycle, transforming applications based on traditional enterprise IT infrastructure into cloud-native systems has become the optimal choice for many enterprises to reduce costs and increase efficiency.

[0003] During the cloud-native transformation process, the inventors discovered that traditional container networking solutions typically divide the cluster network segment evenly across nodes, resulting in a fixed available network segment for each node. However, considering the mixed use of containers and non-container applications (such as virtual machines) during cloud-native migration, where containers are deployed on virtual machines, and each virtual machine has different host machine resource specifications and can support a different number of containers, this leads to a mismatch between the computing resources of a node and the IP resources allocated to that node, resulting in wasted IP resources or container computing resources. Therefore, a more rational and efficient container network management solution is needed to further reduce costs and increase efficiency in cloud-native transformation. Summary of the Invention

[0004] In view of the above problems, embodiments of the present invention provide a container network management method to solve the problem of wasted IP resources or container computing resources in container clusters in the prior art.

[0005] According to one aspect of the present invention, a container network management method is provided, the method comprising:

[0006] When a network initialization request corresponding to the target container cluster is received, the IP resource requirement information of the target node in the target container cluster is determined.

[0007] Based on the IP resource requirement information, a search is performed on the cluster available network segment corresponding to the target container cluster to obtain the target network segment corresponding to the target node;

[0008] Based on the target network segment, the target node performs route registration in a preset Layer 3 network device, so that the Layer 3 network device forwards traffic for the target node.

[0009] In an alternative approach, the method further includes:

[0010] Detect changes in the IP resource requirements of the target node;

[0011] The target network segment is dynamically adjusted based on the aforementioned demand change information to obtain the adjusted network segment;

[0012] Based on the adjusted network segment, the target node will re-register its route in the preset Layer 3 network device.

[0013] In an alternative approach, the method further includes:

[0014] When it is determined that the IP resource demand of the target node increases, an idle network segment is searched in the available network segments of the cluster, and the idle network segment is added to the target network segment;

[0015] When it is determined that the IP resource demand of the target node is reduced, the unused IPs in the target network segment are reclaimed.

[0016] In an alternative approach, the method further includes:

[0017] The IP resource requirement information is obtained by reading the preset extended fields in the node configuration file of the target node; wherein, the extended fields are used to write the IP resource requirement information.

[0018] Alternatively, the number of containers that the target node can accommodate can be calculated based on the node specification information and the internal container specification information of the target node.

[0019] The IP resource requirements of the target node are determined based on the number of containers that can be accommodated.

[0020] In an alternative approach, the method further includes:

[0021] Obtain a container creation request, which is used to create a target container on the target node;

[0022] Assign a target IP address to the target container from the target network segment;

[0023] Create policy routing rules corresponding to the target container to direct traffic forwarded by the Layer 3 network device to the target node into the target container.

[0024] In an alternative approach, the method further includes:

[0025] Obtain a cluster creation request; the cluster creation request includes the network segment to be allocated;

[0026] Based on the network segment to be allocated and the already occupied network segment, network segment conflict detection is performed. When it is determined that there is no conflict between the network segment to be allocated and the already occupied network segment, the network segment to be allocated is determined as the available network segment of the cluster.

[0027] In one alternative approach, the IP resource demand information includes the number of IP addresses required; the method further includes:

[0028] A bitmap file is constructed based on the occupancy of IP addresses within the available network segment of the cluster;

[0029] Based on the bitmap file, adjacent addresses of the required number of unoccupied IP addresses are merged to obtain the target network segment of the target node.

[0030] According to another aspect of the present invention, a container network management apparatus is provided, comprising:

[0031] The determination module is used to determine the IP resource requirement information of the target node in the target container cluster when a network initialization request corresponding to the target container cluster is received.

[0032] The lookup module is used to search within the available network segment of the target container cluster based on the IP resource requirement information to obtain the target network segment corresponding to the target node.

[0033] The registration module is used to register routes for the target node in a preset Layer 3 network device according to the target network segment, so that the Layer 3 network device can forward traffic for the target node.

[0034] According to another aspect of the present invention, a container network management device is provided, including: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other through the communication bus;

[0035] The memory is used to store at least one executable instruction that causes the processor to perform operations as described in any of the preceding embodiments of the container network management method.

[0036] According to another aspect of the present invention, a computer-readable storage medium is provided, the storage medium storing at least one executable instruction that causes a container network management device to perform the operations of any of the preceding container network management method embodiments.

[0037] This invention, upon receiving a network initialization request corresponding to a target container cluster, determines the IP resource requirements of a target node within the target container cluster. Based on these requirements, it searches the available network segments of the target container cluster to obtain the target network segment corresponding to the target node. Then, it registers the target node's route on a pre-defined Layer 3 network device using this target network segment, enabling the Layer 3 network device to forward traffic for the target node. This differs from existing methods that typically allocate IP resources evenly to nodes within a container cluster, failing to consider the actual IP requirements of host nodes with different configurations, leading to a mismatch between the node's computing resources and the allocated IP resources. This invention allocates IP resources to the target node on demand based on its IP resource requirements and the available network segments of the cluster it resides in, thereby improving the utilization of IP and container resources within the container cluster and optimizing resource utilization in cloud-native migration scenarios where containers and non-container applications such as virtual machines coexist. Furthermore, in order to adapt to the above-mentioned flexible on-demand IP allocation method, unlike the existing technology that generally uses bridges to forward container traffic, the embodiments of the present invention directly forward traffic through Layer 3 routing. This not only eliminates the forwarding performance loss of the bridge layer, but more importantly, the configuration and registration of Layer 3 routing are more flexible and customizable. As a result, it can be updated in real time when IP requirements and allocation schemes change, ensuring the management efficiency and network availability of the container network.

[0038] The above description is merely an overview of the technical solutions of the embodiments of the present invention. In order to better understand the technical means of the embodiments of the present invention and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0039] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0040] Figure 1 A flowchart illustrating the container network management method provided in an embodiment of the present invention is shown;

[0041] Figure 2 This diagram illustrates the target network segment allocation result in a container network management method provided in another embodiment of the present invention.

[0042] Figure 3 This diagram illustrates the data plane of a container cross-host access scenario in a container network management method provided in another embodiment of the present invention.

[0043] Figure 4 This diagram illustrates the policy routing of host node-1 in a container network management method provided in another embodiment of the present invention.

[0044] Figure 5 This diagram illustrates the routing table 100 of host node-1 in a container network management method provided in another embodiment of the present invention.

[0045] Figure 6 This diagram illustrates the policy routing of host node-2 in a container network management method provided in another embodiment of the present invention.

[0046] Figure 7 This diagram illustrates the routing table main of host node-2 in a container network management method provided in another embodiment of the present invention.

[0047] Figure 8 This diagram illustrates the structure of the container management component upon which the container network management method provided in another embodiment of the present invention is based;

[0048] Figure 9 A schematic diagram of the structure of the container network management device provided in an embodiment of the present invention is shown;

[0049] Figure 10 A schematic diagram of the structure of a container network management device provided in an embodiment of the present invention is shown. Detailed Implementation

[0050] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0051] A brief explanation of the relevant terms:

[0052] Cloud Native: Containers are a key technology in cloud-native technologies, with microservices, DevOps, and CI / CD all built on top of them. As a lightweight virtualization technology, containers offer higher resource utilization efficiency compared to virtual machines because they don't require a separate operating system for each application. Therefore, instances are smaller, and creation and migration are faster. Virtual machines are hardware-level virtualization, while containers are operating system or application-level virtualization. Both containers and virtual machines are essentially virtualization technologies, but they operate at different levels. Containers are above the operating system, unlike virtual machines which lack an operating system. Different containers can share the operating system, making them more lightweight, faster to start, and more efficient. However, this also means that containers have weaker isolation and lower security compared to virtual machines. On the other hand, virtual machines are more widely used, and related tools are more mature and complete. In most cases, most enterprises will use both virtual machines and containers. Therefore, containers and virtualization are likely to coexist for a considerable period, especially considering that most enterprises have already widely deployed virtualization technologies.

[0053] Node: The smallest unit of computing hardware in Kubernetes. It is a representation of a single machine in the 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 like Google Cloud Platform.

[0054] Cluster: Nodes aggregate resources to form a more powerful cluster. When an application is deployed to a cluster, the cluster intelligently handles the assignment of work to the target nodes. If any target nodes are added or removed, the cluster will shift the workload as needed.

[0055] Container Pods: Kubernetes does not run containers directly; instead, it encapsulates one or more containers into a high-level structure called a Pod. Any containers within the same Pod will share the same namespace and local network. Containers can easily communicate with other containers within the same container, as if they were on the same machine while maintaining a degree of isolation. Pods are allocated on Nodes based on scheduling; a Node can host multiple pods, and a pod can host multiple containers. Container ports within a Pod do not conflict, and all containers within a Pod share the network stack and storage volumes. Resources of different containers within the same Pod can be accessed via localhost.

[0056] Policy-based routing: This method involves forwarding packets according to policies and then looking up the routing table after a failure. It requires manual hop-by-hop configuration to ensure packets are forwarded according to the policy. Routing policies select the next hop based on the destination address within the routing table, considering different conditions (source address, transport protocol, port). Linux systems use multiple routing tables, and policy-based routing redirects requests to different tables based on these conditions. For example, a source address might use routing table A for certain ranges, while other packets might use routing table B. Policy-based routing controls these rules. In Linux, a rule primarily contains three pieces of information: its priority, the conditions, and the routing table.

[0057] Default Gateway: The device connecting the subnet to the external network, typically a router. When a computer sends information, it uses the subnet mask to determine whether the target host is on the local subnet based on the destination address. If the target host is on the local subnet, the message can be sent directly. If the target is not on the local subnet, the message is sent to the default gateway / router, which forwards it to other networks to further search for the target host.

[0058] Configuration Management Database (CMDB): A logical database that contains information about the entire lifecycle of configuration items and the relationships between them (including physical relationships, real-time communication relationships, non-real-time communication relationships, and dependencies).

[0059] Before describing the embodiments of the present invention, the prior art and its problems will be further explained:

[0060] Cloud-native technologies have gained widespread popularity in recent years due to their advanced nature, and various enterprise information systems urgently need to undergo cloud-native transformation. However, due to the high cost of purchasing private clouds and the long migration cycle, transforming applications based on traditional enterprise IT infrastructure into cloud-native systems has become the optimal choice for many enterprises to reduce costs and increase efficiency. Due to the lack of underlying professional network virtualization capabilities and the support of a wide range of cloud products, at least the following problems need to be addressed to complete cloud-native transformation on existing enterprise infrastructure:

[0061] Low utilization of container network IP resources: In a container cluster, each host machine has different resource specifications and can support a different number of containers. Traditional container networking solutions ignore these differences and write a fixed-length podCIDR as a host machine attribute into the Node object field, resulting in low resource utilization and hindering cost reduction and efficiency improvement for enterprises.

[0062] Poor network performance: To ensure the elasticity of cluster scaling, container clusters are often composed of virtual machines. Containers are deployed on virtual machines and then connected to virtual bridges or OVS bridges. The long data forwarding links result in weak performance. Traditional overlay solutions also suffer from performance losses during packet encapsulation and decapsulation.

[0063] Connecting physical networks and container network segments is challenging: During enterprise cloud-native migration and transformation, there is a need to connect east-west traffic between containers and non-container applications (such as virtual machines). If a popular overlay container network solution is adopted, network connectivity is usually achieved using EIP solutions such as kube-ovn. These solutions require manual application and allocation of EIPs (Elastic Public IPs), which is not only inefficient and lacks automation but also wastes physical network segment IPs. If an underlay container network solution such as Calico is adopted, the underlying network devices need to enable BGP (Border Gateway Protocol) functionality, which is highly intrusive.

[0064] Maintaining container network segments is difficult: To conserve physical network IP resources, each container cluster uses a separate network segment. This results in fragmented cluster network segment management and makes it difficult to maintain network stability due to conflicts.

[0065] Therefore, a container network management solution with higher resource utilization, better network performance, and easier management is needed to adapt to the implementation of container networks in cloud-native transformation scenarios.

[0066] Figure 1 A flowchart of a container network management method provided in an embodiment of the present invention is shown. This method is executed by a computer processing device. The computer processing device may include a mobile phone, a laptop computer, etc. Figure 1 As shown, the method includes the following steps:

[0067] Step 10: When a network initialization request corresponding to the target container cluster is received, determine the IP resource requirements of the target node in the target container cluster;

[0068] The target container cluster can be pre-created. It should be noted that the host on which the target container cluster is deployed can be a virtual machine or a hybrid of virtual and physical machines. The network initialization request is used to request network initialization of the target container cluster, enabling it to communicate with external networks. The IP resources in the IP resource requirement information can be IP addresses. Specific requirement information may include the number of IP addresses, the type of IP addresses, and the network segment range to which the IP addresses belong.

[0069] It's easy to understand that IP resource requirements can be determined based on actual business needs, and the implementation of these needs relies on the underlying host machine and the configuration parameters related to the computing performance of the containers. Therefore, IP resource requirements can be determined by the user based on business needs, or they can be determined based on the computing resource configuration parameters of the target node, thereby improving the efficiency of IP address allocation for the target node.

[0070] Therefore, in another embodiment of the present invention, the process of determining IP resource demand information may include:

[0071] Step 101: Read the preset extended fields in the node configuration file of the target node to obtain the IP resource requirement information; wherein, the extended fields are used to write the IP resource requirement information.

[0072] This can be achieved by using pre-defined extended fields in the node configuration files of a container cluster management platform (such as Kubernetes) to transmit IP resource requirements determined by the user (e.g., the cluster administrator). Specifically, these extended fields can be annotation fields in Kubernetes. These extended fields are used to transmit custom types of information between the container management platform and the user. By monitoring these extended fields in the target node's configuration file in real time, the latest IP resource requirements can be obtained.

[0073] For example, the administrator manually specifies the container subnet capacity requirement for each host node based on its specifications and writes it into the Node object annotation of the Kubernetes cluster. For instance, for a target node Node1 with 4 CPU cores and 16GB of memory, the annotation field could contain `xx.kubernetes.io / need-ip:16`. Here, the `need-ip` field (i.e., the required IP address) indicates the number of IPs needed by the target node. Therefore, based on the information in the `need-ip` field, it can be determined that the target node requires at least 2... 16 For a target node Node2 with 8 CPU cores and 32GB of RAM, the comment field can contain `xx.kubernetes.io / need-ip:32` to specify that the target node requires at least 2... 32 IP address.

[0074] Alternatively, considering that when users input IP resource requirement information, they need to have a good understanding of the container resources and IP resources required for specific business needs, which relies heavily on manual network management experience, the efficiency and accuracy cannot be guaranteed. Therefore, to further improve the automation and accuracy of container network management and reduce the dependence of IP resource allocation on business experience, the process of determining the IP resource requirement information of the target node in this embodiment of the invention can also be as follows:

[0075] Step 102: Calculate the number of containers that the target node can accommodate based on the node specification information and the internal container specification information of the target node.

[0076] The node specification information describes the configuration of computing resources on the host machine where the target node resides, such as the number of CPUs and memory capacity. Correspondingly, the container specification information describes the configuration rules of computing resources for a single container on the target node, such as the number of CPUs and memory capacity. It's easy to understand that containers achieve specific functions by occupying node configuration resources (including computing resources and IP resources). The more computing resources a single container occupies, the fewer containers of that type can be configured on the target node. Therefore, the number of containers that a target node can accommodate can be determined based on the ratio of the node specification information to the container specification information.

[0077] Step 103: Determine the IP resource requirements of the target node based on the number of containers that can be accommodated.

[0078] Considering that there is a one-to-one correspondence between containers and IP addresses, the number of containers that can be accommodated can be determined as the number of IP addresses required by the target node.

[0079] It is easy to understand that before deploying the target container based on the target node, it is first necessary to create the node cluster where the target node resides. During network initialization, the administrator can request the independent network segment that the cluster wishes to use. Therefore, in another embodiment of the present invention, the method further includes the following step before step 10:

[0080] Step 110: Obtain cluster creation request; the cluster creation request includes the network segment to be allocated.

[0081] The network segment to be allocated is an independent container network segment (which can be denoted as clusterCIDR) manually assigned to the container cluster by the administrator when the cluster is created. For example, the network segment to be allocated, clusterCIDR, could be 192.168.0.0 / 16.

[0082] Step 111: Perform network segment conflict detection based on the network segment to be allocated and the network segment already occupied. When it is determined that there is no conflict between the network segment to be allocated and the network segment already occupied, determine the network segment to be allocated as the available network segment of the cluster.

[0083] To ensure the availability of network segments within the cluster, before allocating a network segment to the target container cluster, it's necessary to determine if there's a conflict between an existing network segment already occupied by containers related to other services and the network segment to be allocated. If so, the subsequent network initialization process for the target container cluster needs to be stopped. If no conflict exists, the network segment to be allocated is assigned as a usable network segment to the target container cluster. The already occupied network segments can be determined based on a pre-defined CMDB database corresponding to the business system. By checking the container network segment conflict records in the CMDB database in real time, the target container cluster's container network has a locking mechanism, ensuring concurrent reliability.

[0084] Step 20: Based on the IP resource requirement information, search within the available network segment of the target container cluster to obtain the target network segment corresponding to the target node.

[0085] Specifically, each IP address in the available network segment of the cluster is matched with the IP resource demand information. The matched IP addresses are then combined to obtain the target network segment corresponding to the target node. Specifically, when the IP resource demand information is the target number of IP addresses, the target number of unused IP addresses can be selected from the available network segment of the cluster based on the IP address occupancy status to form the target network segment.

[0086] Optionally, when the IP resource requirement information is a target IP type, IP addresses in the cluster's available network segments that match the target IP type and are currently unoccupied can be added to the target network segment. Optionally, when there is a specified requirement for a node network segment, the IP resource requirement information can be a target IP address range. Unoccupied IP addresses in the cluster's available network segments can be extracted based on the target IP address range. If the IP addresses within the target IP address range are unoccupied, the target IP address range can be used as the target network segment.

[0087] To record and provide feedback on network segment allocation results, facilitating visualization of subsequent container network management, the target network segment can be written into an extended field in the target node's node configuration file. As described in step 101 above, this extended field is used for transmitting custom types of information between the container creator and the container management platform. Therefore, by correspondingly writing the target network segment into the extended field, users can easily obtain feedback on the fulfillment of IP resource requirements after writing the target node's IP resource requirements into the node configuration file. Specifically, continuing with the example in step 101 above, the target network segment allocation result refers to... Figure 2 ,.like Figure 2 As shown, for node-1 with 4 cores and 16GB of RAM, its corresponding IP resource capacity requirement is determined to be 16. A container subnet of length 16 is allocated to node-1, such as 192.168.0.0 / 28. The extended field of the node configuration file for node-1 is written as xx.kubernetes.io / podCIDR:192.168.0.0 / 28, where podCIDR (i.e., container subnet) represents the subnet allocated to the containers within this node. Node-2 has the same configuration as node-1, and its IP resource capacity requirement is also the same. Therefore, the IP subnet allocation result for node-2 is also 192.168.0.0 / 28. For node-3 with 8 cores and 32GB of RAM, its corresponding IP resource capacity requirement is determined to be 32. A container subnet with a length of 32 is allocated to node-3, such as 192.168.32.0 / 27. And xx.kubernetes.io / podCIDR:192.168.0.32 / 27 is written in the extended field of the node configuration file corresponding to node-3.

[0088] Furthermore, in order to improve the efficiency of finding available IP addresses in the available network segments of the cluster, and to divide the target network segment from the available network segments of the cluster, minimize IP fragmentation, and improve the utilization rate of IP resources, bitmap files can be used to maintain the status of IP addresses in the available network segments of the cluster. Specifically, the IP resource demand information includes the number of IP addresses required.

[0089] Step 20 also includes: Step 201: Construct a bitmap file based on the occupancy of IP addresses within the available network segment of the cluster.

[0090] The bitmap file can be a bitmap file, in which each IP address corresponds to a flag bit. The flag value of this flag bit is used to indicate whether the IP address is occupied. For example, when the IP address is occupied, the flag bit can be marked as 1, and when the IP address is not occupied, the flag bit can be marked as 0.

[0091] Step 202: Merge adjacent addresses of the number of unoccupied IP addresses required by the IP address according to the bitmap file to obtain the target network segment of the target node.

[0092] In order to minimize IP fragmentation and improve the utilization rate of IP resources, adjacent IP addresses in the bitmap file whose values ​​in their identifier bits represent unoccupied IP addresses can be merged to obtain candidate network segments. Then, the required number of IP addresses can be extracted from the candidate network segments as the target network segment.

[0093] Step 30: Register the target node for routing in a preset Layer 3 network device according to the target network segment, so that the Layer 3 network device can forward traffic for the target node.

[0094] In particular, considering that the IP resource requirements of the target node may change dynamically, especially in cloud-native transformation scenarios, since the configuration information of the virtual machines acting as host machines can be dynamically adjusted, it is necessary to dynamically adjust the specifications of the IP resources corresponding to the host nodes. This ensures that the IP resources are compatible with the computing resources configured on the nodes, avoiding situations where high computing performance is configured but there are insufficient IP addresses, or low computing performance is configured but there are excess IP addresses, thus preventing waste of IP or computing resources. Therefore, the target network segment corresponding to the target node can be updated in real time according to changes in IP resource requirements, meaning the update frequency of the target network segment may be relatively high.

[0095] Therefore, considering that existing methods of attaching containers to virtual bridges or OVS bridges are inefficient in updating container routes and are unsuitable for scenarios with frequent container IP address updates, the long links for data forwarding at the bridge layer result in weak network performance, and traditional overlay solutions also suffer from performance losses due to packet encapsulation and decapsulation. In contrast, policy-based routing offers greater personalization, allowing for more flexible configuration and modification. Furthermore, it bypasses packet encapsulation and decapsulation during forwarding through Layer 3 routing devices, resulting in better network performance. Additionally, policy-based routing eliminates the forwarding performance losses caused by the bridge layer after traffic reaches the virtual machine, further improving container network performance.

[0096] Therefore, to improve the performance and IP address update efficiency of container networks, this embodiment of the invention employs a Layer 3 routing approach to implement container networks. Specifically, a target network segment can be bound to a target node. Then, by calling the underlying network device interface, the target network segment bound to the target node is written into the global dynamic routing table of the Layer 3 network device. This allows the Layer 3 network device to look up the target address in the global dynamic routing table when it receives external traffic. If the target address matches the target network segment where the target node is located, the external traffic is redirected to the target node, enabling external access to the containers on the target node.

[0097] After the target node is registered with the Layer 3 routing device, in order to further realize container-level traffic routing, policy routes can be established for the target node. These policy routes will then guide traffic arriving at the target node to its next hop until it reaches the target address. Specifically, step 30 may include:

[0098] Step 301: Obtain a container creation request, which is used to create a target container on the target node.

[0099] The container creation request can be sent by the manager in step 110 above.

[0100] Step 302: Assign a target IP address from the target network segment to the target container.

[0101] Specifically, an unused IP address is searched within the target network segment, and the found unused IP address is assigned as the target IP to the target container.

[0102] Step 303: Create policy routing rules corresponding to the target container to import the traffic forwarded by the Layer 3 network device to the target node into the target container.

[0103] Specifically, the policy routing rules corresponding to the target container are written into the policy routing entries corresponding to the target node. Each policy routing entry includes the triggering condition for the node's priority and the action to be executed after triggering. For example... Figure 3 This diagram illustrates the data plane access of containers across hosts. Figure 4 This diagram illustrates the policy routing for host node-1. Figure 5 A schematic diagram of the routing table 100 for host node-1 is shown. Figure 6 This diagram illustrates the policy routing for host node-2. Figure 7 A schematic diagram of the routing table main of host node-2 is shown.

[0104] in, Figure 3The global dynamic routing table in the system registers routes for the IP network segment 192.168.1.0 / 24 bound to node-1 and the IP network segment 192.168.2.0 / 24 bound to node-2, so that external traffic is diverted to node-1 via 10.118.8.5 and to node-2 via 10.118.8.6. After the container IP address of the target node is allocated, in actual application, the network processing of the container can be as follows: obtain the traffic request sent by the source address to the target container; query the policy route configured on the target node where the target container is located according to the source address to obtain the forwarding path between the source address and the target container; the policy route includes multiple preset target node priorities, triggering conditions and corresponding route lookup actions; forward the traffic request to the target container according to the forwarding path. Specifically, as follows... Figure 3-7 As shown, container A (192.168.1.1) accesses container B (192.168.2.1). A default gateway of 169.254.1.1 and a static ARP entry are injected into container A. Because 169.254.1.1 and container A's IP address 192.168.1.1 are not on the same subnet, the ARP protocol cannot be used to obtain the gateway MAC address. Therefore, a static ARP entry is injected, making the MAC address of gateway 169.254.1.1 the MAC address of the veth device on the node. Thus, the traffic successfully reaches the host node-1. After the data packet arrives at node-1, according to the host node's policy routing guidance, i.e., From 192.168.1.1 look up 100, it is determined that the routing table 100 needs to be checked. Then, according to... Figure 5 As shown in routing table 100, the packet originates from the eth0 network interface. After being forwarded through Layer 3 routing, the packet is forwarded to Node-2. Upon reaching Node-2, the packet is routed according to Node-2's policy as follows... Figure 6 As shown, view the routing table main. The routing table main is as follows: Figure 7 As shown, the next step is to send the data to the corresponding veth device, which will eventually reach the target address.

[0105] In particular, considering that cloud-native transformation scenarios often involve the mixed use of container and non-container technologies, such as using virtual machines as host nodes in container clusters, and given that the resource configuration of virtual machines can be dynamically adjusted, the existing fixed IP address allocation scheme may result in a mismatch between the dynamically adjusted computing resources and the fixed IP resources, leading to low resource utilization. Therefore, in another embodiment of the present invention, after step 30, the method further includes:

[0106] Step 311: Detect the change information of the IP resource demand information of the target node.

[0107] In this context, regarding the method of determining IP resource demand information, when IP resource demand is obtained by reading extended fields in the node configuration file, the demand change information can be obtained by listening to the extended fields in the target node's node configuration file, such as listening to the value of need-ip in the comment field.

[0108] Correspondingly, when the IP resource demand information is automatically calculated based on the node specification information and the node content container specification information, the demand change information can be calculated by detecting changes in the node specification information and the node content container specification information.

[0109] Step 312: Dynamically adjust the target network segment according to the demand change information to obtain the adjusted network segment.

[0110] Specifically, when the IP resource demand of the target node increases, the target network segment needs to be expanded. Specifically, idle IP addresses can be added to the target network segment. Conversely, when the IP resources of the target node decrease, to avoid wasting IP resources, unallocated IP addresses in the target network segment can be reclaimed. Therefore, step 312 also includes:

[0111] Step 3121: When it is determined that the IP resource demand of the target node increases, search for an idle network segment in the available network segments of the cluster and add the idle network segment to the target network segment.

[0112] This can be achieved by searching for a new free IP address in the aforementioned bitmap file and adding it to the target network segment. Furthermore, the free IP address can also be written into the extended field corresponding to the target node.

[0113] Step 3122: When it is determined that the IP resource demand of the target node is reduced, the unused IPs in the target network segment are reclaimed.

[0114] The process of IP reclamation includes: detecting the IP occupancy status on the target node, reclaiming unassigned IPs, and canceling the reclamation and handling errors when IPs have already been assigned. Furthermore, the IP reclamation status can be written to an extended field corresponding to the target node.

[0115] Step 313: Based on the adjusted network segment, the target node performs route registration again in the preset Layer 3 network devices.

[0116] In order to enable the Layer 3 network device to forward traffic to the target node after the network segment is adjusted, the adjusted network segment is bound to the target node. The underlying network device interface is called to write the adjusted network segment corresponding to the target node into the global dynamic routing table of the Layer 3 network device, thereby completing the Layer 3 route registration of the target node after the network segment is adjusted.

[0117] Unlike existing popular overlay container network solutions, which typically use EIP solutions like kube-ovn for network connectivity, this invention avoids the waste of physical network IP resources by using a separate container network segment. This solution requires manual application and allocation of EIPs (Elastic Public IPs), which is inefficient, lacks automation, and wastes physical network segment IPs. Underlay container network solutions like Calico require enabling BGP (Border Gateway Protocol) on the underlying network devices, which is highly intrusive. This invention uses a dedicated container network segment, avoiding the waste of physical network segment IP resources. It also efficiently achieves connectivity between the container network and the physical network through Layer 3 routing, maximizing automation and eliminating the need for manual network connectivity configuration. Furthermore, it eliminates the need to enable BGP, reducing network security risks.

[0118] In another embodiment of the present invention, for the sake of low coupling, high availability, and high reusability in software design, it can be achieved through a method such as Figure 8 The target container network component shown is implemented, wherein, as Figure 8 As shown, the target container network component consists of three parts:

[0119] (1) Agent: Deployed on each node of the container cluster, responsible for installing the Majin-CNI binary and other general plugin binaries to the specified directory, and configuring the specified kernel parameters. It listens for changes in the PodCIDR annotation of the local node object and registers routes by calling the underlying device interface.

[0120] (2) CNI Plugin: This is a binary file installed on each node, which is only invoked and run by Kubelet when a pod is created or deleted. It can create or delete corresponding policy routing entries for a pod.

[0121] (3) IPAMD: Responsible for listening to the IP capacity requirements entered by the administrator in the annotations on each Node, allocating container subnets (PodCIDR) on demand using the Bitmap algorithm, and filling the results into the annotations of the Node objects after allocation. It should be noted that only one IPAMD needs to be installed in a container cluster, which is responsible for global IP address allocation and recording.

[0122] The embodiments of the present invention are as follows: Figure 8The target container management component shown listens to Node object annotations in real time and dynamically registers routing tables, supporting dynamic modification of node container network segment capacity requirements, improving the utilization of container network IP resources and virtual machine computing resources, and is more suitable for large-scale container clusters within enterprises.

[0123] The container management method provided in this invention determines the IP resource requirements of a target node in the target container cluster when a network initialization request corresponding to the target container cluster is received. Based on the IP resource requirements, the method searches the available network segments of the target container cluster to obtain the target network segment corresponding to the target node. Then, based on the target network segment, the method registers the target node with a preset Layer 3 network device, enabling the Layer 3 network device to forward traffic for the target node. This differs from existing methods that typically allocate IP resources evenly to nodes within a container cluster, failing to consider the actual IP requirements of host nodes with different configurations, leading to a mismatch between the computing resources allocated to a node and the IP resources allocated to it. This invention can allocate IP resources to target nodes on demand based on their IP resource requirements and the available network segment information of the cluster where the node resides. This improves the resource utilization of IP and container resources in the container cluster, thereby optimizing resource utilization in cloud-native migration scenarios where containers and non-container applications such as virtual machines are used together. Furthermore, in order to adapt to the above-mentioned flexible on-demand IP allocation method, unlike the existing technology that generally uses bridges to forward container traffic, the embodiments of the present invention directly forward traffic through Layer 3 routing. This not only eliminates the forwarding performance loss of the bridge layer, but more importantly, the configuration and registration of Layer 3 routing are more flexible and customizable. As a result, it can be updated in real time when IP requirements and allocation schemes change, ensuring the management efficiency and network availability of the container network.

[0124] Figure 9 A schematic diagram of the structure of a container network management device provided in an embodiment of the present invention is shown. Figure 3 As shown, the device 40 includes: a determination module 401, a search module 402, and a registration module 403.

[0125] The determination module 401 is used to determine the IP resource requirement information of the target node in the target container cluster when a network initialization request corresponding to the target container cluster is received.

[0126] The lookup module 402 is used to search in the cluster available network segment corresponding to the target container cluster according to the IP resource requirement information to obtain the target network segment corresponding to the target node;

[0127] The registration module 403 is used to perform route registration for the target node in a preset Layer 3 network device according to the target network segment, so that the Layer 3 network device can forward traffic for the target node.

[0128] The operation process of the container network management device provided in this embodiment of the invention is largely the same as that of the aforementioned method embodiment, and will not be described again.

[0129] The container network management device provided in this embodiment of the invention determines the IP resource requirement information of the target node in the target container cluster when it receives a network initialization request corresponding to the target container cluster. Based on the IP resource requirement information, it searches the available network segments of the target container cluster to obtain the target network segment corresponding to the target node. Then, it registers the target node with a preset Layer 3 network device based on the target network segment, enabling the Layer 3 network device to forward traffic for the target node. This differs from existing methods that typically allocate IP resources evenly to nodes within a container cluster, without considering the actual IP requirements of host nodes with different configurations, leading to a mismatch between the computing resources of a node and the IP resources allocated to it. This embodiment of the invention can allocate IP resources to the target node on demand based on the target node's IP resource requirement information and the available network segment information of the cluster where the node resides, thereby improving the resource utilization of IP resources and container resources in the container cluster, and optimizing resource utilization in a mixed environment of containers and non-container applications such as virtual machines in cloud-native migration scenarios. Furthermore, in order to adapt to the above-mentioned flexible on-demand IP allocation method, unlike the existing technology that generally uses bridges to forward container traffic, the embodiments of the present invention directly forward traffic through Layer 3 routing. This not only eliminates the forwarding performance loss of the bridge layer, but more importantly, the configuration and registration of Layer 3 routing are more flexible and customizable. As a result, it can be updated in real time when IP requirements and allocation schemes change, ensuring the management efficiency and network availability of the container network.

[0130] Figure 10 The diagram shows a structural schematic of a container network management device provided in an embodiment of the present invention. The specific embodiments of the present invention do not limit the specific implementation of the container network management device.

[0131] like Figure 10 As shown, the container network management device may include: a processor 502, a communications interface 504, a memory 506, and a communications bus 508.

[0132] The processor 502, communication interface 504, and memory 506 communicate with each other via communication bus 508. Communication interface 504 is used to communicate with other network elements, such as clients or other servers. The processor 502 executes program 510, specifically performing the relevant steps described in the embodiment of the container network management method.

[0133] Specifically, program 510 may include program code, which includes computer-executable instructions.

[0134] Processor 502 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention. The container network management device includes one or more processors, which may be processors of the same type, such as one or more CPUs; or processors of different types, such as one or more CPUs and one or more ASICs.

[0135] Memory 506 is used to store program 510. Memory 506 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0136] Specifically, program 510 can be invoked by processor 502 to cause the container network management device to perform the following operations:

[0137] When a network initialization request corresponding to the target container cluster is received, the IP resource requirement information of the target node in the target container cluster is determined.

[0138] Based on the IP resource requirement information, a search is performed on the cluster available network segment corresponding to the target container cluster to obtain the target network segment corresponding to the target node;

[0139] Based on the target network segment, the target node performs route registration in a preset Layer 3 network device, so that the Layer 3 network device forwards traffic for the target node.

[0140] The operation process of the container network management device provided in this embodiment of the invention is largely the same as that of the aforementioned method embodiment, and will not be repeated here.

[0141] The container network management device provided in this embodiment of the invention determines the IP resource requirements of a target node in the target container cluster when it receives a network initialization request corresponding to the target container cluster. Based on the IP resource requirements, it searches the available network segments of the target container cluster to obtain the target network segment corresponding to the target node. Then, it registers the target node with a preset Layer 3 network device based on the target network segment, enabling the Layer 3 network device to forward traffic for the target node. This differs from existing methods that typically allocate IP resources evenly to nodes within a container cluster, failing to consider the actual IP requirements of host nodes with different configurations, leading to a mismatch between the computing resources allocated to a node and the IP resources allocated to it. This embodiment of the invention can allocate IP resources to a target node on demand based on its IP resource requirements and the available network segment information of the cluster where the node resides. This improves the resource utilization of IP and container resources in the container cluster, thereby optimizing resource utilization in a mixed environment of containers and non-container applications such as virtual machines in cloud-native migration scenarios. Furthermore, in order to adapt to the above-mentioned flexible on-demand IP allocation method, unlike the existing technology that generally uses bridges to forward container traffic, the embodiments of the present invention directly forward traffic through Layer 3 routing. This not only eliminates the forwarding performance loss of the bridge layer, but more importantly, the configuration and registration of Layer 3 routing are more flexible and customizable. As a result, it can be updated in real time when IP requirements and allocation schemes change, ensuring the management efficiency and network availability of the container network.

[0142] This 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 above method embodiments.

[0143] Specifically, the executable instructions can be used to cause the container network management device to perform the following operations:

[0144] When a network initialization request corresponding to the target container cluster is received, the IP resource requirement information of the target node in the target container cluster is determined.

[0145] Based on the IP resource requirement information, a search is performed on the cluster available network segment corresponding to the target container cluster to obtain the target network segment corresponding to the target node;

[0146] Based on the target network segment, the target node performs route registration in a preset Layer 3 network device, so that the Layer 3 network device forwards traffic for the target node.

[0147] The operation process of storing executable instructions on the computer storage medium provided in this embodiment of the invention is largely the same as that in the aforementioned method embodiments, and will not be described again.

[0148] The executable instructions stored in the computer storage medium provided in this embodiment of the invention determine the IP resource requirement information of the target node in the target container cluster when a network initialization request corresponding to the target container cluster is received; search the available network segments of the cluster corresponding to the target container cluster according to the IP resource requirement information to obtain the target network segment corresponding to the target node; and register the target node with a preset Layer 3 network device according to the target network segment so that the Layer 3 network device can forward traffic for the target node. This differs from existing methods that generally allocate IP resources evenly to nodes in a container cluster, without considering the actual IP requirements of host nodes with different configurations, leading to a mismatch between the computing resources of a node and the IP resources allocated to it. This embodiment of the invention can allocate IP resources to the target node on demand based on the target node's IP resource requirement information and the available network segment information of the cluster where the node is located, thereby improving the resource utilization of IP resources and container resources in the container cluster, and thus optimizing resource utilization in a mixed environment of containers and non-container applications such as virtual machines in cloud-native migration scenarios. Furthermore, in order to adapt to the above-mentioned flexible on-demand IP allocation method, unlike the existing technology that generally uses bridges to forward container traffic, the embodiments of the present invention directly forward traffic through Layer 3 routing. This not only eliminates the forwarding performance loss of the bridge layer, but more importantly, the configuration and registration of Layer 3 routing are more flexible and customizable. As a result, it can be updated in real time when IP requirements and allocation schemes change, ensuring the management efficiency and network availability of the container network.

[0149] This invention, upon receiving a network initialization request corresponding to a target container cluster, determines the IP resource requirements of a target node within that cluster. Based on these requirements, it searches the available network segments of the target container cluster to obtain the target network segment for the target node. Then, it registers the target node's route on a pre-defined Layer 3 network device using this target network segment, enabling the Layer 3 network device to forward traffic for the target node. This differs from existing methods that typically allocate IP resources evenly across nodes within a container cluster, neglecting the actual IP requirements of host nodes with varying configurations, leading to a mismatch between the node's computing resources and the allocated IP resources. This invention allocates IP resources to the target node on demand based on its IP resource requirements and the available network segments of the cluster it resides in. This improves the utilization of both IP and container resources within the container cluster, thereby optimizing resource utilization in cloud-native migration scenarios where containers and non-container applications such as virtual machines coexist. Furthermore, in order to adapt to the above-mentioned flexible on-demand IP allocation method, unlike the existing technology that generally uses bridges to forward container traffic, the embodiments of the present invention directly forward traffic through Layer 3 routing. This not only eliminates the forwarding performance loss of the bridge layer, but more importantly, the configuration and registration of Layer 3 routing are more flexible and customizable. As a result, it can be updated in real time when IP requirements and allocation schemes change, ensuring the management efficiency and network availability of the container network.

[0150] This invention provides a container network management device for executing the above-described container network management method.

[0151] This invention provides a computer program that can be invoked by a processor to cause a container network management device to execute the container network management method in any of the above method embodiments.

[0152] This invention provides a computer program product, which includes a computer program stored on a computer-readable storage medium. The computer program includes program instructions that, when executed on a computer, cause the computer to perform the container network management method in any of the above method embodiments.

[0153] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings herein. The required structure for constructing such systems is apparent from the above description. Furthermore, the embodiments of the present invention are not directed to any particular programming language. It should be understood that the content of the invention described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of the invention.

[0154] Numerous specific details are set forth in the specification provided herein. However, it will be 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 so as not to obscure the understanding of this specification.

[0155] Similarly, it should be understood that, in order to streamline the invention and aid in understanding one or more of the various aspects of the invention, features of the embodiments of the invention are sometimes grouped together in a single embodiment, figure, or description thereof in the above description of exemplary embodiments of the invention. However, this disclosure should not be construed as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim.

[0156] Those skilled in the art will understand that modules in the device of the embodiments can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiments can be combined into a single module, unit, or component, and can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or units of any method or device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0157] It should be noted that the above embodiments are illustrative of the invention and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

Claims

1. A method of managing a network of containers, characterized by, The method comprises: When receiving a network initialization request corresponding to a target container cluster, determining IP resource requirement information of a target node in the target container cluster; According to the IP resource requirement information, searching in a cluster available network segment corresponding to the target container cluster to obtain a target network segment corresponding to the target node, wherein when the IP resource requirement information is a target IP address quantity, according to the occupation of IP addresses in the cluster available network segment, a target IP address quantity of unoccupied IP addresses is screened out from the cluster available network segment to form the target network segment; when the IP resource requirement information is a target IP type, IP addresses of the target IP type and in an unoccupied state are added to the target network segment from the cluster available network segment; According to the target network segment, performing routing registration of the target node in a preset three-layer network device, so that the three-layer network device performs traffic forwarding for the target node; The IP resource requirement information comprises an IP address requirement quantity; and according to the IP resource requirement information, searching in a cluster available network segment corresponding to the target container cluster to obtain a target network segment corresponding to the target node comprises: constructing a bitmap file according to the occupation of IP addresses in the cluster available network segment; and according to the bitmap file, performing adjacent address merging on the IP address requirement quantity of unoccupied IP addresses to obtain the target network segment of the target node.

2. The method of claim 1, wherein, After the routing registration of the target node in the preset three-layer network device according to the target network segment, so that the three-layer network device performs traffic forwarding for the target node, the method further comprises: Detecting demand change information of the IP resource requirement information of the target node; According to the demand change information, dynamically adjusting the target network segment to obtain an adjusted network segment; According to the adjusted network segment, performing routing registration of the target node in the preset three-layer network device again.

3. The method of claim 2, wherein, The dynamically adjusting the target network segment according to the demand change information to obtain an adjusted network segment comprises: When it is determined that the IP resource requirement of the target node increases, searching for an idle network segment in the cluster available network segment, and adding the idle network segment to the target network segment; When it is determined that the IP resource requirement of the target node decreases, recycling unoccupied IP addresses in the target network segment.

4. The method of claim 1, wherein, The determining the IP resource requirement information of the target node in the target container cluster when receiving the network initialization request corresponding to the target container cluster comprises: Reading a preset extension field in a node configuration file of the target node to obtain the IP resource requirement information; wherein the extension field is used to write the IP resource requirement information; Or, calculating a tolerable container quantity of the target node according to node specification information and node container specification information of the target node; According to the tolerable container quantity, determining the IP resource requirement information of the target node.

5. The method of claim 1, wherein, The method comprises the following steps: obtaining a container creation request, the container creation request being used to create a target container on the target node; allocating a target IP from the target network segment to the target container; creating a policy routing rule corresponding to the target container, so as to guide the traffic of the three-layer network device to the target container.

6. The method of claim 1, wherein, Before the step of determining the IP resource requirement information of the target node in the target container cluster when receiving the network initialization request corresponding to the target container cluster, the method further comprises the steps of: obtaining a cluster creation request, the cluster creation request comprising a to-be-allocated network segment; performing network segment conflict detection according to the to-be-allocated network segment and an occupied network segment, and determining the to-be-allocated network segment as a cluster available network segment when determining that there is no conflict between the to-be-allocated network segment and the occupied network segment.

7. A container network management apparatus characterized by comprising: The device comprises: a determining module configured to determine the IP resource requirement information of the target node in the target container cluster when receiving the network initialization request corresponding to the target container cluster; a searching module 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, wherein when the IP resource requirement information is a target IP address quantity, a target IP address quantity of unoccupied IP addresses is screened from the cluster available network segment according to the occupation of the IP addresses in the cluster available network segment, to form the target network segment; and when the IP resource requirement information is a target IP type, an IP address of the target IP type and in an unoccupied state is added to the target network segment from the cluster available network segment; a registering module configured to perform route registration for the target node in a preset three-layer network device according to the target network segment, so that the three-layer network device performs traffic forwarding for the target node. The IP resource requirement information comprises an IP address quantity requirement; and the searching in the cluster available network segment corresponding to the target container cluster according to the IP resource requirement information, to obtain the target network segment corresponding to the target node, comprises: constructing a bitmap file according to the occupation of the IP addresses in the cluster available network segment; and performing adjacent address merging on the IP address quantity requirement of unoccupied IP addresses according to the bitmap file, to obtain the target network segment of the target node.

8. A container network management device, characterized by The device comprises: a processor, a memory, a communication interface and a communication bus, the processor, the memory and the communication interface performing communication with each other through the communication bus; the memory is used to store at least one executable instruction, the executable instruction causing the processor to perform the operations of the container network management method in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The storage medium stores at least one executable instruction, and the executable instruction causes the container network management device to perform the operations of the container network management method in any one of claims 1-6 when the container network management device runs the executable instruction.

Images